Seguridad

De Asterisk Wiki
Saltar a: navegación, buscar

Como suele darse en la mayor parte de los sistemas, la seguridad es fundamental, y en gran parte de los casos, obviada.

Solemos establecer varios niveles de seguridad en función de la "exposición" a la máquina a los posibles transgresores que pudieran surgir sobre el contexto. No es lo mismo tener una máquina que funciona a nivel local, sin conexión de red, que una máquina con plena exposición a Internet. En términos generales, hemos de seguir una serie de directrices dentro de un marco común de seguridad empezando desde lo mas básico, y es lo que vamos a cubrir a continuación.

Aspectos Generales

Por regla general establecemos dos enfoques a la seguridad de un sistema:

  • Creación durante la construcción del sistema, que suele darse en usuarios expertos que conocen todos los aspectos del mismo, y pueden permitirse realizarla de forma procedimental.
  • Auditoría en producción, clásico de sistemas creados por manos inexpertas, y que suele darse a posteriori, con un análisis general del sistema.

Eventualmente, es altamente recomendable, seguir el primer enfoque, dado que establece las bases fuertes desde el primer abordaje, pero eventualmente, podriamos diseñar un "Check List" aplicable en gran medida a todas las maquinas, y divido por niveles en función de la seguridad que requiramos aplicar.

Sabemos que los sistemas evolucionan de forma permanente, y surgen nuevas fallas que afectan directamente a nuestros sistemas en mayor o menor medida. Para todo profesional que mantenga sistemas en producción es imprescindible que se encuentre actualizado tanto a nivel informativo, como todos sus sistemas en producción en curso. Para ello Asterisk mantiene un medio común en el que va informando de todas las contribuciones al sistema, a traves de una lista de Correo mantenida por Digium:

Lista de Correo Asterisk Dev

Para estar al tanto de todas las incidencias, bugs, y actualizaciones de versión es posible hacerlo a través del Issue Tracker basado en Attlasian JIRA de la comunidad Asterisk

Seguimiento de Incidencias de Asterisk

Asterisk Certified

Versionado de Asterisk 2011-2012

Siguiendo el la linea de actualizaciones del sistema, a finales de abril 2012, Digium liberó su versión Asterisk Business Edition [1] convirtiéndola en una versión libre, en la que se aplicaban todos los parches de seguridad, y se focalizaba especialmente para forjarla especialmente robusta.

Aunque sea popular la creencia, que el software libre no tiene ningún soporte técnico detrás, es más realista pensar que de hecho el soporte es aun más riguroso y sofisticado que el soporte técnico ofrecido por software privativo, dado que se ofrece a dos niveles, el que aporta la comunidad en la linea diaria de desarrollo de forma relativamente altruista, ya que por regla general suelen ser profesionales que hacen uso y disfrute de la aplicación dentro de su sector, y por otro lado, el que ofrece la(s) empresa(s) colaboradora(s).

Yendo mas allá, en el caso de Asterisk Business Edition, Digium, ofrecería Acuerdos económicos en el Nivel de Servicio (SLA) bastante interesantes para los distribuidores de la solución Asterisk, y ahora darían paso el mismo tipo de acuerdos, a través de esta nueva versión Asterisk Certified, de la cual adicionalmente, pudieran aprovecharse el resto de las empresas que no pudieran o quisieran invertir en este camino.

La estructura de versionado y "certificación" de Asterisk Certified es relativamente sencilla. Siguiendo la linea estándar, Asterisk sufre unas 12-15 modificaciones a nivel de versionado principal durante un año. Digium se centrará en 3 o 4 de estas versiones para convertirlas en "versiones certificadas" con soporte a largo plazo. Dentro de estas versiones certificadas, se establecería a su vez, otro subsistema de versionado en el que se irían unicamente corrigiendo las posibles fallas, pero no se avanzaría a nivel de desarrollo dado que este suele ser el principal motivo que da lugar a nuevas fallas al aparecer nueva funcionalidad sin suficientes mecanismos de prueba y análisis por cuestiones principalmente de recursos y tiempo como es común en cualquier proyecto de Ingeniería del Software. [2]

Niveles de Seguridad

