Esquemas de filtrado

Es importante saber cual es el circuito exacto que siguen los paquetes en la máquina. Cada paquete que llega a nuestro cortafuegos sigue un determinado camino donde se le aplican una determinadas reglas de filtrado. Si el paquete no ha verificado ninguna de las reglas de aceptar o denegar entonces también deberemos tomar una decisión final con ese paquete.

esquema de filtrado

Figura 1. Esquema de filtrado

Circuito de filtrado

Cuando un paquete llega a nuestro cortafuegos primero pasa unos filtros.

En primer lugar pasamos al filtro de PREROUTING donde podemos manipular el paquete modificando sus datos de destino, por ejemplo redirigir a otra máquina o a otro puerto. Esto se conoce como DNAT (destination network address translation).

Una vez que el paquete de entrada está preparado se comprueba si va dirigido al propio ordenador en cuyo caso pasa al filtro de entrada (INPUT), o bien si va dirigido a otra máquina, en cuyo caso se dirige al filtro de reenvío (FORWARD).

Si el paquete iba destinado a la máquina local y ha pasado el filtro de entrada se le entrega al proceso local que lo solicitó.

Si un proceso local genera un paquete que tiene que enviar a la red primero pasa por el filtro de salida (OUTPUT). El filtro de salida podría manipular el paquete modificando el destino.

Si el paquete ha pasado el filtro de reenvío (FORWARD) pasaría el filtro de POSTROUTING. Igualmente si el paquete local pasa el filtro de salida también pasa al filtro de POSTROUTING).

En el filtro de POSTROUTING se pueden manipular los datos de origen de un paquete. En esta fase podemos realizar SNAT (source network address translation), es decir, manipular los datos de origen del paquete.

Cada vez que tengamos que configurar un filtro tenemos que tener muy en cuenta este esquema.

Orden de la reglas

El orden de las reglas de un cortafuegos define su comportamiento. El filtro de va comparando el paquete con cada una de las reglas hasta que se encuentra una que verifica y en ese caso se lleva a cabo lo que indique esa regla (aceptar o denegar); una vez realizada la acción no se comprueban más reglas. Si ponemos reglas muy permisivas entre las primeras del cortafuegos, puede que las siguientes no se apliquen y no sirvan de nada.

Política predeterminada

También se puede dar el caso de que un paquete no haya verificado ninguno de los filtros una vez que ha los ha comprobado todos. En este caso no sabemos si tenemos que aceptar o rechazar este paquete. Para resolver esta situación iptables dispone de una política predeterminada que permite indicar qué hacer con los paquetes que no hayan verificado ninguna regla. La política predeterminada será algunas de las acciones que hemos definido y se define con la opción "-P".

Por ejemplo:

 

iptables -P INPUT -j ACCEPT

Definiría como aceptar la política predeterminada del filtro INPUT.

La política predeterminada define un esquema distinto de cortafuegos. Si la política predeterminada es aceptar entonces tendremos que denegar todo aquello que no nos interese. Si la política predeterminada es denegar entonces entremos que permitir todo aquello que nos interese.

Cada uno de los modelos de cortafuegos tiene sus ventajas e inconvenientes. En el primer caso, con la política predeterminada de aceptar es mucho más fácil la gestión del cortafuegos. En este caso es útil cuando sabemos claramente qué puertos queremos proteger y el resto no importa y se acepta. El problema que plantea es no poder controlar qué tenemos abierto o que en un momento dado se instale un software nuevo, un troyano por ejemplo, que abra un puerto determinado, o que no sepamos que determinados paquetes ICMP son peligrosos. Si la política predeterminada es ACEPTAR y no se protege explícitamente el sistema puede ser inseguro.

Cuando política predeterminada es DENEGAR todo lo que no aceptemos explícitamente será denegado por lo que el sistema puede fallar por despiste o desconocimiento en lo que estamos permitiendo. Es más complicado establecer este tipo de cortafuegos, hay que tener muy claro como funciona el sistema y qué es lo que se tiene que aceptar sin caer en la tentación de intorducir reglas muy perpermisivas. Esta configuración de cortafuegos es la recomendada, aunque no es aconsejable usarla si no se domina mínimamente el sistema.

