网络设备日志中DDoS攻击的典型记录格式

在运维的日常工作中，翻看网络设备日志是排查故障的“肌肉记忆”。当你怀疑服务器正遭受分布式拒绝服务攻击时，不需要复杂的分析软件，直接SSH进设备，抓取一段原始的日志输出，往往就能立刻定性和定量。网络设备日志中关于DDoS攻击的记录，并非杂乱无章，它遵循着非常严谨的格式逻辑。看懂这些由数字、符号和缩写组成的“密码”，是快速响应攻击的第一道防线。

在核心路由器和高端交换机上，最经典的攻击发现手段不是看包速率，而是看流记录。当DDoS发生时，Netflow v5或v9输出的日志会呈现出极端的“单向性”和“碎片化”。一条典型的攻击流记录通常长这样：

Date flow start|Duration|Proto|Src IP Addr:Port|Dst IP Addr:Port|Packets|Bytes|Flows
2024-05-20 14:32:10.459|0.000|TCP|192.168.1.100:0|10.0.0.1:80|1|40|1
2024-05-20 14:32:10.460|0.000|UDP|172.16.0.50:53|10.0.0.1:53|1|28|1

注意看这几个致命指标：Duration（持续时间）极短，通常是0.000秒；Packets（数据包数）为1；Bytes（字节数）极小，如40或28字节。这代表攻击者发送的是海量的、极短的、伪造源IP的单包会话。正常的Web访问流，Duration会有几秒甚至几分钟，Packets会有几十个来回。而在攻击日志里，全是这种“一闪而过”的会话，且Src IP Addr（源IP地址）极其分散，甚至端口显示为0或随机值。如果你在Netflow分析器中看到Flows（流数量）在瞬间从几千飙升到几百万，且99%都是这种1包1字节的“微流”，无需怀疑，这就是典型的SYN Flood或UDP Flood在设备层面的日志映射。

状态防火墙是DDoS攻击最直接的受害者。当攻击流量涌入，防火墙的会话表会被迅速占满。此时，日志中不会直接显示“正在被攻击”，而是会疯狂刷屏关于会话建立失败和表项溢出的告警。以某主流厂商的防火墙日志格式为例：

May 20 14:35:22 FW01 kernel: [SESSION]DROPPED: proto=TCP src=1.2.3.4 dst=10.0.0.1 sport=54321 dport=80 reason="No free session entry"
May 20 14:35:22 FW01 kernel: [SESSION]LIMIT: policy=inbound src=5.6.7.8 dst=10.0.0.1 sport=12345 dport=443 limit=500000 current=500001

这里的核心字段是reason和LIMIT。reason="No free session entry"直译就是“没有空闲会话资源”，这是最危险的信号，意味着防火墙的连接表物理内存已被耗尽，任何新连接都无法建立，正常用户访问彻底中断。而LIMIT告警则显示了具体的会话限制策略，current数值达到了设定的极限阈值。在排查时，如果你发现日志中sport（源端口）在疯狂变化，但dst（目的IP）和dport（目的端口）高度固定，且伴随大量No free session entry的记录，这基本可以断定是冲着单一服务发起的连接耗尽型攻击。

深入TCP层，网络设备在开启抗攻击模块后，会对TCP标志位进行严格校验。SYN Flood攻击在日志中会留下大量“首包无效”或“无后续ACK”的记录。典型日志格式如下：

May 20 14:40:01 Router01 %ANTI-DDOS-4-TCP_SYN_OVERLOAD: Threshold exceeded. SYN rate to 10.0.0.1:80 is 150000 pps, limit is 10000 pps. Action: SYN Cookie enabled.
May 20 14:40:05 Router01 %ANTI-DDOS-4-TCP_HALF_OPEN_MAX: Half-open connections to 10.0.0.1:443 exceeded 30000.

第一条日志明确指出了攻击目标（10.0.0.1:80）、实时速率（150000 pps）和触发阈值（10000 pps）。设备自动触发了SYN Cookie防护机制。这是关键转折点：如果日志显示SYN Cookie enabled，说明设备正在替服务器抵挡握手洪水，此时服务器的CPU可能并不高，但设备的CPU正在飙升。第二条日志中的HALF_OPEN_MAX（半开连接数最大限制）则更致命。它意味着有大量伪造源IP的SYN包发出后，设备或服务器在等待永远不会到来的第三次握手ACK包。这些半开连接会占用内存，日志中如果这个数值居高不下，且伴随大量源IP在日志中从未重复出现，就是典型的伪造源IP攻击。

DNS放大攻击在日志中的特征极其鲜明，因为它利用了UDP协议的无连接特性和DNS服务器的响应差异。在网络设备上，你通常看不到具体的DNS解析内容，但能看到流量模式的极度反常。设备日志会记录下这种“以小博大”的流量不对称：

May 20 14:45:33 CoreSW01 %SEC-6-IPACCESSLOGP: list 101 denied udp 10.0.0.1(53) -> 192.168.1.50(12345), 1 packet
May 20 14:45:33 CoreSW01 %SEC-6-IPACCESSLOGP: list 101 denied udp 10.0.0.1(53) -> 192.168.1.50(12346), 1 packet
... (repeated millions of times with different destination ports)

注意这里的方向：源端口是53（DNS服务），目的IP是你的公网IP，且目的端口在疯狂变化。这是典型的反射放大攻击。攻击者伪造了你的IP向全球的开放DNS服务器发送了短小的查询请求，DNS服务器将数倍大的响应包“反射”给了你。在设备日志中，你会看到来自完全不同的、合法的DNS服务器IP（如8.8.8.8、1.1.1.1或各种冷门递归DNS），都指向你的IP，且源端口统一为53。如果你抓取ACL拒绝日志，发现denied udp src_port=53的记录在毫秒级时间内覆盖了几万个不同的源IP，那这就是一起典型的DNS Amplification Attack。