En Asterisk establecemos varios niveles de seguridad, gran parte de ellos, los tres primeros, comunes a la mayoría de los sistemas informáticos y los tres últimos exclusivamente dedicados al tema que nos atañe.

  • El nivel físico, donde se establecen las políticas de seguridad para el acceso a la máquina
  • El nivel del sistema operativo, y todo lo específicamente relacionado al mismo y a su entorno incluyendo aplicaciones de uso concreto en el mismo y de administración
  • El nivel de red e Internet, aquí englobando todas las políticas de seguridad que impidan el acceso desde fuera a través de estos medios.
  • El nivel general del sistema Asterisk.
  • El nivel de script, y mas concretamente del Plan de Marcación
  • Paralelamente, el nivel de protocolo de comunicación, aquí englobando todo lo relacionado a SIP e IAX como los dos más comúnmente extendidos.

Los tres primeros niveles, son propios de un Administrador de Sistemas, que tenga un buen control y manejo de su infraestructura de red, incluyendo los cortafuegos, Routers, etc, y por otro lado, un buen manejo del sistema operativo, en este caso Linux y todas sus políticas que suponen un grado de fiabilidad, inclusive la elección de la distribución, y la versión de la misma.

Los dos siguientes, son más específicos de Linux, y son los que se verán tratados más en profundidad a continuación.

Nivel general Asterisk

Aquí veremos todos los aspectos que cubren el nivel de seguridad de Asterisk desde el momento de la instalación hasta la puesta en marcha en el proceso de producción.

Instalación

Según visto en el apartado de Instalación es muy importante que Asterisk no tenga acceso al sistema como Superusuario del sistema. No podría concretar si esto realmente afecta a nivel de Sistema Operativo, pero dado que se establece posterior a la instalación del sistema Asterisk creo que encajaría mejor aquí.

En caso de que se acometa una intrusión en nuestro sistema Asterisk, es importante que el acceso quede limitado exclusivamente a lo que Asterisk pueda ofrecernos y no interfiera en general dentro del sistema Operativo. La mayor parte de las instalaciones por defecto de Asterisk, han de hacerse dentro del contexto de superusuario de Linux, dado que es necesario escribir dentro de determinados directorios exclusivos de este usuario. Ademas por defecto Asterisk configura dentro del archivo principal asterisk.conf el proceso de Asterisk para que sea ejecutado por el superusuario del sistema.

Para limitar toda esta funcionalidad a un usuario con propiedades extralimitadas al entorno de Asterisk sería fundamental seguir dos pasos.

En primer lugar cree un script muy sencillo para que los directorios principales de asterisk pasasen al control de nuestro usuario limitado a voluntad:

Archivo: ~/permisos_asterisk
#!/bin/bash
# Uso: ./permisos_asterisk usuario grupo
sudo chown -R $1:$2 /usr/lib/asterisk/
sudo chown -R $1:$2 /var/lib/asterisk/
sudo chown -R $1:$2 /var/spool/asterisk/
sudo chown -R $1:$2 /var/log/asterisk/
sudo chown -R $1:$2 /var/run/asterisk
sudo chown $1:$2 /usr/sbin/asterisk
sudo chown $1:$2 /etc/asterisk/


En segundo lugar, es fundamental configurar asterisk.conf para que pueda ejecutar el demonio principal de asterisk como usuario limitado (soponiendo que el usuario y el grupo elegidos son asterisk para los dos casos).

Archivo: /etc/asterisk/asterisk.conf
runuser=asterisk
rungroup=asterisk


Carga y Descarga de Módulos

Otra parte muy importante a considerar para preservar la seguridad del sistema, es ser muy selectivos a la hora de elegir que módulos van a funcionar con nuestro sistema Asterisk, ya que como sabemos, son totalmente independientes del núcleo principal, ampliamente explicado en el apartado de Arquitectura. De esta forma, al ser tan autónomos, cada modulo posee sus fallos de seguridad de forma exclusiva, pero de alguna forma u otra, podrían comprometer al sistema Asterisk en general, ya que no existen realmente mecanismos de aislamiento entre los mismos. En este sentido la única forma de tener esto bien atado, es tener controlados los módulos que deseamos cargar en función de las necesidades especificas de cada instalación, por muy engorroso que pueda ser esto.

Adicionalmente hay que considerar que en la actualidad existen muchos módulos cerca de la desaparición, o módulos para algo demasiado especifico que seguramente jamas utilicemos, por eso merece bastante la pena revisar modulo por modulo su utilidad, y plantearnos su descarte en caso que no vaya a cumplir ningún cometido en la mayor parte de nuestras instalaciones.

