Bảo mật VPS: Checklist bảo vệ VPS Linux khỏi tấn công

• Bùi Tấn Lực
• 105
• 06/09/2026

Một VPS Linux sau khi được tạo mới thường có đủ tài nguyên để chạy website, API, cơ sở dữ liệu hoặc nhiều dịch vụ khác. Tuy nhiên, việc máy chủ hoạt động được không đồng nghĩa với việc nó đã an toàn. Một VPS có thể bị dò quét tự động, thử mật khẩu, khai thác dịch vụ mở trên Internet hoặc bị lợi dụng sau khi một tài khoản có quyền truy cập bị lộ.

Bảo mật VPS vì vậy không nên được hiểu đơn giản là cài một phần mềm bảo mật hoặc bật firewall. Cách tiếp cận hiệu quả hơn là xây dựng nhiều lớp phòng vệ: giảm bề mặt tấn công, kiểm soát quyền truy cập, giới hạn dịch vụ, cập nhật phần mềm, theo dõi log, sao lưu dữ liệu và chuẩn bị phương án xử lý khi có sự cố.

Checklist dưới đây được xây dựng theo hướng thực tế cho VPS Linux dùng để vận hành website và ứng dụng. Mục tiêu không phải biến máy chủ thành một hệ thống tuyệt đối không thể bị tấn công, mà là giảm đáng kể những rủi ro phổ biến và giúp người quản trị phát hiện, xử lý vấn đề sớm hơn.

Bảo mật VPS nên bắt đầu từ đâu?

Trước khi thay đổi hàng loạt cấu hình, cần xác định VPS đang chạy những gì và những thành phần nào thực sự cần thiết. Đây là bước thường bị bỏ qua nhưng lại có ảnh hưởng lớn đến mức độ an toàn của máy chủ.

Một máy chủ chỉ chạy website PHP sẽ có yêu cầu bảo mật khác với VPS chạy thêm Docker, Redis, PostgreSQL, MariaDB, FTP, mail server hoặc nhiều API. Mỗi dịch vụ được cài thêm đều có thể tạo ra một điểm cần bảo vệ.

Kiểm kê dịch vụ đang chạy

Hãy bắt đầu bằng việc kiểm tra các tiến trình và cổng mạng đang được sử dụng. Trên Linux, có thể dùng các lệnh sau:

ss -tulpn
systemctl --type=service --state=running

Kết quả giúp xác định VPS đang lắng nghe trên những cổng nào và dịch vụ nào đang hoạt động. Không nên chỉ dựa vào danh sách phần mềm đã cài vì một dịch vụ có thể được kích hoạt tự động hoặc chạy dưới dạng một tiến trình khác.

Nguyên tắc quan trọng là: dịch vụ không cần thiết thì không nên tồn tại trên máy chủ sản xuất. Nếu không sử dụng FTP, không cần chạy FTP. Nếu không cần một database truy cập trực tiếp từ Internet, không nên mở cổng database ra Internet.

Xác định những cổng thực sự cần công khai

Không phải mọi cổng đang mở đều là vấn đề, nhưng mỗi cổng có thể trở thành một điểm mà kẻ tấn công tìm cách tiếp cận. Một website thông thường thường chỉ cần HTTP và HTTPS cho người truy cập, trong khi cổng quản trị nên được kiểm soát chặt hơn.

Nhóm dịch vụ	Mục đích	Khuyến nghị
HTTP	Phục vụ website không mã hóa	Chỉ mở nếu cần chuyển hướng sang HTTPS hoặc phục vụ nội dung phù hợp
HTTPS	Phục vụ website qua TLS	Thường cần công khai cho website
SSH	Quản trị máy chủ	Hạn chế nguồn truy cập và bảo vệ bằng xác thực mạnh
Database	Kết nối cơ sở dữ liệu	Ưu tiên chỉ cho phép kết nối nội bộ hoặc từ máy chủ được tin cậy
Redis	Lưu cache hoặc dữ liệu tạm	Không nên công khai trực tiếp nếu không có nhu cầu đặc biệt
FTP	Truyền tệp	Nên loại bỏ nếu không cần thiết; ưu tiên phương thức truyền an toàn hơn

Đặc biệt, không nên có suy nghĩ rằng một cổng không chứa website thì không đáng quan tâm. Các dịch vụ quản trị, cơ sở dữ liệu, cache hoặc API nội bộ nếu bị đưa ra Internet có thể trở thành mục tiêu của các hệ thống quét tự động.

Giảm bề mặt tấn công của máy chủ

Giảm bề mặt tấn công là một trong những nguyên tắc quan trọng nhất khi bảo vệ VPS. Thay vì cố gắng bảo vệ hàng chục dịch vụ không cần thiết, cách tốt hơn là loại bỏ ngay những thành phần không phục vụ mục đích của hệ thống.

Gỡ phần mềm và dịch vụ không sử dụng

Một VPS mới cài có thể chứa các gói phần mềm được nhà cung cấp hoặc hệ điều hành cài sẵn. Hãy kiểm tra trước khi quyết định giữ lại hoặc gỡ bỏ.

Với hệ thống sử dụng systemd, có thể kiểm tra dịch vụ đang chạy bằng:

systemctl --type=service --state=running

Nếu phát hiện một dịch vụ không rõ mục đích, không nên lập tức xóa. Hãy xác định nó thuộc gói nào, ứng dụng nào sử dụng và có phải thành phần cần thiết của hệ thống hay không.

Sau khi xác định chắc chắn một dịch vụ không cần thiết, có thể vô hiệu hóa nó. Ví dụ:

sudo systemctl disable --now ten-dich-vu

Việc vô hiệu hóa một dịch vụ không sử dụng có hai lợi ích: giảm tài nguyên tiêu thụ và giảm số lượng thành phần có thể trở thành mục tiêu khai thác.

Không mở dịch vụ nội bộ ra Internet

Một sai lầm phổ biến là cấu hình ứng dụng để lắng nghe trên mọi địa chỉ mạng chỉ vì muốn kết nối thuận tiện. Trong nhiều trường hợp, dịch vụ chỉ cần phục vụ cho các ứng dụng chạy cùng VPS.

Ví dụ, nếu database chỉ được sử dụng bởi website nằm trên cùng máy chủ, việc cho phép database lắng nghe trên địa chỉ công khai là không cần thiết. Tốt hơn là giới hạn kết nối ở giao diện nội bộ hoặc chỉ cho phép các địa chỉ IP thực sự cần truy cập.

Nguyên tắc có thể áp dụng cho nhiều dịch vụ:

• Website công khai thì mở dịch vụ web cần thiết.
• Dịch vụ nội bộ chỉ nên phục vụ mạng nội bộ hoặc localhost nếu có thể.
• Dịch vụ quản trị phải được giới hạn nguồn truy cập.
• Cơ sở dữ liệu không nên mở toàn Internet nếu ứng dụng không yêu cầu.
• Các cổng không có mục đích rõ ràng nên được đóng.

