En esta ocasión les comparto un excelente post de Blog-vozip.
Volvemos a la carga con un pequeño post sobre como configurar otra de las nuevas features que nos trae Asterisk 1.8: TLS y SRTP, audio (y video) cifrado y seguro.
Estos tests se han realizado con terminales Cisco SPA5XX, que supone tener que aplicar un pequeño parche en el código de Asterisk (luego veremos el porque), pero funciona exactamente igual para terminales Snom y softphones como Blink
La parte de configuración se explicará bastante rápido, ya que está explicado en varios sitios en la web.
Empezamos:
1. Es necesario compilar la librería libSRTP para que Asterisk tenga el soporte SRTP.
wget http://srtp.sourceforge.net/srtp-1.4.2.tgz
tar zxvf srtp-1.4.2.tgz
cd srtp/
CFLAGS="-Wall -O4 -fexpensive-optimizations -funroll-loops -fPIC" ./configure
make && make install
2. Descargamos y Compilamos Asterisk: (Para este Post se utiliza la versión 1.8.2.3)
svn co http://svn.asterisk.org/svn/asterisk/tags/1.8.2.3/ asterisk18
cd asterisk18
./configure
make menuselect (nos aseguramos de que esté res_srtp activado en 'Resource Modules')
**Ahora es cuando tenemos que aplicar el parche anteriormente mencionado**
¿Porque? Es necesario parchear el código porque los terminales SPA5xx envían dos líneas con el atributo crypto, tal que:
a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:Ud154Hz42jLai6YI7RBcKtctTHBzIKjiHM6nGD36.
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:Ud154Hz42jLai6YI7RBcKtctTHBzIKjiHM6nGD36.
y Asterisk no es capaz de negociar cual de los métodos (AES_32 o AES_80) se va a utilizar para la encriptación. De hecho, sólo escoge el primero y como podéis ver, los Cisco envían primero el AES_32.
Aquí está el problema. Asterisk es capaz de manejar ambos tipos, pero sólo ofrece uno de ellos, el AES_80. Por tanto, tenemos que parchear el código para que Asterisk ofrezca en la señalización encriptación AES_32. Si no, se cifrará el Audio en las dos patas con un tipo diferente y nos quedamos sin audio y con un mensaje eterno (30 por Seg.) en el CLI:
WARNING[25205]: res_srtp.c:338 ast_srtp_unprotect: SRTP unprotect: authentication failure
Más info al respecto en el Bugtracker de Digium
Un poco de SIP para ver “claro” el problema (primer INVITE e INVITE de Asterisk al destino):
INVITE sip:200@10.10.0.165 SIP/2.0.
From:
To: "200"
m=audio 16890 RTP/SAVP 8 0 9 18.
a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:hE+4XPMbPaF9/XEgIek7rUJiqoTEpLGZ1YXNiJhS.
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:hE+4XPMbPaF9/XEgIek7rUJiqoTEpLGZ1YXNiJhS.
INVITE sip:200@10.10.0.177:5063 SIP/2.0.
From: "100"
To:
Contact:
User-Agent: Asterisk PBX 1.8.2.3.
Remote-Party-ID: "100"
m=audio 12202 RTP/SAVP 8.
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:5uWtfxfK0vE90lTrgLTr83bRWTL2nCEFJ6NlXWjq.
El parche es bien simple:
--- channels/sip/sdp_crypto.c 2010-06-08 07:29:08.708826000 +0200
+++ channels/sip/sdp_crypto.c 2011-02-24 17:37:00.514711568 +0100
@@ -287,7 +287,8 @@
int sdp_crypto_offer(struct sdp_crypto *p)
{
char crypto_buf[128];
- const char *crypto_suite = "AES_CM_128_HMAC_SHA1_80"; /* Crypto offer */
+ //const char *crypto_suite = "AES_CM_128_HMAC_SHA1_80"; /* Crypto offer */
+ const char *crypto_suite = "AES_CM_128_HMAC_SHA1_32"; /* Crypto offer */
if (p->a_crypto) {
ast_free(p->a_crypto);
Aplicamos el parche (lo hemos nombrado como sdp_crypto.patch):
patch -p0 < sdp_crypto.patch (suponiendo que estamos en /usr/src/asterisk18 y tenemos el parche en la misma carpeta)
Asterisk is patched!!! 
Ya podemos compilar e instalar:
make && make install
3. Configuración (tanto para TLS como para SRTP)
**TLS**
-Primero nos generamos una clave pública y otra privada, las fusionamos en un único fichero y la guardamos en algún sitio conocido.
Hay formas mucho mejores y elegantes de hacerlo (léeme), pero esto sólo es para testing!
openssl genrsa 1024 > host.key
openssl req -new -x509 -nodes -sha1 -days 365 -key host.key > host.cert
cat host.cert host.key > asterisk.pem
mv asterisk.pem /etc/asterisk/keys/
-Configuramos sip.conf para poder utilizar TLS:
tlsenable=yes
tlsbindaddr=0.0.0.0
tlscertfile=/etc/asterisk/keys/asterisk.pem
-Configuramos los peers para que trabajen con TLS. Tanto en realtime como en raw en sip.conf hay que añadir:
transport=tls (por defecto es UDP)
-Configuramos nuestro SPA5XX para que utilice TLS:
Ya tenemos señalización segura entre Asterisk y los terminales!! ;P
Para asegurarnos capturamos en el puerto 5061 y no vemos “nada”:
....J...F..Mg|.L^
...E}.....A...d.|.~...... l..i9.j,..q"..............&./....5................0..~0...................0...*.H........0..1.0...U....ES1.0...U....Vizcaya1.0...U....Erandio1.0...U.
..Irontec1.0...U....VozIP1.0...U....Irontec1 0...*.H........vozip@irontec.com0...110215125446Z..210212125446Z0..1.0...U....ES1.0...U....Vizcaya1.0...U....Erandio1.0...U.
..Irontec1.0...U....VozIP1.0...U....Irontec1 0...*.H........vozip@irontec.com0..0...*.H............0........>.S.51...bND.J..Q..O.).-t.."~x..g&^t....E.*..@..n.jF...v.t.<....Zf...%Y.......[...[....HE.e....9..8...qc..|(...P.....*.c4>.V..........0..0...U.........En?.0.%.^......
.0....U.#...0.......En?.0.%.^......
.......0..1.0...U....ES1.0...U....Vizcaya1.0...U....Erandio1.0...U.
..Irontec1.0...U....VozIP1.0...U....Irontec1 0...*.H........vozip@irontec.com...........0...U....0....0...*.H............T.-F....R..2%.....T......=9.ye.z..6.0............i...O;.../s..e.........S.6.31......!iT......N....]........>XNt....Z...MHKH3...K.........
**SRTP**
-Para configurar SRTP tenemos que poner la directiva ‘encryption’ en los peers (ya sean realtime o en sip.conf)
encryption=yes
-En los SPA5XX hay que tocar 3 valores. Esto es configurable al menos, desde la versión 7.4.3 del firmware (OJO! que se aplica para todas las líneas configuradas):
+SRTP Method: s-descriptor
+Secure Call Serv: yes
+Secure Call Setting: yes
Voilá! Ya tenemos SRTP configurado!
DETALLE: No hay modo opcional de SRTP para Asterisk, es decir, si está encryption activado en el peer no aceptará audio no cifrado y al contrario. En los terminales en cambio, si está el cifrado configurado, pero no el peer como tal, las llamadas entrantes se establecerán sin problemas. No así, las salientes, porque el terminal hemos dicho que tenía SRTP activo y para Asterisk no. En los Snom se puede utilizar también el modo ‘Optional’ para el SRTP (envía dos atributos m=audio con y sin SRTP), pero Asterisk no sabe manejar estos SDP… :S
4. Pruebas
Para probar todo esto lo más fácil es capturar tráfico en la red y después verificar con WireShark, OmniPeek o cualquier otro software si vemos la señalización en claro y si podemos escuchar las conversaciones.
En los test realizados en nuestro lab, nos encontramos con un Warning (no siempre) en el CLI, pero en principio todo funciona como debe.
WARNING[25205]: res_srtp.c:338 ast_srtp_unprotect: SRTP unprotect: authentication failure
Estamos debuggeando este último punto para ver que puede estar provocándolo…
**Curiosidad**
Los CiscoSPA5XX cuando están con SRTP activado, reproducen una especie de “beep” tres veces al principio de la conversación y muestran en pantalla un $ como símbolo de conversación encriptada. Un ejemplo:
Al final ha quedado un post un tanto largo… pero bueno, esperemos que sirva a alguien! ;P
Fuente: Blog Voiz-IP
No hay comentarios.:
Publicar un comentario