Leer la cabecera de una regla de Suricata

Una regla se lee de izquierda a derecha en tres bloques. El primero es la acción, una sola palabra. El segundo es la cabecera: protocolo, dirección y puerto de origen, una flecha que marca el sentido, y dirección y puerto de destino. El tercero son las opciones, entre paréntesis y separadas por punto y coma, donde está lo que la regla busca y cómo se identifica.

Esa división es útil porque cada bloque responde una pregunta distinta. La cabecera decide a qué paquetes se mira; las opciones deciden qué se busca en ellos; la acción decide qué pasa al coincidir. Una regla bien leída se resume sola: «esto, sobre este tráfico, hace aquello».

El primer campo de la cabecera es el protocolo. Puede ser de transporte (tcp, udp, icmp) o de aplicación (http, dns, tls): con uno de aplicación, la regla solo se evalúa sobre conexiones donde el sensor reconoció ese protocolo, sin importar el puerto. Después van el origen y su puerto, la flecha, y el destino y su puerto. any en un puerto significa «cualquier puerto de ese lado», y en tráfico de clientes el puerto de origen suele ser un número alto al azar, por eso casi nunca se fija.

El puerto de destino es el que más dice: es el servicio al que se dirige el tráfico. Abre local.rules y busca la regla que vigila el escritorio remoto desde fuera.

Las direcciones casi nunca se escriben a mano: se usan variables. $HOME_NET son las direcciones de la casa y $EXTERNAL_NET es todo lo demás; en Fundición Tunjuelo están definidas en LEEME-sensor.txt. Si la variable está mal definida, la regla mira donde no debe y no avisa de nada, así que lo primero al heredar un sensor es leer cómo están definidas.

La flecha -> fija el sentido: lo de la izquierda es quien inicia, lo de la derecha, a quien se dirige. Una cabecera con $EXTERNAL_NET a la izquierda vigila lo que entra; con $HOME_NET a la izquierda, lo que sale. Es una diferencia que cambia el significado de una alerta entera: «alguien de fuera toca un servicio nuestro» y «un equipo nuestro habla con un servicio de fuera» son historias distintas.

La acción es una sola palabra y cambia lo que ocurre al coincidir. alert genera una alerta. drop descarta el paquete y genera la alerta, pero solo bloquea de verdad si el sensor está en línea, en el camino del tráfico; si recibe una copia, no puede detener nada. reject descarta y además envía un aviso de cierre. pass deja pasar el tráfico y deja de inspeccionarlo.

El sensor ftj-ids-01 está en línea delante de la DMZ, de modo que sus reglas drop sí cortan. Una sola de las ocho reglas locales usa esa acción, y por eso es la que más cuidado merece: una regla equivocada que bloquea corta tráfico legítimo, y quien lo nota es el usuario.

Una regla pass es un agujero en la vigilancia puesto a propósito. Se usa, por ejemplo, para que el sensor no tropiece con el escáner de vulnerabilidades de la propia casa, que hace exactamente lo que una regla de reconocimiento busca. Pero «dejar pasar» significa que nada de lo que haga esa dirección se inspecciona: ni lo que molestaba ni lo demás.

Por eso se lee con lupa: ¿quién es la dirección, hay un ticket que la explique, sigue siendo suya? Una excepción que nadie revisa se convierte en el mejor escondite. Localiza la regla pass de local.rules y anota a qué dirección de origen deja sin inspeccionar.