38
1

Asegurando Elastix - Samuel Cornu.pdf

Embed Size (px)

Citation preview

Page 1: Asegurando Elastix - Samuel Cornu.pdf

1

Page 2: Asegurando Elastix - Samuel Cornu.pdf

2

Asegurando Elastix® Primera Edición – Agosto de 2011

Samuel Cornu

Page 3: Asegurando Elastix - Samuel Cornu.pdf

3

[PAGINA DEJADA INTENCIONALMENTE EN BLANCO]

Page 4: Asegurando Elastix - Samuel Cornu.pdf

4

Contenido

AGRADECIMIENTOS ........................................................................................................... 5

LICENCIAMIENTO .............................................................................................................. 5

INTRODUCCIÓN ................................................................................................................ 6

SERVICIOS ....................................................................................................................... 7

RUN LEVELS...................................................................................................................... 9

ASEGURANDO SSH ........................................................................................................... 12

Grupo Wheel ................................................................................................................ 12

Uso del sudo................................................................................................................. 14

FIREWALL ........................................................................................................................ 17

NETFILTER-IPTABLES ....................................................................................................... 17

ASEGURANDO HTTPS ........................................................................................................ 21

Fail2ban .......................................................................................................................... 24

Instalación y Configuración ............................................................................................ 24

fail2ban y SSH .............................................................................................................. 24

Fail2ban y Asterisk ....................................................................................................... 25

Fail2ban y apache2 ....................................................................................................... 26

PORTSENTRY ................................................................................................................... 28

Configuración ............................................................................................................... 28

Portsentry - Modo clásico ............................................................................................... 28

Portsentry - Modo avanzado ........................................................................................... 29

Portsentry - Otras opciones de configuración .................................................................... 29

CHKROOTKIT ................................................................................................................... 31

TCPWRAPPER ................................................................................................................... 32

PRÁCTICAS RECOMENDADAS ............................................................................................. 33

SIETE PASOS PARA MEJORAR LA SEGURIDAD SIP EN ASTERISK PUBLICADOS POR DIGIUM .... 34

Backdoor en FreePBX .................................................................................................... 35

NOTAS FINALES ............................................................................................................... 37

FUENTES ......................................................................................................................... 38

Page 5: Asegurando Elastix - Samuel Cornu.pdf

5

AGRADECIMIENTOS

Principalmente quiero agradecer a mi familia (esposa e hijos) que me apoya cuando me quedo probando cosas los fines de semana o cuando me quedo toda la noche haciendo ruido.

A Juan Manuel García Carral que me introdujo en el paranoico mundo de la seguridad y me prestó algo de tiempo para que pueda escribir este manual.

Rafael Ibáñez por el apoyo institucional para este proyecto.

A la gente de PaloSanto Solutions por corregir y publicar este manual.

LICENCIAMIENTO

Copyright © 2011 Samuel Cornu

Este documento está permitido de copiar, distribuir y/o modificar bajo los términos de la licencia GNU Free Documentation License Versión 1.3; sin Secciones Invariantes (Invariant Sections), Textos de Cubierta Frontal (Front-Cover Texts), y sin Textos de Cubierta Posterior (Back-Cover Texts).

El autor puede en cualquier momento decidir actualizar la licencia de la presente obra a una versión más reciente de la GNU Free Documentation License.

Page 6: Asegurando Elastix - Samuel Cornu.pdf

6

INTRODUCCIÓN

En el mundo actual, donde las comunicaciones son cada día más importantes, los servidores de comunicaciones, tanto Elastix como cualquier otro, se encuentran comprometidos.

El avance constante de la telefonía y la VOIP hace que día a día aumenten las instalaciones de servidores de comunicaciones. Paralelo a este avance van las técnicas de ataques a estos servidores. Las herramientas actuales hacen que cualquier persona con un mínimo de conocimiento pueda realizar un daño grande en ellos.

Las empresas en busca de reducir costos utilizando los avances en comunicaciones, muchas veces no toman las precauciones de seguridad necesarias. Puede ser por desconocimiento o simplemente por optar por la empresa o persona inadecuada.

Estos errores se traducen en grandes costos en comunicaciones y que culminan generalmente en el retiro de servidores con distribuciones de código abierto por servicios propietarios de grandes Empresas como Cisco o Avaya. Esto también se traduce en desprestigio para el software Libre.

No se trata de una guía definitiva de seguridad sino un buen punto de partida, ya que constantemente aparecen nuevas vulnerabilidades. El administrador del servidor de comunicaciones tendrá que estar al día con los boletines de seguridad y constantemente mirando los logs del sistema.

Existen muchos productos tendientes a utilizar las bondades de la telefonía IP, para este ejemplo se va a utilizar Asterisk, creado por Mark Spencer, y mantenido por la empresa Digium.

Uno de los productos más difundidos en el mundo de la telefonía IP es Elastix.

“Elastix es un software de código abierto para el establecimiento comunicaciones unificadas. Pensando en este concepto el objetivo de Elastix es el de incorporar en una única solución todos los medios y alternativas de comunicación existentes en el ámbito empresarial. “

Las siguientes especificaciones de seguridad son el fruto de la lectura de manuales, participación en foros y experiencias personales.

Page 7: Asegurando Elastix - Samuel Cornu.pdf

7

SERVICIOS

Lo primero que hay que tener en cuenta a la hora de administrar un servidor, es tener control de los servicios que están corriendo en el mismo.

Al momento de la instalación algunos servicios son instalados por defecto y realmente no serán necesarios en el uso cotidiano del servidor de comunicaciones.

A continuación los servicios que corren al inicio en un servidor Elastix luego de una instalación.

# chkconfig --list

Acpid 0:off 1:off 2:on 3:on 4:on 5:on 6:off

asterisk 0:off 1:off 2:on 3:on 4:on 5:on 6:off

atd 0:off 1:off 2:off 3:on 4:on 5:on 6:off

auditd 0:off 1:off 2:on 3:on 4:on 5:on 6:off

crond 0:off 1:off 2:on 3:on 4:on 5:on 6:off

cyrus-imapd 0:off 1:off 2:off 3:on 4:on 5:on 6:off

dahdi 0:off 1:off 2:on 3:on 4:on 5:on 6:off

elastix-firstboot 0:off 1:off 2:on 3:on 4:on 5:on 6:off

elastix-updaterd 0:off 1:off 2:on 3:on 4:on 5:on 6:off

haldaemon 0:off 1:off 2:off 3:on 4:on 5:on 6:off

