12+ cách kiểm tra VPS có đang bị DDoS hay không | Check DDoS

dataonline

2 tháng trước

Cách kiểm tra VPS có đang bị DDoS hay không, Bạn có thể Check DDoS nhanh bằng các cách dưới đây. Nếu hệ thống của Bạn có Firewall cứng, thì việc check trên firewall sẽ hiệu quả hơn rất nhiều so với check trên OS, ngoài ra có thể xử lý dứt điểm tấn công từ trên firewall. Đừng quên, nhà cung cấp dịch vụ có thể hỗ trợ được Bạn rất nhiều trong trường hợp này. Nếu máy chủ của Bạn đang gặp vấn đề, đừng ngần ngại liên hệ DataOnline, với đội ngũ kỹ thuật giàu kinh nghiệm, chúng tôi có thể hỗ trợ Bạn nhanh chóng.

DataOnline cung cấp dịch vụ

VPS giá rẻ

, chống DDoS L3, L4 và cả L7 bảo vệ cho Website.

Khi VPS đột nhiên chậm, website không truy cập được, ping tăng cao, SSH lag hoặc CPU tăng 100%, một trong những nguyên nhân thường được nghĩ đến là DDoS.

Tuy nhiên, không phải mọi trường hợp server chậm đều là DDoS.

Website có thể chậm do:

CPU quá tải.
RAM thiếu.
Disk I/O cao.
Database quá tải.
Webserver tạo quá nhiều process.
Một ứng dụng bị lỗi.
Network interface bị nghẽn.
Nhà cung cấp VPS bị sự cố mạng.
Hoặc thực sự đang có một cuộc tấn công DDoS.

Vì vậy, thay vì chỉ nhìn CPU hoặc ping rồi kết luận “bị DDoS”, cần kiểm tra từ nhiều lớp:

Internet
   |
   v
Network / Upstream
   |
   v
NIC / Interface
   |
   v
Kernel
   |
   v
TCP / UDP Connections
   |
   v
Firewall
   |
   v
Webserver / Application
   |
   v
CPU / RAM / Disk

Trong bài viết này, DataOnline hướng dẫn cách kiểm tra DDoS trên VPS Linux và Windows, đồng thời hướng dẫn cách xác định:

VPS có thực sự bị DDoS hay không.
DDoS đang đánh vào port nào.
IP nào tạo nhiều connection.
Traffic có bất thường không.
TCP SYN flood có xảy ra không.
UDP flood có xảy ra không.
NIC có bị drop packet không.
CPU có bị network interrupt làm quá tải không.
Website bị quá tải hay network bị tấn công.
Khi nào cần chặn IP.
Khi nào không nên chặn IP.
Khi nào phải yêu cầu nhà cung cấp xử lý DDoS ở upstream.

Mục lục nội dung

Toggle

1. DDoS là gì?

DDoS – Distributed Denial of Service là hình thức sử dụng nhiều nguồn khác nhau tạo ra lượng traffic hoặc request lớn nhằm làm dịch vụ không thể phục vụ người dùng bình thường.

Mục tiêu có thể là:

IP VPS
IP Server
Website
API
Game Server
DNS Server
Mail Server
TCP/UDP Service

Có thể chia DDoS thành một số nhóm chính.

Volumetric DDoS

Tập trung tạo lưu lượng rất lớn:

Gbps
Mbps
Packets/sec

Ví dụ:

500 Mbps
2 Gbps
10 Gbps

Loại này thường làm nghẽn đường truyền trước khi traffic tới VPS.

Protocol / Network DDoS

Tấn công vào tầng network/protocol.

Ví dụ:

SYN Flood
ACK Flood
UDP Flood
ICMP Flood

Application Layer DDoS

Tấn công vào ứng dụng.

Ví dụ:

HTTP Flood
HTTPS Flood
API Request Flood
WordPress Login Flood
Search Request Flood

Điểm quan trọng:

Một server có thể bị DDoS nhưng traffic nhìn thấy bên trong VPS lại không quá lớn nếu nhà cung cấp đã lọc một phần traffic ở upstream.

