Probablemente todo el que visita este sitio ha escuchado sobre Netfilter al menos indirectamente, pues su comando principal de configuración es iptables, que se menciona frecuentemente. Netfilter es un conjunto de módulos para el kernel de GNU/Linux que permite filtrar los paquetes de red, o en otras palabras, configurar un poderoso cortafuegos.
Si bien existen algunos proyectos que ofrecen interfaces amistosas para la configuración de un cortafuegos y por debajo traducen la configuración en reglas de netfilter, en mi opinión trabajar directamente con netfilter es más flexible y potente, y no particularmente difícil, una vez que se comprende cómo funciona.
De modo que en esta primera parte comenzaré exponiendo algunos de los conceptos y elementos básicos que necesitan comprenderse para configurar correctamente netfilter.
Netfilter tiene cuatro tablas para clasificar las reglas de filtrado:
Cada una de las tablas de netfilter tiene cadenas integradas que clasifican la función que se realiza sobre los paquetes de red.
Tabla | Cadena | Función |
raw | PREROUTING | Gestionar los paquetes que entran por alguna interfaz. |
OUTPUT | Gestionar los paquetes generados localmente. | |
mangle | PREROUTING | Gestionar los paquetes entrantes antes de enrutarlos. |
INPUT | Gestionar los paquetes entrantes con destino al propio equipo. | |
FORWARD | Gestionar los paquetes que el equipo reenvía. | |
OUTPUT | Gestionar los paquetes generados localmente antes de enrutarlos. | |
POSTROUTING | Gestionar los paquetes antes de que salgan. | |
nat | PREROUTING | Gestionar los paquetes entrantes antes de enrutarlos. |
INPUT | Gestionar los paquetes entrantes con destino al propio equipo. | |
OUTPUT | Gestionar los paquetes generados localmente antes de enrutarlos. | |
POSTROUTING | Gestionar los paquetes antes de que salgan. | |
filter | INPUT | Gestionar los paquetes entrantes con destino al propio equipo. |
FORWARD | Gestionar los paquetes que el equipo reenvía entre otros dos equipos. | |
OUTPUT | Gestionar los paquetes salientes generados localmente. |
Netfilter también permite crear en las distintas tablas cadenas personalizadas para analizar o alterar ciertos paquetes de manera más eficiente. Estas cadenas pueden usarse entonces como destinos.
Netfilter permite especificar para qué interfaces de red queremos aplicar las reglas, como lo, para referirse a la interfaz local (paquetes originados o destinados al propio equipo), o eth0, para referirse a la primera interfaz de ethernet (usualmente utilizada para la LAN). Algo no muy utilizado con el comando iptables pero que conviene tener presente, es que el signo de suma sirve de comodín para especificar más de una interfaz. Por ejemplo, eth+ para referirse a todas las interfaces de ethernet o ppp+ para referirse a todos los enlaces PPP, etc. Sin embargo, hay tablas como raw donde esto puede no funcionar, de modo que es preferible utilizarlo solo en la tabla filter.
Netfilter soporta una variedad de protocolos. Los más comunes son TCP, UDP e ICMP, pero hay muchos más, algunos de los cuales rara vez se utilizan y podrían explotarse para fines maliciosos, por lo que podrían deshabilitarse. Evidentemente que esto dependerá de las necesidades locales, por lo que el administrador debería identificar todos los protocolos que pretende utilizar en su red, para al menos poder marcar como sospechoso el paquete que utilice un protocolo no autorizado.
Es importante también identificar qué servicios tenemos habilitados en el servidor, y qué puertos utilizan estos para «escuchar», de esta manera es más fácil filtrar cualquier petición a un servicio inexistente. En otras palabras, en ocasiones es más simple, claro y seguro crear reglas diciendo por ejemplo «descarta cualquier paquete TCP nuevo cuyo puerto de destino no sea el puerto 80 o 443» que algo como «descarta cualquier paquete TCP nuevo cuyo puerto de destino sea el 0, 1, 2, 3 …» (la lista podría ser larga, pues el kernel de Linux permite 65,536 puertos). Similarmente, es importante identificar cualquier servicio válido que corra en otros equipos de la red, especialmente aquellos servicios que se pretenda exportar al exterior de la red local, pues en este caso habrá que realizar una traducción de direcciones y posiblemente también una redirección de puertos.
Los puertos privilegiados (aquellos entre 0 y 1023) son particularmente importantes, pues en algunos de estos puertos escuchan servicios que se concibieron en los inicios de la expansión de las redes informáticas, cuando se confiaba en que se les daría un uso apropiado. Actualmente algunos de estos servicios que no son particularmente útiles (como MOTD y CharGen, por ejemplo) pueden explotarse maliciosamente para realizar ataques distribuidos de denegación de servicios mediante reflexión con factores de amplificación (mas adelante ilustraremos esto con el servicio NTP), por lo que conviene que estén deshabilitados.
En netfilter, cada regla con que se evalúa un paquete debe terminar con el salto a un destino, que define que hacer si el paquete coincide con la regla. De no coincidir, simplemente se continúa evaluando el paquete mediante el resto de las reglas de la cadena. El destino puede ser uno integrado, o también una cadena personalizada. De no coincidir el paquete con ninguna regla, se le aplica el destino establecido en las políticas por defecto. Algunos de los destinos integrados más utilizados o útiles son los siguientes:
Destino | Función y observaciones |
ACCEPT | El paquete se acepta, y no se evalúan más reglas de la cadena. |
REJECT | El paquete se rechaza generando un paquete asociado de error explícito (para lo cual se utiliza el protocolo ICMP) y no se evalúan más reglas de la cadena. Este paquete solo es válido en las cadenas INPUT, FORWARD, OUTPUT o en las cadenas personalizadas que partan de estas. |
DROP | El paquete se descarta, y no se evalúan más reglas de la cadena. |
REDIRECT | El paquete se redirige a la propia máquina cambiando la dirección IP de destino a la dirección primaria de la interfaz por donde entró (los paquetes generados localmente se redirigen a la dirección 127.0.0.1). Solo es válido en las cadenas PREROUTING y OUTPUT de la tabla nat. |
MASQUERADE | El paquete se enmascara cambiando la dirección de origen a la de la interfaz de salida. Este destino solo es válido en la cadena POSTROUTING de la tabla nat, y debería utilizarse sólo para enlaces temporales como los de acceso telefónico, pues cuando la interfaz se cae, las conexiones se olvidan. Para direcciones IP estáticas siempre debería utilizarse el destino SNAT. |
SNAT | Permite cambiar la dirección (y opcionalmente el puerto) de origen del paquete. Solo es válido en las cadenas POSTROUTING e INPUT de la tabla nat. |
DNAT | Permite cambiar la dirección (y opcionalmente el puerto) de destino del paquete. Solo es válido en las cadenas PREROUTING y OUTPUT de la tabla nat. |
NFLOG | Permite la creación una traza del paquete, que se continúa evaluando mediante el resto de las reglas de la cadena. |
CT | Permite estblecer parámetros de rastreo para un paquete o su conexión asociada. Útil por ejemplo para deshabilitar el rastreo de conexiones en la tabla raw mediante el destino -j CT --notrack . |
RETURN | Finaliza la evaluación del paquete en la cadena actual y regresa al punto de invocación para continuar con la próxima regla. Debe colocarse al final de las reglas de cada cadena personalizada que creemos. |
Una de las características de netfilter es el rastreo de conexiones (Connection Tracking). Para esto, se utiliza un módulo del kernel (nf_conntrack) que permite analizar el tráfico y clasificar los paquetes según los siguientes estados:
net.ipv4.netfilter.ip_conntrack_tcp_loose = 1
.Netfilter incluye muchos módulos o extensiones de coincidencias (matches) que permiten personalizar las reglas en base a muchos criterios diferentes. Entre las muchas coincidencias disponibles se encuentran udp, tcp, multiport, conntrack, etc. Como son tantas, en este caso es mejor consultar la página de manual del comando iptables (mediante el comando man iptables-extensions
).
En la próxima parte de este tema, ejemplificaremos cómo se integran estos elementos para conformar reglas de filtrado.
Me complace anunciar la creación de esta útil herramienta (SquidStats), para el análisis y monitoreo…
La inteligencia artificial está revolucionando las industrias al automatizar tareas, predecir patrones y permitiendo tomar…
Uno de los grandes retos al que nos podemos enfrentar cuando una aplicación crece, es…
Percona Monitoring and Management (PMM) es una herramienta de código abierto para la supervisión y…
Qué es lo que deseo hacer en este capítulo? Básicamente un sonoff, quiero encender/apagar las…
Hace algunos meses estoy escuchando hablar del proyecto Home Assistant (HA). En palabras literales del…