15 checklist bảo mật VPS Linux cần làm ngay sau khi thuê

VPS mới thuê giống như một ngôi nhà vừa bàn giao: cửa chưa khóa, chìa khóa mặc định ai cũng đoán được, và hàng nghìn "kẻ trộm" tự động trên internet đang quét từng địa chỉ IP để tìm cửa mở. Thống kê từ các nhà cung cấp cho thấy một VPS mới với SSH mở port 22 và mật khẩu yếu có thể bị bot tấn công brute-force chỉ sau vài phút online. Tin tốt là bạn chỉ cần khoảng 30–60 phút để khóa chặt mọi cánh cửa với 15 checklist bảo mật VPS Linux dưới đây — làm ngay sau khi thuê, theo đúng thứ tự.

Bảo mật vps linux: 1. Cập nhật hệ điều hành và gói phần mềm (checklist #1)

VPS mới thường được dựng từ image hệ điều hành đã có từ vài tuần hoặc vài tháng trước — nghĩa là các bản vá bảo mật mới nhất chưa được cài. Lệnh đầu tiên sau khi đăng nhập luôn là cập nhật toàn bộ: trên Ubuntu/Debian dùng apt update && apt upgrade, trên AlmaLinux/RHEL dùng dnf update. Sau khi update xong, khởi động lại VPS nếu có bản vá kernel để bản vá thực sự có hiệu lực. Đây là bước rẻ nhất nhưng loại bỏ được cả một lớp lỗ hổng đã công khai mà bot tự động luôn khai thác đầu tiên.

Bảo mật vps linux: 2. Tạo user quản trị riêng, vô hiệu hóa đăng nhập root (checklist #2–3)

Tài khoản root là mục tiêu số một của mọi cuộc tấn công vì kẻ tấn công biết chắc username này tồn tại trên mọi máy Linux. Checklist #2: tạo một user thường có quyền sudo (adduser tenuser rồi usermod -aG sudo tenuser trên Ubuntu), dùng user này cho mọi thao tác hàng ngày. Checklist #3: tắt đăng nhập SSH trực tiếp bằng root bằng cách đặt PermitRootLogin no trong file /etc/ssh/sshd_config rồi restart sshd. Kẻ tấn công giờ phải đoán cả username lẫn mật khẩu — độ khó tăng gấp bội.

Bảo mật vps linux: 3. Dùng SSH key thay cho mật khẩu (checklist #4–5)

Mật khẩu dù mạnh đến đâu vẫn có thể bị brute-force hoặc rò rỉ; SSH key với độ dài 256-bit (Ed25519) gần như không thể đoán mò. Checklist #4: tạo cặp key trên máy cá nhân bằng ssh-keygen -t ed25519, rồi copy public key lên VPS vào file ~/.ssh/authorized_keys của user mới. Đăng nhập thử bằng key trên một terminal mới để chắc chắn hoạt động. Checklist #5: chỉ khi đã đăng nhập thành công bằng key, mới tắt xác thực mật khẩu (PasswordAuthentication no trong sshd_config). Thứ tự này cực kỳ quan trọng: tắt password trước khi key hoạt động đồng nghĩa với tự khóa mình khỏi server.

4. Đổi port SSH và giới hạn truy cập (checklist #6–7)

Port 22 là port đầu tiên mọi bot quét trên internet. Checklist #6: đổi SSH sang một port ít phổ biến (ví dụ 2222 hoặc một số ngẫu nhiên trên 1024) bằng cách sửa dòng Port trong sshd_config, đồng thời mở port mới trên firewall trước khi restart sshd. Đổi port không phải "bảo mật tuyệt đối" nhưng loại bỏ được 99% các đợt quét tự động. Checklist #7 (nâng cao): nếu bạn quản trị từ IP tĩnh (văn phòng, nhà riêng), hãy giới hạn SSH chỉ chấp nhận từ IP đó bằng firewall rule — biến cánh cửa SSH thành "cửa chỉ mở cho người quen".

5. Dựng tường lửa: chỉ mở port thật sự cần (checklist #8–9)

Checklist #8: bật tường lửa với chính sách mặc định chặn mọi kết nối vào (default deny incoming), chỉ cho phép những gì bạn chủ động mở. Trên Ubuntu dùng UFW (ufw default deny incoming, ufw allow từng port rồi ufw enable); trên AlmaLinux/RHEL dùng firewalld. Checklist #9: rà soát và chỉ mở đúng port dịch vụ đang chạy: 80/443 cho web, port SSH mới, và tuyệt đối không mở port database (MySQL 3306, PostgreSQL 5432, Redis 6379) ra internet — các dịch vụ này chỉ nên lắng nghe trên localhost hoặc mạng nội bộ. Kiểm tra lại bằng ss -tlnp để xem thực tế có port nào đang mở mà bạn không biết.

6. Cài Fail2Ban chặn tấn công brute-force (checklist #10)

Dù đã tắt password auth, bot vẫn sẽ liên tục gõ cửa SSH làm phình log và tốn tài nguyên. Checklist #10: cài Fail2Ban — công cụ tự động theo dõi log và "ban" IP có quá nhiều lần đăng nhập thất bại trong một khoảng thời gian. Cấu hình cơ bản chỉ cần bật jail cho sshd trong file jail.local (ví dụ: 5 lần sai trong 10 phút thì ban 1 giờ). Kiểm tra hoạt động bằng fail2ban-client status sshd để xem danh sách IP đang bị chặn. Đây là lớp phòng thủ tự động chạy 24/7 mà bạn không cần động tay sau khi cấu hình xong.

7. Tắt dịch vụ không dùng và bật tự động cập nhật (checklist #11–12)

Mỗi dịch vụ đang chạy là một "cánh cửa" tiềm năng. Checklist #11: liệt kê các service đang chạy (systemctl list-unit-files --state=enabled) và tắt những gì không cần: nếu không dùng FTP thì tắt vsftpd, không dùng mail server thì tắt postfix, không dùng thì gỡ bỏ. Nguyên tắc: server chỉ chạy đúng những gì nó phải chạy. Checklist #12: bật cập nhật bảo mật tự động bằng unattended-upgrades (Ubuntu/Debian) để các bản vá bảo mật được cài ngay khi phát hành, không phụ thuộc vào việc bạn có nhớ update hay không. Với kernel, cân nhắc dùng live-patching nếu nhà cung cấp hỗ trợ để vá mà không cần reboot.

8. Cấu hình backup tự động ngay từ ngày đầu (checklist #13)

Bảo mật không chỉ là ngăn tấn công — mà còn là đảm bảo khôi phục được khi sự cố xảy ra. Checklist #13: thiết lập backup tự động ngay trong ngày đầu nhận VPS, đừng đợi "khi nào rảnh". Tối thiểu cần backup: toàn bộ dữ liệu website/database và file cấu hình quan trọng (/etc, nginx/apache config). Lịch gợi ý: backup hàng ngày, giữ 7 bản gần nhất; backup tuần giữ 4 bản. Quan trọng nhất: kiểm tra khả năng restore — một bản backup chưa từng test restore thì chưa thể gọi là backup. Nhiều nhà cung cấp cloud như SunCloud có sẵn tính năng backup tự động hàng tuần cho Cloud Server và VPS, bạn chỉ cần bật và kiểm tra định kỳ.

9. Giám sát log và audit định kỳ (checklist #14–15)

Hai checklist cuối cùng biến bảo mật từ "làm một lần" thành "quy trình liên tục". Checklist #14: tập thói quen xem log đăng nhập — trên Ubuntu/Debian là /var/log/auth.log, trên AlmaLinux/RHEL là /var/log/secure. Bất kỳ dòng "Failed password" dày đặc từ IP lạ nào cũng là tín hiệu để kiểm tra lại Fail2Ban và firewall. Checklist #15: chạy audit định kỳ bằng công cụ như Lynis (lynis audit system) mỗi tháng một lần — công cụ này quét hàng trăm điểm cấu hình và chấm điểm bảo mật hệ thống, chỉ ra chính xác chỗ nào còn yếu để bạn khắc phục.

Thứ tự thực hiện: đừng tự khóa mình khỏi server

Thứ tự 15 checklist trên không ngẫu nhiên — nó được sắp xếp để bạn không bao giờ rơi vào tình huống "khóa cửa rồi vứt chìa". Quy tắc vàng gồm ba điều: (1) luôn mở terminal dự phòng đang đăng nhập trước khi sửa SSH/firewall, để còn đường quay lại nếu cấu hình sai; (2) mọi thay đổi SSH đều phải test trên session mới trước khi đóng session cũ; (3) tắt password auth chỉ sau khi SSH key đã đăng nhập thành công. Nếu chẳng may bị khóa, hầu hết nhà cung cấp VPS/Cloud đều có web console (truy cập trực tiếp qua trình duyệt, không qua SSH) để bạn đăng nhập và sửa lại cấu hình.

Kết luận

15 checklist bảo mật VPS Linux có thể tóm gọn trong 5 nguyên tắc: cập nhật hệ thống, bỏ root + dùng SSH key, đổi port SSH, dựng tường lửa chỉ mở port cần thiết, và Fail2Ban + backup + giám sát để bảo vệ liên tục. Làm đủ 15 bước này trong giờ đầu tiên nhận VPS, bạn đã loại bỏ hơn 95% các cuộc tấn công tự động phổ biến trên internet — phần việc còn lại là duy trì thói quen update và audit định kỳ.

Nếu bạn không muốn tự mình làm từng bước, hãy chọn nhà cung cấp có đội ngũ hỗ trợ kỹ thuật 24/7/365 đồng hành từ khâu khởi tạo. SunCloud cung cấp VPS SSD hiệu năng cao đặt tại datacenter Tier III (VNPT Nam Thăng Long), backup tự động hàng tuần, khởi tạo dịch vụ chỉ trong 5 phút và hỗ trợ kỹ thuật 24/7 — liên hệ hotline 083 979 3434 hoặc truy cập suncloud.vn để được tư vấn. (Giá dịch vụ tham khảo tại thời điểm viết, xem giá mới nhất tại suncloud.vn.)

Câu hỏi thường gặp

Đổi port SSH có thực sự giúp bảo mật không?

Có, nhưng chỉ ở mức giảm "tiếng ồn". Đổi port loại bỏ được khoảng 99% các đợt quét tự động nhắm vào port 22 mặc định, giúp log sạch hơn và giảm tải cho Fail2Ban. Tuy nhiên kẻ tấn công có chủ đích vẫn có thể quét toàn bộ port, vì vậy đổi port phải đi kèm SSH key + tắt password auth mới thực sự an toàn.

Quên tắt password authentication thì sao?

Đó là lỗ hổng nghiêm trọng nhất trong checklist này. Chỉ cần password auth còn bật, bot brute-force vẫn có cơ hội đoán trúng mật khẩu — đặc biệt nếu bạn đặt mật khẩu dễ nhớ. Hãy kiểm tra lại bằng lệnh sshd -T | grep passwordauthentication và đảm bảo kết quả là no.

Fail2Ban và firewall khác nhau ở điểm nào?

Firewall là "người gác cổng" chặn/mở theo quy tắc tĩnh (port nào được mở, IP nào được phép). Fail2Ban là "vệ sĩ động": theo dõi hành vi (đăng nhập sai nhiều lần) và tự động thêm lệnh cấm tạm thời vào firewall. Hai công cụ bổ sung cho nhau, không thay thế nhau.

Có nên tắt IPv6 trên VPS không?

Không nên tắt chỉ vì "cho đỡ phức tạp". Nhiều bot hiện nay đã quét cả IPv6. Thay vào đó, hãy đảm bảo firewall rules áp dụng cho cả IPv4 và IPv6 (UFW xử lý IPv6 mặc định khi IPV6=yes trong /etc/default/ufw). Tắt IPv6 còn có thể gây lỗi cho một số dịch vụ hiện đại.

Bao lâu nên chạy audit bảo mật một lần?

Tối thiểu mỗi tháng một lần bằng công cụ như Lynis, và ngay lập tức sau mỗi thay đổi lớn (cài thêm dịch vụ mới, mở thêm port, nâng cấp hệ điều hành). Ngoài ra nên đăng ký nhận tin bản vá bảo mật của distro đang dùng để update kịp thời khi có lỗ hổng nghiêm trọng.

VPS bị tấn công rồi thì xử lý thế nào?

Ngắt mạng hoặc chặn IP tấn công qua firewall ngay, sao lưu log để phân tích, kiểm tra các file bị sửa đổi và user lạ mới xuất hiện. Nếu hệ thống đã bị chiếm quyền root, cách an toàn nhất là dựng lại VPS từ đầu từ image sạch và restore dữ liệu từ bản backup trước thời điểm bị tấn công — đừng cố "dọn dẹp" một hệ thống đã bị rootkit.

Nguồn tham khảo - Checklist bảo mật VPS Linux - 15 bước thiết yếu | AZDIGI Blog - Hướng dẫn bảo mật VPS Linux - SSH, UFW & Fail2ban - UFW trên Linux: Bảo vệ VPS như dân pro - 10 bước bảo mật SSH cho server Linux