Seguridad en Unix y redes - Firewall-1

Figura 16.1: Ubicación del Inspection Module dentro de la pila de protocolos OSI.

Firewall-1 es capaz de analizar la información de una trama en cada uno de los siete niveles OSI y a la vez analizar información de estado registrada de anteriores comunicaciones; el cortafuegos entiende la estructura de los diferentes protocolos TCP/IP - incluso de los ubicados en la capa de aplicación -, de forma que el Inspection Module extrae la información relevante de cada paquete para construir tablas dinámicas que se actualizan constantemente, tablas que el firewall utiliza para analizar comunicaciones posteriores. En el módulo de inspección se implantan las políticas de seguridad definidas en cada organización mediante un sencillo lenguaje denominado INSPECT, también diseñado por Check Point Software Technologies; desde un cómodo interfaz se genera un script en este lenguaje, que se compila y se inserta en el Inspection Module.

La gran potencia y flexibilidad de Firewall-1 hacen imposible que se aquí se puedan explicar con el suficiente nivel de detalle todas sus características; para más información, excelentes lecturas pueden ser [GB99] o (más reciente) [WA02]. También la documentación que acompaña al producto, y la disponible en el servidor web de Check Point Software Technologies, es de gran ayuda para cualquier administrador que utilice este cortafuegos en su red.

Arquitectura

