Seguridad en Unix y redes - IPFilter

IP Filter (http://coombs.anu.edu.au/~avalon/ip-filter.html##∞) es un cortafuegos disponible para muchos clones de Unix (Solaris, IRIX, FreeBSD, NetBSD, HP-UX...); su precio (se trata de un software gratuito) y sus excelentes características técnicas lo han convertido en una solución muy interesante para entornos medios donde otros cortafuegos como Firewall-1 no resultan apropiados por diferentes razones: incluso en Solaris puede ser (>es?) en muchos casos una alternativa más interesante que SunScreen Lite, de la propia Sun Microsystems.

---

Este cortafuegos permite filtrar el tráfico en función de diferentes campos de la cabecera IP de una trama, como las clases de seguridad, las direcciones origen y destino y el protocolo (obvio) o diferentes bits de estado. Además es posible utilizarlo como redirector de tráfico para configurar proxies transparentes, efectuar NAT e IP Accounting, y ofrece también mecanismos de comunicación con el espacio de usuario; por si todo esto fuera poco, IP Filter es stateful y soporta además IPv6.

---

No obstante, no todo es positivo; el argumento más utilizado por los detractores de IP Filter no es técnico sino jurídico, pero en cualquier caso vale la pena comentarlo: se trata del tipo de licencia, o de la interpretación de la misma, que hace el autor del software (el australiano Darren Reed), y que aunque distribuye el código fuente de forma gratuita, no permite efectuar modificaciones sobre el mismo. Aunque parezca una tontería, esta postura choca frontalmente con la filosofía de diferentes sistemas Unix para los que el producto está disponible, lo que ha generado problemas de distribución y utilización del mismo; el ejemplo más extremo es el de OpenBSD, que por indicación expresa del mismísimo Theo de Raadt eliminó IP Filter de sus distribuciones en Mayo de 2001 y comenzó desde entonces el desarrollo de pf, similar al anterior pero liberado bajo otro tipo de licencia.

Instalación

IP Filter no se distribuye oficialmente en formato binario (en forma de paquete), por lo que el código ha de ser compilado antes de ser utilizado; de cualquier forma, su instalación en un sistema Unix suele ser muy sencilla: por ejemplo, en el caso de Solaris, la única precaución a tener en cuenta es que GNU CC (gcc) no puede compilar IP Filter en modo 64 bits, por lo que será necesario utilizar el compilador de Sun Microsystems o, en su defecto, EGCS. En cualquier caso, los pasos a seguir una vez descargado el archivo .tar.gz17.2 son los siguientes:

anita:/var/tmp# gzip -dc ip-fil3.4.17.tar.gz |tar xf - anita:/var/tmp# cd ip_fil3.4.17 anita:/var/tmp/ip_fil3.4.17# /usr/xpg4/bin/make solaris anita:/var/tmp/ip_fil3.4.17# cd SunOS5 anita:/var/tmp/ip_fil3.4.17/SunOS5# /usr/xpg4/bin/make package

La última de estas órdenes creará y añadirá automáticamente un paquete con el cortafuegos en nuestro sistema. Podemos comprobar que está correctamente instalado con la orden pkginfo:

anita:/var/tmp# pkginfo -l ipf PKGINST: ipf NAME: IP Filter CATEGORY: system ARCH: i386 VERSION: 3.4.17 VENDOR: Darren Reed DESC: This package contains tools for building a firewall INSTDATE: Apr 06 2001 19:10 EMAIL: darrenr@pobox.com STATUS: completely installed FILES: 80 installed pathnames 12 shared pathnames 1 linked files 24 directories 11 executables 21441 blocks used (approx) anita:/var/tmp#

Tras instalar el paquete, definiremos las reglas de filtrado y NAT en los archivos correspondientes (tal y como veremos a continuación), y una vez hecho esto ya podremos inicializar nuestro firewall con la orden /etc/init.d/ipfboot start, que podemos incluir en el arranque de nuestra máquina de la forma habitual.

---

Si le pegamos un vistazo a este shellscript de inicialización del cortafuegos, generado al instalar el paquete ipf (en Solaris, /etc/init.d/ipfboot) podemos observar que en sus primeras líneas se definen los ficheros en los que se guardarán las reglas a instalar, tanto para filtrado como para traducción de direcciones. Se trata de simples archivos ASCII ubicados por defecto en el directorio /etc/opt/ipf/ que podemos modificar con nuestro editor preferido, aunque también podemos utilizar cómodos interfaces gráficos como fwbuilder (que ya hemos comentado al hablar de iptables e ipchains), capaces de generar reglas también para IP Filter.

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.

El sistema de log

Como cualquier sistema cortafuegos, IP Filter es capaz de generar registros cuando una determinada trama hace match con una regla que así lo indica; la forma de indicarlo, como ya hemos adelantado en el punto anterior, es mediante la directiva `log':

block in log quick on elxl0 from any to any port = 79

Esta regla bloquea (`block') de forma inmediata (`quick') el tráfico de entrada (`in') a través del interfaz elxl0, desde cualquier origen (`from any') a cualquier destino (`to any') y cuyo puerto destino sea el 79 (correspondiente a finger); mediante `log' hacemos que siempre que se haga match con ella esta regla genere un registro, para lo cual se utiliza la utilidad ipmon, inicializada en el mismo script que hemos visto antes para cargar la política de seguridad.

---

Por defecto, ipmon registra eventos con tipo `local0' y las siguientes prioridades predeterminadas ([McC00])

• info: Paquetes que son sólo registrados, no aceptados o denegados.
• notice: Paquetes registrados en una regla `pass'.
• warning: Paquetes registrados en una regla `block'.
• error: Paquetes cortos que pueden evidenciar un ataque basado en fragmentación de tramas IP.

Aunque este modelo suele ser más que suficiente en la mayoría de situaciones, si necesitamos un registro más fino podemos especificar, mediante la directiva `level', el tipo y la prioridad con que deseamos que una determinada regla registre las tramas que hacen match con ella; así, en el caso de la regla anterior, si queremos que cuando alguien trate de acceder al servicio finger de una máquina el tráfico se bloquee y además se registre un evento con tipo `auth' y prioridad `alert' (en lugar de `local0' y `warning', que serían los que le corresponderían por defecto), debemos reescribir la regla de una forma similar a:

block in log level auth.alert quick on elxl0 from any to any port = 79

Cuando esta regla haga match, se generará en el fichero correspondiente (no debemos olvidarnos de pegarle un vistazo a nuestro /etc/syslogd.conf para ver dónde se van a registrar los mensajes) una entrada de esta forma:

anita:/# tail -1 /var/log/syslog 02:59:04 anita ipmon[7043]: [ID 702911 auth.alert] 02:59:04.700386 elxl0 \ @0:2 b 62.42.102.18,4897 -> 192.168.0.3,79 PR tcp len 20 48 -S IN anita:/#

Aparte de generar eventos a través de syslog, la herramienta ipmon permite monitorizar en tiempo real las tramas que generan registros mediante opciones como `-o' o `-a', en línea de comandos; evidentemente esto es útil para visualizar en una terminal el estado del log en nuestro cortafuegos, por ejemplo para iniciar mecanismos de respuesta automática ante un determinado evento; para obtener más información acerca de esta herramienta, y del sistema de log de IP Filter en general, podemos consultar la página de manual de ipmon(8).