Cualquier router IP utiliza reglas de filtrado para
reducir la carga de la red; por ejemplo, se descartan paquetes cuyo TTL
ha llegado a cero, paquetes con un control de errores erróneos, o simplemente
tramas de broadcast. Además de estas aplicaciones,
el filtrado de paquetes se puede utilizar para implementar diferentes
políticas de seguridad en una red; el objetivo principal de todas ellas
suele ser evitar el acceso no autorizado entre dos redes, pero manteniendo
intactos los accesos autorizados. Su funcionamiento es habitualmente muy
simple: se analiza la cabecera de cada paquete, y en función de una serie de
reglas establecidas de antemano la trama es bloqueada o se le permite seguir su
camino; estas reglas suelen contemplar campos como el protocolo utilizado
(TCP, UDP, ICMP...), las direcciones fuente y destino, y
el puerto destino, lo cual ya nos dice que el firewall ha de ser capaz de
trabajar en los niveles de red (para discriminar en función de las
direcciones origen y destino) y de transporte (para hacerlo en función de los
puertos usados). Además de la información de cabecera de las tramas,
algunas implementaciones de filtrado permiten especificar reglas basadas en
la interfaz del router por donde se ha de reenviar el paquete, y también
en la interfaz por donde ha llegado hasta nosotros ([Cha92]).
>Cómo se especifican tales reglas? Generalmente se expresan como una simple
tabla de condiciones y acciones que se consulta en orden hasta encontrar una
regla que permita tomar una decisión sobre el bloqueo o el reenvío de la
trama; adicionalmente, ciertas implementaciones permiten indicar si el bloqueo
de un paquete se notificará a la máquina origen mediante un mensaje ICMP ([Mog89]). Siempre hemos de tener presente el orden de análisis
de las tablas para poder implementar la política de seguridad de una forma
correcta; cuanto más complejas sean las reglas y su orden de análisis, más
difícil será para el administrador comprenderlas. Independientemente del
formato, la forma de generar las tablas dependerá obviamente del sistema
sobre el que trabajemos, por lo que es indispensable consultar su
documentación; algunos ejemplos particulares - pero aplicables a otros
sistemas - pueden encontrarse en [CHS91] (routers NetBlazer),
[Par98] (routers Cisco), [RA94] (TIS Internet
Firewall Toolkit sobre Unix) y también en la obra indispensable al
hablar de cortafuegos: [CZ95] (screend, NetBlazer, Livingston y Cisco).
Por ejemplo, imaginemos una hipotética tabla de reglas de filtrado de la
siguiente forma:
Origen Destino Tipo Puerto Accion
----------------------------------------------------------------------
158.43.0.0 * * * Deny
* 195.53.22.0 * * Deny
158.42.0.0 * * * Allow
* 193.22.34.0 * * Deny
Si al cortafuegos donde está definida la política anterior llegara un
paquete proveniente de una máquina de la red 158.43.0.0 se bloquearía
su paso, sin importar el destino de la trama; de la misma forma, todo el
tráfico hacia la red 195.53.22.0 también se detendría. Pero, >qué
sucedería si llega un paquete de un sistema de la red 158.42.0.0 hacia
193.22.34.0? Una de las reglas nos indica que dejemos pasar todo el tráfico
proveniente de 158.42.0.0, pero la siguiente nos dice que si el destino es
193.22.34.0 lo bloqueemos sin importar el origen. En este caso depende de
nuestra implementación particular y el orden de análisis que siga: si se
comprueban las reglas desde el principio, el paquete atravesaría el
cortafuegos, ya que al analizar la tercera entrada se finalizarían las
comprobaciones; si operamos al revés, el paquete se bloquearía porque
leemos antes la última regla. Como podemos ver, ni siquiera en nuestra tabla
- muy simple - las cosas son obvias, por lo que si extendemos el ejemplo a
un firewall real podemos hacernos una idea de hasta que punto hemos de
ser cuidadosos con el orden de las entradas de nuestra tabla.
>Qué sucedería si, con la tabla del ejemplo anterior, llega un paquete
que no cumple ninguna de nuestras reglas? El sentido común nos dice que por
seguridad se debería bloquear, pero esto no siempre sucede así;
diferentes implementaciones ejecutan diferentes acciones en este caso. Algunas
deniegan el paso por defecto, otras aplican el contario de la última regla
especificada (es decir, si la última entrada era un Allow se niega el
paso de la trama, y si era un Deny se permite), otras dejan pasar este
tipo de tramas...De cualquier forma, para evitar problemas cuando uno de
estos datagramas llega al cortafuegos, lo mejor es insertar siempre una regla
por defecto al final de nuestra lista - recordemos una vez más la cuestión
del orden - con la acción que deseemos realizar por defecto; si por
ejemplo deseamos bloquear el resto del tráfico que llega al firewall con
la tabla anterior, y suponiendo que las entradas se analizan en el orden
habitual, podríamos añadir a nuestra tabla la siguiente regla:
Origen Destino Tipo Puerto Accion
----------------------------------------------------------------------
* * * * Deny
La especificación incorrecta de estas reglas constituye uno de los problemas
de seguridad habituales en los cortafuegos de filtrado de paquetes; no obstante,
el mayor problema es que un sistema de filtrado de paquetes es incapaz de
analizar (y por tanto verificar) datos situados por encima del nivel de red
OSI ([Ste98a]). A esto se le añade el hecho de que si utilizamos
un simple router como filtro, las capacidades de registro de información
del mismo suelen ser bastante limitadas, por lo que en ocasiones es
difícil la detección de un ataque; se puede considerar un mecanismo de
prevención más que de detección. Para intentar solucionar estas - y
otras vulnerabilidades - es recomendable utilizar aplicaciones software
capaces de filtrar las conexiones a servicios; a dichas aplicaciones se les
denomina proxies de aplicación, y las vamos a comentar en el punto
siguiente.
© 2002 Antonio Villalón Huerta
