我偶然注意到我的計算機上有奇怪的防火牆日誌條目，如下所示：
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 和大多數其他網路映射工具提供了映射設備的大量詳細信息，因此我建議映射您的網路並根除任何可疑的 IP 位址。隨著現代豐富的 ISP 強制連接埠過濾和「預設啟用」網路範圍的防火牆，現在最常見的攻擊來自網路內部（例如，附近的攻擊者已獲得對您 Wi-Fi 網路的存取權限，並記錄了並發動惡意攻擊）。因此，映射您的網路將是尋找惡意實體的最佳選擇。您也可以採用網路入侵偵測系統，例如鼻息。如果您使用的是無線網絡，第一個邏輯步驟是將預先共用金鑰（或「密碼」）變更為強密鑰，最好是隨機產生的密鑰。如前所述，大多數攻擊來自您的網路內部，因此除非攻擊者能夠持續存取您網路上的裝置和/或對您的路由器進行實體訪問，否則這將阻止許多攻擊者，至少是暫時阻止。