Filtración de contraseñas en 000webhost

Me acaba de saltar una alerta de have i been pwned? sobre una nueva filtración de contraseñas.

Estamos hablando de la friolera de 13 millones de contraseñas en claro filtradas de la base de datos de usuarios de 000webhost, uno de los proveedores de hosting gratuito más habituales.

La base de datos de contraseñas se filtró en marzo de 2015, y desde entonces se ha estado vendiendo en foros por un precio de unos $2.000. Que se venda significa que aquellos que la hayan comprado esperan obtener un retorno económico de ello. Dicho de otra manera, esperan que las víctimas hayan reutilizado sus contraseñas de 000webhost en otros sitios de Internet y puedan robarte dinero de alguna manera.

Lo peor de todo este asunto es la estrategia seguida por 000webhost cuando el investigador de seguridad Troy Hunt les informó de ello: le ignoraron completamente y no avisaron a sus clientes. 000webhost ha reseteado silenciosamente las contraseñas de todos sus clientes, pero no les ha advertido de que, si han reutilizado su contraseña en otros sitios, pueden estar gravemente expuestos. En ese sentido, la actuación de 000webhost ha sido lamentable.

Si tienes cuenta en 000webhost y has reutilizado la contraseña en otros sitios de Internet, ve y cambia tus credenciales en todos esos sitios ahora mismo.

Si quieres leer más sobre la nefasta gestión de 000webhost ante el incidente, aquí tienes la investigación completa de Troy Hunt:

Breaches, traders, plain text passwords, ethical disclosure and 000webhost

Charla “Seguridad en Aplicaciones Web”

Este año voy a dar una charla dentro del programa de cursos de verano que organiza el grupo e-ghost en la Universidad de Deusto. Estos son los datos básicos de la convocatoria:

  • Tema: Seguridad en Aplicaciones Web
  • Fecha: 17 de julio, 12:00
  • Lugar: Bilbao, Facultad de Ingeniería de la Universidad de Deusto, aula 105L
  • Duración: 2 horas

En la charla analizaremos las 10 debilidades de seguridad más comunes que se cometen durante el desarrollo de una aplicación web, con ejemplos de cómo se podrían explotar y qué impacto tendrían en el negocio.

Analizaremos fugas de información, inyección de código en formularios, falsificación de peticiones, debilidades de autenticación, y mucho más. ¿Te lo vas a perder?

Para asistir hay que inscribirse previamente. Puede asistir cualquier persona, pero si se llena tendrán prioridad los alumnos y ex-alumnos de la Universidad de Deusto.

Los cursos de verano del grupo e-ghost se van a impartir del 13 al 24 de julio en la Facultad de Ingeniería de la Universidad de Deusto, en Bilbao. Puedes ver el programa completo aquí:

Hay charlas y talleres muy interesantes. ¡Anímate!

Actualización: Ya puedes consultar las transparencias utilizadas en la charla:

Muchas gracias a todos por asistir.

Sobre los 5 millones de contraseñas de Gmail

El pasado 10 de septiembre se desataba la noticia de que se habían filtrado nada menos que 5 millones de contraseñas de Gmail en claro. Rápidamente todos los medios de comunicación especializados se hicieron eco de la noticia y la alarma corrió por foros y redes sociales. Más tarde Google emitió un comunicado indicando que sus sistemas no habían sido vulnerados, y desde entonces nada más se ha vuelto a saber.

La sospecha es que las contraseñas no habían salido de Google, sino de algún otro sitio en Internet menos protegido. Digamos del “Blog Pepe”. La noticia también apuntaba a que, probada una pequeña muestra de la filtración, se podía inferir que el 60% de las contraseñas publicadas eran válidas en Gmail. Esto significa que al menos el 60% de las personas de esa lista utiliza la misma contraseña en Gmail que en “Blog Pepe”.

El listado de cuentas comprometidas se puede encontrar fácilmente en Internet. El listado completo con contraseñas no es mucho más difícil de conseguir. Yo he dado con él, y me he permitido cargarlo en un SQLite para sacar el Top 20 de contraseñas más utilizadas. Ahí va:

TOP 20 de Contraseñas

Posición

Contraseña Apariciones

1

123456 23116
2 password 5569
3 123456789 5379
4 12345 3974
5 qwerty 2922
6 12345678 2491
7 111111 1682
8 abc123 1499
9 123123 1476
10 1234567 1352
11 1234567890 1343
12 iloveyou 925
13 1234 923
14 password1 895
15 27653 889
16 000000 808
17 zaq12wsx 738
18 monkey 722
19 qwerty123 717
20 tinkle 716

De este listado se pueden extraer varias conclusiones:

  • La contraseña más utilizada es “123456”, seguida de “password”.
  • La mayor parte de las contraseñas son exclusivamente numéricas, las más fáciles de reventar por fuerza bruta.
  • Prácticamente todas representan secuencias sobre el teclado, y no sólo “123456” y derivados, sino también “qwerty” y “zaq12wsx”.
  • En general, las contraseñas son muy cortas, entre 6 y 8 caracteres.
  • Las que no son números ni secuencias son palabras del diccionario.

Las filtraciones de contraseñas están a la orden del día. En este caso la filtración no parece proceder de los sistemas de Google, pero en ocasiones pasadas se han visto comprometidos muchos sistemas de grandes compañías como Adobe (152 millones), mail.ru (casi 5 millones), Forbes (1 millón), Yahoo (medio millón), Vodafone (56.021), Sony (37.103) y muchos más. Puedes comprobar si tu cuenta está afectada visitando have I been pwned?

Siento decirte que si tu cuenta aparece en la filtración de Gmail, o en cualquier otra, tu email va a pasar a estar en las listas de los spammers de todo el mundo. Prepárate para recibir SPAM como un bellaco.

