作者：高玉涵

时间：2022-11-23 10:21

环境：

• Linux ubuntu 4.15.0-163-generic #171-Ubuntu SMP Fri Nov 5 11:53:11 UTC 2021 i686 i686 i686 GNU/Linux

• Windows 10 专业工作站版 22H2

• Windows 7 旗舰版 SP1

工具：

• Wireshark

• tcpdump

• gssdp-discover

在计算机网络中，每天都可能发生成千上万的问题，从简单的间谍软件感染，到复杂的路由配置错误。我们永远也不能立即解决所有问题，而只能期盼充分地准备好相关的知识和工具，从而能够快速地响应各种类型的错误。—— Chris Sanders

一段来自陌生人的对话

明眼人一定能通过上述对话发现问题。当时限于我固有认知，再加上并未在 WIN10 系统上去验证他所描述的现象，在经验主义的驱使下，想当然的认为这只是一个平常的网络通信问题。然后，就有了上述“哔哩吧啦”一段所谓的排查。我想这一定给他带来不少困扰、走了不少弯路。在此，深表歉意。

可能缘于我多年从事技术相关工作的原因，日常潜移默化培养成有了严谨习惯的人。在上面对话中我虽然给出了排查方案，也笃信这是造成上述"故障"的原因，但终究没有亲手验证总是有点不自信。就利用空闲时间，在电脑上打开 WireShark 一看，让我大跌眼镜的是，我也遇到上述“故障"经过一系列的排查验证（搭建了一套实验环境）终将原因刨析出来（先卖个关子暂不给出结论）将此次经历分享出来，以期大家在排除网络通信问题上有所启发。

我所在网络拓扑图

一、SSDP 协议极简介绍

为了能顺利阅读下面的主题，这里极简介绍下 SSDP 协议（详细部分见文未给出的参考）如果你熟知此协议可跳过此部分。

SSDP（简单服务发现协议）是应用层协议，是在 HTTPU 和 HTTPMU 的基础上实现的协议，是构成 UPnP（通用即插即用）技术的核心协议之一。它为网络客户端提供了一种发现网络服务的机制，采用基于通知和发现路由的多播方式实现。

按照协议的规定，当一个控制点（客户端）接入网络的时候，它可以向一个特定的多播地址的 SSDP 端口使用 M-SEARCH 方法发送 ssdp:discover 消息。当设备监听到这个保留的多播地址上由控制点发送的消息的时候，设备会分析控制点请求的服务，如果自身提供了控制点请求的服务，设备将通过单播的方式直接响应控制点的请求。

在 IPv4 环境，当需要使用多播方式传送相关消息的时候 SSDP 一般使用多播地址239.255.255.250 和 UDP 端口号 1900。根据互联网地址指派机构的指派 SSDP 在 IPv6 环境下使用多播地址 FF0X::C 这里的 X 根据 scope 的不同可以有不同的取值。

自此，你只需要知道支持 SSDP 协议的控制点或服务，接入网络后会首先以多播方式声明和查找设备，当收到别的设备发来的查询时，如果自身提供了控制点请求的服务，再以单播的方式进行回复。

典型的设备查询请求消息格式：

M-SEARCH * HTTP/1.1
S:uuid:ijklmnop-7dec-11d0-a765-00a0c91e6bf6
Host:239.255.255.250:1900
Man:"ssdp:discover"ST:ge:fridge
MX:3

典型的响应消息格式：

HTTP/1.1 200 OK
Cache-Control: max-age= seconds until advertisement expires
S: uuid:ijklmnop-7dec-11d0-a765-00a0c91e6bf6
Location: URL for UPnP description for root device
Cache-Control: no-cache="Ext",max-age=5000ST:ge:fridge // search targetUSN: uuid:abcdefgh-7dec-11d0-a765-00a0c91e6bf6 // advertisement UUIDAL: <blender:ixl><http://foo/bar>

响应消息应该包含服务的位置信息（Location 或AL头），ST 和 USN 头。响应消息应该包含cache 控制信息（max-age 或者 Expires头）。

其实谈论 SSDP 是绕不开 UPnP 协议，要想把它们都讲清楚，可不是这篇文章的任务，感兴趣的朋友可以参考文未给出的链接，限于篇幅关于 SSDP 的介绍就此结束。

二、模拟查找 SSDP 设备

为了能更好的解决网络问题，我们需要进入到数据包层次。在这一层次，没有任何东西能够逃出我们的视线范围。首先，我需要复现 SSDP 通信的整个流程。

2.1 Linux 发现 SSDP 服务

这里我利用 Linux 发行版自带的 gssdp-discover （推荐）命令，安装如下：

sudo apt-get install gupnp-tools

UBUNTU@192.168.100.142 下执行：

gao@ubuntu:~$ gssdp-discover -i eth0 --timeout=3
Using network interface eth0
Scanning for all resources
Showing "available" messages
resource availableUSN:      uuid:e90f107d-5086-4516-af02-493389e5574cLocation: http://192.168.100.1:1900/rootDesc.xml
resource availableUSN:      uuid:0e594edd-c5d4-4f0b-a216-85d0a58c460c::urn:schemas-upnp-org:service:ContentDirectory:1Location: http://192.168.100.167:2869/upnphost/udhisapi.dll?content=uuid:0e594edd-c5d4-4f0b-a216-85d0a58c460c
resource availableUSN:      uuid:50809696-105a-3721-e8b8-f084c96d1c54::upnp:rootdeviceLocation: http://192.168.100.196:52869/dscdesc.xml