Firewall-1 está basado en dos módulos independientes: el de gestión (o control) y el de cortafuegos. El primero de ellos está formado por el gestor gráfico de políticas (incluyendo el visor de registros) y el servidor de gestión, típicamente un demonio (fwm) que se ejecuta en una máquina Unix. El gestor gráfico puede ser un cliente Unix (con X/Motif) o Windows 9x/NT; es triste que a estas alturas no exista un cliente gráfico para Linux, encontrándose únicamente para otros Unices, y que además el cliente X/Motif contenga errores y sea bastante ineficiente, lo que motiva que se tienda a utilizar clientes Windows para gestionar los cortafuegos. En cualquier caso, el gestor gráfico puede ejecutarse en la misma máquina que el servidor de gestión o en una diferente, mediante un esquema cliente/servidor. Este gestor no hace más que presentar de una forma cómoda al administrador del cortafuegos la información generada por el servidor de gestión (el demonio fwm), que es el verdadero `corazón' de la gestión del firewall y que permite administrar diferentes sistemas con módulo de cortafuegos (en castellano plano, diferentes cortafuegos) desde una misma estación de control.

Por otra parte, el módulo de cortafuegos está formado por el inspection module, los demonios de Firewall-1 y los servidores de seguridad del firewall. El inspection module se instala como ya hemos comentado (figura 16.1) entre el nivel de enlace y el nivel de red, por completo antes de la pila de protocolos TCP/IP, con lo que se asegura que Firewall-1 analiza todos y cada uno de los paquetes que pasan por el sistema. Los demonios del firewall son simples programas con diferentes funciones, como la comunicación con el servidor de gestión o la carga de las reglas definidas para el cortafuegos en el inspection module. Finalmente, los servidores de seguridad son módulos que se invocan cuando así se define en la política (por ejemplo, cuando la acción asociada a una determinada regla es User Authentication), y que realizan tareas de autenticación y seguridad de contenidos; la conexión entre origen y destino se divide en dos, una entre el origen y el servidor de seguridad y otra entre este y el destino.

Instalación

Antes de instalar Firewall-1 en un sistema Unix es muy importante deshabilitar en el núcleo del operativo el IP Forwarding, de forma que todo el reenvío de tramas sea gestionado por el software de cortafuegos (esta opción se define durante la instalación). Esto permite que el reenvío sólo sea posible si el firewall está ejecutándose - es decir, protegiendo nuestra red -, lo que imposibilita que la máquina reenvíe paquetes si Firewall-1 no está activo, algo que como vimos a la hora de hablar de diferentes clones de Unix puede ser problemático para nuestra seguridad.

Teniendo en cuenta la consideración anterior, y asumiendo que en la máquina donde vamos a instalar Firewall-1 no existen problemas ajenos al cortafuegos (conectividad, resolución de nombres, reconocimiento de interfaces de red...), la instalación del software no ofrece ninguna dificultad: simplemente hemos de instalar los paquetes correspondientes con las órdenes habituales de cada Unix (pkgadd en Solaris, swinstall en HP-UX...) o, en algunas versiones del programa, ejecutar la orden fwinstall, que no es más que una instalación seguida de una configuración del cortafuegos equivalente a la que veremos a continuación.

Una vez instalado el firewall hemos de configurarlo; para ello no tenemos más que ejecutar la orden fwconfig (versión 4.0) o cpconfig (versión 4.1), que paso a paso nos guiará a través de la configuración (o reconfiguración, una vez el cortafuegos esté ya funcionando) de Firewall-1:

anita:/# fwconfig
 
 Welcome to VPN-1 & FireWall-1 Configuration Program
 =================================================
 This program will let you re-configure
 your VPN-1 & FireWall-1 configuration.
 
 
 Configuration Options:
 ----------------------
 (1)  Licenses
 (2)  Administrators
 (3)  GUI clients
 (4)  Remote Modules
 (5)  SMTP Server
 (6)  SNMP Extension
 (7)  Groups
 (8)  IP Forwarding
 (9)  Default Filter
 (10) CA Keys
 
 (11) Exit
 
 Enter your choice (1-11) : 11
 
 Thank You...
 anita:/#
 

Como podemos ver, esta herramienta permite realizar tareas como la instalación de licencias, la planificación del software en el arranque de la máquina o la definición de módulos de firewall remotos. Aunque todo es vital para el correcto funcionamiento del cortafuegos, existen dos apartados especialmente importantes para la posterior gestión del firewall: la definición de administradores y la definición de estaciones que actuarán como clientes gráficos; si no definimos al menos un administrador y una estación cliente, no podremos acceder al cortafuegos para gestionarlo (evidentemente, en esta situación no estaría todo perdido, ya que siempre podemos añadir ambos elementos, así como modificar su relación, a posteriori).

El administrador o administradores que definamos serán los encargados de acceder a las políticas del cortafuegos a través del gestor gráfico, únicamente desde las estaciones que hayamos definido como cliente. Podemos añadir elementos a ambas listas (la de administradores y la de estaciones gráficas) ejecutando de nuevo fwconfig o cpconfig, o bien de forma más directa ejecutando la orden fwm (para añadir administradores) y modificando el archivo $FWDIR/conf/gui-clients (para añadir clientes gráficos); este archivo no es más que un fichero de texto donde se listan las direcciones IP (o los nombres DNS) de las máquinas que pueden acceder a gestionar el firewall:

anita:/# cat $FWDIR/conf/gui-clients
 192.168.0.1
 192.168.0.2
 192.168.0.3
 158.42.22.41
 anita:/# fwm -p
 FireWall-1 Remote Manager Users:
 ================================
 toni (Read/Write)
 avh (Read/Write)
 
 Total of 2 users
 anita:/# fwm -a admin -wr
 Password:
 Verify Password:
 User admin added succesfully
 anita:/# fwm -p
 FireWall-1 Remote Manager Users:
 ================================
 toni (Read/Write)
 avh (Read/Write)
 admin (Read Only)
 
 Total of 3 users
 anita:/# fwm -r prova
 User prova removed succesfully
 anita:/#
 

Para acabar con la instalación de Firewall-1 es necesario definir la variable de entorno $FWDIR, que apuntará al directorio /etc/fw/, y añadirla en los scripts de inicio de sesión correspondientes. También es recomendable añadir el directorio $FWDIR/bin/ a nuestro $PATH, ya que ahí se ubican las utilidades de gestión del cortafuegos, y hacer lo mismo con $FWDIR/man/ y la variable $MANPATH, ya que en este directorio se encuentran las páginas de manual del firewall.

Antes de finalizar este punto quizás es necesaria una pequeña advertencia: como Firewall-1 inserta módulos en el núcleo del operativo, es dependiente de la versión del kernel utilizada. Todas las versiones más o menos modernas funcionan correctamente sobre Solaris 2.6 y la última también sobre Solaris 7; no obstante, sobre este último el resto de versiones no funcionan bien, aunque se instalen correctamente. Es posible, y esto lo digo por experiencia, que la máquina no arranque tras instalar el software debido a las modificaciones de los scripts de arranque (concretamente los ubicados en /etc/rcS.d/), que al ser invocados desde /sbin/rcS producen errores que impiden montar correctamente los discos y proseguir el arranque; para solucionar estos problemas, lo más rápido es eliminar cualquier modificación que la instalación de Firewall-1 haya realizado sobre los programas ejecutados al iniciar el sistema.

Gestión

Como cualquier sistema cortafuegos, Firewall-1 permite al usuario definir una política de seguridad formada por reglas, cada una de las cuales se basa principalmente en el origen, destino y servicio de una determinada trama. El conjunto de reglas se examina de arriba hacia abajo, de forma que si una determinada regla hace match con el paquete que se está inspeccionando, se aplica y las que quedan por debajo de ella ni siquiera se examinan; como debería suceder en cualquier sistema cortafuegos, las tramas no explícitamente aceptadas se rechazan.

La gestión de Firewall-1 suele ser completamente gráfica, a través de dos interfaces principales: el de gestión de políticas (fwui) y el visor de logs (fwlv, mostrado en la figura 16.2). En versiones más recientes del firewall ambos se unifican en fwpolicy, basado en X/Motif (los anteriores se basan en OpenLook), más cómodo e intuitivo que sus predecesores. En cualquier caso, siempre tenemos la opción de trabajar en modo texto mediante la orden fw, aunque esta opción no suele ser la habitual entre los administradores de Firewall-1.

Para gestionar el cortafuegos, cada uno de los administradores definidos anteriormente puede conectar desde las estaciones gráficas autorizadas al servidor de gestión (máquina en la que se ha instalado el módulo de gestión de Firewall-1), para lo cual necesita autenticarse mediante su nombre de usuario y su clave; una vez conectado, si su acceso es de lectura y escritura, puede comenzar a trabajar con el cortafuegos. Lo primero que verá será la política del firewall (de hecho, ha conectado con el editor de políticas de Firewall-1); estas políticas no son más que ficheros ubicados en $FWDIR/conf/, con un nombre finalizado en `.W', que se compilan y cargan en los sistemas donde está instalado el módulo de cortafuegos.

