18 octubre 2011

Cómo diseñar una política de cortafuegos

Aunque he de confesar que llevaba tiempo pensando en escribir un artículo con este título, ha sido a raíz de los comentarios que nuestros lectores dejaron en la encuesta que realizamos para conocer los intereses sobre los posts que os gustaría leer en SbD, lo que me ha impulsado a hacerlo ahora.

Muchas son las veces que me ha tocado analizar políticas de cortafuegos  de clientes con problemas, en los que he tardado más en hacerme un esquema mental de cómo es la topología de la red e imaginar en qué tienda ha comprado el criterio quien lo haya diseñado, que en dar realmente con el fallo de configuración.

Procesos tan vitales como aplicar una política de cortafuegos partiendo de una base ordenada, así como seguir unas buenas prácticas a la hora de hacer modificaciones, hacen que la política de seguridad sea más legible a la hora de entenderla, así como más eficiente en cuanto al procesamiento de las reglas.

Aquí van pues mis pasos y/o recomendaciones:
  • Suponemos que comenzamos partiendo de un dispositivo (o un clúster) que segmenta de forma correcta las redes que la organización desea separar. En este ejemplo, y como dicen los libros de matemáticas: "Sea un cortafuegos con cuatro redes diferentes: Una LAN, una DMZ de servicios públicos, una red DMZ de servicios privados (o accesibles sólo desde dentro) y la red de salida a Internet".
  • Un cortafuegos es, generalmente, un software implementado en un sistema operativo muy securizado y optimizado para tener un rendimiento óptimo en procesado y filtrado de paquetes, que interpreta las reglas que implementemos en modo Top-Down, es decir, por orden de definición. Si un paquete/conexión/sesión (dependiendo del cortafuegos) hace match con una regla, no se sigue procesando por las siguientes.
  • La regla 1 a definir en una política de cortafuegos que vamos a administrar de forma remota, es precisamente añadir una regla para permitirnos el acceso a los servicios de administración del propio cortafuegos, desde las direcciones IP de administración (sea SSH, HTTPS o el servicio cliente/servidor que corresponda). Ni sabéis la de veces que me habré autodenegado el servicio al aplicar una política de seguridad sin tener en cuenta esto, y la de paseos al CPD que me he pegado a modificar la política por consola o puerto serie.
  • Una vez definida la regla que permite la administración remota, habrá que crear la regla 2, que precisamente niega el acceso a los servicios de administración a TODAS las direcciones IP. Como las reglas se procesan de arriba a abajo, si la petición viene de una dirección IP permitida, entrará por la regla 1 y en caso contrario seguirá por la 2 hasta que haga "matching" en alguna. Si con estas dos reglas se abarca todas las posibles conexiones a la administración del equipo, siempre entrará por una de ellas. Esta regla es lo que se conoce como la "Stealth Rule"
  • A partir de aquí, para ser lo más eficiente posible, hay que pensar qué conviene más. Antiguamente, con dispositivos hardware limitados de recursos, había que tener en cuenta que los servicios más prioritarios a ofrecer (pensad en un servicio web o alguno en tiempo real o streaming), debían ir procesados al principio para dar una mejor satisfacción de usuario. Otra filosofía es poner al principio las reglas más utilizadas (tráfico web saliente o de correo, por ejemplo), dejando en últimos lugares aquellos servicios que se usan menos. En este caso, por estadística, un mayor porcentaje del tráfico se procesará antes. En dispositivos con una base de reglas a procesar "grande" o "muy grande" con mucho tráfico, el tener en cuenta este tipo de consideraciones, se nota en la carga del sistema. Actualmente, y dado los equipos hardware mastodontes de procesamiento que se utilizan, se nota menos. Un buen ejemplo lo tenéis en cómo, antiguamente, un programador se preocupaba de optimizar el número de variables a utilizar, así como la memoria a reservar en cada momento, dando lugar a verdaderas "joyas" con poco consumo de recursos. Ahora mismo, desde un Windows a un navegador se comen toneladas de memoria,…
  • Mi sugerencia es definir al principio las reglas para permitir los servicios prioritarios o, de negocio, de la organización. Lo más normal será dar acceso desde el Internet a las máquinas de la DMZ de servicios públicos. El orden a seguir es de mayor a menor prioridad, y de mayor a menor necesidad de "Tiempo Real". Por cada máquina (o grupo de máquinas) que dan un servicio habrá que crear una regla con los servicios a publicar. Yo sugeriría el siguiente orden (quitad aquellos servicios que la organización no ofrezca, claro está): HTTP/HTTPS, SSH, VNC, Terminal Server, FTP, VPN, SMTP. Nunca en la vida, a no ser que el cliente me obligara con una pistola en la cabeza, publicaría hacia Internet servicios de una organización como SSH, VNC y/o Terminal Server, pero en caso que se me requiera y, siempre y cuando se haga desde un número finito de direcciones IP, lo haría en ese orden para optimizar la experiencia del usuario que accede, al ser servicios interactivos.
  • Una vez se definen los accesos desde el exterior a la DMZ de servicios públicos, habrá que definir, al final de esa sección, una regla que prohiba el acceso desde Internet a cualquier servicio de dicha red. Es mejor prohibir accesos a la red completa, que comprenda todas las IPs de esa red, en vez de negar solo a las IPs de las máquinas existentes, de manera que si un día alguien sin avisar pincha una máquina nueva, queda correctamente filtrado.  
  • Si es necesario que desde la DMZ pública se acceda a servicios de la red DMZ privada (típico acceso a Sistema Gestor de Base de Datos, servidor de aplicaciones o accesos a servidor de correo con sus buzones desde un Mail Relay en la DMZ pública por ejemplo), será ahora cuando haya que crear dichos permisos. Importante es que se creen reglas específicas de máquinas origen de la DMZ pública a máquinas destino de la DMZ privada, exclusivamente a los servicios necesarios. Una vez terminada esa sección, habrá que definir una regla que prohiba acceso a cualquier servicio desde la red DMZ pública completa a la red DMZ privada también completa. Si nos compromenten una máquina en la DMZ pública, sólo podrán acceder a algunas máquinas a algunos servicios de la DMZ privada… no habiendo "barra libre". Habrá que tener en cuenta también qué servicios se permiten desde las redes DMZ privada y pública hacia Internet, hacia la LAN y desde la privada hacia la pública. Permitimos lo necesario explícitamente y negamos todo lo demás, evitando así, en la medida de lo posible canales de envío de shell inversas a través de servicios salientes innecesarios.
  • Las siguientes reglas a crear, por orden de importancia, serían las que permiten accesos desde la red interna LAN a la DMZ privada y a la red DMZ pública. Habrá que aplicar los mismos principios que antes, distinguiendo en este caso por redes origen (a no ser que el cortafuegos permita identificar a los usuarios de una forma más específica, no sólo por la IP origen, que en cualquier caso se puede cambiar para obtener mayores privilegios de acceso) para permitir lo justo y necesario a las DMZ, prohibiendo en una última regla todo lo demás a estas redes.
  • Finalmente habrá que definir las reglas de tráfico permitido desde la LAN hacia Internet. Al final de la sección, otra regla que prohiba todo lo no estrictamente permitido anteriormente.
  • Al final del todo, es típico y recomendable crear una regla llamada "Cleanup rule" o regla de limpieza que prohiba el tráfico desde Cualquier sitio hacia Cualquier sitio a Cualquier servicio. Es importante puesto que si hemos olvidado definir alguna de las reglas parciales de fitlrado entre redes, habrá tráfico que pase por aquí.
  • Hasta ahora, sólo he hablado de cómo definir reglas y qué permitir y qué negar. Sin embargo, me gustaría hacer un apunte a la hora de loggear o dejar un registro de aplicación de las reglas según el tráfico procesado. Los logs son sólo útiles si puedes leerlos y seguirlos. Si loggeamos TODO no habrá manera de monitorizar qué esta pasando en un momento dado, porque "los árboles no nos dejarán ver el bosque". Sin embargo, yo recomiendo loggear prácticamente todo lo que podamos que no sea absolutamente innecesario, como tráfico de broadcast, multicast, Netbios, DHCP, ARP, etc,.. que el firewall procese. Para ello, y si es un tráfico que entra por las reglas de prohibición de tráfico, recomiendo siempre crear una regla previa a esa, con las IPs de broadcast de la red o de broadcast genérico (255.255.255.255) en el destino, denegando el tráfico y marcando la casilla de NO Loggear el tráfico.
  • Si os dais cuenta, al principio del artículo he dicho cuál es la regla 1 a definir en el cortafuegos. Sin embargo, en la mayoría de los firewalls, existe un grupo de primeras reglas a procesar previa a la regla 1. Son las que se llaman reglas implícitas o "Regla 0", que suelen permitir o denegar "de fábrica" accesos a servicios de administración, o aquellos proporcionados por la propia máquina, como VPNs IPSEC/SSL/PPTP, DHCP, etc,...
  • Una parte muy importante en la definición de reglas es el rellenar el campo "Comentarios" que va al final de cada regla en casi todas las GUIs y que permite añadir una descripción para indicar qué hace concretamente dicha regla. Una vez más: documentación!
  • Una buena práctica después de definir una política de reglas es auditar desde las diferentes redes, los accesos hacia las demás, comprobando que la política está bien definida. Igualmente se aconseja monitorizar con especial dedicación los logs producidos, al menos al principio, corrigiendo en caso contrario la política si hemos dejado algo en el tintero.
