VPS hosting có an toàn không? Bạn kiểm soát gì

VPS hosting có an toàn không? Câu trả lời ngắn

Có. VPS hosting an toàn cho hầu hết công việc mà người dùng thuê nó để thực hiện, đồng thời an toàn hơn rõ rệt so với shared hosting. VPS (virtual private server) là một máy ảo có kernel riêng, bộ nhớ riêng, ổ đĩa riêng và user account riêng. Hypervisor chạy máy ảo đó sẽ ngăn các khách hàng khác truy cập cả bốn thành phần này. Người thuê server nằm cạnh server của bạn trên cùng một máy vật lý không thể đọc file, liệt kê process, đăng nhập vào server hoặc xem network traffic của bạn.

Câu trả lời đầy đủ gồm hai phần. Nhà cung cấp sở hữu phần cứng và hypervisor. Bạn sở hữu mọi thứ bên trong máy ảo, và gần như mọi sự cố thực tế đều bắt đầu từ đó. Server thường bị xâm nhập qua một cổng đang mở, SSH password yếu, package không được cập nhật hoặc secret nằm trong file đã bị công khai. Rất hiếm khi server bị xâm nhập thông qua hypervisor.

Hypervisor thực sự phân tách những gì

Hypervisor là phần mềm chạy các máy ảo trên một máy chủ vật lý. Trên VPS KVM (KVM là kernel-based virtual machine, tiêu chuẩn trên các máy chủ Linux), server của bạn là một máy ảo đầy đủ. Máy ảo này khởi động kernel riêng. Host cấp cho máy ảo một vùng bộ nhớ vật lý cố định. Memory management unit của processor từ chối mọi truy cập nằm ngoài vùng đó, vì vậy code chạy trong guest khác hoàn toàn không thể address RAM của bạn. Không có filesystem dùng chung và không có bảng user dùng chung, nên quyền file trên server của máy khách khác không có tác dụng trên server của bạn.

Shared hosting hoạt động khác. Nhiều website chạy trong cùng một operating system, dưới cùng một web server và một PHP install, dưới dạng các user account thông thường. Ranh giới duy nhất là quyền file. Một lỗi quyền, hoặc một plugin có lỗ hổng chạy dưới user có thể đọc quá nhiều dữ liệu, có thể truy cập file của account khác. Đó là khoảng cách mà việc chuyển từ shared hosting sang VPS khắc phục.

Hãy kiểm tra kỹ gói bạn mua, vì không phải plan nào được bán dưới tên VPS cũng là máy ảo. Các plan dựa trên container (OpenVZ, LXC, Virtuozzo) dùng chung kernel của host và phân tách khách hàng bằng namespace và cgroup thay vì hardware virtualization. Đây là ranh giới yếu hơn, vì lỗi kernel trên host cũng là lỗi kernel trong server của bạn. Bạn cũng không thể load kernel module trên các plan này, nên một số software sẽ không chạy được. KVM là lựa chọn mặc định an toàn hơn. Hãy hỏi rõ bạn được cấp loại nào trước khi thanh toán.

Những gì một “hàng xóm ồn ào” có thể gây ra cho bạn

Dùng chung một máy chủ vật lý sẽ làm giảm tốc độ, và đó là ảnh hưởng duy nhất. Các guest trên cùng một máy dùng chung CPU vật lý và ổ đĩa. Khi CPU đang bận xử lý tác vụ của khách hàng khác, vCPU của bạn phải chờ. Linux ghi nhận thời gian chờ này là steal time: trường %st trong top và vmstat. Nếu steal time duy trì trên vài phần trăm trong nhiều giờ, máy chủ vật lý đang bị phân bổ quá tải. Điều đó không có nghĩa là có người đang đọc dữ liệu của bạn. Cách xử lý là chọn gói khác hoặc nhà cung cấp khác. Trước khi quyết định, bạn có thể đo CPU và ổ đĩa thực tế được cấp cho mình.

