Anatomía de una regla de red

Una regla de Suricata tiene tres partes. La acción dice qué pasa si coincide: alert genera una alerta; drop descarta el paquete y alerta, lo que solo tiene efecto si el sensor está en línea con el tráfico; pass deja de inspeccionarlo. El encabezado dice qué tráfico se mira: protocolo, origen y puerto, dirección de la flecha, destino y puerto. Las opciones van entre paréntesis, separadas por punto y coma, y dicen qué se busca dentro de ese tráfico y cómo se identifica la regla.

Abre la terminal y lee cat perimetro-guachucal.rules. En la primera regla, dns $HOME_NET any -> any any es el encabezado: consultas DNS que salen de la red propia hacia cualquier sitio. dns.query le dice al motor que mire solo el nombre consultado, y content lo que tiene que encontrar ahí.

Cada regla se identifica con sid, un número que debe ser único, y con rev, su versión, que sube cada vez que alguien la cambia. El sid es lo que ven el tablero, el SOC y los informes: si dos reglas comparten sid, sus alertas se mezclan y nadie puede decir cuál disparó. Por eso, al revisar un archivo de reglas, lo primero es comprobar que ningún sid se repite.

Lee las seis reglas fijándote solo en el final de cada línea.

Una regla puede estar bien escrita y no servir. Si busca algo en un lugar que el sensor no ve, no disparará nunca, y su silencio parecerá una buena noticia. Las palabras clave de cada protocolo miran un dato concreto: http.host mira el encabezado Host de una petición HTTP, que solo se lee si la petición va en claro; tls.sni mira el nombre pedido en el saludo TLS, que se ve aunque la conexión vaya cifrada.

Lee cat notas-del-sensor.txt y vuelve a las reglas. Busca la que mira un dato que, según las notas, este sensor nunca va a tener.

Una regla con un content muy corto y genérico coincide con miles de nombres legítimos. No vigila a ningún actor: llena el tablero y entierra lo que importa. Al medir lo que dieron las reglas del informe hay que separar esa regla de las demás, porque su volumen no dice nada de la campaña.

Lee cat alertas-7-dias.txt. Identifica la regla de contenido genérico en el archivo de reglas y déjala fuera de la cuenta.

La regla de las direcciones del actor va por su tercera revisión. Quien la mantiene cambió algo tres veces, y cada cambio debe quedar contado para que el SOC sepa qué versión estaba activa cuando llegó una alerta.