| Artículos | 01 MAR 2007

Más allá de los cortafuegos

Tags: Histórico
Daniel Matey.
En la actualidad, el mero hecho de contar con un cortafuegos en la empresa no es suficiente para combatir las vulnerabilidades del día a día. A continuación proponemos un método que nos permite blindar el tráfico dirigido a nuestra organización, con el fin de proteger al máximo la infraestructura de la empresa.

Los cortafuegos, o firewalls, son un gran invento, ya que aportan, de forma rápida, un cierto nivel de seguridad. Pero no debemos dejar de pensar en que estos cortafuegos no son más que coladores sofisticados. Si lo pensamos con detenimiento, al fin y al cabo, un firewall deja entrar y salir el tráfico indicado por el administrador a través de un número determinado de reglas. Suponemos que los intentos de un hacker se quedarán en dicho colador como si fueran los grumos del zumo de naranja, pero, en realidad, sabemos que un firewall sólo se lo pone un poco más difícil.
Hoy en día, muchos firewalls incluyen filtros a nivel de protocolo, esto implica que, si por ejemplo, hemos creado una regla para dejar salir los datos vía HTTP, el firewall se asegure de que el tráfico que transcurra por esa regla sea realmente HTTP.
Un problema que tienen los filtros de aplicación es que, cada vez más, todo se encapsula bajo HTTP. Por ejemplo, las aplicaciones dejan de conectarse a las bases de datos con conexiones típicas y usan servicios web que se apoyan en HTTP/SSL. Otros ejemplos son los servicios de proxy RPC sobre HTTP para leer el correo de Exchange desde Outlook usando HTTP, o la posibilidad de hacer VPNs por SSL. Todo esto junto con la dificultad añadida de inspeccionar el trafico encriptado, hace que, al final, los filtros de aplicaciones o protocolos no sean tan útiles como se pudiera pensar.
En este artículo veremos que para obtener infraestructuras seguras es necesario ir un poco más allá de los cortafuegos, y para demostrar el porqué, vamos a usar el siguiente escenario:
La empresa ficticia que se ve en el diagrama dispone de un servidor Web situado en la DMZ (zona desmilitarizada). Este servidor alberga la página web pública de la empresa, y dicha página está visible a través de Internet. Por otra parte, el firewall (FWE) publica el puerto 80 de ese servidor. Por seguridad, el firewall interno (FWI) impide todo el tráfico de ese servidor hacia la red interna.
También hay otro servidor Web (WS) que expone una serie de servicios que son consumidos por los clientes de la empresa. Para acceder a ese servidor, hay que acceder de una dirección IP determinada, tener un certificado, y validarse con un usuario de Windows. Con estas medidas de seguridad, un atacante no podrá acceder fácilmente a este servidor. Además, el filtro por IP origen impedirá que un atacante común encuentre indicios de este sitio web con un simple escaneo de puertos.
El hecho de que este servidor (WS) tenga tantas medidas de seguridad, se debe a que puede acceder al servidor de base de datos que, además de encontrarse en la red interna, contiene información critica para la empresa.
El firewall interno (FWI) dejara que el servidor (WS) acceda a la base de datos en el servidor (BD), donde está la información que retornan los servicios web. El servidor de base datos (BD), por su parte, se encuentra dentro de la red interna, y por lo tanto tiene acceso libre a esta red.
En este escenario, que es el más común, la empresa ha confiado tradicionalmente en los cortafuegos y ha creído que son la panacea a los problemas de seguridad.
Lo cierto es que un atacante no trataría de penetrar en el firewall, ni el router de internet, ni se desanimaría por encontrar que sólo puede ver el puerto 80 de un servidor web. Es más, en cuanto vea que está abierto, lo más seguro es que sonría y piense que ya tiene por dónde empezar.
A partir de este punto, el atacante puede usar, bien una vulnerabilidad no corregida o parcheada en el servidor web, o fallos de seguridad en el código del sitio web para lograr acceder a dicho servidor, y comenzar un escalado de privilegios que le conduzca a apropiarse de él.
No obstante, a este nivel hemos de preguntarnos qué protege al servidor WS del servidor WWW. En este caso la respuesta es nada, ya que un atacante que tenga el control del servidor WWW podrá probar toda suerte de ataques y escanear libremente en WS desde la propia DMZ (que nosotros consideramos de confianza), hasta lograr acceder a su interior. Una vez dentro, nada le impedirá llegar al BD, y en ese momento ya habrá penetrado y podrá acceder al resto de servidores en la red interna.
Si nunca ha pensado en esto, le invito a tomarse cinco minutos para darse cuenta de que los firewalls son coladores. No obstante, es igualmente reconfortante el hecho de que no todo el mundo sabría cómo realizar un ataque de estas características. Además, tan sólo con tener los servidores actualizados, y haber encargado la página web a una empresa que desarrolle código preocupándose por la seguridad del mismo, ya será bastante más complicado que una situación como la anteriormente descrita le ocurra a usted. De todas formas, a continuación indicamos una solución que nos permitirá diseñar redes más seguras.
Segmentando, segmentado, triunfe securizando. (imagen_2.jpg)
Piensen ahora que dispusiéramos de una tecnología que nos permitiera segmentar la red más allá de los cortafuegos, de forma que, dado que el servidor (WWW) no tiene nada que hablar con él (WS), este tráfico no estuviera permitido. Piense que también impidiera que el servidor (BD) hablara con el resto de servidores de la red interna (con la excepción del controlador de dominio, o AD, que será necesario para validar las sesiones de la base de datos). Coincidirá conmigo en que sería todo mucho más seguro.
Pues este tipo de disposiciones ya son posibles con la tecnología actual. Para conseguir nuestro objetivo, haremos uso de una técnica llamada aislamiento, también denominada como “Domain Isolation” (aislamiento de dominio) o “Server Isolation” (aislamiento de servidor), según el ámbito de aplicación.
Para llevar a cabo nuestro objetivo, usaremos el directorio activo (Active Directory), para organizar los servidores en unidades organizativas. Después crearemos políticas de seguridad IPsec, y las asignaremos a los equipos en las unidades organizativas a través de las GPOs (o políticas de grupo). Por último, modificaremos algunos permisos para completar nuestra solución y hacerla aún más segura.
IPsec
El protocolo IPsec permite que los equipos se autentifiquen unos con otros antes de comunicarse. Opcionalmente también permite encriptar la comunicación, aunque hemos de tener en cuenta que esta encriptación añadirá a la carga de los procesadores de nuestros servidores una carga extra que oscila entre el uno y el tres por ciento. No obstante, si fuera necesario, existen tarjetas de red especiales que permiten descargar ese trabajo a las CPU del servidor.
La autenticación usada en IPsec puede ser de varios tipos, se pueden usar, por ejemplo, certificados, pero en nuestro caso, y dado que todos las máquinas son Windows, y que además pertenecen a un dominio del directorio activo, usaremos Kerberos, que es un método muy seguro, y no requerirá de una administración adicional, por ser el sistema estándar de autenticación de Windows 2000 y 2003.
Hay que tener en cuenta que IPsec

Contenidos recomendados...

Comentar
Para comentar, es necesario iniciar sesión
Se muestran 0 comentarios
X

Uso de cookies

Esta web utiliza cookies técnicas, de personalización y análisis, propias y de terceros, para facilitarle la navegación de forma anónima y analizar estadísticas del uso de la web. Consideramos que si continúa navegando, acepta su uso. Obtener más información