httpd 0:off 1:off 2:off 3:on 4:on 5:on 6:off

hylafax 0:off 1:off 2:on 3:on 4:on 5:on 6:off

iaxmodem 0:off 1:off 2:on 3:on 4:on 5:on 6:off

ip6tables 0:off 1:off 2:on 3:on 4:on 5:on 6:off

iptables 0:off 1:off 2:on 3:on 4:on 5:on 6:off

isdn 0:off 1:off 2:on 3:on 4:on 5:on 6:off

kudzu 0:off 1:off 2:off 3:on 4:on 5:on 6:off

lm_sensors 0:off 1:off 2:on 3:on 4:on 5:on 6:off

lvm2-monitor 0:off 1:on 2:on 3:on 4:on 5:on 6:off

mcstrans 0:off 1:off 2:on 3:on 4:on 5:on 6:off

mdmonitor 0:off 1:off 2:on 3:on 4:on 5:on 6:off

messagebus 0:off 1:off 2:off 3:on 4:on 5:on 6:off

mysqld 0:off 1:off 2:off 3:on 4:on 5:on 6:off

netfs 0:off 1:off 2:off 3:on 4:on 5:on 6:off

network 0:off 1:off 2:on 3:on 4:on 5:on 6:off

nfslock 0:off 1:off 2:off 3:on 4:on 5:on 6:off

Page 8: Asegurando Elastix - Samuel Cornu.pdf

8

ntpd 0:off 1:off 2:off 3:on 4:on 5:on 6:off

openfire 0:off 1:off 2:on 3:on 4:on 5:on 6:off

portmap 0:off 1:off 2:off 3:on 4:on 5:on 6:off

postfix 0:off 1:off 2:on 3:on 4:on 5:on 6:off

rawdevices 0:off 1:off 2:off 3:on 4:on 5:on 6:off

rpcgssd 0:off 1:off 2:off 3:on 4:on 5:on 6:off

rpcidmapd 0:off 1:off 2:off 3:on 4:on 5:on 6:off

saslauthd 0:off 1:off 2:off 3:on 4:on 5:on 6:off

sshd 0:off 1:off 2:on 3:on 4:on 5:on 6:off

syslog 0:off 1:off 2:on 3:on 4:on 5:on 6:off

wanrouter 0:off 1:off 2:on 3:on 4:on 5:on 6:off

xfs 0:off 1:off 2:on 3:on 4:on 5:on 6:off

xinetd 0:off 1:off 2:off 3:on 4:on 5:on 6:off

xinetd based services:

tftp: on

Page 9: Asegurando Elastix - Samuel Cornu.pdf

9

RUN LEVELS

Antes de configurar los servicios del sistema, debemos conocer los niveles de ejecución o runlevels de un sistema Linux. Un run level es un modo de ejecución, con determinadas características.

Los niveles de ejecución o run levels existentes son

0 Halt 1 Single-user mode 2 Multi-user without network support. 3 Full multi-user mode). 4 Not used (user-definable). 5 Full multi-user mode (with an X-based login screen). 6 Reboot

Cuando el sistema se encuentra en modo texto, se está ejecutando el modo 3. Si por el contrario usa un sistema de ventanas, ejecuta el modo 5. Estos dos run levels corren servicios diferentes, ya que el modo 5 necesita al menos los servicios necesarios para que la interfaz grafica funcione en el sistema. Este documento abarcara solo los servicios que son ejecutados en el run level 3, ya que el sistema Elastix se encuentra en modo texto, es decir en ese nivel.

Ahora se debe analizar los servicios necesarios para el servidor de comunicaciones.

Uno de los servicios que se puede deshabilitar, si es que no se está usando es ip6tables.

Esta tarea se realiza ejecutando la siguiente acción:

chkconfig –level 345 ip6tables off

Otros servicios a deshabilitar son:

KUDZU

Se encarga de detectar y configurar el hardware nuevo conectado al equipo. Se recomienda desactivar este servicio y ejecutarlo cuando sea necesario. Para realizar esta tarea se debe ejecutar la siguiente acción:

chkconfig --level 345 kudzu off

Page 10: Asegurando Elastix - Samuel Cornu.pdf

10

ISDN

Servicio utilizado para conexión a Internet. Si no dispone de un modem de este tipo, debe deshabilitar el servicio ejecutando la siguiente acción:

chkconfig --level 2345 isdn of

NETFS

Monta sistema de archivos en red como NFS, Samba, entre otros. Al momento del inicio del sistema.

Para desactivar este servicio ejecutamos la siguiente acción:

chkconfig --level 345 netfs off

NFSLOCK

Bloquea los archivos que se encuentran compartidos en la red a través de NFS. Si no utiliza NFS para acceder a unidades compartidas puede deshabilitar este servicio.

Para desactivar este servicio ejecutamos la siguiente acción:

chkconfig –level 345 nfslock off

PORTMAP

Es un Servicio complementario al NFS (Network File System) y NIS (Autenticación). Si no se hace uso de NFS, el servicio debe estar desactivado.

Para desactivar este servicio ejecutamos la siguiente acción:

chkconfig --level 345 portmap off

RESTODECOND

Se usa monitorizar y restaurar file context para SELinux. Puede deshabilitarlo con:

chkconfig --level 345 restodecond off

PCGSSD / RPCIDMAPD

Servicios utilizados por NFS, si usted no utiliza este protocolo, debe deshabilitarlo.

Para desactivar este servicio ejecutamos la siguiente acción:

chkconfig –level 345 pcgssd off

chkconfig –level 345 rpcidmapd off

Page 11: Asegurando Elastix - Samuel Cornu.pdf

11

WANROUTER

Es el driver para las tarjetas Sangoma, si no utiliza una en el servidor de comunicaciones es recomendable desactivarlo. Para desactivar este servicio ejecutamos la siguiente acción:

Chkconfig –level 345 wanrouter off

XINETD

A través de xinetd se puede hacer uso de funciones especiales, tales como el tftp. En el caso de ser vulnerado puede dar un riesgo a nivel seguridad. Si no va a utilizar el servicio de tftp puede deshabilitarlo ejecutando la siguiente acción:

chkconfig –level 345 xinetd off

Hasta ahora sólo se deshabilitaron los servicios al arranque, pero los mismos aún siguen corriendo. Se pueden parar todos los servicios con:

service kudzu stop

service isdn stop

service netfs stop

service nfslock stop

service portmap stop

service restodecond stop

service pcgssd stop

service rpcidmapd stop

service wanrouter stop

service xinetd stop