Y a continuación algunos consejos para minizar daños en el futuro:

  • Utiliza contraseñas únicas. No puedes evitar que un sitio web se vea comprometido, pero al menos puedes evitar que la información que extraigan sirva para acceder a otros servicios donde estés registrado. Utiliza una contraseña diferente en cada sitio web en el que te registres, o como mínimo hazlo en los sitios importantes.
  • Utiliza contraseñas complejas. Sobre todo en los servicios importantes. Asegúrate de que tengan más de 12 caracteres y que incluyan números, letras mayúsculas y minúsculas, y algún símbolo.
  • Tu cuenta de correo es la llave de muchas puertas. Protégela adecuadamente con una clave robusta y accede sólo desde ordenadores confiables, preferentemente el tuyo propio.
  • Activa la autenticación en dos pasos en todas tus cuentas. Esta opción está disponible en Google, Apple, Microsoft, Facebook, y muchos más. Te permite pasar de un escenario donde la llave es “algo que sabes” a un escenario mucho más seguro del tipo “algo que sabes + algo que tienes”.
  • Plantéate el uso de un llavero offline de contraseñas. Esto te permitirá manejar contraseñas complejas sin volverte loco, y de paso te olvidarás del típico problema de “¿qué usuario/email utilicé para registrarme en esta web?”. Tienes muchas opciones, aunque me centraré en algunas de Software Libre: KeePass para Windows, KeePassX como opción multiplataforma, y KeePassDroid para Android. Ya no tienes excusa.
  • Cambia periódicamente las contraseñas de tus cuentas principales. Tus cuentas importantes merecen un cambio de contraseña cada cierto tiempo. Si estás utilizando un llavero offline puedes incluso especificar la caducidad de la contraseña, y él mismo te avisará llegado el momento.
  • Utiliza una segunda cuenta de correo destinada exclusivamente como método de recuperación de tus cuentas principales. Prácticamente cualquier servicio importante permite introducir una segunda cuenta de correo para recuperación de clave en caso de olvido o robo. Utiliza una contraseña única y almacénala en lugar seguro fuera incluso de tu llavero offline. Un trozo de papel guardado en casa servirá. En general no necesitarás acceder a ella, pero debes ser capaz de recordar dónde pusiste la clave.

Con estos consejos espero que en la próxima filtración os veáis menos expuestos.

Curso Asterisk (VIII): Plantilla mínima de configuración

En un comentario del capítulo anterior he recibido una petición que me ha parecido suficientemente interesante como para dedicarle una pequeña entrada independiente.

En el comentario, el autor pide si sería posible publicar el contenido de los archivos sip.conf y extensions.conf reducidos a su mínima expresión, sin extensiones de ejemplo ni ningún tipo de relleno, salvo los parámetros de seguridad mencionados en el correspondiente capítulo.

A continuación, os pongo el contenido de dichos archivos. Lo que incluyen es lo mínimo imprescindible, justo el esqueleto sobre el que empezar a definir vuestras extensiones y vuestro dialplan.

Atención a los siguientes tres parámetros que tendréis que adaptar a vuestra instalación:

  • udpbindaddr: Cambiar el puerto de ejemplo 42187 por uno mayor que 1024 y que no esté en la lista de puertos conocidos.
  • externhost: Debes tener un servicio de DNS dinámico para que Asterisk pueda resolver tu IP pública. Hay múltiples opciones gratuitas que encontrarás en esta lista de proveedores. Uno de los más conocidos es No-IP. Indica en este campo el dominio que hayas creado, y asegúrate de instalar el programa cliente correspondiente que mantenga actualizada tu IP. Si te pierdes en este punto te recomiendo buscar una guía sobre DNS Dinámico.
  • localnet: Adapta el rango y la máscara de red en función de la configuración de tu red local.

El Dialplan básico quedaría resumido a lo siguiente:

Os animo a seguir enviando sugerencias sobre los contenidos que queráis ver publicados en este espacio. Intentaré darle salida a todas las propuestas que me resulten interesantes.

Índice del Curso Asterisk:

Curso Asterisk (VII): Seguridad

Desde el capítulo 5 estamos conectados a proveedores VoIP, lo que significa que un atacante malintencionado podría generarnos pérdidas económicas si no tuviéramos bien configurado nuestro Asterisk.

Configurarlo correctamente no parece complicado: das de alta tus extensiones y tus proveedores, y listo. Todo tiene clave, todo parece estar bien. ¿Seguro? Desgraciadamente, la implementación SIP de Asterisk es insegura en su configuración por defecto y necesitaremos saber lo que estamos haciendo para proteger nuestro sistema de usos no autorizados.

Pero que no cunda el pánico, porque si has seguido el curso al pie de la letra, ya has ido aplicando sin saberlo una gran parte de las medidas que detallaremos en el presente capítulo. Aun así presta atención, ya que es necesario conocer ciertos detalles para no meter la pata cuando crees por ti mismo tu configuración, y para poder llevar a cabo otras cosas que hasta ahora no hemos hecho.

 

1. Cambia el puerto por defecto

Estás en tu casa, tienes una IP dinámica, y te sientes seguro. ¿Crees que nadie escaneará tu Asterisk desde el exterior? Te equivocas.

Existe un importante negocio de venta de minutos de voz a través de servidores vulnerables, por lo que el puerto 5060/UDP es ampliamente escaneado en Internet. Si no quieres que tu servidor forme parte de esta red lo mejor es que no lo encuentren, y un primer paso es cambiar el puerto por defecto para pasar un poco más desapercibidos.

Modifica el puerto en la propiedad udpbindaddr de /etc/asterisk/sip.conf, eligiendo un valor por encima de 1024 que no esté en la lista de puertos conocidos. En este ejemplo usaremos el 42187, pero tú debes elegir otro:

A continuación reinicia Asterisk. Después, tendrás que reconfigurar tus clientes y la tabla NAT de tu router para reflejar el cambio de puerto.

Por supuesto, la seguridad basada en el ocultamiento de información no es una buena estrategia de seguridad, pero no nos vamos a quedar aquí. Nuestro objetivo es securizar correctamente Asterisk basándonos en otros mecanismos. Este primer punto simplemente persigue el objetivo de ser más discretos bajo el radar.

 

2. Cambia el User Agent

