Gestión

Como ya hemos comentado, una de las grandes diferencias de IP Filter con respecto a otros sistemas cortafuegos es que este toma su configuración - su política - de simples ficheros ASCII; realmente esto es una diferencia importante con respecto a otros sistemas cortafuegos, como iptables, que no están orientados a archivo: un script de arranque de IP Filter instala políticas leídas del fichero correspondiente, que posee una cierta sintaxis, mientras que uno de iptables ejecuta línea a línea órdenes que conforman la política a implantar.

El hecho de que IP Filter esté orientado a archivo es principalmente una cuestión de diseño, pero no tanto de gestión; la segunda - pero quizás la más importante - diferencia de IP Filter con respecto a casi todo el resto de firewalls del mercado sí que es puramente relativa a su gestión, y la encontramos a la hora de implantar en el cortafuegos la política de seguridad definida en nuestro entorno de trabajo: se trata del orden de procesamiento de las reglas de IP Filter, completamente diferente a Firewall-1, ipchains o iptables. En todos estos firewalls se analizan en orden las reglas instaladas hasta que una coincide con el tipo de tráfico sobre el que actuar (como se dice habitualmente, hasta que hace match); en ese momento ya no se analizan más reglas, sino que se aplica la acción determinada por la regla coincidente. IP Filter no sigue este esquema; por contra, se suelen (digo `se suelen' porque se puede forzar un comportamiento diferente) procesar todas las reglas definidas en nuestra configuración, desde la primera a la última, y se aplica la última coincidente con el tipo de tráfico sobre el que se va a actuar. Como esta forma de trabajar puede resultar al principio algo confusa (especialmente para la gente que ha trabajado con otros cortafuegos), veamos un ejemplo que aclare un poco nuestras ideas; imaginemos un conjunto de reglas como el siguiente (utilizando una nomenclatura genérica):

  Origen           Destino           Tipo        Puerto        Accion
----------------------------------------------------------------------
    *                 *               *             *           Allow
    *                 *               *             *           Deny

Si un administrador de Firewall-1 ve esta política implantada en su cortafuegos seguramente se llevará las manos a la cabeza, ya que este firewall interpretará únicamente la primera regla: como cualquier tráfico coincide con ella, es la única que se aplicará; de esta forma, la política anterior dejaría pasar todo el tráfico hacia y desde nuestra red (algo que evidentemente no es ni recomendable ni práctico, porque es exactamente lo mismo que no tener ningún firewall).

En cambio, IP Filter no sigue este mecanismo; el software procesará ambas reglas, y aplicará la última que coincida con el tipo de tráfico sobre el que se quiere actuar; como la segunda y última regla coincidirá con todo el tráfico que circule por el cortafuegos, será la que se aplicará siempre: en definitiva, todo será parado por el firewall (aunque esto sería evidentemente muy beneficioso para nuestra seguridad, en la práctica es impensable: equivale a desconectar a cada sistema, o al menos a cada segmento, del resto de la red).

Teniendo en cuenta esta peculiaridad del software, ya podemos comenzar a definir nuestra política de filtrado en el fichero correspondiente; como siempre, por seguridad vamos a denegar todo el tráfico que no esté explícitamente autorizado, por lo que la primera regla del archivo será justamente la que niegue todo, y a continuación se definirán más entradas contemplando el tráfico que deseamos permitir:

anita:/# head -4 /etc/opt/ipf/ipf.conf 
#####
# Bloqueamos todo lo que no se permita explicitamente
#####
block in all
anita:/#

Esta regla viene a decir que se bloquee (`block') todo el tráfico (`all') de entrada (`in') al sistema; como podemos ver, una de las ventajas de este cortafuegos, orientado a archivo, es que la sintaxis del fichero de configuración es extremadamente sencilla: al menos al nivel más básico, casi únicamente sabiendo inglés podemos deducir qué hace cada regla, a diferencia de ipchains o ipfilter y sus opciones, que a decir verdad no son precisamente inmediatas...

Una vez negado todo el tráfico que no habilitemos explícitamente ya podemos comenzar a definir las reglas que acepten tramas; como en el anterior ejemplo, imaginemos que deseamos permitir todo el tráfico web cuyo destino sea la dirección 158.42.22.41, así como los accesos SSH a esta misma IP desde la 158.42.2.1. Para conseguirlo, definiremos un par de reglas similares a las siguientes:

# HTTP
pass in on elxl0 from any to 158.42.22.41 port = 80
# SSH
pass in on elxl0 from 158.42.2.1 to 158.42.22.41 port = 22

Podemos seguir viendo la facilidad para interpretar la sintaxis del archivo: estamos permitiendo (`pass') el tráfico de entrada (`in') por el interfaz elxl0 desde cualquier sitio (`from any', en el caso de HTTP) o desde una dirección concreta (en el caso de SSH) a los puertos correspondientes de la máquina destino (`to 158.42.22.41'). Una vez hecho esto - realmente, las reglas que vamos a comentar a continuación deberíamos ubicarlas antes que las reglas `pass' en un sistema real, pero a efectos de comprender la sintaxis de IP Filter esto es irrelevante - vamos a definir ciertas reglas para bloquear y detectar ataques, que además nos van a servir para introducir la directiva `quick'. Al igual que hacíamos sobre nuestro firewall Linux, vamos a bloquear el tráfico dirigido a ciertos puertos sospechosos, como 31337 (BackOrifice), 79 (finger) o 7 (echo); además, nos interesa bloquear también el tráfico que entre por el interfaz externo (donde se supone que está Internet) y provenga de redes que no están pinchadas en este interfaz. En conseguir ambos objetivos, usaremos un conjunto de reglas similar al siguiente:

#####
## LOG de escaneos
#####
block in log quick on elxl0 from any to any port = 31337
block in log quick on elxl0 from any to any port = 79

#####
# Trafico que no deberia verse en la interfaz externa
#####
block in     quick on elxl0 from 192.168.0.0/16 to any
block in     quick on elxl0 from 172.16.0.0/12 to any
block in     quick on elxl0 from 10.0.0.0/8 to any
block in     quick on elxl0 from 127.0.0.0/8 to any
block in     quick on elxl0 from 0.0.0.0/8 to any

De nuevo, vemos que entender lo que hace cada regla es inmediato; lo que ahora nos puede llamar la atención es, por un lado, la utilización de la directiva `log', de la que hablaremos en el punto siguiente - aunque no hace falta ser muy listo para imaginar qué hace - y por otro, lo que vamos a ver ahora, el uso de `quick': esta directiva provoca que la regla se aplique inmediatamente y para el tráfico afectado el resto de reglas no se examine. De esta forma, con la política definida hasta ahora, si no hubiéramos utilizado la directiva `quick' para bloquear el acceso a nuestro puerto 79, siempre que se viera tráfico hacia este servicio se analizaría el fichero completo, y como la última regla que hace match es la que indica su bloqueo, las tramas se denegarían; al utilizar `quick', en el momento que esta regla hace match, el tráfico se deniega sin seguir examinando la política, presentando así un comportamiento más similar al de las reglas de otros firewalls.

Hasta ahora nos hemos limitado a crear o modificar el fichero donde definimos la política de IP Filter, pero esos cambios no van a tener efecto hasta que la máquina se reinicie o hasta que obliguemos al firewall a releer su archivo de configuración; para esto último podemos invocar al shellscript que carga el cortafuegos en el arranque de la máquina pasándole el parámetro `reload', de la forma /etc/init.d/ipfboot reload.