Thiết lập tài khoản quản trị an toàn

Tài khoản quản trị có quyền cao là mục tiêu đặc biệt quan trọng. Nếu thông tin xác thực của tài khoản này bị lộ, kẻ tấn công có thể thay đổi cấu hình, đọc dữ liệu, cài phần mềm độc hại hoặc kiểm soát toàn bộ máy chủ.

Không sử dụng tài khoản quản trị trực tiếp cho mọi thao tác

Thay vì đăng nhập bằng tài khoản quản trị cho tất cả công việc, nên tạo một tài khoản riêng để quản trị VPS và chỉ sử dụng quyền cao khi thực sự cần.

sudo adduser adminweb
sudo usermod -aG sudo adminweb

Cách tổ chức này tạo ra một lớp kiểm soát bổ sung. Những thao tác thông thường có thể thực hiện bằng tài khoản không có quyền cao, còn các lệnh quản trị phải thông qua cơ chế nâng quyền.

Trước khi vô hiệu hóa quyền đăng nhập của tài khoản quản trị, cần bảo đảm tài khoản mới có thể đăng nhập và sử dụng sudo bình thường. Nếu cấu hình sai rồi đóng phiên SSH hiện tại, người quản trị có thể tự khóa mình khỏi VPS.

Đặt mật khẩu đủ mạnh

Mật khẩu quản trị VPS không nên là một chuỗi ngắn, tên website, tên miền, tên công ty hoặc thông tin có thể đoán được. Không nên sử dụng cùng một mật khẩu cho VPS, email, tài khoản quản lý tên miền và các dịch vụ khác.

Nếu hệ thống sử dụng SSH key, nên ưu tiên xác thực bằng khóa thay vì phụ thuộc hoàn toàn vào mật khẩu. SSH key giúp giảm đáng kể nguy cơ bị tấn công bằng cách thử hàng loạt mật khẩu yếu.

Kiểm tra quyền sudo

Không nên cấp quyền quản trị rộng hơn nhu cầu thực tế. Một tài khoản chỉ cần thực hiện một nhóm tác vụ cụ thể thì nên được cấp đúng phạm vi cần thiết thay vì mặc định cho mọi người quyền root.

Đối với VPS cá nhân hoặc website nhỏ, một tài khoản quản trị riêng có quyền sudo thường là mô hình đơn giản và phù hợp. Với hệ thống nhiều người vận hành, cần quản lý quyền theo vai trò để tránh việc một tài khoản bị lộ dẫn tới toàn bộ máy chủ bị kiểm soát.

Cập nhật hệ điều hành và phần mềm

Một máy chủ chưa được cập nhật trong thời gian dài có thể chứa các lỗ hổng đã được công bố và có bản vá. Vì vậy, cập nhật hệ điều hành là một phần bắt buộc trong checklist bảo mật chứ không phải công việc chỉ thực hiện khi VPS gặp lỗi.

Kiểm tra bản cập nhật trước khi nâng cấp

Với Debian hoặc Ubuntu, có thể kiểm tra các gói có phiên bản mới bằng:

sudo apt update
sudo apt list --upgradable

Sau khi kiểm tra, có thể tiến hành nâng cấp:

sudo apt upgrade

Trên các hệ thống RPM như Rocky Linux, AlmaLinux hoặc Fedora, quy trình sẽ khác tùy phiên bản và trình quản lý gói đang sử dụng.

Không chỉ cập nhật hệ điều hành

Việc cập nhật kernel nhưng bỏ quên các thành phần của ứng dụng cũng tạo ra rủi ro. Một website thực tế có thể phụ thuộc vào web server, PHP, thư viện, framework, database, CMS hoặc các package bên thứ ba.

Do đó, checklist cập nhật nên bao gồm:

• Hệ điều hành và các package hệ thống.
• Kernel và các thành phần bảo mật quan trọng.
• Web server như Nginx hoặc Apache.
• PHP và các extension đang sử dụng.
• Database server.
• Framework, CMS và thư viện của ứng dụng.
• Các package được ứng dụng cài thông qua trình quản lý dependency.

Không nên cập nhật mù quáng trên hệ thống sản xuất. Với ứng dụng quan trọng, nên kiểm tra tương thích trước, sao lưu và có phương án quay lại nếu bản cập nhật gây lỗi.

Checklist kiểm tra VPS ngay sau khi triển khai

Trước khi chuyển VPS sang trạng thái vận hành chính thức, có thể dùng checklist cơ bản dưới đây để rà soát nhanh:

• Đã xác định rõ VPS đang chạy những dịch vụ nào.
• Đã kiểm tra các cổng mạng đang lắng nghe.
• Đã loại bỏ hoặc vô hiệu hóa dịch vụ không cần thiết.
• Không có dịch vụ nội bộ nào bị mở công khai mà không có lý do.
• Đã tạo tài khoản quản trị riêng thay vì sử dụng tài khoản quyền cao cho mọi thao tác.
• Mật khẩu quản trị đủ mạnh và không dùng lại ở dịch vụ khác.
• Đã thiết lập SSH key nếu hệ thống cho phép.
• Hệ điều hành đã được cập nhật.
• Các phần mềm quan trọng trên máy chủ đã được kiểm tra phiên bản.
• Đã xác định những cổng thực sự cần truy cập từ Internet.

Đây mới là lớp bảo vệ ban đầu. Một VPS được cấu hình tài khoản tốt nhưng SSH vẫn mở rộng, firewall không giới hạn, database công khai hoặc không có cơ chế phát hiện đăng nhập bất thường thì vẫn còn nhiều điểm yếu cần xử lý.

Siết chặt quyền truy cập SSH

SSH thường là cánh cửa quản trị quan trọng nhất của VPS Linux. Nếu cánh cửa này được cấu hình quá rộng, toàn bộ máy chủ có thể trở thành mục tiêu của các chương trình tự động dò mật khẩu trên Internet.

Bảo vệ SSH không có nghĩa là chỉ đổi cổng mặc định. Việc đổi cổng có thể làm giảm một phần lưu lượng quét đơn giản nhưng không thể thay thế cho xác thực mạnh, giới hạn nguồn truy cập và kiểm soát tài khoản.

Ưu tiên SSH key thay cho mật khẩu

SSH key sử dụng một cặp khóa gồm khóa riêng và khóa công khai. Khóa riêng được giữ trên thiết bị của người quản trị, còn khóa công khai được đặt trên VPS.

Trên máy tính quản trị, có thể tạo một cặp khóa mới bằng:

ssh-keygen -t ed25519

Khóa công khai có thể được thêm vào tài khoản trên VPS. Với hệ thống hỗ trợ công cụ ssh-copy-id, có thể sử dụng:

ssh-copy-id adminweb@IP_VPS

Điểm quan trọng nhất là không làm mất khóa riêng. Khóa riêng không nên gửi qua email, đưa lên website, commit vào Git hoặc lưu trong thư mục mà người khác có thể đọc.

