Por cierto, noté entradas extrañas en el registro del firewall como las siguientes en mi computadora:
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
El dispositivo con la dirección IP SRC es una caja Telus DVR, conectada al Smart TV. No veo ninguna razón por la que una TV Box deba intentar enviar mensajes a computadoras en la red, especialmente en puertos aleatorios, como parece ser el caso según el registro.
¿Estoy en lo cierto al concluir que la caja del DVR ha sido infectada y está ejecutando algún escáner de vulnerabilidades?
ACTUALIZACIÓN 1
Como quería obtener una imagen completa, no solo el tráfico bloqueado por el firewall, seguí adelante y realicé algunos tcpdump-s en mi computadora, relacionados con el host en cuestión: tcpdump -i wlp2s0 -n "src host 192.168.1.65 or dst host 192.168.1.65"(tenga en cuenta que, aunque estoy escuchando en una interfaz wifi , la caja de TV en sí está en Ethernet, si es importante)
El resultado fue un montón de solicitudes de multidifusión como estas:
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
cada uno de los mensajes tiene contenido como este:
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>
luego, de vez en cuando, las solicitudes familiares bloqueadas por el firewall:
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
con contenido:
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
Esto me sugeriría una implementación de SSDP defectuosa, pero cualquier aportación de personas con conocimientos podría arrojar luz sobre la situación.
ACTUALIZACIÓN 2
Encontré al culpable del grupo de mensajes bloqueados por el firewall (192.168.1.65:1900 -> my.computer:random_port). Google Chrome siguió enviando solicitudes de descubrimiento de SSDP en multidifusión aproximadamente cada minuto. Debido a la forma en que está codificada, estas solicitudes utilizan puertos aparentemente aleatorios y, por lo tanto, cuando llega una respuesta legítima de la TV Box, se bloquea.
Esto aclara el primer grupo de mensajes. Todavía me gustaría saber qué causa el segundo grupo.
Respuesta1
Esto puede estar sucediendo por una multitud de razones, así que no saque conclusiones precipitadas. Muchos dispositivos con acceso a Internet realizan análisis de una red de forma periódica o cuando se cumplen determinadas condiciones. Como lo primero no parece ser el caso, es posible que el DVR haya detectado un cambio en la red, como un nuevo dispositivo enviando paquetes, un cambio en la seguridad de la red en el que la clave precompartida sigue siendo la misma (es decir, WPA a WPA2), o incluso una diferencia en las versiones de protocolo provocada por una actualización automática del enrutador. Estas son sólo algunas de las razones por las que el dispositivo realizaría esta acción.
Mi consejo para usted es que ejecute un análisis de red. Puedes hacer esto usando una variedad de herramientas, comoNMapa, una herramienta gratuita de mapeo de redes muy popular que ofrece opciones gráficas y de línea de comandos. NMap y la mayoría de las otras herramientas de mapeo de redes brindan muchos detalles sobre los dispositivos mapeados, por lo que sugeriría mapear su red y eliminar cualquier dirección IP sospechosa. Con la abundancia moderna de filtrado de puertos aplicado por los ISP y firewalls en toda la red "habilitados por defecto", los ataques más comunes ahora provienen del interior de la red (por ejemplo, un atacante cercano ha obtenido acceso a su red Wi-Fi y ha iniciado sesión). y lanzaron ataques maliciosos). Por lo tanto, mapear su red será su mejor opción para encontrar entidades maliciosas. También podría emplear un sistema de detección de intrusiones en la red comoBufido. Siempre que esté utilizando una red inalámbrica, el primer paso lógico sería cambiar la clave previamente compartida (o "contraseña") por una clave segura, preferiblemente generada aleatoriamente. Como se mencionó anteriormente, la mayoría de los ataques provienen de su red, por lo que, a menos que el atacante tenga acceso persistente a un dispositivo en su red y/o tenga acceso físico a su enrutador, esto detendrá a muchos atacantes, al menos temporalmente.