Linux DDoS 攻击的基本识别方法

DDoS第一信号是网络接口吞吐量异常激增而非服务器宕机；需用nload、ip -s link、sar -n DEV实时比对历史基线；SYN_RECV堆积、SyncookiesSent上升、ss显示synrecv>1000提示TCP层攻击；tcpdump过滤抓包确诊协议特征。

看流量峰值是否远超基线

DDoS 的第一信号不是服务器宕机，而是网络接口吞吐量突然翻几倍甚至几十倍。关键不在于“高”，而在于“异常”——比如平时 eth0 RX 峰值 20Mbps，现在持续卡在 800Mbps，且无业务变更，这就是强提示。

• 用 nload -u M eth0 看实时带宽（单位设为 MB/s 更直观）；
• 用 ip -s link show eth0 查看 rx_packets 和 tx_packets 计数器——1秒内增长数万包，基本可判定是洪泛类攻击；
• 别只盯平均值：sar -n DEV 1 每秒采样一次，比 vnstat 这类分钟级统计更能抓到尖峰。

容易踩的坑：云服务器常有“弹性带宽”或“突发带宽”，误把平台限速释放当成攻击；要对比同一时段的历史 sar 数据，而非单看绝对值。

查连接状态是否失衡

SYN_RECV 堆积、ESTABLISHED 数暴增但实际业务连接数极少，是 TCP 层攻击（如 SYN Flood）的典型痕迹。Linux 内核不会无限排队，一旦 /proc/net/netstat 中 TcpExt:SyncookiesSent 开始上升，说明已触发防御机制。

• 快速筛查可疑 IP：netstat -ntu | awk {print $5} | cut -d: -f1 | sort | uniq -c | sort -nr | head -20；
• 看半开连接：ss -s 输出里的 synrecv 值若 > 1000，且持续不降，大概率被 SYN Flood；
• 注意区分：Web 服务正常时也会有大量 TIME_WAIT，但 DDoS 下 ss -tan state syn-recv | wc -l 会稳定在高位。

别直接信 netstat -an | grep :80 | wc -l——它包含所有状态，干扰大；ss 更轻量、更准，且默认不解析域名（加 -n 避免 DNS 查询拖慢响应）。

Linux

操作Linux系统，避免权限陷阱、静默失败及常见管理错误。

下载

抓包确认协议与行为特征

流量和连接数只是“症状”，抓包才是确诊依据。重点不是抓全量包，而是用过滤表达式直击可疑模式，避免 pcap 文件过大导致分析卡死。

• 怀疑 SYN Flood：tcpdump -i eth0 tcp[tcpflags] & tcp-syn != 0 and tcp[tcpflags] & tcp-ack == 0 -c 1000 -w syn_flood.pcap；
• 怀疑 UDP 小包洪泛（如 DNS/SSDP 反射）：tcpdump -i eth0 udp and (udp[4:2] ；
• 抓完立刻用 tshark -r syn_flood.pcap -T fields -e ip.src | sort | uniq -c | sort -nr | head -5 快速定位源 IP 分布。

常见错误：在高负载下用 tcpdump -w 写磁盘，IO 占满反而掩盖真实问题；建议先用 -c 限制包数，或写入 /dev/shm/（内存文件系统）。

交叉验证日志与系统表现

单看网络层可能误判——比如 CDN 回源失败、爬虫误配、监控探针暴增，都会模拟出类似 DDoS 的流量。必须结合应用日志与资源使用反推。

• 检查 Web 日志是否“有请求无业务”：tail -n 1000 /var/log/nginx/access.log | awk {print $1} | sort | uniq -c | sort -nr | head -3，如果 top3 IP 的请求全是 GET / 或 GET /wp-login.php，且 User-Agent 是空或非常规字符串，大概率是应用层攻击；
• 看 CPU 是否“空转”：top 中 %sy（内核态）占比极高（>70%），而 %us（用户态）很低，说明大量时间花在协议栈处理上，符合洪泛特征；
• 留意 dmesg 输出：dmesg -T | grep -i "nf_conntrack.*full" 表示连接跟踪表溢出，是 Linux 主动丢包的明确证据。

最容易被忽略的一点：很多 DDoS 并非来自公网，而是内网扫描器误配、容器间调用风暴、或 Kubernetes Service ClusterIP 转发环路——所以别急着封外网 IP，先确认流量真实入口。