T
Trinh Digital
Xây dựng Hệ thống

VPS bị hack sau 3 ngày cài: 5 lỗi bảo mật ai cũng mắc

Trinh Digital · · 11 phút đọc

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ápGiả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.

ServicePort mặc địnhNên mở ra internet?
SSH22 (hoặc custom)Có (hạn chế IP nếu được)
HTTP80
HTTPS443
MySQL3306KHÔNG — chỉ localhost
Redis6379KHÔNG — chỉ localhost
MongoDB27017KHÔNG — chỉ localhost
FTP21KHÔNG — dùng SFTP thay thế
phpMyAdmin8080KHÔ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/FileQuyềnOwnerGhi chú
/var/www/website/755www-data:www-dataThư mục gốc
Thư mục con755www-data:www-dataĐọc + thực thi
File PHP/HTML644www-data:www-dataĐọc only
wp-config.php600www-data:www-dataNhạy cảm
uploads/755www-data:www-dataCho phép upload
.env600www-data:www-dataKhô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 updateTần suấtTự động?
Security patchesNgay lập tứcCó (unattended-upgrades)
Package updatesHàng tuầnKhông (kiểm tra trước)
Kernel updatesHàng thángKhông (cần reboot)
PHP/MySQL majorMỗi 6 thángKhông (cần test kỹ)

Lỗi 5: Không có Backup (hoặc backup sai)

Vấn đề

Có 3 trường hợp:

  1. Không backup: “VPS mạnh, không hỏng đâu” → Khi bị hack, mất sạch
  2. Backup trên cùng VPS: Backup lưu trong /opt/backup/ trên cùng server → Hacker xóa cả backup
  3. 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:

  1. Tạo VPS test tạm (DigitalOcean hourly billing ~2.000 VND/giờ)
  2. Restore backup lên VPS test
  3. Kiểm tra website chạy đúng
  4. 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ênThời gian
1Tắt root login, dùng SSH keyCao15 phút
2Cấu hình UFW firewallCao10 phút
3Cài Fail2BanCao5 phút
4Tạo user riêng, không dùng rootCao10 phút
5Bật automatic security updatesCao5 phút
6Setup backup offsiteCao30 phút
7Đổi SSH portTrung bình5 phút
8Cấu hình PHP/MySQL securityTrung bình20 phút
9Cài ClamAV antivirusThấp10 phút
10Setup monitoring + alertingTrung bình30 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:

  1. CPU luôn 100% — crypto miner đang chạy
  2. Tài khoản lạ trong /etc/passwd — hacker tạo backdoor user
  3. Cronjob lạ (crontab -l cho thấy script không quen)
  4. Outbound traffic bất thường — server đang gửi spam hoặc tham gia DDoS
  5. File lạ trong webroot — shell upload, webshell
  6. Log bị xóa — hacker xóa dấu vết
  7. Thời gian file hệ thống bị thay đổi — rootkit

Khi phát hiện bị hack, làm gì?

  1. Không tắt server — giữ evidence
  2. Snapshot server — tạo bản copy để phân tích
  3. Kiểm tra backup — xác nhận backup sạch chưa bị nhiễm
  4. Tạo VPS mới — cài lại từ đầu (KHÔNG cố “dọn dẹp” VPS bị hack)
  5. Restore từ backup sạch — backup trước thời điểm bị hack
  6. Đổi tất cả password — database, SSH, admin panel, email
  7. 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í.

#security#VPS#bảo mật#hack
Chia sẻ: Z

Sẵn sàng chuyển đổi số cùng Trinh Digital?

Liên hệ ngay để nhận tư vấn miễn phí. Đội ngũ chuyên gia sẽ phân tích nhu cầu và đề xuất giải pháp tối ưu.

Zalo