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.

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/

“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 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/

Pese a que está a punto de salir la versión 1.4.20 estable (ya está disponible la versión 1.4.20-rc2), el equipo de desarrolladores de Asterisk acaba de solucionar un importante bug de seguridad en el canal IAX tras lo cual escribieron un parche y este hacía que una llamada sobrecargara el sistema hasta tal punto que Russell Bryant, con un Core 2 Duo a 2.33Ghz era incapaz de manejar 16 canales IAX.

Tras esto, muy recomendable actualizar, sobre todo si se utiliza el canal IAX.

Más Información: http://downloads.digium.com/pub/asterisk/ChangeLog-1.4.19.2
Enlace: http://downloads.digium.com/pub/asterisk/

RTPBreak es una aplicación que detecta, reconstruye y analiza cualquier trama RTP.

La principal ventaja de esta aplicación es que no requiere de la presencia de paquetes RTCP y es totalmente independiente del protocolo de señalización utilizado (SIP, H.323, SCCP, …). La entrada es una secuencia de paquetes, la salida es un conjunto de archivos que puedes utilizar como entrada para otras aplicaciones como Wireshark, sox, grep, awk, cut, sed, etc.

Un ejemplo de esta aplicación:

xenion@gollum:~/dev/rtpbreak-1.3$ sudo src/rtpbreak -i wifi0 \
-g -m -d logz

+ rtpbreak v1.3 running here!
+ pid: 3580, date/time: 19/02/2008#09:49:21
+ Configuration

+ INPUT
Packet source: iface 'wifi0'
Force datalink header length: disabled

+ OUTPUT
Output directory: 'logz'
RTP raw dumps: enabled
RTP pcap dumps: enabled
Fill gaps: enabled
Dump noise: disabled
Logfile: 'logz/rtp.0.txt'
Logging to stdout: enabled
Logging to syslog: disabled
Be verbose: disabled

+ SELECT
Sniff packets in promisc mode: enabled
Add pcap filter: disabled
Expecting even destination UDP port: disabled
Expecting unprivileged source/destination UDP ports: disabled
Expecting RTP payload type: any
Expecting RTP payload length: any
Packet timeout: 10.00 seconds
Pattern timeout: 0.25 seconds
Pattern packets: 5

+ EXECUTION
Running as user/group: root/root
Running daemonized: disabled
* You can dump stats sending me a SIGUSR2 signal
* Reading packets...
! [rtp0] detected: pt=0(g711U) 192.168.0.30:2072 => 192.168.0.20:2074
! [rtp1] detected: pt=0(g711U) 192.168.0.20:2074 => 192.168.0.30:2072
* [rtp1] probable reverse RTP stream: [rtp0]
+ Status
Alive RTP Sessions: 2
Closed RTP Sessions: 0
Detected RTP Sessions: 2
Flushed RTP packets: 3358
Lost RTP packets: 122 (3.51%)
Noise (false positive) packets: 0
+ [rtp1] stats: packets inbuffer=262 flushed=1673 lost=61(3.52%),

call_length=1m2s
+ [rtp0] stats: packets inbuffer=270 flushed=1685 lost=61(3.49%),

call_length=1m2s
* [rtp1] closed: packets inbuffer=0 flushed=2800 lost=115(3.95%),

call_length=1m28s
* [rtp0] closed: packets inbuffer=0 flushed=2819 lost=106(3.62%),

call_length=1m28s
--
Caught SIGINT signal (2), cleaning up...
--

+ Status
Alive RTP Sessions: 0
Closed RTP Sessions: 2
Detected RTP Sessions: 2
Flushed RTP packets: 5619
Lost RTP packets: 221 (3.78%)
Noise (false positive) packets: 0
+ No active RTP streamxenion@gollum:~/dev/rtpbreak-1.3$

Como podeis comprobar, es una herramienta muy potente y muy interesante para monitorización y sobre todo para ayudar a localizar quién o qué está ocasionando problemas.

Enlace: http://xenion.antifork.org/rtpbreak/doc/rtpbreak_en.html

Pulvermedia que parece que no está pasando por uno de sus mejores momentos, acaba de anunciar un webinar sobre Seguridad en entornos IMS (IMS Security - How to Protect Signaling Communications against Attack).

Este webinar se realizará hoy (9 de Abril) a las 19:00h hora española ( 1:00 PM New York, 10:00 AM Los Angeles PDT) con los siguientes puntos interesantes:

• IMS… what does it mean?
• Why secure IMS?
• Common vulnerabilities of IMS
• Signaling between user equipment and CSCF
• IMS security requirements
• IPsec-based SIP security
• Solutions for IMS security

Para los interesados, todavía hay tiempo para inscribirse:
http://www.iian.ibeam.com/events/mult001/25978/

Leyendo el blog de Saúl, me entero que el equipo de desarrolladores de Asterisk acaba de publicar una actualización de AsteriskNOW que soluciona algunos bugs que se encontraron en la versión 1.0.1.

¿Porqué no llevan el sistema de control de versiones en AsteriskNOW de la misma manera que con Asterisk, basado en versiones RC y habilitando fechas para el envío de bugs encontrados por la comunidad?

AsteriskNOW es una distribución de Linux basada en rPath destinada a introducir a los curiosos en el mundo de Asterisk de una forma rápida y visual, no creo que esté indicada para algo serio, ya que para eso tienen el ABE.

Enlace: http://www.asterisknow.org

El equipo de desarrollos de Asterisk ha anunciado varias actualizaciones de seguridad en todas las versiones de Asterisk:

• Asterisk 1.2.27
• Asterisk 1.4.18.1
• Asterisk 1.6.0-beta6 

Estas actualizaciones solucionan algunos bugs de seguridad como:

1. Overflow en el manejo de RTP
2. Llamadas sin autenticarse en el canal SIP
3. Vulnerabilidad en logger y manager.

A actualizar se ha dicho!

Ingate organiza un webinar (charla, webcast,…) sobre seguridad en entornos SIP, algo que seguro le interesará a todos aquellos que trabajamos en entornos donde las comunicaciones viajan mediante este protocolo.

La asistencia a la charla es gratuita, aunque es importante registrarse previamente y será exclusivamente en inglés.

Los ponentes de la charla son Steven Johnson (presidente de Ingate) y Dan York (fundador de Voipsa).

La conferencia será el 10 de Abril a las 19:00 hora española y se permitirá un turno final de preguntas donde los asistentes podrán interrogar a estos expertos.

Temas que enseñarán:

• Fallos de concepto en seguridad, requerimientos y necesidades
• VoIP vs. PSTN: Cómo SIP y la VoIP pueden ser más seguras que la telefonía tradicional
• Los ajustes en seguridad que seguramente necesites (y las que no)
• Aspectos básicos de la seguridad en una empresa con VoIP: SRTP, TLS y NAT traversal
• Últimas novedades en cuanto a segurida

Si estais interesados, tan solo teneis que apuntaros en esta dirección:
https://event.on24.com/eventRegistration/EventLobbyServlet