Ngược lại, server có thể nhận traffic không quá lớn nhưng packet rate hoặc connection rate cực cao, khiến CPU/kernel/webserver quá tải.

2. Dấu hiệu VPS có thể đang bị DDoS

Một hoặc nhiều dấu hiệu sau có thể xuất hiện:

Dấu hiệu network

Traffic tăng bất thường
Packet/s tăng mạnh
RX tăng cao
TX tăng cao
Packet dropped tăng
Network interface gần 100%

Dấu hiệu TCP

SYN_RECV tăng cao
Connection tăng đột biến
TIME_WAIT tăng mạnh
Connection reset tăng

Dấu hiệu ứng dụng

Apache/Nginx CPU cao
PHP-FPM process tăng
MySQL connection tăng
Load Average tăng
HTTP request tăng bất thường

Dấu hiệu người dùng

Website timeout
SSH lag
RDP lag
Ping cao
Packet loss
Không truy cập được DirectAdmin

Nhưng cần nhớ:

Một dấu hiệu đơn lẻ không đủ để kết luận DDoS.

3. Cách 1 – Kiểm tra băng thông VPS

Trên Linux, có thể sử dụng:

ip -s link

Hoặc:

ip -s -s link

Ví dụ:

RX: bytes  packets  errors  dropped
    123456  12345    0       0

TX: bytes  packets  errors  dropped
    456789  67890    0       0

Linux kernel cung cấp interface statistics bao gồm bytes, packets, errors và dropped packets; ip -s link là một trong những cách tiêu chuẩn để xem các số liệu này.

Tìm interface:

ip addr

Ví dụ:

eth0
ens3
ens18
bond0

Sau đó:

ip -s link show dev eth0

4. Cách 2 – Theo dõi traffic realtime bằng sar

Cài sysstat:

apt update
apt install sysstat -y

Chạy:

sar -n DEV 1

Ví dụ:

IFACE   rxpck/s   txpck/s   rxkB/s   txkB/s
eth0    125000    3500      85000    1200

Các thông số quan trọng:

rxpck/s = packet nhận mỗi giây
txpck/s = packet gửi mỗi giây
rxkB/s  = KB nhận mỗi giây
txkB/s  = KB gửi mỗi giây

Đừng chỉ nhìn Mbps

Ví dụ:

Server A:

500 Mbps
50,000 packet/s

Server B:

500 Mbps
500,000 packet/s

Hai server có cùng bandwidth nhưng Server B có thể gây áp lực CPU/kernel/NIC lớn hơn đáng kể.

Do đó khi kiểm tra DDoS nên theo dõi cả bandwidth và packets/sec.

5. Cách 3 – Kiểm tra connection bằng ss

Đây là một trong những lệnh quan trọng nhất trên Linux.

ss -s

Ví dụ:

TCP:
    1500 established
    4500 closed
    12000 orphaned
    18000 timewait
    5000 synrecv

Nếu bình thường chỉ có vài chục hoặc vài trăm connection nhưng đột nhiên:

SYN-RECV = 50,000

thì cần điều tra ngay.

6. Cách 4 – Kiểm tra SYN_RECV

Chạy:

ss -ant state syn-recv

Đếm:

ss -ant state syn-recv | wc -l

Ví dụ:

Đây là dấu hiệu rất đáng chú ý.

Có thể kiểm tra theo IP:

ss -ant state syn-recv | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head

Nếu thấy:

10000 203.0.113.10
9000  198.51.100.20
8000  192.0.2.50

có thể đang có lượng SYN bất thường.

Tuy nhiên:

SYN_RECV cao không tự động có nghĩa là DDoS.

Có thể là traffic thật, application/backend chậm hoặc một vấn đề TCP khác.

7. Cách 5 – Tìm IP tạo nhiều connection nhất

Một cách nhanh:

ss -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -20

Ví dụ:

15000 203.0.113.10
12000 198.51.100.20
8000  192.0.2.100

