TV Box被感染了吗？

我顺便注意到我的计算机上出现了以下奇怪的防火墙日志条目：

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 - ＆gt; my.computer:random_port）。 Google Chrome每分钟左右都会保持多播SSDP发现请求。由于它的编码方式，这些请求使用看似随机的端口，因此，当来自TV Box的合法响应时，它被阻止。

这澄清了第一组消息。我还想知道导致第二组的原因。

这可能由于多种原因而发生，因此不要过快地得出结论。许多支持互联网的设备定期或在满足某些条件时执行网络扫描。由于前者似乎不是这种情况，DVR可能已经检测到网络中的变化，例如发送分组的新设备，预共享密钥保持不变的网络安全性的变化（即，WPA到WPA2），甚至是自动更新路由器触发的协议版本的差异。这些只是设备执行此操作的几个原因。

我的建议是运行网络扫描。您可以使用各种工具执行此操作，例如 NMap的 ，一种非常流行的免费网络映射工具，提供命令行和图形选项。 NMap和大多数其他网络映射工具提供了有关映射设备的大量详细信息，因此我建议将您的网络映射出来并根除任何可疑的IP地址。凭借现代丰富的ISP强制端口过滤和“默认启用”网络范围的防火墙，现在最常见的攻击来自网络内部（例如，附近的攻击者已获得对您的Wi-Fi网络的访问权限，并且已记录进入并发起恶意攻击）。因此，映射您的网络将是查找恶意实体的最佳选择。您还可以使用网络入侵检测系统，如 哼 。如果您使用的是无线网络，则第一个逻辑步骤是将预共享密钥（或“密码”）更改为强大的，最好是随机生成的密钥。如前所述，大多数攻击都来自您的网络，因此除非攻击者能够持续访问您网络上的设备和/或对您的路由器进行物理访问，否则这将阻止许多攻击者，至少是暂时的。