dns.log y http.log: lo que se pidió y lo que se contestó

En dns.log, query es el nombre pedido, qtype_name el tipo de dato (A pide una dirección IPv4, AAAA una IPv6) y rcode_name el resultado: NOERROR si el nombre existe y NXDOMAIN si no existe. Cuando la respuesta es correcta, answers trae las direcciones y TTLs cuánto tiempo pueden guardarlas los demás, en segundos.

Un NXDOMAIN suelto es normal: alguien escribió mal una dirección. Lo que se lee es el patrón: muchos NXDOMAIN seguidos desde un solo equipo, a nombres que no forman palabras, es lo que hace un programa que prueba nombres hasta dar con uno que existe.

Filtra dns_log por NXDOMAIN y mira cuántos hay por equipo.

Atar el patrón a un equipo es el siguiente paso: la columna id.orig_h dice quién preguntó. Con eso, el hallazgo deja de ser «hay nombres raros» y es «este equipo preguntó por nombres que no existen en ráfaga». Después se mira qué hizo ese mismo equipo cuando algún nombre sí resolvió.

El TTL es el tiempo, en segundos, que quien pregunta puede guardar la respuesta antes de volver a preguntar. Los servicios corrientes de una empresa suelen traer TTL de minutos u horas (el correo interno, 3600). Un TTL muy corto, de segundos, hace que la dirección pueda cambiarse con rapidez; algunos servicios legítimos lo usan, y algunos abusos también.

Por sí solo no prueba nada: es un dato que suma a otros. Compara en dns_log el TTL del nombre que sí resolvió tras la ráfaga con el de los demás nombres.

http.log trae lo que el cliente dijo de sí mismo: user_agent es la cadena con que se presenta el programa que hace la petición. Los navegadores de oficina traen la suya, muy repetida; una biblioteca de programación o una herramienta de línea de comandos trae otra. No es una prueba (se puede cambiar), pero una cadena que nadie más usa en la red es un buen primer filtro.

Sigue la cadena: el nombre con TTL de 30 resolvió a una dirección; busca en http_log las peticiones que fueron a esa dirección y lee su agente de usuario.

method distingue lo que se pide (GET) de lo que se envía (POST), y request_body_len cuánto se envió en el cuerpo. Una web de pedidos recibe POST legítimos con cuerpos de unos kilobytes; un POST hacia un destino que nadie reconoce es otra conversación. Contar los POST por equipo y por destino es una de las primeras agrupaciones que se hacen sobre http.log.

Cuenta en http_log las peticiones con método POST, sin importar su destino.