Inseguridad en Elastix: estadísticas actualizadas (México)

3 Nov

Hace algunos meses publiqué un artículo sobre estadísticas de inseguridad en Elastix y los resultados fueron bastante alarmantes, ya que el estudio claramente indicaba que quienes se habían encargado de instalar los sistemas no habían seguido muchos de los consejos básicos de seguridad tales como no exponer el HTTPS a internet ni mucho menos cambiar las contraseñas default puestas. Por tal motivo, durante este año se reportaron múltiples casos de empresas  a los que les habían cometido algún tipo de fraude telefónico, representando pérdidas de varios cientos o miles de dólares en tan solo una noche.

Hoy, con motivo del inicio del Elastix World precisamente en México, decidí repetir el ejercicio para hacer un comparativo de como han cambiado los números desde aquel entonces. Aquí mis resultados obtenidos:

Los resultados fueron:

– Total de equipos escaneados (en México): 27.8 millones
– Total de equipos con puerto TCP 443 expuesto: 67,887
– Total de equipos con puerto TCP 443 expuesto y que usan Elastix: 336

De los equipos con Elastix expuesto:

– Presentan algún tipo de vulnerabilidad descubierta: 102 (27.87%)
– Tienen acceso mediante UDP 5060 (SIP):  102 (27.87%)
– Tienen alguna contraseña default en FreePBX: 82 (22.40%)
– Siguen usando ‘palosanto’ como contraseña de Elastix: 9 (2.46%)
– No han parchado la vulnerabilidad del ‘asteriskuser’: 120 (32.79%)
– Usan la misma contraseña para FreePBX y para Elastix: 4 (1.09%)
– Utilizan una versión muy vieja de FreePBX (2.5 o menor): 43 (11.75%)

De los equipos con vulnerabilidades que permiten acceso:

– Se detectaron extensiones completas (usuarios, contraseñas y correos electrónicos) de 1,192 personas

Tomen en cuenta que todos estos números son reales, ya que el estudio fue conducido sobre equipos en producción durante la noche del 2/noviembre/2011.

Tras analizar los números, es posible ver que ha habido una notable mejoría. Sin embargo, muchas empresas siguen desprevenidas contra ataques por no seguir simples reglas de seguridad básicas (las cuales se mencionan en el artículo inicial)

Ahora, tras los números, mi opinión personal: ¿Es Elastix una herramienta insegura? No, no lo es. Ha tenido sus vulnerabilidades relacionadas con las herramientas que incorpora (tal como FreePBX), pero todos estos males podrían haberse resuelto si tan solo los «administradores» que las instalaron hubieran tomado 5 minutos extras en asegurar su conmutador después de haber hecho la instalación. De hecho, creo que el principal problema de las herramientas que hacen la labor de instalación más sencilla (tal como Elastix lo es), es que cualquier persona piensa que por meter un CD y dar unos cuantos clicks ya terminó todo, cuando realmente se requiere preparación y conocimiento detrás de cada acción para saber lo que se está haciendo. Desafortunadamente, personas con este perfil son las que le dan una mala reputación a los sistemas VoIP (y a quienes nos encargamos de ofrecerlos), haciendo que se genere desconfianza para muchos por culpa de tan solo algunos.

Una vez más, no me queda recomendarles mas que asegurar sus equipos. Hoy más que nunca, los fraudes telefónicos están a la orden del día.

¡Suerte!

Protege tu Asterisk de ataques usando fail2ban

7 Jul

En ocasiones anteriores he hecho la mención de fail2ban, una herramienta escrita en Python que analiza logs del sistema y responde en caso de que ciertas condiciones se cumplan, por ejemplo, 5 intentos de contraseña SSH equivocada en un periodo de 10 minutos. Dada la proliferación de ataques a equipos Asterisk para tratar de hacer llamadas de larga distancia, tiene sentido que ocupemos esta herramienta para protegernos de los amantes de lo ajeno.

Ahora bien, ¿cómo configuramos esta herramienta para que nos evite los cargos de miles de dólares en llamadas fantasmas?

Primero, lo instalamos. En Debian podemos usar el mundialmente reconocido apt-get:

apt-get install fail2ban

O, si tenemos Centos, primero asegurémonos de que tengamos EPEL (un repositorio que nos da acceso a mucho software útil) y luego instalamos fail2ban:

rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm 
yum -y install fail2ban

Fail2Ban se configura en 2 partes básicas:

  • /etc/fail2ban/jail.conf – Define que logs monitorear y que hacer en caso de que una regla se cumpla
  • /etc/fail2ban/filter.d/<filtro> – Definimos las reglas de coincidencia para analizar los logs

