Bloqueo aplicado no es bloqueo verificado

Casi toda herramienta de bloqueo funciona igual: detecta un ataque, ejecuta un comando en el firewall y marca la IP como bloqueada. El problema está en la última parte. “Ejecuté el comando” y “la regla está ahí ahora” son afirmaciones distintas, y la distancia entre las dos es mayor de lo que parece.

Qué borra una regla sin avisar

En un servidor real, muchas cosas tocan el firewall además de tu herramienta de bloqueo:

• Reloads de otras herramientas. ufw, firewalld y CSF reconstruyen sus propias cadenas al recargar. Según cómo lo hagan, un salto que otra herramienta insertó en INPUT desaparece con ellas.
• Pelea por la posición. Las herramientas que quieren quedar arriba de INPUT pueden intercambiar lugares en ciclos. Le pasó al propio atalince con mailcow, que cambiaban de posición cada veinte segundos, hasta que la versión 1.0.2 del agente lo corrigió.
• Reinicio del servidor. Las reglas de iptables no sobreviven a un arranque por sí solas.
• Familias distintas. Un bloqueo que existe en IPv4 no protege nada si el ataque llega por IPv6 y el firewall de esa familia no está disponible.

En todos esos casos, el panel de la herramienta sigue diciendo “bloqueado”. Nadie mintió a propósito; solo nadie volvió a comprobar.

Cuatro estados, no uno

atalince muestra cada bloqueo como una ruta de cuatro etapas:

1. Detectado: el detector leyó el log e identificó el ataque.
2. Bloqueo solicitado: el panel se lo pidió al agente de ese servidor.
3. Aplicación informada por el agente: el agente lo aplicó y envió un recibo.
4. Lectura del firewall verificada: una lectura del kernel confirmó que la regla está ahí.

Las etapas 3 y 4 parecen iguales, pero no lo son. El recibo dice que el comando corrió sin error. La lectura dice que, en el momento en que el agente miró, el bloqueo seguía en pie.

Qué comprueba la lectura

Cada hora, el panel pide la lectura de los bloqueos activos. El agente aplica lo pendiente, repara los saltos y luego lee el kernel, comprobando tres cosas para cada bloqueo:

• INPUT salta a la cadena ATALINCE-BANS;
• la cadena tiene la regla de descarte del conjunto (-m set --match-set atalince-bans src -j DROP);
• la IP está dentro del conjunto atalince-bans.

Si una falla, el panel dice cuál. “INPUT no pasa por la cadena de bloqueo” es un mensaje muy distinto de “la IP no está en el conjunto”, y cada uno pide una acción diferente. Cuando un reload borró el salto, el agente lo nota y lo rehace solo.

Desconocido no es éxito

La regla más importante de la ruta trata de lo que pasa cuando falta información. Si el recibo no llegó, o la lectura no se pudo hacer, el estado queda desconocido. El panel lo dice con todas las letras: “Sin evidencia; no equivale a éxito.”

Parece un detalle de interfaz, pero es una decisión de producto. Un panel que redondea lo desconocido hacia arriba es un panel en el que no puedes confiar el día que más lo necesitas.

En la práctica

En la página de bloqueos, cada fila muestra el estado actual, y el detalle abre la ruta con la hora de cada etapa. Si quieres saber cuántos bloqueos están realmente confirmados ahora, ese es el número que importa, no el total de solicitudes.

Lee más sobre cómo funciona en Protección.