Otros criterios de definición de filtros

Registro de paquetes

Se utiliza con el objetivo LOG (-j LOG) y dispone de las siguientes opciones:

--log-level nivel (nombre o número de nivel) define el nnivel de registro. Los nombres válidos son (distingue mayúsculas/minúsculas) «debug», «info», «notice», «warning», «err», «crit», «alert», «emerg», que corresponden a los números 7 a 0.

--log-prefix cadena Especifica una cadena de hasta 30 caracteres que se escriben la comienzo del registro para identificarlos con posterioridad.

Este módulo se puede asociar con «limit» para evitar que los registros de conexión se hagan excesivamente voluminosos en los ficheros de registro.

Extensiones TCP

Las extensiones TCP se cargan automáticamente si especificamos "-p tcp" y habilitan las algunas opciones de especificación más:

--tcp-flags tomo como argumento dos cadenas de indicadores que permiten filtrar según ciertos indicadores de TCP. En primer lugar especificamos la máscara: una lista de los indicadores que desea examinar. En segundo lugar indicamos cuales deben estar activos. "--tcp-flags" puede ir seguido por una «!» opcional Por ejemplo,

 

# iptables -A INPUT --protocol tcp --tcp-flags ALL SYN,ACK -j DENY

Esto indica que se deben examinar todos los indicadores («ALL» es sinónimo de «SYN,ACK,FIN,RST,URG,PSH»), pero sólo deben estar activos SYN y ACK. Hay otro argumento llamado «NONE», que significa «ningún indicador».

--syn es equivalente a --tcp-flags SYN,RST,ACK SYN. Esta condición la verifican sólo los paquetes que treten de iniciar una conexión con un servidor. Ese indicador permite controlar quien inicia conexión. Puede incluir "!".

--sport y --dport ya las hemos descrito anteriormente.

son lo mismo que lo anterior, sólo que especifican el puerto de destino, en lugar del de origen.

Extensiones ICMP

Esta extensión se carga de forma automática si se especifica «-p icmp». Proporciona sólo una opción nueva:

--icmp-type seguida de un «!» opcional, y a continuación el nombre de un tipo icmp (p.ej. «host-unreachable»), un tipo numérico («3»), o un tipo numérico y un código separados por «/» («3/3»). Puede ver una lista de los nombres de los tipos icmp disponibles usando «-p icmp --help».

Otras extensiones de coincidencia (match)

Otras extensiones del paquete netfilter se pueden invocar con la opción «-m».

Extensión mac

Este módulo se debe especificarde forma explícita con «-m mac» o «--match mac». Se usa para coincidencias en las direcciones Ethernet (MAC) de los paquetes entrantes, y por tanto sólo son útiles para los paquetes que pasan por las cadenas PREROUTING e INPUT. Proporciona sólo una opción:

--mac-source seguida de un «!» opciona, y luego una dirección ethernet en notación hexadecimal separada por «:», por ejemplo «--mac-source B0:70:99:AD:DC:B4».

limit

Este módulo de debe especificar de forma explícita con «-m limit» o «--match limit». Se usa para restringir la tasa de coincidencias, como por ejemplo para suprimir mensajes de registro. Sólo se activará un número dado de veces por segundo (por defecto, 3 coincidencias por hora, a ráfagas de 5). Tiene dos argumentos opcionales:

--limit seguido por un número; especifica el número máximo de coincidencias de media por segundo a permitir. El número puede especificar unidades de forma explícita, usando «/second», «/minute», «/hour», o «/day», o abreviadas (de manera que «5/second» es lo mismo que «5/s»).

--limit-burst seguido de un número, indica la ráfaga más larga que se puede producir antes de comprobar el límite.

Este tipo de coincidencias se suele usar con el objetivo LOG para producir registros limitados por una tasa. Para comprender cómo funciona esto, veamos la siguiente regla, que registra los paquetes con los parámetros de limitación por defecto:

 

 iptables -A FORWARD -m limit -j LOG

