Hướng dẫn bảo mật VPS Ubuntu 24.04 từng bước (có lệnh kiểm tra)

Bảo mật VPS Ubuntu là đóng các đường vào không cần thiết và ghi lại mọi thay đổi quan trọng trên máy chủ. Trên Ubuntu 24.04 LTS, thứ tự an toàn là: cập nhật hệ thống, tạo user sudo, đăng nhập bằng SSH key ed25519, tắt mật khẩu và root qua SSH. Sau đó bật UFW (mở SSH trước), cài Fail2ban, kiểm tra cập nhật tự động, giữ AppArmor, bật auditd và rà cổng đang mở.

Checklist chung cho máy chủ ảo VPS Linux và Windows Server nằm ở bài bảo mật VPS; bài này là lệnh chi tiết cho Ubuntu. Chỉ sang bước sau khi lệnh kiểm tra của bước trước cho kết quả đúng.

• Phiên bản: Ubuntu 24.04 LTS, hỗ trợ bảo mật tiêu chuẩn đến 05/2029. Ubuntu 26.04 LTS ra mắt 04/2026; Ubuntu 20.04 đã hết hỗ trợ tiêu chuẩn từ 05/2025 (chu kỳ phát hành Ubuntu, truy cập 21/10/2026), nên nâng cấp hoặc cài lại trước.
• Giả định: VPS mới cài, đăng nhập lần đầu bằng root và mật khẩu nhà cung cấp gửi, chạy web qua Nginx hoặc Apache.
• Đường lui: biết mở console ở trang quản trị của nhà cung cấp (ví dụ Web Console noVNC); console vẫn vào được khi SSH bị chặn.

Bảo mật VPS Ubuntu 24.04 gồm những bước nào?

Bảo mật VPS Ubuntu 24.04 gồm 9 bước, làm theo nguyên tắc: tạo đường đăng nhập mới và thử thành công, rồi mới đóng đường cũ. SSH key phải chạy được trước khi tắt mật khẩu, quy tắc mở cổng SSH phải có trước khi bật UFW, và giữ phiên SSH đang mở cho đến khi phiên mới đăng nhập được.

Bước 1: Cập nhật Ubuntu và kiểm tra phiên bản

Cập nhật toàn bộ gói là việc đầu tiên trên VPS Ubuntu mới, vì image cài sẵn thường cũ hơn bản vá hiện tại. Kiểm tra thêm phiên bản Ubuntu, đồng hồ hệ thống (log sai giờ khó điều tra) và máy có cần khởi động lại không.

# Phiên bản Ubuntu
cat /etc/os-release | grep -E '^(NAME|VERSION)='

# Cập nhật toàn bộ gói
sudo apt update && sudo apt upgrade -y

# File này tồn tại nghĩa là cần khởi động lại để nạp kernel hoặc thư viện mới
# VPS sẽ khởi động lại: đợi 1–2 phút rồi SSH lại bằng root
ls /var/run/reboot-required && sudo reboot

# Đồng hồ: dòng "System clock synchronized" phải là yes
timedatectl status
sudo timedatectl set-timezone Asia/Ho_Chi_Minh

Bước 2: Tạo user sudo thay cho root

User sudo là tài khoản thường được chạy lệnh quản trị khi gõ sudo, nên mỗi lệnh quản trị đều có chủ đích và được ghi log. Root vẫn tồn tại, chỉ không đăng nhập trực tiếp qua SSH nữa (bước 4).

# Đang đăng nhập root: tạo user (thay tenban bằng tên của bạn) và cấp quyền sudo
adduser tenban
usermod -aG sudo tenban

# Kiểm tra: dòng kết quả phải có "sudo"
groups tenban

Bước 3: Đăng nhập bằng SSH key ed25519

SSH key là cặp khoá dùng thay mật khẩu khi đăng nhập qua giao thức SSH: khoá riêng nằm trên máy của bạn, khoá công khai đặt trên VPS. Tài liệu OpenSSH server của Ubuntu khuyến nghị ed25519. Tạo key trên máy cá nhân, không tạo trên VPS, và đặt passphrase cho khoá riêng. Xem thêm SSH key là gì.

# Trên máy tính của bạn (macOS, Linux, Windows 10/11 đều có sẵn OpenSSH)
ssh-keygen -t ed25519 -C "tenban@laptop"

# Chép khoá công khai lên VPS: macOS, Linux
ssh-copy-id tenban@IP_VPS

# Windows PowerShell không có ssh-copy-id, dùng lệnh này 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ổ terminal MỚI, thử đăng nhập bằng key
ssh tenban@IP_VPS
sudo whoami      # kết quả phải là root

