Un IDS para mi servidor VPN…

Hola de nuevo. En otro post hablaba sobre cómo crear un servidor de VPNs basado en la aplicación OpenVPN. Pues bien un amigo me comentó, muy acertadamente, que lo de tener una infraestructura para conectarte a casa de forma segura está muy bien pero él no veía claro que teniendo un servicio expuesto en Internet no tuviéramos además un elemento que nos monitorizase o mostrase si alguien con no tan buenas intenciones nos descubriese y tratase se comenzar a hacer cosillas por ahí…

Para dar solución a tal interesante pregunta me puse manos a la obra en buscar la manera de montar alguna cosilla que me permitiese hacer esto. Le verdad que haberlas, hay las, pero instalarlas, configurarlas y demás, lleva su tiempo, contando ya con los conocimientos, claro. Esto a mi amigo no le moló mucho, había que meter horas, y entre empollar, los niños, recados, etc. no le quedaba tiempo libre así que hubo que buscar algo que fuese además sencillo. Y tras buscar por el “Interné” encontré la solución, EasyIDS.

EasyIDS es una distribución Linux basada en CentOS y que su propio nombre la define es un IDS basado en Snort que además viene con un conjunto de aplicaciones que complementan su funcionalidad, como gráficas de tráfico, carga del propio IDS, entre otras. Todo ello gestionado por una interfaz Web.

Lo malo era que ya teníamos nuestro servidor VPN montado en una máquina física y esto es una distribución para instalado desde cero en otro PC, con lo que… ¿cómo integramos las dos? Pues recurriendo a la virtualización. Básicamente lo que he hecho ha sido virtualizar el IDS en Virtualbox como si fuera otra máquina más.

Comencé por bajarme la imagen de EasyIDS desde Sourceforge desde aquí y Virtualbox desde aquí. Luego leí la guía de instalación de EasyIDS que podéis encontrar aquí y lo instalé.

Como nos indican sus autores, el IDS debe tener dos tarjetas de red, una de gestión y otra en la llegará todo el tráfico que será analizado e interpretado por Snort y el resto de aplicaciones y que esta última deberá ir conectada a un puerto del switch en modo “espejo” u un hub. Sobre esto indicar que un puerto en este modo es un puerto que sacará el mismo tráfico de otro del mismo switch. Es decir, se configurará el switch para que el tráfico de un puerto, lo replique y lo saque como digo por otro, este será nuestro “espejo” y en el que tendremos conectado el IDS. En condiciones normales de operación un switch no haría esto ya que sólo envía el tráfico por el puerto que corresponde, a diferencia de los “hubs” que lo propagan por todas las bocas, esté o no, el destinatario conectado a esa boca. En mi post “Seguridad en Puerto” explico de forma resumida esto, lo podéis encontrar aquí. Obviamente, como norma, general nosotros en casa no tenemos un switch con estas prestaciones con lo que gracias a Virtualbox hemos conseguido engañar al IDS para que funcione.

El “truco” ha sido el siguiente, en Virtualbox hemos creado dos tarjetas de red, y las hemos configurado en modo “Adaptador Puente” y, a ambas, las hemos vinculado a la interfaz de nuestro equipo anfitrión, en mi caso según muestra la captura la “eth0”.

Captura_01

Captura_02

¿Por qué esto? Porque EasyIDS debe manejar las dos tarjetas de red de forma distinta con lo que a nuestro IDS le decimos que tiene dos tarjetas de red distintas, por ejemplo la “eth0” y “eth1”, la “eth0” para el analizar el tráfico de red y la “eth1” para la administración. Luego nosotros le diremos a Virtualbox que ambas tarjetas de red virtuales salgan por la misma tarjeta de red física, que será por donde nos llegue todo el tráfico desde exterior, nuestras peticiones de establecer la VPN o las que “otros” quieran hacernos. Cuando llegue tráfico a mi servidor, llegará también a la tarjeta de red virtual encargada de analizar todo el tráfico. Por otra parte cuando quiera conectarme a EasyIDS para ver el estado de todo en general también podré hacerlo ya que también hemos configurado la tarjeta de red virtual de administración de la misma manera.