Nếu khóa riêng được bảo vệ bằng passphrase, ngay cả khi file khóa bị sao chép trái phép thì việc sử dụng nó cũng khó hơn đáng kể.

Kiểm tra đăng nhập bằng SSH key trước khi tắt mật khẩu

Đây là bước rất quan trọng. Hãy mở một phiên SSH mới và xác nhận tài khoản quản trị có thể đăng nhập bằng key trước khi thay đổi cấu hình xác thực.

Chỉ sau khi xác nhận phương thức đăng nhập mới hoạt động ổn định mới nên vô hiệu hóa đăng nhập bằng mật khẩu. Không nên đóng phiên SSH đang hoạt động cho đến khi phiên đăng nhập mới được kiểm tra thành công.

Vô hiệu hóa đăng nhập trực tiếp bằng tài khoản quyền cao

Nếu VPS cho phép tài khoản quyền cao đăng nhập trực tiếp qua SSH, việc một thông tin xác thực bị lộ có thể tạo ra hậu quả rất lớn. Mô hình an toàn hơn là đăng nhập bằng tài khoản quản trị thông thường rồi sử dụng sudo khi cần.

Cấu hình SSH thường nằm trong tệp:

/etc/ssh/sshd_config

Trong cấu hình, có thể kiểm soát việc đăng nhập trực tiếp bằng tài khoản quyền cao:

PermitRootLogin no

Không nên chỉnh sửa cấu hình rồi khởi động lại SSH ngay lập tức mà chưa kiểm tra cú pháp. Có thể kiểm tra trước bằng:

sudo sshd -t

Nếu không có lỗi, mới tiến hành áp dụng cấu hình theo cơ chế quản lý dịch vụ của hệ điều hành.

Tắt đăng nhập bằng mật khẩu khi đã sử dụng key

Nếu hệ thống đã được kiểm tra kỹ và tất cả tài khoản SSH cần thiết đều sử dụng key, có thể cân nhắc tắt xác thực bằng mật khẩu:

PasswordAuthentication no

Cấu hình này đặc biệt hữu ích trong việc loại bỏ nguy cơ tấn công brute-force dựa trên mật khẩu SSH. Tuy nhiên, trước khi áp dụng cần chắc chắn rằng người quản trị vẫn có phương thức truy cập dự phòng hợp lệ.

Không nên tắt xác thực bằng mật khẩu chỉ vì thấy trên một bài hướng dẫn rằng đó là cấu hình bảo mật tốt. Nếu VPS chưa có SSH key hoạt động hoặc nhà cung cấp không có console quản trị dự phòng, thao tác này có thể khiến quản trị viên mất quyền truy cập.

Kiểm soát người dùng và quyền hạn

Bảo mật máy chủ không chỉ nằm ở cách người dùng đăng nhập mà còn nằm ở việc họ được phép làm gì sau khi đăng nhập. Một tài khoản ứng dụng không nên có quyền quản trị toàn bộ hệ thống nếu công việc của nó chỉ là chạy website.

Tách tài khoản quản trị và tài khoản chạy ứng dụng

Website nên chạy dưới một user phù hợp với web server hoặc ứng dụng thay vì chạy toàn bộ tiến trình bằng quyền cao nhất.

Ví dụ, một ứng dụng PHP không cần quyền ghi vào toàn bộ hệ thống tệp. Nếu ứng dụng bị khai thác và tiến trình web có quyền quá lớn, kẻ tấn công có thể tận dụng chính quyền đó để mở rộng phạm vi kiểm soát.

Mô hình phân quyền nên hướng tới nguyên tắc quyền tối thiểu: tài khoản chỉ được đọc, ghi hoặc thực thi đúng những gì ứng dụng thực sự cần.

Kiểm tra các tài khoản hiện có

Nên rà soát định kỳ những tài khoản có khả năng đăng nhập vào VPS. Việc này giúp phát hiện tài khoản cũ, tài khoản thử nghiệm hoặc tài khoản không còn người sử dụng.

Có thể kiểm tra danh sách user bằng:

cut -d: -f1 /etc/passwd

Danh sách này không có nghĩa mọi tài khoản đều có thể đăng nhập SSH. Vì vậy, cần xem xét thêm shell đăng nhập, nhóm quyền và cấu hình SSH để xác định tài khoản nào thực sự có khả năng truy cập.

Thu hồi quyền của tài khoản không còn sử dụng

Khi một nhân sự, đối tác hoặc nhà phát triển không còn cần truy cập VPS, quyền truy cập phải được thu hồi thay vì để nguyên tài khoản cho lần sử dụng sau.

Với SSH key, cần xóa key không còn hợp lệ khỏi file authorized_keys của tài khoản tương ứng. Với tài khoản không còn sử dụng, có thể khóa tài khoản thay vì chỉ thay đổi mật khẩu.

sudo passwd -l ten_user

Việc thu hồi quyền thường bị bỏ quên vì nó không tạo ra lỗi ngay lập tức. Tuy nhiên, một tài khoản cũ với quyền truy cập còn tồn tại là một điểm yếu không cần thiết.

Bảo vệ file cấu hình và dữ liệu nhạy cảm

Không phải mọi cuộc tấn công đều bắt đầu bằng việc phá firewall. Một website có thể bị xâm nhập thông qua lỗ hổng ứng dụng rồi kẻ tấn công tìm cách đọc file cấu hình chứa mật khẩu database, API key hoặc thông tin kết nối dịch vụ.

Hạn chế quyền đọc file cấu hình

Các file chứa thông tin nhạy cảm nên chỉ cho phép những user hoặc group cần thiết đọc. Ví dụ, file cấu hình ứng dụng chứa thông tin database không nên có quyền đọc cho tất cả người dùng trên hệ thống.

Có thể kiểm tra quyền file bằng:

ls -l /duong-dan/toi/file-config

Không nên áp dụng một quyền cố định cho mọi ứng dụng. Quyền phù hợp phụ thuộc vào user chạy ứng dụng, group của web server và cách ứng dụng được triển khai.

Không đặt secret trực tiếp trong mã nguồn công khai

Mật khẩu database, API key, token hoặc private key không nên được đưa trực tiếp vào repository công khai. Một lỗi nhỏ trong quá trình đưa source code lên Git cũng có thể làm lộ thông tin truy cập.

Nếu ứng dụng sử dụng file môi trường hoặc file cấu hình riêng, cần bảo đảm các file này không bị web server phục vụ như tài nguyên tĩnh.

Ví dụ, một file chứa thông tin kết nối như:

DB_HOST=127.0.0.1
DB_NAME=website
DB_USER=website_user
DB_PASSWORD=mat_khau_manh

không nên được đặt ở vị trí mà người truy cập có thể tải trực tiếp qua HTTP.

Kiểm tra quyền thư mục upload

