Etiqueta: sipcheck

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.
Gráfica de Netfilter donde observa que a medida que crecen las reglas de IPTables, aumenta el tiempo que lleva procesarlas, mientras que con ipset, se mantiene casi constante.
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. 😉
2022-12-16
SIPCheck 3 : La herramienta que asegura tu Asterisk ante ataques externos
Por mucho que pase el tiempo, y más ahora que el número de sistemas VoIP en la nube (o en remoto) aumenta, el número de ataques también aumenta considerablemente y es entonces cuando se hace necesario el uso de herramientas que nos ofrezcan la seguridad que necesitamos para poder estar seguro que nuestro sistema está controlado y no vamos a ser víctimas de un ataque mientras no estamos pendientes. Esta es la función de SIPCHECK, una herramienta que se conecta a Asterisk y vigila de accesos ilegítimos de direcciones IP desconocidas manteniendo nuestro Firewall actualizado con las direcciones IP de los atacantes.
En 2010, durante una comida en el curso de Asterisk Advanced de Bilbao, surgió una idea muy simple pero efectiva. Uno de los principales problemas que tenían muchos de ellos era la inseguridad que producía recibir ataques en los Asterisk que debían estar expuestos por Internet.
Ni que decir tiene que surgieron muchas ideas: utilizar VPN, cambiar a puertos no estándar, etc. y tras la exposición de los problemas y las posibles soluciones, una de ellas se presentó tan sencilla como fácil de implementar: Generar una aplicación que analizara el log de Asterisk y cuando detectara errores de autentificación, baneara automáticamente esa IP compartiendo dicha IP con el resto de la comunidad.
Esto fue una gran idea y así se hizo en la versión inicial de SIPCheck. Cuando el sipcheck detectaba un ataque, obtenía la dirección IP y la compartía con el resto de la comunidad para que todos pudieran tomar nota y rechazarla en los firewalls.
El resultado de esto fue algo más inesperado de lo que pensábamos: miles de direcciones IP baneadas (incluso algunas legítimas) y firewalls con tablas inmensas que incluían direcciones IP que, en algún momento del pasado atacaron a alguien. Estaba claro que tener un firewall con decenas de miles de direcciones IP que, en algún momento pudieron ser víctimas de un ataque y sirvieran de proxy para otro atacante no era la solución, ni siquiera para tenerlo en una tabla ACL de «IPs denegadas» ya que el 90% de esas direcciones IP no van a volver a atacarnos. La solución a esto, sin duda, era otra.
Ante esto, sucedieron varias modificaciones (añadir IPs con un registro de fecha y hora para que expiraran pasado un tiempo, introducir únicamente aquellas direcciones IP comunes que hayan sido baneadas por varios usuarios distintos, etc.) y los resultados fueron interesantes, aunque seguía sin obtenerse el resultado esperado.
Para ello, en 2014 se publicó SIPCheck 2, una versión nueva que incluía un registro sobre las direcciones IP baneadas en una web local que se podía consultar y añadir o eliminar aquellas IPs en tiempo real. Se eliminó la parte comunitaria ya que entendimos que si a un usuario de Japón le ataca una IP, no tiene por qué atacar a otro de Nápoles y, de esta manera se reducía el número de direcciones IP en el firewall. Se añadió soporte IPSet que mejora el funcionamiento de grandes listas de direcciones IP baneadas y aún así, la lista seguía sin ser efectiva (seguían apareciendo nuevas direcciones y seguíamos teniendo en el firewall direcciones que ya no se usaban). Al menos con SIPCheck v.2 podíamos eliminar manualmente aquellas direcciones antiguas.
Es en 2019 que, tras algunos cambios y nuevos proyectos surgió la idea de renovar el SIPCheck para paliar algunos defectos del SIPCheck inicial (que todavía hay gente utilizándolo) así como para reducir la carga al mínimo (muy inferior al de SIPcheck 2 y por supuesto al de Fail2Ban), empezamos a desarrollar la tercera versión nuevamente pero con todas las mejoras.
SIPCheck v.3
Funcionamiento
Esta versión de SIPCheck utiliza dos mecanismos diferentes para controlar los eventos:
– Mánager de Asterisk: (el 99% de los ataques) Con esto se controlan los intentos de login erroneos, los correctos y gracias a esto evitamos sobrecargar el sistema cuando el Asterisk es muy grande y genera mucha información en el log.
– Archivo /var/log/asterisk/messages: (el 1% restante) Con esto se controlan los INVITES sin autentificar y que no aparecen en el manager. Está claro que con el parámetro ‘allowguest = no‘ ni siquiera aparecerán estos INVITES, pero de alguna manera había que controlar este caso.
El funcionamiento de esta versión se basa en la gestión automática de 3 listas:
- Lista blanca : con direcciones IP confiables y que no deben estar baneadas aunque se reciban peticiones de registro con contraseña erronea. (Esta lista blanca la formarán aquellos que incluyamos en el archivo ‘whitelist.txt’ y aquellas direcciones IP que se hayan registrado correctamente.)
- Lista de sospechosos : con direcciones IP procedentes de algunos ataques pero no los suficientes como para considerarlos ataques. Cuando se recibe un intento de registro con una contraseña inválida, se almacena aquí hasta que el número de intentos supere un número determinado /y configurable/. Si un sospechoso deja de enviar los intentos, el sistema lo eliminará de la lista de sospechosos pasado un tiempo.
- Lista negra : con direcciones IP oficialmente considerados como ataques. Estos son auténticos atacantes y cuando están en la lista negra, el SIPCheck también lo incluye en el firewall impidiendo volver a acceder al sistema, por lo que el sistema es autónomo y no tenemos que preocuparnos. En esta lista permanecerá un tiempo configurable tras el cual se eliminarán tanto de la lista negra como del firewall, manteniendo a este limpio de atacantes antiguos.
Cuando SIPCheck detecte un ataque procedente de una IP, lo añadirá a la Lista de sospechosos y permitirá seguir recibiendo tráfico. Si recibe varias peticiones idénticas entonces pasará a considerarlo como un ataque oficial y lo añadirá a la lista negra y al firewall impidiendo más tráfico procedente de esa IP.
Si una IP se ha registrado correctamente en nuestro sistema, entonces se considera que esa IP pertenece a alguien «confiable» por lo tanto lo añadiremos a la Lista Blanca durante un tiempo evitando considerarlo atacante durante el tiempo en el que esa IP esté en la lista blanca. Esto impedirá banear una dirección IP de una empresa únicamente porque un teléfono tenga una contraseña errónea.
Todos los valores son configurables: número de contraseñas erroneas, tiempos en cada una de las listas, etc.
Se tiene incluso un archivo ‘whitelist.txt‘ donde podremos indicar las direcciones IP que jamás deberán serán baneadas por el SIPCheck (operadores, IPs de gestión, etc.)
Objetivos
El objetivo de esta aplicación son varios:
- Orientado a sistemas de alta carga: Probándolo en sistemas de alta carga, el consumo se disparaba, por lo que había que buscar una forma alternativa de minimizarla. Para ello se utiliza principalmente el ‘manager’ de Asterisk y para algunos casos puntuales el messages como complemento y evitar la sobrecarga de analizar cada línea del log de Asterisk.
- Evitar falsos positivos: En versiones anteriores, si un teléfono enviaba varias veces una contraseña erronea, el SIPCheck baneaba la IP entera. En esta versión, si una IP es registrada correctamente, pasa a una lista blanca que impide activar el protocolo de ataque en dicha IP compartida por varios teléfonos, seguramente de la misma empresa. De esta manera evitamos que un teléfono mal registrado en una empresa banee la IP del resto de la empresa.
- Persistente en el tiempo: Si se reinicia la aplicación, todos los datos y direcciones IP de todas las listas se mantienen y se vuelven a banear en firewall (si no lo estaban ya).
- Configurable: Se ha añadido un archivo sipcheck.conf donde poder configurar prácticamente cualquier parámetro que permita personalizar la aplicación.
La instalación es bastante sencilla ya que tan solo hay que seguir las 4 instrucciones del README para instalarla.
Y para comprobar qué está haciendo, todo queda registrado en un archivo de log en /var/log/sipcheck.log
Con esta aplicación, en varios Asterisk expuestos en Internet a modo de honeypot sin ningún otro tipo de protección, el sistema ha detectado y bloqueado cientos de ataques y lo mejor es que mantiene un firewall bastante reducido ya que las direcciones IP desde donde se producen los ataques dejan de atacar cuando empiezan a ser bloqueadas. Gracias a estos honeypots hemos aprendido muchas cosas nuevas sobre estos ataques que nos permitirán seguir mejorando el SIPCheck para conseguir detectar nuevas formas de ataques.
Si tienes comentarios o quieres dejarnos un feedback sobre esta aplicación puedes escribirnos un issue en Github, un comentario en el canal Telegram de @sinologic o en el correo electrónico sipcheck@sinologic.net
Para descarga y más información: https://github.com/sinologicnet/sipcheck
2020-02-24
Cómo generar una contraseña segura
Uno de los grandes problemas que nos encontramos al conectar un sistema a la red (Internet) es sin duda, los distintos ataques a los que tenemos que hacer frente. Por desgracia, no hay una persona como tal jugando con direcciones IP buscando a alguien a quien atacar, eso hoy día ha sido delegado a un ejército de sistemas «zombies» repartidos por todo el globo de forma que los ataques sean distribuidos, automatizados, rápidos y efectivos.
El momento de generar una contraseña se suele tomar a la ligera y es algo bastante importante plantear:
Primero, necesitamos una contraseña que sea fácil de recordar para poder escribirla siempre que nos la pidan.
Por otro lado, la contraseña debe ser difícil de obtener mediante fuerza bruta, (aunque el uso de GPU para desencriptar contraseñas, unido a algoritmos distribuidos en cientos de máquinas, puede reducir el tiempo para descifrar la contraseña en apenas unos minutos), de manera que cada vez hay más sitios que utilizan sistemas de autentificación en dos pasos o bien te exigen poner una contraseña con letras, números, simbolos, mayúsculas, y una longitud mínima de 15 caracteres.
Existen sistemas mnemotécnicos para ayudarnos a recordar contraseñas fuertes, pero lo que mucha gente empieza a hacer es disponer de un archivo donde guardar todas las contraseñas fuertes que utilizan y hacer uso del «copy+paste» para evitar recordarlas. Hay otras personas que utilizan contraseñas aleatorias y hacen uso del «he olvidado la contraseña» para evitar recordar semejante cadena. Sea como fuere, el uso de contraseñas fuertes es algo obligatorio incluso para algo rápido y sencillo.
En VoIP, vamos a ver que la cosa es mucho más sencilla…
(más…)
2015-05-29
SIPCheck2 vigila tu Asterisk en busca de atacantes
Hace exactamente 4 años, en Sinologic lanzamos una aplicación llamada SIPCheck que se encargaba de monitorizar el log de Asterisk y vigilar los intentos de conexión por parte de bots y atacantes para así, añadirlos al firewall y crear una lista de atacantes pública y utilizable por cualquiera, algo similar a lo que hace la aplicación fail2ban aunque más orientado a Asterisk y, al reportar las direcciones IP a una base de datos general que pueda ser consultada por todos, más social y útil.
Tras 4 años, el resultado ha sido realmente interesante: más de 4000 direcciones IP atacantes y más de 400 usuarios detectando ataques ha hecho que desde Sinologic nos planteásemos una mejora considerable: SIPCheck2
En esta nueva versión, desarrollada en Python, permite, no solo informar de cualquier atacante, si no también recibir la lista de los atacantes que dos o más usuarios hayan reportado, adelantándonos a los posibles ataques incluso antes de que se produzcan.
Se han añadido alguna mejoras como posibilidad de no detectar «falsos ataques» de direcciones IP y redes «conocidas» (clientes, red local, pruebas, etc.).
Cuando nuestro SIPCheck2 detecta un atacante, lo reporta al servidor y esa dirección IP queda almacenada en tu cuenta, de forma que queda baneada automaticamente en todos los sistemas que compartan dicha cuenta.
Si otros sistemas reportan también la misma IP atacante, esa dirección pasa a ser oficialmente un atacante y es reportada a todos los usuarios de SIPCheck con otras cuentas.
Otra de las novedades es que las direcciones IP atacantes caducan, desapareciendo al cabo del tiempo, ya que está demostrado que pertenecen a sistemas zombies que tienen fallos de seguridad y que con el tiempo son bloqueados o arreglados y no tiene sentido que permanezcan más tiempo en nuestro firewall.
Como variante, incluye un archivo de configuración desde el que se puede modificar algunos parámetros para adaptarlo mejor a nuestro sistema, añadir direcciones IP y redes nuestras para evitar falsos positivos y algunas mejoras más.
(más…)
2014-06-03