Có một ảnh hưởng giữa các khách hàng mà bạn nên biết, nhưng đây không phải lỗ hổng bảo mật. Nếu bạn gửi email từ VPS, địa chỉ IP của bạn nằm trong một dải IP cũng được các khách hàng khác sử dụng. Một hàng xóm gửi spam có thể khiến một phần dải IP đó bị đưa vào blocklist. Khi đó, email của bạn có thể vào thư mục spam dù nguyên nhân không phải do bạn. Các nhà cung cấp kiểm soát hành vi lạm dụng thường có những dải IP sạch hơn. Nếu email quan trọng với bạn, hãy hỏi về vấn đề này.

Những gì hàng xóm độc hại không thể làm, và trường hợp hiếm khi họ có thể

Khách hàng dùng cùng host không có đường truy cập đến các file của bạn. Họ không thể xem các process của bạn, mount disk của bạn hoặc mở shell trên server của bạn, vì không có thành phần nào trong số đó tồn tại bên trong virtual machine của họ. Có một ngoại lệ cần nêu rõ: hãy coi mọi private network của provider là network dùng chung với người lạ, và mã hóa dữ liệu truyền qua đó thay vì cho rằng network này không thể bị quan sát.

Hypervisor escape là có thật. Một lỗi trong lớp virtualization có thể cho phép code bên trong một guest truy cập host, rồi từ host truy cập mọi guest trên đó. Các lỗi này được phát hiện, công bố kèm mã định danh CVE (common vulnerabilities and exposures) và được vá. Hosting provider thường vá nhanh vì toàn bộ hoạt động kinh doanh của họ phụ thuộc vào lớp này. Để khai thác lỗi, kẻ tấn công cần exploit hoạt động được trên một phiên bản hypervisor cụ thể. Đây là thứ quá đắt để dùng cho một hosting account nhỏ.

Side channel giữa các guest cũng là rủi ro có thật. Chúng thuộc họ Spectre và Meltdown, khai thác các cache processor dùng chung để suy ra một lượng nhỏ dữ liệu qua ranh giới giữa các guest. Các bản cập nhật microcode và kernel giảm thiểu rủi ro này, còn tốc độ rò rỉ trong các nghiên cứu đã công bố là rất thấp. Những trường hợp đã công bố chủ yếu là minh chứng nghiên cứu, không phải các cuộc tấn công diện rộng. Rủi ro không bằng 0. Nhưng nó không nằm gần nhóm đầu danh sách những thứ có thể gây hại cho bạn.

Ranh giới giữa trách nhiệm của nhà cung cấp và trách nhiệm của bạn

Nhà cung cấp chịu trách nhiệm về tòa nhà, phần cứng máy chủ vật lý, hypervisor và kernel của host, mạng vật lý, cùng control panel có thể start, stop, rebuild và snapshot server của bạn. Nếu bất kỳ thành phần nào trong số đó gặp lỗi, nhà cung cấp phải khắc phục.

Bạn chịu trách nhiệm về mọi thứ từ operating system trở lên. Điều đó bao gồm các package bạn cài, những port bạn để mở, các account và key có thể đăng nhập, các bản update bạn áp dụng, backup của bạn và code ứng dụng của chính bạn. Hầu hết gói VPS đều là unmanaged. Điều đó có nghĩa là không ai patch server thay bạn và việc gửi support ticket cũng không khiến họ thực hiện việc đó. Phân biệt managed và unmanaged là phần đáng đọc trước khi mua, vì nó quyết định bao nhiêu trách nhiệm trong danh sách đó thuộc về bạn.

Một phần trong phạm vi trách nhiệm của bạn rất dễ bị quên: chính hosting control panel. Bất kỳ ai có thông tin đăng nhập đó đều có thể rebuild server hoặc gắn disk của bạn vào một rescue system mà không cần biết bất kỳ password nào bên trong server. Hãy bật xác thực hai yếu tố (2FA) cho hosting account và không dùng lại password đó ở bất kỳ nơi nào khác.

Nhà cung cấp hosting có thể xem dữ liệu của bạn không?