Nuestro Asterisk tiene la mala costumbre de dar demasiada información. Concretamente indica a cada visitante que se trata de un servidor Asterisk e informa de la versión exacta que estamos utilizando. No hay mayor problema en que indique lo que es, pero es una mala idea que devuelva la versión. Vamos a cambiarlo.

Debemos editar /etc/asterisk/sip.conf y añadir la propiedad useragent en la sección general:

Como siempre, hay que reiniciar Asterisk para que los cambios se apliquen.

 

3. El contexto por defecto siempre es de rechazo

Cuando un usuario no autenticado accede a nuestro Asterisk, se utiliza el contexto definido en la sección [general] para definir las acciones que puede realizar este usuario. Por supuesto no vamos a permitir usuarios anónimos en nuestro sistema, pero debemos asumir que esta situación podría darse ante la aparición de un bug de seguridad o por una mala configuración.

Para minimizar los riesgos y la capacidad de acciones de un atacante anónimo, siempre vamos a definir un contexto en la sección [general] que no permita hacer nada. Es decir, colgará toda llamada incondicionalmente.

De esta manera, un atacante anónimo que consiga pasar por alto la autenticación no podrá realizar llamadas.

 

4. No permitas invitados

Asterisk por defecto permite que usuarios sin autenticar hagan llamadas a través del sistema. ¿Cómo es eso? Mira:

Parámetro Valor por defecto Descripción
allowguest yes Permite que los usuarios anónimos (sin autenticar) realicen llamadas a través del contexto definido en [general]

Para evitarlo tendremos que añadir la siguiente línea a nuestra sección [general]:

Sin esta línea, y sobre todo si tampoco has hecho lo indicado en el paso anterior, cualquiera podrá realizar llamadas a través de tu sistema sin necesidad de disponer de usuario y clave válidos.

 

5. No filtres información de extensiones

Otro problema es la exposición a ataques de fuerza bruta. Encontrado un servidor Asterisk, lo primero es dar con una extensión válida para empezar a probar claves sobre ella. La mayoría de servidores Asterisk tendrán definidas extensiones internas numéricas de tres o cuatro dígitos en total, así que es cuestión de probar el rango de extensiones [100, 9999]. Esto se puede hacer en muy poco tiempo con herramientas específicas, por ejemplo con SIPVicious.

Por defecto, Asterisk devuelve una respuesta diferente en función de si el usuario ha intentado registrarse con una extensión válida, aunque la contraseña enviada sea incorrecta. Esto permite a un atacante encontrar rápidamente nuestras extensiones para, a continuación, comenzar ataques de fuerza bruta sobre ellas.

Debemos configurar nuestro Asterisk de tal forma que siempre ofrezca la misma respuesta independientemente de si la extensión es válida o no. Esto evita problemas de fugas de información (information leakage) a nuestros atacantes.

Parámetro Valor por defecto Descripción
alwaysauthreject no Devolver siempre la misma respuesta independientemente de si el usuario es válido o no.

Debemos añadir la siguiente línea a nuestra sección [general]:

 

6. La configuración NAT siempre en la sección general

Este es otro problema de filtrado de información de extensiones. Para entenderlo tenemos que saber cómo funciona SIP detrás de un NAT.

Cuando un cliente envía una petición a nuestro servidor, dentro del paquete SIP se especifica la IP y puerto a la que el servidor debe enviar la respuesta. El problema es que, si el cliente está detrás de un NAT, la IP y puerto indicados en la cabecera SIP se corresponden con su red interna privada, que no es alcanzable por el servidor. Cuando especificamos en la configuración de Asterisk “nat=force_rport”, estamos indicando al servidor que ignore la dirección de respuesta indicada en la cabecera SIP, y en su lugar utilice la indicada en el datagrama UDP, que está manipulada por el router NAT y apunta correctamente al servidor.

El problema de especificar “nat=force_rport” en cada extensión, como muchos ejemplos sugieren, es que cambia la respuesta del servidor en función de si la extensión existe o no. Un atacante podría ir probando extensiones componiendo un mensaje con un puerto en su cabecera SIP, y otro puerto diferente en su datagrama UDP. En función de en qué puerto reciba la respuesta sabrá si la extensión existe.

Para evitarlo, deberemos especificar la configuración NAT en la sección [general], para que así el servidor tenga un comportamiento uniforme.

Esto es algo que curiosamente no se suele mencionar, y la recomendación en la mayor parte de los ejemplos es especificarlo por extensión. A mi juicio, hacerlo por extensión supone un gran riesgo de seguridad.

 

7. Cuidado con los “insecure”

Nunca tengas un “insecure=very” o “insecure=invite” en la definición de una extensión interna de tu Asterisk. Si lo haces, estás permitiendo que cualquiera pueda hacer llamadas sin autenticarse con contraseña. Es decir, estarías permitiendo realizar llamadas sólo con adivinar una extensión válida. Esto es algo que también se ve en algunos ejemplos disponibles en Internet, así que cuidado con el copy&paste.

El parámetro “insecure=invite” (o “insecure=very”) se utiliza sólo en las conexiones con proveedores, ya que permite que ellos se comuniquen con nosotros sin tener que autenticarse, principalmente para entregarnos llamadas. Esto no supone un riesgo, ya que en este caso, el contexto definido para el proveedor lo que hará será hacer sonar una de nuestras extensiones internas, pero no realizar gasto a través de otro proveedor.

 

8. Limita el número de llamadas simultáneas

Si tu sistema se ve comprometido y un atacante tiene la oportunidad de realizar llamadas a través de tu Asterisk, no interesa que pueda canalizar demasiadas llamadas en paralelo.

Aunque normalmente los proveedores que utilicemos ya tienen una limitación de llamadas por su propia seguridad, es conveniente que nosotros también especifiquemos nuestros propios límites. Esto es tan simple como especificar el siguiente parámetro en cada extensión que hayamos definido:

Podéis especificar un límite razonable para minimizar los daños en caso de que nos veamos comprometidos, sin que ello nos limite nuestro propio uso razonable.

 

9. Revisa el registro de llamadas (CDR)

Esta es una tarea manual, pero es conveniente realizarla de vez en cuando. Asterisk guarda registro de todas las llamadas entrantes y salientes, y conviene echarle un vistazo de vez en cuando en busca de actividad sospechosa.

