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.