Instalación de un Firewall
Memoria de la instalación de un firewall para una institución educativa.
Este documento está bajo la licencia GPL.
Antecedentes
Una institución educativa me pidió que le instalara un firewall para uno de sus enlaces a Internet, de 2Mbit.
La institución tiene asignadas en este momento 4 redes clase C (1024 números IP posibles) y, por otro lado, gran parte de la comunicación dentro del campus es con fibra óptica, conectando a casi 700 computadoras (la mayoría atrás de NAT), además de algunos enlaces vía DS0 e inalámbricos para otros departamentos e instituciones fuera del campus. Es decir, dicha red es grande y, sin embargo, ha crecido de manera desordenada y con poca planeación.
Marco Teórico
Seguridad y Mecanismos de Protección
Formalmente hablando la seguridad en sistemas de cómputo es una medida de confianza en la integridad de la información manejada por estos. Resulta de gran relevancia, ya que un sistema de cómputo carecería de sentido si la integridad y la confidencialidad de la información que procesa fuera violada.
La seguridad es implementada mediante mecanismos de protección, que controlan el acceso a los recursos de cómputo ofrecidos y a los mismos usuarios.
Controlando el acceso a los recursos de cómputo prevenimos el mal uso del sistema, ya sea de manera accidental y al menos, hasta cierto grado, el abuso intencional.
Elaborar un diseño de seguridad es laborioso, ya que se deben de tener en cuenta las necesidades de cada usuario del sistema, sin embargo, podemos delinear una serie de principios que pueden orientarnos:
- El diseño debe de ser público. Suponer el que intruso no sabrá cómo funciona el sistema sólo sirve para despistar a los diseñadores.
- Lo que no está explícitamente permitido está prohibido.
- Cada operación a realizar debe ser autorizada.
- Darse el menor privilegio posible a cada proceso.
- El mecanismo de protección debe ser simple y uniforme (Keep It Simple, Stupid!).
- El esquema elegido debe ser psicológicamente aceptable para el usuario.
La consecuencia de la correcta implementación de mecanismos de seguridad en un sistema de cómputo es el mejoramiento del desempeño del mismo, ya que nadie se apropiará de un recurso por más tiempo del asignado, además de la verificación de las condiciones de ese uso.
¿Qué es un firewall?
Un firewall es un sistema o grupo de sistemas que impone una política de control de acceso entre dos redes de computadoras. La manera actual de cómo esto es logrado varía ampliamente, pero en principio, el firewall puede ser visualizado como un par de mecanismos: uno que bloquea el tráfico, y otro que permite el tráfico.
Es importante reconocer que un firewall implementa una política de acceso. Si no tenemos una buena idea de qué tipo de acceso permitiremos, un firewall realmente no nos será de utilidad.
¿Qué es un Stateful Firewall?
Un stateful firewall es un firewall que provee de herramientas como el seguimiento y control del flujo de una sesión de datos dentro y fuera de la red. La información concerniente a cada conexión es almacenada en memoria. Cuando un paquete cruza el filtro, la decisión de desechar o enviar es realizada usando la información de conexión almacenada en memoria (p. ej. dirección del destino, número de puerto, información de la secuencia TCP y banderas adicionales).
Ventajas de un Stateful Firewall
En lugar de abrir puertos de red permanentemente para ciertos protocolos que solicitan puertos arbitrarios, este nuevo tipo de firewalls solo abrirán estos puertos durante el tiempo suficiente para que el paquete pase. Esto disminuye drásticamente la oportunidad de un cracker para introducir código destructivo a la red.
Además, permite definir un límite de tasa de conexión para defenderse en contra de ataques de negación de servicio (DoS), tal como la inundación de paquetes SYN.
Para más información acerca de este tema vea Anatomía de un Stateful Firewall.
¿Qué es netfilter/iptables?
El proyecto netfilter/iptables es el subsistema de firewall de Linux 2.4.x/2.5.x. Ofrece la funcionalidad de filtrado de paquetes (ya sea stateless o stateful), todos los diferentes tipos de NAT (Network Address Translation), la manipulación de paquetes (modificar TOS -Type of Service- y encabezados) y también facilita el trabajo al subsistema de QoS (Quality of Service) de Linux.
netfilter es un conjunto de ganchos dentro de la pila de red del kernel Linux 2.4.x, que le permite a los módulos del kernel registrar funciones callback que se mandan llamar cada vez que un paquete atraviesa alguno de esos ganchos.
iptables es una estructura genérica tipo tabla para la definición de reglas de firewall. Cada regla dentro de una tabla IP consiste en un número de clasificadores y una acción asociada.
Objetivo
Antes, con el fin de limitar el alcance de este proyecto, diremos cuáles no son los objetivos:
Podríamos prescindir de un firewall en cualquier red si cada computadora conectada a ella fuera meticulosamente administrada. Si todo el software instalado es constantemente auditado y actualizado; si cada usuario es una persona capacitada y responsable; si se conocieran exactamente los fines de la red, los servicios que ofrecerá y utilizará, y se configura cada computadora para esto, no habría necesidad alguna de firewalls.
Sin embargo, ya hemos establecido que la red es grande, y cumplir con las anteriores condiciones resulta en este momento imposible, por razones económicas, materiales y humanas (errare humanum est).
Jamás se han propuesto políticas de acceso, no se auditan las computadoras conectadas a la red, ni se conocen a ciencia cierta todos los servicios requeridos u ofrecidos a la red por los usuarios. Y querer lograr esto en un corto plazo es demasiado ambicioso con los recursos permitidos.
Por tanto, nuestro objetivo no fue, de ninguna manera, volver a la red en una red segura o correctamente diseñada y administrada. Nos limitamos a plantearnos lo siguiente:
> Contar con un punto centralizado para el monitoreo y control del tráfico entre > la red y la salida a Internet, estableciendo las políticas de acceso más > comunes (Stateful firewalling, bloqueado del RFC 1918 >, IP Spoofing >, etc.).
Pero el trabajo no termina ahí, entre los próximos objetivos se cuenta con la instalación de otro firewall a la salida por Uninet; colocar un proxy para controlar y monitoreará el tráfico por el protocolo HTTP; asignar QoS (limitar el ancho de banda) a las distintas redes del campus, agrupadas en departamentos; configurar el servicio de correo electrónico para endurecer las medidas contra el abuso del mismo.
Implementación
La máquina destinada para la construcción del firewall tiene las siguientes características:
- Pentium III a 500 MHz.
- 128 Mb RAM.
- 5 Gb IDE HD.
- Tarjeta de red Intel Ethernet Pro 100.
- Tarjeta de red 3Comp 3c905C-TX Fast Etherlink.
Desde un inicio hubo la disyuntiva si instalar OpenBSD o alguna distribución de GNU/Linux. Se decantó por GNU/Linux por la razón de que nuestra experiencia en OpenBSD aún es limitada.
Sin embargo, estamos conscientes de sus ventajas con respecto a la seguridad, por lo que en un futuro próximo se migrará. Por lo pronto, el nuevo firewall para la salida por Uninet se esta implementando en OpenBSD. Después hubo que elegir alguna distribución de GNU/Linux. La decisión también fue rápida: Debian Woody, que a nuestro juicio, ofrece un mejor aseguramiento de calidad en sus paquetes, así como un esquema de actualización sencillo y eficiente (apt-get), apego a los estándares, solicita pocos recursos, da un nivel aceptable de seguridad por defecto, entre otros.
Instalación del software
- Instalación de Debian GNU/Linux por CD.
- Solo se instaló el software base y nada más. Ningún otro paquete fue agregado instalación. Estos se fueron instalando con respecto se fueron necesitando durante la configuración y puesta a punto.
- Se actualizó el sistema.
- Se siguieron muchas de las recomendaciones expuestas en Securing Debian Manual, TrinityOS: A Guide to configuring your Linux server for performance, security, and managability y Securing & Optimizing Linux: The Ultimate Solution.
- Para que tuviéramos el acceso a QoS se recompiló el kernel, utilizando las fuentes ofrecidas por Debian (2.4.18). Actualización: Se puso el kernel stock 2.4.21 por el reciente agujero de seguridad.
El firewall
La generación de reglas de firewall con iptables, en comparación con otros métodos para expresar estas reglas, tiene cierto mayor grado de complejidad, por lo cual en el ecosistema del software libre existen múltiples opciones para la generación de reglas de firewall para iptables de manera más o menos automática. Uno define, mediante archivos de configuración sus necesidades y el programa generará las reglas de iptables necesarias.
Una muestra de estos programas los podemos encontrar en Freshmeat.
Consideramos, por ser la primera vez que implementamos un firewall de tal relevancia, que, en lugar de diseñar nuestras propias reglas, sería mejor algún software que nos abstrajera ese nivel de configuración y poder hacer la implementación más rápido. Sin embargo, no escapa de nuestra ambición, que a partir de esas reglas, nosotros extenderlas a nuestras necesidades.
Después de analizar diferentes opciones, nuestros candidatos finales fueron:
Debido a la mejor documentación que ofrecía Shorewall, nos decidimos por utilizar este.
Por otro lado, pusimos énfasis en instalar algún servicio que llevara el monitoreo e hiciera reportes del uso de firewall. Debian ofrece el fwlogwatch, así fue nuestra opción inmediata.
Se configuró para que todas las noches genere un reporte de los paquetes rechazados por firewall en formato HTML.
Políticas de acceso
- Bloquear RFC1918
- Stateful firewalling
- Bloqueo de números IP específicos
- Bloqueo de puertos específicos
- Bloqueo de paquetes ICMP
- Bloqueo de escaneo de puertos
- Bloqueo de inundación de paquetes SYN
- Bloqueo de paquetes inválidos
Configuración del Shorewall
En la siguiente gráfica mostramos la estructura general de la red.
Shorewall define zonas. Cada zona tiene un nombre de máximo 5 caracteres como identificador. En nuestro caso solo definimos 2 zonas:
- net — Que identifica a Internet
- loc — Que identifica a todas la redes dentro de la red a proteger
Las zonas básicamente están representadas físicamente como interfaces de red, aunque en otros casos pueden ser subredes dentro de la nuestra o también servidores concretos.
shorewall define zonas por defecto tal como fw que refiere al firewall en sí y all que identifica a cualquier zona definida.
Así que el siguiente paso es mapear las zonas definidas a nuestras interfaces. En nuestro caso las dos zonas definidas corresponden a nuestras dos NICs:
- eth0 → net
- eth1 → loc
En este paso también definimos algunas características que le daremos a las interfaces:
eth0
- tcpflags
Esta opción causa que el Shorewall haga verificaciones de sanidad en los encabezados de los paquetes TCP que arriban a la interfase. Esto incluye combinaciones usadas por los escáneres de puertos.
- blacklist
Implementa listas negras de IP que no queremos que pasen por la interfaz.
- norfc1918
La interfaz no recibirá ningún paquete cuya fuente esté en los rangos reservados por el RFC 1918.
- routefilter
Activa el sistema de antispoofing del kernel en la interfaz.
- dropunclean
Bloquea paquetes inválidos o manipulados deliberadamente.
Paso siguiente es definir las políticas de acceso entre las zonas. Es decir, la acción por defecto cuando pasamos de una zona a otra, definiendo como cliente la zona que solicita un servicio y como servidor la zona que responde a la solicitud.
Políticas de acceso
Cliente | Servidor | Política |
---|---|---|
fw | all | ACEPTAR |
loc | net | ACEPTAR |
net | all | BLOQUEAR |
all | all | RECHAZAR |
Para parafrasear la tabla superior, podemos decir que:
- Nuestro firewall podrá solicitar servicios a todos.
- Nuestra red local solicitar servicios a todos.
- Internet NO podrá solicitar servicios a nuestra red.
- Lo demás será rechazado.
Ahora, una vez declarada nuestras políticas, podemos definir las reglas, que serían las excepciones a las políticas.
Supongamos que tenemos un servidor de correo electrónico. Tendremos activos el puerto SMTP (23), POP3 (110) e IMAP2 (143). Ya que por política, ningún host de Internet podrá comunicarse con nuestra red, debemos definir una excepción para nuestro servidor de correo:
ACEPTAR net loc:xxx.xxx.xxx.xxx tcp smtp,pop3,imap2
Y así sucesivamente con cada servidor.
Para finalizar, agregaremos una serie de reglas comunes, de comportamientos que deseamos aceptar o bloquear por defecto, sin importar las políticas o reglas anteriormente definidas.
Los puertos que bloquearemos son:
Puertos bloqueados por defecto
Puerto | Protocolo | Descripción |
---|---|---|
113 | TCP | identificación |
135 | TCP | autenticación Win2K |
137 | UDP | netbios-ns |
138 | UDP | netbios-dgm |
139 | UDP | netbios-ssn |
445 | UDP | autenticación Win2K |
1434 | TCP/UDP | MS-SQL Server |
1214 | TCP/UDP | Kazaa |
Resultados
Con la implementación de este primer firewall hemos notado que el tráfico que sale de la red al mundo se redujo drásticamente, aunque el ancho de banda que recibe la red del mundo se mantiene constante. Esto de por sí es una ventaja, ya el ancho de banda es el principal valor de una red, su consumo debe ser cuidadosamente vigilado. Sin embargo, hay que hacer notar el poco control que tenemos sobre el tráfico que llega a nuestra red, por lo que uno de los puntos posteriores será delinear políticas para esto.
Gracias al generador de reportes fwlogwatch podemos analizar el tráfico que fue rechazado, ya que no cumplía con las características expuestas. La siguiente gráfica muestra el número de conexiones rechazadas diariamente.
Una de nuestras principales hipótesis al comenzar este trabajo fue que, al pasar el tiempo, las conexiones rechazadas irían disminuyendo. No obstante, en el tiempo monitoreado no ha sido así, se ha comportado más bien sin una tendencia definida.
Por otro lado, hay que hacer notar que el número de quejas por parte de los usuarios por la implementación del firewall fue mínimo, lo cual es todo éxito, cuanto al objetivo de hacer una migración transparente.
Conclusiones
Los firewalls sí sirven, pero se requieren delimitar claramente las políticas de acceso para que realmente cumpla con su objetivo, aunque existen políticas recomendables y genéricas que sirven para protegernos de los ataques más comunes.
Los firewalls por sí mismos no son la solución a la implementación de seguridad en una red. La seguridad no es un concepto estático, una red no es segura una vez y ya lo será para siempre, se requiere de una vigilancia continua, y para ello requerimos de herramientas que nos faciliten esta tarea. Podemos afirmar que en estos momentos el monitoreo de la red no está al nivel de como debería estar, faltan herramientas y políticas.
Faltan además otros mecanismos que hagan cumplir las políticas de seguridad deseadas, como filtrado de contenido (proxy para HTTP, detectores de Spam, etc.), actualización y censo constante de servidores, control del ancho de banda asignado a cada segmento de la red, mecanismos para el evitado y recuperación de virus, gusanos, troyanos, etc.
El trabajo faltante es aún mucho. Sin embargo, consideramos este esfuerzo un buen comienzo y un paso hacia un mejor funcionamiento de la red.
Bibliografía
- Internet Firewalls: Frenquently Asked Questions
- Sistemas Operativos: Diseño e Implementación. Andrew S. Tanenbaum. Prentice Hall.
- Linux Comes of Age with Stateful Firewalling
- netfilter/iptables Home