Anatomía de una regla de IDS

Una regla se lee de izquierda a derecha en tres bloques. El primero es la acción, una sola palabra: alert avisa, drop avisa y descarta el paquete cuando el sensor está en línea, pass deja pasar sin seguir inspeccionando y reject además envía un aviso de cierre al origen. El segundo es la cabecera: protocolo, dirección y puerto de origen, una flecha que indica 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.

La cabecera casi nunca lleva direcciones escritas a mano: usa variables como $HOME_NET, las direcciones de la casa, y $EXTERNAL_NET, todo lo demás. Si la variable está mal definida, la regla mira donde no debe y no avisa de nada. Por eso SELECT * FROM variables es lo primero que se abre al heredar un sensor.

Dentro de los paréntesis, cada opción es un trozo de la regla. msg es el texto que aparecerá en la alerta. flow:established,to_server limita la regla a conexiones ya abiertas y a lo que va hacia el servidor, lo que evita coincidir con las respuestas. Opciones como http.host, http.uri o http.user_agent señalan en qué parte de la petición se busca, y la que viene después, content, es lo que se busca allí. Una cadena, la misma, buscada en otra parte de la petición es otra regla.

nocase hace que no importen las mayúsculas. classtype clasifica la regla, y sid y rev la identifican, como verás en la tarea 5.

Lee la regla de las visitas a sitios de la lista de vigilancia: el sitio que vigila es lo que busca después de la opción que señala el campo de la petición donde mirar.

Algunas reglas no coinciden con una sola petición sino con una cantidad de ellas. La opción threshold fija cuántas coincidencias y en cuánto tiempo hacen saltar la alerta, y a quién se le cuentan: track by_src las cuenta por origen, de modo que diez conexiones de diez orígenes distintos no suman. Con type both, la regla avisa una vez al llegar al número y calla hasta que pasa el intervalo, en lugar de avisar por cada conexión.

Esto importa al leer una alerta. Una sola conexión al puerto 22 no es nada; la regla de ráfaga existe para el momento en que un mismo origen insiste. Y si el umbral es demasiado bajo, salta con cualquier equipo que reintente; si es demasiado alto, no salta con quien va despacio.

La flecha de la cabecera tiene sentido. Una regla $EXTERNAL_NET any -> $HOME_NET any vigila lo que entra; una $HOME_NET any -> $EXTERNAL_NET any vigila lo que sale. Es una diferencia que cambia el significado de una alerta entera: «alguien de fuera pide una ruta de administración» y «alguien de dentro usa un agente de usuario no aprobado» son historias distintas aunque la regla sea casi la misma frase.

La palabra any en el puerto no significa «cualquier cosa»: significa cualquier puerto de ese lado. Y los puertos del origen, en tráfico de clientes, casi siempre son números altos al azar, por eso casi nunca se fijan.

Cada regla lleva dos números. El sid es su identificador, que no se repite, y la rev es su revisión: sube en uno cada vez que alguien la modifica. Una alerta que lleva sid:3100001; rev:3 dice no solo cuál regla coincidió sino con qué versión. Cuando una regla empieza a comportarse distinto, lo primero que se mira es si su rev cambió y qué cambió, porque cambiar una regla es cambiar lo que el SOC verá a partir de ese día.

Los cambios de las reglas están en historial. Una regla puede pasar de alert a drop cuando se confía en ella, y eso es un cambio de alcance, no de texto: de repente lo que antes era una alerta es un bloqueo.