Thư mục upload là khu vực cần đặc biệt chú ý đối với website. Nếu ứng dụng cho phép người dùng tải file lên, kẻ tấn công có thể tìm cách đưa mã độc lên máy chủ rồi kích hoạt nó thông qua web server.

Thư mục upload nên được thiết kế theo nguyên tắc chỉ cho phép loại file cần thiết. Nếu website chỉ nhận hình ảnh, không nên cho phép người dùng tùy ý tải lên mọi loại file thực thi.

Quan trọng hơn, việc kiểm tra phần mở rộng ở phía trình duyệt là chưa đủ. Dữ liệu gửi lên phải được kiểm tra ở phía máy chủ và cần cân nhắc cả MIME type, nội dung file, kích thước, tên file và vị trí lưu trữ.

Giảm nguy cơ từ quyền file và thư mục

Quyền Linux quyết định user nào được đọc, ghi và thực thi tài nguyên. Cấu hình quyền quá rộng có thể khiến một lỗ hổng nhỏ trong website trở thành vấn đề lớn hơn.

Tránh cấp quyền ghi toàn bộ website cho web server

Một cấu hình nguy hiểm là cho phép tiến trình web server ghi vào toàn bộ thư mục mã nguồn. Nếu ứng dụng bị khai thác, kẻ tấn công có thể sửa PHP hoặc các file cấu hình để duy trì quyền truy cập.

Thay vào đó, chỉ những thư mục thực sự cần ghi như cache, session hoặc upload mới nên có quyền ghi tương ứng.

Có thể rà soát quyền của một thư mục bằng:

find /var/www -maxdepth 2 -type d -ls

và kiểm tra các file có quyền ghi rộng:

find /var/www -type f -perm -002 -ls

Các kết quả cần được đánh giá theo cấu trúc ứng dụng. Không phải file nào có quyền ghi rộng cũng lập tức là lỗ hổng, nhưng đây là những vị trí đáng để kiểm tra.

Cẩn thận với quyền 777

Quyền 777 thường được dùng như một cách xử lý nhanh khi website báo lỗi không thể ghi file. Tuy nhiên, việc cấp quyền đọc, ghi và thực thi cho mọi user không phải là giải pháp bảo mật tốt.

Nếu ứng dụng cần ghi file, nên xác định đúng user hoặc group cần quyền ghi rồi cấp quyền ở phạm vi nhỏ nhất có thể.

Thay vì sửa quyền một cách máy móc, hãy tìm nguyên nhân thực sự khiến ứng dụng không ghi được dữ liệu. Có thể vấn đề nằm ở owner, group, đường dẫn, SELinux, AppArmor hoặc cấu hình của chính ứng dụng.

Kiểm tra nhật ký truy cập và đăng nhập

Log là nguồn thông tin quan trọng để phát hiện những dấu hiệu bất thường. Một VPS có thể hoạt động bình thường trong khi phía sau đang có hàng trăm hoặc hàng nghìn lượt thử đăng nhập.

Rà soát lịch sử đăng nhập

Linux cung cấp một số công cụ giúp xem lịch sử đăng nhập và các phiên truy cập. Ví dụ:

last
lastb

Tùy cấu hình hệ thống, lastb có thể hiển thị những lần đăng nhập thất bại được ghi nhận.

Nếu phát hiện nhiều lần thử đăng nhập từ các địa chỉ IP lạ, đặc biệt là với các username không tồn tại hoặc tài khoản quản trị, đó là dấu hiệu VPS đang bị quét hoặc thử brute-force.

Không bỏ qua log SSH

Vị trí log phụ thuộc vào hệ điều hành và cấu hình logging. Trên nhiều hệ thống Linux sử dụng systemd, có thể xem thông tin của dịch vụ SSH thông qua journal:

sudo journalctl -u ssh
sudo journalctl -u sshd

Không nhất thiết phải đọc log thủ công mỗi ngày. Điều quan trọng là hệ thống phải có cách phát hiện những mẫu bất thường và cảnh báo khi số lần đăng nhập thất bại tăng đột biến.

Nguyên tắc tránh tự khóa khỏi VPS

Bảo mật máy chủ phải đi cùng khả năng quản trị. Một cấu hình cực kỳ chặt nhưng khiến quản trị viên mất quyền truy cập cũng không phải là một cấu hình tốt.

Trước mỗi thay đổi quan trọng đối với SSH hoặc quyền hệ thống, nên thực hiện theo trình tự:

1. Kiểm tra cấu hình hiện tại.
2. Sao lưu file cấu hình trước khi chỉnh sửa.
3. Thực hiện thay đổi nhỏ và có kiểm soát.
4. Kiểm tra cú pháp nếu dịch vụ hỗ trợ kiểm tra.
5. Mở một phiên truy cập mới để xác nhận cấu hình hoạt động.
6. Chỉ đóng phiên quản trị hiện tại sau khi phiên mới đăng nhập thành công.
7. Giữ thông tin console hoặc phương thức cứu hộ của nhà cung cấp VPS trong trường hợp SSH gặp sự cố.

Đây là nguyên tắc đặc biệt quan trọng khi thay đổi SSH, firewall hoặc quyền của các tài khoản hệ thống. Không nên thực hiện nhiều thay đổi lớn cùng lúc vì khi có lỗi sẽ rất khó xác định nguyên nhân.

Thiết lập firewall để kiểm soát lưu lượng

Firewall là lớp kiểm soát nằm giữa VPS và các kết nối mạng. Thay vì để mọi dịch vụ đang lắng nghe có thể nhận kết nối từ Internet, firewall cho phép quản trị viên xác định chính xác loại lưu lượng nào được phép đi vào máy chủ.

Một nguyên tắc dễ áp dụng là chỉ cho phép những kết nối thực sự cần thiết. Website công khai cần nhận kết nối HTTP và HTTPS, trong khi SSH hoặc các dịch vụ quản trị không nhất thiết phải cho phép toàn bộ Internet truy cập.

Chọn công cụ firewall phù hợp

Trên Linux có nhiều công cụ quản lý firewall khác nhau. Với máy chủ sử dụng Ubuntu hoặc Debian, UFW thường dễ tiếp cận đối với người mới. Các hệ thống khác có thể sử dụng firewalld hoặc trực tiếp quản lý nftables tùy kiến trúc.

Ví dụ với UFW, có thể kiểm tra trạng thái hiện tại bằng:

sudo ufw status verbose

Trước khi bật firewall, cần bảo đảm cổng SSH đang được cho phép. Nếu bật firewall trong khi chưa cho phép SSH, phiên quản trị hiện tại có thể bị gián đoạn hoặc những lần đăng nhập tiếp theo sẽ không thực hiện được.

Chỉ mở các cổng cần thiết

Một cấu hình đơn giản cho VPS chạy website có thể chỉ cần cho phép SSH, HTTP và HTTPS:

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Số cổng SSH trong ví dụ chỉ mang tính minh họa. Nếu SSH được cấu hình trên cổng khác, phải sử dụng đúng cổng thực tế.