Có thể sử dụng:

ss -nt | awk '{print $5}' \
| sed 's/:[0-9]*$//' \
| sort | uniq -c | sort -nr | head -20

Mục đích là tìm:

Top source IP
Top connection
Top offender

8. Cách 6 – Kiểm tra port nào đang bị đánh

Không chỉ cần biết “có DDoS”.

Cần biết:

DDoS đang đánh vào port nào?

Ví dụ:

ss -ant | awk '{print $4}' | sed 's/.*://' | sort | uniq -c | sort -nr

Có thể thấy:

Nếu server web bình thường chỉ có vài trăm connection nhưng:

80  = 50,000
443 = 35,000

thì cần điều tra HTTP/HTTPS traffic.

Nếu:

22 = 30,000

thì cần kiểm tra SSH brute-force hoặc TCP flood.

Nếu:

UDP port = rất lớn

có thể liên quan đến UDP flood.

9. Cách 7 – Dùng tcpdump để xem packet thực tế

tcpdump cho phép quan sát packet đang đi qua interface.

Cài:

apt install tcpdump -y

Xem traffic:

tcpdump -ni eth0

Chỉ xem TCP SYN:

tcpdump -ni eth0 'tcp[tcpflags] & tcp-syn != 0'

Chỉ xem HTTP:

tcpdump -ni eth0 port 80

HTTPS:

tcpdump -ni eth0 port 443

UDP:

tcpdump -ni eth0 udp

ICMP:

tcpdump -ni eth0 icmp

10. Cách 8 – Đếm SYN packet

Có thể sử dụng:

tcpdump -ni eth0 'tcp[tcpflags] & tcp-syn != 0' -c 1000

Nếu muốn quan sát trong vài giây:

timeout 10 tcpdump -ni eth0 \
'tcp[tcpflags] & tcp-syn != 0'

Mục tiêu là xác định:

SYN packet/s
Source IP
Destination port
Packet size

Nếu hàng trăm nghìn SYN packet xuất hiện trong thời gian rất ngắn, đây là dấu hiệu cần điều tra sâu.

11. Cách 9 – Kiểm tra packet drop trên NIC

Đây là bước rất quan trọng nhưng thường bị bỏ qua.

Chạy:

ip -s link show eth0

Theo dõi:

RX errors
RX dropped
TX errors
TX dropped

Hoặc:

ethtool -S eth0

Có thể xuất hiện:

rx_dropped
rx_missed_errors
rx_no_buffer
rx_errors

Linux phân biệt statistics ở interface, protocol và driver; ethtool có thể cung cấp các driver-defined statistics chi tiết hơn.

Nếu packet drop tăng nhanh:

RX packets       tăng
RX dropped       tăng mạnh
RX errors        tăng

cần xác định nguyên nhân ở:

NIC
Driver
Kernel
CPU
Virtualization layer
Upstream network

chứ không nên lập tức kết luận là DDoS.

12. Cách 10 – Kiểm tra CPU và Load Average

Chạy:

uptime

hoặc:

top

hoặc:

htop

Quan sát:

load average
CPU usage
system CPU
softirq
iowait

Một dấu hiệu đáng chú ý khi server bị packet flood là CPU si/softirq tăng cao.

Dùng:

top

Nếu thấy:

%Cpu:
us  10
sy  20
ni   0
id  30
wa   0
hi   0
si  40
st   0

thì si cao có thể cho thấy CPU đang dành nhiều thời gian xử lý software interrupt.

Có thể kiểm tra thêm:

cat /proc/softirqs

13. Cách 11 – Kiểm tra network interrupt

Dùng:

cat /proc/interrupts

Hoặc:

grep -i eth /proc/interrupts

Nếu có lượng packet rất lớn, CPU có thể phải xử lý một lượng lớn interrupt từ NIC.

Với server vật lý hoặc VM có workload network cao, nên kiểm tra thêm:

ethtool -l eth0
ethtool -k eth0

và:

ethtool -S eth0

