Случайно я заметил странные записи в журнале брандмауэра на моем компьютере:
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 box, подключенный к Smart TV. Я не вижу причин, по которым TV Box должен пытаться отправлять сообщения компьютерам в сети, особенно на случайных портах, как это, судя по журналу, и происходит.
Прав ли я, делая вывод, что DVR-бокс заражен и запущен какой-то сканер уязвимостей?
ОБНОВЛЕНИЕ 1
Поскольку я хотел получить полную картину, а не только заблокированный брандмауэром трафик, я пошел дальше и выполнил несколько tcpdump-ов на своем компьютере, связанных с рассматриваемым хостом: 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 пришел законный ответ, он был заблокирован.
Это проясняет первую группу сообщений. Я бы все же хотел узнать, что вызывает вторую группу.
решение1
Это может происходить по множеству причин, поэтому не спешите делать выводы. Многие устройства с доступом в Интернет выполняют сканирование сети на периодической основе или при выполнении определенных условий. Поскольку первое, похоже, не соответствует действительности, DVR мог обнаружить изменение в сети, например, новое устройство, отправляющее пакеты, изменение сетевой безопасности, при котором предварительный ключ остался прежним (например, с WPA на WPA2), или даже разницу в версиях протоколов, вызванную автоматическим обновлением маршрутизатора. Это всего лишь несколько причин, по которым устройство может выполнить это действие.
Мой вам совет - запустите сканирование сети. Вы можете сделать это с помощью различных инструментов, таких какNMap, очень популярный бесплатный инструмент для составления карт сети, который предлагает как командную строку, так и графические параметры. NMap и большинство других инструментов для составления карт сети предоставляют множество подробностей о сопоставленных устройствах, поэтому я бы рекомендовал составить карту вашей сети и удалить все подозрительные IP-адреса. С современным изобилием фильтрации портов, принудительно применяемой провайдером, и сетевых брандмауэров «включенных по умолчанию», большинство распространенных атак теперь происходят изнутри сети (например, находящийся поблизости злоумышленник получил доступ к вашей сети Wi-Fi, вошел в систему и начал вредоносные атаки). Поэтому составление карты вашей сети будет вашим лучшим выбором для поиска вредоносных объектов. Вы также можете использовать систему обнаружения вторжений в сеть, такую какФырканье. При условии, что вы используете беспроводную сеть, первым логичным шагом будет смена предварительного общего ключа (или «пароля») на надежный, желательно случайно сгенерированный ключ. Как уже упоминалось, большинство атак исходят из вашей сети, поэтому, если у злоумышленника нет постоянного доступа к устройству в вашей сети и/или физического доступа к вашему маршрутизатору, это остановит многих злоумышленников, по крайней мере временно.