La primera vez que se alcanza esta regla, se registra el paquete; en realidad, como la ráfaga por defecto es de 5, se registrarán los primeros cinco paquetes. Después, pasarán veinte minutos antes de que vuelva a registrarse un paquete con esta regla. Además, cada veinte minutos que pasen sin que un paquete alcance la regla, la ráfaga «recuperará» un paquete; si no sucede nada durante 100 minutos, la ráfaga quedará completamente «recargada»; de vuelta entonces a la situación inicial.

Ahora mismo no se pueden crear reglas con un tiempo de recarga mayor a 59 horas, de manera que si establece una tasa de recarga de un paquete por día, entonces el número de paquetes por ráfaga deberá ser menor que 3.

También puede usar este módulo para evitar varios ataques por denegación de servicio (DoS) con una tasa más rápida para incrementar la respuesta.

Protección contra Syn-flood (inundación mediante Syn):

 

 iptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT

Furtivo buscando puertos (port scanner):

 

iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT

state

Cuando se combina este módulo con el seguimiento de conexiones, podremos tener acceso al estado de seguimiento de un paquete. Este módulo de debe especificar de forma explícita con «-m state». Este módulo porporciona un opción

--state state, donde indicamos una lista de estados de conexión separada por comas. Los valores posibles para el esado «INVALID» lo que significa que el paquete no se puede identifcar por alguna razón, como por ejemplo falta de memoria o errores ICMP que no corresponden a ninguna conexión conocida. Otro posible estado es «ESTABLISHED» que se asocia con una conexión que ya ha tenido tráfico en ambas direcciones.. El estado «NEW» significa que el paquete inicia una nueva conexión o asociado con una conexión que aun no ha tenido paquetes en ambas direcciones. Por último «RELATED» indica que el paquete comienza una nueva conexión, pero está asociado con una conexión previa existente, por ejemplo una transferenia FTP o un error ICMP.

owner

El módulo owner se utiliza para fitrar según el propietario del paquete, del propietario del proceso que origina el paquete y sólo tiene sentido para los paquetes generados forma local y sólo es válido para la cadena OUTPUT. Cuando activamos este módulo disponemos de las siguientes opciones:

--uid-owner idusuario que se verifica cuando el proceso que originó el paquete es proiedad del usuario con el UID indicado.

iptables -A OUTPUT -m owner -uid-owner 203 -j ACCEPT

--uid-owner idgrupo es equivalente a la anterior opción pero con grupos.

--pid-owner idproceso Permite especificar el PID del proceso que origina el paquete.

--sid-owner idproceso Permite espcificar el GID del proceso que genera el paquete.

Módulos de iptables

Iptables necesita tener en el núcleo diversos módulos para, qur en primer lugar funciones iptables y en segundo lugar para añadir nuevas funcionalidades, como por ejemplo las que veíamos en el punto anterior. Para comprobar los módulos que tenemos activos en el núcleo podemos ejecutar lsmod y entre otras cosas aparece:

 

ipt_multiport           1176   0  (autoclean)
ipt_conntrack           1688   0  (autoclean)
iptable_mangle          2776   0  (autoclean) (unused)
ipt_MASQUERADE          2200   2  (autoclean)
iptable_nat            21848   1  (autoclean) [ipt_MASQUERADE]
ip_conntrack           28552   2  (autoclean) [ipt_conntrack ipt_MASQUERADE iptable_nat]
ipt_REJECT              4248   1  (autoclean)
ipt_LOG                 4248   2  (autoclean)
iptable_filter          2444   1  (autoclean)
ip_tables              15136  10  [ipt_multiport ipt_conntrack iptable_mangle ipt_MASQUERADE iptable_nat ipt_REJECT ipt_LOG iptable_filter]

En el directorio /lib/modules/version/kernel/net/ipv4/netfilter podremos encontrar todos los módulos necesarios.

Si algún módulo necesario no se carga automáticamente tendremos que hacerlo explícitamente.