Los logs de llamadas están en la ruta: /var/log/asterisk/cdr-csv/Master.csv

Si lo prefieres, en el logrotate puedes hacer que se envíe una copia a tu email. Consulta la documentación de logrotate para saber cómo hacerlo.

 

10. Utiliza Fail2Ban

Lo que viene aquí es aplicable a Asterisk 10 o superior.  Las versiones anteriores no disponen de un log específico para seguridad, y Fail2Ban no será capaz de detectar todos los ataques posibles contra nuestra centralita.

Fail2Ban es una herramienta utilizada para detener accesos por fuerza bruta mediante IpTables. Su funcionamiento se basa en el análisis de logs en busca de patrones. Cuando detecta cierto número de intentos en un intervalo de tiempo, bloquea la IP del atacante añadiendo una regla de rechazo en IpTables. Es una herramienta fundamental para proteger cualquier servidor expuesto a Internet.

Primero debemos activar el log de seguridad en la configuración de Asterisk, y cambiar el formato de fecha del log para que Fail2Ban lo pueda interpretar correctamente. Debemos editar el archivo /etc/asterisk/logger.conf para hacer dos cambios:

Tras las modificaciones, recarga la configuración del logger:

Para instalar Fail2Ban en Debian y derivados debemos hacer:

Una vez instalado debemos añadir un filtro específico para el log de seguridad de Asterisk. Crea un nuevo archivo en /etc/fail2ban/filter.d/asterisk.conf con el siguiente contenido:

A continuación, debemos añadir las reglas para Asterisk en la configuración de Fail2Ban. Concretamente vamos a hacer que si un usuario comete 5 fallos en 24 horas, se le baneará de todo el servidor durante otras 24 horas. Esto limita a los atacantes a hacer un máximo de 5 intentos al día.

Añade este contenido al final de /etc/fail2ban/jail.conf

Reinicia el servicio de Fail2Ban para aplicar los cambios y ya estaremos protegidos:

Para conocer el estado de Fail2Ban con nuestra regla de Asterisk y ver cuántos atacantes ha filtrado, haremos lo siguiente:

Además de proteger nuestro Asterisk, Fail2Ban incluye por defecto reglas para diversos servicios, entre ellos SSH. Nuestro servidor estará ahora mucho mejor protegido frente a ataques de fuerza bruta.

 

Bonus Track: Malas Prácticas

  • No declarar “allowguest=no” en [general]
  • No declarar “alwaysauthreject=yes” en [general]
  • Permitir hacer llamadas desde el contexto definido en [general]
  • Definir la configuración NAT por cada peer, y no en [general]
  • Indicar “insecure=very” o “insecure=invite” en extensiones propias

Por cada uno de estos errores que cometas, ¡golpe de remo!

golpe_remo

Índice del Curso Asterisk:

OpenSSL Heartbleed, descripción gráfica

A veces es difícil explicar una vulnerabilidad a alguien que no tiene muchos conocimientos sobre seguridad. Cuando esto ocurre, una imagen suele funcionar mejor que una explicación técnica.

Esta imagen la he encontrado hoy y me ha encantado:

heartbleed_explanationRecordad que las versiones afectadas son:

  • OpenSSL 1.0.1 – 1.0.1f
  • OpenSSL 1.0.2-beta

Y que las siguientes versiones NO están afectadas:

  • OpenSSL 0.9.8 (all branches)
  • OpenSSL 1.0.0 (all branches)
  • OpenSSL 1.0.1g

Para actualizar en Ubuntu/Debian:

Si vuestro servidor utiliza OpenVPN-AS, que sepáis que utiliza sus propias librerías que tendréis que actualizar de forma independiente. Más información aquí:

OpenVPN Docs: Heartbleed vulnerability on Access Server 1.8.4 –> 2.0.5

Otros enlaces de interés:

Página oficial OpenSSL Heartbleed

Heartbleed Test

 

Curso Asterisk (VI): Lidiando con el NAT

El enemigo público número uno del protocolo SIP son las tablas NAT. El NAT es la principal causa de problemas a la hora de montar nuestro servidor Asterisk. Desafortunadamente para nosotros, debido a la falta de IPs públicas de IPv4, lo normal en nuestros hogares es que estemos detrás de un NAT. Por lo tanto, si queremos montar nuestro Asterisk dentro de casa, tendremos que pelearnos con él.

Si haciendo pruebas se obtienen alguno de estos resultados, casi seguro que estemos experimentando problemas derivados de estar dentro de una red privada con NAT:

  • Audio sólo en un sentido
  • Ausencia total de audio en ambos sentidos
  • No puedes recibir llamadas
  • Las llamadas se cortan transcurridos 10-30 segundos desde el establecimiento

 Los escenarios posibles son los siguientes:

  • El servidor está detrás de un NAT
  • Sólo un extremo está detrás de un NAT
  • Ambos extremos están detrás de un NAT
  • Ambos extremos y el servidor están detrás de un NAT

El escenario más complicado es el último, donde uno de los extremos de la conversación está detrás de un NAT, el otro extremo está detrás de otro NAT diferente, y el servidor está detrás de un tercer NAT.

Las soluciones que se encuentran por Internet en ocasiones resultan confusas, incorrectas o incompletas. Personalmente me ha costado mucho tiempo y esfuerzo dar con la solución definitiva. Afortunadamente para vosotros, una vez que tienes el conocimiento no es tan complicado aplicarlo. Lo vamos a ver en dos apartados: solucionar los problemas de los extremos, y solucionar los problemas del servidor.

Extremos detrás de un NAT

Deberemos añadir las siguientes dos líneas en la sección [general] de la configuración SIP de nuestro Asterisk:

Y punto. No tiene más misterio.

Servidor detrás de un NAT

Tenemos que hacer dos cosas. Por un lado, debemos abrir en el router los puertos necesarios hacia la IP de nuestro servidor Asterisk.

Para ello, debemos consultar el contenido de “/etc/asterisk.rtp.conf” y fijarnos en los valores de los parámetros “rtpstart” y “rtpend”. Por ejemplo:

