Una herramienta web privada para el día a día con servidores Plesk: una base de datos de IPs que atacan, la consulta de quién está detrás de cada una y un generador de comandos de Fail2ban e iptables. La regla de diseño más importante: nunca ejecuta nada en los servidores. Solo genera texto que reviso y pego yo.
En servidores web con Plesk, Fail2ban bloquea solo los ataques más evidentes, y la mayoría de sus bloqueos duran minutos: las mismas IPs vuelven una y otra vez contra SSH, el correo o los WordPress de los clientes. Decidir cuáles merecen un bloqueo largo, comprobar de quién son, escribir el comando para cada servidor y acordarse de qué se bloqueó dónde se hacía a mano, con notas sueltas.
Restricción de partida: en los servidores de clientes no se puede instalar nada propio (ni agentes, ni scripts que llamen a casa). Así que la herramienta tenía que vivir aparte y no depender de tocar los servidores.
Se pega lo que salga en el servidor: IPs sueltas, la salida de fail2ban-client status o un grep de un log. La herramienta extrae las IPs, las normaliza (la misma IPv6 escrita de dos formas es una sola), rechaza las privadas y reservadas y las que están marcadas como seguras, y si una ya estaba le suma una vez en vez de duplicarla.
Cada IP o rango se consulta a la vez en ipinfo (ubicación, ASN, proveedor), en RDAP (el registro oficial: rango asignado, titular, contacto de abuso) y en AbuseIPDB (reputación). Las peticiones van en paralelo con curl_multi y el resultado se resume en un veredicto: intrusiva, sospechosa o sin reportes. Así no se bloquea por error a Google, a un monitor o a un cliente.
Se eligen las IPs (por país, por las más vistas o a mano), el servidor y el método, y sale el texto listo para copiar: fail2ban-client set JAIL banip IP o reglas de iptables en una cadena propia. Por defecto, una orden simple por línea: en algunos servidores compartidos no se puede pegar un bucle. Antes de generar se vuelve a validar todo (el jail y cada IP), porque ese texto se pega como root.
Bloquear un rango entero es una medida grave que puede dejar fuera a gente legítima. Por eso una IP cuenta por sí misma aunque caiga dentro de un rango guardado, y los rangos tienen su propia vista: nunca se mezclan en un mismo bloqueo sin decidirlo expresamente.
Cada vez que se copian comandos queda un lote con el servidor, el método y las IPs. Cada acción (altas, consultas, bloqueos, borrados) se apunta en un registro, y las IPs que no se ven en 12 meses se pueden purgar: una IP es un dato personal y no tiene sentido guardarla para siempre.
Subdominio con contraseña del servidor y, además, una comprobación propia en el código. Base de datos separada de la de la web pública, con un usuario que solo puede leer y escribir filas. CSP estricta: ni una línea de JavaScript dentro del HTML. Las claves de los servicios externos viven fuera de la web.
Las pruebas automáticas encontraron que "recidive\n" se aceptaba como nombre de jail válido: en PHP, el $ de una expresión regular admite un salto de línea al final. En un texto que acaba pegado como root, eso es justo lo que no puede pasar.
/D en todas las validaciones de ese tipo, y una batería de pruebas (IPs con trucos como 1.2.3.4; rm -rf / o $(id), rangos, IPv6) que se lanza tras cada cambio.
La herramienta también guarda scripts y chuletas que se suben desde la web. Un .svgz, un .xht o un archivo sin extensión que empezara por <html> se habría abierto como página dentro del subdominio privado, y desde ahí podría alterar lo que copian los botones.
En servidores con Plesk y CentOS 6 el jail de bloqueo semanal no existe, la base de datos de Fail2ban puede estar corrupta (database disk image is malformed) y el iptables 1.4.7 no tiene la opción -C para comprobar si una regla ya existe.
-C, y las guías de diagnóstico explican cómo reconocer y arreglar esos casos.
Las consultas de IPv6 al servicio RDAP volvían siempre vacías, aunque en la web del registro sí aparecían.
: viajaban como %3A, y el servicio no los entendía.
El ciclo completo en un solo sitio: sacar las IPs atacantes de los logs del servidor, consultarlas, decidir, copiar los comandos y dejar constancia. La decisión sigue siendo siempre de una persona, y la herramienta no puede ejecutar nada aunque alguien llegara a entrar en ella.
Alrededor de la lista de IPs, la misma consola guarda chuletas de comandos y guías de diagnóstico paso a paso (servidor lento, disco lleno, web con error 500, correo que no sale, ataque en curso) con los comandos listos para copiar.