我正在实现一个应该响应SSDP M-SEARCH查询的设备。
我是一个设备供应商，我无法控制这些设备将被部署在哪里。
有一种已知的DDoS攻击使用SSDP搜索放大，即攻击者从假地址发送搜索请求，并且编码不良的SSDP服务器响应该假地址。假地址被敲烂了
我应该做些什么来防止我的设备被用于这种攻击?
- 仅设置TTL=2，依赖路由器丢弃数据包
- 只响应来自自己子网的请求
- 为有效的查询源子网添加配置选项
- 猜猜哪些IP地址是"本地"one_answers"全局"
- 添加响应节流，希望效果最好
- 你的建议吗?
关于1。TTL应该根据SSDP规范进行配置;即使响应很低，也会从本地网络泄漏出去。如果网络上有网桥式VPN，响应会泄露得相当远。
关于2。我可以想象公司网络中有多个子网可达(例如，一个子网用于无线客户端，另一个子网用于桌面，另一个子网用于服务器)，因此我的设备必须可以跨子网搜索(尽管受每个规格的TTL限制)。
关于3。配置和维护麻烦。
关于4。有可靠的方法来做到这一点吗?那么IPv6呢?如果网络有例如/28片的全局地址呢?
关于5。从无数设备中流出的涓涓细流仍然构成了洪流……
裁判:https://blog.sucuri.net/2014/09/quick-analysis-of-a-ddos-attack-using-ssdp.html
另一种选择是根本不回复单播请求。不过，我无法给你一个明确的消息来源，说明这是允许的。其中一份草案读起来似乎是这样的，如果它也是的话，那就说得通了:毕竟这是一个发现协议。
由于组播在任何相同的缺省配置中都不是缺省路由，而239.0.0.0/8是组织本地，您可以放心地假设到达多播地址的请求是真实的。(当然，除非你自己的网络中有攻击者，但这是另一个问题。)
在Linux上，可以使用IP_PKTINFO套接字选项来检查传入的UDP数据包，以验证它实际上是发送到多播地址:
https://stackoverflow.com/a/5309155/705086http://www.linuxquestions.org/questions/programming-9/how-to-get-destination-address-of-udp-packet-600103/