RSA 4096 (ssh-keygen -t rsa -b 4096) vẫn dùng được, nhưng ed25519 được khuyến nghị. VPS tại Tino có thể thêm SSH key qua Tino Panel. Cách mở phiên SSH từ Windows, macOS và xử lý lỗi kết nối: xem cách kết nối VPS.

Bước 4: Tắt đăng nhập bằng mật khẩu và root trong sshd_config.d

Ubuntu 24.04 nạp các file trong /etc/ssh/sshd_config.d/ trước nội dung chính của sshd_config (cùng tài liệu OpenSSH của Ubuntu ở bước 3). OpenSSH dùng giá trị đầu tiên đọc được cho mỗi tuỳ chọn (man sshd_config). Một số image VPS có sẵn file 50-cloud-init.conf bật lại PasswordAuthentication yes, nên hãy đặt file của bạn với số nhỏ hơn.

# Xem có file nào đang bật đăng nhập mật khẩu không
sudo grep -ri passwordauthentication /etc/ssh/sshd_config /etc/ssh/sshd_config.d/

sudo tee /etc/ssh/sshd_config.d/01-bao-mat.conf > /dev/null <<'EOF'
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
AllowUsers tenban
MaxAuthTries 3
X11Forwarding no
EOF

# Kiểm tra cú pháp, rồi xem giá trị thực tế đang có hiệu lực
sudo sshd -t
sudo sshd -T | grep -Ei '^(passwordauthentication|kbdinteractiveauthentication|permitrootlogin|allowusers|maxauthtries)'

sudo systemctl restart ssh.service

AllowUsers chỉ cho các user được liệt kê đăng nhập qua SSH; thêm người quản trị thì thêm tên vào dòng này. Giữ phiên SSH hiện tại, mở phiên mới để thử. ssh root@IP_VPS phải bị từ chối.

Bước 5: Bật UFW đúng thứ tự

UFW là công cụ tường lửa (firewall) mặc định của Ubuntu. Thứ tự đúng là đặt mặc định chặn kết nối vào, mở SSH, mở cổng web, rồi mới bật (Ubuntu Server docs). Quy tắc limit vẫn cho phép SSH nhưng từ chối IP mở từ 6 kết nối trở lên trong 30 giây (man ufw).

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw limit OpenSSH          # mở SSH (cổng 22) kèm giới hạn tần suất, làm TRƯỚC
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

• IP nhà hoặc văn phòng cố định: chỉ cho phép IP đó vào SSH bằng sudo ufw allow from IP_CUA_BAN to any port 22 proto tcp. Thử đăng nhập được rồi mới xoá quy tắc OpenSSH cũ (sudo ufw status numbered, rồi sudo ufw delete SO).
• IPv6: UFW áp quy tắc cho cả IPv6 khi IPV6=yes trong /etc/default/ufw. Kiểm tra dòng này nếu VPS có IPv6.
• Docker: cổng do Docker publish đi qua quy tắc riêng, không bị UFW chặn (tài liệu Docker). 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.

Bước 6: Cài Fail2ban và cấu hình jail cho SSH

Fail2ban đọc log đăng nhập và tạm chặn IP thất bại nhiều lần bằng tường lửa. Khi đã tắt mật khẩu, Fail2ban chủ yếu giảm log rác và tải do bot dò, và dùng lại được cho Nginx, WordPress. Không sửa jail.conf; đặt cấu hình riêng trong jail.local hoặc jail.d/. CrowdSec là công cụ cùng loại dùng danh sách chặn chia sẻ; bài này dùng Fail2ban vì có sẵn trong kho Ubuntu.

sudo apt install fail2ban -y

sudo tee /etc/fail2ban/jail.local > /dev/null <<'EOF'
[DEFAULT]
# Thay IP_CUA_BAN bằng IP thật; không có IP cố định thì xoá chữ IP_CUA_BAN
ignoreip = 127.0.0.1/8 ::1 IP_CUA_BAN
bantime  = 1h
findtime = 10m
maxretry = 5

[sshd]
enabled = true
# port = 2222   (bỏ dấu # nếu đã đổi cổng SSH)

# Chặn lâu hơn IP bị chặn lặp lại nhiều lần (đọc file log của chính Fail2ban)
[recidive]
enabled  = true
backend  = auto
logpath  = /var/log/fail2ban.log
bantime  = 1w
findtime = 1d
EOF

sudo fail2ban-client -t        # kiểm tra cú pháp trước khi khởi động lại
sudo systemctl enable --now fail2ban
sudo systemctl restart fail2ban
sudo fail2ban-client status
sudo fail2ban-client status sshd
# Dòng "File list" phải có /var/log/fail2ban.log
sudo fail2ban-client status recidive