Vamos que de forma sencilla podremos instalar nuestro IDS y visualizar  con NTOP todo el tráfico que nos llega a nuestro servidor VPN y así tenerlo algo más controlado.

Ahora el tiempo nos lo llevará conocer las herramientas y manejarlas para sacarle el mayor provecho posible.

Un saludo, nos vemos en otra.

 Seguiremos informando…

Conectándonos a casa…Parte II

Siguiendo con el tema anterior, en este post vamos a explicar los pasos a seguir para poder conectarnos al servidor y establecer así el túnel cifrado.

Para este ejemplo lo haremos con un equipo con Windows 7 in. Para ello nos descargaremos e instalaremos la aplicación OpenVPN para este sistema operativo, desde aquí.

Luego nos dirigiremos a C:\Program Files\OpenVPN\config y allí pegaremos los certificados y claves privadas ca.cert, cliente01.cert, cliente01.key y ta.key que utilizará la aplicación como credenciales para poder autenticarnos contra el servidor. Luego crearemos un archivo de texto con extensión .ovpn que será nuestro archivo de configuración, el cual editaremos de la siguiente manera:

#Modo de funcionamiento
client
#Tipo de interfaz
dev tun
#Protocolo de transporte
proto udp
#IP o FQDN y puerto a la escuha de éste
remote <IP o FQDN> <Puerto>
#Certificado de nuestra AC
ca ca.crt
#Certificado de nuestro equipo cliente
cert cliente01.crt
#Clave privada de nuestro equipo cliente
key software01.key
#Clave para modod TLS
tls-auth ta.key 1
#Papel en el modo TLS, en este caso cliente
tls-client
keepalive 10 40
persist-key
persist-tun
verb 3
comp-lzo yes
cipher AES-256-CBC
tls-cipher DHE-RSA-AES256-SHA
auth SHA512

De los parámetros anteriores veremos cómo hay algunos que especifican claramente el papel que juega nuestro equipo, es decir es un cliente y no un servidor. Esto queda claro en la primera línea, client.  Por tanto al cliente hay que decirle contra quién se tiene que conectar. Esto lo conseguimos con la línea remote <IP o FQDN> > <puerto a la escucha del servidor>. Alguno dirá ¿qué pasa si mi ISP me da una dirección IP dinámica? Para esto podremos crear una cuenta en DynDNS y configurar nuestro router o nuestro servidor para actualizar periódicamente nuestra IP. Finalmente las líneas tls-auth ta.key 1 y tls-client especifican los parámetros del modo TLS. En la primera vemos que finaliza en (a diferencia del servidor que termina en 0) y en la segunda cómo se especifica que se trata de un cliente.

Con esto aún nos quedaría indicar que la aplicación debe ejecutarse con permisos de administrador para que podamos agregar a nuestra tabla de rutas que todo el tráfico dirigido a la red de nuestra casa salga por la interfaz de nuestra VPN (tun0) en lugar de la interfaz física conectada a la red en la que nos encontremos, un hotel, aeropuerto, casa de un colega, etc.

Y ya está, con pinchar con el botón derecho del ratón sobre el archivo de configuración y seleccionar “Start OpenVPN on this config file” se abrirá una ventana de consola donde figurará todo el procedimiento de conexión y al cabo de unos segundos tendremos nuestra VPN establecida.

A partir de ahí podremos trabajar con las unidades de red tal y como estuviéramos en casa. OJO!! Acordarse que el tipo de interfaz que tenemos funcionando (tun0) es de capa 3 con lo que el tráfico broadcast utilizado por ciertos protocolos de red NO se pasará de una interfaz a otra, con lo que si queremos mapear unidades de red en nuestro equipo deberemos indicar la IP y no su nombre. ¿Si?

Pues nada, con este artículo ya damos por finalizado la creación nestra VPN casera. Ahora me voy a preparar un laboratorio para las siguientes entradas.

