Cách chống DDoS cho VPS: phòng theo từng lớp và xử lý khi bị tấn công

Chống DDoS cho VPS là chặn lưu lượng tấn công trước khi nó làm nghẽn đường mạng hoặc làm cạn tài nguyên máy chủ. Một VPS tự cấu hình chỉ xử lý được tấn công nhỏ ở tầng ứng dụng và SYN flood. Tấn công làm đầy băng thông phải được lọc ở phía trước VPS: hệ thống của nhà cung cấp hoặc một dịch vụ proxy như Cloudflare.

Vì vậy một máy chủ ảo VPS cần được phòng theo ba lớp: nhà cung cấp, CDN hoặc reverse proxy, rồi mới đến cấu hình máy chủ. Lệnh mẫu dùng Ubuntu 24.04 và Nginx. Cơ chế tấn công: xem DDoS là gì; các rủi ro khác ngoài DDoS: bảo mật VPS.

VPS chống DDoS (VPS anti DDoS) là gì?

VPS chống DDoS là VPS mà nhà cung cấp lọc lưu lượng tấn công ở tầng mạng trước khi lưu lượng đó tới VPS, thường qua trung tâm lọc (scrubbing) hoặc thiết bị lọc ở biên mạng. Các nhà cung cấp khác nhau ở ngưỡng lọc, loại tấn công được xử lý và cách phản ứng khi vượt ngưỡng.

Cụm “có chống DDoS” không cho biết mức bảo vệ, nên hãy hỏi rõ bốn điều:

• Lọc ở lớp nào: chỉ tầng mạng (L3/L4: UDP flood, SYN flood, amplification) hay cả tầng ứng dụng (L7: HTTP flood)?
• Ngưỡng: lọc được bao nhiêu Gbps và bao nhiêu gói mỗi giây (pps), vượt có tính phí không? Tấn công gói nhỏ có thể làm nghẽn thiết bị mạng trước khi chạm ngưỡng Gbps.
• Khi vượt ngưỡng: có “null-route” (chặn mọi lưu lượng tới IP bị tấn công) không? Khi đó VPS vẫn chạy nhưng không ai truy cập được.
• Tự động hay thủ công: lọc luôn bật (always-on), chỉ bật khi phát hiện tấn công (on-demand) hay phải mở ticket? Với on-demand, VPS chịu trận trong lúc chờ phát hiện.

Trang VPS NVMe tại Tino ghi Tino áp dụng “hệ thống chống tấn công DDoS, tường lửa bảo mật” (kiểm tra ngày 21/10/2026) nhưng không nêu ngưỡng hay loại tấn công, nên hãy hỏi bộ phận hỗ trợ bốn điểm trên.

VPS thường bị DDoS theo những kiểu nào?

Các cuộc tấn công DDoS vào VPS thường do botnet (mạng thiết bị bị chiếm quyền) gửi từ hàng nghìn IP, và chia thành ba nhóm theo mục tiêu: làm đầy băng thông, làm cạn bảng kết nối của hệ điều hành, hoặc làm quá tải ứng dụng web. Mỗi nhóm cần một lớp phòng thủ khác nhau.

Theo tài liệu DDoS Protection của Cloudflare, lớp bảo vệ DDoS tiêu chuẩn xử lý cả L3/4 và L7 trên mọi gói, kể cả gói Free, với điều kiện lưu lượng đi qua Cloudflare.

Làm sao biết VPS đang bị DDoS?

Dấu hiệu rõ nhất là website chậm hoặc không truy cập được trong khi CPU, RAM của ứng dụng không đổi. Đi kèm thường là băng thông vào tăng vọt không khớp lượng khách thật, ping mất gói, nhiều kết nối SYN-RECV, log web server đầy request lặp lại từ nhiều IP lạ, hoặc nhà cung cấp báo IP bị null-route.

Xác nhận nhanh bằng các lệnh dưới (log Nginx mặc định trên Ubuntu):

# Tổng quan kết nối TCP theo trạng thái
ss -s

# Số kết nối đang chờ bắt tay (SYN-RECV); hàng trăm, hàng nghìn là bất thường
ss -n state syn-recv | wc -l

# Kernel có cảnh báo SYN flood không
sudo journalctl -k --since "1 hour ago" | grep -i "syn flooding"

# 10 IP gửi nhiều request nhất trong log truy cập Nginx
sudo awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