Không nên mở một dải cổng rộng chỉ để tránh phải kiểm tra từng dịch vụ. Mỗi cổng được mở nên có một lý do rõ ràng và nên được ghi nhận để sau này dễ rà soát.

Giới hạn nguồn truy cập đối với dịch vụ quản trị

Nếu chỉ có một vài địa chỉ IP cố định cần quản trị VPS, có thể giới hạn SSH chỉ cho những nguồn đó. Cách này giúp giảm đáng kể số lượng kết nối không mong muốn từ Internet.

Tuy nhiên, nếu người quản trị thường xuyên sử dụng mạng có IP động, việc whitelist IP cố định có thể gây bất tiện. Khi đó cần kết hợp SSH key, xác thực mạnh và các cơ chế chống brute-force thay vì áp dụng whitelist một cách máy móc.

Bảo vệ web server trước các yêu cầu bất thường

Web server là dịch vụ thường xuyên tiếp xúc trực tiếp với Internet. Nginx hoặc Apache có thể phải xử lý hàng nghìn request mỗi ngày, trong đó không phải tất cả đều đến từ người dùng hợp lệ.

Các bot tự động có thể liên tục dò đường dẫn quản trị, file backup, file cấu hình, endpoint cũ hoặc những phần mềm có lỗ hổng. Vì vậy, bảo mật web server cần được xem xét cùng với bảo mật ứng dụng.

Không để lộ file cấu hình và file tạm

Những file như file cấu hình môi trường, bản sao database, file backup hoặc source code chưa đóng gói có thể chứa thông tin nhạy cảm. Nếu chúng nằm trong thư mục public và web server phục vụ trực tiếp, dữ liệu có thể bị tải xuống chỉ bằng một request.

Website cần được tổ chức sao cho thư mục public chỉ chứa những tài nguyên thực sự cần công khai. File cấu hình, secret và dữ liệu nội bộ nên được đặt bên ngoài document root nếu kiến trúc ứng dụng cho phép.

Tắt directory listing khi không cần

Directory listing có thể khiến người truy cập nhìn thấy danh sách file trong một thư mục. Trong một số trường hợp điều này không trực tiếp tạo ra lỗ hổng, nhưng nó làm lộ cấu trúc tài nguyên và hỗ trợ quá trình dò tìm của kẻ tấn công.

Nếu website không cần chức năng liệt kê thư mục, nên tắt nó trong cấu hình web server.

Không sử dụng cấu hình mặc định một cách mù quáng

Cấu hình mặc định thường nhằm giúp phần mềm hoạt động nhanh chứ không nhất thiết phù hợp với mọi môi trường sản xuất. Sau khi cài web server, cần xem xét các thành phần đang được bật, các virtual host, thư mục public, quyền file và những module không cần thiết.

Không nên sao chép nguyên một cấu hình bảo mật từ Internet mà không hiểu tác dụng của từng directive. Một cấu hình không phù hợp có thể làm website lỗi hoặc vô tình chặn chức năng hợp lệ.

Triển khai HTTPS đúng cách

HTTPS mã hóa dữ liệu giữa trình duyệt và máy chủ, giúp bảo vệ thông tin đăng nhập, session và dữ liệu được truyền trong quá trình sử dụng website. Đối với website có tài khoản người dùng hoặc biểu mẫu chứa dữ liệu riêng tư, HTTPS gần như là yêu cầu cơ bản.

Không chỉ cài chứng chỉ rồi bỏ đó

Chứng chỉ TLS cần được theo dõi thời hạn và quá trình gia hạn. Nếu chứng chỉ hết hạn, người dùng có thể nhận cảnh báo trình duyệt và website mất tính tin cậy.

Với hệ thống sử dụng Let's Encrypt, việc gia hạn tự động thường có thể được thiết lập thông qua Certbot hoặc cơ chế tương ứng. Sau khi cấu hình tự động, vẫn nên kiểm tra định kỳ để bảo đảm quá trình gia hạn thực sự hoạt động.

Chuyển hướng HTTP sang HTTPS

Nếu website chỉ muốn phục vụ nội dung qua HTTPS, HTTP có thể được dùng để chuyển hướng người truy cập sang phiên bản bảo mật. Cần kiểm tra kỹ cấu hình chuyển hướng để tránh tạo vòng lặp hoặc làm hỏng các domain và subdomain hợp lệ.

Sau khi HTTPS hoạt động, cần kiểm tra cả tài nguyên bên trong trang. Việc website sử dụng HTTPS nhưng vẫn gọi JavaScript, CSS hoặc hình ảnh qua HTTP có thể tạo ra vấn đề mixed content.

Bảo vệ PHP và môi trường thực thi

Đối với VPS chạy website PHP, PHP-FPM và các extension liên quan là một phần quan trọng của bề mặt tấn công. Việc sử dụng phiên bản PHP cũ hoặc bật quá nhiều extension không cần thiết có thể làm tăng rủi ro.

Sử dụng phiên bản PHP còn được hỗ trợ

Không nên giữ một phiên bản PHP lỗi thời chỉ vì website hiện tại vẫn chạy. Khi một phiên bản không còn nhận các bản vá bảo mật, việc tiếp tục sử dụng nó làm tăng rủi ro theo thời gian.

Trước khi nâng cấp PHP, nên kiểm tra mã nguồn và dependency của website. Một số hàm hoặc thư viện có thể thay đổi hành vi giữa các phiên bản, vì vậy việc nâng cấp cần được kiểm thử thay vì thực hiện trực tiếp trên hệ thống đang có lưu lượng lớn.

Chỉ bật extension thực sự cần thiết

Mỗi extension bổ sung thêm thành phần vào môi trường PHP. Không có nghĩa mọi extension đều nguy hiểm, nhưng một hệ thống gọn gàng sẽ dễ quản lý và kiểm tra hơn.

Có thể xem danh sách module PHP đang được bật bằng:

php -m

Hãy đối chiếu danh sách này với yêu cầu thực tế của website. Những extension không sử dụng có thể được xem xét tắt hoặc gỡ bỏ sau khi xác nhận chúng không phải dependency của ứng dụng.

Hạn chế thông tin PHP bị công khai

Website không cần thiết phải công khai phiên bản PHP đang sử dụng cho người truy cập. Việc giảm thông tin kỹ thuật bị tiết lộ không thể ngăn một cuộc tấn công có chủ đích, nhưng giúp hạn chế lượng thông tin mà hệ thống tự cung cấp.

Trong cấu hình PHP, có thể xem xét thiết lập:

expose_php = Off

Việc này chỉ là một lớp giảm thông tin, không thay thế cho việc cập nhật PHP và bảo vệ ứng dụng.

Kiểm soát các chức năng nguy hiểm trong ứng dụng

Việc vô hiệu hóa một số chức năng PHP có thể hữu ích trong một số môi trường, nhưng không nên tạo ra một danh sách cấm chung áp dụng cho mọi website.