执行后，在网络上找到了 3 台设备。

2.2 Windows 发现 SSDP 服务

这里利用一个 PYTHON 程序来实现，程序向一个多播地址发送查询请求，并监听其它支持设备的应答。

import socket
import sysdst = "239.255.255.250"
if len(sys.argv) > 1:dst = sys.argv[1]
st = "upnp:rootdevice"
if len(sys.argv) > 2:st = sys.argv[2]msg = ['M-SEARCH * HTTP/1.1','Host:239.255.255.250:1900','ST:%s' % (st,),'Man:"ssdp:discover"','MX:1','']s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
s.settimeout(10)
s.sendto('\r\n'.join(msg).encode('ascii'), (dst, 1900) )while True:try:data, addr = s.recvfrom(32*1024)except socket.timeout:breakprint ("[+] %s\n%s" % (addr, data))

Windows10@192.168.100.192 下执后，在网络上只能找到了 1 台设备。经测试程序在所有机器下执行结果都一样，不知是不是受构造包大小不同的影响（安全较严格的系统会丢弃不规范的包）这也是我推荐使用 gssdp-discover 来查找 SSDP 设备原因。

[+] ('192.168.100.1', 1900)
b'HTTP/1.1 200 OK\r\nCACHE-CONTROL: max-age=120\r\nST: upnp:rootdevice\r\nUSN: uuid:e90f107d-5086-4516-af02-493389e5574a::upnp:rootdevice\r\nEXT:\r\nSERVER: TP-LINK/2.0 UPnP/1.1 MiniUPnPd/2.0\r\nLOCATION: http://192.168.100.1:1900/rootDesc.xml\r\nOPT: "http://schemas.upnp.org/upnp/1/0/"; ns=01\r\n01-NLS: 1514736021\r\nBOOTID.UPNP.ORG: 1514736021\r\nCONFIGID.UPNP.ORG: 1337\r\n\r\n'

三、Windows 10 VS Windows 7 数据包

两台机器同时抓取由 gssdp-discover 命令发送的包。截图省去了不必要的只给差异部分。

• Windows 10
  

• Windows 7
  

在 Windows 10 和 Windows 7 上都收到了来自 192.168.100.142 设备的查询包。 而 Windows 7 还以单播方式向对方进行了应答，通过查看数据包细节 Server 项，它还告知对方自身提供了那些服务。

四、回答先前的问题

回答 1：Windows 10 系统开启了 SSDP 服务，为何不响应 SSDP Discovert 消息。

希望你注意到了在 SSDP 协议极简介绍 中，我标记的这段话 "…如果自身提供了控制点请求的服务，再以单播的方式进行回复。”

其实我和这位朋友都犯了同一种错误，认为只要支持 SSDP 协议并开启了 1900 端口的设备，都必定会提供服务并响应来自网络上其它设备的查询。在这种错误的认知下，就有了开头那段"啼笑皆非"的对话。

结论：开启了 1900 端口的控制点（如，Windows 10）本身不提供 UPnP 服务，就不会响应 SSDP 包。

回答 2：为什么说 Windows 10 不会被 DDoS SSDP反射攻击利用

SSDP 反射攻击原理：攻击者伪造成被攻击者的 IP 向互联网（或内网）上大量支持 SSDP 服务的设备发起 SSDP 请求（多播），网络上接收到请求的所有设备根据源 IP 地址将响应数据包返回给受害者（攻击被放大）。

结论：Windows 10 虽然开启了 1900 端口，但它是做为 UPnP 的控制点的存在，并不提供UPnP服务，因此不会响应SSDP包。而且 UPnP多个缓冲区溢出漏洞 的利用是通过构造特殊的或超长的 SSDP 包来触发。因此可得：Windows 10 作为 UPnP 控制点，即使开了 1900 端口也不受该漏洞影响。

五、SSDP 协议的 DDoS 攻击的防御措施

对于不需要启用即插即用服务的设备，将即插即用服务停止运行。如，家用路由器出厂设置默认开启此功能的，需要手动将其关闭，同时应检查确认所有连接外网的设备没有将即插即用服务暴露于互联网上，对非信任网络禁用 SSDP 协议，以防设备被攻击者利用为攻击发射点，另外，除 SSDP 服务之外，应检查屏蔽设备未用协议，关闭相应无用端口。

在攻击目标侧，引入 DDoS 防御技术。如，流量清洗，其原理是，对业务流量进行实施监控分析，如果检测到遭受DDoS攻击，则改变业务流量的流向，将其导引到流量清洗中心，由清洗中心对流量进行清洗，将攻击流量数据包直接抛弃，将正常业务流量再回注到业务网络。 此技术通道采用旁路工作方式，可有效避免单点故障和网络瓶颈，是当前行之有效的 DDoS 攻击防御技术。

参考：

• 反黑风暴·记一次遭遇 SSDP DDoS 和 EternalBlue（永恒之蓝）攻击经历_半点闲的博客-CSDN博客_eternalblue攻击

• [Microsoft SSDP Provider](SSDP Provider | Microsoft Learn)

• [Stupidly Simple DDoS Protocol (SSDP) generates 100 Gbps DDoS](Stupidly Simple DDoS Protocol (SSDP) generates 100 Gbps DDoS (cloudflare.com))