Diferencia entre revisiones de «Seguridad»

De Asterisk Wiki
Ir a la navegación Ir a la búsqueda
Línea 200: Línea 200:
 
{{Archivo|./clave_md5|#! /bin/bash<br>
 
{{Archivo|./clave_md5|#! /bin/bash<br>
 
# Podemos cambiar el REALM si es diferente al usado por defecto "asterisk"<br>
 
# Podemos cambiar el REALM si es diferente al usado por defecto "asterisk"<br>
REALM=":asterisk:"<br>
+
REALM&#61;":asterisk:"<br>
 
echo -n $1$REALM$2 | md5sum<br>}}
 
echo -n $1$REALM$2 | md5sum<br>}}
  

Revisión del 23:25 10 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


Archivo: ./clave_md5
#! /bin/bash
  1. Podemos cambiar el REALM si es diferente al usado por defecto "asterisk"

REALM=":asterisk:"

echo -n $1$REALM$2


# ./clave_md5 100 1234
b0c8e1299774ca91800bb972b9f1b1c5 -


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

Véase también

Instalación

Enlaces Externos