Một số ứng dụng hợp pháp cần thực thi chương trình hệ thống, xử lý file hoặc sử dụng các chức năng đặc biệt. Nếu vô hiệu hóa tùy tiện, website có thể phát sinh lỗi hoặc tạo ra giải pháp thay thế còn kém an toàn hơn.

Đánh giá chức năng theo nhu cầu thực tế

Thay vì sao chép một danh sách disable_functions có sẵn trên mạng, hãy xác định ứng dụng thực sự sử dụng những chức năng nào.

Ví dụ, một website PHP thông thường không nên có lý do để cho phép mọi thành phần trong mã nguồn thực thi lệnh hệ điều hành tùy ý. Nếu ứng dụng thực sự cần chức năng đó, quyền thực thi phải được xem xét cùng với kiến trúc và user chạy PHP.

Không dùng cấu hình bảo mật để che giấu lỗi ứng dụng

Nếu website có lỗ hổng SQL injection, upload file không an toàn, command injection hoặc lỗi phân quyền, việc khóa một vài hàm PHP không giải quyết được nguyên nhân gốc.

Lớp máy chủ và lớp ứng dụng phải được bảo vệ đồng thời. VPS an toàn nhưng source code có lỗ hổng vẫn có thể bị khai thác thông qua HTTP.

Giảm nguy cơ brute-force và quét tự động

Các dịch vụ công khai như SSH, trang đăng nhập quản trị và một số API thường xuyên nhận những request tự động. Không phải mọi request bất thường đều là một cuộc tấn công thành công, nhưng số lượng thử nghiệm lớn có thể tạo tải và làm tăng nguy cơ nếu hệ thống sử dụng xác thực yếu.

Sử dụng cơ chế giới hạn đăng nhập

Đối với SSH, có thể sử dụng các công cụ như Fail2ban để theo dõi log và tạm thời chặn những địa chỉ có hành vi đăng nhập thất bại bất thường.

Fail2ban không phải giải pháp thay thế firewall hoặc SSH key. Nó nên được xem là một lớp bổ sung nhằm giảm tác động của những hành vi thử mật khẩu tự động.

Không nhầm số lượng request với mức độ nguy hiểm

Một IP gửi nhiều request chưa chắc đã là kẻ tấn công. Có thể đó là crawler, health check, CDN hoặc một hệ thống giám sát. Vì vậy, các luật chặn tự động cần được thiết kế cẩn thận để tránh khóa nhầm người dùng hợp lệ.

Đặc biệt với website có API, hệ thống đăng nhập hoặc dịch vụ phía sau proxy, cần xác định chính xác địa chỉ IP thực của client trước khi xây dựng quy tắc giới hạn.

Checklist lớp mạng và ứng dụng

Sau khi hoàn thành các bước trên, có thể rà soát nhanh theo danh sách sau:

• Firewall đang hoạt động và có chính sách rõ ràng.
• Chỉ những cổng cần thiết mới được phép nhận kết nối từ Internet.
• Cổng quản trị được bảo vệ bằng phương thức xác thực mạnh.
• Database và các dịch vụ nội bộ không bị công khai nếu không cần thiết.
• Web server không bật directory listing khi không có nhu cầu.
• File cấu hình, secret và backup không nằm trong vùng public.
• Website sử dụng HTTPS và chứng chỉ có cơ chế gia hạn phù hợp.
• Phiên bản PHP đang sử dụng vẫn được hỗ trợ.
• PHP chỉ bật những extension cần thiết.
• Cấu hình PHP không công khai thông tin kỹ thuật không cần thiết.
• Thư mục upload được kiểm soát cả loại file và quyền thực thi.
• Có cơ chế giảm brute-force đối với các dịch vụ xác thực quan trọng.
• Các quy tắc tự động chặn đã được kiểm tra để tránh ảnh hưởng người dùng hợp lệ.

Thiết lập giám sát để phát hiện bất thường

Bảo mật VPS không kết thúc sau khi cấu hình xong firewall và SSH. Một hệ thống an toàn cần có khả năng cho biết khi nào máy chủ bắt đầu hoạt động khác thường. Nếu chỉ kiểm tra khi website đã ngừng hoạt động, rất nhiều dấu hiệu quan trọng có thể đã bị bỏ qua.

Các chỉ số cơ bản nên được theo dõi gồm CPU, RAM, dung lượng ổ đĩa, lưu lượng mạng, số lượng tiến trình, tải hệ thống và tình trạng của những dịch vụ quan trọng.

Theo dõi tài nguyên hệ thống

Có thể kiểm tra nhanh tình trạng CPU và tiến trình bằng:

top

Hoặc sử dụng:

htop

Nếu VPS đột nhiên sử dụng CPU rất cao trong thời gian dài, không nên mặc định rằng nguyên nhân là lượng truy cập tăng. Một tiến trình lạ chạy liên tục cũng có thể là dấu hiệu của malware, cryptominer hoặc một ứng dụng bị khai thác.

Tương tự, RAM tăng bất thường hoặc ổ đĩa nhanh chóng đầy có thể xuất phát từ log tăng đột biến, tiến trình bị lỗi, file tạm hoặc hoạt động đáng ngờ.

Theo dõi dung lượng ổ đĩa

Ổ đĩa đầy có thể khiến database, web server hoặc các dịch vụ khác ngừng hoạt động. Vì vậy, đây vừa là vấn đề vận hành vừa là vấn đề bảo mật.

Có thể kiểm tra nhanh bằng:

df -h

Nếu một phân vùng gần đầy, cần xác định nguyên nhân thay vì chỉ xóa ngẫu nhiên các file. Đặc biệt không nên tự ý xóa log hệ thống khi chưa hiểu cơ chế rotation hoặc retention của dịch vụ.

Quản lý log và tìm dấu hiệu xâm nhập

Log giúp trả lời những câu hỏi quan trọng khi xảy ra sự cố: ai đã đăng nhập, thời điểm nào, dịch vụ nào nhận request bất thường và hệ thống bắt đầu thay đổi từ lúc nào.

Đối với website, nên quan tâm ít nhất đến log của SSH, web server, PHP-FPM, database và các ứng dụng quan trọng khác.

Không chỉ lưu log mà phải biết cách đọc log

Một máy chủ có thể tạo ra hàng triệu dòng log nhưng vẫn không giúp ích nhiều nếu không có cơ chế lọc và cảnh báo. Hãy xác định trước những sự kiện đáng chú ý.

• Nhiều lần đăng nhập SSH thất bại liên tiếp.
• Đăng nhập thành công từ nguồn không quen thuộc.
• Thay đổi tài khoản hoặc quyền sudo.
• Xuất hiện process mới không thuộc ứng dụng đã triển khai.
• Website xuất hiện request tới những đường dẫn bất thường.
• Số lượng lỗi HTTP tăng đột biến.
• PHP phát sinh lỗi hoặc warning bất thường trên diện rộng.
• File mã nguồn thay đổi ngoài thời gian triển khai.
• Dung lượng ổ đĩa tăng nhanh không có nguyên nhân rõ ràng.