Por cierto, que quiero agradecer desde aquí a Enrique Martín, mi buen amigo y ex-compañero de SGI,  que me enseñó las bases y me dió estas mismas guías cuando empecé a trabajar, implementando y posteriormente diseñando, políticas de seguridad en cortafuegos y otros dispositivos.

13 comments :

Pptxo dijo...

Importante para el mantenimiento y la gestion de cambios: RuleID unico.
El ruleset esta vivo y lo que antes era la regla 9 puede que ahora sea la 13. Y llegaran peticiones de cambio solicitando, por ejemplo, incluir una IP adicional en el FROM de la regla 11 :-/ Donde lo metemos?

Algunos FW lo traen de serie (Juniper por ej) pero la mayoria no. En ese caso, meter un ID de regla unico como inicio en el campo de comentarios, de manera que se pueda referenciar sin ambiguedades.

En DMZ publicas, recomendaria un disenyo de 2/3 niveles: con proxies inversos seguidos de front-end. Esto, mejor lo comentamos con unas cervezas :-)

Rsantamaria dijo...

Hola buen articulo, creo que faltó hablar un poco más de las políticas asociadas a las VPN

Lorenzo_Martinez dijo...

RuleID único es una buena idea. Sin embargo, además yo requeriría a quien pida un cambio, que me envíen con todo detalle "qué" necesitan realmente. Me explico: No es lo mismo lo que se lee en foros genéricos de forma: "lo que tienes que hacer es abrir los puertos 4661 y 4662 en el router....", que decir: "Necesito publicar a Internet los puertos TCP y UDP 4661 y 4662 (Emule) de la IP privada 192.168.1.4. La dirección IP pública a utilizar será la propia del router mediante NAT entrante, con los mismos puertos 4661 y 4662"... El administrador del firewall, cuando lee esto, entiende lo que quiere la gente... en el ejemplo anterior, sólo lo imagina :)