Seguiremos informado….

Conectándonos a casa…Parte I

En este post voy a hablar sobre cómo montar una Red Privada Virtual (VPN). Aunque muchos ya lo sepan una VPN es una canal de comunicación privado sobre una red pública, o sea Internet. El objetivo es que dos o más dispositivos geográficamente dispersos se comuniquen entre sí, pudiendo los usuarios acceder a los mismos recursos de red como si estuvieran en la misma red local. Los dos escenarios más comunes sobre los que se implementa esta tecnología es para comunicar dos, o más sedes o bien, una sede y uno o varios trabajadores.

Sitio a Sitio

Teletrabajador

Al utilizar una infraestructura de comunicaciones pública podremos ser blancos de algún tipo de ataque, por lo que deberemos dotar a nuestra conexión VPN de unos mecanismos de seguridad tales como integridad, confidencialidad, autenticidad y si puede ser, no repudio. Éstos deben ser proporcionados, según sus capacidades, por los distintos protocolos que existen para la creación de túneles VPN, como pueden ser IPSec, PPTP, L2TP, SSL/TLS, etc.

Nuestro objetivo será crear una método a través del cual podamos conectarnos a nuestra red de casa estableciendo una canal de comunicaciones a través del cual toda la información que viaje por él cumpla con los requisitos descritos en el párrafo anterior. Para ello utilizaremos la aplicación OpenVPN, el protocolo SSL/TLS para creación del túnel, y una infraestructura de clave pública mediante la generación de certificados digitales por medio de nuestra propia autoridad certificadora (AC). Finalmente una vez hayamos establecido la conexión podremos tener acceso a otros equipos dentro de nuestra red. Es decir:

Así pues, necesitaremos de un servidor (bien físico o virtualizado) corriendo OpenVPN que situaremos en nuestra red local y que será el que reciba las conexiones de los clientes. Una vez autenticado el equipo remoto, se establecerá un túnel cifrado por donde circulará todo el tráfico entre éste y aquél. Este servidor lo montaremos sobre una distribución GNU/Linux Ubuntu 11.10 y nuestros clientes podrán ser tanto Microsoft Windows como GNU/Linux.

Empezamos por el servidor. El primer paso será instalar la aplicación,

sudo apt-get install openvpn

Para que nuestra aplicación se ejecute con los parámetros que queramos deberemos editar un archivo de texto con las instrucciones que deseemos incluir dentro del directorio /etc/openvpn. A mi particularmente me gusta crear un directorio adicional y dentro de éste otros dos en los que irán por un lado, la configuración como tal y por otro, los certificados de autenticación. Es una manía de tenerlo separado y ordenado. Así entonces ejecutaremos, como root:

#cd /etc/openvpn
#mkdir mi_vpn
#cd mi_vpn
#mkdir credenciales
#mkdir config

Para hacer más sencilla la tarea de creación de certificados tanto de la Autoridad Certificadora, servidor y clientes, vamos a copiar en la carpeta config unos script que nos servirán de gran ayuda.

#cp -R /usr/share/doc/openvpn/examples/easy-rsa/2.0/* /etc/openvpn/mi_vpn/config/

Allí veremos una serie de ficheros. Comenzaremos por editar vars. Este fichero contendrá las variables a las que estará sujetos los certificados a generar, tamaño de las claves, lugar donde se almacenarán, etc. En él sustituiremos una serie de líneas:

Lugar donde se almacenarán los certificados:

export KEY_DIR=”$EASY_RSA/keys”

por:

export KEY_DIR=”/etc/openvpn/mi_vpn/credenciales”

Si queremos aumentar el tamaño de la clave del proceso Diffie-Hellman. En nuestro caso lo dejaremos en 1024 pero lo podemos aumentar a 2048, 4096, etc:

export KEY_SIZE=1024

Validez del certificado de la AC desde su creación, en días:

export CA_EXPIRE=3650

por:

export CA_EXPIRE=365

Validez de los certificados generados:

export KEY_EXPIRE=3650

por:

export KEY_EXPIRE=365

Valores para los distintos campos de los certificados digitales, cada cual ponga lo que quiera.

export KEY_COUNTRY=”US”
export KEY_PROVINCE=”CA”
export KEY_CITY=”SanFrancisco”
export KEY_ORG=”Fort-Funston”
export KEY_EMAIL=”me@myhost.mydomain”

por:

export KEY_COUNTRY=”ES”
export KEY_PROVINCE=”Alava”
export KEY_CITY=”Vitoria”
export KEY_ORG=”celedon2.0″
export KEY_EMAIL=”celedon2.0@midominio.com”

Luego:

# source ./vars
# ./clean-all

Generamos la clave Diffie-Hellman, puede llevar un rato:

# ./build-dh

Comenzamos a crear los certificados. Primero la Autoridad Certificadora, luego el servidor y finalmente los clientes. Durante el proceso nos pedirá que aceptemos una serie de campos para los certificados que serán los mismos que hemos editado anteriormente en el fichero vars. También cuando nos aparezca “Sign the certificate? [y/n]:” y “1 out of 1 certificate requests certified, commit? [y/n]y” responderemos que sí (o sea, y + Enter).

# ./build-ca

./build-key-server server

./build-key cliente01

./build-key cliente02

Luego nos dirigiremos al directorio /etc/openvpn/mi_vpn/credenciales y comprobaremos que allí se encuentran los certificados que acabamos de generar.

#cd /etc/openvpn/mi_vpn/credenciales/

A continuación vamos a crear una contraseña estática que luego veremos para qué sirve:

# openvpn –genkey –secret ta.key

Ahora toca generar un archivo de texto dentro de /etc/openvpn/mi_vpn/config el cual albergará los parámetros bajo los cuales queremos correr nuestro servidor. Si consultamos el manual (ejecutamos man openvpn) de OpenVPN veremos que la lista es muy amplia.

# nano mi_vpn.conf

Y podemos pegar el siguiente contenido sin las líneas comentadas con #:

#Tipo de interfaz
dev tun
#Protocolo de transporte
proto udp
#Puerto a la escuha
port 45123
#El servidor actuará también como DHCP server para los clientes #de la VPN
server 10.1.1.0 255.255.255.0
#Credenciales de autenticación y archivos para protocolo      #Diffie-Hellman
ca /etc/openvpn/mi_vpn/credenciales/ca.crt
cert /etc/openvpn/mi_vpn/credenciales/server.crt
key /etc/openvpn/mi_vpn/credenciales/server.key
dh /etc/openvpn/mi_vpn/credenciales/dh1024.pem
#Clave para autenticación modo TLS
tls-auth /etc/openvpn/mi_vpn/credenciales/ta.key 0
#Comportamiento en modo TLS
tls-server
#Tipo de cifrado para TLS
tls-cipher DHE-RSA-AES256-SHA
#Método de cifrado para los paquetes dentro de la VPN
cipher AES-256-CBC
#Tipo de autenticación para los paquetes dentro de la VPN
auth SHA512
#Se indica a los clientes que todo el tráfico a la red 192.168.1.0/24 #vaya por la VPN
push “route 192.168.1.0 255.255.255.0”
#Servidores DNS a utilizar para los clientes
push “dhcp-option DNS 8.8.8.8”
push “dhcp-option DNS 8.8.4.4”
#Frecuencia para los mensajes de comprobación del estado de la #VPN
keepalive 10 40
#No se releen las contraseñas tras caídas y reinicios de sesión
persist-key
#No se cae y se levanta la interfaz ante caídas de sesión
persist-tun
#Máxima cantidad de clientes permitidos
max-clients 4
#Nivel de información
verb 3
#Se permite la comunicación entre clientes
client-to-client
#Logs de estado de conexiones en el servidor
status /etc/openvpn/mi_vpn/config/status.log
#Compresión de datos
comp-lzo yes
#A los clientesse les asignará la misma dirección IP dentro de la #VPN
ifconfig-pool-persist /etc/openvpn/mi_vpn/config/ipp.txt
#Fichero donde se indica los certificados que han sido revocados
crl-verify /etc/openvpn/mi_vpn/credenciales/crl.pem

