Red y cortafuegos

El cortafuegos de Linux no es un programa, es una parte del núcleo llamada netfilter. iptables es solo la herramienta con la que se le escriben reglas. netfilter coloca puntos de enganche a lo largo del recorrido de un paquete, y en cada punto de enganche cuelga una cadena de reglas.

Hay cinco cadenas y su nombre dice dónde están. Entenderlas es entender el momento del recorrido en el que se puede actuar sobre el paquete.

El otro eje son las tablas, que agrupan reglas por el tipo de trabajo que hacen. Cada tabla existe solo en las cadenas que le tienen sentido, y si no se indica ninguna se trabaja sobre la de filtrado.

Una precisión que conviene tener clara porque circula mal: el seguimiento de conexiones no es una tabla. Es un subsistema de netfilter que recuerda el estado de cada conexión, y es lo que permite escribir reglas que aceptan el tráfico de vuelta de una conexión ya establecida sin abrir el puerto de entrada.

Cinco cadenas y cinco tablas. Las tablas son filter, nat, mangle, raw y security; el seguimiento de conexiones es un subsistema, no una tabla.

Con cinco cadenas hay muchas combinaciones posibles, pero en la práctica un paquete solo sigue uno de tres recorridos, y saber cuál es lo que decide en qué cadena hay que escribir la regla. Es la pregunta más repetida de todo el subtema.

El tercer caso es el de una máquina con varias interfaces de red que reenvía tráfico de una a otra. No funciona de serie: el reenvío entre interfaces viene desactivado, y eso pilla a mucha gente escribiendo reglas de FORWARD que nunca llegan a aplicarse porque el paquete ni siquiera se plantea salir.

# activar el reenvío hasta el próximo reinicio
echo 1 > /proc/sys/net/ipv4/ip_forward

# dejarlo activado de forma permanente, en /etc/sysctl.conf
net.ipv4.ip_forward=1

Si la máquina hace de encaminador y el tráfico no pasa, lo primero es comprobar el bit de reenvío. Sin él, las reglas de FORWARD son papel mojado.

Una regla de iptables se lee como una frase: en qué tabla, en qué cadena, qué paquetes seleccionar y qué hacer con ellos. Las opciones que eligen la cadena y la operación van en mayúscula; las que describen el paquete, en minúscula.

La D mayúscula borra una regla; la d minúscula es la dirección de destino. Es la confusión que más reglas mal escritas produce.

Los criterios de selección describen qué paquetes encajan: el protocolo, las direcciones de origen y destino, los puertos y las interfaces por las que el paquete entra o sale.

Dentro de una cadena, las reglas se comprueban por orden y manda la primera que encaja: en cuanto una regla decide, el resto no se mira. De ahí que el orden importe tanto y que exista la opción de insertar en una posición concreta en vez de añadir al final.

iptables -L -n -v
iptables -t nat -L -n -v
iptables -P INPUT DROP
iptables -A INPUT -p tcp --dport 22 -s 10.20.0.0/16 -j ACCEPT
iptables -I INPUT 1 -i lo -j ACCEPT
iptables -D INPUT 3
iptables -F

La política por defecto merece un aviso práctico: poner la de INPUT en descarte con una sesión remota abierta y sin haber permitido antes el puerto de administración deja la máquina inaccesible. Se permite primero y se cierra después, nunca al revés.

La opción -j indica el objetivo, es decir qué se hace con el paquete que ha encajado. Unos objetivos son de filtrado y otros de traducción de direcciones, y cada uno solo vale en determinadas tablas y cadenas.

La diferencia entre descartar y rechazar no es de matiz. Descartar en silencio hace que el cliente espere hasta agotar el tiempo, lo que ralentiza a quien explora la máquina buscando puertos abiertos. Rechazar es más limpio para los servicios internos, porque el error llega de inmediato.

En la traducción de direcciones, la elección entre dirección fija y dirección de la interfaz depende de si la salida tiene una dirección estable. Con una conexión de dirección variable, la opción de enmascarar es la única que funciona sin reescribir la regla cada vez.

# salida a internet de toda una red interna, con dirección pública fija
iptables -t nat -A POSTROUTING -s 10.20.30.0/24 -o eth0 -j SNAT --to 203.0.113.7

