游戏服务器带宽突然被打满，监控显示入向流量里全是UDP包，但源IP查过去，都是些正常的DNS服务器、NTP服务器，甚至还有暴露在公网的memcached。这些服务器没被入侵，它们只是在正常响应请求——只不过请求的源IP被伪造了。这就是UDP反射攻击，攻击者自己没多少带宽，却能让一堆无辜的第三方服务器替他打出几十上百G。
攻击者带宽不大，为什么能打出几十G
反射放大靠的是请求和响应的体积差。攻击者伪造受害者IP，向开放UDP服务的服务器发一个小请求，服务器把大响应发到受害者IP上。DNS查询的放大倍数在50到70倍，NTP的monlist请求能放大500倍以上，memcached的统计指令放大倍数可以达到数万倍。攻击者用1G的上传带宽，理论上能打出几T的流量。这也是为什么UDP反射攻击的峰值往往比TCP攻击高得多——TCP握手需要三次交互，伪造源IP很难完成，UDP无连接，伪造起来没有任何门槛。
反射流量源IP都是真的，阈值清洗基本失效
传统DDoS清洗依赖源IP信誉和请求频率阈值。但反射攻击的流量来自真实存在的合法服务器，源IP没有伪造，频率也不一定异常——一台DNS服务器可能只是正常响应了查询。用阈值去卡，要么卡不住，要么把正常DNS响应也一起封了。更麻烦的是，这些UDP包在协议层看是合规的，没有畸形包特征，网络层的行为分析也很难区分“正常DNS响应”和“反射攻击的DNS响应”，因为两者长得一模一样。
清洗UDP，难在不能一刀切封端口
如果业务本身跑着UDP——游戏对战、语音通话、实时同步——清洗时不能简单封掉UDP端口，否则正常业务先断。攻击者恰恰利用了这一点：反射流量用的端口（53、123、11211）和正常业务端口混在一起，防护设备要在放行正常UDP的同时，把反射流量挑出来。这比清洗TCP的SYN Flood难得多，SYN Flood至少能通过TCP状态机判断连接是否合法，UDP没有连接状态，每个包都是独立的。
会话跟踪：把合法UDP包和反射包分开
可行的思路是给UDP加会话状态。正常游戏或语音业务，客户端和服务器之间有明确的会话：客户端先发包，服务器再回包，源端口和目的端口在一段时间内固定，包的大小和频率有规律。反射攻击的包没有前置会话，源端口通常是53、123这类服务端口，包大小和业务不匹配。高防IP在UDP防护上的处理方式是维护会话表：只有匹配已有会话的UDP包才允许通过，非会话内的UDP包直接丢弃。同时结合包大小分布、源端口特征、响应速率做辅助判断，把反射流量从正常业务里剥离出来。这个方式对业务透明，玩家端不需要任何改动。
反射协议端口，封不封要看业务
DNS、NTP、SSDP、memcached这些反射常用端口，如果业务用不到，最省事的做法是在高防IP上直接丢弃这些端口的入向流量。业务用到DNS解析的场景，则需要放行合法DNS响应，只拦截异常放大的响应包。这个判断需要按业务实际情况配，不能照搬默认规则。有些高防IP默认封了53端口，结果业务自己的DNS查询也被断了，这种方案在选型时就要问清楚：反射端口是默认全封，还是可以按业务放行。
选型时确认三件事
第一，UDP防护是不是真的支持会话跟踪，还是只做了简单的包大小过滤。第二，反射协议端口能不能按业务灵活配置，而不是一刀切。第三，清洗UDP时的延迟增加是多少，游戏和语音业务对这一点很敏感。高防IP在这三项上的处理是：UDP会话表维护、反射端口可配置放行、清洗节点就近接入控制延迟。100G独享300元/月起，UDP防护和TCP防护在同一个方案内，不需要分开采购。
如果业务用UDP，但防护方案只讲TCP清洗、对UDP一笔带过，这个方案基本可以跳过。反射攻击专打UDP业务，防护能力跟不上，买了也白买。
