Bảo mật VPS là giảm tối đa đường vào máy chủ và phát hiện sớm khi có bất thường. Với phần lớn VPS, việc cần làm gồm: cập nhật hệ điều hành, đăng nhập bằng SSH key thay cho mật khẩu, không đăng nhập trực tiếp bằng root. Tiếp theo là bật tường lửa chỉ mở cổng thật sự dùng, chặn dò mật khẩu bằng Fail2ban, không mở database ra Internet, sao lưu ra ngoài VPS và theo dõi log.
- Ai chịu trách nhiệm: với VPS không quản lý (unmanaged), nhà cung cấp lo phần cứng và mạng; hệ điều hành, phần mềm và dữ liệu là việc của bạn.
- Làm ngay từ ngày đầu: VPS có IP công khai sẽ bị quét cổng và dò mật khẩu ngay khi lên mạng, không cần ai “nhắm” tới bạn.
- VPS Windows: phần lớn nguyên tắc giống Linux, thay SSH bằng Remote Desktop (RDP); xem phần riêng bên dưới.
Bài này thuộc lộ trình cách sử dụng VPS; lệnh mẫu dùng Ubuntu 24.04 LTS. Bài này là checklist chung cho cả VPS Linux và Windows. Từng lệnh chi tiết hơn cho Ubuntu có ở bài bảo mật VPS Ubuntu.
Checklist bảo mật VPS cho Linux và Windows
Các bộ hướng dẫn bảo mật máy chủ như NIST SP 800-123 và CIS Controls có chung vài nguyên tắc. Đó là chỉ chạy dịch vụ cần thiết, cấp quyền tối thiểu, vá lỗi thường xuyên và ghi log để phát hiện sự cố. Bảng dưới đây chuyển các nguyên tắc đó thành việc cụ thể trên VPS Linux và Windows.

