PDF de programación - Seguridad en Servidores CentOS con Elastix

Seguridad en Servidores
CentOS con Elastix ® +

Buenas Prácticas

V. 0.8.7



Rodrigo A. Martin



Este artículo se distribuye bajo la licencia Attribution 3.0 de Creative Commons, más información:
http://creativecommons.org/licenses/by/3.0/

El presente documento tiene solo fines informativos y su contenido está sujeto a cambios sin notificación
alguna.







Tabla de contenido



Introducción .................................................................................................................................. 3

Firewall-Iptables ............................................................................................................................ 3

Asegurando SSH en su sistema ..................................................................................................... 5

Fail2ban ......................................................................................................................................... 7

Port-knocking o Golpeo de Puertos: “Llamar antes de entrar” ................................................... 11

Buenas Prácticas en nuestro Servidor ......................................................................................... 16

Siete pasos para mejorar la seguridad SIP en Asterisk ............................................................... 16

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



Indetics – Ingeniería en Soluciones IT

Mayor Arruabarrena 1715 PA (C.P: 5000) - Córdoba – Argentina

+54 9 351 5903033 | [email protected] | www.indetics.com





Introducción


Antes de comenzar el desarrollo del presente, debo aclarar que no se trata de un
manual que cubre todos los aspectos de seguridad a tener en cuenta al poner un
servidor elastix en producción, sino, ciertas recomendaciones y configuraciones
básicas del S.O junto con otros aplicativos, extraídas de libros, manuales y
experiencias personales que nos ayudaran a mantenerlo seguro y más si este, no
está dentro de una VPN o atrás de un Firewall físico (que sería lo ideal).

Mi recomendación inicial es cambiar todos los passwords que trae elastix por
defecto, esto lo podemos encontrar en el libro “Elastix a Ritmo de Merengue”
capítulo 12, (desde la versión 2.0 en Elastix se solicita que se carguen los
passwords al final de la instalación) otra observación importante es que realicen
todo este tipo de pruebas y configuraciones sobre servidores en laboratorio (un
excelente aliado para esto es la Virtualización) y así comprender realmente lo que
se esta haciendo permitiéndonos equivocarnos o inclusive mejorar las mismas,
dicho esto, comencemos:


Firewall-Iptables

Iptables es el firewall que trae instalado nuestro CentOS , este es muy popular y
uno de los más utilizados en distribuciones Linux por su robustez y estabilidad. Lo
ideal es que el firewall sea un componente independiente separado de los demás
servidores, pero si no tenemos dicho dispositivo, podemos aplicar estas reglas
directamente sobre nuestro servidor y así establecer políticas con los puertos de
red del mismo.
Lo que haremos por medio de esta herramienta será habilitar o “abrir” solo los
puertos que estamos utilizando y cerrar todos los demás brindando así mayor
protección al servidor. Es importante el orden de ingreso de las reglas, ya que
iptables va “macheando” por estas desde la primera que se ingresa, hasta llegar a
la última, si no encuentra ninguna coincidencia, la última regla que escribiremos
será cerrar todos los demás puertos, así que si no coincide con los especificados al
principio, no podrá gestionar alguna conexión por dicho puerto.

En el ejemplo tomamos que la tarjeta de red por defecto es “eth0”

Permitir acceso total desde la LAN (suponiendo que estamos en la red 192.168.0.0,
deberá modificar este parametro dependiendo de su red)

# iptables -A INPUT -s 192.168.0.0/24 -j ACCEPT

Aceptando el tráfico SIP:

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

Aceptando el tráfico IAX2:

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



Indetics – Ingeniería en Soluciones IT

Mayor Arruabarrena 1715 PA (C.P: 5000) - Córdoba – Argentina

+54 9 351 5903033 | [email protected] | www.indetics.com





Aceptando el tráfico RTP (Suponiendo que no se ha alterado el archivo rtp.conf):

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

Aceptando tráfico MGCP (solo 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

Aceptando el tráfico de mensajería instantánea (si es que se va a acceder desde
fuera):

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

Aceptando 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

Aceptando tráfico Web (HTTP y HTTPS) para poder visitar la interface
administrativa de Elastix; si vamos a utilizar “Portknocking” (desarrollado más
adelante) no abrir los puertos 80 ni 443:

# iptables -A INPUT -p tcp -i eth0 --dport 80 -j ACCEPT
# iptables -A INPUT -p tcp -i eth0 --dport 443 -j ACCEPT
# iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j
ACCEPT

Aceptando tráfico SSH para poder remotamente a la consola del S.O (si utilizamos
un puerto no estándar abrir ese y no el 22) misma aclaración anterior, si vamos a
utilizar “Portknocking” (desarrollado más adelante) con este puerto, no abrir el
mismo:

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

Finalmente denegando el acceso a todo lo demás en la interfaz eth0:

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

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

# iptables -L

Si algo no salió de acuerdo a lo esperado, podemos hacer un “flush” (borrar) de
todas las reglas con el comando:

# iptables –F

Para guardar nuestras reglas y que estas sean aplicadas cada vez que reiniciemos
nuestro server usamos el comando:
# /sbin/service iptables save

Indetics – Ingeniería en Soluciones IT

Mayor Arruabarrena 1715 PA (C.P: 5000) - Córdoba – Argentina

+54 9 351 5903033 | [email protected] | www.indetics.com





Asegurando SSH en su sistema

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 redundantes, en su mayoría, 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 perfecta, y cuando
corremos un servidor ssh, hay algunos pasos simples que pueden endurecer
dramáticamente una instalación.

1. Usar contraseñas Fuertes

Si usted está corriendo ssh y se encuentra expuesto al mundo exterior, una de las
primeras cosas que podrá notar serán los intentos de los hackers tratando de
acceder para adivinar su nombre de usuario/contraseña. Típicamente un hacker
escaneará el puerto 22 (el puerto por defecto por el cual ssh escucha) para
encontrar máquinas que estén corriendo ssh, y entonces intentarán un ataque de
fuerza-bruta contra ésta. Con contraseñas fuertes en su lugar, felizmente 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
contengan:

8 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.)

Los beneficios de una contraseña fuerte no son específicos 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:


#Prevent root logins:

PermitRootLogin no

y reiniciar el servicio sshd:

service sshd restart


Si usted necesita acceder como root, acceda como un usuario normal y use el
comando su -.



Indetics – Ingeniería en Soluciones IT

Mayor Arruabarrena 1715 PA (C.P: 5000) - Córdoba – Argentina

+54 9 351 5903033 | [email protected] | www.indetics.com





3. Deshabilitar el protocolo 1

SSH posee dos protocolos que se pueden usar, protocolo 1 y protocolo 2. El viejo
protocolo 1 es menos seguro y debe estar deshabilitado, a menos que usted lo
requiera para algo específico. Busque la siguiente línea en el fichero
/etc/ssh/sshd_config, descoméntela y modifíquela como sigue:


# Protocol 2,1

Protocol 2

Reinicie el servicio sshd.

4. Usar un Puerto No-Estándar

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 (porque es fácil de
recordar), de la misma forma que el 8080 es conocido, a menudo, 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 solo como buena medida. Es mejor escoger cualquier
puerto alto al azar que no sea usado por ningú