Bảo vệ log khỏi bị xóa hoặc ghi đè quá sớm

Nếu máy chủ bị xâm nhập, kẻ tấn công có thể tìm cách xóa dấu vết. Do đó, những hệ thống quan trọng nên cân nhắc gửi log tới một nơi khác thay vì chỉ lưu duy nhất trên chính VPS.

Việc lưu log tập trung giúp điều tra tốt hơn khi máy chủ gặp sự cố nghiêm trọng hoặc ổ đĩa bị hỏng.

Sao lưu dữ liệu theo nguyên tắc có thể khôi phục

Backup không ngăn được cuộc tấn công, nhưng nó quyết định khả năng phục hồi sau cuộc tấn công. Một bản backup chỉ thực sự có giá trị khi dữ liệu có thể khôi phục thành công.

Sao lưu nhiều loại dữ liệu

Đối với website, không nên chỉ sao lưu source code. Một hệ thống hoàn chỉnh thường cần quan tâm đến:

• Mã nguồn website.
• Cơ sở dữ liệu.
• File người dùng upload.
• File cấu hình quan trọng.
• SSL certificate và cấu hình liên quan nếu cần thiết.
• Cấu hình web server.
• Các thiết lập đặc biệt của ứng dụng.

Không phải dữ liệu nào cũng cần backup với cùng tần suất. Database của website có giao dịch mỗi phút sẽ có yêu cầu khác với một website giới thiệu doanh nghiệp ít thay đổi.

Không lưu bản backup duy nhất trên chính VPS

Nếu VPS bị xóa, lỗi ổ đĩa hoặc bị mã hóa dữ liệu, backup nằm cùng máy chủ có thể mất theo. Vì vậy, bản sao quan trọng nên được lưu ở một hệ thống độc lập.

Đặc biệt, backup cần được bảo vệ quyền truy cập. Nếu tài khoản VPS bị chiếm quyền và kẻ tấn công có thể xóa toàn bộ backup từ xa, việc sao lưu sẽ mất phần lớn ý nghĩa.

Kiểm tra khả năng phục hồi

Không nên coi việc tạo được file backup là đồng nghĩa với việc có backup hợp lệ. Hãy định kỳ thử khôi phục một bản sao trên môi trường kiểm tra.

Một quy trình backup tốt cần trả lời được ba câu hỏi:

1. Dữ liệu được sao lưu ở đâu?
2. Có thể khôi phục dữ liệu trong bao lâu?
3. Nếu VPS mất hoàn toàn, hệ thống có thể được dựng lại như thế nào?

Đây là điểm khác biệt giữa có backup và có khả năng phục hồi.

Kiểm tra tính toàn vẹn của website

Một website bị xâm nhập không nhất thiết phải ngừng hoạt động. Kẻ tấn công có thể chỉ chèn một đoạn mã vào một file PHP, tạo tài khoản quản trị ẩn hoặc đặt một backdoor để quay lại sau.

Vì vậy, sau khi VPS vận hành ổn định, nên có phương án phát hiện những thay đổi ngoài dự kiến.

Quản lý mã nguồn bằng hệ thống kiểm soát phiên bản

Đối với website có mã nguồn được quản lý bằng Git, lịch sử thay đổi có thể giúp phát hiện những file bị sửa ngoài quy trình triển khai.

Tuy nhiên, không nên đặt thư mục repository chứa thông tin nội bộ vào vùng có thể truy cập trực tiếp qua HTTP. Các file metadata của hệ thống quản lý mã nguồn có thể tiết lộ thông tin về source code nếu bị cấu hình sai.

Theo dõi file quan trọng

Các file cấu hình web server, PHP, cron job và mã nguồn quan trọng nên được kiểm soát. Nếu một file bất ngờ thay đổi vào thời điểm không có đợt triển khai, đó là sự kiện cần điều tra.

Có thể sử dụng hệ thống kiểm tra tính toàn vẹn file hoặc công cụ giám sát phù hợp với quy mô VPS. Không nhất thiết phải triển khai một hệ thống phức tạp cho website nhỏ, nhưng phải có cách xác định những thay đổi quan trọng.

Kiểm tra cron và tiến trình chạy nền

Cron là thành phần hợp pháp được sử dụng để chạy backup, xử lý dữ liệu, gửi email hoặc thực hiện các tác vụ định kỳ. Tuy nhiên, cron cũng có thể bị lợi dụng để duy trì một hoạt động trái phép sau khi máy chủ bị xâm nhập.

Rà soát cron job

Hãy kiểm tra các cron job của tài khoản quản trị và những tài khoản chạy ứng dụng:

crontab -l
sudo crontab -l

Ngoài cron của từng user, cần chú ý đến các cấu hình định kỳ khác của hệ thống như cron system và systemd timer.

Một tác vụ không rõ nguồn gốc, chạy một file nằm trong thư mục tạm hoặc tải dữ liệu từ Internet về thực thi là dấu hiệu cần được kiểm tra kỹ.

Kiểm tra process bất thường

Khi VPS có CPU cao hoặc lưu lượng mạng bất thường, hãy kiểm tra những process đang chạy thay vì chỉ khởi động lại máy chủ.

ps aux --sort=-%cpu | head
ps aux --sort=-%mem | head

Việc khởi động lại có thể làm hiện tượng tạm thời biến mất nhưng không giải quyết nguyên nhân. Nếu có malware hoặc một cron job độc hại, tiến trình có thể xuất hiện trở lại sau khi máy chủ khởi động.

Hạn chế khả năng duy trì quyền truy cập trái phép

Một cuộc xâm nhập nguy hiểm không chỉ nằm ở việc kẻ tấn công thực hiện được một hành động ban đầu. Điều đáng lo hơn là họ có thể duy trì quyền truy cập để quay lại sau khi lỗ hổng đã được đóng.

Do đó, khi phát hiện sự cố, cần kiểm tra nhiều vị trí thay vì chỉ xóa một file đáng ngờ.

Rà soát SSH key

Kiểm tra các file authorized_keys của những tài khoản có khả năng đăng nhập. Nếu xuất hiện một khóa không thuộc về quản trị viên, cần xem đó là dấu hiệu xâm nhập.

Không nên chỉ xóa khóa đáng ngờ rồi kết luận rằng VPS đã sạch. Cần xác định bằng cách nào khóa đó được thêm vào và liệu kẻ tấn công có tạo thêm tài khoản hoặc cơ chế truy cập khác hay không.

Rà soát tài khoản và quyền sudo

Kiểm tra những tài khoản mới tạo, nhóm quyền và các thay đổi bất thường trong cấu hình sudo. Một tài khoản lạ có quyền cao có thể là cơ chế duy trì truy cập.

Rà soát các cơ chế khởi động tự động

