直接查看/var/log/messages中DNS高频异常日志是发现DNS反射攻击最基础有效手段，主要表现为突增的可疑DNS响应包、named进程大量“refused”“no TTL”等错误日志及缓存/内存告警。
直接看 /var/log/messages 里 DNS 相关的高频、异常日志条目，是发现 DNS 反射攻击最基础也最有效的手段之一。这类攻击不直接打到你服务器，而是伪造你服务器的 IP 向开放 DNS 服务器发请求，再让那些服务器把放大后的响应“反射”回你——所以你的服务器在日志里看到的不是大量请求，而是大量突增的、来源可疑的 DNS 响应包，且往往集中在极短时间内。
重点监控 named 进程的异常日志模式
DNS 服务（如 BIND 的 named）在处理海量伪造响应时，会因资源耗尽或协议校验失败产生特定日志。需重点关注以下几类关键词组合：
-
“client” + “refused” 或 “dropped”：例如
client 192.0.2.100#53428: query (cache) 'example.com/AAAA/IN' denied—— 大量同类拒绝记录，说明服务器正在被动接收并丢弃非法响应 - “no TTL”、“bad qname”、“invalid label”：反映收到畸形 DNS reply 报文，常见于反射攻击中伪造的恶意响应
- “exceeding max-cache-size”、“cache full”、“out of memory”：缓存被刷爆、内存告急，是服务濒临瘫痪的明确信号
- “named.*fatal” 或 “exiting on signal”：进程因过载异常退出，属于严重事件，必须立即响应
用 Zabbix 实现自动化日志关键词捕获
人工翻日志效率低且滞后，建议用 Zabbix 主动采集并告警。关键配置如下：
IntoDNS.ai
下载
免费 DNS 与邮件安全分析（IntoDNS.ai）：包括 DNSSEC、SPF、DKIM、DMARC、MTA-STS、BIMI、SMTP STARTTLS、FCrDNS、黑名单、发件人要求及报告。
- 监控项键值设为：
log[/var/log/messages,named.*refused|named.*dropped|named.*cache.*full,,skip] - 触发器表达式示例：
{DNS模板:log[/var/log/messages,named.*refused|named.*dropped,,skip].count(#5)}>50—— 表示 5 分钟内匹配到超 50 条拒绝日志即告警 - 若需区分真实客户端请求与反射响应，可额外采集
tcpdump -i any port 53 -c 1000 -w /tmp/dns.pcap并用脚本解析源端口分布：反射流量常表现为源端口高度集中（如全为 32768–65535 某一固定值），而正常查询端口随机
结合时间窗口与源 IP 聚类分析
单看日志关键词还不够，要叠加时间和 IP 维度才能确认是否为反射攻击：
- 提取日志时间戳（
awk '{print $1,$2,$3}' /var/log/messages | grep named），观察是否在秒级内出现数百条同类记录 - 用
awk '/named.*refused/{print $NF}' /var/log/messages | cut -d'#' -f1 | sort | uniq -c | sort -nr | head -10查看 Top 10 异常源 IP —— 若多数为数据中心 ASN（如阿里云、AWS、OVH）、且风险分>70，基本可判定为反射源 - 注意：这些 IP 往往不是攻击者真实出口，而是被利用的开放 DNS 服务器，封禁它们无意义；真正要做的，是识别其背后的恶意基础设施（如恶意 DNS 解析器 IP），并同步加入防火墙黑名单
补充验证：抓包比对日志线索
当 Zabbix 触发告警后，立刻执行轻量抓包确认：
-
tcpdump -i any port 53 and udp -c 200 -nn -tttt | awk '{print $1,$3,$NF}'—— 快速查看时间、源IP、响应大小 - 重点找：源 IP 固定、目的端口 53、响应长度远大于请求（典型放大特征，如请求 60 字节，响应 1500 字节）
- 若发现大量来自不同 IP 的 UDP DNS 响应，但你的服务器从未发起过对应请求（即无 outbound query 日志），即可坐实为 DNS Reply Flood 或反射攻击
