Cómo proteger tu servidor Linux de miles de direcciones IP y no morir en el intento

Hace algunos años, comencé un proyecto llamado SIPCheck que se basaba en un programa que leía el log de Asterisk buscando cadenas de texto que aparecían cuando se recibían intentos de registro y de esta forma, obtener la dirección IP para bloquearlo en el firewall. Esto ya lo hacía Fail2Ban (con muchos más servicios) y más especialmente APIBan, pero incluso en la primera versión de SIPCheck aprendí un error que sigue ocurriendo en todos estos sistemas: Los ataques procedentes de una dirección IP se quedan en el firewall hasta que lo hace prácticamente inmanejable, además de que esa dirección IP (que la pobre sólo tiene culpa de haberle tocado un dueño al que le han metido un gol por la escuadra) pasa a ser etiquetada como hostil e inutilizándola para cualquier uso legal y razonable hasta «el fin de los días» (más o menos lo mismo que comentamos cuando hablamos de los números de teléfono que se usan para campañas de marketing). Dejaré para un futuro artículo las venturas y desventuras de lo aprendido cuando desarrollábamos el nuevo SIPCheck, porque aprendimos muchas y muy interesantes lecciones sobre como pasar de bloquear IPs a cómo evitar ataques, pero esto mejor en otro artículo.

Así que, viendo que alguien hace uso de direcciones IP de sistemas vulnerables para arrancar sus programas de ataque a sistemas VoIP, y que cuando estos dejan de funcionar, cambian de IP y siguen atacando… ¿para qué vamos a estar guardando en el firewall una lista sin fin de direcciones IP?

Primero, el firewall de Linux (IPTables) es de lo mejorcito que hay (razón por la cual, la mayoría de los firewalls comerciales funcionan con Linux/FreeBSD) tiene muy poca carga, es estable como lo que más (filosofía Unix: muchos programas pequeños y cada uno hace su función a la perfección) pero cuenta con un pequeño defecto cuando se almacenan «decenas o cientos de miles» de direcciones IP (lo que ocurre con SIPCheck, Fail2Ban o APIBan): se vuelve lento para aceptar o rechazar peticiones, algo que puede cargar bastante el sistema e incluso provocar problemas en las comunicaciones.

La primera solución era evidente: usar ipset

Qué es ‘ipset’ y cómo funciona

El pequeño ‘ipset‘ es una herramienta fácil y sencilla, complementaria de IPTables que maneja una lista desordenada de direcciones IP como si fuera una única regla del firewall. Esto es (para que lo entendamos mejor), que cuando nuestro sistema recibe un paquete y tiene que comprobar si puede o no dejarlo pasar, recorre TODO el firewall, lo cual, si tenemos 100.000 direcciones IP bloqueadas, por cada paquete que reciba, tendrá que hacer 100.000 comprobaciones antes de dejarlo pasar, una carga bestial para un sistema que maneja miles de paquetes UDP por segundo como es un servidor de comunicaciones VoIP.

Por lo tanto, en lugar de una «lista ordenada» de reglas, ipset sirve para manejar un «conjunto» de IP, de manera que es 10.000 veces más rápido (utiliza una búsqueda hash) que preguntar: -«¿Está esta lista en el conjunto?» y buscar secuencialmente una IP en la lista ordenada, así que no es casualidad que cuando el número de direcciones IP a bloquear sea demasiado grande, es muchísimo mejor utilizar ipset, que IPTables.

Al final ipset debe estar conectado a IPTables para que puedan ser bloqueadas las direcciones IP guardadas en «el conjunto».
De manera que cuando un sistema nos envía un paquete, el firewall sigue recorriendo sus líneas, pero una línea en particular dice: «Consulta el conjunto listanegra» y esa línea pregunta al conjunto si está la IP en él. La respuesta de ejecutar esa consulta es tan rápida como una simple línea de IPTables, por lo que la mejora en velocidad es muy interesante.

Cómo evitar los guisantes caídos en el fondo del congelador

Tenemos el problema que comentábamos antes ¿hasta cuando vamos a bloquear una IP que nos atacó? ¿va a estar castigada para siempre? ¿hasta que hagamos un FLUSH y comencemos de nuevo? ¿no hay nada más manejable? La respuesta a esto sigue siendo la misma: ipset.

Además, ipset tiene una funcionalidad muy interesante y es que se pueden poner tiempos de expiración a las reglas (borrarlas automáticamente al cabo de X segundos) por lo que si baneamos una IP, podemos dejar a ipset que la saque de la lista negra al cabo de 30 minutos, 6 horas o 30 días (o por poner una cantidad de tiempo en la que pensamos que no nos volverá a atacar), de esta manera, el número de registros se mantendrá automáticamente controlado y si vuelven a atacarnos, volverán a ser baneados otro buen tiempo.

