Chuẩn bảo mật tối thiểu cho VPS công cộng: Bản vá, Phân quyền, Tường lửa và Cứu hộ

Ngay khi VPS được cấp một địa chỉ IP công cộng, nó sẽ liên tục bị rà quét cổng và dò mật khẩu tự động từ khắp nơi trên thế giới. Người mới thường rơi vào hai thái cực: bỏ mặc vì nghĩ "chẳng ai thèm nhòm ngó IP của mình", hoặc sao chép hàng chục lệnh cấu hình phức tạp để rồi tự khóa quyền truy cập của chính mình.

Mô hình bảo vệ đáng tin cậy dựa trên việc thiết lập một chuẩn bảo mật tối thiểu và triển khai theo từng bước có kiểm soát, luôn duy trì lối thoát cứu hộ khẩn cấp.

1. Bảo mật là mô hình phòng thủ theo chiều sâu nhiều lớp

Không có lớp nào là chiếc khiên vạn năng. Đổi cổng không thay thế được khóa SSH; tường lửa không vá được lỗi mã nguồn ứng dụng; và snapshot nội bộ không thể thay thế cho bản sao lưu ngoại vi độc lập.

2. Bảo vệ tài khoản nhà cung cấp hosting trước tiên

Việc đầu tiên cần làm khi nhận VPS là bảo vệ tài khoản quản trị hạ tầng máy chủ:

• Dùng mật khẩu dài, độc lập không trùng với bất kỳ dịch vụ nào khác;
• Bật xác thực hai yếu tố (MFA/2FA) và lưu mã khôi phục ở nơi an toàn ngoại tuyến;
• Kiểm tra độ an toàn của email đăng ký tài khoản;
• Lưu sẵn đường dẫn Web Console cứu hộ và cổng hỗ trợ kỹ thuật;
• Xóa các API token không dùng và giới hạn quyền các token hiện có.

Nếu tài khoản quản trị bị chiếm quyền, kẻ tấn công có thể xóa sổ toàn bộ các lớp bảo vệ bên trong Linux.

3. Sử dụng OS được hỗ trợ và duy trì cập nhật

Chọn các bản phân phối còn trong thời hạn hỗ trợ cập nhật bảo mật chính thức (như Ubuntu LTS).

Trước khi nâng cấp:

1. Kiểm tra phiên bản OS và các dịch vụ quan trọng; 2. Đảm bảo dung lượng ổ đĩa còn trống đủ nhiều; 3. Xác nhận cấu hình và dữ liệu đã có bản sao lưu; 4. Nắm rõ việc cập nhật nhân kernel có cần khởi động lại máy hay không; 5. Xác định cách kiểm tra dịch vụ sau khi cập nhật xong.

4. Không dùng tài khoản root cho mọi thao tác hàng ngày

Tài khoản root có quyền can thiệp vào toàn bộ hệ thống. Nguyên tắc vận hành an toàn:

• Tạo người dùng quản trị thông thường;
• Chỉ nâng quyền qua sudo khi thực sự cần thao tác hệ thống;
• Chạy các dịch vụ mạng dưới tài khoản hệ thống chuyên dụng có đặc quyền thấp;
• Không dùng chung một mật khẩu quản trị cho tất cả cơ sở dữ liệu và ứng dụng;
• Định kỳ dọn dẹp các tài khoản cũ và khóa SSH không còn dùng.

5. Quy trình gia cố SSH chống bị khóa quyền truy cập

1. Xác nhận Web Console của nhà cung cấp hoạt động tốt; 2. Giữ nguyên phiên kết nối SSH hiện tại; 3. Tạo người dùng thường và cài đặt khóa SSH công khai; 4. Mở terminal mới thử đăng nhập bằng khóa và kiểm tra lệnh sudo; 5. Kiểm tra cấu hình SSH và log xác thực; 6. Từng bước tắt đăng nhập bằng mật khẩu và cấm đăng nhập root trực tiếp; 7. Kiểm tra lại bằng phiên kết nối mới sau mỗi thay đổi.

6. Tường lửa: Chỉ mở những cổng thực sự cần

Với VPS chỉ chạy web và quản trị SSH, số lượng cổng mở ra ngoài là rất ít.

Kiểm tra trên cả hai tầng:

