VPS bị hack là câu chuyện không hiếm gặp — đặc biệt với các SME Việt Nam tự setup VPS lần đầu. Một khảo sát từ Sucuri (2025) cho thấy 43% VPS mới bị scan và thử tấn công trong vòng 24 giờ đầu tiên sau khi được tạo. Đáng lo hơn, theo báo cáo của VNISA (Hiệp hội An ninh mạng Việt Nam), thiệt hại trung bình khi VPS bị hack cho một SME dao động từ 20–200 triệu VND, chưa tính mất dữ liệu khách hàng và uy tín thương hiệu.
Bài viết này phân tích 5 lỗi bảo mật phổ biến nhất mà chúng tôi gặp khi audit VPS cho khách hàng — và cách khắc phục từng lỗi.
Câu chuyện thực tế: VPS bị hack sau 72 giờ
Anh M. — chủ một cửa hàng thời trang online tại TP.HCM — quyết định chuyển website từ shared hosting sang VPS để “chạy nhanh hơn”. Anh thuê freelancer setup VPS với giá 500.000 VND. Mọi thứ chạy ổn được 3 ngày.
Ngày thứ 4:
- Website hiển thị trang lạ bằng tiếng Trung
- Khách hàng báo nhận email spam từ domain anh
- Google Search Console cảnh báo “trang web có phần mềm độc hại”
- Database bị xóa sạch, file backup cũng bị xóa
Thiệt hại:
- 15 triệu VND thuê chuyên gia khôi phục (chỉ phục hồi được 60% dữ liệu)
- 7 ngày website không hoạt động = mất khoảng 35 triệu VND doanh thu
- Google deindex website → 2 tháng mới khôi phục ranking SEO
- Mất 2.000+ email khách hàng
Vậy freelancer đã mắc những lỗi gì?
Lỗi 1: Đăng nhập root bằng password đơn giản
Vấn đề
Đây là lỗi phổ biến nhất và nguy hiểm nhất. Khi VPS mới tạo, bạn nhận được root password qua email. Nhiều người giữ nguyên password này hoặc đổi thành password đơn giản (“Admin@123”, “Abc123456”).
Thực tế: Mỗi VPS với port SSH 22 mở nhận trung bình 10.000–100.000 lần thử đăng nhập brute-force mỗi ngày. Với password yếu, hacker trung bình mất 2–6 giờ để crack.
Hậu quả
Khi hacker có root access, họ có thể:
- Cài crypto miner (VPS chạy 100% CPU mining tiền ảo cho hacker)
- Cài backdoor để quay lại bất cứ lúc nào
- Đọc toàn bộ database (thông tin khách hàng, mật khẩu)
- Gửi spam email từ server của bạn (domain bị blacklist)
- Cài ransomware, mã hóa tất cả dữ liệu
Cách khắc phục
Bước 1: Tắt đăng nhập root qua SSH
# /etc/ssh/sshd_config
PermitRootLogin no
Bước 2: Sử dụng SSH key thay vì password
PasswordAuthentication no
PubkeyAuthentication yes
Bước 3: Cài Fail2Ban
sudo apt install fail2ban -y
# Tự động chặn IP sau 3 lần đăng nhập sai
Bước 4: Đổi port SSH (tùy chọn nhưng giảm 99% scan tự động)
# /etc/ssh/sshd_config
Port 2222 # Thay 22 bằng port khác
| Biện pháp | Giảm rủi ro |
|---|---|
| Đổi password mạnh | ~50% |
| Tắt root login | ~70% |
| SSH key only | ~95% |
| SSH key + Fail2Ban + đổi port | ~99.9% |
Lỗi 2: Không cấu hình Firewall
Vấn đề
VPS mới mặc định mở tất cả port (1–65535). Điều này nghĩa là bất kỳ service nào chạy trên server đều có thể truy cập từ internet. MySQL chạy trên port 3306? Ai cũng kết nối được. Redis trên port 6379? Ai cũng đọc được dữ liệu cache.
Câu chuyện thực tế
Một VPS chạy Redis không có password, không có firewall. Hacker kết nối vào Redis, ghi SSH key vào authorized_keys của root thông qua lỗ hổng Redis CONFIG SET. Kết quả: hacker có root access mà không cần brute-force.
Cách khắc phục
# Chỉ mở đúng các port cần thiết
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 2222/tcp # SSH (port tùy chỉnh)
sudo ufw allow 80/tcp # HTTP
sudo ufw allow 443/tcp # HTTPS
sudo ufw enable
Quy tắc vàng: Chỉ mở port nào bạn biết rõ tại sao cần mở. Mọi port khác phải đóng.
| Service | Port mặc định | Nên mở ra internet? |
|---|---|---|
| SSH | 22 (hoặc custom) | Có (hạn chế IP nếu được) |
| HTTP | 80 | Có |
| HTTPS | 443 | Có |
| MySQL | 3306 | KHÔNG — chỉ localhost |
| Redis | 6379 | KHÔNG — chỉ localhost |
| MongoDB | 27017 | KHÔNG — chỉ localhost |
| FTP | 21 | KHÔNG — dùng SFTP thay thế |
| phpMyAdmin | 8080 | KHÔNG — dùng SSH tunnel |
Lỗi 3: Chạy mọi thứ bằng quyền root
Vấn đề
Nhiều người cài website, database, và tất cả service đều chạy bằng root. Lý do: “đỡ phải chmod, chown cho mệt”.
Hậu quả: Nếu website có lỗ hổng (WordPress plugin outdated, SQL injection), hacker exploit lỗ hổng đó → truy cập shell với quyền root → toàn quyền trên server.
Nguyên tắc Least Privilege
Mỗi service chỉ nên có đúng quyền tối thiểu cần thiết:
# Website chạy bằng user www-data
sudo chown -R www-data:www-data /var/www/website
sudo chmod -R 755 /var/www/website
sudo chmod -R 644 /var/www/website/*.php
# Database chạy bằng user mysql
# (MariaDB/MySQL tự tạo user này khi cài)
# Không cho www-data sudo
# Không cho www-data viết vào thư mục system
Phân quyền đúng cho website
| Thư mục/File | Quyền | Owner | Ghi chú |
|---|---|---|---|
| /var/www/website/ | 755 | www-data:www-data | Thư mục gốc |
| Thư mục con | 755 | www-data:www-data | Đọc + thực thi |
| File PHP/HTML | 644 | www-data:www-data | Đọc only |
| wp-config.php | 600 | www-data:www-data | Nhạy cảm |
| uploads/ | 755 | www-data:www-data | Cho phép upload |
| .env | 600 | www-data:www-data | Không để trong webroot |
Lỗi 4: Không cập nhật phần mềm
Vấn đề
“Cài xong chạy được rồi, đừng update nữa kẻo hỏng” — tâm lý phổ biến nhưng cực kỳ nguy hiểm.
Thống kê: 60% các cuộc tấn công VPS khai thác lỗ hổng đã có bản vá (known vulnerabilities). Hacker không cần tìm lỗi mới — họ chỉ cần scan VPS nào chưa update và dùng exploit công khai.
Ví dụ thực tế
- Log4j (2021): Lỗ hổng nghiêm trọng trong Java. Bản vá ra trong 24 giờ, nhưng 6 tháng sau vẫn có 30% server chưa update.
- WordPress plugin vulnerabilities: Mỗi tháng phát hiện 50–100 lỗ hổng mới trong WordPress plugins. Plugin không update = mời hacker vào.
- OpenSSL Heartbleed: Lỗ hổng cho phép đọc memory của server. 3 năm sau khi có bản vá, vẫn có 200.000+ server chưa patch.
Cách khắc phục
# Bật tự động cập nhật bảo mật
sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure -plow unattended-upgrades
# Kiểm tra cập nhật thủ công hàng tuần
sudo apt update && sudo apt list --upgradable
# Cập nhật và restart nếu cần
sudo apt upgrade -y
Lịch update khuyến nghị:
| Loại update | Tần suất | Tự động? |
|---|---|---|
| Security patches | Ngay lập tức | Có (unattended-upgrades) |
| Package updates | Hàng tuần | Không (kiểm tra trước) |
| Kernel updates | Hàng tháng | Không (cần reboot) |
| PHP/MySQL major | Mỗi 6 tháng | Không (cần test kỹ) |
Lỗi 5: Không có Backup (hoặc backup sai)
Vấn đề
Có 3 trường hợp:
- Không backup: “VPS mạnh, không hỏng đâu” → Khi bị hack, mất sạch
- Backup trên cùng VPS: Backup lưu trong
/opt/backup/trên cùng server → Hacker xóa cả backup - Backup nhưng không test restore: Backup chạy hàng ngày nhưng chưa bao giờ thử restore → Đến lúc cần mới biết backup file bị lỗi
Cách backup đúng: Quy tắc 3-2-1
- 3 bản copy dữ liệu
- 2 loại media khác nhau (VPS + cloud storage)
- 1 bản offsite (ngoài server, ngoài datacenter)
Setup backup offsite
# Cài rclone để sync backup lên cloud
curl https://rclone.org/install.sh | sudo bash
# Cấu hình rclone với Google Drive hoặc S3
rclone config
# Script backup + sync
#!/bin/bash
DATE=$(date +%Y%m%d)
# Backup database
mysqldump -u user -p'password' db_name | gzip > /opt/backup/db_$DATE.sql.gz
# Backup files
tar czf /opt/backup/files_$DATE.tar.gz /var/www/
# Sync lên cloud
rclone sync /opt/backup/ remote:vps-backup/
# Giữ 30 bản local, 90 bản trên cloud
find /opt/backup/ -mtime +30 -delete
Test restore hàng tháng
Tạo lịch test restore backup mỗi tháng 1 lần:
- Tạo VPS test tạm (DigitalOcean hourly billing ~2.000 VND/giờ)
- Restore backup lên VPS test
- Kiểm tra website chạy đúng
- Xóa VPS test
Chi phí: ~10.000 VND/lần test. Giá trị: Vô giá.
Checklist bảo mật VPS — Sau khi đọc bài này
| # | Hạng mục | Ưu tiên | Thời gian |
|---|---|---|---|
| 1 | Tắt root login, dùng SSH key | Cao | 15 phút |
| 2 | Cấu hình UFW firewall | Cao | 10 phút |
| 3 | Cài Fail2Ban | Cao | 5 phút |
| 4 | Tạo user riêng, không dùng root | Cao | 10 phút |
| 5 | Bật automatic security updates | Cao | 5 phút |
| 6 | Setup backup offsite | Cao | 30 phút |
| 7 | Đổi SSH port | Trung bình | 5 phút |
| 8 | Cấu hình PHP/MySQL security | Trung bình | 20 phút |
| 9 | Cài ClamAV antivirus | Thấp | 10 phút |
| 10 | Setup monitoring + alerting | Trung bình | 30 phút |
Dấu hiệu VPS đã bị hack
Nếu bạn thấy một trong các dấu hiệu sau, VPS có thể đã bị compromise:
- CPU luôn 100% — crypto miner đang chạy
- Tài khoản lạ trong /etc/passwd — hacker tạo backdoor user
- Cronjob lạ (
crontab -lcho thấy script không quen) - Outbound traffic bất thường — server đang gửi spam hoặc tham gia DDoS
- File lạ trong webroot — shell upload, webshell
- Log bị xóa — hacker xóa dấu vết
- Thời gian file hệ thống bị thay đổi — rootkit
Khi phát hiện bị hack, làm gì?
- Không tắt server — giữ evidence
- Snapshot server — tạo bản copy để phân tích
- Kiểm tra backup — xác nhận backup sạch chưa bị nhiễm
- Tạo VPS mới — cài lại từ đầu (KHÔNG cố “dọn dẹp” VPS bị hack)
- Restore từ backup sạch — backup trước thời điểm bị hack
- Đổi tất cả password — database, SSH, admin panel, email
- Thông báo khách hàng — nếu dữ liệu khách hàng bị ảnh hưởng
FAQ — Câu hỏi thường gặp
VPS nào dễ bị hack nhất?
VPS chạy hệ điều hành cũ (Ubuntu 16.04, CentOS 6), không update, dùng password đăng nhập root, không có firewall. Nền tảng VPS không ảnh hưởng — DigitalOcean, Vultr, AWS đều an toàn ngang nhau. Vấn đề nằm ở cách bạn cấu hình, không phải nhà cung cấp.
VPS bị hack có lấy lại được không?
Nếu có backup sạch: Có, tạo VPS mới và restore. Nếu không có backup: Rất khó, có thể thuê chuyên gia forensics nhưng tốn 20–100 triệu VND và không đảm bảo phục hồi 100%. Bài học: Luôn có backup offsite.
Tôi không biết Linux, làm sao bảo mật VPS?
Hai lựa chọn: (1) Dùng managed VPS — nhà cung cấp lo bảo mật; (2) Thuê dịch vụ quản lý VPS chuyên nghiệp. Trinh Digital cung cấp dịch vụ quản lý VPS với monitoring 24/7, tự động vá lỗ hổng, và backup offsite hàng ngày.
Kết luận
VPS bị hack không phải do “xui” — 99% là do lỗi cấu hình có thể phòng tránh. 5 lỗi trong bài viết này chiếm 90% nguyên nhân VPS bị hack. Fix 5 lỗi này, bạn đã an toàn hơn 90% VPS trên internet.
Nếu bạn đang lo lắng về bảo mật VPS hoặc cần audit VPS hiện tại, hãy liên hệ Trinh Digital để được đánh giá miễn phí.