Ver intentos de inicio de sesión fallidos, escaneos de puertos y pruebas de exploits repetidos en los registros invita a bloquear la dirección de inmediato. Pero que sirva o no depende de dónde, durante cuánto tiempo y con qué amplitud se bloquea.
¿En qué capa bloquear?
- Borde / CDN: corta el tráfico antes de que llegue al servidor; en ataques de volumen es la única opción realista.
- Cortafuegos del servidor (nftables/iptables): rápido y barato para decisiones de una máquina; el paquete cae antes de llegar a la aplicación.
- Capa de aplicación: la más cara, porque la petición ya se ha procesado, pero la única con contexto de cuenta, sesión y comportamiento.
Regla práctica: detenga la fuerza bruta y los escaneos en el cortafuegos, y el abuso de lógica de negocio (registros falsos, abuso de cupones) en la aplicación.
fail2ban: bloqueo automático por comportamiento
fail2ban lee los registros y añade una dirección al cortafuegos cuando un patrón se repite lo suficiente en una ventana de tiempo. Configuración típica para SSH:
La jaula recidive mantiene fuera durante semanas a quien acumula bloqueos cortos. No olvide añadir sus direcciones de oficina y de monitorización a ignoreip: de lo contrario acabará bloqueándose a sí mismo.
Listas grandes: ipset y sets de nftables
Escribir una regla por dirección para miles de entradas ralentiza el cortafuegos. Lo correcto es un único conjunto evaluado por una sola regla:
Esta estructura mantiene un coste constante incluso con cientos de miles de entradas; basta con repoblar el conjunto por cron a partir de los datos actualizados.
¿Cuán amplio y cuánto tiempo?
- Bloqueos temporales por defecto. Las listas permanentes se degradan: las direcciones cambian de dueño y el atacante de ayer es el cliente de mañana.
- Cuidado con /24 o rangos mayores. Cerrar un bloque entero por un solo servidor malicioso golpea también a los usuarios legítimos que hay dentro.
- Extreme la prudencia con CGNAT y rangos móviles. Tras una dirección puede haber miles de abonados.
- Ponga su propia infraestructura en la lista blanca: monitorización, copias de seguridad y direcciones de retorno de la pasarela de pago.
No bloquee a los buscadores por error
No todo bot que rastrea con agresividad es malicioso. Antes de bloquear una dirección que dice ser un bot de buscador, resuelva su DNS inverso y vuelva a consultar hacia delante el nombre devuelto; si el nombre y la IP no coinciden, el bot es falso. La cabecera User-Agent por sí sola no prueba nada.
Alimente la lista con IP-DB
Verificar las direcciones extraídas de sus propios registros antes de bloquearlas reduce mucho los bloqueos innecesarios. La API de IP-DB.com devuelve los registros en listas negras, el ASN y los reportes de la comunidad de una dirección; colocada delante de su automatización de cortafuegos, solo entran en el conjunto las direcciones con mala reputación real. Para revisiones puntuales use la consulta masiva; para flujo continuo, la API.
Comentarios 0
Comparte una pregunta, tu experiencia o una corrección, registrado o de forma anónima.
Aún no hay comentarios. Sé el primero.