Điều này đặc biệt hữu ích khi nghi ngờ packet-per-second flood thay vì chỉ bandwidth flood.

14. Cách 12 – Kiểm tra bandwidth bằng vnStat

Cài:

apt install vnstat -y

Khởi động:

systemctl enable --now vnstat

Xem:

vnstat

Theo dõi realtime:

vnstat -l

Xem theo ngày:

vnstat -d

Theo tháng:

vnstat -m

vnStat đặc biệt hữu ích để trả lời câu hỏi:

“Traffic hôm nay có bất thường so với những ngày trước không?”

Ví dụ:

Ngày bình thường:
50 GB/day

Ngày hôm nay:
800 GB/day

thì cần điều tra.

15. Cách 13 – Kiểm tra HTTP request

Nếu nghi ngờ HTTP/HTTPS DDoS, cần kiểm tra webserver.

Nginx

Ví dụ:

tail -f /var/log/nginx/access.log

Tìm IP request nhiều:

awk '{print $1}' /var/log/nginx/access.log \
| sort | uniq -c | sort -nr | head -20

Ví dụ:

50000 203.0.113.10
42000 198.51.100.20
35000 192.0.2.50

Đây là dấu hiệu cần điều tra.

16. Kiểm tra URL bị request nhiều nhất

Với Nginx:

awk '{print $7}' /var/log/nginx/access.log \
| sort | uniq -c | sort -nr | head -20

Ví dụ:

100000 /login
85000  /wp-login.php
70000  /api/search
50000  /

Nếu một URL bị request cực lớn:

/api/search

thì có thể là application-layer attack.

17. Kiểm tra HTTP status code

Có thể thống kê:

awk '{print $9}' /var/log/nginx/access.log \
| sort | uniq -c | sort -nr

Ví dụ:

Nếu lượng request tăng mạnh và server liên tục trả:

thì có thể application/backend đang quá tải.

Nhưng điều này cũng không đồng nghĩa với DDoS.

18. Kiểm tra Apache

Nếu sử dụng Apache:

tail -f /var/log/apache2/access.log

Top IP:

awk '{print $1}' /var/log/apache2/access.log \
| sort | uniq -c | sort -nr | head -20

Top URL:

awk '{print $7}' /var/log/apache2/access.log \
| sort | uniq -c | sort -nr | head -20

19. Kiểm tra DirectAdmin

Nếu VPS chạy DirectAdmin, cần kiểm tra đồng thời:

CSF/LFD
Nginx/Apache
PHP-FPM
MySQL/MariaDB
DirectAdmin
Network

Có thể kiểm tra process:

ps aux --sort=-%cpu | head

và:

ps aux --sort=-%mem | head

Kiểm tra connection:

ss -s

Kiểm tra log:

tail -f /var/log/lfd.log

Nếu CSF/LFD đang block hàng loạt IP, đó là thông tin hữu ích để xác định server đang nhận nhiều hành vi bất thường.

20. Cách 14 – Kiểm tra bằng iftop

Cài:

apt install iftop -y

Chạy:

iftop -i eth0

iftop cho phép quan sát:

Source IP
Destination IP
Bandwidth
Traffic direction

Ví dụ:

203.0.113.10  => SERVER   500Mb
198.51.100.20 => SERVER   300Mb
192.0.2.50    => SERVER   200Mb

Nếu có hàng trăm IP cùng tạo traffic, khả năng phân tán nguồn traffic cao hơn.

21. Cách 15 – Kiểm tra bằng nload

Cài:

apt install nload -y

Chạy:

nload eth0

Công cụ này đơn giản nhưng rất hữu ích để quan sát:

Incoming
Outgoing
Current bandwidth
Average bandwidth

22. Cách 16 – Kiểm tra bằng nethogs

Nếu nghi ngờ server đang gửi traffic bất thường thay vì chỉ nhận traffic, dùng:

apt install nethogs -y

Sau đó:

nethogs eth0

Có thể xác định process nào đang sử dụng network.

Ví dụ:

nginx
php-fpm
mysqld
docker
python

