Filtrado de paquetes
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.
Proxy de aplicación
Además del filtrado de paquetes, es habitual que los cortafuegos utilicen aplicaciones
software para reenviar o bloquear conexiones a servicios como
finger,
telnet o FTP; a tales aplicaciones se les denomina servicios
proxy, mientras que a la máquina donde se ejecutan se le llama
pasarela de aplicación.
Los servicios
proxy poseen una serie de ventajas de cara a incrementar nuestra seguridad ([WC94]); en primer lugar, permiten únicamente la utilización de servicios para los que existe un
proxy, por lo que si en nuestra organización la pasarela de aplicación contiene únicamente
proxies para
telnet, HTTP y FTP, el resto de servicios no estarán disponibles para nadie. Una segunda ventaja es que en la pasarela es posible filtrar protocolos basándose en algo más que la cabecera de las tramas, lo que hace posible por ejemplo tener habilitado un servicio como FTP pero con órdenes restringidas (podríamos bloquear todos los comandos
put para que nadie pueda subir ficheros a un servidor). Además, los
application gateways permiten un grado de ocultación de la estructura de la red protegida (por ejemplo, la pasarela es el único sistema cuyo nombre está disponible hacia el exterior), facilita la autenticación y la auditoría del tráfico sospechoso antes de que alcance el
host destino y, quizás más importante, simplifica enormemente las reglas de filtrado implementadas en el
router (que como hemos dicho antes pueden convertirse en la fuente de muchos problemas de seguridad): sólo hemos de permitir el tráfico hacia la pasarela, bloqueando el resto.
>Qué servicios ofrecer en nuestro
gateway, y cómo hacerlo? La configuración de la mayoría de servicios `habituales' está muy bien explicada (como el resto del libro) en el capítulo 8 de [CZ95]. Además, en numerosos artículos se comentan problemas específicos de algunos servicios; uno muy recomendable, centrado en el sistema de ventanas
X Window, pero donde también se habla de otros protocolos, puede ser [TW93].
El principal inconveniente que encontramos a la hora de instalar una pasarela de aplicación es que cada servicio que deseemos ofrecer necesita su propio
proxy; además se trata de un elemento que frecuentemente es más caro que un simple filtro de paquetes, y su rendimiento es mucho menor (por ejemplo, puede llegar a limitar el ancho de banda efectivo de la red, si el análisis de cada trama es costoso). En el caso de protocolos cliente-servidor (como
telnet) se añade la desventaja de que necesitamos dos pasos para conectar hacia la zona segura o hacia el resto de la red; incluso algunas implementaciones necesitan clientes modificados para funcionar correctamente.
Una variante de las pasarelas de aplicación la constituyen las pasarelas de nivel de circuito (
Circuit-level Gateways, [CB94]), sistemas capaces de redirigir conexiones (reenviando tramas) pero que no pueden procesar o filtrar paquetes en base al protocolo utilizado; se limitan simplemente a autenticar al usuario (a su conexión) antes de establecer el circuito virtual entre sistemas. La principal ventaja de este tipo de pasarelas es que proveen de servicios a un amplio rango de protocolos; no obstante, necesitan
software especial que tenga las llamadas al sistema clásicas sustituidas por funciones de librería seguras, como SOCKS ([KK92]).
Monitorización de la actividad
Monitorizar la actividad de nuestro cortafuegos es algo indispensable para la seguridad de todo el perímetro protegido; la monitorización nos facilitará información sobre los intentos de ataque que estemos sufriendo (origen, franjas horarias, tipos de acceso...), así como la existencia de tramas que aunque no supongan un ataque
a priori sí que son al menos sospechosas (podemos leer [Bel93b] para hacernos una idea de que tipo de tramas `extrañas' se pueden llegar a detectar).
>Qué información debemos registrar? Además de los registros estándar (los que incluyen estadísticas de tipos de paquetes recibidos, frecuencias, o direcciones fuente y destino) [BCOW94] recomienda auditar información de la conexión (origen y destino, nombre de usuario - recordemos el servicio
ident - hora y duración), intentos de uso de protocolos denegados, intentos de falsificación de dirección por parte de máquinas internas al perímetro de seguridad (paquetes que llegan desde la red externa con la dirección de un equipo interno) y tramas recibidas desde
routers desconocidos. Evidentemente, todos esos registros han de ser leidos con frecuencia, y el administrador de la red ha de tomar medidas si se detectan actividades sospechosas; si la cantidad de
logs generada es considerable nos puede interesar el uso de herramientas que filtren dicha información.
Un excelente mecanismo para incrementar mucho nuestra seguridad puede ser la sustitución de servicios reales en el cortafuegos por programas trampa ([Bel92]). La idea es sencilla: se trata de pequeñas aplicaciones que simulan un determinado servicio, de forma que un posible atacante piense que dicho servicio está habilitado y prosiga su `ataque', pero que realmente nos están enviando toda la información posible sobre el pirata. Este tipo de programas, una especie de troyano, suele tener una finalidad múltiple: aparte de detectar y notificar ataques, el atacante permanece entretenido intentando un ataque que cree factible, lo que por un lado nos beneficia directamente - esa persona no intenta otro ataque quizás más peligroso - y por otro nos permite entretener al pirata ante una posible traza de su conexión. Evidentemente, nos estamos arriesgando a que nuestro atacante descubra el mecanismo y lance ataques más peligrosos, pero como el nivel de conocimientos de los atacantes de redes habituales en general no es muy elevado (más bien todo lo contrario), este mecanismo nos permite descubrir posibles
exploits utilizados por los piratas, observar a qué tipo de atacantes nos enfrentamos, e incluso divertirnos con ellos. En la Universidad Politécnica de Valencia existen algunos sistemas con este tipo de trampas, y realmente es curioso observar cómo algunos intrusos siguen intentando aprovechar
bugs que fueron descubiertos - y solucionados - hace más de cuatro años (ejemplos típicos aquí son PHF y algunos problemas de
sendmail). En [Che92], un artículo clásico a la hora de hablar de seguridad (también se comenta el caso en el capítulo 10 de [CB94]), se muestra cómo Bill Cheswick, un experto en seguridad de los laboratorios AT&T estadounidenses, es capaz de analizar detenidamente gracias a estos programas las actividades de un pirata que golpea el
gateway de la compañía.
