遭遇反射放大攻击时，源站收到的往往不是直接发起请求的设备，而是 DNS、NTP 等服务返回的响应包。判断反射放大攻击流量特征及源站防护措施，不能只看访问日志：网络层流量、边界设备记录和应用日志要放在一起核对，才能区分带宽拥塞、服务异常与正常访问高峰。
先识别入站流量的反射特征
反射攻击通常利用伪造的源地址：攻击者把受害者地址放进请求的源地址字段，再向可响应的第三方服务发送请求，响应便被发往受害者。若响应数据明显大于请求，就形成放大效果。受害源站看到的是一批来自不同地址的入站数据，源地址不一定代表真实攻击者。
重点观察短时间内的包速率、入站带宽、协议和目的端口分布，以及源地址数量是否突然扩大。DNS、NTP、CLDAP 等基于 UDP 的服务都可能被滥用；协议本身并不等于攻击，关键要看流量是否与业务预期相符。若链路接近饱和而应用请求量没有同步增长，问题可能发生在应用层之前。
把网络记录和回源日志对齐
源站访问日志记录的是到达应用并被处理的请求，不会完整呈现所有网卡收到的数据包。攻击流量若在网络栈或防火墙处被丢弃，应用日志可能没有对应记录；反过来，日志量变大也不必然意味着反射攻击。因此，应将边界设备计数、云平台流量记录、主机防火墙日志与应用回源日志按时间段对照。
按顺序完成排查
- 固定时间窗口：记录异常开始、峰值和缓解时间，统一设备时钟，并保存入站带宽、包速率、协议及端口统计。
- 检查目标分布：确认流量集中于单台源站、某个服务端口，还是多个地址；同时比较正常时段的基线，避免把业务突发误判为攻击。
- 核对回源记录：检查请求时间、目标服务、状态码和上游来源。若边界流量激增而应用请求未增加，可能是大量数据未进入应用处理环节。
- 抽样核验数据包：在具备权限且不影响业务的条件下，使用网卡统计、流量分析或短时抓包确认协议特征；高流量时避免长时间保存完整抓包，以免占满磁盘。
- 留存证据并升级处置：保留设备计数和日志副本，向网络服务商或防护平台提供时间、目标地址、协议、端口及流量趋势，便于其在上游链路定位和过滤。
按影响层级完善源站防护
如果攻击已经占满接入链路，主机防火墙通常无法单独解决，因为流量在到达源站前就消耗了带宽。此时应优先联系具备上游清洗能力的服务商，或使用适合业务架构的 DDoS 防护服务；清洗服务能否覆盖相应协议、地址和线路，需要事先确认。仅增加源站实例或提高应用限流阈值，未必能缓解链路拥塞。
链路仍可用时，可逐项收紧边界策略：只开放业务确需的入站服务；限制不需要的管理端口；对 UDP 服务按业务需求设置访问范围和速率；检查 DNS、NTP、Memcached 等服务是否有不必要的公网暴露。不要为图省事直接封禁所有 UDP 流量，语音、实时通信或其他业务可能依赖它。对源站启用连接与请求速率限制时，也要确认规则不会误伤共享出口后的正常用户。
将源站地址隐藏在代理或防护层后，可减少攻击者直接向源站发包的机会，但前提是源站只接受可信代理的回源连接，并关闭绕过代理的公开入口。变更前核对健康检查、证书和回源规则；变更后从外部验证源站直连是否仍可达，并持续比较边界流量与回源日志。
用复盘结果改进长期策略
处置结束后，整理攻击期间的协议分布、峰值时间、被触发的规则和业务影响，区分上游带宽问题与主机资源问题。把告警阈值建立在自身历史基线上，定期检查公网暴露服务和应急联系人。反射放大攻击流量特征及源站防护措施的核心，是尽早识别异常入站流量、用回源日志核实业务是否受影响，并在正确的网络层实施缓解，而不是只依赖单一应用日志或临时封禁。
常见问题
源站日志没有异常，是否说明没有攻击？
不是。大量数据包可能在到达应用前被丢弃或耗尽链路，应同时查看网络设备和流量统计。
看到很多不同来源地址，就能确认是反射攻击吗？
不能。来源分散只是线索，还要结合协议、端口、流量突增和业务基线判断，并注意源地址可能被伪造。
直接封禁 UDP 是否有效？
可能降低部分流量，但也会影响依赖 UDP 的正常服务；应按业务端口和来源范围制定规则，链路饱和时优先寻求上游缓解。
部署代理后还需要保护源站吗？
需要。应限制源站只接受可信代理或防护节点回源，并检查是否存在可被直接访问的备用地址和服务端口。