Probando el soporte IPv6 de Asterisk 1.8

Como ya habréis leído por ahí la próxima versión de Asterisk, la 1.8, traerá soporte para IPv6. Gracias a mi buen amigo Mikel «packet tracer» Jimenez dispongo de plena conectividad IPv6 en mi casa, así que hacer una llamada SIP por IPv6 era la siguiente prueba tras ping6. 😉

No quería ensuciar mucho el servidor de SIPdoc (donde realicé las pruebas) así que opté por instalar Asterisk 1.8 con el script live_ast que ya comenté en su día. Resumiendo:

svn co http://svn.asterisk.org/svn/asterisk/branches/1.8 asterisk18
cd asterisk18
cp contrib/scripts/live_ast .
./live_ast configure
./live_ast install
./live_ast samples
./live_ast run -vvvvvvvvvvvvvvc

Tras instalar asterisk modificamos el fichero sip.conf e indicamos que Asterisk escuche en IPv6:

udpbindaddr=::

Si tenemos una IP concreta a la que queremos bindear haríamos lo siguiente:

udpbindaddr=[2001:470:1f12:X:X::1]:5060

¡Ya tenemos el servidor configurado! Para hacer nuestra primera llamada SIP con IPv6 utilizaremos la herramienta pjsua del proyecto PJSIP.

Por defecto PJSIP no se compila con soporte IPv6, así que haremos lo siguiente para descargar y compilar PJSIP:

svn co http://svn.pjsip.org/repos/pjproject/trunk pjsip
cd pjsip
echo "#define PJ_HAS_IPV6 1" > pjlib/include/pj/config_site.h
./configure && make dep && make

La herramienta pjsua se habrá compilado en el directorio pjsip-apps/bin. Nos cambiamos a ese directorio y ya podemos arrancarla:

./pjsua-x86_64-unknown-linux-gnu --ipv6 --no-tcp

pjsua-ipv6

Probemos ha hacer una llamada: pulsamos ‘m’ e introducimos la URI SIP a la que queremos llamar: ‘sip:1000@[2001:470:1f12:286::2]’.

Si hemos dejado el dialplan por defecto deberíamos estar escuchando a Allison Smith y su demo-congrats. ¡A través de IPv6!

asterisk-ipv6

¡Parece que funciona!

INVITE sip:1000@[2001:470:1f12:286::2]:5060 SIP/2.0
Via: SIP/2.0/UDP [2001:470:c846:1:225:ff:feac:6aca]:5060;rport;branch=z9hG4bKPjBcy323TSZVZa86u8GMIV01Zv8wNs1DAE
Max-Forwards: 70
From: ;tag=-3p-SYm.MD6bVaH-8WHegCIArkOYu.9R
To: sip:1000@[2001:470:1f12:286::2];tag=as349aa7db
Contact: 
Call-ID: cWEqE795OfqpixU.l1IavBkTPpgVmX3F
CSeq: 21549 INVITE
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY,
REFER, MESSAGE, OPTIONS
Supported: replaces, 100rel, timer, norefersub
Session-Expires: 1800;refresher=uas
Min-SE: 90
Content-Type: application/sdp
Content-Length:   310

v=0
o=- 3490026667 3490026668 IN IP6 2001:470:c846:1:225:ff:feac:6aca
s=pjmedia
c=IN IP6 2001:470:c846:1:225:ff:feac:6aca
t=0 0
a=X-nat:0
m=audio 4030 RTP/AVP 3 101
a=rtcp:4031 IN IP6 2001:470:c846:1:225:ff:feac:6aca
a=rtpmap:3 GSM/8000
a=sendrecv
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

--end msg--
 21:51:09.178   pjsua_core.c  RX 659 bytes Response msg