Según el ejemplo, debemos abrir en nuestro router el rango de puertos 10000-20000/UDP, además del 5060/UDP correspondiente al protocolo SIP. Consulta el manual de tu router para saber cómo abrir puertos hacia la IP de tu servidor Asterisk.

Por otro lado, necesitaremos un servicio de DNS dinámico del tipo No-IP o FreeDNS. Si no sabes cómo hacerlo, en Internet hay numerosas guías que lo explican muy bien.

Vamos a suponer que tenemos un dominio “ejemplo.no-ip.org” correctamente configurado, y que el rango privado de IPs de nuestra red es del tipo “192.168.0.x”.  Deberemos añadir las siguientes líneas en la sección [general] de la configuración SIP de nuestro Asterisk:

Gracias a esta configuración, nuestro servidor Asterisk sabe cuándo las peticiones surgen desde dentro de la propia red privada del servidor, y cuándo provienen del exterior. En este último caso, en lugar de encapsular la IP privada del servidor en los paquetes SIP, utiliza la IP pública a la que apunta el dominio especificado. De esta manera, el extremo obtiene la IP de contacto correcta y puede responder correctamente al servidor.

Ejemplo completo

Supongamos lo siguiente:

  • Queremos poder contactar con extremos que estén detrás de un NAT
  • Nuestro servidor Asterisk está detrás de un NAT
  • El rango de IPs privadas de nuestro servidor Asterisk es de la forma 192.168.0.x
  • Tenemos un dominio DNS dinámico “ejemplo.no-ip.org” correctamente configurado con la IP pública de nuestro Asterisk

Para cumplir con estos objetivos, deberíamos añadir las siguientes líneas a la sección “general” de nuestra configuración SIP:

Consideraciones adicionales

  • Si los clientes disponen de ellas, conviene activar las opciones STUN e ICE.

 

Índice del Curso Asterisk:

Curso Asterisk (V): Interconexión con proveedores VoIP

Ha llegado el momento de que nuestra centralita Asterisk pueda comunicarse con el exterior. Mediante el uso de proveedores de telefonía VoIP podremos realizar llamadas a la Red de Telefonía Conmutada, y también que nos puedan llamar desde ella. Aquí empieza el verdadero potencial de Asterisk.

Podemos separar los proveedores VoIP en dos categorías diferenciadas en función del servicio que proporcionan:

  • Proveedores de minutos: Permiten realizar llamadas hacia la Red de Telefonía Conmutada, cobrándonos por tiempo u ofreciéndonos tarifas planas de llamadas. Las tarifas son variadas, pero podemos encontrar precios de 1 cent/minuto o incluso menos a destinos tanto nacionales como internacionales.
  • Proveedores de DID: Nos proporcionan un número de teléfono de la Red de Telefonía Conmutada donde cualquier persona nos pueda llamar, y nos entregan las llamadas  a nuestro Asterisk. Normalmente se alquilan por meses, y tienen un coste entre 2 y 10€/mes según el proveedor y el tipo de número. Por ejemplo, podemos tener un DID de numeración fija de Madrid del tipo “91 xxx xx xx”, o de cualquier otra provincia española. También podemos alquilar números de países extranjeros para que nos llamen desde allí a precio de llamada local.

Y por supuesto, podemos encontrar proveedores que ofrezcan los dos servicios al mismo tiempo.

Para configurar un proveedor VoIP tendremos que hacer algunos cambios en nuestra configuración:

  • En “sip.conf”
    1. Añadir una nueva sección con los datos de nuestro proveedor (IP, puerto, username, password y codecs a utilizar).
    2. Añadir la línea de registro. De la misma manera que nuestras extensiones internas se registran con nuestro Asterisk, nuestro Asterisk se tiene que registrar con el proveedor externo. El registro realiza una autenticación con nuestra cuenta en el servidor VoIP del proveedor.
  • En “extensions.conf”
    1. Añadir contextos para los proveedores de DID, es decir, aquellos que sí van a interactuar con nuestro sistema para entregarnos llamadas.
    2. Los proveedores que sólo nos ofrezcan minutos no necesitan interactuar con nosotros, así que por seguridad siempre les asignaremos un contexto de rechazo. En nuestros ejemplos, el contexto “general” es un contexto de rechazo.
    3. Añadiremos las reglas de llamada para los destinos que nos interesen, modificando los contextos de aquellos usuarios que queramos que tengan salida al exterior.

 

DANDO DE ALTA LOS PROVEEDORES VOiP

Para que resulte más ilustrativo y práctico vamos a centrar los ejemplos en dos proveedores reales, probablemente dos de los más utilizados en España:

Proveedor Propósito
Netelip Proveedor tanto de DIDs (recibir llamadas) como de minutos (hacer llamadas).
FreeVoIPDeal Proveedor exclusivamente de minutos.

No me voy a centrar en el proceso de alta en las correspondientes webs, ya que se escapa de los propósitos de este curso, y además es sencillo. Vamos a suponer que hemos creado una cuenta y tenemos el nombre de usuario y clave de ambos proveedores.

Netelip

Tenemos que añadir la siguiente sección al archivo de configuración sip.conf, poniendo vuestros datos correspondientes en los campos “username” y “secret”.

A continuación pasaremos a describir los diferentes campos:

Campo Descripción

type

Con los proveedores usaremos siempre el tipo de cuenta "peer".
host El nombre o la IP del servidor SIP de nuestro proveedor.
fromdomain Establece el dominio asociado a nuestra cuenta de usuario. Este dato nos lo proporciona el proveedor.
username Nombre de usuario de nuestra cuenta SIP en el proveedor.
secret Password de nuestra cuenta SIP.
insecure El término resulta más preocupante de lo que debería. Insecure permite cambiar algunos aspectos de la autenticación, normalmente para permitir llamadas entrantes desde proveedores. En este caso, "port" indica que la autenticación se haga exclusivamente en base a IP, sin tener en cuenta el puerto; e "invite" indica que no se necesita autenticación con usuario/password para hablar con nosotros.
context El contexto donde se enviarán las llamadas entrantes desde este proveedor.
canreinvite Estableciendo a "no" obligamos a que el audio de las llamadas pasen obligatoriamente por Asterisk. Esto añade algo de latencia pero nos ahorra problemas con el NAT.

