Dominios generados y puertos raros

Cuando un programa prueba nombres de una lista generada, el DNS lo delata así: muchas consultas seguidas desde un mismo equipo, nombres de aspecto aleatorio bajo un mismo sufijo, casi todas con NXDOMAIN y, al final, una que sí resuelve. Los nombres que fallaron no sirven de mucho: mañana serán otros. Lo que sirve es el que resolvió, la dirección a la que apuntó y la forma de la ráfaga, que se puede describir en una regla de detección.

Un nombre de aspecto aleatorio, por sí solo, no basta: hay redes de contenidos que usan nombres así a propósito.

Abre SELECT * FROM consultas_dns. Hay una ráfaga de nombres de diez caracteres bajo el mismo sufijo. La cifra de fallos es parte del informe porque da el tamaño de la ráfaga, y se obtiene contando la columna rcode, no a ojo.

Entre las consultas con respuesta hay dos que parecen aleatorias. Una de ellas está bajo un dominio de la base de ruido (cdn-fuentes.example, la red de contenidos del sistema invitado): aunque el subdominio sea raro, es del propio equipo. La otra no está en la base. Compara con SELECT * FROM base_ruido.

Aspecto aleatorio más ninguna explicación en el ruido más una respuesta es la combinación que se lleva a la lista de indicadores.

Los flujos que no son DNS ni HTTP se leen con cuatro datos: protocolo, destino, puerto y volumen. La web va por el 80 y el 443; el 123 es hora. Un flujo TCP a otro puerto, sin saludo TLS y sin cabeceras HTTP que el sensor reconozca, se anota como protocolo desconocido: no se afirma qué es.

Abre SELECT * FROM flujos.

Un eco de ICMP (el «ping») normalmente lleva pocos bytes de datos; en esta red, 32. La captura trae 200 ecos de 512 bytes hacia la misma dirección a la que resolvió el nombre de la tarea 3. Un tamaño fuera de lo normal es una característica, y se anota como tal. Que ese espacio se use para llevar datos es una hipótesis que solo se comprueba mirando si el contenido de los ecos se repite o parece información, y eso no está en este registro.