100/INVITE/cseq=21549 (rdata0x1f61238) from UDP
2001:470:1f12:286::2:5060:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP [2001:470:c846:1:225:ff:feac:6aca]:5060;branch=z9hG4bKPjBcy323TSZVZa86u8GMIV01Zv8wNs1DAE;received=2001:470:c846:1:225:ff:feac:6aca;rport=5060
From: ;tag=-3p-SYm.MD6bVaH-8WHegCIArkOYu.9R
To: sip:1000@[2001:470:1f12:286::2];tag=as349aa7db
Call-ID: cWEqE795OfqpixU.l1IavBkTPpgVmX3F
CSeq: 21549 INVITE
Server: Asterisk PBX SVN-branch-1.8-r281052
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
INFO, PUBLISH
Supported: replaces, timer
Require: timer
Session-Expires: 1800;refresher=uas
Contact: 
Content-Length: 0


--end msg--
 21:51:09.180   pjsua_core.c  RX 981 bytes Response msg
200/INVITE/cseq=21549 (rdata0x1f61238) from UDP
2001:470:1f12:286::2:5060:
SIP/2.0 200 OK
Via: SIP/2.0/UDP [2001:470:c846:1:225:ff:feac:6aca]:5060;branch=z9hG4bKPjBcy323TSZVZa86u8GMIV01Zv8wNs1DAE;received=2001:470:c846:1:225:ff:feac:6aca;rport=5060
From: ;tag=-3p-SYm.MD6bVaH-8WHegCIArkOYu.9R
To: sip:1000@[2001:470:1f12:286::2];tag=as349aa7db
Call-ID: cWEqE795OfqpixU.l1IavBkTPpgVmX3F
CSeq: 21549 INVITE
Server: Asterisk PBX SVN-branch-1.8-r281052
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
INFO, PUBLISH
Supported: replaces, timer
Require: timer
Session-Expires: 1800;refresher=uas
Contact: 
Content-Type: application/sdp
Content-Length: 293

v=0
o=root 1289948586 1289948587 IN IP6 2001:470:1f12:286::2
s=Asterisk PBX SVN-branch-1.8-r281052
c=IN IP6 2001:470:1f12:286::2
t=0 0
m=audio 11994 RTP/AVP 3 101
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

Dejo pendiente para otro día el montaje de IPv6 que realicé con Mikel en el servidor de SIPdoc y mi casa.

Happy IPv6 calling!

svcrash: ¿el comienzo del anti-hacking en SIP?

Hace unas semanas fue presentada (el autor también fue invitado al VUC) la utilidad svrash.py, de la suite de seguridad SIPVicious. Con esta utilidad es posible hacer que las utilidades svwar.py y svcrack.py se dentengan, ya que les provoca una excepción. ¿WTF?

Así es, svcrash es capaz de detener los ataques causados desde SIPVicious. Su autor no programó las utilidades para que la gente lanzara ataques contra otros, sino para que cualquiera pudiera comprobar el nivel de seguridad de sus propios sistemas, pero como hay malos sueltos por ahí que utilizan las herramientas de un modo bastante dudoso, programó svcrack.

Svcrash aprovecha un bug (tal vez dejado intencionadamente) para convertirlo en una feature: todas las versiones de SIPVicious tienen un bug que provoca la parada del programa debido a una excepción no controlada si se le envía un To tag con determinada forma. El funcionamiento de svcrash es sencillo: responde a los requests enviados por svcrack o svwar con un 200 OK con el To tag adecuado para provocar una excepción. El autor incluso ha añadido un modo automático, en el cual svcrash funciona en modo demonio leyendo los logs de Asterisk, y responde con éstos 200 OK (con el To tag adecuado) en caso de que Asterisk indique un fallo de autenticación en los logs.

Podéis ver un vídeo de su funcionamiento aquí.

Además de ser una manera elegante de terminar un ataque, el concepto de svcrash me hizo pensar un rato… ¿y si en lugar de bloquear o evitar un ataque simplemente contraatacamos, llegado el momento?