# 10 URL bị gọi nhiều nhất
sudo awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

# Lưu lượng vào/ra của card mạng (chạy 2 lần cách nhau vài giây để so sánh)
ip -s link show

Đường truyền đã đầy thì SSH cũng chập chờn: vào máy bằng console của nhà cung cấp (ví dụ Web Console noVNC) và báo nhà cung cấp ngay.

Cách chống DDoS cho VPS theo từng lớp

Chống DDoS cho VPS hiệu quả khi kết hợp ba lớp: nhà cung cấp lọc tấn công lớn ở tầng mạng, CDN hoặc reverse proxy che IP thật và lọc tấn công HTTP, còn máy chủ tự giới hạn request và kết nối. Lọc càng sớm, VPS càng ít phải gánh.

Lớp 1: Hạ tầng nhà cung cấp và mạng

Lớp nhà cung cấp là lớp duy nhất xử lý được tấn công làm đầy băng thông, vì lưu lượng bị lọc trước khi vào đường truyền của VPS. Lưu sẵn kênh hỗ trợ và thông tin VPS (IP, mã dịch vụ) để báo nhanh, và dùng tường lửa mạng của nhà cung cấp (nếu có) để đóng cổng không dùng.

Lớp 2: Đặt website sau Cloudflare hoặc CDN có lọc DDoS

Cloudflare là reverse proxy: khách kết nối tới Cloudflare, Cloudflare lọc rồi mới chuyển request hợp lệ về VPS. Khi bản ghi DNS bật proxy (đám mây màu cam), người tra cứu tên miền chỉ thấy IP của Cloudflare. Lớp này chỉ có tác dụng khi kẻ tấn công không biết IP gốc; IP lộ qua lịch sử DNS hoặc mail server thì tấn công gửi thẳng vào VPS (Cloudflare docs). Xem thêm Cloudflare là gì và CDN là gì.

• Bật proxy cho mọi bản ghi web (A, AAAA, CNAME của tên miền chính và www); bản ghi đám mây xám trả về IP thật.
• Không gửi mail từ IP của website, vì bản ghi MX dễ làm lộ IP gốc. IP cũ đã lộ thì đổi IP, vì lịch sử DNS vẫn lưu.
• Chỉ nhận lưu lượng web từ IP Cloudflare ở VPS. Danh sách tại cloudflare.com/ips thay đổi theo thời gian, cần cập nhật định kỳ.
• Chỉ cổng HTTP/HTTPS được proxy: Cloudflare proxy các cổng web như 80, 443, 8080, 8443… (danh sách cổng). SSH, game server, VPN hay mail không đi qua proxy; muốn bảo vệ các dịch vụ này cần Cloudflare Spectrum (có trên gói trả phí với một số giao thức; ứng dụng TCP/UDP tuỳ ý cần gói Enterprise) hoặc dịch vụ lọc của nhà cung cấp.

Lệnh UFW dưới chỉ cho dải IP Cloudflare vào cổng 80/443. Chạy sau khi đã mở SSH và website đã chạy qua Cloudflare. Chỉ xoá quy tắc mở 80/443 cho mọi nơi (“Nginx Full” hoặc 80/tcp, 443/tcp) khi đã thấy đủ quy tắc “cloudflare”, nếu không website bị chặn hoàn toàn.

