linux排查syn攻击需先确认网卡与权限，再精准过滤syn报文，结合ss、sysctl等内核状态验证是否真被攻击，最后用wireshark分析源ip分布、端口随机性、时间间隔及tcp选项一致性。
Linux 系统中排查 SYN 攻击，核心是快速捕获并识别异常的 TCP SYN 流量，同时结合内核行为判断是否真被攻击或协议栈已丢弃连接请求。不能只看“有没有 SYN”，而要看“SYN 到了没、回没回 SYN-ACK、谁在发、频率多高”。
确认网卡与权限，避免抓不到包
很多排查失败，是因为根本没抓到真实流量：
- 用 ip link show 查活跃网卡（如 eth0、ens33），别默认写 lo 或 any —— 内核新版对 any 支持受限，易报错
- 必须加 sudo 执行，普通用户无权进入混杂模式
- 若服务跑在容器/K8s 中，需在宿主机抓 docker0 或 cni0，进容器抓通常只能看到 loopback 流量
精准过滤 SYN 报文，减少干扰
全量抓包效率低且难分析，应直接聚焦三次握手首包：
- 抓本机收到的所有 SYN：sudo tcpdump -i eth0 -nn -c 100 'tcp[tcpflags] & tcp-syn != 0 and tcp[tcpflags] & tcp-ack == 0'
- 只看来自某 IP 段的 SYN：sudo tcpdump -i eth0 -nn 'src net 203.0.113.0/24 and tcp[tcpflags] & tcp-syn != 0'
- 加 -w syn-attack.pcap 保存为文件，便于后续用 Wireshark 分析时间分布和源端口熵值
结合内核状态交叉验证是否真被攻击
光有 SYN 包不够，得确认内核是否已处理、为何不回包：
- 查当前半连接队列长度：ss -s | grep -i "synrecv"，持续高于 net.ipv4.tcp_max_syn_backlog 是典型信号
- 检查 SYN cookies 是否启用：sysctl net.ipv4.tcp_syncookies，值为 1 表示开启（可缓解但非根治）
- 看是否有大量未完成连接：netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'，若 ESTABLISHED 很少而 SYN_RECV 占比极高，基本可判定
- 注意排除干扰：iptables DROP 规则、多网卡路径不一致、应用未监听对应端口，这些也会导致“有 SYN 无 SYN-ACK”，但不属于 SYN Flood
用 Wireshark 进一步分析攻击特征
导出的 pcap 文件打开后，重点关注：
- 按 tcp.flags.syn == 1 and tcp.flags.ack == 0 过滤，再按源 IP 分组统计数量（右键 → Apply as Filter → ip.src）
- 观察源端口是否高度随机（正常客户端端口有规律，攻击者常用伪随机端口）
- 检查时间间隔：短时密集（如每秒数百个）、固定间隔（如 100ms 均匀发送）都是可疑模式
- 对比 SYN 包的 TTL、IP ID、TCP 选项（如 MSS、WScale）是否高度一致——手工构造包往往缺乏多样性
抓包本身不复杂，但容易忽略网卡选择、权限、过滤精度和内核指标的联动验证。