Supongamos el siguiente escenario: estamos sufriendo un ataque con el objetivo de adivinar el password de alguno de nuestros usuarios SIP. Lo habitual al detectar el tráfico generado por éste tipo de ataques suele ser bloquear el acceso de la IP en cuestión. Pero eso no quiere decir que el atacante haya dejado de enviar paquetes. El atacante podría enviarnos tráfico desde distintas IPs de manera dinámica, lo que haría más complicado bloquearlo, aunque tampoco imposible.

Si «la mejor defensa es un buen ataque» aquí va una idea: extender el concepto de svcrash y crear una suite de anti-hacking para SIP. Las herramientas de ataque para SIP no suelen implementar un completo cliente SIP, básicamente se quieren enviar paquetes SIP por un socket rápido o con ciertas credenciales. Por lo tanto, podríamos suponer que la herramienta que nos ataque haya dejado algún caso sin contemplar en su parser y podríamos provocar una excepción en la aplicación con una respuesta especialmente preparada (tal y como hace svcrash). Aquí van unas cuantas ideas que se me ocurren a botepronto:

  • Que la respuesta empiece con «SIP/1.0 200 OK».
  • Utilizar unicode en las cabeceras From y To. (el soporte unicode es algo en lo que casi nunca se piensa desde el principio…)
  • Eliminar cabeceras de manera arbitraria: responder sin Contact, sin From ni To, …
  • …

Es solo una idea, pero sería interesante ver alguna herramienta que empiece a responder con alguna de las respuestas malvadas cuando detecte X intentos de autenticación fallidos, ¿no creéis?

Happy anti-hacking! 🙂

¿Desvelado el secreto de Skype?

Ayer por la noche la noticia recorría Internet como la pólvora: Skype puede haber sido hackeado haciendo ingeniería inversa su protocolo.

Skype lleva muchos años en el mercado y se conocen muchos detalles sobre su infraestructura: sigue un modelo P2P (al igual que el sistema de almacenamiento de Google o la tecnología Dynamo de Amazon). Los nodos de esta red P2P tienen distintos niveles, de manera que los más propensos a reenviar tráfico de otros usuarios (como universidades, donde abundan las IPs públicas) son promocionados a ‘supernodos’. Las versiones móviles de Skype, por el contrario, nunca podrán llegar a ser ssupernodos.

Aunque se utilice la tecnología P2P, Skype también tiene servidores: algo tendrá que haber para SkypeOut, y una especie de B2BUA para distribuir los mensajes entre las múltiples instancias de Skype abiertas para un mismo usuario.

El problema de todo esto es mantener la confianza: poner perros y alambradas para que nadie que no sea Skype entre en la red P2P, ya sea para bien o para mal. Tal vez para que la gente deje de intentarlo, Skyoe lanzó SkypeKit SDK, pero parece que no es suficiente para todos. 😉

Según éste post el algoritmo de expansión de keys Skype RC4 ha sido obtenido gracias a la ingeniería inversa. Todos los detalles serán publicados en el 27C3 en Berlin en diciembre.

¿Veremos un cliente de Eskhipe? ¿Será un hoax? No lo parece…

skype_logo.png

Soporte de IPv6 en Asterisk

Ya lo había comentado Kevin P. Fleming varios meses atrás y hoy me he desayunado con la noticia. Russell Bryant acaba de postear el soporte de IPv6 para Asterisk en reviewboard.

No es que todo el mundo el vaya a utilizar (aún falta para eso…) pero es algo que hay que soportar a día de hoy y que convertirá Asterisk en un buena herramienta para probar IPv6 en otras aplicaciones como clientes SIP.

Añadir soporte para IPv6 en una aplicación del tamaño de Asterisk no ha tenido que ser fácil, así que mi enhorabuena al equipo de Asterisk por haberlo conseguido. 🙂

ipv6

Happy IPV6ing!

PD: La imágen la he tomado prestada de aquí.

