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. 

 

Fuente: http://www.securitybydefault.com/2011/10/como-disenar-una-politica-de.html