反射放大型DDoS攻击的入口识别与限流思路，重点不是看到异常流量就封掉一个端口，而是判断哪些响应流量正在涌向目标、哪些业务入口承受冲击，以及如何限制流量而不误伤正常服务。处置前要先分清：攻击者发出请求，被滥用的第三方服务器回包，受害网络看到的源地址往往是这些服务器，并非攻击者本人。
先从回包特征判断攻击类型
反射放大通常利用可被外部访问、且响应可能大于请求的 UDP 服务。常见情形包括 DNS反射放大、NTP反射放大和 Memcached反射放大。流量可能集中在 UDP 53、123 或 11211 等目标端口，但端口只能作为线索，不能单独证明攻击类型；同一端口也可能承载合法服务。
检查边界设备或上游提供的 NetFlow、IPFIX、sFlow 等流量记录，关注协议、目的地址与端口、包速率（pps）、带宽（bps）、包长分布和来源地址数量。若大量 UDP 响应在短时间内指向少数目标，且业务侧没有对应请求增长，就应进一步核对。源 IP 可被伪造，单凭来源地址封禁容易漏掉变化中的反射节点。
识别真正承压的入口
这里的“入口”不只是某个物理网卡，还包括公网 IP、负载均衡入口、递归 DNS 等具体服务，以及流量经过的运营商链路。先判断是单个服务被打，还是整条接入链路已拥塞：若链路先满，主机上的日志可能不完整，必须尽早向上游索取清洗前流量特征。
- 确认受影响范围：记录异常开始时间、受影响的目标 IP、端口及业务表现；对照正常时段的基线，避免把合法流量高峰当成攻击。
- 按协议拆分流量：比较 UDP 与 TCP 的变化，查看目标端口、包长和 pps/bps。多个目标同时受影响时，检查是否共享同一接入链路或前置设备。
- 核对服务侧证据：检查 DNS、NTP 等服务是否对公网开放，日志中是否存在与异常回包相匹配的请求。受害端没有请求记录并不意外，因为请求可能发往第三方反射服务器。
- 和上游协同验证：请网络服务商提供可用的流量摘要或清洗入口信息；若只有带宽告警而缺少分协议数据，先补齐观测，再决定精确过滤条件。
按风险分层限流，而非一刀切封端口
优先限制目标和协议
在边界或上游清洗设备上，针对受影响的目标 IP、协议和目的端口设规则；若业务不需要某种公网 UDP 服务，可关闭该服务的公网访问或仅允许可信来源。提供公共 DNS、NTP 等服务的网络，则不能直接封掉对应端口，应保留合法请求路径，并限制异常流量。
再设速率与例外
限流可按目标地址、协议、服务入口组合设置，并同时观察 pps 与 bps：小包洪泛可能先耗尽包处理能力，大流量则可能先占满链路。阈值应以正常峰值、设备能力和业务容忍度为依据；可先在短周期内观察基线，再从略高于正常高峰的保守阈值试行，逐步收紧。不存在适用于所有网络的固定速率值。
源地址限流可以作为辅助，但 IP源地址伪造会削弱它的效果。若规则触发大量误报，应按业务来源、服务类型设置白名单或独立配额，并检查丢包、请求成功率和链路利用率。上游链路已饱和时，仅在本地设备限流可能来不及，应申请运营商侧过滤或清洗；黑洞路由会使目标流量整体不可达，只适合作为影响范围明确时的最后手段。
处置后验证并补上长期防护
规则生效后，持续比较攻击流量与合法请求，检查丢包、时延及业务错误是否下降；短期内每隔数分钟复核一次，稳定后再延长观察间隔。攻击结束后撤销临时的宽泛规则，保留必要的服务访问控制、流量告警和变更记录。反射放大型DDoS攻击的入口识别与限流思路，应落到“看见流量从哪里进入、确认哪些服务受影响、按证据逐步限速”这三件事上，而不是只留下一个封端口动作。
常见问题
看到大量陌生源 IP，能直接封禁吗？
不建议只按源 IP 封禁。来源可能是被滥用的合法服务器，也可能被伪造；先按协议、目标和流量特征确认，再采用上游过滤或组合规则。
关闭 UDP 就能止住攻击吗？
未必。关闭 UDP 可能中断 DNS、语音或其他正常服务，也无法解决链路已经拥塞的问题。应限制确实不需要的服务，或对受影响目标实施更窄的规则。
什么时候需要联系运营商？
当接入链路接近饱和、站点本地看不到完整流量，或本地规则无法及时缓解时，应尽快联系上游，提供目标 IP、时间范围和协议等信息。
怎样判断限流没有误伤？
同时观察业务成功率、合法请求量、丢包和带宽变化；若异常流量下降但正常请求也明显失败，应放宽规则或增加业务例外，再继续校准。