Todos los módulos disponibles, son aquellos que seleccionamos durante la compilación (con la orden del Makefile, "menuselect"). Al instalar, todos esos modulos compilados, van a parar al directorio por defecto, /usr/lib/asterisk/modules/ y ya de ahí depende su tratamiento dentro del archivo de configuración /etc/asterisk/modules.conf

Existen tres enfoques concretos para gestionar este concepto:

Carga General y Descarga Selectiva

Por un lado podemos plantear cargar todos los modulos por defecto ya compilados y ubicados en el directorio de módulos en el fichero de configuración de los módulos, y luego descargarlos individualmente a voluntad.

Un ejemplo ilustrativo y posible [3]:

Archivo: /etc/asterisk/modules.conf
[modules]

autoload=yes
; Resource modules
noload => res_speech.so
noload => res_phoneprov.so
noload => res_ael_share.so
noload => res_clialiases.so
noload => res_adsi.so

; PBX modules
noload => pbx_ael.so
noload => pbx_dundi.so

; Channel modules
noload => chan_oss.so
noload => chan_mgcp.so
noload => chan_skinny.so
noload => chan_phone.so
noload => chan_agent.so
noload => chan_unistim.so
noload => chan_alsa.so

; Application modules
noload => app_nbscat.so
noload => app_amd.so
noload => app_minivm.so
noload => app_zapateller.so
noload => app_ices.so
noload => app_sendtext.so
noload => app_speech_utils.so
noload => app_mp3.so
noload => app_flash.so
noload => app_getcpeid.so
noload => app_setcallerid.so
noload => app_adsiprog.so
noload => app_forkcdr.so
noload => app_sms.so
noload => app_morsecode.so
noload => app_followme.so
noload => app_url.so
noload => app_alarmreceiver.so
noload => app_disa.so
noload => app_dahdiras.so
noload => app_senddtmf.so
noload => app_sayunixtime.so
noload => app_test.so
noload => app_externalivr.so
noload => app_image.so
noload => app_dictate.so
noload => app_festival.so


Carga Selectiva

Este enfoque podría ser el más engorroso, ya que por regla general, solemos necesitar cargar más módulos que desearíamos descargar, aunque de alguna forma, nos daría una visión bastante general de como funciona Asterisk ya que al no conseguir que algo funcione puede darse el caso que sea por falta de un modulo en concreto. Creo que es un tipo de método de análisis que todo gran experto en Asterisk que se precie, debería pasar al menos una vez.

Archivo: /etc/asterisk/modules.conf
[modules]

; Precargamos modulos recurso para interconectar con ODBC
preload => res_odbc.so
preload => res_config_odbc.so

; Cargamos el modulo recurso relacionado a la Musica en Espera
load => res_musiconhold.so

; Cargamos el modulo de driver del canal Dahdi para trabajar con tarjetas Digium, con require si no carga por algun motivo Asterisk no arrancaría
require => chan_dahdi.so


Carga basada en la Instalación

Este método es el más limpio hasta cierto punto, y el mas eficaz a nivel de recursos del sistema, ya que el planteamiento reside en el hecho de compilar el número justo de módulos durante la compilación/instalación general de Asterisk a través de la opción menuselect del Makefile del paquete Asterisk. Una vez hecha la selección exhaustiva procedemos a compilar y todos los módulos seleccionados irían a parar al directorio por defecto /usr/lib/asterisk/modules/. A partir de ahí con el fichero de configuración más sencillo posible tendríamos una carga exacta de los módulos que hayamos elegido a voluntad.

Archivo: /etc/asterisk/modules.conf
[modules]
autoload=yes


Asterisk Manager Interface

Si consideramos que Asterisk puede ser más seguro o inseguro en función de su "eslabón" más débil, podríamos considerar en este caso, el AMI como este. Tener acceso a este interfaz supone un grado de libertad que podría considerarse tanto, como tener acceso a través del servidor SSH, o estar físicamente presente delante del mismo.

Y yendo más allá, por defecto, la comunicación que se establece con AMI es a través de mensajes en texto plano, aunque esto podemos evitarlo, estamos considerando que es poco menos seguro que una comunicación clásica a través de TELNET. Por ello si vamos a utilizar AMI, y mucho más, si estamos forzados a dar acceso al mismo a través de Internet, es importante tener en cuenta algunas consideraciones.

