/proc/net/nf_conntrack和ss -s是ddos第一响应依据，因攻击最先冲击内核连接跟踪子系统与socket表，二者毫秒级响应且实时反映synrecv>500等关键指纹，远快于日志分析。
直接看 /proc/net/nf_conntrack，比查日志快10倍以上——攻击正在发生时，日志还没落盘，连接跟踪表里已经挤满SYN_RECV和TIME_WAIT状态的IP了。
为什么 ss -s 和 conntrack -L 是第一响应依据
DDoS攻击在内核层面最先冲击的是连接跟踪子系统（nf_conntrack）和socket状态表。等你去翻access.log或跑grep，攻击可能已持续两分钟，而ss -s输出是实时内核统计，conntrack -L直接读取连接跟踪哈希桶，毫秒级响应。
-
ss -s显示的tcp:行中synrecv值 > 500，基本可判定SYN Flood正在进行 -
conntrack -L | head -50能立刻看到高频出现的源IP+端口组合，不用解析日志格式 - 若
conntrack -L | wc -l接近net.netfilter.nf_conntrack_max（通常65536），说明连接表即将溢出，必须立即干预
从 conntrack 输出快速提取攻击源IP
conntrack原始输出字段顺序固定，但IP位置不依赖列数，靠协议关键字定位更可靠。别用cut -c 45-这种易错方式。
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 提取所有TCP源IP：
conntrack -L | awk '$3 ~ /^tcp$/ {print $6}' | cut -d= -f2 | sort | uniq -c | sort -rn | head -20 - 只看SYN未完成连接：
conntrack -L | awk '$3 ~ /^tcp$/ && $10 ~ /SYN_SENT|SYN_RECV/ {print $6}' | cut -d= -f2 | sort | uniq -c | sort -rn | head -20 - 注意：$6是
src=字段，$10是状态字段；不同内核版本字段数可能浮动，但src=和状态关键词位置稳定
iptables -L -v 能暴露攻击指纹，但要看哪一行
很多人只扫一眼iptables -L -v就加规则，结果封错了正常业务IP。关键不是看包计数最大的那条规则，而是看pkts列每秒跳变超过10万的规则对应的目标端口和协议。
- 执行
watch -n 1 'iptables -L INPUT -v --line-numbers | grep -E "pkts|dpt:|udp|tcp"，盯住pkts列变化速率 - 如果某条
--dport 53的UDP规则pkts每秒涨30万，基本是DNS反射攻击，源头IP藏在conntrack里 - 别急着
-A INPUT -s x.x.x.x -j DROP，先确认该IP是否在conntrack高频列表中——避免误杀NAT网关或CDN回源IP
离线IP库批量画像前，先筛掉干扰项
刚导出的IP列表里常混着云厂商健康检查IP、监控探针、甚至本机127.0.0.1。不清洗就喂给离线库，结果全是噪声。
- 过滤私有地址：
grep -vE "^(10\.|172\.(1[6-9]|2[0-9]|3[0-1])\.|192\.168\.|127\.|::1|fe80)" suspicious_ips.txt - 排除已知良性ASN：
ip_lib.query(ip)返回的asn_name含AWS/Azure/Cloudflare时，暂不纳入封禁候选 - 重点盯
network_type为datacenter且country为高危地区的IP——2026年数据显示，73%的T级UDP Flood来自三个数据中心ASN段
真正卡住响应速度的，从来不是工具不会用，而是分不清哪些输出是攻击指纹、哪些是系统自检流量。连conntrack里src=127.0.0.1都懒得过滤的人，喂他再强的IP库也白搭。
