Diferencia entre revisiones de «Seguridad»

De Asterisk Wiki
Ir a la navegación Ir a la búsqueda
Línea 257: Línea 257:
 
* '''permit/deny'''
 
* '''permit/deny'''
 
* '''md5secret'''
 
* '''md5secret'''
 +
 +
==== Encriptando la Comunicación con RSA ====
 +
 +
Por defecto, la instalación de Asterisk suele traer un script llamado '''astgenkey''' <ref>[http://www.voip-info.org/wiki/view/Asterisk+iax+rsa+auth IAX RSA Auth], Olle E. Johansson (2003)</ref> dentro del directorio donde descomprimimos nuestro sistema Asteirsk, en el subdirectorio '''./contrib/scripts/'''. Si lo ejecutamos (hay que darle permisos de ejecución):
 +
 +
{{Comando|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:
 +
 +
{{Comando|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.
  
 
== Referencias ==
 
== Referencias ==

Revisión del 13:51 23 may 2012

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.

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


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 [4]).

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 [5] 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.

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. Borrador 3 del RFC de IAX, Apartado 7.2 Encriptación, M. Spencer (2007)
  5. IAX RSA Auth, Olle E. Johansson (2003)

Véase también

Instalación

Enlaces Externos