Pero en términos generales, desaconsejamos fehacientemente abrir el acceso al Mánager a través de Internet, dado que solo un pequeño fallo en la seguridad nos dejaría totalmente expuestos y hay que considerar que la comunidad de personas que hay detrás de AMI es considerablemente inferior, a la de otras puertas de acceso como el servidor SSH, el cual recibe parches para evitar fallos en la seguridad muy regularmente.

Vamos a suponer un caso: Tenemos una aplicación en entorno Web para dar servicio nuestros empleados, que ademas tiene la posibilidad de conectar con AMI para integrar servicios de telefonía. En este caso, sería más conveniente, montar dicha aplicación en un servidor web interno dentro de nuestra organización, y dar acceso a AMI a través de la red local, y abrir el servidor Web al exterior, que montar el servidor web en el exterior, y abrir AMI para que conecte el mismo a nuestra maquina Asterisk. Considerad esta recomendación como una de las más importantes a tomar entre todos los niveles de Seguridad de Asterisk.

Aún así, dentro del fichero de configuración del manager (/etc/asterisk/manager.conf), podemos definir algunos parámetros específicos, para conseguir por lo menos una comunicación con mensajes encriptados, pero en contrapartida, todas las aplicaciones que utilicen el AMI, necesitarán poder soportar este tipo de encriptación de alguna forma lo que podría suponer una lacra, en el posible soporte, aunque tenemos múltiples alternativas como podemos ver a continuación:

  • tlsenable: Permitimos la encriptación TLS, además para el funcionamiento el parámetro enable de AMI también ha de estar activado.
  • tlsbindaddr: Si queremos que haya una dirección IP especifica a la que queramos que apunte, y un puerto para la comunicación TLS. Por defecto sería 0.0.0.0:5039
  • tlscertfile: La ruta al certificado PEM.
  • tlsprivate: La ruta si tenemos una clave privada PEM, en caso que no, AMI buscará el certificado puesto en el anterior parámetro
  • tlscipher: Una cadena de texto de cifrado especifico siguiendo estandares OpenSSL[4]
  • tlscadir': La ruta si tenemos certificados en un almacen CA.

Además con los parámetros específicos de los pares para permitir y denegar redes, podríamos especificar una dirección o un rango específico de direcciones para limitar los accesos al mismo, lo que aportaría un nivel adicional de seguridad.

Nivel de Protocolo

SIP

La mayoría de las caracteristicas de seguridad basadas en el protocolo SIP se establecen a nivel de configuración dentro del archivo correspondiente sip.conf (/etc/asterisk/sip.conf). Hay una serie de parámetros críticos que son los que establecen la mayor seguridad en las comunicaciones. Es bastante importante tener todo bien atado y no dejar a libre albedrío las conexiones entrantes por este protocolo ya que justamente este es sistema más clásico para acceder a nuestras máquinas mal intencionadamente.

Parámetro Insecure

Existe este parámetro utilizado para los pares/dispositivos que conectan a nuestra máquina Asterisk y define el tipo de comprobación que se establece durante la comunicación con el mismo. Por defecto este parámetro se encuentra en la forma mas restrictiva: insecure = no que sería equivalente a que el máximo de comprobaciones posibles se realicen.

Las dos existentes en la actualidad:

  • port : En este caso se permite que un par se conecte a nuestra máquina siempre que la dirección IP coincida, aunque el puerto no coincida.
  • invite : No pide autentificación de los mensajes tipo INVITE que van entrando. Con la autentificación inicial es suficiente
  • port,invite : La combinación es el mínimo de seguridad y de chequeo ya que no comprueba ni el puerto, ni la autentificación en los mensajes tipo INVITE.

Eventualmente, lo ideal sería poder trabajar con los pares, sin tocar este parámetro que por defecto se considera máxima protección. Pero en instalaciones Asterisk en las prima el tiempo, el acceso será muy limitado, seguramente a nivel local y se busca un despliegue en tiempo récord, es muy común ver insecure = port,invite ya que las conexiones de los dispositivos con nuestra máquina se realizan con relativa facilidad y podemos continuar con el siguiente proceso de implantación.

Parámetro Directmedia

