Grupo Linuxero del Bajío

Instalación de un firewall

Víctor Manuel Jáquez Leal

Una institución educativa me pidió que le instalara un firewallpara una de sus enlaces a Internet, de 2Mbit.

La institución tiene asignadas en este momento 4 redes clase C (1024números IP posibles) y, por otro lado, gran parte de la comunicación dentro del campus es con fibra óptica, conectando a casi 700computadoras (la mayoría atrás de NAT), además de algunos enlaces víaDS0 e inalámbricos para otros departamentos e instituciones fuera del campus. Es decir, dicha red es grande y sin embargo ha crecido demanera 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 éstos. 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 detener en cuenta las necesidades de cada usuario del sistema, sin embargo podemos delinear una serie de principios que pueden orientarnos:

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 firewalling 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 paqueteatraviesa 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 IPconsiste 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 o 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, IPSpoofing, etc.).

IMPLEMENTACIÓN

La máquina destinada para la construcción del firewall tiene las siguientes características:

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 otra salida por 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

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á lareglas 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 candidatosfinales fueron:

Debido a la mejor documentación que ofrecía Shorewall, nos decidimos por utilizar éste.

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

Configuración del Shorewall

El shorewall define zonas. Cada zona tiene un nombre de máximo 5 caracteres como identificador. En nuestro caso solo definimos 2zonas:

Las zonas básicamente están representadas físicamente como interfaces de red, aunque en otros casos pueden ser subredes dentro de toda nuestra o también servidores concretos.

El 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 anuestras dos NICs:

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 usados por los escaners de puertos.

blacklist Implementa listas negras de IP que no queremos que pasen por lainterfaz.

norfc1918 La interfaz no recibirá ningún paquete cuya fuente este 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.

ClienteServidorPolítica
fwallACEPTAR
locnetACEPTAR
netallBLOQUEAR
allallRECHAZAR

Para parafrasear la tabla superior, podemos decir que:

  1. Nuestro firewall podrá solicitar servicios a todos.
  2. Nuestra red local solicitar servicios a todos.
  3. Internet NO podrá solicitar servicios a nuestra red.
  4. 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:

PuertoProtocoloDescripción
113TCPidentificación
135TCPautenticación Win2K
137UDPnetbios-ns
138UDPnetbios-dgm
139UDPnetbios-ssn
445UDPautenticación Win2K
1434TCP/UDPMS-SQL Server
1214TCP/UDPKazaa

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 fueque, al pasar el tiempo, las conexiones rechazadas iríandisminuyendo. No obstante, en el tiempo monitoreado no ha sido así,se ha comportado más bien sin un tendencia definida.

Por otro lado hay que hacer notar que el número de quejas por partede los usuarios por la implementación del firewall fue mínimo, lo cuales 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 ésta tarea. Podemos afirmar que en estos momentos el monitoreo de la red no esta 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 dela red.

BIBLIOGRAFÍA