Editemos el archivo jail.conf y agreguemos esto hasta abajo:

[asterisk-iptables]
enabled  = true
filter   = asterisk
action   = iptables-allports[name=ASTERISK, protocol=udp, port=5060]
sendmail-whois[name=ASTERISK, dest=micorreo@algunmail.com, sender=fail2ban@example.org]
logpath  = /var/log/asterisk/full
maxretry = 5
findtime = 600
bantime = 10800

Lo que estamos especificando es lo siguiente:

  • La regla (jail) se llama asterisk-iptables
  • El filtro a usar debe existir en /etc/fail2ban/filter.d/asterisk.conf
  • Cuando se active la regla, usaremos la acción iptables-allports, la cual bloquea a nivel de iptables. Nosotros le estamos indicando que cierre el acceso al puerto UDP 5060, y luego que haga uso de la acción sendmail-whois, la cual me enviaria a mi correo electrónico la notificación del bloqueo, además de enviarme información de whois de la IP que se bloqueó.
  • El archivo log a monitorear es el /var/log/asterisk/full (ojo, dependiendo de tu sistema, el log puede ser diferente, ajústalo acorde)
  • Se permiten un máximo de 5 fallos en 10 minutos antes de activar la protección. Es decir, se permiten un máximo de maxretry intentos en findtime segundos
  • Al activarse el bloqueo, se hará por 3 horas o bien, 10800 segundos (bantime)

En esta liga encuentras el manual oficial para el jail.conf.