# 1. Tải danh sách dải IP Cloudflare về file và kiểm tra
{ curl -fsS https://www.cloudflare.com/ips-v4; echo; curl -fsS https://www.cloudflare.com/ips-v6; echo; } \
  | grep -E '^[0-9a-f:.]+/[0-9]+$' > /tmp/cf-ips
wc -l < /tmp/cf-ips      # phải có khoảng 20 dòng; nếu ra 0 thì DỪNG, không làm tiếp

# 2. Thêm quy tắc cho từng dải
for ip in $(cat /tmp/cf-ips); do
  sudo ufw allow proto tcp from "$ip" to any port 80,443 comment "cloudflare"
done

# 3. Thấy đủ quy tắc "cloudflare" rồi mới xoá quy tắc mở 80/443 cho mọi IP
sudo ufw status numbered
sudo ufw delete allow 'Nginx Full'

Nginx chạy trong Docker và publish cổng 80/443 thì quy tắc UFW không áp dụng cho các cổng đó (xem FAQ).

Sau Cloudflare, log Nginx ghi IP Cloudflare thay vì IP khách. Lấy lại IP thật bằng ngx_http_realip_module với header CF-Connecting-IP (Cloudflare docs) trước khi bật rate limit và Fail2ban, nếu không sẽ chặn nhầm Cloudflare.

# /etc/nginx/conf.d/cloudflare-realip.conf
# Mỗi dải IP Cloudflare một dòng set_real_ip_from (lấy từ cloudflare.com/ips)
set_real_ip_from 173.245.48.0/20;
# ... các dải còn lại ...
real_ip_header CF-Connecting-IP;

Lớp 3: Cấu hình máy chủ (Nginx, kernel, Fail2ban)

Cấu hình trên VPS giúp chống HTTP flood nhỏ, Slowloris và SYN flood mức thấp khi lớp phía trước để lọt; nó không cứu được VPS khi đường truyền đã đầy.

Giới hạn tốc độ request trong Nginx. limit_req giới hạn số request mỗi giây theo IP; limit_conn giới hạn số kết nối đồng thời (tài liệu nginx). Vai trò của Nginx: xem Nginx là gì. Đổi mã từ chối mặc định 503 sang 429 để dễ phân biệt trong log. Áp mức chặt cho URL tốn tài nguyên, không áp cho file tĩnh.

# Trong khối http { } (ví dụ /etc/nginx/conf.d/limit.conf)
limit_req_zone  $binary_remote_addr zone=dong:10m rate=5r/s;
limit_req_zone  $binary_remote_addr zone=dangnhap:10m rate=1r/s;
limit_conn_zone $binary_remote_addr zone=ketnoi:10m;
limit_req_status 429;
limit_conn_status 429;

# Giảm thời gian chờ để chống Slowloris (mặc định 60s)
client_header_timeout 10s;
client_body_timeout   10s;

# Trong khối server { } của website
limit_conn ketnoi 20;

location = /wp-login.php {
    limit_req zone=dangnhap burst=3 nodelay;
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}

location ~ \.php$ {
    limit_req zone=dong burst=20 nodelay;
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}

# Kiểm tra rồi nạp lại
sudo nginx -t && sudo systemctl reload nginx

Các số rate, burst, limit_conn là điểm khởi đầu: quá chặt sẽ chặn nhầm người dùng chung IP (văn phòng, mạng di động), nên theo dõi log vài ngày rồi chỉnh. Timeout mặc định theo ngx_http_core_module; socket PHP-FPM tuỳ phiên bản PHP.

Bật SYN cookies trong kernel. SYN cookies giúp kernel tiếp tục nhận kết nối hợp lệ khi hàng đợi SYN bị đầy. Theo tài liệu kernel Linux, tcp_syncookies mặc định là 1. Kiểm tra lại vì một số image VPS đã chỉnh; có thể tăng hàng đợi và giảm số lần gửi lại SYN-ACK (mặc định 5).

# Xem giá trị hiện tại
sysctl net.ipv4.tcp_syncookies net.ipv4.tcp_max_syn_backlog net.ipv4.tcp_synack_retries

# Ghi cấu hình riêng rồi nạp
sudo tee /etc/sysctl.d/90-chong-syn-flood.conf > /dev/null <<'EOF'
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_synack_retries = 2
EOF
sudo sysctl --system

Tự chặn IP vượt giới hạn bằng Fail2ban. Bộ lọc có sẵn nginx-limit-req đọc log lỗi của Nginx và khoá IP bị limit_req từ chối nhiều lần (Fail2ban GitHub). Cài Fail2ban và jail SSH: xem bảo mật VPS Ubuntu.

Ubuntu 24.04 đặt Fail2ban đọc journal mặc định (backend = systemd). Jail đọc file log như Nginx phải ghi backend = auto kèm logpath, nếu không jail báo đang chạy nhưng không bao giờ chặn.

sudo tee /etc/fail2ban/jail.d/nginx-limit-req.local > /dev/null <<'EOF'
[nginx-limit-req]
enabled  = true
# Ubuntu 24.04 đặt backend = systemd mặc định; Nginx ghi log ra file nên jail này phải đọc file
backend  = auto
port     = http,https
logpath  = /var/log/nginx/error.log
findtime = 10m
maxretry = 10
bantime  = 1h
EOF
sudo fail2ban-client -t && sudo systemctl restart fail2ban
# Dòng "File list" phải có /var/log/nginx/error.log
sudo fail2ban-client status nginx-limit-req

Website sau Cloudflare thì Fail2ban chặn ở tường lửa VPS không có tác dụng, vì kết nối tới từ IP Cloudflare; hãy chặn bằng quy tắc WAF hoặc rate limiting trên Cloudflare.

Giới hạn tần suất kết nối SSH. UFW là công cụ quản lý tường lửa trên Ubuntu; ufw limit từ chối IP mở từ 6 kết nối trở lên trong 30 giây (man ufw), giúp giảm dò mật khẩu chứ không chống DDoS băng thông. Đã đổi cổng SSH thì dùng sudo ufw limit 2222/tcp (thay bằng cổng của bạn).

sudo ufw limit OpenSSH
sudo ufw status

VPS đang bị DDoS: xử lý theo thứ tự nào?

Khi VPS đang bị DDoS, việc đầu tiên là xác nhận đúng là tấn công và báo nhà cung cấp, vì chỉ họ chặn được lưu lượng trước khi vào VPS. Sau đó mới bật phòng thủ trên Cloudflare, chặn tạm trên máy chủ và ghi lại bằng chứng.

• Xác nhận: chạy các lệnh ở phần dấu hiệu; loại trừ bot, plugin lỗi, khách tăng thật.
• Báo nhà cung cấp: gửi IP, thời điểm, loại lưu lượng (UDP, SYN, HTTP), ảnh biểu đồ băng thông; hỏi IP có bị null-route không.
• Bật Under Attack mode nếu web đã sau Cloudflare; có thể chỉ áp cho đường dẫn bị nhắm. Chế độ này kiểm tra thêm trình duyệt để lọc L7 và hiện trang chờ, nên Cloudflare coi là biện pháp cuối (Cloudflare docs).
• Chặn tạm trên VPS: siết limit_req cho URL bị nhắm, chặn IP nổi bật (sudo ufw insert 1 deny from IP_TAN_CONG), tắt tạm tìm kiếm, xmlrpc.php.
• Đổi IP nếu IP gốc đã lộ: chỉ khai báo IP mới ở bản ghi có bật proxy, không gửi mail từ IP đó.
• Rà soát sau sự cố: lưu log, tìm chỗ lộ IP gốc, đóng cổng thừa, chỉnh ngưỡng rate limit.

Đừng khởi động lại VPS liên tục hay nâng cấu hình khi bị tấn công băng thông: tài nguyên máy chủ không phải điểm nghẽn.

Mỗi biện pháp chống DDoS có giới hạn gì?

Không biện pháp đơn lẻ nào chặn được mọi kiểu DDoS. Mỗi biện pháp chỉ xử lý một nhóm tấn công và đa số phụ thuộc vào lớp phía trước: lọc trên VPS vô ích khi đường truyền đã đầy, Cloudflare vô ích khi IP gốc đã lộ.

DDoS làm gián đoạn dịch vụ, không trực tiếp đọc hay xoá dữ liệu. Thấy tiến trình hoặc tài khoản lạ là sự cố xâm nhập: xem dấu hiệu và cách xử lý VPS bị xâm nhập và khôi phục từ bản sao lưu VPS.

Khi nào cần dịch vụ chống DDoS trả phí, khi nào chưa cần?

Website nhỏ, blog, trang giới thiệu doanh nghiệp chịu được gián đoạn vài giờ thường chưa cần gói chống DDoS trả phí riêng: lớp lọc sẵn có của nhà cung cấp, Cloudflare gói Free và Nginx cơ bản đã đủ, ưu tiên ẩn IP gốc.

Nên cân nhắc gói trả phí cho game server, dịch vụ ngoài HTTP, thương mại điện tử mùa cao điểm, dịch vụ đã bị tấn công lặp lại hoặc bị tống tiền bằng DDoS. Hỏi rõ ngưỡng lọc, cam kết bằng văn bản và phí vượt ngưỡng.

Mới bắt đầu quản trị máy chủ: xem hướng dẫn sử dụng VPS. Khi chọn gói VPS tại Tino, hỏi bộ phận hỗ trợ 24/7 về phạm vi chống DDoS trước khi đặt mua.

Câu hỏi thường gặp về chống DDoS cho VPS