Introducción
Packet Filter es un componente de software con la capacidad para examinar las cabeceras de los paquetes que lo atraviesan y en base a ellas tomar decisiones sobre el destino de cada uno de los paquetes. Trabaja a nivel del kernel e inspecciona cada paquete IP que entra o sale del sistema.
Fue desarrollado por Daniel Hartmeier, para el proyecto OpenBSD (desde la version 3.0) en el año 2001. Este software ha ido evolucionando rápidamente y ahora posee varias ventajas ante otros sistemas de firewalls, como la integración de NAT (Network Address Translation) y Calidad de Servicio (QoS) han sido integrados en packet filter. También existe la capacidad de loguear los eventos que ocurren en la red, y monitorearlos con herramientas especiales que ofrece el ambiente OpenBSD (como pflog).
*NAT: Es un sistema que se utiliza para asignar una red completa (o varias redes) a una sola dirección IP. NAT es necesario cuando la cantidad de direcciones IP que nos haya asignado nuestro proveedor de Internet sea inferior a la cantidad de ordenadores que queramos que accedan a Internet. NAT
*QoS: son las tecnologías que garantizan la transmisión de cierta cantidad de datos en un tiempo dado. Con ello ofrecen mayor garantía y seguridad para las aplicaciones avanzadas
PF consiste básicamente en dos elementos: las reglas de filtro y la tabla de estados.
Reglas de Filtro : Cada paquete es comparado con un conjunto de reglas de filtro. Un filtro puede tomar tres decisiones sobre un paquete, aceptarlo, rechazarlo o descartarlo. Además el cortafuegos puede realizar cierto tipo de manipulación de paquetes. Esto tendremos que especificarlo en cada regla.
Tabla de Estados: Un firewall no solo inspecciona paquetes independientes, sino que conoce las conexiones ya establecidas. Cualquier regla que permite pasar el paquete, puede escribir en la tabla de estados. Antes de que una regla sea evaluado para el paquete, se busca en la tabla de estados para ver si ya existe, de ser asi, se deja pasar, sin evaluarlo nuevamente. Para TCP, se ve el número de secuencia y se compara con las ventanas esperadas, esto provee un importante mecanismo de seguridad contra ataques de secuencia.
PF guarda los estados en un árbol AVL (binario y balanceado). Este diseño provee funcionalidades eficientes para buscar, y una buena escalabilidad si el árbol crece mucho. Para el peor caso se tiene O(long n), lo que impide ataques de negación de servicios (DoS).
Sistema de Filtrado de Trafico
El tráfico sobre el que puede actuar un cortafuegos puede ser el propio tráfico que llega o sale de la propia máquina y el tráfico de "paso", el que la máquina tiene que enrutar cuando actúa como router entre redes.
Como un router recoge todo el tráfico entre redes otra posibilidad que nos brinda es poder modificar el ancho de banda que puede utilizar cada cliente. Para que la red sea justa con todos podemos prevenir el caso de que unos pocos saturen el ancho de banda disponible.
Ahora, la acción de filtrar paquetes consiste en bloquear o permitir el paso a los paquetes de datos de forma selectiva, según van llegando a una interfaz de red. Los criterios que usa Packet Filter para inspeccionar los paquetes se basan en la información existente en la capa de red y en la capa de transporte de las cabeceras de los paquetes.
Las reglas de filtrado especifican los criterios con los que debe concordar un paquete y la acción a seguir, bien sea bloquearlo o permitir que pase, que se toma cuando se encuentra una concordancia. Las reglas de filtrado se evalúan por orden de secuencia, de la primera a la última. El paquete se evaluara comparándolo con todas las reglas de filtrado antes de decidir una acción final. La última regla que concuerde será la «ganadora» y la que dictamine qué acción se tomará con el paquete. Al principio del grupo de reglas de filtrado hay un “pass all” implícito que indica que si algún paquete no concuerda con ninguna de las reglas de filtrado, la acción a seguir será pass, o sea permitirle el paso.
Rendimiento
El rendimiento de PF es determinado por una serie de variables, algunas son:
- Numero de paquetes por segundo. Los filtros deben ser evaluados cada segundo, determinando la demanda efectiva del sistema.
- Una buena tarjeta de red (NIC).Para un desempeño óptimo, se recomienda usar tarjetas ethernet de gigabits, pues aunque la red no sea de gigabit, tiene capacidades mas avanzadas de buffering.
- Complejidad y diseño de las reglas. Mientras mas complejas sean las reglas, mas lento se pone el sistema. Al contrario con reglas rápidas y bien diseñadas, se demora menos en procesarlas.
El Router es el encargado de filtrar los paquetes basados en cualquiera de los siguientes criterios:
1- El protocolo a través del cual se transfiere el paquete. De manera predeterminada, se seleccionan todos los protocolos del conjunto de protocolos TCP/IP. Sin embargo, a fin de satisfacer requisitos especiales, puede especificarse un protocolo individual para este filtro, incluidos los protocolos personalizados.
2- Dirección IP de origen y de destino. Se puede especificar cualquier dirección IP asignada al interlocutor IPSec, una única dirección IP, direcciones IP por nombre DNS o grupos de direcciones para especificar subredes IP.
3- Puerto TCP-UDP de origen y de destino. El filtrado de paquetes mediante puertos TCP-UDP permite establecer que servicios estarán disponibles al usuario y por cuales puertos. Por ejemplo se puede permitir navegar en
Algunos puertos usados para los protocolos
| Protocolo | Puerto | Uso |
| TCP | 25 | Protocolo simple de transferencia de correo (SMTP) |
| TCP | 67 | Protocolo de configuración dinámica de host (DHCP) |
| TCP | 80 | World Wide Web. Protocolo de transferencia (HTTP). |
| TCP | 110 | Protocolo de oficina de correo (POP version 3) |
| UDP | 53 | Servicio de nombres de dominio (DNS) |
| UDP | 67 | Parámetros de configuración a PCs conectados a la red |
| UDP | 500 | Seguridad del Protocolo Internet (IPSec) |
| UDP | 1723 | Acceso de usuarios remotos a una red corporativa |
Estos criterios permiten gran flexibilidad en el tratamiento del tráfico.
Debido a su funcionamiento y estructura basada en el filtrado de direcciones y puertos este tipo de Firewalls trabajan, como ya se mencionó, en los niveles de Transporte y de Red del Modelo OSI y están conectados a ambos perímetros (interior y exterior) de la red.
Ventajas y Desventajas
Ventajas:
- Son económicos.
- Tienen un alto nivel de desempeño
- Son transparentes para los usuarios conectados a la red.
Sin embargo presenta debilidades como:
- No protege las capas superiores a nivel OSI.
- Las necesidades aplicativas son difíciles de traducir como filtros de protocolos y puertos.
- No son capaces de esconder la topología de redes privadas, por lo que exponen la red al mundo exterior.
- Sus capacidades de auditoría suelen ser limitadas, al igual que su capacidad de registro de actividades.
- No soportan políticas de seguridad complejas como autentificación de usuarios y control de accesos con horarios prefijados.
Denegación Predeterminada
La práctica recomendada para configurar un cortafuegos es la de tomar una aproximación de «denegación predeterminada»; o sea, denegar el paso a todo y a partir de ahí ir permitiendo el paso a través del cortafuegos de forma selectiva a cierto tráfico. Esta aproximación es la recomendada ya que los posibles fallos se cometerían a favor de la seguridad, y también por que hace más fácil la creación de grupos de reglas.
Para crear una política de filtrado de denegación predeterminada, las primeras dos reglas deben ser:
block in all
block out all
Con esto se bloquea todo el tráfico en todas las interfaces en cualquier dirección, y desde cualquier origen, hasta cualquier destino.
Paso de Tráfico
Ahora hay que permitir de forma explícita y selectiva el paso del tráfico a través del cortafuegos, o de lo contrario será bloqueado por la política de denegación predeterminada. Aquí es donde entran en juego los criterios del paquete, como son el puerto de origen/destino, la dirección de origen/destino, y el protocolo. Siempre que se permita el paso de cierto tráfico a través del cortafuegos hay que escribir las reglas de un modo tan restrictivo como sea posible. Esto es para asegurarse de que sólo pasará el tráfico que se permita, y ningún otro.
Especificación de las reglas
Las 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. 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.
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.
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. 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 (proxies de aplicación).
No hay comentarios:
Publicar un comentario