Nếu TX bất thường, đây là bước rất hữu ích để xác định process gây traffic.

23. Cách 17 – Kiểm tra UDP traffic

Dùng:

ss -u -a

Hoặc:

tcpdump -ni eth0 udp

Thống kê port:

ss -uan | awk '{print $5}' | sort | uniq -c | sort -nr | head

Nếu server không chạy UDP service nhưng lại nhận lượng UDP traffic lớn, cần điều tra.

24. Cách 18 – Kiểm tra ICMP flood

Theo dõi:

tcpdump -ni eth0 icmp

Hoặc:

sar -n ICMP 1

Nếu ICMP traffic tăng đột biến:

ICMP packets/s

có thể là ICMP flood.

Tuy nhiên:

Không nên block toàn bộ ICMP chỉ vì thấy ICMP traffic.

ICMP vẫn cần thiết cho nhiều hoạt động network như troubleshooting, Path MTU Discovery và các chức năng khác.

25. Kiểm tra DDoS trên Windows Server

Nếu VPS chạy Windows Server, có thể sử dụng các công cụ có sẵn.

Kiểm tra connection bằng netstat

Chạy CMD với quyền Administrator:

netstat -ano

Microsoft cho biết netstat có thể hiển thị TCP connections, port đang listen, Ethernet statistics, routing table và IPv4/IPv6 statistics.

Kiểm tra SYN:

netstat -ano | findstr SYN_RECEIVED

Đếm connection:

netstat -ano | findstr ESTABLISHED

26. Tìm IP tạo nhiều connection trên Windows

PowerShell:

Get-NetTCPConnection |
Group-Object RemoteAddress |
Sort-Object Count -Descending |
Select-Object -First 20

Có thể phát hiện:

IP
Number of connections

Sau đó xác định process:

Get-NetTCPConnection |
Select-Object LocalAddress,LocalPort,RemoteAddress,RemotePort,State,OwningProcess

27. Kiểm tra network bằng Performance Monitor

Windows Server có Performance Monitor.

Mở:

Win + R

Nhập:

perfmon

Các counter đáng quan tâm:

Network Interface
    Bytes Received/sec
    Bytes Sent/sec
    Packets Received/sec
    Packets Sent/sec

TCPv4
    Segments Received/sec
    Segments Sent/sec
    Segments Retransmitted/sec

Processor
    % Processor Time
    Interrupts/sec
    DPCs Queued/sec

Microsoft cũng liệt kê các counter như Bytes Received/sec, Packets Received/sec, Packets Received Discarded, Packets Received Errors, TCP connection failures và resets để theo dõi vấn đề network.

28. Kiểm tra packet drop trên Windows bằng pktmon

Windows Server có sẵn:

pktmon

Microsoft mô tả Pktmon là công cụ network diagnostics có thể:

Packet capture
Packet drop detection
Packet filtering
Packet counting

và đặc biệt hữu ích trong môi trường virtualization.

Kiểm tra:

pktmon list

Có thể dùng:

pktmon filter add -p 80

Sau đó:

pktmon start --etw -m real-time

Khi kiểm tra xong:

pktmon stop

29. Dùng Wireshark để phân tích DDoS

Nếu cần phân tích sâu packet, có thể capture traffic bằng:

tcpdump
Wireshark
pktmon

Một số filter hữu ích trong Wireshark:

tcp.flags.syn == 1

SYN traffic.

udp

UDP traffic.

icmp

ICMP traffic.

tcp.flags.reset == 1

TCP RST.

http.request

HTTP request.

Mục tiêu không phải capture càng nhiều càng tốt mà là tìm:

Source
Destination
Protocol
Port
Packet rate
Packet size
TCP flags
Request pattern

30. Phân biệt DDoS với VPS bị quá tải

Đây là phần quan trọng nhất.

Trường hợp 1: CPU cao nhưng network bình thường

Ví dụ:

CPU = 100%
RX = 20 Mbps
Packets = bình thường

Có thể là:

