Categoría: Seguridad

  • Nuevos proyectos para Asterisk en la AstriDevCon 2008

    En la última AstriDevCon (concentración de programadores de Asterisk para planear nuevos proyectos relacionados con Asterisk) que se realizó la semana pasada entre otros proyectos, se plantearon algunos temas interesantes entre los que se encuentran:

    – Negociación de códecs y media
    – API y Framework
    – CLI (Console Line Interface)
    – Seguridad VoIP

    Sobre la Negociación de códecs y media, un tema bastante discutido y antiguo, existen diversos parches para realizar una negociación de códecs medianamente funcional, aunque parece ser que ahora se lo van a tomar mucho más en serio y han elaborado un plan de desarrollo sobre cómo debería ser.
    Podeis ver la descripción del problema y su posible solución en esta presentación:
    * Presentación sobre la negociación de códecs y media.

    En cuanto a la parte de las API y Framework, aparece un nuevo proyecto bastante ambicioso y con un nombre en clave como PineMango (mezcla entre pinneapple -piña- y mango).

    Este proyecto podría llegar a ser uno de los saltos más interesantes en cuanto a la integración de Asterisk con otras aplicaciones y uno de los objetivos de Asterisk 1.6: soporte para infraestructuras distribuidas y especialmente grandes (varios miles de extensiones y llamadas simultaneas).Después de leer los emails de la lista Asterisk-dev y algunos documentos sobre este proyecto que han hecho personas como Olle Johannson, Nir Simionovich, Txafrir Cohen y Russell Bryant, y muchos más, me queda claro que Asterisk pasará a disponer de soporte nativo para muchos estándares tan interesantes como Radius, Diameter, Django, Ruby, PHP, Lua, LDAP, y muchos otros.
    *Presentación sobre la parte de API y nuevos Frameworks para la integración de Asterisk.

    Y otro de los puntos importantes es sin duda el tema de la Seguridad de la VoIP.
    Asterisk es uno de los sistemas de comunicaciones más seguros que existen (no hay más que ver las decenas de boletines de seguridad mensuales que publica Microsoft o Cisco para darse cuenta que Asterisk es una aplicación bastante segura pese a tener sus bugs), no obstante, en sistemas de gran tamaño, la seguridad adquiere un nuevo significado (sobre todo en sistemas distribuidos) y por eso se han elaborado un plan de actuación y una API especial (ASAAsterisk Security Arquitecture-) para mejorar aún más la seguridad y arar el terreno para desarrollar nuevas medidas de integración con otros sistemas seguros. Este sistema también forma parte del proyecto PineMango:
    * Presentación sobre la parte de Asterisk Security Arquitecture.

    En fín, la AstriDevCon 2008 ha vuelto a ser un éxito con unos objetivos bastante definidos y un nuevo horizonte con unas vistas impresionantemente interesantes.

  • Vulnerabilidades de base

    Hace un par de meses, leía estupefacto cómo habían descubierto una vulnerabilidad en el mismísimo protocolo DNS que ponía de manifiesto que cuando algo es bueno, nadie lo mira.

    Pues si el DNS fue ámpliamente criticado por dicha vulnerabilidad y poner en peligro toda la infraestructura de nombres en Internet, ahora aparece algo aún más difícil de entender: una vulnerabilidad en el mismísimo protocolo TCP/IP.

    Esta vulnerabilidad permitiría a un atacante desconectar cualquier cosa conectada a la red.

    Se ha especulado bastante sobre lo que se podría hacer, a quién podría afectar y que repercusiones podría tener este descubrimiento, es por eso por lo que la gente de Hispasec han elaborado un FAQ sobre esta vulnerabilidad para aclarar un poco más este desastre.

    Podeis ver el artículo en su web: http://www.hispasec.com/unaaldia/3632

  • Cuidado con los servidores DNS en Asterisk

    Muchas personas, para evitar que su servidor Asterisk se quede bloqueado en el caso en que falle la conexión a Internet, suelen recurrir a diversas técnicas (explicación):

    • Utilizar direcciones IP en lugar de nombres de dominio.
    • Añadir los nombres de dominio que vayan a utilizar en el archivo /etc/hosts.
    • Instalar un servidor DNS en la red local que le sirva de caché y aisle las peticiones de resolución de nombres.

    En muchos casos, la primera opción no es viable, ya que muchos proveedores de servicios IP utilizan el mismo nombre de dominio para realizar round-robin y distribuir la carga entre varios servidores con distinta IP pero el mismo nombre de host.

    Son muchos los que optan por instalar el servidor DNS en el mismo sistema o bien dentro de la red local, pero aquí es donde hay que tener especial cuidado.

    Los servidores DNS son accesibles mediante los puertos 53 UDP y TCP (en algunos casos) y si estos son accesibles desde internet, y los utilizan los sistemas de nuestra red puede ocurrir que seamos vulnerables a diversos exploits e «inyecciones falsas» de registros IP/nombres en la caché DNS lo que puede llevarnos a páginas falsas o incluso a ataques phishing.

    Ahora, con las últimas vulnerabilidades encontradas (y publicadas) en el mismísimo protocolo de DNS son muchos los que se están aprovechando de esto.

    Concretamente, hoy he visto logs de ataques y donde consiguen inyectar direcciones IPs de diferentes páginas (de spam y porno por lo general) en servidores Bind.

    Por suerte, hay técnicas para prohibir el acceso al servidor DNS desde direcciones IPs diferentes a las de la red local, desde el propio servidor Bind o bien desde el maravilloso iptables de Linux.

    Así que… cuidado con los servidores DNS que tengamos instalados, no vayan a darnos alguna sorpresa desagradable. 🙂

  • Asterisk 1.4.21.2 y 1.2.30 Released!

    Empezamos el día con una nueva versión de Asterisk: acaba de ser lanzada 2 nuevas versiones de Asterisk, debido a 2 bugs encontrados en el IAX que han sido gestionados como vulnerabilidades como podeis ver en: AST-2008-010 y AST-2008-011.

    Las nuevas versiones las encontrareis en:
    http://downloads.digium.com/pub/asterisk/

  • Cómo configurar el envío de emails desde Asterisk

    Es una pregunta bastante común y pese a que su respuesta es la misma, voy intentar dejarlo tan claro como sea posible.

    Asterisk es una aplicación, como cualquier otra que corra bajo Linux, y por lo tanto sigue una norma que siguen todas las aplicaciones en Linux: Asterisk NO ENVIA EMAILS, si no que se comunica con el servidor SMTP que tengamos instalado en nuestro sistema local y es este el que envía el email. Incluso si queremos utilizar un servidor remoto con una cuenta, el procedimiento sigue siendo el mismo.

    Por este motivo, y por que todas las aplicaciones en linux funcionan prácticamente igual (apache, pureftpd, syslog, etc…) suelen darle los emails que quieren enviar a una aplicación bastante conocida: SendMail.

    SendMail es un servidor de envío de emails (SMTP) y fue uno de los primeros y más avanzados servidores de este tipo, pero su poca fiabilidad (demasiados bugs para los administradores de redes) unido a su complejidad si queríamos configurar un servidor serio, hizo que apareciesen otros servidores SMTP más ligeros, simples y rápidos que Sendmail.

    No obstante, todos los sistemas continúan intentando enviar emails dejándolos a Sendmail y es por esto por lo que los nuevos y más sencillos servidores SMTP utilizan un truco para hacerse pasar por Sendmail y poder «suplantarlo», esto es, crean un enlace simbólico en el sistema con el nombre «sendmail», de manera que cuando una aplicación intenta acceder a «sendmail», realmente quien contesta es esta aplicación. 🙂

    Como ya he comentado, casi todas las aplicaciones que tienen la necesidad o la opción de enviar emails utilizan el servidor SMTP local, esto ha hecho que muchas distribuciones, para facilitar la configuración y envío de emails, instalen por defecto algunos sustitutos de sendmail como por ejemplo exim o postfix son las más conocidas.

    El principal problema de utilizar el servidor SMTP local es el proveedor: Debido al aumento de correos SPAM, los proveedores y los servidores de correo que van a recepcionar tu email comprobarán si realmente el servidor del que procede el email es realmente un servidor «oficial» o bien un servidor que se dedica a enviar SPAM, y como el servidor local no es realmente un servidor en toda regla (no tiene registros MX en el DNS de algún dominio, tiene una dirección IP dinámica, o ha sido utilizado por otro spamer) es por lo que se aconseja encarecidamente utilizar una cuenta de algún servidor de emails ya verificado y seguro.

    Posiblemente, tras la instalación de nuestra distribución preferida, podremos enviar emails con el comando:

    echo «Prueba de email» |mail -s «Prueba de email» miUsuario@miDominio.com

    Pero cuando hayamos enviado varios de este tipo y empecemos a confiarnos, veremos como nuestro cliente de correo empezará a considerarlo spam, o puede que ni llegue. Es entonces cuando tendremos que configurar nuestro servidor SMTP local para que envíe los emails mediante una cuenta autentificada.

    Para el ejemplo de configuración voy a hacerlo con Exim (el servidor que viene por defecto con Debian), quizá sea uno de los más sencillos de configurar y de manejar, aunque personalmente siempre he preferido Qmail por ser mucho más seguro, no obstante, como nuestro objetivo no es configurar un servidor de correos en toda regla, vamos a hacerlo con Exim (versión 4) que es la que trae Debian (y Ubuntu) de serie.

    Lo primero que tenemos que hacer es asegurarnos que lo tenemos instalado:

    apt-get install exim4 exim4-config

    Una vez que lo hayamos instalado, aparecerá una pantalla de configuración. Si no aparece, podremos acceder a ella en cualquier momento ejecutando el comando:

    dpkg-reconfigure exim4-config

    ¿Sencillo verdad? 🙂

    Será entonces cuando nos pregunte por distintas opciones de configuración:

    – ¿Quiere utilizar archivos separados para la configuración?
    Respondemos SI

    – ¿De qué forma queremos configurar nuestro servidor?
    Respondemos «enviar por SMARTHOST, y recibir por SMTP o Fetchmail»

    – Escriba el nombre del sistema:
    Respondemos con nuestro dominio: miDominio.com

    – Escriba la dirección IP desde donde va a atender las conexiones al SMTP:
    Respondemos: 127.0.0.1

    – Escriba otros servidores destino que el SMTP será aceptado:
    Aquí no respondemos nada, lo dejamos en blanco.

    – Sistemas a los que reenviar emails ?
    No piques, esto también hay que dejarlo en blanco. 😛

    – Escribe el sistema que gestionará el correo saliente de este sistema:
    (Aquí escribimos nuestro servidor SMTP remoto, por ejemplo…)
    smtp.miDominio.com

    Si queremos utilizar una cuenta de gmail, el servidor SMTP de gmail hay que especificarlo junto con el puerto que va a utilizar, y sería esto: smtp.gmail.com::587 (ojo que lleva dos simbolos de dos puntos antes del puerto)

    – ¿Quiere ocultar el nombre local del sistema local del email saliente?
    Pues NO.

    – Quiere cachear las peticiones DNS para ahorrar ancho de banda?
    Pues NO.

    Bien, hasta ahora tenemos algunos parámetros básicos configurados, pero no hemos indicado el usuario ni la contraseña con el que queremos autentificarnos para enviar emails. Si probásemos a enviar emails, seguramente nuestro servidor remoto recibiría un email de un tal root@localhost y nos lo rechazaría. 🙂

    Vamos a configurar los datos importantes:

    1º. – Editamos el archivo /etc/exim4/passwd.client y escribimos algo como esto:

    smtp.miDominio.com:usuario:contraseña

    En el caso de que queramos utilizar la cuenta de email, deberíamos poner algo como esto:

    gmail-smtp.l.google.com:usuario@gmail.com:contraseña
    *.google.com:usuario@gmail.com:contraseña
    smtp.gmail.com:usuario@gmail.com:contraseña

    De esta manera, sea cual sea el nombre del servidor SMTP que utilicemos en gmail, le enviaremos los parámetros correctos y nos aceptará el envío.

    2º.- Protegemos el archivo para que nadie tenga acceso a leer nuestros datos:

    chown root:Debian-exim /etc/exim4/passwd.client

    3º.- Si estamos configurando nuestra cuenta de Gmail, hay que indicarle (otra vez) que el envío debe hacerlo por el puerto 587 en lugar del estandar (el 25), por lo que tendremos que editar el archivo:

    /etc/exim4/conf.d/transport/30_exim4-config_remote_smtp_smarthost

    y justo encima de la línea que dice algo como: (hosts_try_auth…) añadir lo siguiente:
    port=587

    4º.- Por último, vamos a configurar nuestra identificación saliente:

    echo «root@localhost: usuario@miDominio.com" >> /etc/exim4/email-addresses

    Y listo, lo último que nos queda es recargar la configuración:

    ejecutamos: update-exim4.conf (es un comando 🙂

    Y probamos a enviar un email como hemos hecho antes…

    echo «Prueba de email» |mail -s «Prueba de email» miUsuario@miDominio.com

    y veremos cómo nos llega con el usuario y dominio correcto. 😀

    Bueno, parece más complicado de lo que realmente es. Una vez que se ha configurado unos cuantos sistemas con esta técnica, se hace todo diréctamente y sin tener que recordar los pasitos.

    Una vez tengamos esto hecho y podamos enviar emails con nuestra cuenta oficial, entonces podremos recibir los emails que hayamos configurado en el buzón de voz de Asterisk, o incluso nuestras alertas de arranque de asterisk o incluso enviar faxes mediante Hylafax,…

    Más información:
    http://www.exim.org/
    http://wiki.debian.org/GmailAndExim4
    http://wiki.debian.org/PkgExim4

  • Alerta roja: Caos con las vulnerabilidades en las PBX cerradas

    «Los clientes de las soluciones de Voz sobre IP (VoIP) de Avaya, Cisco y Nortel han sido alertados por unas vulnerabilidades que podrían conllevar la ejecución de código remoto, accesos no autorizados, denegación de servicio y recolección de información. Estos errores han sido encontrados por los Laboratorios VoIPshield y dados a conocer rápidamente a los tres fabricantes con el fin de que tuvieran tiempo suficiente para desarrollar los parches necesarios, según Rick Dalmazzi, presidente y CEO de VoIPshield, quien, no obstante, no ha querido facilitar más detalles dado que su compañía y los tres fabricantes afectados acordaron realizar un anuncio conjunto.»

    «Eso sí, este responsable confirmaba que al menos dos de los tres nombres afectados tienen ya desarrollados los parches que solucionan estas vulnerabilidades y que el tercero de ellos (que no dicen cual es) lo tendrá en breve. Según Dalmazzi, se eligió a Avaya, Cisco y Nortel para hacer estas pruebas de vulnerabilidad porque representan la mayor parte de las ventas de centralitas IP en el mercado estadounidense. No obstante, anuncia que en las próximas pruebas se incluirá también a Microsoft, cuyos resultados estarán disponibles en unos cuatro meses, aproximadamente.»

    Cuando alguien lee una noticia como esta, la mayoría piensa que pueden ser simples errores que se corrigen rápidamente y no tienen mayor repercusión, pero cuando vemos que una vulnerabilidad de este tipo que el usuario NO PUEDE solucionar por su cuenta (al ser código cerrado) y de hecho debe tener contratado un mantenimiento (en función del tamaño de la infraestructura) para tener «derecho» a actualizaciones, el problema se vuelve mucho más grave.

    Dentro de 4 meses, se publicarán las vulnerabilidades del sistemas de comunicaciones de Microsoft. Las típicas centralitas basadas en Windows que, además de las posibles vulnerabilidades que se pueden llegar a encontrar (provocadas generalmente por errores en la programación, o falta de pruebas), se le añade otros que multiplican por 1000 los factores de riesgos, como son el contagio de un virus, troyanos, o simples gusanos que detecte el sistema de comunicaciones y se dedique a hacer llamadas sin parar a números 906 por las noches (por desgracia ya hay varias pruebas de virus de este tipo circulando por internet) lo que puede llegar a ser la ruina completa para una pequeña empresa.

    Sin duda, malas noticias.

  • VoIPER 0.06 Released

    VoIPER es una herramienta de seguridad que permite a cualquier administrador de una red VoIP probar la seguridad de su infraestructa de voz sobre IP. Es una herramienta para «torturar dispositivos SIP» basada en el RFC 4475 y una gran variedad de módulos de módulos auxiliares para detectar fallos y poder depurarlos.

    Voiper incorpora tests para:

    • SIP INVITE (3 tipos diferentes de tests)
    • SIP ACK
    • SIP CANCEL
    • SIP request structure
    • SDP over IP

    Incluye módulos como:

    • Protocol and process based crash detection and recording
    • Fuzzer pause/restart functionality (SFF)
    • Supports clients that require registration prior to fuzzing
    • Simple to expand to new protocols
    • As far as possible, protocol compliance e.g ACKs and CANCELs responses to prevent some clients hanging
    • Target process control (SFF)

    Esta aplicación es una de las principales para hacerle pruebas a los principales softphones públicos: Ekiga, Linphone, Twinkle, Gizmo5, NCH Business Talk, SJPhone,… aunque por esa misma regla de tres, nos puede servir para probar terminales SIP.

    La web de VoIPER trae algunos ejemplos que pueden ayudarnos a aprender cómo funciona.
    Más información: http://sourceforge.net/project/showfiles.php?group_id=208579
    Página principal de VoIPER: http://voiper.sourceforge.net/

  • Google ayudará a los usuarios a denunciar a su proveedor

    Richard Whitt, uno de los directivos de Google ha anunciado que están preparando una serie de herramientas de análisis para que los usuarios puedan detectar cuando su proveedor de internet realiza acciones que perjudiquen los servicios contratados por sus usuarios.

    Prohibir el acceso a determinados puertos, bajar la velocidad de conexión a determinadas horas o limitar el ancho de banda si se hace uso de aplicaciones que utilicen la técnica P2P o VoIP son algunas de las acciones ilegales (ya que no suene venir declarado en el contrato de alta) que suelen llevar a cabo algunos proveedores de banda ancha.

    «Si los proveedores de banda ancha no te van a decir exactamente lo que está pasando en sus redes, queremos darles a los consumidores el poder de descubrirlo por sí mismos«. (más…)

  • Asterisk 1.4.20 Released! (Actualizacion)

    Leyendo VoipNovatos y Saghul.net me doy cuenta que el equipo de desarrolladores de Asterisk acaban de publicar la versión 1.4.20 estable de Asterisk.

    Realmente no hay ningún cambio con respecto a la versión rc3, y justamente sea eso lo que habrán considerado para convertirla en estable: si nadie comenta ningún comportamiento extraño, es que será estable. 🙂

    Entre los cambios con respecto a la anterior versión 1.4.19.2 se encuentran varios referentes al chan_sip (ya era necesario) donde solucionan algunos bugs encontrados y añaden ciertos soportes que mejoran la compatibilidad con otros sistemas SIP.

    Seguramente esta versión, si todo apunta bien, esta será de las más completas y seguras que tiene Asterisk. (cruzaremos los dedos) 😛

    Actualización:
    La versión ha pasado a ser la 1.4.20.1 debido a unos errores de última hora en la consola que han sido corregidos.

    Podeis ver la lista de cambios aquí:
    http://svn.digium.com/view/asterisk/tags/1.4.20/ChangeLog?view=markup

    Y descargarla de donde siempre:
    http://downloads.digium.com/pub/asterisk/

    (El día que deje de escribir los enlaces, seguro que alguien pregunta por ellos… xD)

  • Asterisk 1.6.0-beta9 Released!

    Pese a que muchos blogs y páginas de noticias sobre VoIP y Asterisk anuncian a bombo y platillo cada versión, revisión y corrección de bugs de Asterisk, estoy seguro que más de uno no le importa lo más mínimo cual es la última versión que salió ayer u hoy, no obstante, es importante recordar qué cambios va haciendo Asterisk ya que como un proyecto vivo, aquellos que siguen Sinologic y leen las noticias de las versiones, seguro que conocen en menor o mayor medida qué añadidos son importantes e interesantes para futuras implementaciones.

    En esta ocasión, la versión que ha salido hoy es la 1.6.0-beta9 (la beta más alta que recuerdo en Asterisk) y que tiene como último añadido, una feature escrita por nuestro colega Olle sobre envío de mensajes en modo texto mediante el chan_sip, algo que empieza a tomar forma. Lástima que el chan_sip siempre vaya tan lento pese a ser uno de los módulos más utilizados en Asterisk.

    Sobre todo, lo que tiene esta versión son correcciones de bugs encontrados desde la última versión.

    Podeis ver el ChanLog aquí:
    http://downloads.digium.com/pub/telephony/asterisk/ChangeLog-1.6.0-beta9

    y cómo no, descargarlo de aquí:
    http://downloads.digium.com/pub/telephony/asterisk/