No queremos direcciones IP permanentemente bloqueadas… al cabo de un tiempo ya no vamos a recibir ataques de ahí pero siempre estará consumiendo ciclos de CPU al comparar cada paquete con esa regla. Vale que con ipset hemos reducido al máximo este consumo, pero aún así, ¿realmente es necesaria una cadena perpetua a una pobre IP por haber sido vulnerable una vez? (no es una pregunta filosófica, moralista ni política…)

Los atacantes son inteligentes, no importa si bloqueamos con IPTables, con ipset o con NFTSet, ganan mucho si consiguen lo que quieren, así que nunca hay que subestimarlos: prueban con una IP, que no lo consiguen, prueban con otra y así hasta que se dan por vencidos… luego probarán otras cosas: prueban contraseñas genéricas, contraseñas robadas de otros lugares, combinaciones de valores (por si bloqueásemos el UserAgent, o permitiésemos llamadas con un prefijo «secreto») ya sabéis que «la técnica de ocultación, realmente es una vulnerabilidad retardada en el tiempo«.

Ahora vamos con la práctica

Lo primero que tenemos que hacer es lo mismo que cuando jugamos con un firewall: Jamás hacer pruebas en un sistema en producción, puede parecer evidente, pero os sorprendería la de routers de Facebook que se han quedado aislados por hacer pruebas donde no debían. 😛

Ahora sí, lo primero que tenemos que hacer es instalar ipset con nuestro gestor de paquetes: apt install ipset o bien yum install ipset, una vez esté instalado, ya podemos empezar a hacer pruebas:

1.- Creamos un conjunto de IPs al que vamos a llamar: listanegra

# Si queremos crear un conjunto con un timeout máximo de 1 hora
ipset create listanegra hash:ip timeout 3600
# Si no queremos que tenga timeout, basta con no ponérselo.
# ipset create listanegra hash:ip

2.- Una vez creado el «conjunto», podemos ver todos los conjuntos que tenemos:

ipset list

3.- A continuación, enlazamos el conjunto «listanegra» con nuestro iptables:

# Para dar de alta el conjunto 'listanegra' en el iptables:
iptables -I INPUT -m set --match-set listanegra src -j DROP
# Siempre podemos eliminar el conjunto del iptables con:
# iptables -D INPUT -m set --match-set listanegra src -j DROP

4.- Por último, tenemos que añadir las direcciones IP al conjunto mediante el propio comando ipset:

ipset add listanegra 248.248.248.247 timeout 30
ipset add listanegra 248.248.248.248 timeout 20
ipset add listanegra 248.248.248.249 timeout 10

La primera IP será eliminada en 30 segundos, la segunda en 20 y la tercera en 10.
Si no se le define un «timeout», utilizará el timeout general que se puso al crear el conjunto: 3600.

5.- Recuerda que para borrar manualmente una IP del conjunto:

ipset del listanegra 248.248.248.247

y de esta manera, hemos visto cómo podemos banear de forma automática a cientos de miles de direcciones IP sin preocuparnos de eliminarlas manualmente.

En nuestro firewall, tan sólo aparecerá una línea indicando que tiene que «dropear» aquellas direcciones del conjunto ‘listanegra’

iptables -L -n

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
DROP       all  --  0.0.0.0/0            0.0.0.0/0            match-set listanegra src

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Cómo hacer persistente la lista negra en caso de reinicio

Si reiniciamos el sistema, todo se borra, así que lo suyo sería almacenarla y restaurarla cuando reiniciemos, así que vamos a modificar el script de ipset de systemd:

# Modifícalo en lo que consideres necesario
[Unit]
Description=ipset persistancy service
DefaultDependencies=no
Requires=netfilter-persistent.service
Requires=ufw.service
Before=network.target
Before=netfilter-persistent.service
Before=ufw.service
ConditionFileNotEmpty=/etc/ipsets.conf
 
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/sbin/ipset restore -f -! /etc/ipsets.conf
 
# save on service stop, system shutdown etc.
ExecStop=/sbin/ipset save listanegra -f /etc/ipsets.conf
 
[Install]
WantedBy=multi-user.target
 
RequiredBy=netfilter-persistent.service
RequiredBy=ufw.service

También estaría bien meter la siguiente línea en el crontab para que periódicamente haga una copia de seguridad de las IPs que tenemos baneadas… aunque esto tampoco es tan vital. 🙂

/sbin/ipset save listanegra -f /etc/ipsets.conf

Y con esto, ya nos tocará buscar la forma de añadir de forma automática las direcciones IP al conjunto, bien mediante un sipcheck modificado, bien mediante un script automatizado que busque intentos de registro fallidos, o de alguna otra forma. ¿se te ocurre alguna forma de ejecutar un comando para añadir direcciones IP al conjunto de ipset cuando se recibe un ataque a Asterisk, Kamailio o a otro servicio? Dínoslo en los comentarios, que estamos en las puertas de navidad y puede que si te portas bien, te traigan regalitos muy pronto. 😉