Việc cần làm VPS Linux VPS Windows Ưu tiên Cập nhật hệ điều hành apt upgrade, bật unattended-upgradesWindows Update Ngày đầu Đăng nhập an toàn SSH key ed25519, tắt mật khẩu và rootMật khẩu mạnh, bật NLA cho RDP, khóa tài khoản khi nhập sai nhiều lần Ngày đầu Tường lửa UFW: mở SSH trước, rồi 80/443 Windows Defender Firewall, giới hạn IP được vào RDP Ngày đầu Chặn dò mật khẩu Fail2ban Chính sách khóa tài khoản, giới hạn IP Ngày đầu Đóng dịch vụ thừa Kiểm tra ss -tulpn; database chỉ nghe localhostGỡ role/feature không dùng Tuần đầu Sao lưu Bản sao ra ngoài VPS, thử khôi phục Bản sao ra ngoài VPS, thử khôi phục Tuần đầu Giám sát journalctl, last, cảnh báo tài nguyênEvent Viewer (sự kiện 4625) Định kỳ
Cách bảo mật VPS Linux (Ubuntu 24.04) từng bước
Trên VPS Ubuntu, thứ tự an toàn là: cập nhật hệ thống, tạo user sudo và cài SSH key, kiểm tra đăng nhập bằng key thành công. Sau đó mới tắt mật khẩu, bật tường lửa và cài Fail2ban. Làm ngược thứ tự là nguyên nhân thường gặp khiến người dùng tự khóa mình khỏi VPS.
1. Cập nhật hệ thống và bật cập nhật bảo mật tự động
Dùng bản Ubuntu LTS còn được hỗ trợ (24.04 tại thời điểm viết, xem chu kỳ phát hành Ubuntu). Gói unattended-upgrades được cài sẵn trên Ubuntu Server và mặc định tự cài bản vá bảo mật, nhưng không tự khởi động lại máy (Ubuntu Server docs). Kiểm tra định kỳ xem VPS có cần khởi động lại để nạp kernel mới không.
sudo apt update && sudo apt upgrade -y
# Chạy thử cập nhật tự động, xem log tại /var/log/unattended-upgrades/
sudo unattended-upgrade -v --dry-run
# File này tồn tại nghĩa là cần khởi động lại
ls /var/run/reboot-required
2. Tạo user sudo và đăng nhập bằng SSH key
Tài liệu Ubuntu khuyến nghị khóa thuật toán ed25519 (OpenSSH server). Tạo key trên máy tính của bạn, không tạo trên VPS. Xem thêm SSH key là gì.
# Trên VPS (đang đăng nhập root): tạo user và cấp quyền sudo
adduser tenban
usermod -aG sudo tenban
# Trên máy tính của bạn: tạo key và chép lên VPS
ssh-keygen -t ed25519
ssh-copy-id tenban@IP_VPS # macOS, Linux
# Windows PowerShell không có ssh-copy-id, dùng lệnh sau thay thế:
type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh tenban@IP_VPS "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"
# Mở cửa sổ mới, thử đăng nhập bằng key
ssh tenban@IP_VPS
3. Tắt đăng nhập bằng mật khẩu và đăng nhập root qua SSH
Chỉ làm bước này khi đã đăng nhập được bằng key ở cửa sổ khác. Trên Ubuntu, nên ghi cấu hình vào thư mục /etc/ssh/sshd_config.d/. Lưu ý: với mỗi tùy chọn, OpenSSH dùng giá trị được đọc đầu tiên (sshd_config), và một số bản cài sẵn có thể có file như 50-cloud-init.conf bật lại đăng nhập bằng mật khẩu. Đặt tên file bắt đầu bằng số nhỏ để được đọc trước, rồi kiểm tra cấu hình thực tế bằng sshd -T.
sudo tee /etc/ssh/sshd_config.d/01-bao-mat.conf > /dev/null <<'EOF'
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
EOF
# Kiểm tra cú pháp và giá trị đang có hiệu lực
sudo sshd -t
sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'
sudo systemctl restart ssh
Giữ nguyên phiên SSH đang mở, mở thêm một phiên mới để chắc chắn vẫn đăng nhập được rồi mới thoát.
4. Bật tường lửa UFW đúng thứ tự
Đặt mặc định chặn mọi kết nối vào, mở cổng SSH, rồi mới bật tường lửa (Ubuntu Server docs). Chỉ mở thêm cổng dịch vụ thật sự phục vụ người dùng, thường là 80 và 443 cho website. Sau đó cài SSL trên VPS để dùng HTTPS. Đọc thêm tường lửa là gì.
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH # mở SSH (cổng 22) trước
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose
Nếu IP nhà bạn cố định, thay vì mở cổng SSH cho mọi nơi, dùng sudo ufw allow from IP_CUA_BAN to any port 22 proto tcp. Thêm quy tắc mới và thử đăng nhập được rồi mới xoá quy tắc OpenSSH.
Nếu ứng dụng chạy bằng Docker: cổng do Docker publish đi qua quy tắc riêng và không chịu sự kiểm soát của UFW (tài liệu Docker). Hãy publish cổng nội bộ vào 127.0.0.1, ví dụ -p 127.0.0.1:5678:5678, rồi đưa ra ngoài qua reverse proxy có HTTPS.
5. Có nên đổi cổng SSH không?
Bước này giả định UFW đã bật như ở bước 4; nếu bạn không đổi cổng, bỏ qua bước này. Đổi cổng 22 sang cổng khác giảm lượng dò mật khẩu tự động và làm log gọn hơn, nhưng không thay được SSH key và tường lửa. Hiệu quả hơn là chỉ cho phép IP của bạn vào cổng SSH.
Nếu vẫn đổi cổng trên Ubuntu 24.04, cần lưu ý SSH chạy qua ssh.socket, nên phải nạp lại systemd sau khi sửa (Ubuntu bug #2069041).
# Mở cổng mới trên tường lửa TRƯỚC
sudo ufw allow 2222/tcp
# Khai báo cổng mới
echo 'Port 2222' | sudo tee /etc/ssh/sshd_config.d/02-port.conf
sudo sshd -t
sudo systemctl daemon-reload
sudo systemctl restart ssh.socket
# Thử đăng nhập ở cửa sổ mới: ssh -p 2222 tenban@IP_VPS
# Thành công rồi mới đóng cổng cũ (quy tắc OpenSSH tạo ở bước 4)
sudo ufw delete allow OpenSSH
6. Chặn dò mật khẩu bằng Fail2ban
Fail2ban đọc log đăng nhập và tạm khóa IP nhập sai nhiều lần. Khi đã tắt đăng nhập bằng mật khẩu, Fail2ban chủ yếu giảm tải và giảm log rác. Dù vậy, nó vẫn đáng cài cho SSH và các dịch vụ có trang đăng nhập. Cách xem và bỏ chặn một IP bị khóa nhầm có trong bài bảo mật VPS Ubuntu nêu ở đầu bài.
sudo apt install fail2ban -y
sudo tee /etc/fail2ban/jail.d/sshd.local > /dev/null <<'EOF'
[sshd]
enabled = true
# port = 2222 (bỏ dấu # nếu đã đổi cổng SSH)
EOF
sudo systemctl restart fail2ban
sudo fail2ban-client status sshd
7. Chỉ mở dịch vụ cần thiết, không mở database ra Internet
Mỗi cổng đang mở là một đường vào. Liệt kê dịch vụ đang lắng nghe và tắt những gì không dùng. Database (MySQL, PostgreSQL, Redis) và bảng quản trị chỉ nên nghe trên 127.0.0.1 hoặc qua VPN; cần quản trị từ xa thì dùng đường hầm SSH thay vì mở cổng.
# Dịch vụ đang lắng nghe: cột Local Address là 0.0.0.0 hoặc [::] nghĩa là mở ra mọi mạng
sudo ss -tulpn
# Truy cập MySQL trên VPS từ máy của bạn qua đường hầm SSH, không cần mở cổng 3306.
# Dùng cổng 3307 ở máy bạn để không đụng MySQL cài sẵn trên máy, rồi kết nối tới 127.0.0.1:3307
ssh -L 3307:127.0.0.1:3306 tenban@IP_VPS
8. Sao lưu ra ngoài VPS
Sao lưu không ngăn bị tấn công, nhưng quyết định bạn mất bao nhiêu dữ liệu sau sự cố. Bản sao lưu phải nằm ngoài VPS (mã độc tống tiền thường mã hoá cả bản sao lưu nằm cùng máy) và cần được thử khôi phục. Các bước chi tiết ở bài backup VPS.
9. Theo dõi log và tài nguyên
# Đăng nhập gần đây và đăng nhập thất bại
last -a | head
sudo lastb | head
# Log SSH trong 24 giờ qua
sudo journalctl -u ssh --since "24 hours ago"
# Dung lượng ổ đĩa và tiến trình tốn CPU
df -h
ps aux --sort=-%cpu | head
Ngoài kiểm tra bằng tay, nên đặt cảnh báo khi CPU, RAM, ổ đĩa tăng bất thường; một VPS bị chiếm quyền thường lộ ra qua tài nguyên trước khi bạn thấy dấu hiệu khác.
Cách bảo mật VPS Windows Server
Với VPS Windows, cửa vào thường bị nhắm tới là Remote Desktop (RDP, cổng 3389) khi mở cho mọi IP và dùng mật khẩu yếu. Các việc cơ bản: bật Network Level Authentication, giới hạn IP được vào RDP, bật khóa tài khoản khi nhập sai nhiều lần, dùng mật khẩu mạnh và cài Windows Update đều đặn.
- Bật NLA cho RDP: Microsoft khuyến nghị bật Network Level Authentication để người dùng phải xác thực trước khi phiên Remote Desktop được tạo (Microsoft Learn). Cách mở RDP: mở Remote Desktop trên Windows Server.
- Giới hạn IP vào RDP: trong Windows Defender Firewall, mở quy tắc Remote Desktop, tab Scope, chỉ cho phép IP của bạn hoặc của VPN công ty. Đổi cổng 3389 chỉ giảm quét tự động, không thay được bước này.
- Khóa tài khoản khi nhập sai: đặt Account lockout threshold trong Local Security Policy để chặn dò mật khẩu (Microsoft Learn).
- Tài khoản: mật khẩu dài, không dùng lại ở nơi khác; tạo tài khoản quản trị riêng cho từng người thay vì dùng chung Administrator; xoá tài khoản không còn dùng.
- Windows Update: bật cập nhật tự động hoặc đặt lịch cập nhật hằng tháng, khởi động lại vào giờ ít truy cập.
- Đóng dịch vụ thừa: gỡ role và feature không dùng (FTP, IIS, SMB mở ra Internet…).
VPS chạy n8n, OpenClaw, Hermes Agent cần bảo mật thêm gì?
VPS chạy AI Agent hoặc công cụ tự động hóa giữ nhiều khoá API và thông tin đăng nhập dịch vụ khác, nên bị chiếm quyền thì thiệt hại lan ra ngoài VPS. Ngoài checklist ở trên, hãy đặt giao diện quản trị sau mạng riêng, cô lập agent và chỉ cấp quyền tối thiểu cho từng khoá API.
- Không mở giao diện quản trị ra Internet; truy cập qua mạng riêng như hướng dẫn bảo mật VPS chạy AI Agent bằng Tailscale.
- Chạy agent trong môi trường cô lập: xem cách ly sandbox cho AI Agent trên VPS.
- Với n8n: đọc bảo mật trong n8n; nhớ lưu ý Docker không đi qua UFW ở phần tường lửa.
Dấu hiệu VPS bị xâm nhập và việc cần làm
Dấu hiệu thường gặp là CPU tăng cao do tiến trình lạ (thường là đào tiền ảo) và đăng nhập thành công từ IP không quen. Ngoài ra còn có cổng hoặc dịch vụ lạ đang mở, cron, systemd timer hoặc SSH key mới không rõ nguồn gốc, và lưu lượng gửi ra tăng vọt. Một dấu hiệu riêng lẻ chưa chắc là bị tấn công, nhưng nhiều dấu hiệu cùng lúc thì cần xử lý ngay.

# Linux: kiểm tra nhanh
ps aux --sort=-%cpu | head # tiến trình tốn CPU
last -a | head # đăng nhập gần đây
sudo ss -tulpn # cổng đang mở
sudo crontab -l; crontab -l # lịch chạy của root và user
ls -la /etc/cron.*
sudo sh -c 'cat /root/.ssh/authorized_keys /home/*/.ssh/authorized_keys' # key của root và mọi user
systemctl list-timers --all; ls -la /etc/systemd/system/ # timer, service lạ
Trên Windows, mở Event Viewer, mục Windows Logs › Security và lọc sự kiện 4625 (đăng nhập thất bại, Microsoft Learn). Hàng loạt sự kiện từ nhiều IP lạ là dấu hiệu bị dò mật khẩu qua RDP.
Khi nghi bị xâm nhập, làm theo thứ tự sau. Cô lập VPS (chặn truy cập công khai, dùng console của nhà cung cấp) và lưu bằng chứng (snapshot, log). Đổi toàn bộ mật khẩu và khoá API. Cài lại hệ điều hành từ bản sạch, khôi phục dữ liệu từ bản sao lưu trước thời điểm bị xâm nhập, vá lỗ hổng rồi mới mở lại. Doanh nghiệp cần quy trình đầy đủ hơn có thể tham khảo khuyến nghị ứng phó sự cố NIST SP 800-61r3. Chỉ xoá file lạ rồi dùng tiếp thường không đủ, vì kẻ tấn công có thể đã để lại đường vào khác.
Nếu VPS bị tấn công từ chối dịch vụ thay vì bị chiếm quyền, xem cách chống DDoS cho VPS.
Khi nào không nên tự quản trị bảo mật VPS?
Tự bảo mật VPS chỉ hiệu quả khi có người làm đều đặn: cập nhật, đọc log, kiểm tra sao lưu. Nếu không ai trong nhóm làm được việc đó, một VPS tự quản trị dễ thành máy chủ bị bỏ quên với phần mềm cũ.
- Website nhỏ, không cần phần mềm riêng: shared hosting giao phần bảo mật máy chủ cho nhà cung cấp.
- Chỉ cần chạy một ứng dụng như n8n: cân nhắc VPS cài sẵn ứng dụng để giảm phần cài đặt. Phần cập nhật và bảo mật còn lại vẫn cần xem rõ trong mô tả gói.
- Chưa quen dòng lệnh: đừng đổi cổng SSH hay bật tường lửa khi chưa biết cách vào lại VPS qua console của nhà cung cấp.
Các gói VPS NVMe tại Tino có Web Console (noVNC) để vào VPS qua trình duyệt khi bị chặn SSH. Gói cũng có sao lưu tự động; tần suất và số bản giữ lại xem trong mô tả gói hoặc hỏi bộ phận hỗ trợ. Tino hỗ trợ kỹ thuật 24/7 (theo trang sản phẩm ngày 19/10/2026). Nếu chưa rõ VPS có phù hợp với bạn không, xem VPS là gì và khi nào nên dùng.
Câu hỏi thường gặp về bảo mật VPS
Bật tường lửa xong bị mất kết nối SSH thì làm sao?
Vào VPS qua console trên trang quản trị của nhà cung cấp (không đi qua SSH). Chạy sudo ufw allow OpenSSH hoặc mở đúng cổng SSH bạn đang dùng, rồi kiểm tra lại bằng sudo ufw status. Nếu không có console, liên hệ bộ phận hỗ trợ của nhà cung cấp.
VPS Linux có cần cài phần mềm diệt virus không?
Không bắt buộc với VPS chỉ chạy website, nhưng nên có khi VPS nhận file tải lên từ người dùng hoặc chia sẻ file cho máy Windows. Các lớp quan trọng hơn vẫn là cập nhật, tắt đăng nhập mật khẩu, đóng cổng thừa và sao lưu.
Có nên chặn ping (ICMP) để bảo mật VPS không?
Lợi ích nhỏ: chặn ping không ngăn được quét cổng hay dò mật khẩu, trong khi lại làm khó việc kiểm tra kết nối. Ưu tiên đóng cổng thừa và giới hạn IP vào SSH/RDP trước.
Nhà cung cấp VPS có chịu trách nhiệm bảo mật cho tôi không?
Thường chỉ phần hạ tầng: phần cứng, mạng, nền tảng ảo hoá và các biện pháp chống tấn công ở tầng mạng (nếu có trong gói). Hệ điều hành, mật khẩu, phần mềm và dữ liệu trên VPS không quản lý là trách nhiệm của bạn. Hãy đọc mô tả gói và điều khoản dịch vụ để biết chính xác phạm vi.
Bảo mật VPS mất bao lâu?
Các việc ngày đầu (cập nhật, SSH key, tắt mật khẩu, tường lửa, Fail2ban) thường làm xong trong một buổi nếu đã quen dòng lệnh. Phần tốn thời gian hơn là duy trì: cập nhật định kỳ, đọc log, kiểm tra bản sao lưu.
Nguồn tham khảo
- Ubuntu Server: OpenSSH server (truy cập 19/10/2026)
- Ubuntu Server: Automatic updates (truy cập 19/10/2026)
- Ubuntu Server: Firewalls (ufw) (truy cập 19/10/2026)
- OpenBSD manual: sshd_config(5) (truy cập 19/10/2026)
- Launchpad: Ubuntu bug #2069041 (đổi cổng SSH với ssh.socket) (truy cập 19/10/2026)
- Docker Docs: Packet filtering and firewalls (truy cập 19/10/2026)
- Microsoft Learn: Enable Remote Desktop on your PC (truy cập 19/10/2026)
- Microsoft Learn: Account lockout threshold (truy cập 19/10/2026)
- Microsoft Learn: Event 4625 (truy cập 19/10/2026)
- NIST SP 800-123: Guide to General Server Security (truy cập 19/10/2026)
- NIST SP 800-61r3: Incident Response Recommendations (truy cập 19/10/2026)
- CIS Critical Security Controls (truy cập 19/10/2026)