Además de lo anterior, tenemos que hacer que Asterisk envíe el usuario y password de nuestra cuenta al proveedor para registrarnos con él. Esto es necesario para indicar que estamos activos, y decirle dónde nos puede encontrar cuando nos tenga que entregar una llamada. Esta parte se hace con la línea de registro en la sección [general], indicando el nombre de usuario y el nombre de la sección que hemos definido para el proveedor, en este caso [trunk-netelip]:

FreeVoIPDeal

Hacemos lo mismo para definir la conexión con FreeVoIPDeal. La única diferencia es que reenviaremos todas las llamadas entrantes al contexto general de rechazo. Esto es porque FreeVoIPDeal sólo proporciona minutos, es decir, sólo nos permite llamar, y nunca deberíamos recibir llamadas desde este proveedor. Por tanto, por seguridad le asignamos un contexto que rechaza todas las llamadas entrantes.

Y también necesitamos una línea de registro en [general]:

 

CONFIGURANDO EL DIALPLAN

El siguiente paso es configurar el DialPlan tanto para las llamadas entrantes como para las salientes.

Supongamos que, además de los dos proveedores anteriores, tenemos dada de alta una extensión interna “3001” asociada al contexto “extensiones”.

Tenemos que hacer dos cosas:

  • Crear el contexto “callin-netelip” donde redirigiremos las llamadas entrantes para que suenen en nuestra extensión interna 3001.
  • Modificar el contexto “extensiones” para permitir llamar al exterior desde nuestras extensiones internas.

Crear el contexto “callin-netelip”

Añadiremos a nuestro DialPlan lo siguiente:

Campo Descripción

Extensión "s"

Extensión especial de Asterisk que se activa cuando no hay ninguna otra extensión del contexto actual que encaje con la llamada entrante. Como en este caso nos da igual el número de destino marcado, usamos la extensión "s" para capturar todas las llamadas entrantes sin importar el patrón.

Dial(SIP/3001)

Redirige la llamada hacia la extensión 3001 de SIP. Es decir, cuando alguien llame a nuestro número de Netelip desde la Red de Telefonía Conmutada, sonará nuestra extensión 3001.
Hangup(16) Por último, al terminar la llamada colgaremos a la persona que nos ha llamado. El código 16 indica que la llamada ha terminado con normalidad.

Modificar el contexto “extensiones”

Una de las ventajas de usar Asterisk es que podemos configurar las rutas de llamadas como mejor nos convenga. Por ejemplo, nos puede interesar cursar unos tipos de llamadas a través de un proveedor concreto por razones de calidad o precio, y el resto de llamadas a través de otro proveedor. La flexibilidad es total.

Supongamos lo siguiente:

  • Queremos usar Netelip para llamar a teléfonos fijos de España.
  • Queremos usar FreeVoIPDeal para llamar a móviles de España.
  • Queremos dar un mensaje de voz cuando se marque un número no válido (ej: llamadas internacionales).

Para organizar mejor el dialplan y asegurar que las expresiones se evalúan en el orden correcto vamos a introducir una nueva directiva: “include”. Esta directiva nos permite definir un contexto como composición de contextos, y nos permite controlar mejor el orden de evaluación de extensiones. Veámoslo con un ejemplo:

Hemos definido el contexto “extensiones” como la suma de “llamadas-externas” + “llamadas-no-validas”, en ese orden.

Al realizarse una llamada a través del contexto “extensiones”, Asterisk buscará primero una coincidencia de extensión dentro del contexto “llamadas-externas”. Si hemos marcado un número fijo español o un móvil que empiece por 6, la extensión marcada cuadrará con una de las dos definiciones existentes y cursará la llamada a través del proveedor correspondiente.

Si no cuadra con ninguna definición de “llamadas-externas”, entonces buscará en el contexto “llamadas-no-validas”. Este contexto tiene una única extensión definida que lo admite todo, por lo que siempre que se llegue hasta aquí aceptará realizando lo siguiente: descuelga, indica que el número marcado no es válido, y cuelga.

Es decir, cuando marquemos un número definido con alguna regla en “llamadas-externas”, Asterisk cursará la llamada a través del proveedor que hayamos asignado. Si el número marcado no está aceptado por nuestro DialPlan (por ejemplo llamadas internacionales o líneas 806 xxx xxx), entonces Asterisk nos dará una locución de aviso y colgará sin enviar la llamada al exterior.

 

EJEMPLO COMPLETO

Supongamos lo siguiente:

  • Tenemos una extensión interna: 3001.
  • Tenemos dos proveedores de telefonía: Netelip y FreeVoIPDeal.
  • Queremos usar Netelip para llamar a fijos de España.
  • Queremos usar FreeVoIPDeal para llamar a móviles de España.
  • Queremos que las llamadas entrantes de Netelip suenen en la extensión 3001.

Índice del Curso Asterisk:

Reparar el display de un Kenwood TH-79E

Ha llegado a mis manos un transceptor de radio bibanda UHF/VHF Kenwood TH-79E con problemas de visualización del display. Concretamente la unidad que me han traído sufría parpadeos y problemas con algunos segmentos del LCD, aunque la mayoría de unidades suelen presentar el display completamente en blanco.

Se trata de un problema habitual de este modelo producido por acumulación de suciedad en la cinta que va del LCD a la unidad “A”. La solución es tan simple como llegar a la cinta, limpiar los contactos con alcohol y volverlo a montar, con la única salvedad de que tendremos que desoldar un par de contactos del LCD para poder retirarlo. Todo viene bien detallado en el Manual de Servicio del modelo:

Kenwood TH-79E Service Manual