Antiguamente este parámetro se llamaba CanReinvite. Como vimos en la sección correspondiente de SIP, servía para poder establecer una conexión entre dos pares, sin tener que pasar los medios de audio que van por RTP a través de nuestro servidor Asterisk.

El problema de seguridad que entraña es relativamente limitado. Según visto en el articulo SIP en combinación con RTP es un protocolo relativamente inseguro, dado que los mensajes van en formato texto sencillo (con lo cual si las contraseñas no van cifradas por ejemplo, nos las podrían extraer en cuestión de segundos), pero el stream a través de RTP tampoco va cifrado, por lo que podríamos interferir los paquetes de audio y decodificarlos para "escuchar" la linea de forma poco ortodoxa.

Para que DirectMedia se de es necesario cumplir varios condicionantes, como la utilización de mismos codecs, que ambos pares tengan la opción directmedia activada, etc... pero en el caso que todo se cumpliera, surgiría un riesgo que a lo mejor, para nosotros resulta imprevisto, el hecho que se comuniquen directamente (e incluso, involuntariamente) sin pasar por la máquina Asterisk. Y si por ejemplo, nuestra máquina Asterisk se encarga, no solo de cuestiones de Grabación de llamada, sino de encriptación de los medios RTP (SRTP), para esta comunicación concreta, no se daría esta posibilidad, suponiendo un riesgo incontrolado y/o indebido.

Parámetros Permit/Deny

Podría llegar a ser importante que tengamos claro que redes deberían de poder conectar exclusivamente a nuestro servidor Asterisk. Si queremos extralimitar para un tipo de dispositivo la conexión desde fuera, con estos parámetros podríamos elegir exactamente desde que redes podrían acceder.

Supongamos que en nuestro servidor Asterisk tenemos acceso a varios operadores, y la máquina abierta a Internet. Al conectar un dispositivo desde Internet, técnicamente tenemos acceso a todos los dispositivos siempre y cuando en el Plan de Marcación exista un acceso a los mismos. Pero si existe un par al cual no queremos ni aun con acceso desde el diaplan, que el dispositivo que entra desde Internet tenga acceso, podríamos limitárselo especificando exactamente desde que red se puede conectar al mismo.

Así a priori puede resultar un caso demasiado hipotético, pero conforme vamos ampliando el sistema, suele ser mas conveniente tenerlo bastante cerrado desde el principio y que sea la necesidad concreta la que fuerce el hecho de abrirlo, que no lo contrario.

Parámetro MD5secret

Como resulta lógico, a la hora de autentificarse contra nuestra máquina Asterisk, utilizando mensajes SIP, lo ideal sería utilizar una contraseña en formato MD5. Tampoco es el apogeo, dado que utilizando esa misma cadena podría un tercero autentificarse de forma poco adecuada, pero eventualmente no expondríamos el sistema de contraseñas que quizá estemos utilizando recurrentemente para otros apartados de nuestro sistema.

Para crear un md5hash para la contraseña que deseemos ponerle a nuestro usuario con este sencillo script hacemos el truco:

# touch clave_md5 && chmod +x clave_md5


Podemos cambiar variable REALM si es diferente al usado por defecto "asterisk"

Archivo: ./clave_md5
#! /bin/bash

REALM=":asterisk:"

echo -n $1$REALM$2


# ./clave_md5 100 1234
b0c8e1299774ca91800bb972b9f1b1c5 -


IAX

La mayoría de las caracteristicas de seguridad basadas en el protocolo IAX se establecen a nivel de configuración dentro del archivo correspondiente iax.conf (/etc/asterisk/iax.conf). Hay una serie de parámetros críticos que son los que establecen la mayor seguridad en las comunicaciones. Al igual que en otros protocolos es importante tenerlo bien atado y considerar determinados parametros que pueden resultar más fundamentales a la hora de restringir las posibilidades de intrusión.

Parámetro Encryption

Este sencillo parámetro es el que establece la encriptación de las comunicaciones entre dos dispositivos que operen a través del protocolo IAX.

Puede tomar dos valores, que de momento son exactamente iguales, yes o aes128 (que justamente es el tipo de encriptación que utiliza, Rijndael, también AES de 128 bits [5]).