Curioso pero me ha pasado algo parecido esta mañana en un cliente con un NAT entrante que he tenido que "dar mascado" al administrador de los firewalls para que lo implementara bien... al cuarto intento!

Lorenzo_Martinez dijo...

Me lo apunto para otro posible post! (Ya me han sugerido en Twitter hacer algo similar para WAF)
Muchas gracias!

Alguien dijo...

Hola, excelente post. quizá esta pregunta sea un offtopic... pero ¿Cómo filtro trafico saliente TCP/UDP hacia el puerto 53 que no es necesariamente DNS? Osea el firewall solo dice permitido o no permitido pero... no se pone a revisar el contenido real.

Gracias.

Croulder dijo...

"Alguien" , mira si tu firewall tiene control de aplicaciones.

Un saludo.

Lorenzo_Martinez dijo...

Buena pregunta! En realidad en este artículo lo único que se ha hecho ha sido explicar cómo diseñar una política de cortafuegos. Lo que tú pides va más allá y depende de la inspección de protocolos que haga el propio firewall. Desgraciadamente, no todos los dispositivos son capaces de hacer este tipo de inspección, para comprobar que por el TCP 53 por ejemplo no estés encapsulando otra cosa que no sea DNS, como por ejemplo SSH...

Esialam dijo...

Muy interesante el articulo. Como información a ampliar me gustaria saber que firewalls del mercado ofrecen mejores prestaciones y opciones de configuración.

Jorge dijo...

Muy buen artículo.
Muy claro y organizado.

Alguien dijo...

Gracias por la respuesta, soy fanático del software libre xD y bueno estaba buscando alguna alternativa libre que pudiera usar para implementar eso... aunque solo con fines didacticos.

Lorenzo_Martinez dijo...

Gracias... Firewalls en el mercado hay muchos: libres, comerciales puros y "comerciales basados en libres". Hace poco hice un análisis de una GUI para varios firewalls (sobre todo libres, como IPTables, PF, IPFW, ipfilter,...) y otros como Cisco o incluso ACLs en algunos switches/routers de HP. La GUI era Fwbuilder [http://www.securitybydefault.com/2011/09/firewall-builder-la-gui-para-tu.html]
Cortafuegos comerciales hay muchos: Checkpoint, Fortinet, Juniper, Stonegate, NetASQ, Watchguard, Sonicwall... De todos estos, a mí personalmente me resulta bastante interesante NetASQ en cuanto a calidad/precio/grado_de_completitud. Es un UTM que permite hacer de todo desde PYMES hasta grandes empresas y el coste no es muy elevado.

Madrikeka dijo...

Me ha venido que ni pintado el post.
En breve tendré unos cambios en la red nos y tocará montarlo todo.

Un saludo.

tepes dijo...

Muy interesante el artículo. Y gracias por tener en cuenta nuestros comentarios :).

Saludos!!