El procedimiento es sencillo, aunque hay que tener cuidado a la hora de sacar la placa “A” de la carcasa, ya que va encajada a presión y la podemos partir. El procedimiento es:

  1. Retirar los tres tornillos traseros y abrir la unidad.
  2. Separar las dos mitades y desconectar de la unidad “A” el cable plano y el cable tricolor que la une a la unidad “B”.
  3. Quitar un pequeño PCB que va sobre la unidad “A”, cerca del cable plano. Sale simplemente tirando hacia arriba.
  4. Quitar la cubierta que separa el teclado del alojamiento de baterías haciendo palanca con un destornillador en la parte inferior.
  5. Quitar los dos tornillos dorados que fijan la unidad “A” al chasis.
  6. Quitar las dos espigas de los controles de volumen y frecuencias, retirar con cuidado la cubierta superior donde se alojan, la goma protectora y las dos tuercas.
  7. Separar la unidad “A” del chasis haciendo palanca con cuidado desde arriba, donde están las espigas de volumen. A partir de este punto cuidado con perder piezas.
  8. Con malla desoldadora, quitar las dos soldaduras de alimentación del LCD.
  9. Retirar con mucho cuidado el LCD, haciendo palanca sobre los cuatro enganches que lo fijan a la unidad “A”. Ojo con perder el pad de goma que va sobre los contactos del LCD.
  10. Limpiar los contactos del LCD, de la unidad “A”, y del pad de goma.
  11. Alojar el pad de goma en el hueco que tiene en el LCD y montar el LCD de vuelta en la unidad “A”. Hay que prestar atención a que el pad esté bien colocado y haga buen contacto.
  12. Montar el transceptor siguiendo los pasos en orden inverso.

Y a continuación, algunas fotos del proceso:

IMG_2801

Transceptor abierto por la mitad. A la izquierda está la unidad “A”. Debemos retirar los dos cables y el pequeño PCB que se ve abajo en el centro.

IMG_2803

Para separar la unidad “A” de la carcasa debemos retirar dos tornillos dorados.

IMG_2804

Retiramos el protector que separa el teclado del compartimento de baterías haciendo palanca desde la parte inferior.

IMG_2806

Retiramos las espigas de volumen y frecuencias, la cubierta, el protector de goma y las dos tuercas.

IMG_2808

Una ves desoldado, el LCD sale fácilmente. Cuidado con perder el pad de goma que realiza el contacto entre el LCD y la unidad “A”. Debemos limpiar con alcohol los contactos de ambas partes, y el pad.

IMG_2811

Una vez montado con cuidado para que no sobren piezas, ¡funciona!

Curso Asterisk (IV): El Dialplan

En la anterior entrada vimos cómo dar de alta algunas extensiones internas, y trabajamos muy por encima con el Dialplan para poder llamar de una extensión a otra.

El Dialplan es el verdadero corazón de Asterisk y de cualquier sistema VoIP. El Dialplan, o plan de marcado, es una colección ordenada de acciones que se ejecutan cuando alguien marca un número dentro de nuestro Asterisk. El ejemplo más trivial sería que cuando alguien marca la extensión de otra persona, por ejemplo “3001”, suene el teléfono de ese usuario. Sin embargo, se pueden hacer cosas mucho más avanzadas, como por ejemplo gestionar las llamadas en función de un horario, crear una centralita automática de recepción de llamadas, grabar conversaciones, poner música en espera, etc.

Antes de entrar en lo que se puede hacer con el Dialplan, vamos a definir algunos conceptos básicos.

CONCEPTOS BÁSICOS

Extensiones

Definición: Una extensión es una marcación en el teclado de un teléfono.

Por ejemplo, un usuario podría marcar “3001” en su teléfono, y eso sería una extensión. También podría marcar un número de teléfono nacional, como por ejemplo “915881000”, y también sería una extensión.

Aunque lo normal es que las extensiones sean numéricas, no debemos pensar sólo en números, ya que en Asterisk también se pueden definir extensiones como texto. Por ejemplo, “pizza” sería una extensión válida.

Un plan de marcado empieza con una colección de extensiones a las que se puede llamar. Esta definición de extensiones puede ser literal, o puede ser una expresión. Por ejemplo, si hemos definido las extensiones desde la 3001 hasta la 3009, podemos definirlas en nuestro dialplan enumerándolas una detrás de otra, de forma literal:

  • 3001
  • 3002
  • 3003
  • 3004
  • 3005
  • 3006
  • 3007
  • 3008
  • 3009

Sin embargo, si todas ellas van a tener la misma colección de acciones (en general, pasar la llamada a la extensión marcada), sería mucho más cómodo definirlas todas a la vez con una expresión:

  • _300X

Las expresiones van precedidas de guión bajo “_”, que indica que lo que viene a continuación es una expresión que puede cuadrar con más de una extensión. Para definir expresiones en Asterisk disponemos del siguiente lenguaje:

Símbolo Significado
X Cualquier cifra de 0 a 9
Z Cualquier cifra de 1 a 9
N Cualquier cifra de 2 a 9
[x-y] Cualquier cifra de "x" a "y"
[xyz] Las cifras "x", "y" o "z"
. Una o más repeticiones del símbolo anterior
! Cero o más repeticiones del símbolo anterior

En general necesitaremos hacer uso de expresiones para definir las extensiones de nuestro sistema, ya que hay cosas que no se pueden hacer de forma literal. Por ejemplo, no podemos definir uno a uno todos los números de teléfono posibles de España. Lo lógico es decir “los teléfonos móviles en España empiezan por “6” y tienen 9 dígitos en total”, y no empezar a enumerar las 1.000.000.000 (mil millones) de posibilidades existentes. Veamos algunos ejemplos:

Significado Expresión
Todas las extensiones de 4 cifras _XXXX
Todas las extensiones de 4 cifras que empiecen por 3 _3XXX
Móviles de España que empiecen por 6 _6XXXXXXXX
Móviles de España que empiecen por 7 _7[1-4]XXXXXXX
Fijos de España que empiezan por 9 _9[1-8]XXXXXXX
Todos los fijos de España _[8-9][1-8]XXXXXXX

A continuación veremos cómo se relacionan las extensiones con las acciones, llamadas “aplicaciones” en Asterisk.

 

Aplicaciones (acciones)