Hay que considerar varios aspectos sobre la seguridad especifica. Los números inicialmente marcados no van encriptados, pero en cambio los tonos DTMF si van encriptados (muy útil cuando trabajamos con sistemas IVR en los cuales puede existir la posibilidad que nuestro usuario marque determinados números secretos como su código PIN para una transacción bancaria). Si necesitamos que el número inicialmente marcado sea oculto, esto podríamos hacerlo desviando el trafico a cualquier extensión interna, y que esta realice la marcación del mismo como si fueran tonos DTMF.

Por otro lado, una de las últimas implementaciones de Asterisk aseguran el hecho que la clave secreta, vaya rotando eventualmente para aumentar la seguridad general del sistema. Antiguamente esta funcionalidad se podría eliminar con un parámetro especifico del iax.conf (keyrotate), pero en la actualidad este parámetro ha sido desechado, ya que el sistema identifica automaticamente, si el otro sistema que trabaja con el protocolo IAX, no es capaz de controlar estas rotaciones, así que de alguna forma por defecto, los sistemas Asterisk en la actualidad (versiones 1.6.1 en adelante) ya incorporan esta "retrocompatibilidad".

Parámetro Transfer

Parecido al parámetro Directmedia de SIP, este parámetro permite la posibilidad de emitir comunicaciones IAX entre dos terminales sin pasar por nuestra máquina Asterisk.

En este sentido los aspectos de inseguridad que aparecen, son parecidos al otro parametro que comentabamos, con el añadido, de no poder poseer de los aspectos adicionales que aportaría la máquina Asterisk al no pasar a traves de la misma, como el sistema de Autentificación y Encriptación (a no ser que los dos terminales negocien el mismo y lo dispongan por defecto).

Los posibles valores que puede tomar son:

  • yes: Los dos terminales se comunican directamente
  • mediaonly: En este caso, se deshabilitan las funciones de trunking por defecto, y los medios pasan directamente entre los dos terminales, pero se conservan las capacidades de señalización a través de nuestra Máquina Asterisk
  • no: Es la opción por defecto, y más común sobre todo si hablamos de comunicaciones de voz.

Parámetro DBSecret

Este parámetro sirve para almacenar las contraseñas de los pares en la base de datos AstDB (Asterisk Database). Eventualmente establece otro nivel de seguridad adicional, que de alguna forma paralelamente MD5Secret ya ofrece (el hecho de no tener las contraseñas de los pares en un fichero de texto plano).

Seguridad Relativa al Call Token y al número de llamadas Concurrentes

A continuación existen los siguientes parámetros que concretan este aspecto de seguridad tal y como definimos como debilidad en el apartado IAX:

  • requirecalltoken: Este parámetro puede tomar tres posibilidades, en caso que elijamos "yes", forzamos a que las dos máquinas se intercomuniquen forzadamente utilizando Call Tokens. En caso que elijamos "no", dejamos esta posibilidad de autentificación como algo opcional. Tenemos la tercera opción "auto", en la cual, por defecto no es necesario obligatoriamente que se utilicen los Token, hasta el momento que un par si lo utilice, momento que sentaría de precedente, y a partir de ahí sería forzado su uso.
  • calltokenoptional: Podemos seleccionar un host (con su mascara) concreto para el cual, el Call Token sería de carácter opcional. Ejemplo: 192.168.1.200/255.255.255.0
  • maxcallnumbers: Limita el número de llamadas concurrentes para un Peer concreto, aquí especificamos el número de llamadas concurrentes que permitimos.
  • maxcallnumbers_nonvalidated: En caso que estemos trabajando con la posibilidad de accesos sin autorización (invitados por ejemplo), aquí especificamos el numero de llamadas global que estos invitados tienen permitido hacer simultánea y concurrentemente (no se aplicaría individualmente a cada peer).

Además existe un contexto especifico del fichero iax.conf llamado [callnumberlimits] en el cual podemos especificar determinados hosts con sus mascaras de red, detallando el número de llamdas concurrentes que son capaces de realizar concretamente. Podemos ver un pequeño ejemplo a continuación:

Archivo: /etc/asterisk/iax.conf
[callnumberlimits]
192.168.1.200/255.255.255.0 = 20
192.168.1.201/255.255.255.0 = 30


Parámetros parecidos a SIP

Existe una serie de parámetros que no son específicos de IAX y que a nivel de seguridad comparten los mismos elementos que el protocolo SIP como son:

  • permit/deny
  • md5secret

