Anatomía de una regla de red

Una regla de red tiene dos partes. La cabecera son siete campos en un orden fijo, separados por espacios; después, entre paréntesis, van las opciones separadas por punto y coma. La cabecera dice a qué tráfico mira; las opciones dicen qué se busca en él y cómo se identifica la regla.

Los dos motores comparten esta forma general, y por eso una persona que lee reglas de uno puede leer las del otro. Lo que cambia entre ellos son las palabras clave concretas de las opciones y algunas acciones, que verás en las salas siguientes.

La tabla partes_de_una_regla resume cada parte.

El sentido dice en qué dirección debe ir el tráfico para que la regla coincida. La flecha -> exige que vaya del origen al destino. El operador <> acepta cualquiera de las dos direcciones, y por eso se usa con cuidado: una regla bidireccional coincide también con las respuestas de los servidores, y casi siempre se pretende vigilar solo un sentido.

Lee las seis reglas de reglas_locales.

Entre las opciones, classtype asigna una clase a la alerta, y con ella una prioridad por defecto. Una regla sin clase genera alertas que no se pueden ordenar ni filtrar por categoría en el panel donde el turno las ve. No es un error de sintaxis: la regla carga, alerta y nadie nota que falta, por eso se descubre solo leyendo.

Cada regla se identifica por su sid, que no cambia, y por su rev, que sube cada vez que alguien la modifica. Una revisión alta en una regla propia indica que se ha retocado muchas veces, por falsos positivos, por cambios de direccionamiento o porque nadie fijó bien su intención. Es la primera candidata a una lectura atenta y a una ficha de detección completa.

El tráfico de una consulta de nombres, de una petición web o de un saludo de cifrado tiene campos propios, y las opciones de la regla permiten mirar uno de ellos y compararlo con un valor, como en la regla 7340002. La cabecera, en cambio, solo sabe de direcciones, puertos y del protocolo de aplicación.