Ubuntu 24.04 đặt sẵn backend = systemd trong /etc/fail2ban/jail.d/defaults-debian.conf, nên jail sshd đọc journal, không cần /var/log/auth.log. Jail đọc file log riêng (recidive, Nginx) phải ghi backend = auto kèm logpath, nếu không jail báo đang chạy nhưng không bao giờ chặn. Bỏ chặn IP bị khoá nhầm: sudo fail2ban-client set sshd unbanip IP.

Bước 7: Kiểm tra cập nhật bảo mật tự động (unattended-upgrades)

Gói unattended-upgrades được cài sẵn trên Ubuntu và mặc định chỉ tự cài bản vá bảo mật (Ubuntu Server docs). Gói này không tự khởi động lại máy (Automatic-Reboot "false"), nên bản vá kernel chỉ có hiệu lực sau khi bạn reboot; bản sửa lỗi không phải bảo mật vẫn cần apt upgrade định kỳ.

# Hai dòng trong file này phải có giá trị "1"
cat /etc/apt/apt.conf.d/20auto-upgrades

# Nếu chưa bật
sudo dpkg-reconfigure -plow unattended-upgrades

# Chạy thử, không thay đổi gì
sudo unattended-upgrade -v --dry-run

# Log mỗi lần chạy
ls /var/log/unattended-upgrades/

Muốn tự khởi động lại vào giờ ít truy cập (chỉ khi website chịu được vài phút gián đoạn), sửa trong /etc/apt/apt.conf.d/50unattended-upgrades: Unattended-Upgrade::Automatic-Reboot "true"; và Unattended-Upgrade::Automatic-Reboot-Time "03:00";.

Bản vá kernel nghiêm trọng không cần chờ reboot nếu dùng Canonical Livepatch: dịch vụ vá kernel khi máy đang chạy, miễn phí cho tối đa 5 máy dùng cá nhân qua Ubuntu Pro (sudo pro attach TOKEN, rồi sudo pro enable livepatch; Ubuntu Livepatch, truy cập 22/10/2026). Livepatch không thay được lần reboot định kỳ.

Bước 8: Giữ AppArmor bật và theo dõi thay đổi bằng auditd

AppArmor giới hạn file và quyền mà từng chương trình được dùng, nên dịch vụ bị khai thác khó lan sang phần còn lại của hệ thống. Ubuntu nạp AppArmor mặc định (Ubuntu Server docs). Gặp lỗi quyền thì không tắt AppArmor: chuyển riêng profile đó sang complain, đọc log, sửa profile rồi trả về enforce.

# Trạng thái: số profile đang nạp, bao nhiêu ở chế độ enforce
sudo aa-status

# Thêm bộ profile mẫu và công cụ quản lý (tuỳ chọn)
sudo apt install apparmor-profiles apparmor-utils -y

# Tạm chuyển một profile sang complain để điều tra lỗi, xong thì trả về enforce
sudo aa-complain /usr/sbin/TEN_CHUONG_TRINH
sudo aa-enforce /usr/sbin/TEN_CHUONG_TRINH

auditd ghi lại ai sửa file quan trọng và lúc nào. Quy tắc -w theo dõi một file, -p wa ghi khi có thay đổi nội dung hoặc thuộc tính, -k gắn nhãn để tìm (man auditctl).

sudo apt install auditd -y

sudo tee /etc/audit/rules.d/90-bao-mat.rules > /dev/null <<'EOF'
-w /etc/passwd -p wa -k taikhoan
-w /etc/shadow -p wa -k taikhoan
-w /etc/sudoers -p wa -k sudo
-w /etc/sudoers.d/ -p wa -k sudo
-w /etc/ssh/sshd_config -p wa -k ssh
-w /etc/ssh/sshd_config.d/ -p wa -k ssh
EOF

sudo augenrules --load
sudo auditctl -l

# Tìm các thay đổi theo nhãn, hoặc xem báo cáo tổng hợp
sudo ausearch -k ssh -i | tail -20
sudo aureport --summary

Kiểm tra hằng ngày, đọc log bằng journal là đủ:

# Đăng nhập SSH thành công trong 24 giờ qua
sudo journalctl -u ssh --since "24 hours ago" | grep "Accepted"

# Lệnh sudo đã chạy hôm nay
sudo journalctl _COMM=sudo --since today

Bước 9: Kiểm tra cổng đang mở và dịch vụ đang lắng nghe