Có, về nguyên tắc là có. Đây là giới hạn thực tế của những gì VPS cung cấp. Image ổ đĩa của bạn nằm trên hệ thống lưu trữ của nhà cung cấp. Console của họ có quyền truy cập ở cấp màn hình vào máy ảo của bạn. Rescue mode có thể khởi động một hệ thống khác và gắn ổ đĩa của bạn vào đó. VPS bảo vệ bạn khỏi những khách hàng khác, còn nhà cung cấp không nằm trong phạm vi cam kết đó.

Nếu bạn lưu dữ liệu không được phép để host đọc, hãy mã hóa dữ liệu ngay trong ứng dụng trước khi ghi dữ liệu đó. Full disk encryption bên trong guest giúp bảo vệ image đã sao chép khi đang lưu trữ, nhưng key phải nằm trong memory khi server đang chạy. Vì vậy, cách này không loại nhà cung cấp khỏi mô hình tin cậy. Mức độ tin cậy tương tự cũng áp dụng cho dedicated server bạn thuê riêng, chỉ ít hơn một lớp dùng chung.

Điều gì thực sự khiến VPS bị xâm nhập

Một service lắng nghe trên mọi interface. Database, cache, message queue và admin panel thường bind vào 0.0.0.0 theo mặc định. Điều đó có nghĩa là service lắng nghe trên mọi network interface, bao gồm interface public. Việc scan trên Internet diễn ra liên tục và tự động, nên một địa chỉ IP mới thường nhận được probe không mong muốn đầu tiên trong vòng vài phút sau khi online. Redis không có password, node Elasticsearch không yêu cầu xác thực, Docker API mở trên port 2375 và admin panel vẫn dùng thông tin đăng nhập mặc định đều bị phát hiện theo cách này, bởi scanner không biết bạn là ai. Bind service vào 127.0.0.1 khi chỉ máy local cần truy cập, và chặn các kết nối còn lại tại firewall.

Docker đi vòng qua firewall của bạn. Việc publish port của container tạo các rule network address translation (NAT) được xử lý trước các rule của ufw (uncomplicated firewall). Vì vậy, container vẫn có thể truy cập từ Internet trong khi ufw status cho biết port đó bị từ chối. Điều này thường khiến những người đã cấu hình đúng mọi thứ khác vẫn bị bất ngờ. Lý do port Docker bỏ qua ufw là nội dung nên đọc trước khi publish port của container.

SSH vẫn bật đăng nhập bằng password. Đọc /var/log/auth.log trên bất kỳ server public nào, bạn sẽ thấy những dòng như Failed password for root from 203.0.113.10 port 54312 ssh2, xuất hiện hàng nghìn lần cả ngày lẫn đêm. Bot thử lần lượt các username và password phổ biến. Chỉ cần đăng nhập bằng password kết hợp với tài khoản root cho phép đăng nhập là đủ để attacker xâm nhập. Chỉ dùng key và tắt đăng nhập root sẽ biến lượng traffic đó thành nhiễu mà bạn có thể bỏ qua.

Dùng một private key ở mọi nơi. Một key được sao chép vào mọi laptop và mọi server có nghĩa là chỉ cần một laptop bị đánh cắp là attacker có thể mở khóa tất cả. SSH key cũng không tự hết hạn, nên key đã cấp cho contractor hai năm trước vẫn hoạt động hôm nay. Mỗi người và mỗi máy dùng một key riêng không tốn chi phí và giới hạn phạm vi mà một key bị đánh cắp có thể truy cập.

Các package không được cập nhật. Một CVE đã công bố đối với web server hoặc application framework của bạn là một bộ hướng dẫn công khai. Scanner sẽ bắt đầu kiểm tra lỗ hổng đó trong vòng vài ngày. Security update là biện pháp phòng thủ rẻ nhất hiện có và có thể tự chạy: xem tự động cập nhật bảo mật trên Ubuntu.

Một secret bị lộ. Password của database và API key nằm trong các file .env. Những file đó có thể bị commit vào repository public hoặc được web server phục vụ do trỏ nhầm directory. Bất kỳ nội dung nào được dán vào context của AI coding agent cũng có thể xuất hiện trong log. Đây là một chủ đề riêng: giữ secret ngoài phạm vi truy cập của agent.

Mọi thứ đều chạy bằng root. Khi application chạy bằng root, chỉ một bug trong application cũng có thể chiếm toàn bộ máy, vì bên trong server không còn boundary nào để ngăn nó lan rộng.