De esta manera sólo han quedado los servicios necesarios para el buen funcionamiento de un servidor de comunicaciones integradas, y resta asegurar a los mismos.

Page 12: Asegurando Elastix - Samuel Cornu.pdf

12

ASEGURANDO SSH

SSH (Secure Shell) es el nombre de un protocolo y del programa que lo implementa, y sirve para acceder a máquinas remotas a través de una red. Permite manejar por completo la computadora mediante un intérprete de comandos.

Antes de explicar cómo agregar seguridad al Secure Shell se explicarán algunas políticas de usuario que luego serán utilizadas para asegurar SSH.

Grupo Wheel

El uso del grupo wheel para usuarios “superusuarios” es una tradición en los Unix estilo BSD, y que ha sido adoptada en otros sistemas operativos Unix-like. No es una obligación hacerlo, pero es una de las tantas formas en las cuales puede mejorarse la seguridad de un sistema Linux.

El programa “su” permite cambiar la identidad de un usuario a otro, generalmente se utiliza para convertirse en superusuario. Esto es sumamente peligroso, por ello, es conveniente, regular el acceso a un programa como este.

En Linux para realizar esta tarea se puede utilizar PAM (“Pluggable Authentication Modules" para Linux), es una suite de librerías compartidas que permiten al administrador local del sistema escoger cómo autentifican a los usuarios y las aplicaciones”.

Para ello hay que editar el archivo /etc/pam.d/su en el cual se encuentran las condiciones de autenticación para emplear el comando ‘

#vim /etc/pam.d/su

#%PAM-1.0

Auth sufficient pam_rootok.so

# Uncomment the following line to implicitly trust users in the "wheel" group.

#auth sufficient pam_wheel.so trust use_uid

# Uncomment the following line to require a user to be in the "wheel" group.

#auth required pam_wheel.so use_uid

auth include system-auth

account sufficient pam_succeed_if.so uid = 0 use_uid quiet

account include system-auth

password include system-auth

Page 13: Asegurando Elastix - Samuel Cornu.pdf

13

session include system-auth

session optional pam_xauth.so

Se debe descomentar la siguiente línea:

auth required pam_wheel.so use_uid

Tal como dice el comentario que precede esa línea al descomentar la misma se requiere ser del grupo wheel para poder utilizar el comando “su”

Si quita el comentario a la siguiente línea implica confianza en los usuarios del grupo Wheel:

auth sufficient pam_wheel.so trust use_uid

Le brindara a cualquier usuario del grupo Wheel la posibilidad de cambiar a superusuario sin la necesidad de introducir password. Por supuesto que esta opción es inaceptable desde el punto de vista de la seguridad del sistema. Por lo tanto únicamente es necesario descomentar la línea:

auth required pam_wheel.so use_uid

Para archivo quede de la siguiente manera:

#cat /etc/pam.d/su

#%PAM-1.0

auth sufficient pam_rootok.so

# Uncomment the following line to implicitly trust users in the "wheel" group.

#auth sufficient pam_wheel.so trust use_uid

# Uncomment the following line to require a user to be in the "wheel" group.

auth required pam_wheel.so use_uid

auth include system-auth

account sufficient pam_succeed_if.so uid = 0 use_uid quiet

account include system-auth

password include system-auth

session include system-auth

session optional pam_xauth.so

Page 14: Asegurando Elastix - Samuel Cornu.pdf

14

Ahora simplemente se debe crear un usuario y asignarlo al grupo Wheel

adduser -G wheel -m -s /bin/bash Samuel

passwd Samuel

De esta manera el usuario Samuel podrá utilizar el comando “su” para convertirse en superusuario.

Sin embargo cualquier otro usuario no podrá hacerlo.

Uso del sudo

Existen algunos comandos muy útiles como el tcpdump que sólo se pueden correr como superusuario. Como se vio anteriormente no es recomendable dar a todos los usuarios el poder de cambiar de usuario. Entonces qué sucedería si se necesita utilizar una herramienta que requiere el uso del usuario root y el administrador no tiene acceso a una PC con Internet. ¿Deberá esperar el tiempo que sea necesario?

Afortunadamente existe el comando sudo que permite que un usuario corra un programa como superusuario, para ello necesita entregarle el password del root al usuario y lamentablemente, realizar esta acción, es un grave error. Dar a un usuario, sin los conocimientos necesarios, este privilegio puede comprometer la integridad de su sistema.

Para evitar futuros dolores de cabeza se puede indicar al comando sudo que a ciertos usuarios le permita utilizar determinados comandos sin la necesidad de ingresar el password de root.

Esta tarea se realiza editando el archivo /etc/sudoers

Para ello es necesario editar el archivo desde consola como superusuario ejecutando el siguiente comando:

Visudo

Y agregar al final del mismo.

user ALL = NOPASSWD: /usr/sbin/tcpdump

No se profundizará en el tema ya que está fuera del ámbito de este documento. Por ello solo se explicara cómo realizar esta tarea en un sistema Elastix que ya usa este archivo para el usuario Asterisk y simplifica la configuración

Page 15: Asegurando Elastix - Samuel Cornu.pdf

15

Si bien aquí se podrían incluir todos los comandos que desee es recomendable que sean los menos posibles.

Hasta este momento se establecieron políticas de usuarios tendientes a mejorar la seguridad del sistema. Para continuar con las políticas de seguridad se deben modificar las opciones de seguridad del servicio SSH, que habitualmente se utiliza para administración remota.

OpenSSH (o Shell Seguro) se ha convertido en el estándar para el acceso remoto, reemplazando al protocolo telnet. SSH ha hecho que los protocolos como telnet sean obsoletos, por el hecho de que la conexión es encriptada y las contraseñas no son enviadas en texto plano para que todos la puedan ver. De todas maneras, una instalación por defecto de SSH no es segura, y hay algunos pasos simples que pueden fortalecer una instalación.

1. Usar contraseñas Fuertes

Si usted está corriendo ssh y se encuentra expuesto al mundo exterior, y revisa el archivo /var/log/audit/audit.log periódicamente, notará la cantidad de intentos de usuarios mal intencionado tratando de acceder a su equipo. Un atacante escaneará el puerto 22 (el puerto por defecto en el cual SSH escucha) para encontrar máquinas que estén corriendo el servicio SSH, y de esta manera intentarán un ataque de fuerza-bruta contra ésta.

Con contraseñas fuertes cualquier ataque será registrado y notificado antes de que pueda tener éxito. Si usted no está utilizando contraseñas fuertes, trate de escoger combinaciones que cumplan las siguientes particularidades:

• 12 Caracteres como mínimo • Mezcle letras mayúsculas y minúsculas • Mezcle letras y números • Use caracteres no alfabéticos (ej.: caracteres especiales como ! " £ $ % ^ etc.) • Rote las contraseñas periódicamente.

Los beneficios de una contraseña fuerte no son exclusivos de SSH, pero tienen fuerte impacto en todos los aspectos de la seguridad del sistema

2. Deshabilitar el acceso como root

La configuración del servidor SSH se encuentra almacenada en el fichero

/etc/ssh/sshd_config. Para deshabilitar el acceso de root, asegúrese de tener la siguiente entrada:

# Authentication:

Page 16: Asegurando Elastix - Samuel Cornu.pdf

16

#LoginGraceTime 2

PermitRootLogin no

y reiniciar el servicio sshd:

service sshd restart

Si usted necesita acceder como root, acceda como un usuario normal que pertenezca al grupo Wheel y use el comando su -.

3. No utilizar el puerto por defecto

Por defecto, SSH escucha las conexiones entrantes en el puerto 22. Para que un hacker determine si SSH se está ejecutando en su máquina, lo más probable es que escanee el puerto 22. Un método efectivo es ejecutar SSH en un puerto no estándar. Cualquier puerto sin usar funcionará, pero es preferible usar uno por encima del 1024.

Muchas personas escogen el 2222 como un puerto alternativo, de la misma forma que el 8080 es conocido, como un puerto HTTP alternativo. Por esta razón, probablemente esta no es la mejor opción. De la misma forma que cualquier hacker escaneará el puerto 22, seguramente también escaneará el puerto 2222 sólo como buena medida. Es mejor escoger cualquier puerto alto al azar que no sea usado por ningún servicio conocido. Para hacer los cambios, añada una línea como esta a su fichero

/etc/ssh/sshd_config:

# Ejecutar ssh en un puerto No-Estándar:

Port 30022

y reinicie el servicio sshd.

Page 17: Asegurando Elastix - Samuel Cornu.pdf

17

FIREWALL

Un firewall es un elemento de hardware o software que filtra el tráfico entre dos redes u hosts conectados entre sí. El firewall permite controlar el flujo de paquetes que van de un lado al otro, es decir, decide si un paquete pasa, se descarta o es respondido con un mensaje de error. Los firewalls más comunes operan en las capas de transporte y de red, es decir, analizan los paquetes en base al protocolo TCP/IP. Para ello, el firewall examina primero si la comunicación es entrante o saliente, de dónde viene y hacia dónde se dirige (direcciones IP y puertos origen - destino).

Siempre es recomendable poseer un Firewall en la red, para que tome las decisiones sobre aceptar, rechazar o denegar. En algunos casos no existe la posibilidad de contar con él, por costos, disponibilidad o decisiones comerciales. Para estos casos se puede utilizar las herramientas disponibles en CentOS, el sistema operativo elegido para las distribuciones Elastix.

NETFILTER-IPTABLES

Netfilter es un framework disponible en el Kernel de Linux a partir de la versión 2.4, que permite interceptar y manipular paquetes de red. Dicho framework permite realizar el manejo de paquetes en diferentes estados del procesamiento. Netfilter es también el nombre que recibe el proyecto que se encarga de ofrecer herramientas Open Source para firewall basados en Linux.

El componente más popular construido sobre Netfilter es iptables, una herramienta de firewall que permite no solamente filtrar paquetes, sino también realizar traducción de direcciones de red (NAT) para IPv4 o mantener registros de log.

Para proteger el sistema operativo y el servidor de comunicaciones Elastix, es necesario, aceptar sólo las conexiones que sean necesarias y rechazar las demás. De esta manera se reduce la exposición del Servidor de comunicaciones.

Un punto a tener en cuenta es el orden de ingreso de las reglas, ya que iptables va examinado las reglas desde la primera que se ingresa, hasta llegar a la última, si no encuentra ninguna coincidencia, la última regla debe ser denegar todo, de esta manera, si no encuentra ninguna coincidencia, no podrá gestionar alguna conexión.

En el ejemplo, se tomará en cuenta sólo una tarjeta de red (NIC).

Se introducirán las líneas con sus respectivas explicaciones, el lector puede si lo desea armar un script.

Page 18: Asegurando Elastix - Samuel Cornu.pdf

18

Se borran las reglas anteriores

#iptables –F

#iptables –F –t nat

Aceptar todo a local loop

#iptables -A INPUT -i lo -j ACCEPT

Aceptar la red interna, se asume que el texto $RED_LAN es una variable que tiene cargada la red interna

#iptables -A INPUT -s $RED_LAN -d 0/0 -j ACCEPT

Acepto el trafico SIP de un proveedor. El texto $IP_ITSP1 y $IP_ITSP2 representan a la dirección IP de un ITSP

#iptables -A INPUT -s $IP_ITSP1 -p udp --dport 5060 -j ACCEPT #iptables -A INPUT -s $IP_ITSP2 -p udp --dport 5060 -j ACCEPT

En el caso de que se tenga usuarios que deben registrarse desde IP remotas dinámicas no deben introducir las líneas anteriores y agregar la siguiente.

#iptables -A INPUT -p udp -m udp --dport 5060 -j ACCEPT

Esto es un faro para los atacantes, si necesita tener esta regla, deberá implementar algún analizador de log, tal como se explicará más adelante.

Se agrega el seguimiento de conexiones sólo para una conexión existente y una relacionada tanto para la cadena input y output

#iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

#iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Estas líneas permitirán el trafico RTP.

#iptables -A INPUT –s $IP_ITSP1 –p udp –dport 10000:20000 -j ACCEPT

#iptables -A INPUT –s $IP_ITSP2 –p udp –dport 10000:20000 -j ACCEPT

Tener especial cuidado con estas líneas, ya que no siempre los ITSP utilizan las mismas IP’s para señalización y media, a veces, hasta utilizan subredes diferentes. En el caso de

Page 19: Asegurando Elastix - Samuel Cornu.pdf

19

que quiera liberar la tarea administrativa que lleva tener que agregar estas IP’s o redes puede agregar la siguiente entrada.

#iptables -A INPUT –p udp –m udp –dport 10000:20000 –j ACCEPT

Aceptar el tráfico IAX2. Como su nombre indica es un protocolo propietario de Asterisk y sirve para interconectar servidores corriendo Asterisk

Si algún proveedor provee una interconexión utilizando este protocolo se debe ingresar la siguiente línea.

#iptables -A INPUT -s $IP_ITSP2 -p udp --dport 4569 -j ACCEPT

En el caso de que existan algunos clientes IAX2 con IP dinámica ingresar la siguiente línea.

# iptables -A INPUT -p udp -m udp -i eth0 --dport 4569 -j ACCEPT

Aceptar tráfico MGCP (sólo aplicar si es que se va a usar. En la mayoría de los casos no es necesario):

# iptables -A INPUT -p udp -m udp -i eth0 --dport 2727 -j ACCEPT

Aceptar el tráfico de mensajería instantánea (si es que se va a acceder desde fuera) desde la red interna no hace falta ya que está permitido todo el tráfico:

# iptables -A INPUT -p tcp -i eth0 --dport 9090 -j ACCEPT

Aceptar el tráfico del servidor de correo y POP/IMAP:

# iptables -A INPUT -p tcp -i eth0 --dport 25 -j ACCEPT

# iptables -A INPUT -p tcp -i eth0 --dport 110 -j ACCEPT

# iptables -A INPUT -p tcp -i eth0 --dport 143 -j ACCEPT

En el caso de que se quiera utilizar el servidor de comunicaciones unificadas como mail server. Si no se va a utilizar de esta manera no ingrese ninguna de estas reglas.

Aceptar tráfico Web (HTTPS) para poder visitar la interface administrativa de Elastix:

También es conveniente ingresar desde una IP o IP’s de confianza, en este caso el texto $IP_CONFIANZA1 asume una dirección IP

iptables -A INPUT -s $IP_CONFIANZA1 -p tcp --dport 443 -j ACCEPT

Page 20: Asegurando Elastix - Samuel Cornu.pdf

20

Se pueden ingresar cuantas líneas como IP’s de confianza se tenga. Sin embargo si se requiere ingresar desde cualquier IP deberá ingresar la siguiente línea.

# iptables -A INPUT -p tcp -i eth0 --dport 443 -j ACCEPT

Esto es como otro faro para los atacantes, por ello, se verán algunas políticas para restringir el acceso HTTP más tarde en este documento

Finalmente denegando el acceso a todo lo demás:

#iptables -A INPUT -p all -i eth0 -j DROP

Para verificar si las reglas se aplicaron correctamente utilizar el comando:

#iptables –L –n –v

Luego para guardar las reglas de iptables

#service iptables save

Page 21: Asegurando Elastix - Samuel Cornu.pdf

21

ASEGURANDO HTTPS

Para las ocasiones que no puede cerrar el HTTPS para las redes de confianza, se puede agregar más seguridad al mismo. En este caso se va a evitar que todo el mundo que ingrese en su navegador https://IPDEMIELASTIX obtenga una imagen como esta.

Para ello hay que configurar apache2 para que antes de que autentifique Elastix tome algunos recaudos de seguridad.

A muchos les gusta el mod_auth_mysql para bloquear http, sin embargo es más práctico para estos fines realizarlo mediante htpasswd ya que hay que realizar unos pequeños ajustes para hacerlo funcionar.

Simplemente hay editar el archivo /etc/httpd/conf.d/elastix.conf para que quede similar a este ejemplo

#vim /etc/httpd/conf.d/elastix.conf

# Apache-level configuration for Elastix administration interface

Timeout 300

# Default apache configuration specifies greater limits than these

#MaxClients 150

#MaxRequestsPerChild 1000

# Default apache User and Group directives MUST be commented out

# in order for these to take effect.

Page 22: Asegurando Elastix - Samuel Cornu.pdf

22

User asterisk

Group asterisk

<Directory "/var/www/html">

# Redirect administration interface to https

RewriteEngine On

RewriteCond %{HTTPS} off

RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

AuthType Basic

AuthName "Zona Restringida"

AuthUserFile /usr/local/apache/wwwpasswd

Require user elastix Samuel

</Directory>

Como se nota se han agregado las últimas 4 líneas al archivo y se explicarán una por una

La primera habla del tipo de autentificación La segunda habla de la leyenda que saldrá con el pop up solicitando usuario y

contraseña. La tercera habla de la ruta donde irá a buscar el usuario y password cifrado. La última hace alusión al usuario a utilizar.

El siguiente paso es generar el password con el comando htpasswd:

# mkdir /usr/local/apache

#htpasswd –c /usr/local/apache/wwwpasswd Samuel

Luego solicitara ingresar un password, finalizados estos pasos es necesario reiniciar apache para que tome los cambios

#service httpd restart

Page 23: Asegurando Elastix - Samuel Cornu.pdf

23

A partir de ahora, el servidor de contenidos web mostrará una ventana similar a esta en lugar de la página de inicio de Elastix.

Todo intento de acceso erróneo será guardado en los archivos de log que se encuentran en /var/log/httpd/

Page 24: Asegurando Elastix - Samuel Cornu.pdf

24

Fail2ban

Fail2Ban es un analizador de logs que busca intentos fallidos de registro y bloquea las IP’s de donde provienen estos intentos. Se distribuye bajo la licencia GNU y típicamente funciona en todos los sistemas que tengan interfaz con un sistema de control de paquetes o un firewall local.

Fail2Ban tiene una gran configuración pudiendo, además, crear reglas para programas propios o de terceros.

Instalación y Configuración

Para instalar fail2ban en un sistema operativo CentOS es necesario ejecutar:

# yum install fail2ban

Ahora hay que configurar Fail2Ban para que analice los logs que deseamos y bloquee IP’s, enviando notificaciones vía e-mail. Para ello se modificara el archivo jail.conf que encontramos en /etc/fail2ban

# cd /etc/fail2ban

# vim jail.conf

Lo primero a modificar es el valor bantime, este valor determina el tiempo en segundos que quedará bloqueada la IP del atacante, por defecto el valor viene en 600 segundos.

Después buscar el valor maxretry que serán el número de veces que una IP puede tener una autenticación fallida antes de ser bloqueada.

fail2ban y SSH

Para que busque intentos fallidos de logueo por SSH modificar el archivo hasta que sea similar a las siguientes líneas:

[ssh-iptables] # Configuración de fail2ban para el puerto ssh

enabled = true

filter = sshd

action = iptables[name=SSH, port=22, protocol=tcp]

Page 25: Asegurando Elastix - Samuel Cornu.pdf

25

sendmail-whois[name=SSH, [email protected], sender=fail2ban@localhost]

logpath = /var/log/secure # Este es el log que analizará fail2ban

maxretry = 3 # cualquier IP que tenga tres o más intentos erroneos se bloqueara.

bantime = 86400 # Tiempo de baneo de 24 horas expresado en segundos

Si modifico el puerto donde escucha el SSH, deberá modificar el parámetro port

Fail2ban y Asterisk

Ahora se debe configurar para que fail2ban lea los registros de Asterisk

#cd /etc/fail2ban/filter.d

Crear el archivo asterisk.conf

#vim asterisk.conf

Copiar estas líneas…

[INCLUDES]

[Definition]

failregex = NOTICE.* .*: Registration from '.*' failed for '<HOST>' - Wrong password

NOTICE.* .*: Registration from '.*' failed for '<HOST>' - No matching peer found

NOTICE.* .*: Registration from '.*' failed for '<HOST>' - Username/auth name mismatch

NOTICE.* <HOST> failed to authenticate as '.*'$

NOTICE.* .*: No registration for peer '.*' (from <HOST>)

NOTICE.* .*: Host <HOST> failed MD5 authentication for (*.) '*.'

NOTICE.* .*: Registration from '.*' failed for '<HOST>' – Device does not match ACL

NOTICE.* .*: Failed to authenticate user .*@<HOST>.*

ignoreregex =

Con esto le indica a fail2ban que tiene que controlar eventuales accesos indeseados en el archivo de registro de Asterisk.

Luego hay que modificar el archivo de configuración de fail2ban

Page 26: Asegurando Elastix - Samuel Cornu.pdf

26

cd /etc/fail2ban

vim jail.conf

Añadir al final del archivo de texto las siguientes líneas

[asterisk-iptables]

enabled = true

filter = asterisk

action = iptables-allports[name=ASTERISK, protocol=all]

sendmail-whois[name=ASTERISK, [email protected],

sender=fail2ban@localhost]

logpath = /var/log/asterisk/full

maxretry = 3

bantime = 86400

Para que funcione este nuevo jail hay que chequear la configuración de los archivos de registro de Asterisk:

#vim /etc/asterisk/logger.conf

Agregar las siguientes líneas al inicio.

[general]

dateformat=%F %T

Recargar el modulo de asterisk

#asterisk –rx “module reload”

Fail2ban y apache2

Otro servicio que se puede monitorear con fail2ban son los intentos fallidos de logeo en Apache2, para ello solo hay que cambiar algunos parámetros en el archivo jail.conf

enabled = true

port = http,https

filter = apache-auth

logpath = /var/log/httpd/ssl_error_log.log

#logpath = /var/log/apache*/*error.log

Page 27: Asegurando Elastix - Samuel Cornu.pdf

27

maxretry = 6

Reiniciar el servicio de fail2ban para que tome en cuenta las modificaciones realizadas

service fail2ban restart

Starting fail2ban: [ OK ]

Para lograr que fail2ban al inicio del sistema, ejecutar:

#chkconfig fail2ban on

Si aparece algún error tendrá que revisar la configuración.

Es una herramienta muy flexible que permitirá realizar los filtros que crea necesario pero los mismos exceden los alcances de este documento.

Page 28: Asegurando Elastix - Samuel Cornu.pdf

28

PORTSENTRY

Una herramienta muy útil para evitar escaneos de puertos es Portsentry. Su misión es sentarse y escuchar a los puertos que se le indique que deben permanecer siempre inactivos. En caso de llegar una conexión a uno de ellos puede marcarlo en el log del sistema, bloquear toda la comunicación con la dirección identificada como agresora, o correr un comando externo.

Siga los siguientes pasos para su instalación:

#wget ftp://ftp.pbone.net/mirror/ftp.falsehope.net/home/tengel/centos/4/te/i386/RPMS/portsentry-1.2-1.te.i386.rpm (para la versión de 32 bits)

# rpm -Uvh portsentry-1.2-1.te.i386.rpm

Para agregarlo para que arranque al inicio del sistema operativo, utilizar el comando:

# chkconfig portsentry on

Configuración

La configuración de Portsentry se hace en el archivo

/etc/portsentry/portsentry.conf

Portsentry tiene varios modos de operación. Sólo se explicará dos: el más común y sencillo es el modo clásico, y el más poderoso es el modo avanzado.

Portsentry - Modo clásico

En este modo, se especifica a Portsentry que escuche determinados puertos TCP y UDP, en las opciones UDP_PORTS y TCP_PORTS en los que no se brindan servicio y son poco solicitados. Por ejemplo, puede que nuestro servidor no esté dando servicio de red SMB (Samba, red tipo Microsoft). Sin embargo, es común que las computadoras Windows manden mensajes broadcast buscando a un sistema en específico, con lo que podríamos recibir una gran cantidad de falsos positivos. Vienen varios puertos predefinidos en el archivo de configuración, y son buenos como recomendación inicial.

Page 29: Asegurando Elastix - Samuel Cornu.pdf

29

Portsentry - Modo avanzado

En éste modo, Portsentry no abre ningún puerto, sino que le pide al kernel que le notifique si llega alguna petición a algún puerto menor al especificado en las opciones ADVANCED_PORTS_TCP y ADVANCED_PORTS_UDP. Claro, tendremos que excluir algunos puertos que sean particularmente ruidosos --como el ejemplo que comentábamos en la sección anterior de la red SMB-- y para ello tenemos las opciones ADVANCED_EXCLUDE_TCP y ADVANCED_EXCLUDE_UDP.

Como ventaja adicional de este modo, al ejecutar netstat -na estando en modo avanzado el sistema no reportará los puertos que está escuchando, dado que no están realmente abiertos. Esto puede simplificar el trabajo como administradores.

El modo avanzado es mucho más sensible que el modo clásico, dado que escucha a muchos más puertos, por lo que puede efectivamente causar una negación de servicio si no es configurado con cuidado

Portsentry - Otras opciones de configuración

Tras haber especificado los puertos que deseamos escuchar, hay algunos parámetros adicionales que se deben especificar:

IGNORE_FILE

Es el nombre del archivo que incluye la lista de direcciones en las que confiamos y por tanto no se quiere bloquear si intentan accesar un puerto bloqueado. Por ejemplo, sería muy molesto que quisiéramos correr nmap contra uno de nuestros servidores para asegurar de que no haya servicios abiertos que no se requieran y que nos bloqueáramos por ello.

HISTORY_FILE

Contiene la lista de direcciones que Portsentry ha detectado intentando accesar puertos monitoreados.

BLOCKED_FILE

Es equivalente a HISTORY_FILE, pero relevante únicamente a la sesión actual de Portsentry.

Page 30: Asegurando Elastix - Samuel Cornu.pdf

30

BLOCK_TCP

Especifica qué hacer cuando un barrido de puertos TCP es detectado. Tiene tres posibles valores: 0 (sólo registrar el intento), 1 (bloquear la dirección que intento el escaneo) y 2 (correr un comando externo especificado en KILL_RUN_CMD).

BLOCK_UDP

Es equivalente a BLOCK_TCP para barridos de puertos UDP.

KILL_ROUTE

Guarda el comando utilizado para descartar toda la comunicación con una dirección. En los Unix’s que no incluyen un paquete que permita manejar reglas de filtrado de paquetes tipo firewall sugiere hacerlo creando una ruta estática hacia dicho host por una interfaz por la que nunca podremos llegar a él (una dirección IP falsa o localhost), evitando toda posible respuesta. En un sistema que incluya un filtro de paquetes (por ejemplo, iptables en Linux o ipf en los *BSD) es muy preferible manejar una regla bloqueando la conexión.

KILL_HOSTS_DENY

Tiene la línea que deberá ser agregada a /etc/hosts.deny para que la dirección atacante sea bloqueada por TCPwrappers. Es conveniente activarlo, pues a diferencia de las reglas manejadas por KILL_ROUTE éste archivo sobrevivirá a la baja del sistema. Claro, no hay que confiarse - TCPwrappers sólo maneja determinados servicios, y si sólo nos protegemos con él, el sistema podrá seguir proporcionando información importante a nuestro atacante.

KILL_RUN_CMD

Puede guardar un comando a ser ejecutado de ser detectada una intrusión. No recomendamos utilizar esta opción, ya que puede fácilmente llevar a una negación de servicio. Hay administradores que sugieren utilizar esta opción para lanzar un contraataque contra el atacante.

SCAN_TRIGGER

Indica qué tan rápido marcar un intento fallido de conexión como un ataque. Probablemente, si a la primera bloqueamos toda comunicación con el presunto atacante, dejaremos fuera a muchos usuarios legítimos que por casualidad hicieron la conexión equivocada. Sin embargo, si ponemos un número muy alto nos exponemos a dar más información de la que hubiéramos querido. Un valor de 1 o 2 es recomendado.

Page 31: Asegurando Elastix - Samuel Cornu.pdf

31

CHKROOTKIT

Para instalar y ejecutar correctamente la aplicación Chkrootkit siga los siguientes pasos:

1.-Descagar e instalar el chkrootkit con los siguientes comandos:

cd /usr/local/src

wget ftp://ftp.pangeia.com.br/pub/seg/pac/chkrootkit.tar.gz

tar -zxvf chkrootkit.tar.gz

mkdir /usr/local/chkrootkit

mv /usr/local/src/chkrootkit*/* /usr/local/chkrootkit

cd /usr/local/chkrootkit

make sense

2.- Agregar al CRON para que se ejecute a diario:

vim /etc/cron.daily/chkrootkit.sh

#!/bin/sh

(

/usr/local/chkrootkit/chkrootkit

) | /bin/mail -s 'CHROOTKIT Daily Run Nombre_del_Server' [email protected]

# ingresar un email de su preferencia, a modo ilustrativo yo ingrese el mío

3.- Cambiar los permisos necesarios:

chmod 700 /etc/cron.daily/chkrootkit.sh

4.- Ejecutar en el momento con el siguiente comando:

./chkrootkit

Esto analizara todo los archivos ejecutables en busca de algún rootkit

Page 32: Asegurando Elastix - Samuel Cornu.pdf

32

TCPWRAPPER

TCP Wrapper ("Envoltorio de TCP") es un sistema de ACL que trabaja en terminales y que se usa para filtrar el acceso de red a servicios de protocolos de Internet que corren en sistemas operativos (tipo UNIX), como Linux o BSD. Permite que las direcciones IP, los nombres de terminales y/o respuestas de consultas ident de las terminales o subredes sean usadas como tokens sobre los cuales filtrar para propósitos de control de acceso.

Este proceso trabaja con los archivos /etc/hosts.allow y /etc/hosts.deny. Al compararse con las directivas de control de acceso de una terminal, que comúnmente se encuentran en los archivos de configuración de los demonios, TCP Wrappers tienen el beneficio de una reconfiguración de ACL en tiempo de ejecución (es decir, los servicios no necesitan ser cargados nuevamente o reiniciados). Esto facilita su uso en scripts anti-gusano, tales como Fail2ban, para agregar y sacar reglas de bloqueo a clientes, cuando estos producen excesivos intentos de conexión o varios errores en el proceso mismo.

Utilizando TCPWapper se puede acotar los accesos por ejemplo de SSH.

Ejemplo de host allow

sshd : 192.168.2.1 : allow

sshd : 172.16.86.0/255.255.255.0 : allow

En el archivo /etc/hosts.deny debe existir una línea como la siguiente.

sshd : ALL : deny

También existen otros demonios que utilizan esta ACL los cuales quedaran a cargo del lector buscar información al respecto.

Page 33: Asegurando Elastix - Samuel Cornu.pdf

33

PRÁCTICAS RECOMENDADAS

Les dejo algunos puntos importantes a tener en cuenta al momento de una nueva implementación. Son algunas recomendaciones que evitaran problemas futuros. Esto no quiere decir que implementando todos estos puntos nunca tendrán un evento de seguridad, sino que será muy difícil para un atacante poder vulnerar un sistema de esta manera. Es posible que cualquier atacante desista de intentar atacar un sistema protegido, e intente otro que no lo está. Por ello les propongo las siguientes prácticas:

Tener una política de acceso físico al servidor adecuada Políticas de acceso remoto limitado por firewall, ACL, y usuarios. Conocer perfectamente el sistema por dentro. Llevar un control exhaustivo del sistema. Estar al día con las actualizaciones, vulnerabilidades y soluciones. Llevar un mantenimiento continuo. Observar los logs del sistema. Evitar utilizar puertos estándares. Utilizar un firewall. Utilizar herramientas como fail2ban y portsentry para evitar escaneos y ataques

DoS. Denegar peticiones al 5060/4569 UDP desde el exterior siempre que no tenga

usuarios SIP/IAX externos. DROPear cualquier paquete procedente de cualquier IP que no sea de su red de

confianza. Rotar password periódicamente. Tener listas de Acceso (ACL) para las registraciones de las extensiones. No dejar los usuarios y password por defectos de Elastix En el caso de utilizar el protocolo SIP, autentificar el paquete de INVITE. No permitir llamadas sin autentificar. Validar la integridad de los ejecutables del sistema. (chkrootkit) Tener un control de la integridad de los directorios y archivos. Correr solo los servicios que realmente sean necesarios. Implementar Monitoreo y log remotos. Una solución a conciencia de Backup y disaster recovery.

Page 34: Asegurando Elastix - Samuel Cornu.pdf

34

SIETE PASOS PARA MEJORAR LA SEGURIDAD SIP EN ASTERISK

PUBLICADOS POR DIGIUM

En los últimos meses han aparecido una serie de nuevas herramientas que hace posible a cualquier usuario novel atacar y cometer fraudes en equipos SIP, incluyendo los sistemas basados en Asterisk.

Existen herramientas fácilmente disponibles que hacen un barrido de redes en busca de hosts que ofrezcan servicios SIP, luego, una vez encontrado, realiza un barrido en busca de extensiones y contraseñas.

Existen ciertas reglas, de aplicación inmediata, que eliminan muchos de los problemas de seguridad, protegiendo al servidor Asterisk de los barridos masivos y los ataques posteriores. Estos métodos y herramientas de protección ya existen, simplemente hay que aplicarlos.

1) No aceptar pedidos de autenticación SIP desde cualquier dirección IP. Utilizar las líneas “permit=” y “deny=” de sip.conf para sólo permitir un subconjunto razonable de direcciones IP alcanzar cada usuario/extensión listado en el archivo sip.conf. Aun aceptando llamadas entrantes desde “anywhere” (vía [default]) no se debe permitir a esos usuarios alcanzar elementos autenticados.

2) Establecer el valor de la entrada “alwaysauthreject=yes” en el archivo sip.conf. Esta opción está disponible desde la versión 1.2 de Asterisk, pero su valor por defecto es "no", lo que puede ser potencialmente inseguro. Estableciendo este valor en "yes" se rechazarán los pedidos de autenticación fallidos utilizando extensiones válidas, es decir envía un mensaje SIP 404 not found, en lugar del clásico 403 forbidden. De esta forma no facilitamos la tarea al atacante para detectar nombres de extensiones existentes utilizando técnicas de "fuerza bruta".

3) Utilizar claves SEGURAS para las entidades SIP. Este es probablemente la más importante medida de seguridad. Los programas que generan y prueban claves por fuerza bruta son accesibles desde la web. Usar símbolos, números, una mezcla de letras minúsculas y mayúsculas y al menos 12 caracteres de longitud es una buena práctica y llevaría demasiado tiempo a un atacante poder descifrar una contraseña así.

4) Bloquear los puertos del Asterisk Manager Interface. Usar “permit=” y “deny=” en manager.conf para limitar las conexiones entrantes sólo a hosts conocidos. Una vez más

Page 35: Asegurando Elastix - Samuel Cornu.pdf

35

utilizar claves seguras aquí también, al menos 12 caracteres de longitud en una combinación de números, letras y símbolos.

5) Permitir sólo una o dos llamadas por vez por entidades SIP cuando sea posible. Limitar el uso no autorizado de las líneas voip es una sabia decisión, esto también es útil para el caso que usuarios legítimos hagan pública su clave y pierdan control de su uso.

6) Los nombres de usuarios SIP deben ser diferentes que sus extensiones.

A pesar de ser conveniente tener una extensión “1234″ que mapee a una entrada SIP “1234″ la cual es también el usuario SIP “1234″, esto también facilita a los atacantes para descubrir nombres de autenticación SIP. En su lugar usar las direcciones MAC del dispositivo, o alguna combinación de frases comunes + extensión MD5 hash (por ejemplo: desde el Shell prompt, hacer “md5 -s ThePassword5000″)

7) Asegurarse que el contexto [default] sea seguro. No permitir que llamadores no autenticados alcancen contextos que les permitan llamar. Permitir sólo una cantidad limitada de llamadas activas pasen por el contexto default (utilizar la función “GROUP” como contador). Prohibir totalmente las llamadas no autenticadas (si es que así lo queremos) estableciendo “allowguest=no” en la parte [general] de sip.conf.

Backdoor en FreePBX

Backdoor detectado en FreePBX (hasta la versión 2.0.1 de Elastix - Agosto 2010)

Reseña

En el mes de agosto de 2010, Andrés Babativa, miembro de lista general de Elastix descubrió que uno de los usuarios definidos para acceder a la base de datos, podía acceder como usuario Admin por el front-end de FreePBX, así es; mas allá de que nos hayamos esmerado muchísimo en usuarios y contraseñas fuertes, si yo vengo con el “gold super user” entro sin ningún problema con permisos de admin y puedo hacer lo que quiero en cualquier Asterisk que tenga un FreePBX!

Para verificar esto podemos acceder a la interfaz de FreePBX, cuando nos solicite user y password ingresamos: asteriskuser/eLaStIx.asteriskuser.2oo7

Page 36: Asegurando Elastix - Samuel Cornu.pdf

36

Frente a esto ese mismo día, horas más tarde el equipo de desarrolladores de Palosanto Solutions ya tenía listo el paquete RPM de FreePBX corregido en los repositorios de Elastix.

Para aplicarlo debemos actualizar FreePBX; para esto ejecutamos en la consola como usuario root:

yum upgrade freePBX

Una vez actualizado, se puede corroborar que el problema está solucionado ingresando el usuario y password anteriormente mencionados y notará que ya no puede acceder.

Page 37: Asegurando Elastix - Samuel Cornu.pdf

37

NOTAS FINALES

Sin dudas la mejor opción es tener un firewall delante de un servidor Elastix, y luego poner un segundo nivel de reglas en el servidor de comunicaciones, sin embargo, no siempre es posible disponer de este escenario.

Para estas ocasiones es recomendable personalizar el firewall del servidor de comunicaciones, dejando solo lo que es estrictamente necesario y denegar el resto, suena algo paranoico pero a veces es mejor restringir de más y corregir sobre la marcha, que pagar voluminosas facturas telefónicas por ser demasiado permisivo.

De esta manera, finaliza este manual y recopilación de buenas prácticas, espero que el lector lo encuentre interesante y sobre todo útil.

Page 38: Asegurando Elastix - Samuel Cornu.pdf

38

FUENTES

Comunicaciones unificadas con Elastix volumen 1 y 2 de Edgar Landívar Elastix a ritmo del merengue de Alfio Muñoz www.wikipedia.org securing_trixbox_ce de Tim Yardley. www.google.com www.iddover.net Material interno de Crossfone Argentina.