Desde el editor gráfico, las políticas se ven como un conjunto de reglas que se examina de arriba a abajo hasta que una de ellas hace match con el paquete que se está analizando (como ya hemos comentado, si ninguna de ellas hace match, el paquete se deniega). Cada una de estas reglas está numerada en función del orden de aplicación, y sus campos principales son los habituales en cualquier cortafuegos: origen, destino, servicio y acción. Además, existen un campo que indica si se ha de registrar la trama (`Track'), otro para determinar dónde se ha de instalar (`Install On'), otro para especificar el tiempo que la regla estará activa (`Time') y finalmente un campo de texto donde se pueden incluir comentarios.

Evidentemente, como sucede en cualquier firewall, tanto el campo origen como el destino pueden ser sistemas concretos o redes completas. En Firewall-1 ambos elementos, así como los servicios, se manejan como objetos: elementos definidos por el administrador e identificados mediante un nombre - en principio algo fácilmente identificable por el mismo -, con una serie de propiedades determinadas. Sin duda, en el caso de los hosts o las redes la propiedad más importante es la dirección IP o la dirección de red con su máscara correspondiente asociadas al objeto; en el caso de los servicios, definidos también por un nombre, la característica más importante es el puerto o rango de puertos asociado al mismo. Por ejemplo, podemos definir el objeto `servidor1', con su IP correspondiente, el objeto DMZ, con su dirección de red y máscara asociada, o el objeto ssh, con su puerto concreto; en todos los casos, el nombre dice mucho más al encargado de gestionar el cortafuegos que una simple IP, dirección de red o número de puerto, lo que facilita enormemente la administración del firewall.

El campo `Action' de cada regla define qué se ha de hacer con una conexión cuando hace match con la regla; al igual que en la mayor parte de cortafuegos del mercado, tres son las acciones principales a tomar: `Accept', si dejamos que la conexión se establezca a través del firewall, `Reject', si la rechazamos, y `Drop', si la rechazamos sin notificarlo al origen. Para las conexiones que no permitimos, esta última suele ser la mejor opción, ya que el paquete se elimina sin ningún tipo de notificación hacia el origen; si utilizáramos `Reject' sí que informaríamos de las conexiones no permitidas, lo que puede ayudar a un atacante a conocer tanto nuestra política de seguridad como la topología de nuestra red.

