Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Asegurando Elastix Samuel Cornu PDF
Asegurando Elastix Samuel Cornu PDF
®
Asegurando Elastix
Primera Edición – Agosto de 2011
Samuel Cornu
2
[PAGINA DEJADA INTENCIONALMENTE EN BLANCO]
3
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
4
AGRADECIMIENTOS
LICENCIAMIENTO
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).
5
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. “
6
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
7
ntpd 0:off 1:off 2:off 3:on 4:on 5:on 6:off
tftp: on
8
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
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
9
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
10
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.
11
ASEGURANDO 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
12
session include system-auth
session optional pam_xauth.so
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
13
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.
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?
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
14
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.
15
#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 -.
16
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
17
Se borran las reglas anteriores
#iptables –F
#iptables –F –t nat
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
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.
18
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 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
19
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
20
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
21
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.
22
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/
23
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
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
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]
24
sendmail-whois[name=SSH, dest=miMail@mail.com, 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
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
25
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, dest=mimail@mail.com,
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
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
26
maxretry = 6
Reiniciar el servicio de fail2ban para que tome en cuenta las modificaciones realizadas
service fail2ban restart
Starting fail2ban: [ OK ]
Es una herramienta muy flexible que permitirá realizar los filtros que crea necesario
pero los mismos exceden los alcances de este documento.
27
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.
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.
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.
28
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
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.
29
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.
30
CHKROOTKIT
Para instalar y ejecutar correctamente la aplicación Chkrootkit siga los siguientes pasos:
#!/bin/sh
(
/usr/local/chkrootkit/chkrootkit
) | /bin/mail -s 'CHROOTKIT Daily Run Nombre_del_Server' samuel@call-
evolution.com.ar
# ingresar un email de su preferencia, a modo ilustrativo yo ingrese el mío
31
TCPWRAPPER
También existen otros demonios que utilizan esta ACL los cuales quedaran a cargo del
lector buscar información al respecto.
32
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:
33
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.
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
34
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″)
Backdoor en FreePBX
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
35
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.
36
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.
De esta manera, finaliza este manual y recopilación de buenas prácticas, espero que el
lector lo encuentre interesante y sobre todo útil.
37
FUENTES
38