Mỗi dịch vụ lắng nghe trên địa chỉ công khai là một đường vào VPS. Kiểm tra trong VPS để biết dịch vụ nào đang mở, rồi từ máy ngoài để biết tường lửa thực sự chặn gì. Database, Redis và trang quản trị chỉ nên nghe trên 127.0.0.1.

# Trong VPS: cột Local Address 0.0.0.0 hoặc [::] nghĩa là mở cho mọi mạng
sudo ss -tulpn

# Từ máy tính của bạn (chỉ quét VPS của chính bạn): xem cổng nào thực sự truy cập được
nmap -Pn IP_VPS

# Ví dụ MySQL/MariaDB: kiểm tra địa chỉ lắng nghe
sudo ss -tlnp | grep 3306        # nên là 127.0.0.1:3306

# Cần vào database từ xa thì dùng đường hầm SSH thay vì mở cổng
ssh -L 3307:127.0.0.1:3306 tenban@IP_VPS

Tắt dịch vụ không dùng bằng sudo systemctl disable --now TEN_DICH_VU. Cài chứng chỉ cho cổng 443: xem cài SSL trên VPS. Bảo mật không thay được sao lưu ra ngoài VPS: xem backup VPS.

Có nên đổi cổng SSH trên Ubuntu 24.04 không?

Đổi cổng SSH khỏi 22 giảm lượng bot dò tự động và làm log gọn hơn, nhưng không thay được SSH key, UFW hay Fail2ban; giới hạn IP có tác dụng lớn hơn. Ubuntu 24.04 chạy SSH qua ssh.socket, nên phải nạp lại systemd sau khi đổi cổng (Ubuntu bug #2069041).

# 1. Mở cổng mới trên UFW TRƯỚC
sudo ufw limit 2222/tcp
# 1b. DỪNG LẠI: nếu VPS có tường lửa ở trang quản trị của nhà cung cấp, mở cổng 2222/tcp ở đó NGAY BÂY GIỜ

# 2. Khai báo cổng mới
echo 'Port 2222' | sudo tee /etc/ssh/sshd_config.d/02-port.conf
sudo sshd -t

# 3. Chỉ restart khi cả UFW và tường lửa nhà cung cấp đã mở cổng mới
sudo systemctl daemon-reload
sudo systemctl restart ssh.socket

# 4. Thử ở cửa sổ mới: ssh -p 2222 tenban@IP_VPS
# 5. Thành công rồi mới đóng cổng cũ, và sửa port trong jail [sshd] của Fail2ban
sudo ufw delete limit OpenSSH

Kiểm tra lại toàn bộ cấu hình bảo mật VPS Ubuntu

Sau 9 bước, chạy lại lệnh kiểm tra của từng bước và so với kết quả mong đợi dưới đây. Dùng bảng này để rà hằng tháng hoặc sau khi người khác can thiệp vào VPS.

Muốn rà tự động thêm một lượt, công cụ mã nguồn mở Lynis quét cấu hình và liệt kê cảnh báo kèm gợi ý: sudo apt install lynis rồi sudo lynis audit system. Bản trong kho Ubuntu có thể cũ hơn bản trên trang dự án; coi kết quả là danh sách để xem xét, không phải điểm số phải đạt.

Bị khoá khỏi VPS sau khi bảo mật thì làm sao?

Khi không SSH được sau khi đổi cấu hình, hãy vào VPS qua console trên trang quản trị của nhà cung cấp, vì console không đi qua SSH hay UFW. Từ console, kiểm tra lần lượt tường lửa, cấu hình SSH và Fail2ban.

Trên VPS NVMe tại Tino, Web Console (noVNC) vào được VPS qua trình duyệt ngay cả khi bị chặn truy cập, theo trang sản phẩm (kiểm tra 21/10/2026). Mất khoá riêng thì dùng console để thêm key mới.

Khi nào không cần làm hết các bước trên?

Không phải VPS nào cũng cần đủ 9 bước ngay ngày đầu. Bảy bước đầu nên làm với mọi VPS có IP công khai, vì bot quét không phân biệt máy lớn hay nhỏ; auditd và tinh chỉnh AppArmor có thể để sau.

• VPS thử nghiệm, xoá sau vài ngày: làm tới bước 5, không lưu dữ liệu thật.
• Dùng control panel hoặc script VPS: nhiều công cụ tự cấu hình tường lửa và Fail2ban; kiểm tra bằng bảng ở trên thay vì cài đè.
• Chưa quen dòng lệnh, không có người trực VPS: cân nhắc shared hosting thay vì VPS. VPS bị tấn công làm nghẽn mạng: xem cách chống DDoS cho VPS.

Câu hỏi thường gặp về bảo mật VPS Ubuntu