Por su parte, el campo `Track' de una regla determina una medida a tomar cuando un paquete hace match con la regla en cuestión: ninguna medida (campo vacío), un registro en diferentes formatos (`Short Log', `Long Log' y `Accounting'), una alerta de seguridad, un correo electrónico, un trap SNMP o una acción definida por el usuario (estas cuatro últimas acciones han de ser configuradas por el administrador del cortafuegos). Evidentemente, este campo es muy útil para obtener información acerca de posibles hechos que traten de comprometer nuestra seguridad, tanto en un log habitual como para implantar en el firewall un sistema de detección de intrusos y respuesta automática en tiempo real ([Spi01a]); en el punto 16.1.5 hablaremos con más detalle del sistema de log de Firewall-1.

Una vez que hemos definido una política - un conjunto de reglas - lo más habitual es aplicarla en un sistema con el módulo de cortafuegos de Firewall-1 instalado en él; hemos de recordar que habitualmente trabajamos con un simple editor de políticas, de forma que las modificaciones que realicemos sobre una determinada política (añadir o eliminar reglas, definir nuevos objetos, etc.) no tendrán ningún efecto hasta que esa política se instale en el cortafuegos correspondiente. Para instalar una política no tenemos más que escoger la opción del menú del gestor gráfico adecuada; a partir de ese momento, Firewall-1 verifica que la política escogida es lógica y consistente, genera y compila el código INSPECT (en el punto 16.1.6 hablamos mínimamente de este lenguaje) correspondiente para cada objeto sobre el que vayamos a instalarla, y carga dicho código en el objeto donde se encuentra el módulo de cortafuegos a través de un canal seguro.

Figura 16.2: Una imagen de fwlv.

anita:/etc/fw/bin# ./fw log
 Date: May 2, 2000
  3:28:43 ctl    anita      >daemon started sending log to localhost
  3:49:27 ctl    anita      >daemon started sending log to localhost
  4:30:30 ctl    anita      >daemon started sending log to localhost
 anita:/etc/fw/bin# ./fw logexport -o /etc/fw/logs/salida.ascii
 Starting pass 1 of the log file.
 Starting pass 2 of the log file..
    100.00% of log file processed.
 
 anita:/etc/fw/bin# cat /etc/fw/logs/salida.ascii
 num;date;time;orig;type;action;alert;i/f_name;i/f_dir;sys_msgs
 0;2May2000; 3:28:43;anita;control;ctl;;daemon;inbound;started sending log
 to localhost
 1;2May2000; 3:49:27;anita;control;ctl;;daemon;inbound;started sending log
 to localhost
 2;2May2000; 4:30:30;anita;control;ctl;;daemon;inbound;started sending log
 to localhost
 
 anita:/etc/fw/bin#
 

anita:/# fw log -f -n |head -3
 2:21:12 drop   anita   >nei0 proto tcp src 192.168.0.3 dst 158.42.22.41 \
 service finger s_port 13000 len 40 rule 5 
 2:22:23 drop   anita   >nei0 proto tcp src 192.168.0.10  dst 158.42.2.1 \
 service NetBus s_port 32344 len 40 rule 6 
 2:22:45 drop   anita   >nei0 proto tcp src 192.168.0.1  dst 192.168.2.3 \
 service echo-tcp s_port 30298 len 40 rule 5
 anita:/#