我偶然注意到我的计算机上有类似以下的奇怪的防火墙日志条目：
Apr 1 22:17:56 slavic-probook kernel: [23623.091873] [UFW BLOCK] IN=wlp2s0 OUT= MAC=d0:57:7b:60:3a:6a:18:b8:1f:27:ed:06:08:00 SRC=192.168.1.65 DST=192.168.1.70 LEN=323 TOS=0x00 PREC=0xA0 TTL=64 ID=39529 DF PROTO=UDP SPT=1900 DPT=49952 LEN=303
Apr 1 22:17:57 slavic-probook kernel: [23624.092666] [UFW BLOCK] IN=wlp2s0 OUT= MAC=d0:57:7b:60:3a:6a:18:b8:1f:27:ed:06:08:00 SRC=192.168.1.65 DST=192.168.1.70 LEN=323 TOS=0x00 PREC=0xA0 TTL=64 ID=39622 DF PROTO=UDP SPT=1900 DPT=49952 LEN=303
Apr 1 22:17:58 slavic-probook kernel: [23625.094162] [UFW BLOCK] IN=wlp2s0 OUT= MAC=d0:57:7b:60:3a:6a:18:b8:1f:27:ed:06:08:00 SRC=192.168.1.65 DST=192.168.1.70 LEN=323 TOS=0x00 PREC=0xA0 TTL=64 ID=40181 DF PROTO=UDP SPT=1900 DPT=49952 LEN=303
Apr 1 22:17:59 slavic-probook kernel: [23626.094239] [UFW BLOCK] IN=wlp2s0 OUT= MAC=d0:57:7b:60:3a:6a:18:b8:1f:27:ed:06:08:00 SRC=192.168.1.65 DST=192.168.1.70 LEN=323 TOS=0x00 PREC=0xA0 TTL=64 ID=40237 DF PROTO=UDP SPT=1900 DPT=49952 LEN=303
具有 SRC IP 地址的设备是 Telus DVR 盒，连接到智能电视。我看不出电视盒为什么要尝试向网络上的计算机发送消息，尤其是在随机端口上，因为从日志来看似乎确实如此。
我是否可以正确地得出 DVR 盒已被感染并且正在运行某些漏洞扫描程序？
更新 1
因为我想获得完整的画面，而不仅仅是防火墙阻止的流量，所以我继续在我的计算机上执行了一些与有问题的主机相关的 tcpdump-s :(tcpdump -i wlp2s0 -n "src host 192.168.1.65 or dst host 192.168.1.65"请注意，虽然我在 wifi 接口上监听，但电视盒本身在以太网上，如果重要的话）
结果是一堆如下的多播请求：
01:59:17.410558 IP (tos 0xa0, ttl 1, id 9041, offset 0, flags [DF], proto UDP (17), length 564)
192.168.1.65.40106 > 239.255.255.250.8082: [udp sum ok] UDP, length 536
01:59:20.482689 IP (tos 0xa0, ttl 1, id 11391, offset 0, flags [DF], proto UDP (17), length 564)
192.168.1.65.40106 > 239.255.255.250.8082: [udp sum ok] UDP, length 536
01:59:23.350033 IP (tos 0xa0, ttl 1, id 14259, offset 0, flags [DF], proto UDP (17), length 564)
192.168.1.65.40106 > 239.255.255.250.8082: [udp sum ok] UDP, length 536
01:59:26.421815 IP (tos 0xa0, ttl 1, id 16051, offset 0, flags [DF], proto UDP (17), length 564)
192.168.1.65.40106 > 239.255.255.250.8082: [udp sum ok] UDP, length 536
01:59:29.494329 IP (tos 0xa0, ttl 1, id 17699, offset 0, flags [DF], proto UDP (17), length 564)
192.168.1.65.40106 > 239.255.255.250.8082: [udp sum ok] UDP, length 536
每条消息的内容如下：
NOTIFY * HTTP/1.1
x-type: dvr
x-filter: f0e4ba33-5680-459b-8c3d-a4fdeffdb2f9
x-lastUserActivity: 4/2/2018 7:26:29 AM
x-location: http://192.168.1.65:8080/dvrfs/info.xml
x-device: 0d90b7cc-3fc2-4890-b2b9-8f7026732fd6
x-debug: http://192.168.1.65:8080
<node count='7102'><activities><schedver dver='3' ver='57' pendcap='True' /><x/><p15n stamp='08D514D5EC333DF818B81F27ED06'/><recordver ver='46' verid='355872864' size='962072674304' free='952610324480' /><x/></activities></node>
然后偶尔会出现熟悉的、被防火墙阻止的请求：
02:02:28.005207 IP (tos 0xa0, ttl 64, id 34066, offset 0, flags [DF], proto UDP (17), length 323)
192.168.1.65.1900 > 192.168.1.70.53280: [udp sum ok] UDP, length 295
02:02:28.900119 IP (tos 0xa0, ttl 64, id 34258, offset 0, flags [DF], proto UDP (17), length 323)
192.168.1.65.1900 > 192.168.1.70.53280: [udp sum ok] UDP, length 295
内容：
HTTP/1.1 200 OK
LOCATION: http://192.168.1.65:56790/dd.xml
CACHE-CONTROL: max-age=1800
EXT:
BOOTID.UPNP.ORG: 1
SERVER: Linux/2.6 UPnP/1.1 quick_ssdp/1.1
ST: urn:dial-multiscreen-org:service:dial:1
USN: uuid:0d90b7cc-3fc2-4890-b2b9-8f7026732fd6::urn:dial-multiscreen-org:service:dial:1
在我看来，这表明 SSDP 实施存在问题，但任何来自知识渊博人士的意见都可以阐明情况。
更新2
我找到了防火墙阻止的一组消息的罪魁祸首（192.168.1.65:1900 -> my.computer:random_port）。Google Chrome 每隔一分钟左右就会多播 SSDP 发现请求。由于其编码方式，这些请求使用看似随机的端口，因此，当电视盒发出合法响应时，它会被阻止。
这澄清了第一组消息。我仍然想知道导致第二组消息的原因。
答案1
这种情况可能由多种原因引起，所以不要太快下结论。许多支持互联网的设备会定期或在满足某些条件时对网络进行扫描。由于前者似乎不是这种情况，因此 DVR 可能检测到网络发生变化，例如新设备发送数据包、网络安全发生变化（预共享密钥保持不变）（即 WPA 变为 WPA2），甚至由路由器自动更新触发的协议版本差异。这些只是设备执行此操作的几个原因。
我的建议是运行网络扫描。您可以使用各种工具来执行此操作，例如NMap，一款非常流行的免费网络映射工具，提供命令行和图形选项。NMap 和大多数其他网络映射工具提供了大量有关映射设备的详细信息，因此我建议绘制网络图并根除任何可疑 IP 地址。随着现代 ISP 强制端口过滤和“默认启用”的网络范围防火墙的大量出现，现在最常见的攻击来自网络内部（例如，附近的攻击者已获得对您 Wi-Fi 网络的访问权限，并已登录并发起恶意攻击）。因此，绘制网络图将是您查找恶意实体的最佳选择。您还可以使用网络入侵检测系统，例如呼噜。如果您使用的是无线网络，那么第一个合乎逻辑的步骤就是将预共享密钥（或“密码”）更改为强密钥，最好是随机生成的密钥。如前所述，大多数攻击都来自您的网络内部，因此除非攻击者可以持续访问您网络上的设备和/或可以物理访问您的路由器，否则这将至少暂时阻止许多攻击者。