ТВ-бокс заражен?

Question

Я случайно заметил на своем компьютере странные записи журнала брандмауэра, подобные следующим:

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

Устройство с IP-адресом SRC представляет собой коробку Telus DVR, подключенную к Smart TV. Я не вижу причин, по которым TV Box должен пытаться отправлять сообщения на компьютеры в сети, особенно на случайные порты, как это, похоже, происходит из журнала.

Правильно ли я пришел к выводу, что видеорегистратор был заражен и работает какой-то сканер уязвимостей?

ОБНОВЛЕНИЕ 1

Поскольку я хотел получить полную картину, а не только трафик, заблокированный брандмауэром, я пошел дальше и выполнил на своем компьютере несколько tcpdump-s, связанных с рассматриваемым хостом: tcpdump -i wlp2s0 -n "src host 192.168.1.65 or dst host 192.168.1.65" (обратите внимание, что, хотя я слушаю по интерфейсу Wi-Fi, сама телевизионная приставка находится в сети Ethernet, если это имеет значение)

Результатом стала куча многоадресных запросов:

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 каждую минуту или около того. Из-за того, как он закодирован, эти запросы используют, казалось бы, случайные порты и, таким образом, когда из TV Box поступил законный ответ, он был заблокирован.

Это уточняет первую группу сообщений. Я хотел бы еще знать, что вызывает вторую группу.

Answer 1

Это может происходить по множеству причин, поэтому не спешите с выводами слишком быстро. Многие устройства с подключением к Интернету выполняют сканирование сети на периодической основе или при соблюдении определенных условий. Поскольку первое, кажется, не имеет место, DVR, возможно, обнаружил изменение в сети, такое как новое устройство, отправляющее пакеты, изменение в сетевой безопасности, в котором предварительный общий ключ остался тем же самым (то есть WPA к WPA2), или даже разница в версиях протокола, вызванная автоматическим обновлением маршрутизатора. Это всего лишь несколько причин, по которым устройство будет выполнять это действие.

Мой вам совет - запустить сканирование сети. Вы можете сделать это с помощью различных инструментов, таких как NMap, очень популярный бесплатный инструмент сетевого сопоставления, который предлагает как командную строку, так и графические опции. NMap и большинство других инструментов сетевого сопоставления предоставляют много подробностей о подключенных устройствах, поэтому я бы предложил составить карту вашей сети и исключить любые подозрительные IP-адреса. Благодаря современному изобилию фильтрации портов с применением интернет-провайдера и межсетевых экранов "по умолчанию по умолчанию" большинство распространенных атак теперь происходят изнутри сети (например, злоумышленник, находящийся поблизости, получил доступ к вашей сети Wi-Fi и зарегистрировался в сети). и запустил вредоносные атаки). Таким образом, картирование вашей сети будет лучшим выбором для обнаружения вредоносных объектов. Вы также можете использовать систему обнаружения вторжений в сеть, такую как Snort. При условии, что вы используете беспроводную сеть, первым логическим шагом будет изменение предварительно общего ключа (или "пароля") на надежный, предпочтительно случайно сгенерированный ключ. Как упоминалось ранее, большинство атак происходит из вашей сети, поэтому, если злоумышленник не имеет постоянного доступа к устройству в вашей сети и / или не имеет физического доступа к вашему маршрутизатору, это остановит многих злоумышленников, по крайней мере, временно.