El cortafuegos y el proxy como registro

El cortafuegos escribe una línea por cada conexión sobre la que decide: origen, destino, puerto, la acción —permitido o denegado— y el nombre de la regla que la decidió. Las reglas se leen en orden y gana la primera que encaja; casi todas las redes terminan con una regla que corta todo lo que nadie autorizó.

Es tentador leer un «denegado» como un final feliz: el cortafuegos hizo su trabajo y ya está. Para el turno es al revés. El corte está bien; lo que importa es que alguien o algo lo intentó. Un puesto que intenta salir directo, por un puerto poco común, una vez cada cinco minutos, no se arregla con la regla que lo corta: la regla solo te avisa de que en ese equipo hay algo que no usa el camino previsto.

Cada petición web lleva una cadena con la que el programa se presenta: el agente de usuario. Un navegador dice qué navegador es y en qué sistema corre; un programa escrito con una biblioteca de programación suele presentarse con el nombre de la biblioteca, porque nadie se molestó en cambiarlo. El proxy la registra en cada petición, también en las cifradas: va en la petición con la que el programa le pide al proxy que le abra el túnel.

La cadena la escribe el propio programa y se puede falsear, así que nunca prueba que algo sea legítimo. Pero cuando dice la verdad sin disimulo es una pista barata: en un puesto de oficina, lo normal es ver navegadores y el servicio de actualizaciones del sistema. Cualquier otra cosa se compara con la lista de lo aprobado. Agrupa las peticiones por equipo y agente.

El proxy le pone a cada destino una categoría de su base de datos —negocios, juegos de azar, actualizaciones de software— y decide según la política: unas se dejan pasar, otras se cortan. Un destino que su base no conoce queda «sin categoría», y muchas empresas lo dejan pasar porque bloquearlo rompería cosas a diario. Es justo la rendija por la que entra lo que se estrenó la semana pasada.

Fíjate también en la columna del usuario. El proxy pone el nombre de la sesión abierta en el equipo, y cualquier programa que corra en esa sesión sale con ese nombre. Que la petición lleve el nombre de una persona no prueba que esa persona estuviera navegando: con un agente de usuario de programa y una petición cada quince minutos clavados, lo más probable es que no.

Los dos registros miran la misma salida desde sitios distintos. El cortafuegos trabaja con direcciones y puertos: sabe que un equipo habló con otro, pero no cómo se llamaba el destino. El proxy trabaja con peticiones web: sabe el nombre, la categoría, la sesión y el agente de usuario. Con HTTPS y sin inspección del tráfico, ninguno de los dos ve la página concreta ni el contenido.

Por eso se leen juntos, con el inventario de puente: el cortafuegos habla de 10.4.70.algo y el proxy de nombres de equipo. Lo que no pasa por el proxy, el proxy no lo ve; y un programa que intenta las dos cosas —salir directo y salir por el proxy— deja la mitad de su historia en cada registro.

El mismo equipo no se conforma con el proxy: además intenta salir por su cuenta, hacia una dirección fija y por un puerto poco común, una vez cada cinco minutos. El cortafuegos lo corta cada vez y lo deja escrito. Ese destino es tan importante como el dominio de la tarea 3: es la otra mitad de lo que el programa intenta alcanzar, y lo primero que se bloquea y se busca en el resto del parque.