Falsos positivos y afinado del sensor

En la tabla de los últimos treinta días hay dos reglas con muchos disparos y pocas confirmaciones, y no son el mismo problema. La de la ráfaga de conexiones al puerto 22 describe algo que de verdad ocurre: desde internet, a todas horas, alguien prueba la puerta de los servidores. Disparó 1.284 veces y ninguna terminó en incidente, porque el servicio no está expuesto de forma que importe. La alerta es un verdadero positivo sin consecuencia. La otra, la de la biblioteca de scripts, describe algo que la casa hace a diario: es un falso positivo de la regla, porque lo que ve es normal aquí.

Se tratan distinto. El segundo se calla acotando la regla para el origen que lo explica. El primero no se calla: se le pone un umbral más alto o una prioridad baja, para que no llene la cola pero siga contando lo que pasa.

El primer paso de afinar una regla ruidosa no es tocarla: es saber quién la dispara. Si casi todos los disparos vienen de uno o dos orígenes, el ruido tiene nombre y probablemente tiene una explicación en una tarea programada. Si vienen de decenas de orígenes distintos, la regla está describiendo mal algo general y hay que corregir la regla, no un origen.

La regla 3100008 busca el agente de usuario de una biblioteca de scripts en las peticiones que salen a internet. Mira de dónde vienen sus disparos.

Antes de proponer un cambio hay que medir qué parte del problema resuelve. Si un solo origen explica el 20 % de los disparos, silenciarlo no cambia mucho la cola; si explica casi todo, es el cambio que más rinde. La medida es una división: los disparos del origen entre el total, por cien.

El total de la regla está en disparos_30d y la parte de ese equipo, en origen_3100008. Redondea a un número entero.

Silenciar una regla puede hacerse a tres tamaños. Se puede desactivar la regla, y se pierde para todos los equipos. Se puede escribir una regla pass para el equipo, y entonces el sensor deja de inspeccionar todo su tráfico, no solo lo que molestaba, y cualquier cosa rara que haga ese equipo mañana pasa sin mirar. O se puede suprimir esa regla solo para ese origen, con una línea de la forma suppress gen_id 1, sig_id N, track by_src, ip X, que la calla para esa dirección y deja la regla funcionando para todas las demás.

La regla de oro del afinado es que el alcance del cambio sea lo más cercano posible al del ruido: una regla, un origen. Lee las cuatro propuestas del turno anterior y compara qué calla cada una.

El ruido también existe del lado de la prevención, con un precio mayor. Una regla que solo avisa y se equivoca cuesta una fila en la cola; la misma regla en drop y equivocada corta tráfico legítimo, y quien lo nota es el usuario. Por eso una regla se deja en alerta durante una ventana antes de pasarla a bloqueo y se mira a quién habría cortado.

La tabla ensayo_de_prevencion es ese ensayo de 14 días para tres candidatas. Una de ellas habría bloqueado tráfico de un equipo legítimo. Es la que no se pasa a bloqueo hasta resolver ese caso.