Deteniendo un SIP flood con OpenSIPS y el módulo pike

Esta semana mientras miraba algo en uno de nuestros servidores me di cuenta de que estábamos siendo «atacados» mediante SIP flooding. Lo pongo entre comillas porque no era un ataque suficientemente significativo como para que el servicio se viera afectado, así que decidí aprovechar la ocasión para experimentar un poco y encontrar la manera de evitar éste tipo de ataques.

Como he dicho el ataque no era gran cosa: un montón de REGISTER que ni siquiera intentaban averiguar passwords. El problema de éste tipo de ataques es que pueden dejar nuestro sistema fuera de combate si los recursos no se liberan demasiado rápido. Los descriptores de fichero asignados a un proceso no son ilimitados (aunque ulimit -n diga lo contrario) y si se acaban no podremos hacer casi nada. Por otro lado, si la aplicación que está sufriendo el ataque consume el 100% de la CPU también estaremos afectando a otros procesos del sistema.

En estos casos un IDS como Snort puede ayudarnos, pero ya que se trata de OpenSIPS vamos a utilizar el módulo pike ya que viene incluido y así no necesitamos añadir un elemento más a nuestra infraestructura.

El módulo pike no bloquea el ataque de por si. Es capaz de detectarlo y de darnos las herramientas necesarias para actuar ente un ataque. Podéis ver toda la documentación del módulo, yo aquí comentaré los parámetros más relevantes:

  • sampling_time_unit: Indica el número de segundos que componen una muestra. A priori puede parecer algo abstracto, cobra sentido en combinación con el siguiente parámetro.
  • reqs_density_per_unit: Indica el número de mensajes permitidos en un sampling_time_unit, de manera que al sobrepasar éste número se ‘bloqueará’ la IP que esté originando el tráfico.
  • remove_latency: Indica el tiempo que tendremos una IP marcada como ‘bloqueada’.

Todas las unidades de tiempo se indican en segundos.

Una vez tenemos el módulo configurado vamos a utilizar la función pike_check_req() para detectar el flooding y actuar en consecuencia. Un ejemplo con un poco de pseudocódigo:

modparam("pike", "sampling_time_unit", 2)
modparam("pike", "reqs_density_per_unit", 30)
modparam("pike", "remove_latency", 120)
...
...
if (!(FROM_SELF || FROM_TRUSTED)) {
if (!pike_check_req()) {
exit;
}
}
...
...

Como se puede ver lo que haremos al detectar el flood es llamar a la función exit, para dejar de procesar los requests y liberar los recursos lo antes posible.

Alguno ya se habrá dado cuenta de que en realidad no estamos deteniendo el ataque… veamos como se podría hacer 🙂

El módulo pike nos generará unas bonitas entradas en syslog:

Jun 14 11:32:39 node03 /usr/sbin/opensips[12654]: PIKE - BLOCKing ip 1.2.3.4, node=0xaf793a68
Jun 14 14:15:43 node03 /usr/sbin/opensips[12659]: PIKE - UNBLOCKing node 0xaf793a68
Jun 14 14:15:45 node03 /usr/sbin/opensips[12623]: PIKE - BLOCKing ip 1.2.3.4, node=0xaf793axx
Jun 14 14:34:25 node03 /usr/sbin/opensips[12659]: PIKE - UNBLOCKing node 0xaf793axx
Jun 14 14:34:27 node03 /usr/sbin/opensips[12646]: PIKE - BLOCKing ip 1.2.3.4, node=0xaf793axx
Jun 14 15:35:39 node03 /usr/sbin/opensips[12659]: PIKE - UNBLOCKing node 0xaf793axx

Todo lo que tendremos que hacer es detectar estos mensajes con Rsyslog (por ejemplo) y añadir temporalmente una regla de iptables para bloquear el tráfico.

Ala, ya tenéis deberes 😉

4005407576_a1e671452d_m