当攻击绕过网络层，直接打击应用层时，网络设备层面的日志往往显得“平静”，但Web应用防火墙或反向代理的日志会暴露出真相。HTTP Flood的特征不是包速率高，而是URL请求的极度集中或随机参数化。一条典型的CC攻击日志片段如下：

2024-05-20 14:50:01 WAF01 10.0.0.1 GET /api/search?keyword=random123&token=abc - 403 - 0 "Mozilla/5.0 (compatible; Bot/1.0)" - "HIGH_RATE_ALERT"
2024-05-20 14:50:01 WAF01 10.0.0.1 GET /api/search?keyword=random456&token=def - 403 - 0 "Mozilla/5.0 (compatible; Bot/1.0)" - "HIGH_RATE_ALERT"

这里的关键信息是返回状态码403和触发原因HIGH_RATE_ALERT。WAF日志中，User-Agent往往是伪造的，且请求集中在某个计算资源消耗较大的动态页面（如搜索接口、数据库查询接口）。日志中Bytes Sent（发送字节数）可能很小，但Request Processing Time（请求处理时间）可能极长，或者因为触发了速率限制而被直接拒绝。如果你在日志分析平台看到某个URL的请求数在短时间内呈90度直线上升，且所有请求的User-Agent都一致，或者Referer为空，同时WAF返回大量403或503错误，这就是应用层DDoS的铁证。

ICMP协议虽然简单，但ICMP Flood依然是耗尽带宽的常见手段。由于ICMP没有端口概念，日志记录会聚焦于Type和Code字段。设备日志通常这样显示：

May 20 15:00:00 EdgeRouter %DOS-4-ICMP_FLOOD: ICMP flood detected from multiple sources to 10.0.0.1. Current rate: 85000 pps, Type=8 Code=0.
May 20 15:00:01 EdgeRouter %DOS-4-ICMP_THROTTLE: Throttling ICMP Type 8 to 10.0.0.1 to 1000 pps.

Type=8, Code=0代表Echo Request，也就是ping命令发出的包。正常的ping探测每秒也就几个包，当设备日志显示ICMP Type 8的速率达到几万甚至几十万pps时，这就是典型的Ping Flood。值得注意的独到细节是，很多运维会忽略Type=3（Destination Unreachable）的洪水。如果日志显示大量Type=3, Code=3（端口不可达）的包涌向你的IP，这通常不是攻击者直接发送的，而是一种“背向散射”流量。攻击者伪造了你的IP去攻击别人，别人的服务器回复了大量的端口不可达消息给你。看到这种日志，说明你的IP正在被当作伪造源，此时你的入向带宽可能被这些无用的ICMP错误报文占满。

NTP放大攻击与DNS放大类似，但具有特定的端口号123，且放大倍数往往更惊人。在设备ACL或Netflow日志中，它的特征非常明显：

May 20 15:10:10 CoreRouter %SEC-6-IPACCESSLOGP: list 110 denied udp 202.120.2.100(123) -> 10.0.0.1(80), 468 bytes
May 20 15:10:10 CoreRouter %SEC-6-IPACCESSLOGP: list 110 denied udp 130.88.200.5(123) -> 10.0.0.1(80), 468 bytes

注意源端口固定为123，且单包大小非常固定，比如468字节，这是NTP monlist查询的典型响应大小。攻击者利用NTP服务器的monlist功能，发送一个很小的请求包，服务器会返回最近与服务器交互过的多达600个IP地址列表，导致响应包极大。在日志中，你会发现这些响应的目的端口并不是123，而是攻击者伪造的你的服务器的任意开放端口（如80、443）。如果你在日志中过滤src_port=123，发现短时间内有来自全球各地不同NTP服务器的流量涌向你的同一个IP，且包大小都是468或类似的固定大字节数，这就是典型的NTP Amplification。

最后一道防线是设备自身的控制平面保护。当DDoS流量大到开始影响网络设备的CPU时，设备会生成最后的“护盾”日志。这类日志通常带有Control Plane或Punt等关键词：

May 20 15:20:00 Core01 %CONTROL-PLANE-4-PUNT_RATE_EXCEEDED: Punt rate exceeded 5000 pps. Current rate 12500 pps. Protocol: ARP.
May 20 15:20:01 Core01 %CONTROL-PLANE-4-CPU_HIGH: CPU utilization for 5 seconds: 99%/95%; 1 minute: 85%; 5 minutes: 60%.

这里的Punt指的是数据平面将无法处理的包“上送”给CPU处理的过程。正常情况下，通过ASIC芯片硬件转发的流量不经过CPU。但当攻击流量触发了大量需要CPU处理的异常（如TTL超时、需要分片但DF位设置、ARP请求过载），日志就会记录Punt rate exceeded。如果你看到CPU_HIGH与PUNT_RATE_EXCEEDED同时出现，且协议类型为ARP或ICMP，说明攻击流量已经穿透了硬件防护，正在直接消耗路由引擎的计算资源。此时，设备随时可能因CPU过载而导致邻居协议中断，造成全网震荡。

读懂这些日志格式，本质上是在脑海中建立了一个攻击流量的“法医鉴定”模型。从流记录的微流特征，到防火墙的会话耗尽告警，再到特定协议的端口和标志位异常，每一行日志都在精准地描述攻击者的武器类型和打击路径。下次当告警响起，直接切入这些关键字段，你就能在几分钟内完成从“感觉被攻击了”到“确切知道被什么攻击了”的关键跨越。