PHP
MySQL
WordPress
Application
Cron
Backup

Không nên kết luận DDoS.

Trường hợp 2: Network cao + packet cao + connection cao

Ví dụ:

RX = 950 Mbps
Packets = 800k/s
SYN_RECV = 50,000
CPU softirq = cao

Đây là dấu hiệu mạnh của network attack/flood.

Trường hợp 3: HTTP request cực cao

Ví dụ:

RX = 200 Mbps

HTTP:
1,000,000 request/min

URL:
POST /login
GET /search
GET /api

Có thể là:

HTTP Flood
Application Layer DDoS
Bot attack

Trường hợp 4: Network gần như bình thường nhưng website chậm

Ví dụ:

RX = 20 Mbps
CPU = 100%
PHP-FPM = cao
MySQL = cao

Khả năng cao là application overload hơn là volumetric DDoS.

31. Cách xác định DDoS có thực sự đến VPS hay không

Đây là điểm rất quan trọng đối với VPS.

Giả sử:

Internet
    |
    v
Provider
    |
    v
VPS

Nếu DDoS:

10 Gbps

đánh vào IP nhưng provider đã lọc:

9.9 Gbps

thì VPS có thể chỉ nhìn thấy:

100 Mbps

Do đó bạn không thể chỉ dùng iftop, sar hoặc ip -s link trên VPS để biết tổng lượng DDoS trước upstream.

Cần yêu cầu nhà cung cấp kiểm tra:

Port traffic
Traffic graph
Interface utilization
Packet rate
Upstream traffic
DDoS mitigation
NetFlow/sFlow
Flow logs

Đây là lý do một số trường hợp:

VPS chỉ thấy 100 Mbps nhưng provider thông báo IP đang bị tấn công nhiều Gbps.

Hai thông tin này hoàn toàn có thể cùng đúng.

32. Kiểm tra traffic từ phía nhà cung cấp

Nếu bạn quản trị hệ thống VPS/Cloud, nên kiểm tra thêm ở:

Switch
Router
Firewall
Hypervisor
Cloud Network
Upstream

Ví dụ trên Linux host:

ip -s link

Trên switch có thể kiểm tra:

Interface utilization
RX/TX packets
RX/TX errors
Broadcast
Multicast
Drops

Nếu sử dụng hệ thống monitoring:

Zabbix
Prometheus
Grafana
LibreNMS
Cacti
Netdata

nên lưu:

Bandwidth
Packets/sec
Connection
CPU
Drops
Errors

để so sánh baseline.

33. DDoS có thể không làm bandwidth đầy

Một quan niệm sai phổ biến:

“Chỉ khi bandwidth 1 Gbps đầy thì mới là DDoS.”

Không chính xác.

Ví dụ:

Packet size = rất nhỏ
Packets/sec = cực cao
Bandwidth = chỉ 100 Mbps

Server vẫn có thể bị ảnh hưởng nghiêm trọng bởi:

CPU interrupt
Kernel processing
Connection tracking
Firewall rules
Socket allocation
Application processing

Vì vậy nên kiểm tra đồng thời:

Mbps
PPS
Connections
CPU
SoftIRQ
NIC drops
Application requests

34. Checklist kiểm tra DDoS nhanh trên Ubuntu

Khi VPS có dấu hiệu bất thường, có thể chạy lần lượt:

uptime

top

ss -s

ip -s link

sar -n DEV 1 10

ss -ant state syn-recv | wc -l

ss -ant | awk '{print $4}' | sed 's/.*://' | sort | uniq -c | sort -nr | head

ss -nt | awk '{print $5}' | sort | uniq -c | sort -nr | head

ethtool -S eth0

tail -f /var/log/nginx/access.log

tail -f /var/log/lfd.log

Nếu cần phân tích packet:

tcpdump -ni eth0

35. Checklist kiểm tra DDoS trên Windows

Mở CMD/PowerShell Administrator:

netstat -ano

netstat -ano | findstr SYN_RECEIVED

PowerShell:

Get-NetTCPConnection |
Group-Object RemoteAddress |
Sort-Object Count -Descending |
Select-Object -First 20

Kiểm tra:

perfmon

Theo dõi:

Network Interface
TCPv4
TCPv6
Processor

Nếu cần kiểm tra packet:

pktmon

Các công cụ này giúp phân biệt connection overload, packet drops và network utilization.

36. Không nên vội block toàn bộ IP

Khi thấy một IP tạo nhiều connection, không nên lập tức:

csf -d IP

hoặc:

iptables -A INPUT -s IP -j DROP

Cần kiểm tra:

IP có phải CDN không?
IP có phải Load Balancer không?
IP có phải Proxy không?
IP có phải Googlebot/Bingbot không?
IP có phải customer không?
IP có phải API client không?

Đặc biệt nếu website sử dụng:

Cloudflare
Reverse Proxy
Load Balancer
CDN

thì IP mà server nhìn thấy có thể là IP proxy chứ không phải IP client thực tế.

37. Khi nào nên sử dụng CSF để block?

Nếu traffic trực tiếp tới VPS và xác định một IP có hành vi bất thường, CSF có thể được sử dụng để block.

Ví dụ:

csf -d 203.0.113.10

Kiểm tra:

csf -g 203.0.113.10

Tuy nhiên, block từng IP chỉ hiệu quả trong một số trường hợp.

Nếu:

100,000 IP

cùng tạo traffic thì block thủ công từng IP không phải giải pháp.

38. Khi nào CSF không thể giải quyết DDoS?

Ví dụ VPS có:

Port 1 Gbps

nhưng DDoS:

5 Gbps

Traffic đã làm đầy đường truyền trước khi tới VPS.

Lúc này:

CSF
iptables
nftables
fail2ban

không thể giúp VPS lấy lại bandwidth đã bị upstream tiêu thụ.

Cần xử lý tại:

Provider
Upstream
DDoS Protection
Scrubbing Center
Cloud DDoS Protection
CDN

Đây là điểm rất quan trọng khi vận hành VPS/Dedicated Server.

39. Quy trình xử lý khi phát hiện DDoS

Có thể áp dụng quy trình:

        Phát hiện bất thường
                |
                v
       Kiểm tra bandwidth
                |
                v
       Kiểm tra PPS / packet
                |
                v
       Kiểm tra connections
                |
                v
       Kiểm tra source IP
                |
                v
        Xác định port
                |
       +--------+--------+
       |                 |
       v                 v
    Network            HTTP/API
      flood              flood
       |                 |
       v                 v
   Provider/          WAF/CDN/
   upstream           rate limit

40. Khi VPS đang bị DDoS, nên thu thập thông tin gì?

Khi liên hệ nhà cung cấp, nên gửi:

IP bị tấn công
Thời gian bắt đầu
Thời gian kết thúc
Bandwidth
Packets/sec
Protocol
Destination port
Source IP sample
CPU
Packet drops
Connection count

Ví dụ:

Target IP: 103.x.x.x
Start: 10:20
Protocol: TCP
Destination: 443
Traffic: ~850 Mbps
PPS: ~450k
SYN_RECV: ~30k
CPU: 90%

Thông tin này giúp NOC/network team xử lý nhanh hơn rất nhiều so với chỉ báo:

“Server đang bị DDoS, kiểm tra giúp.”

41. Cách xây dựng hệ thống monitoring để phát hiện DDoS sớm

Nếu quản trị nhiều VPS, không nên đợi khách hàng báo:

“VPS bị chậm.”

Nên monitoring:

Bandwidth
PPS
TCP connections
SYN_RECV
CPU
SoftIRQ
NIC drops
NIC errors
HTTP requests
HTTP 5xx
Load average

Có thể sử dụng:

Zabbix
Prometheus
Grafana
Netdata
LibreNMS

Đặc biệt nên đặt cảnh báo theo baseline.

Ví dụ bình thường:

RX = 20-50 Mbps

Nếu đột nhiên:

RX = 500 Mbps

thì cảnh báo.

