CMO DISEAR UNA POLTICA DE

CORTAFUEGOS
Autor: Lorenzo Martnez 18 octubre 2011 [ 6:58 ] 26 comentarios

Aunque he de confesar que llevaba tiempo pensando

en escribir un artculo con este ttulo, ha sido a raz
de los comentarios que nuestros lectores dejaron en
la encuesta que realizamos para conocer los
intereses sobre los posts que os gustara leer en
SbD, lo que me ha impulsado a hacerlo ahora.

Muchas son las veces que me ha tocado analizar

polticas de cortafuegos de clientes con problemas,
en los que he tardado ms en hacerme un esquema
mental de cmo es la topologa de la red e imaginar
en qu tienda ha comprado el criterio quien lo haya
diseado, que en dar realmente con el fallo de
configuracin.

Procesos tan vitales como aplicar una poltica de cortafuegos partiendo de una base ordenada, as como
seguir unas buenas prcticas a la hora de hacer modificaciones, hacen que la poltica de seguridad sea ms
legible a la hora de entenderla, as como ms 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 clster) que segmenta de forma correcta
las redes que la organizacin desea separar. En este ejemplo, y como dicen los libros de matemticas:
"Sea un cortafuegos con cuatro redes diferentes: Una LAN, una DMZ de servicios pblicos, una red DMZ
de servicios privados (o accesibles slo 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 definicin. Si un
paquete/conexin/sesin (dependiendo del cortafuegos) hace match con una regla, no se sigue
procesando por las siguientes.

La regla 1 a definir en una poltica de cortafuegos que vamos a administrar de forma remota, es
precisamente aadir una regla para permitirnos el acceso a los servicios de administracin del
propio cortafuegos, desde las direcciones IP de administracin (sea SSH, HTTPS o el servicio
cliente/servidor que corresponda). Ni sabis la de veces que me habr autodenegado el servicio al aplicar
una poltica de seguridad sin tener en cuenta esto, y la de paseos al CPD que me he pegado a modificar
la poltica por consola o puerto serie.

Una vez definida la regla que permite la administracin remota, habr que crear la regla 2, que
precisamente niega el acceso a los servicios de administracin a TODAS las direcciones IP. Como las
reglas se procesan de arriba a abajo, si la peticin viene de una direccin 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 administracin 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 ms eficiente posible, hay que pensar qu conviene ms. Antiguamente, con
dispositivos hardware limitados de recursos, haba que tener en cuenta que los servicios ms
prioritarios a ofrecer (pensad en un servicio web o alguno en tiempo real o streaming), deban ir
procesados al principiopara dar una mejor satisfaccin de usuario. Otra filosofa es poner al principio
las reglas ms utilizadas(trfico web saliente o de correo, por ejemplo), dejando en ltimos lugares
aquellos servicios que se usan menos. En este caso, por estadstica, un mayor porcentaje del trfico se
procesar antes. En dispositivos con una base de reglas a procesar "grande" o "muy grande" con mucho
trfico, 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 tenis en cmo, antiguamente, un programador se preocupaba de optimizar el nmero 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
organizacin. Lo ms normal ser dar acceso desde el Internet a las mquinas de la DMZ de servicios
pblicos. El orden a seguir es de mayor a menor prioridad, y de mayor a menor necesidad de "Tiempo
Real". Por cada mquina (o grupo de mquinas) que dan un servicio habr que crear una regla con
los servicios a publicar. Yo sugerira el siguiente orden (quitad aquellos servicios que la organizacin 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, publicara hacia Internet
servicios de una organizacin como SSH, VNC y/o Terminal Server, pero en caso que se me
requiera y, siempre y cuando se haga desde un nmero finito de direcciones IP, lo hara 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 pblicos, habr que definir, al final
de esa seccin, 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 mquinas existentes, de manera que si un da alguien sin avisar pincha una mquina nueva,
queda correctamente filtrado.

Si es necesario que desde la DMZ pblica se acceda a servicios de la red DMZ privada (tpico 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 pblica por ejemplo), ser ahora cuando haya que crear dichos
permisos. Importante es que se creen reglas especficas de mquinas origen de la DMZ pblica a
mquinas destino de la DMZ privada, exclusivamente a los servicios necesarios. Una vez
terminada esa seccin, habr que definir una regla que prohiba acceso a cualquier servicio desde la red
DMZ pblica completa a la red DMZ privada tambin completa. Si nos compromenten una mquina en la
DMZ pblica, slo podrn acceder a algunas mquinas a algunos servicios de la DMZ privada no
habiendo "barra libre". Habr que tener en cuenta tambin qu servicios se permiten desde las redes DMZ
privada y pblica hacia Internet, hacia la LAN y desde la privada hacia la pblica. Permitimos lo necesario
explcitamente y negamos todo lo dems, evitando as, en la medida de lo posible canales de envo de
shell inversas a travs de servicios salientes innecesarios.

Las siguientes reglas a crear, por orden de importancia, seran las que permiten accesos desde la red
interna LAN a la DMZ privada y a la red DMZ pblica. 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 ms especfica, no slo 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 dems a estas redes.

Finalmente habr que definir las reglas de trfico permitido desde la LAN hacia Internet. Al final de la
seccin, otra regla que prohiba todo lo no estrictamente permitido anteriormente.

Al final del todo, es tpico y recomendable crear una regla llamada "Cleanup rule" o regla de
limpieza que prohiba el trfico 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 trfico que pase por aqu.

Hasta ahora, slo he hablado de cmo definir reglas y qu permitir y qu negar. Sin embargo, me gustara
hacer un apunte a la hora de loggear o dejar un registro de aplicacin de las reglas segn el trfico
procesado.Los logs son slo 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 dejarn ver el
bosque". Sin embargo, yo recomiendo loggear prcticamente todo lo que podamos que no sea
 absolutamente innecesario, como trfico de broadcast, multicast, Netbios, DHCP, ARP, etc,.. que el
firewall procese. Para ello, y si es un trfico que entra por las reglas de prohibicin de trfico, recomiendo
siempre crear una regla previa a esa, con las IPs de broadcast de la red o de broadcast genrico
(255.255.255.255) en el destino, denegando el trfico y marcando la casilla de NO Loggear el trfico.

Si os dais cuenta, al principio del artculo he dicho cul es la regla 1 a definir en el cortafuegos. Sin
embargo, en la mayora de los firewalls, existe un grupo de primeras reglas a procesar previa a la regla
1. Son las que se llaman reglas implcitas o "Regla 0", que suelen permitir o denegar "de fbrica"
accesos a servicios de administracin, o aquellos proporcionados por la propia mquina, como VPNs
IPSEC/SSL/PPTP, DHCP, etc,...

Una parte muy importante en la definicin de reglas es el rellenar el campo "Comentarios" que va al
final de cada regla en casi todas las GUIs y que permite aadir una descripcin para indicar qu hace
concretamente dicha regla. Una vez ms: documentacin!

Una buena prctica despus de definir una poltica de reglas es auditar desde las diferentes redes,
los accesos hacia las dems, comprobando que la poltica est bien definida. Igualmente se
aconseja monitorizar con especial dedicacin los logs producidos, al menos al principio, corrigiendo en
caso contrario la poltica si hemos dejado algo en el tintero.

Por cierto, que quiero agradecer desde aqu a Enrique Martn, mi buen amigo y ex-compaero de SGI, que
me ense las bases y me di estas mismas guas cuando empec a trabajar, implementando y
posteriormente diseando, polticas de seguridad en cortafuegos y otros dispositivos.