Encriptando la Comunicación con RSA

Por defecto, la instalación de Asterisk suele traer un script llamado astgenkey [6] dentro del directorio donde descomprimimos nuestro sistema Asteirsk, en el subdirectorio ./contrib/scripts/. Si lo ejecutamos (hay que darle permisos de ejecución):

# chmod +x ./astgenkey -n


Nos pedirá el nombre del fichero para las claves, y nos generaría dos ficheros con el nombre dado y con las extensiones .pub y .key.

Ahora, para cargar las claves dentro de nuestro sistema Asterisk en primer lugar las copiamos al directorio de claves:

# cp nombre_clave_generada.* /var/lib/asterisk/keys/


Ahora desde la CLI, necesitamos cargar esas claves en nuestro sistema Asterisk:

CLI> module reload res_crypto.so


Y podemos ver si estan cargadas con el comando:

CLI> keys show


Este procedimiento lo seguimos igual cada vez que generemos nuevas claves, o carguemos nuevas claves públicas de servidores remotos.

Por otro lado queda la configuración de IAX, existen una serie de parámetros específicos para los pares para este propósito, dentro del fichero de configuración iax.conf:

  • auth=rsa: Es fundamental poner esto en los pares, para especificar que la autentificación la vamos con una clave RSA generada por nosotros
  • inkeys: Aquí podemos poner los nombres (sin extensión .pub) de todas las claves publicas que vamos a utilizar para autentificarnos, suele ponerse este parametro en los tipo friend, y user, ya que supone un parametro que orienta sobre que clave publica se va a realizar la autentificación por parte de los pares llamantes. Cada nombre de clave se separa mediante el caracter :
  • inkey: Una variante, para especificar solo una clave.
  • outkey: Aquí se especifica el nombre de la clave privada (sin extensión .key) con la que vamos a realizar la autentificación.

El uso del tipo de autentificación RSA junto a los nombres de las claves sustituye el uso del parametro secret para especificar una contraseña en concreta.

Podríamos prescindir de un posible par de tipo "peer" en el caso que queramos enviar llamadas salientes utilizando el protocolo IAX, utilizando directamente la autentificación en la Aplicación Dial. Para ello la sintaxis sería la siguiente:

  • Dial(IAX2/<nombre_de_usuario_del_peer>:[<nombre_clave_publica>]@<host_destino>/<extension>@<contexto>)

En los parámetros generales es importante especificar que vamos a utilizar una comunicación cifrada gracias al parametro encryption=yes. Es importante considerar que no debemos forzar la encriptación dado que ya se establece por defecto, es una peculiaridad de este sistema, por ello debemos especificar el parámetro general forceencryption=no

Otros Modos de Encriptación Seguros

Según hemos visto, una de las grandes bondades de IAX es la grandísima sencillez, con la que podemos establecer una comunicación cifrada con solo especificar un parámetro encryption=yes. Además con el parámetro forceencryption=yes forzamos la obligatoriedad que el otro par también este dispuesto a recibir y enviar esta comunicación del mismo modo.

Por último tenemos la posibilidad de establecer como sistema de autentificación, un checksum md5 en nuestra contraseña de cada par, lo que sumaríamos aún mas seguridad al sistema.

Base de Datos de Contraseñas

Esto es algo que de momento solo esta disponible para IAX, pero sera extrapolable próximamente para otros protocolos como SIP. Podemos mantener todo el sistema de contraseñas dentro de Asterisk Database.

Gracias al parámetro para los pares dbsecret podemos especificar en que clave de que familia se encuentra el valor de la contraseña que buscamos (Considerar que AstDB es un tipo de Base de Datos basado en [Berkeley DB].

Referencias

  1. Artículo SinoLogic sobre Asterisk Cert, Elio Rojano (Mayo 2012)
  2. Artículo Blog Digium sobre Asterisk Cert, Malcom Davenport (Abril 2012)
  3. Fichero de Configuración de Modulos de Ejemplo, Asterisk: The Definitive Guide
  4. Cadenas de Texto de Cifrado, The OpenSSL Project
  5. Borrador 3 del RFC de IAX, Apartado 7.2 Encriptación, M. Spencer (2007)
  6. IAX RSA Auth, Olle E. Johansson (2003)

Véase también

Instalación

Enlaces Externos