Ya definido el jail, necesitamos crear el filtro que atrapará los ataques. Esto se define (de acuerdo a lo que especificamos arriba) en el /etc/fail2ban/filter.d/asterisk.conf (los valores con # son comentarios, solo se dejan por referencia)

[INCLUDES]

# Read common prefixes. If any customizations available -- read them from
# common.local
#before = common.conf

[Definition]

#_daemon = asterisk

# Option:  failregex
# Notes.:  regex to match the password failures messages in the logfile. The
#          host must be matched by a group named "host". The tag "<HOST>" can
#          be used for standard IP/hostname matching and is only an alias for
#          (?:::f{4,6}:)?(?P<host>S+)
# Values:  TEXT
#

failregex = Registration from '.*' failed for '<HOST>(:[0-9]{1,5})?' - Wrong password
       Registration from '.*' failed for '<HOST>(:[0-9]{1,5})?' - No matching peer found
       Registration from '.*' failed for '<HOST>(:[0-9]{1,5})?' - Device does not match ACL
       Registration from '.*' failed for '<HOST>(:[0-9]{1,5})?' - Username/auth name mismatch
       Registration from '.*' failed for '<HOST>(:[0-9]{1,5})?' - Peer is not supposed to register
       NOTICE.* <HOST> failed to authenticate as '.*'$
       NOTICE.* .*: No registration for peer '.*' (from <HOST>)
       NOTICE.* .*: Host <HOST> failed MD5 authentication for '.*' (.*)
       VERBOSE.* logger.c: -- .*IP/<HOST>-.* Playing 'ss-noservice' (language '.*')

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
#
ignoreregex =

Se observa que estamos tratando de atrapar a los siguientes:

  • Usuarios que ingresan su contraeña SIP incorrectamente
  • Usuarios que intentan usar un usuario SIP que no existe
  • Usuarios que no cumplen con los parámetros permit y deny del sip.conf
  • Usuarios que su auth username no coincide con su username
  • Usuarios que tratan de registrarse con perfiles que son fijos (es decir, que no tienen host=dynamic)
  • Usuarios que no cumplen con los criterios de autenticación
  • Usuarios que marcan hacia números que no existen (esto es común en Elastix/FreePBX cuando deshabilitamos recibir llamdas anónimas)

En esta liga encontramos el manual de los filtros de fail2ban.

Finalmente, solo nos queda activar el servicio. En Debian ya quedó instalado automáticamente, solo tenemos que arrancarlo:

/etc/init.d/fail2ban start

En CentOS, tenemos que habilitar el autoarranque para que inicie al arrancar el equipo:

chkconfig --add fail2ban
chkconfig fail2ban on
/etc/init.d/fail2ban start

Fail2ban es un excelente apoyo contra ataques que dejan registros en logs y no solo nos sirve para Asterisk, también para SMTP, SSH, HTTP o cualquier otra cosa que queramos monitorear. Esto, en conjunción con buenas prácticas de seguridad para Asterisk, nos darán un sistema más confiable y menos propenso a sufrir daños por parte de atacantes.

¡Suerte!

 

Estadísticas de inseguridad en Elastix (México)

9 Mar

Hoy decidí realizar un estudio sobre las vulnerabilidades que sería capaz de encontrar en un entorno como Elastix en México. Me puse mi sombrero blanco y decidí escanear todas las posibles redes del país y buscar cuantos equipos utilizan la distribución antes mencionada (al menos las visibles en el puerto TCP 443), y los resultados fueron alarmantes. Aquí algunas estadísticas:

25.4 millones de hosts escaneados
69 mil tienen el puerto 443 abierto
467 equipos eran Elastix

Aclaro que esto no quiere decir que estos sean todos los equipos Elastix en México. Esto quiere decir que en una noche cualquiera fui capaz de encontrar 467 equipos visibles abiertamente en internet, los demás están tras algún firewall y son invisibles al exterior (¡bien!).

Ahora, para los números del terror:

  • 287 tienen algún tipo de dato «secreto» que se puede obtener fácilmente (contraseña de FreePBX, contraseña de Elastix, contraseñas de extensiones)
  • los mismos 287 tienen el puerto SIP abierto
  • 261 tenían algún tipo de contraseña default para FreePBX
  • 26 aún tenían la contraseña de «palosanto» para Elastix
  • 31 usan la misma contraseña en FreePBX que en Elastix
  • 42 aún usan FreePBX 2.5.x que muestra la contraseña de administrador en texto plano

Y quizá la más sobresaliente:

  • 197 usan alguna distribución de Elastix suficientemente vieja que permite descargar el archivo de batch extensions, entregándote el archivo que nombra todas las extensiones del sistema con sus respectivas contraseñas, dando un total de ¡8,300 extensiones disponibles para hacer llamadas en Elastix ajenos!

Esto quiere decir que aún con una tasa de fallo del 50%, tengo 4,150 de posibles extensiones desde las cuales se pueden sacar llamadas sin pagar un solo centavo, ocasionando tráfico VoIP que en pocas horas se convierte en facturas millonarias de teléfono.

Y si creen que exagero, échenle cuentas:

  • Supongan que de los 197 servidores visibles, al menos 170 tienen algún tipo de interfaz FXO o E1
  • Supongan que en una sesión de ataque promedio, puedo cursar llamadas por el mismo equipo (por la noche) durante unas 4 horas
  • Supongamos que promediando la cantidad de canales de E1 y de puertos FXO, puedo cursar 3 llamadas simultáneas por servidor

Esto me da un total de 4 horas * 60 minutos * 3 llamadas simultáneas * 170 servidores = 122,400 minutos de tráfico. Si el destino costara $7/min, hablamos de un total facturado de $856,800, ¡en unas horas!

Y claro que este es el espectro conservador: conozco casos de 2a persona que han tenido facturaciones de $24,000 en una sola pasada. Hagan números, y fácilmente comprenderán por que esto del robo de VoIP está tan de moda y resulta tan redituable.

Obviamente si no quieren convertirse en amigos de lo ajeno, sigan las ya super conocidas medidas de seguridad para cualquier entorno Asterisk:

  1. Siempre cambien las contraseñas default
  2. Tampoco usen palabras de diccionario como contraseña
  3. No den acceso desde el exterior si no se necesita. Esto aplica a los puertos UDP 5060 y TCP 22, 443 (los más comunes)
  4. User el permit deny dentro de Asterisk para limitar que IPs se registran en cada extensión.
  5. No usen contraseñas y passwords iguales (user:100 pass:100)
  6. Actualicen sus distribuciones a la más reciente versión
  7. Limiten la cantidad de llamadas simultáneas por extensión (¿Por qué razón Juan Pérez haría 20 llamadas a la vez?)
  8. Rechazen malas autenticaciones sin dar más detalles (alwaysauthreject=yes) en sip.conf
  9. Firewall firewall firewall
  10. Usen fail2ban para defenderse de ataques de fuerza bruta
  11. Autentiquen al usuario, no solo al teléfono (usen contraseñas post-marcado)
  12. Nieguen llamadas anónimas provenientes del exterior
  13. Definan planes de marcación limitados (ojo con el dialplan injection)

Asterisk/Elastix como tal son bastante seguros: es el administrador el que los hace inseguros al obviar cualquier de estos pasos sugeridos. Todos los puntos que aquí se mencionan también se estudian desde nuestros cursos Asterisk

Suerte, y…  ¡aseguren sus equipos!