Leer conn.log y dns.log

En conn.log cada fila es una conversación. Los campos orig_bytes y resp_bytes cuentan la carga que envió quien abrió la conversación y la que envió quien la recibió. En una navegación normal el puesto manda una petición pequeña y recibe una página grande: más bajada que subida.

Cuando un puesto de oficina manda mucho más de lo que recibe, la conversación parece una subida. Es una pregunta, no un veredicto: puede ser un respaldo o un archivo adjunto. Pero es una de las primeras cosas que se mira cuando se busca datos que salen.

Consulta conn.

La conversación con más bytes del día suele ser el respaldo programado, y eso no es noticia. El trabajo está en separar lo que se espera de lo que no. Aquí hay un servidor que sube 214000000 bytes y es lo normal para ese servidor, que hace los respaldos.

Lo que sí hay que mirar es un puesto de oficina que sube más de lo que recibe. Revisa los puestos (los equipos de contabilidad, compras y bodega, no los servidores) y quédate con la conversación en la que el puesto manda más de lo que recibe. El uid es lo que se anota en el caso.

Un equipo que pide muchos nombres que no existen en pocos segundos se parece poco a una persona escribiendo mal una dirección. Una persona se equivoca una vez y corrige. Un programa que prueba nombres generados falla muchas veces seguidas. La respuesta NXDOMAIN de dns.log es la que dice «ese nombre no existe».

Cuenta las consultas con ese resultado por equipo. No basta con la dirección: el inventario le pone nombre, y el nombre es lo que va al ticket.

En conn hay dos filas seguidas de un mismo puesto hacia una misma dirección, ambas con estado S0: se vio el intento de conexión y no hubo respuesta. Antes de preguntarse por qué, conviene saber a qué nombre corresponde esa dirección, porque en el registro de conexiones solo hay números.

El nombre se saca de dns.log: la consulta anterior, del mismo equipo, cuya respuesta (answers) es esa dirección. Se unen por la dirección de la respuesta y por la hora, porque el uid de una consulta es el de su conversación con el servidor DNS, no el de la que vino después.

El nombre existía (la respuesta fue NOERROR y devolvió una dirección) pero la conversación nunca se estableció: no hubo respuesta al primer paquete, y el puesto lo volvió a intentar tres segundos después. Un nombre que se resuelve y un servidor que no contesta tiene varias lecturas, y el registro solo permite descartar algunas.