# lo mismo cuando la dirección de salida cambia
iptables -t nat -A POSTROUTING -s 10.20.30.0/24 -o eth0 -j MASQUERADE

# publicar hacia dentro un servidor web interno
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j DNAT --to 10.20.30.8

# atender en un puerto alto lo que llega al 8080
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j REDIRECT --to-port 80

DNAT cambia el destino y va en PREROUTING; SNAT y MASQUERADE cambian el origen y van en POSTROUTING. La regla nemotécnica es que el destino se decide antes de encaminar y el origen, después.

Las reglas de iptables viven en memoria. Al apagar la máquina desaparecen, y ese es el error de bulto del administrador novato: dejar un cortafuegos perfectamente configurado que al siguiente reinicio no existe. Guardarlas y restaurarlas son dos órdenes.

iptables-save > /etc/iptables/rules.v4
iptables-restore < /etc/iptables/rules.v4

Guardar no basta: alguien tiene que restaurar en cada arranque. En la familia Debian eso lo hace un paquete específico de persistencia, que hay que instalar aparte y que carga automáticamente el fichero de reglas al iniciar el sistema.

iptables-save escribe y iptables-restore lee. Sin un mecanismo que ejecute la restauración al arrancar, el cortafuegos se pierde en el primer reinicio.

iptables sigue siendo lo que se estudia y lo que se pregunta, pero conviene saber en qué punto está. El sustituto oficial es nftables, que unifica en una sola herramienta lo que antes eran cuatro utilidades distintas para tráfico IPv4, IPv6, puentes y tramas.

En las distribuciones actuales, escribir una regla con la orden clásica suele acabar traduciéndose por debajo a nftables mediante una capa de compatibilidad. Es decir, se sigue tecleando lo mismo, pero el motor de abajo ya no es el antiguo.

Los dos frontends existen porque escribir reglas a mano es propenso a errores. Trabajan por servicios y por zonas de confianza en vez de por direcciones y puertos sueltos, y por debajo generan las reglas correspondientes.

netfilter es el motor, iptables y nftables son las herramientas de reglas, y ufw y firewalld son capas de comodidad por encima. Confundir netfilter con iptables es el error de concepto más común.

En Windows, la orden equivalente para tocar la red desde la consola es netsh. Su sintaxis se organiza en contextos: se indica de qué se va a hablar y después qué se quiere hacer. Los contextos que salen en el temario son el del cortafuegos, el de las interfaces, el inalámbrico y el del servicio web.

netsh advfirewall show allprofiles
netsh advfirewall set allprofiles state on
netsh advfirewall firewall add rule name="Intranet 8080" dir=in action=allow protocol=TCP localport=8080

Fíjese en la estructura de una regla: nombre, dirección del tráfico, acción, protocolo y puerto. Son los mismos conceptos que en iptables, con otra sintaxis. La diferencia visible es que el cortafuegos de Windows trabaja por perfiles, es decir por tipo de red, y una regla puede aplicarse solo al perfil activo.

El contexto de interfaces configura el direccionamiento, y sirve tanto para fijar una configuración estática como para volver a la automática.

netsh interface ip show config
netsh interface ip set address name="Ethernet" source=static addr=10.20.30.8 mask=255.255.255.0 gateway=10.20.30.1
netsh interface ip set address name="Ethernet" source=dhcp
netsh interface ip add dnsservers "Ethernet" 10.20.0.5
netsh interface ip delete arpcache

Dos posibilidades más que se preguntan: el contexto inalámbrico permite bloquear redes por su identificador, y el del servicio web permite asociar un certificado a una combinación de dirección y puerto, que es como se publica un servicio cifrado sin interfaz gráfica. Y la configuración entera se puede volcar a fichero y restaurar desde él.

netsh wlan add filter permission=block ssid="Invitados" networktype=infrastructure
netsh http add sslcert ipport=10.20.30.8:443 certhash=... appid={...}
netsh dump > C:\copias\red.txt
netsh exec C:\copias\red.txt

Alrededor de netsh están las órdenes de diagnóstico, que no configuran nada pero son las que se usan para averiguar qué está pasando.

netstat -ano es la orden que resuelve la pregunta de qué proceso está ocupando un puerto, porque la opción o añade el identificador del proceso a la salida.