Definición: Las aplicaciones son el conjunto de acciones a ejecutar cuando un usuario inicia una llamada.

Por ejemplo, supongamos que cuando alguien marque “3001”, queremos que suene el teléfono de esa persona. Sería algo así:

También podríamos querer darle un mensaje a la persona que llama antes de pasar la llamada a destino. Por ejemplo:

O pasar la llamada sólo entre las 10h de la mañana y las 20h de la tarde:

Las aplicaciones más utilizadas son las siguientes:

Aplicación Ficha Descripción
Answer URL Descuelga la llamada entrante
Dial URL Realiza una llamada saliente
Hangup URL Termina la llamada en curso
Wait URL Espera X segundos antes de continuar con la siguiente acción
Festival URL Utiliza el sintetizador Festival para emitir mensajes de voz
Playback URL Reproduce un archivo de sonido o vídeo
SayUnixTime URL Dice la fecha y hora actual a la persona llamante
Background URL Reproduce música en espera
NoOp URL No realiza ninguna operación, pero imprime el mensaje indicado en la consola de Asterisk
ExecIf URL Ejecutar la aplicación indicada si se cumple la condición dada
ExecIfTime URL Ejecutar la aplicación indicada si se cumple el requisito de fecha y hora indicados

En esta página web se puede ver un listado completo de aplicaciones de Asterisk junto con la descripción y sintaxis de cada una de ellas:

Asterisk Applications

 

Prioridades

En un lenguaje de scripting, las acciones se van ejecutando de arriba a abajo, en orden. En cambio, en Asterisk, el orden en el que se ejecutan las acciones debe ser explícitamente indicado mediante números. Así, primero se ejecutará la acción 1, después la acción 2, y así sucesivamente.

Es decir, en los ejemplos anteriores no basta con poner las aplicaciones (acciones) una debajo de la otra. Hay que indicar numéricamente el orden, de forma explícita.

Definición: La prioridad representa el orden en el que se ejecutarán las acciones del dialplan.

La sintaxis para indicar el orden la veremos a continuación.

 

PONIENDO TODO JUNTO

Hemos visto cómo se definen las extensiones mediante expresiones, qué aplicaciones (acciones) podemos utilizar, y también que es necesario especificar de forma explícita el orden de éstas. ¿Cuál es la sintaxis de Asterisk para poner todo esto junto?

Por ejemplo, supongamos que cuando alguien marque la extensión 3001, se pase la llamada sólo entre las 10h de la mañana y las 20h de la tarde:

Generalizando el ejemplo anterior, supongamos que queremos el mismo comportamiento cuando alguien marque cualquier extensión desde la 3001 hasta la 3009. Para esto, lo más cómodo es utilizar expresiones:

Fijaos que en este caso hemos utilizado la variable ${EXTEN} dentro de la llamada a Dial() para que se lance la llamada a quien corresponda. La variable ${EXTEN} es una de las variables básicas que utilizaremos, y que contiene la extensión marcada por la persona llamante.

 

PONIENDO TODO JUNTO: VARIANTES

En “Poniendo todo junto” hemos visto la sintaxis básica del dialplan de Asterisk. Sin embargo, a la larga es una sintaxis muy engorrosa de mantener. El problema es que hay que repetir la expresión en cada línea, y hay que indicar la prioridad de ejecución cuando lo normal es que las acciones se ejecuten de arriba a abajo.

Supongamos este dialplan de ejemplo, donde la expresión cuadra con todos los fijos nacionales de España en formato internacional:

Si quisiéramos introducir una nueva aplicación entre Wait() y Dial(), nos obligaría a actualizar los números de prioridad de todas las aplicaciones que vienen debajo. Si el dialplan fuese mucho más largo, digamos 50 acciones en lugar de 5, imaginaos el engorro que puede suponer esto.

Una solución mejor es indicar que las aplicaciones se ejecuten de forma consecutiva, de arriba a abajo. Para esto, podemos utilizar la prioridad “n”, que indica “next”. De esta forma, podemos introducir nuevas aplicaciones en mitad de un dialplan sin tener que actualizar los números de prioridad. Sólo tenemos que indicar cuál es la prioridad “1”, y utilizar prioridad “n” para el resto:

Por otro lado, cambiar la expresión de las extensiones a las que se hacen referencia también resulta un engorro, ya que la expresión aparece en cada una de las líneas del dialplan. Si quisieramos que el segundo dígito admitiera “cero” para poder llamar a números “902 XXX XXX”, tendríamos que modificar cada una de las líneas de este dialplan. Sin embargo, hay otra sintaxis que permite definir la expresión sólo una vez, e indicar en las siguientes líneas que se trata de la misma extensión:

Esta última sintaxis es la que utilizaremos en el presente curso a partir de ahora, ya que es la más cómoda y compacta de todas las posibles.

 

CONTEXTOS

Ya hemos visto cómo se definen las extensiones de marcación y las acciones asociadas a ellas. Según lo estudiado hasta ahora, todos los usuarios tienen las mismas libertades. Ya que no todos los usuarios son iguales, necesitamos algún mecanismo que nos permita variar el comportamiento del sistema en función del mismo. Eso son los contextos.

Cuando definimos un usuario en sip.conf le asignamos un contexto. Cuando ese usuario inicia una llamada, se utiliza ese contexto del dialplan para ver qué extensiones tiene accesibles y qué acciones debe realizar el sistema.

Definición: Los contextos representan la unidad de organización más básica del dialplan de Asterisk. Un contexto engloba extensiones y acciones. Se utiliza para aumentar la seguridad del sistema, y para ofrecer servicios diferenciados en función del usuario.

Un contexto se define de la siguiente manera:

 

EJEMPLO COMPLETO

Supongamos un hotel con una recepción y tres habitaciones que cumple lo siguiente:

  • Para llamar a la recepción hay que marcar “0”
  • Para llamar a las habitaciones hay que marcar el número de habitación: “101”, “102” o “103”
  • La recepcionista puede llamar a cualquier habitación
  • Los huéspedes sólo pueden llamar a recepción (no pueden llamar a otras habitaciones)

Índice del Curso Asterisk: