Las opciones de una regla, y quién las cambió

Dentro de los paréntesis, cada opción es un trozo de la regla. msg es el texto que saldrá en la alerta. Opciones como http.uri, http.host, http.user_agent, dns.query o tls.sni señalan en qué parte del tráfico se busca (el «buffer»), y la que viene después, content, es lo que se busca allí. La misma cadena buscada en otra parte del tráfico es otra regla: un nombre en el campo del servidor al que se pide no significa lo mismo que ese nombre dentro de la ruta.

nocase hace que las mayúsculas no importen. Si una regla tiene content sin un buffer delante, busca en el contenido en general, lo que casi siempre es menos preciso y más propenso a falsos positivos.

La forma más rápida de saber qué vigila una regla es leer su buffer y su content juntos. La tabla reglas_opciones los desglosa en columnas para que no haya que descifrar la línea completa. Tras leerlas, la regla de la petición web a una zona de administración se resume en una frase: «cuando alguien de fuera pide una ruta que contiene tal cosa».

Esa «tal cosa» es lo que hay que poder decir de memoria al ver la alerta, porque es lo único que el sensor comprobó. Todo lo demás, que la petición funcionara o no, hay que ir a buscarlo a otro registro.

La opción flow:established,to_server limita la regla a conexiones ya abiertas y a lo que va hacia el servidor. Sin ella, la regla podría coincidir con la respuesta del servidor, con intentos que no llegaron a completar el saludo, o con tráfico que solo viaja en el sentido contrario. Es una de las opciones que más falsos positivos evita sin costar nada.

Mira en la tabla qué reglas la llevan y cuáles no. Una regla de contenido web sin flow puede disparar por lo que contesta un servidor, y entonces la alerta apunta al lado equivocado de la conversación.

Cada regla lleva dos números: el sid, su identificador, y la rev, su revisión, que sube en uno cada vez que alguien la modifica. Una alerta que dice sid:5200002; rev:3 indica no solo qué regla coincidió sino con qué versión. Cuando una regla empieza a comportarse distinto, lo primero que se mira es si cambió su rev y qué cambió.

El historial dice cuándo, quién y qué. Es evidencia de la misma clase que un registro de acceso: no sirve para culpar, sirve para saber a quién preguntar «¿qué querías conseguir con este cambio?» antes de revertirlo.

classtype clasifica la regla en una familia reconocida —reconocimiento, ataque a una aplicación web, violación de política, actividad miscelánea— y de ahí salen la categoría que se ve en la alerta y, a menudo, su prioridad. La opción priority la fija a mano, y 1 es la más alta. La clasificación no dice si la alerta es cierta: dice qué tipo de cosa intenta describir la regla.

Sirve para ordenar la cola y para saber a qué equipo mandar la alerta. Lee la regla que vigila las ráfagas de conexiones al puerto de acceso remoto seguro y anota su clasificación.