Phần việc của bạn

Không mục nào dưới đây thuộc công việc của hypervisor. Tất cả đều nằm ở phía bạn, và chính phía này quyết định VPS của bạn có an toàn hay không.

• Làm đúng việc trong giờ đầu tiên: mười phút đầu tiên trên một VPS mới hướng dẫn tạo user không phải root và cấu hình firewall.
• Khóa chặt truy cập từ xa: hardening SSH trên VPS.
• Đóng các port bạn không sử dụng: kiến thức cơ bản về firewall ufw.
• Chỉ cấp cho mỗi service quyền truy cập cần thiết: user có least privilege trên VPS.
• Làm chậm các lần đăng nhập brute force: fail2ban trên Ubuntu 24.04.
• Duy trì một bản backup mà bạn đã restore ít nhất một lần: backup VPS bằng restic.

Phần việc của provider đã hoàn tất khi server của bạn boot. Phần việc của bạn mất khoảng một giờ trong ngày đầu tiên và vài phút mỗi tháng sau đó. Nếu bạn vẫn đang so sánh các lựa chọn, VPS thực sự là gì giải thích nền tảng của toàn bộ nội dung này.

FAQ

Một khách hàng khác trên cùng máy chủ vật lý có thể đọc file của tôi không?

Không, nếu bạn dùng KVM VPS. Server của bạn là một máy ảo có kernel riêng và ổ đĩa ảo riêng, cùng một vùng bộ nhớ vật lý do host cấp phát. Bộ xử lý chặn mọi truy cập ra ngoài vùng đó. Các guest không dùng chung filesystem, nên quyền file bên trong server của máy khác không có ý nghĩa trong server của bạn. Các gói dựa trên container như OpenVZ và LXC dùng chung kernel của host và có ranh giới cô lập yếu hơn, vì vậy hãy kiểm tra loại VPS trước khi mua.

VPS có an toàn hơn shared hosting không?

Xét về khả năng cô lập thì có. Với shared hosting, nhiều website chạy trong cùng một hệ điều hành và ranh giới duy nhất là quyền file, nên lỗi trong account khác đôi khi có thể làm lộ file. Với VPS, ranh giới đó là một máy ảo. Đổi lại, host sẽ cập nhật bản vá cho shared hosting, còn với VPS không được quản trị, bạn phải tự cập nhật. VPS chỉ an toàn hơn nếu bạn thực sự cài các bản cập nhật và đóng những cổng không cần thiết.

Nhà cung cấp hosting có thể đọc dữ liệu của tôi không?

Về nguyên tắc là có, và không sản phẩm VPS nào thay đổi được điều đó. Disk image được lưu trên phần cứng của nhà cung cấp, console cho phép truy cập ở cấp màn hình vào máy đang chạy, còn rescue mode có thể khởi động một hệ thống khác và gắn disk của bạn vào đó. Nếu có dữ liệu phải bảo đảm host không thể đọc, hãy mã hóa dữ liệu trong ứng dụng trước khi ghi. Mã hóa disk bên trong guest vẫn giữ key trong memory khi server đang chạy, nên không loại nhà cung cấp khỏi mô hình tin cậy.

Cách phổ biến nhất khiến VPS bị breached là gì?

Một service bị expose hoặc thông tin đăng nhập SSH yếu, với khoảng cách rất lớn so với các nguyên nhân khác. Các scanner tự động liên tục thăm dò mọi địa chỉ IP public, nên database bind vào 0.0.0.0 mà không có password, hoặc admin panel vẫn dùng credential mặc định, sẽ bị phát hiện trong vài phút thay vì vài tháng. /var/log/auth.log trên mọi server public cho thấy phần SSH của vấn đề: các dòng Failed password for root lặp lại từ những địa chỉ trên khắp thế giới. Lỗ hổng escape khỏi hypervisor có tồn tại, nhưng đây là dạng tấn công ở cấp độ nghiên cứu, nhắm vào các mục tiêu có giá trị cao, không phải nguyên nhân của các vụ breached thông thường.