10 phút đầu tiên cần làm trên VPS mới

10 phút đầu tiên quyết định mức độ an toàn của server

Một VPS mới hoàn toàn không an toàn. Ngay khi có public IP, server đã bị scanner thử đăng nhập. Image mặc định thường để lộ nhiều điểm yếu: root thường có thể truy cập, thường cho phép đăng nhập bằng password, không có firewall và không được patch theo lịch. Tin tốt là bạn có thể xử lý toàn bộ các điểm này trong khoảng 10 phút bằng một số lệnh. Đây là runbook tôi dùng trên mọi server mới trước khi triển khai bất kỳ thứ gì.

Hãy thực hiện theo đúng thứ tự vì các bước phụ thuộc lẫn nhau. Mỗi bước có guide riêng và được liên kết trong quá trình thực hiện; trang này là lộ trình nhanh để kết nối tất cả các bước đó.

Phút 1: Cập nhật mọi thứ

Đăng nhập với tài khoản root bằng thông tin xác thực do nhà cung cấp cấp, rồi cập nhật toàn bộ hệ thống trước khi làm bất kỳ việc gì khác:

apt update && apt upgrade -y

Một máy chủ chưa được vá là mục tiêu dễ bị tấn công nhất, nên đây là việc đầu tiên cần làm. Sau khi hoàn tất, hãy thiết lập automatic security updates để hệ thống luôn được cập nhật bản vá mà bạn không phải tự nhớ.

Phút 2: Tạo user thông thường có sudo

Không tiếp tục làm việc bằng root. Tạo một user cho riêng bạn và cấp quyền sudo:

adduser matt
usermod -aG sudo matt

Từ đây, hãy đăng nhập bằng user này và dùng sudo cho các tác vụ quản trị. Luôn chạy bằng root có nghĩa là mọi lỗi thao tác và mọi vụ server bị breach đều xảy ra với toàn quyền. Đây chính là điều chạy bằng user không có đặc quyền giúp ngăn chặn.

Phút 4: Thiết lập SSH key

Password có thể bị đoán; key thì không. Trên laptop của bạn, nếu chưa có key, hãy tạo một key:

ssh-keygen -t ed25519

Sau đó chép phần public key lên server:

ssh-copy-id matt@YOUR_SERVER

ssh-copy-id yêu cầu bật password login cho user mới; nếu tính năng này đã bị tắt, hãy chép ~/.ssh/authorized_keys của root vào /home/matt/.ssh/authorized_keys (thuộc sở hữu của matt), hoặc tự dán public key vào file đó.

Phần giải thích về mô hình của bước này, gồm mỗi thiết bị dùng một key, các permission khiến key login bị lỗi và cách thu hồi key bị mất, nằm trong Kiến thức cơ bản về quản lý SSH key.

Logout rồi đăng nhập lại bằng key với tư cách matt, đồng thời xác nhận key hoạt động trước khi chuyển sang bước tiếp theo. Khóa SSH trước khi có thể đăng nhập bằng key là cách khiến bạn tự khóa mình khỏi server. Nếu lần đăng nhập đó trả về Permission denied (publickey), hãy xử lý ngay thay vì quay lại dùng password, vì thông báo này có thể chỉ năm lỗi khác nhau, còn output của ssh -v sẽ cho biết bạn thực sự gặp lỗi nào.

Phút 6: Tắt đăng nhập root và mật khẩu

Bây giờ key đã hoạt động, hãy đóng 2 cửa mà các scanner dựa vào. Dùng một file drop-in để các bản nâng cấp package không ghi đè lên cấu hình này. Đặt tên file là 00- để file này được sắp xếp trước 50-cloud-init.conf, vốn được Ubuntu cloud image cung cấp cùng với PasswordAuthentication yes; sshd giữ lại giá trị đầu tiên mà nó đọc được, nên file được sắp xếp sau sẽ âm thầm mất hiệu lực:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

Sau đó reload SSH:

sudo systemctl restart ssh

Tiếp theo, kiểm tra các setting mà sshd thực sự sử dụng để một drop-in bị mất hiệu lực không thể khiến bạn hiểu sai:

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'

Khi đã tắt mật khẩu và vô hiệu hóa đăng nhập root, lưu lượng brute-force liên tục nhắm vào server của bạn sẽ không thể đăng nhập thành công. Hướng dẫn đầy đủ, bao gồm tùy chọn đổi port, có tại Hardening SSH trên VPS.

Phút 8: Bật firewall

Mặc định từ chối toàn bộ kết nối inbound, sau đó chỉ cho phép những gì bạn cần. Hãy cho phép SSH trước khi bật firewall, nếu không bạn sẽ tự ngắt kết nối của mình:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