Ngoài cron, cần kiểm tra những service hoặc timer mới xuất hiện. Nếu có một dịch vụ không thuộc quá trình triển khai nhưng tự động chạy sau mỗi lần khởi động, đó là một dấu hiệu cần điều tra.

Quy trình xử lý khi nghi ngờ VPS bị xâm nhập

Khi phát hiện dấu hiệu rõ ràng như tài khoản lạ, process đáng ngờ, file mã nguồn bị thay đổi trái phép hoặc lưu lượng bất thường, không nên chỉ xóa ngay những gì nhìn thấy.

Cô lập trước khi làm sạch

Nếu tình huống nghiêm trọng, bước đầu tiên nên là hạn chế khả năng máy chủ tiếp tục giao tiếp với bên ngoài, đồng thời bảo toàn những thông tin cần thiết cho việc điều tra.

Tùy mức độ sự cố, có thể giới hạn lưu lượng bằng firewall, tạm ngừng dịch vụ bị ảnh hưởng hoặc sử dụng các công cụ quản trị của nhà cung cấp VPS.

Không nên vội vàng xóa toàn bộ log hoặc reboot liên tục nếu cần điều tra nguyên nhân. Một số bằng chứng có thể mất sau khi hệ thống thay đổi trạng thái.

Đổi thông tin xác thực từ một thiết bị sạch

Nếu nghi ngờ VPS bị chiếm quyền, không nên mặc định rằng các credential đang được sử dụng vẫn an toàn. Cần cân nhắc thay đổi mật khẩu, SSH key, API key, database password và những secret liên quan từ một môi trường được tin cậy.

Đặc biệt, nếu cùng một mật khẩu đã được sử dụng ở nhiều hệ thống khác nhau, cần thay đổi toàn bộ những nơi sử dụng mật khẩu đó.

Cân nhắc dựng lại VPS

Đối với một máy chủ đã bị kiểm soát ở mức cao, việc cố gắng tìm và xóa từng file độc hại không phải lúc nào cũng là lựa chọn đáng tin cậy. Kẻ tấn công có thể đã tạo nhiều cơ chế duy trì quyền truy cập mà quản trị viên chưa phát hiện.

Trong trường hợp phù hợp, cách an toàn hơn là tạo một VPS mới từ image sạch, cập nhật hệ thống, triển khai ứng dụng từ source code đáng tin cậy và khôi phục dữ liệu từ backup đã được kiểm tra.

Không nên phục hồi nguyên trạng toàn bộ hệ thống cũ chỉ vì muốn tiết kiệm thời gian. Những file cấu hình hoặc script đã bị sửa có thể đưa sự cố trở lại máy chủ mới.

Checklist bảo mật VPS Linux hoàn chỉnh

Trước khi đưa VPS vào vận hành lâu dài, có thể sử dụng checklist tổng hợp sau để rà soát:

Hạng mục	Trạng thái cần đạt
Tài khoản quản trị	Có tài khoản quản trị riêng, quyền được kiểm soát và không sử dụng quyền cao tùy tiện
SSH	Xác thực mạnh, SSH key được quản lý an toàn và hạn chế truy cập không cần thiết
Quyền cao	Không cho phép đăng nhập trực tiếp bằng tài khoản quyền cao nếu không có nhu cầu đặc biệt
Firewall	Chỉ mở những cổng thực sự cần thiết
Dịch vụ	Đã loại bỏ hoặc vô hiệu hóa các dịch vụ không sử dụng
Database	Không công khai Internet nếu ứng dụng không yêu cầu
Hệ điều hành	Được cập nhật bản vá bảo mật định kỳ
Web server	Cấu hình phù hợp, không để lộ file và thư mục nội bộ
HTTPS	Chứng chỉ hợp lệ và có cơ chế gia hạn
PHP	Phiên bản còn được hỗ trợ và chỉ bật thành phần cần thiết
File upload	Kiểm soát loại file, kích thước, vị trí lưu trữ và quyền thực thi
File permission	Quyền đọc, ghi, thực thi được cấp theo nhu cầu tối thiểu
Log	Có log cần thiết và có khả năng phát hiện hành vi bất thường
Giám sát	Theo dõi CPU, RAM, ổ đĩa, mạng và dịch vụ quan trọng
Backup	Có bản sao độc lập và đã kiểm tra khả năng khôi phục
Cron và service	Định kỳ rà soát các tác vụ tự động và tiến trình nền
Secret	API key, mật khẩu và token không bị công khai trong source code hoặc thư mục public
Ứng phó sự cố	Có phương án cô lập, thay credential và dựng lại máy chủ khi cần

Bảo mật VPS là quá trình liên tục

Không có checklist nào biến VPS thành một hệ thống bất khả xâm phạm. Mục tiêu thực tế của bảo mật là giảm bề mặt tấn công, hạn chế tác động khi một lớp phòng vệ thất bại và phát hiện sự cố đủ sớm để có thể phục hồi.

Với một VPS chạy website, có thể hình dung hệ thống phòng vệ theo nhiều lớp: SSH và tài khoản bảo vệ quyền quản trị, firewall kiểm soát kết nối, web server và PHP giảm rủi ro ở lớp dịch vụ, phân quyền file giới hạn hậu quả khi ứng dụng bị khai thác, còn log, giám sát và backup giúp phát hiện và phục hồi.

Điều quan trọng nhất là không xem bảo mật như một công việc làm một lần sau khi cài VPS. Phiên bản phần mềm thay đổi, ứng dụng được cập nhật, nhân sự thay đổi quyền truy cập và các lỗ hổng mới liên tục xuất hiện. Vì vậy, checklist cần được rà soát định kỳ thay vì chỉ sử dụng trong ngày đầu triển khai.

Đối với website doanh nghiệp hoặc hệ thống có dữ liệu quan trọng, nên xây dựng quy trình quản trị rõ ràng: ai được truy cập VPS, truy cập bằng cách nào, những cổng nào được phép mở, backup nằm ở đâu, log được lưu trong bao lâu và phải làm gì khi phát hiện dấu hiệu bất thường. Khi những câu hỏi này có câu trả lời cụ thể, bảo mật VPS sẽ trở thành một phần của quy trình vận hành thay vì phụ thuộc vào vài thiết lập thủ công.

Web Mới hướng tới việc xây dựng website và hệ thống web theo nhu cầu thực tế, vì vậy khi triển khai một website trên VPS, bảo mật máy chủ nên được xem xét ngay từ kiến trúc ban đầu thay vì chờ đến khi phát sinh sự cố mới xử lý. Một hệ thống được phân quyền hợp lý, hạn chế dịch vụ công khai, có backup và có khả năng phục hồi sẽ luôn dễ quản lý hơn một VPS được cấu hình vội vàng rồi phải sửa chữa khi đã đi vào vận hành.

Bùi Tấn Lực

Đánh giá

Chia sẻ nội dung đánh giá của bạn về Bảo mật VPS: Checklist bảo vệ VPS Linux khỏi tấn công
Email, Điện thoại của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *

Bình luận, Hỏi đáp