A raíz de lo anterior conviene decir que, al ejecutarse OpenVPN, éste genera una interfaz virtual que podrá ser del tipo tun o tap. Nosotros emplearemos las de tipo tun que es como si fuera una tarjeta de red normal y corriente. El puerto a la escucha de conexiones que utiliza OpenVPN por defecto es 1194 pero lo hemos cambiado a 45123 para dificultar que los escáneres lo localicen. Podemos poner el que queramos.

Las opciones tls-xxxxx hacen referencia al modo TLS. Este modo añade una capa más de seguridad estableciendo dos canales, uno de control y otro de datos. OpenVPN iniciará una sesión TLS sobre el canal de control y lo usará para intercambiar claves de cifrado y HMAC, para proteger así el canal de datos, defendiéndonos de ciertos ataques. Como os digo consultar el manual y veréis el porqué también utiliza UDP en lugar de TCP.

Por otra parte, al generarse una interfaz nueva en nuestro servidor deberemos habilitar el enrutamiento entre ellas, es decir entre la que generará OpenVPN, la tun0 y la física la eth0, eth1, etc. Esto lo haremos mediante:

# echo 1 > /proc/sys/net/ipv4/ip_forward

Si no queremos repetir este paso cada vez que iniciemos el equipo podremos editar el archivo /etc/sysctl.conf para que se habilite el enrutamiento automáticamente. Además podremos activar también algunas medidas de seguridad adicionales para prevenir IP spoofing, ICMP redirects, etc.

Por último tendremos que configurar una regla mediante iptables para que todo el tráfico dirigido a nuestra red de casa 192.168.1.0/24, con una IP de origen de nuestra red VPN y que salga por la interfaz física (eth0) sea enmascarado (realizar NAT) con la IP de la interfaz eth0.

# iptables -t nat -A POSTROUTING -s 10.1.1.0/24 -o eth0 -j MASQUERADE

¿Y con esto ya estaría? Podría, pero aún nos quedaría un par de cosas por hacer. Tras copiar en un soporte externo (un pen drive, por ejemplo), la carpeta mi_vpn, a modo de copa de respaldo deberemos borrar aquellos archivos que no son estrictamente necesarios. Nuestro servidor estará accesible desde Internet a todos los efectos y si por alguna razón “alguien” lo comprometiese, podría entre otras cosas, generar nuevos certificados. Por ello deberemos quitar la clave privada de nuestra AC, los scripts con los que hemos generado los certificados, el fichero vars, etc. En resumen, en la carpeta config podremos dejar los archivos ipp.txt, log.txt, mi_vpn.conf y status.log; mientras que en credenciales, el server.crt, server.key, ca.crt, ta.key, crl.pem, dh1024.pem, index.txt, index.txt.attr, index.txt.attr.old, index.txt.old, serial, serial.old y revoke-test.pem.

En referencia a la regla de iptables deberíamos ser más concisos con el tráfico que dejamos pasar. Para ello recomiendo la aplicación FWBuilder que nos permitirá crear las reglas que deseemos de una forma gráfica y mucho más intuitiva que si lo hacemos a pelo en la línea de comandos. Además no sólo para ipables, sino también para dispositivos Cisco ASA/PIX, Cisco IOS ACL, entre otros. La gente de SecuritybyDefault hablan de ella aqui.

Otra de las cosas que debemos hacer es configurar nuestro router para reenviar las conexiones UDP al puerto 45123, hacia la IP privada de nuestro servidor con IP 192.168.1.100

Y con esto ya tendremos nuestro servidor OpenVPN configurado. Ahora solo queda arrancarlo:

sudo openvpn /etc/openvpn/mi_vpn/config/mi_vpn.conf

Y con esto ya hemos cumplido con la primera de las partes, ahora nos quedan los clientes que eso lo dejamos para los próximos días.

Seguiremos informando….