Thêm các rule allow cho mọi service bạn thực sự chạy, chẳng hạn 80/tcp và 443/tcp cho một website. Nếu một SSH session mới không thể kết nối sau bước này, hãy đọc lỗi trước khi thực hiện bất kỳ thay đổi nào, vì kết nối bị từ chối nghĩa là sshd đã phản hồi, còn timeout thường nghĩa là firewall đã chặn packet. Kiểm tra cả IPv4 và IPv6 đều được bao phủ, vì firewall chỉ lọc IPv4 sẽ để phần IPv6 hoàn toàn không được bảo vệ. Xem hướng dẫn đầy đủ tại Firewalls 101 trên VPS. Các lệnh ufw này dành cho Ubuntu hoặc Debian; trên máy Rocky hoặc AlmaLinux, mục tiêu default-deny vẫn giống nhau nhưng công cụ là firewalld, vì vậy hãy làm theo phiên bản firewalld của bước này.

Phút 10: Làm chậm các trình quét bằng Fail2ban

Cuối cùng, thêm Fail2ban để loại các địa chỉ liên tục đánh vào các cổng của bạn:

sudo apt install -y fail2ban

Trên Ubuntu 24.04, bản cài đặt mặc định đã bảo vệ SSH ngay từ lần boot đầu tiên. Khi SSH đã yêu cầu dùng key, đây là lớp bảo vệ bổ sung giúp giảm log rác và chặn những địa chỉ tái phạm, không phải cơ chế phòng thủ chính của bạn.

Checklist của bạn

Đó là runbook. Dùng generator bên dưới để đánh dấu từng control và tạo checklist riêng mà bạn có thể lưu cùng server, bao gồm command chính xác cho từng bước:

Thực hiện toàn bộ một lần cho mỗi server mới, rồi mọi việc sẽ thành thói quen. Dành 10 phút lúc này sẽ giúp bạn tránh một buổi chiều rất tồi tệ sau khi server bị breach.

Sau khi hoàn tất các phần thiết yếu, automatic security updates trên Ubuntu sẽ giữ server luôn được cập nhật mà bạn không cần đăng nhập lại. Mỗi service bạn triển khai thêm đều cần được kiểm tra riêng, và các điểm yếu cũng thay đổi: với password vault tự host, server không bao giờ lưu plaintext, nên rủi ro thực sự của Vaultwarden nằm ở admin token và file backup.

FAQ

Tôi nên làm gì đầu tiên trên một VPS mới?

Cập nhật hệ thống bằng apt update && apt upgrade -y, sau đó tạo một user thường có quyền sudo và không tiếp tục làm việc bằng root. Tiếp theo, thiết lập SSH key, tắt đăng nhập root và xác thực bằng password, bật firewall với chính sách mặc định là từ chối, rồi cài Fail2ban. Làm theo thứ tự này giúp bạn thực hiện từng bước mà không tự khóa quyền truy cập.

Làm thế nào để tránh tự khóa quyền truy cập khi hardening SSH?

Thiết lập và kiểm tra đăng nhập SSH bằng key trước khi tắt password hoặc root. Đăng xuất rồi đăng nhập lại bằng key để xác nhận hoạt động bình thường, sau đó mới tắt PasswordAuthentication và PermitRootLogin. Khi bật firewall, hãy cho phép port 22 trước khi chạy ufw enable. Nếu vẫn bị khóa quyền truy cập, web console của nhà cung cấp sẽ cho phép bạn đăng nhập lại mà không cần SSH.

Tôi có thực sự cần tất cả các bước này trên một server nhỏ không?

Có, vì các scanner không quan tâm server của bạn nhỏ đến đâu. Chúng quét mọi public IP theo cùng một cách. Toàn bộ runbook chỉ mất khoảng mười phút và loại bỏ các đường tấn công dễ bị khai thác: không đăng nhập root, không đoán password, không expose dịch vụ nào ngoài những gì bạn chủ động chọn, và các bug đã biết được tự động patch.

Bước nào quan trọng nhất?

SSH chỉ dùng key và đã tắt đăng nhập root. Phần lớn các cuộc tấn công vào VPS mới là những lần đoán password tự động nhằm vào root. Tắt cả hai khiến toàn bộ nhóm tấn công này không thể thực hiện được. Firewall và Fail2ban tiếp tục giới hạn những gì được expose và làm chậm các cuộc tấn công còn lại.

Làm thế nào để xác nhận server thực sự đã được khóa bảo mật?

Trước khi tin tưởng cấu hình, hãy kiểm tra thủ công 3 việc. Chạy sudo ss -tlnp và xác nhận chỉ những port bạn định mở đang listening trên public address, không có service 0.0.0.0 hoặc [::] nào mà bạn đã quên. Chạy sudo ufw status verbose và xác nhận policy mặc định cho lưu lượng vào là deny, đồng thời cả rule plain và (v6) đều tồn tại. Luôn mở một phiên SSH thứ hai trước khi đóng phiên đầu tiên, để lỗi trong cấu hình SSH không thể khóa bạn khỏi server. Nếu cả 3 phần đều đúng, các thiết lập cơ bản đã hoàn tất.