Nhưng với server backup:

RX = 800 Mbps

lại có thể hoàn toàn bình thường.

Vì vậy:

Không nên đặt một ngưỡng DDoS giống nhau cho tất cả server.

42. Bảng phân biệt nhanh DDoS và các lỗi khác

Hiện tượng	Network	CPU	Connection	Khả năng
Website code lỗi	Bình thường	Bình thường	Bình thường	Application
MySQL quá tải	Bình thường	Cao	Có thể cao	Database
PHP-FPM quá tải	Bình thường/cao	Cao	Cao	HTTP/Application
SYN flood	Cao	Có thể cao	SYN_RECV cao	DDoS
UDP flood	Rất cao	Có thể cao	Không nhất thiết cao	DDoS
HTTP flood	Cao	Cao	Cao	Layer 7 DDoS
Bandwidth flood	Rất cao	Có thể bình thường	Không nhất thiết cao	DDoS
NIC lỗi	Bất thường	Có thể cao	Không nhất thiết	Hardware/network
Provider lỗi	Bất thường	Bình thường	Có thể bình thường	Upstream

43. 5 chỉ số quan trọng nhất khi kiểm tra DDoS

Nếu chỉ có vài phút để kiểm tra, hãy tập trung vào:

1. Bandwidth

Mbps/Gbps

2. PPS

Packets/sec

3. Connections

ESTABLISHED
SYN_RECV
TIME_WAIT

4. CPU / SoftIRQ

CPU
system
softirq
interrupt

5. NIC drops/errors

RX dropped
RX errors
TX dropped
TX errors

Kết hợp 5 nhóm dữ liệu này sẽ cho kết quả đáng tin cậy hơn nhiều so với chỉ kiểm tra ping.

44. Kết luận

Khi VPS chậm hoặc mất kết nối, không nên ngay lập tức kết luận VPS đang bị DDoS.

Một quy trình kiểm tra chính xác nên đi từ:

Bandwidth
    ↓
Packets/sec
    ↓
TCP/UDP connections
    ↓
Source IP
    ↓
Destination port
    ↓
NIC drops/errors
    ↓
CPU/SoftIRQ
    ↓
Webserver/Application
    ↓
Upstream/Provider

Trên Ubuntu/Linux, các công cụ quan trọng nhất gồm:

ip
ss
sar
tcpdump
ethtool
iftop
nload
nethogs
vnstat
top

Trên Windows Server:

netstat
pktmon

kết hợp:

PowerShell
Performance Monitor

Microsoft cũng khuyến nghị sử dụng các network performance counters như bytes/packets received/sent, packet discarded/errors và TCP connection failures/resets để điều tra các vấn đề network.

Điểm quan trọng nhất cần nhớ là:

DDoS không chỉ được xác định bằng bandwidth.

Cần xem đồng thời:

Bandwidth
PPS
Connections
CPU
SoftIRQ
NIC drops
Application requests

Và nếu traffic đã làm nghẽn đường truyền ở upstream, việc kiểm tra ngay trên VPS có thể không phản ánh được tổng quy mô của cuộc tấn công. Khi đó cần phối hợp với nhà cung cấp VPS/Datacenter để kiểm tra traffic tại router, firewall, switch hoặc hệ thống DDoS mitigation.

Đối với hệ thống cung cấp Cloud VPS/Dedicated Server, cách tốt nhất là triển khai monitoring từ cả hai phía:

             INTERNET
                 |
          +------+------+
          | DDoS / Edge |
          | Monitoring  |
          +------+------+
                 |
              Network
                 |
          +------+------+
          |   Hypervisor|
          +------+------+
                 |
             VPS Server
                 |
       +---------+---------+
       |                   |
    Network             Application
       |                   |
    Bandwidth           HTTP/API
    PPS                  PHP
    Drops                MySQL
    Errors               Logs

Như vậy có thể xác định chính xác hơn DDoS đang xảy ra ở đâu, mức độ bao nhiêu và cần xử lý tại VPS hay tại upstream.