• Security Group / Tường lửa đám mây của nhà cung cấp;
• Tường lửa bên trong hệ điều hành (ufw, nftables).

Đảm bảo cổng SSH đã được mở trước khi kích hoạt tường lửa. Ứng dụng backend chạy sau reverse proxy cục bộ nên bind vào 127.0.0.1 và không mở cổng ra ngoài Internet.

7. Đổi cổng và Fail2ban chỉ là giải pháp bổ trợ

Đổi cổng SSH từ 22 sang cổng khác giúp giảm bớt các bản ghi quét tự động trong log, nhưng không làm cho mật khẩu yếu trở nên an toàn hơn. Máy quét cổng vẫn dễ dàng tìm ra cổng đang mở.

Công cụ như Fail2ban giúp chặn tạm thời các IP có hành vi dò mật khẩu liên tục. Đây là lớp bảo vệ bổ trợ hữu ích, nhưng không thể thay thế cho xác thực bằng khóa và cập nhật bản vá.

8. Log, Sao lưu và Lối thoát cứu hộ là một phần của bảo mật

Mọi sự cố tấn công hay sai sót thao tác đều biểu hiện qua việc "hệ thống bị lệch khỏi trạng thái bình thường":

• Có lượt đăng nhập bất thường nào không?
• Các dịch vụ có bị crash liên tục không?
• Ổ đĩa có bị tăng dung lượng đột biến không?
• Ai đã sửa cấu hình vào lúc nào?
• Khi OS không khởi động được, có vào được Web Console không?
• Khi VPS bị xóa mất, bạn có dựng lại được trên máy chủ khác không?

Snapshot trong cùng một trung tâm dữ liệu chia sẻ chung rủi ro nền tảng. Dữ liệu quan trọng bắt buộc phải có bản sao lưu ngoại vi được mã hóa và diễn tập phục hồi thực tế.

9. Danh sách kiểm tra bảo mật trong 30 phút đầu

• [ ] Tài khoản nhà cung cấp dùng mật khẩu độc lập và đã bật MFA;
• [ ] Đã lưu lối vào Web Console, chế độ cứu hộ và mã khôi phục;
• [ ] OS đang trong thời hạn hỗ trợ chính thức;
• [ ] Đã cài đặt các bản vá bảo mật mới nhất;
• [ ] Đã tạo người dùng quản trị thường và cấu hình khóa SSH;
• [ ] Đã thử đăng nhập bằng khóa và lệnh sudo ở cửa sổ độc lập;
• [ ] Đã thiết lập tường lửa và đóng các cổng không cần thiết;
• [ ] Xem được nhật ký log và dung lượng đĩa bình thường;
• [ ] Đã thiết lập sao lưu ngoại vi và quy trình phục hồi;
• [ ] Tuyệt đối không chạy script lạ bằng quyền root.

10. Tổng kết

Chuẩn bảo mật tối thiểu cho VPS không phải là một script thần kỳ, mà là 6 trạng thái có thể kiểm chứng: tài khoản khó bị chiếm quyền, OS được cập nhật, quyền hạn thu hẹp, cổng vào tối thiểu, bất thường được nhìn thấy và sự cố có thể phục hồi được.

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

VPS dùng cho mục đích cá nhân có cần sao lưu không?

Có. Tối thiểu cần lưu danh mục tái thiết lập: phiên bản OS, file cấu hình, danh sách cổng mở và bản ghi DNS để phục hồi nhanh khi có sự cố.

Bật tường lửa có chống được mọi cuộc tấn công không?

Không. Tường lửa chỉ chặn các cổng đóng, nhưng không bảo vệ được trước lỗ hổng của các ứng dụng đang mở cổng hợp lệ (như web).

Có nên dùng các script làm cứng bảo mật (hardening) tự động trên mạng không?

Chỉ nên dùng khi bạn đọc hiểu toàn bộ mã nguồn, các thay đổi hệ thống và cách khôi phục khi có lỗi.

Tài liệu tham khảo

• Bảo mật Ubuntu: Cập nhật bảo mật
• Ubuntu Server: Tường lửa
• Ubuntu Release Notes: Các phiên bản được hỗ trợ
• OpenSSH: Tài liệu sshd_config
• CISA: Hướng dẫn StopRansomware