iptables en Linux: guía práctica, completa y sin rodeos

Portada » Linux » iptables en Linux: guía práctica, completa y sin rodeos

Si administras distribuciones Linux para proteger tu seguridad y privacidad, tarde o temprano te tocará lidiar con iptables. Este sistema de filtrado de paquetes es el corazón del firewall clásico en GNU/Linux, capaz de decidir qué tráfico entra, sale o se reenvía entre redes. Bien configurado, es como tener un portero muy fino en la puerta de tu red, que aplica tus normas sin pestañear y con una precisión quirúrgica.

En las próximas líneas vas a encontrar una guía completa y actualizada que integra lo esencial: conceptos de cortafuegos, Netfilter, tablas y cadenas, flujo de paquetes, comandos clave, extensiones de reglas y targets avanzados, además de escenarios prácticos como NAT, redirecciones, políticas por defecto y una DMZ funcional. Todo explicado con un lenguaje cercano pero riguroso, para que puedas aplicarlo ya en tu infraestructura.

Cortafuegos en contexto: del portero de discoteca a la DMZ

Un cortafuegos es, en esencia, un filtro entre redes que aplica reglas para decidir el destino de cada paquete. Piénsalo como un portero de discoteca con una lista de criterios: si el paquete cumple, pasa; si no, se queda fuera. Esa metáfora sirve para entender que lo importante es la lógica de reglas y el orden en el que se evalúan.

Dentro del diseño de red, hay topologías más seguras que otras. La DMZ (zona desmilitarizada) es una red intermedia que aloja servicios públicos (como un web o FTP) separándolos de la LAN corporativa. ¿Por qué? Porque si un atacante comprometiese un servidor público, la segmentación impide que tenga acceso directo al resto de la red interna.

Linux como cortafuegos: Netfilter e iptables

El núcleo de Linux incorpora Netfilter, un framework con “ganchos” (hooks) para interceptar y manipular paquetes. En el espacio de usuario, iptables es la utilidad que define las reglas que el kernel aplicará al paso del tráfico. Esta separación kernel/usuario permite alto rendimiento con gran flexibilidad.

Conviene distinguir las utilidades por protocolo: iptables (IPv4), ip6tables (IPv6), arptables (ARP) y ebtables (tramas Ethernet). En el kernel, el módulo común es x_tables, que comparte la lógica para extensiones de coincidencia y objetivos. Y un apunte histórico: iptables sustituyó a ipchains y, a su vez, nftables sucedió a iptables en el kernel 3.13, aunque iptables sigue muy presente en multitud de sistemas.

Para operar, necesitarás privilegios de administrador. Ejecuta iptables como root (o con sudo), normalmente en /usr/sbin/iptables (Debian/derivadas) o /sbin/iptables (Red Hat/derivadas). La documentación oficial está en man iptables y en netfilter.org.

Estructura de iptables: tablas, cadenas y reglas

Iptables organiza su lógica en tablas (tables) compuestas por cadenas (chains) llenas de reglas. Cada regla especifica condiciones de coincidencia y un objetivo (target) a aplicar cuando el paquete encaja.

• Tabla filter (por defecto, filtrado puro)
  • INPUT: tráfico dirigido a la propia máquina.
  • FORWARD: tráfico que atraviesa el equipo (enrutamiento).
  • OUTPUT: tráfico generado localmente.
• Tabla nat (traducción de direcciones; se evalúa en nuevas conexiones)
  • PREROUTING: antes de decidir ruta; ideal para DNAT/port forwarding.
  • OUTPUT: paquetes originados localmente antes de rutear.
  • POSTROUTING: tras el enrutamiento; típico para SNAT/MASQUERADE.
• Tabla mangle (ajustes finos de cabeceras: TOS, TTL, marcado, etc.)
  • PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING: disponible en todo el camino.
• Tabla raw (control de seguimiento de conexiones/conntrack)
  • PREROUTING y OUTPUT: para marcar tráfico que debe saltarse conntrack.

Cuando un paquete llega a una cadena, se compara secuencialmente con cada regla; si coincide, se ejecuta su objetivo y se detiene el recorrido. Si alcanza el final sin encajar en ninguna y la cadena es predefinida, se aplica la política por defecto (chain policy) de esa cadena.

Flujo de los paquetes: por dónde pasan y cuándo

Entender la ruta que sigue el tráfico es clave para ubicar bien las reglas. Un paquete que sale de tu LAN hacia Internet típicamente se procesa así: primero PREROUTING (posible DNAT/mangle), pasa por FORWARD (filtrado de tránsito), y antes de abandonar el equipo toca POSTROUTING (SNAT/MASQUERADE si procede).

En cambio, si el destino es el propio cortafuegos, intervendrán PREROUTING → INPUT; si lo emite la máquina local, la ruta será OUTPUT → POSTROUTING. Esta matriz mental te ahorra dolores de cabeza cuando algo no cuadra.

Comandos básicos: listar, limpiar, crear y políticas por defecto

Para auditar el estado actual, usa iptables -L (opcionalmente -v para detalle y -n para no resolver nombres). También puedes crear y eliminar cadenas con -N y -X respectivamente, y fijar políticas por defecto con -P.

Cuando necesitas partir de cero, limpia reglas con -F (flush) y, si procede, los contadores. Recuerda que puedes especificar tablas con -t y cadenas concretas; por ejemplo, iptables -F -t nat para la NAT.

Al definir reglas, las opciones más comunes son directas: -A añade, -I inserta, -R reemplaza y -D borra. Luego incorporas selectores como -p (protocolo), -s/-d (origen/destino), -i/-o (interfaces) y el objetivo con -j (p. ej., ACCEPT, DROP o REJECT).

Las políticas por defecto definen qué pasa si ninguna regla coincide. Un esquema típico endurecido en un host sería INPUT DROP, FORWARD DROP, OUTPUT ACCEPT, bloqueando todo lo entrante salvo lo permitido explícitamente y permitiendo lo que sale.

Extensiones de coincidencia (-m): TCP, UDP, ICMP, MAC, estado y multiport

Iptables amplía sus filtros con módulos de coincidencia usando -m. El de TCP permite afinar por puertos y banderas: --dport/--sport y --syn para nuevas aperturas de conexión, por ejemplo.

Para UDP, puedes delimitar igualmente puertos de origen y destino. Un caso clásico: abrir el 80/443 hacia un servidor web o permitir consultas DNS salientes al 53/UDP.

Con ICMP, --icmp-type te deja discriminar tipos (p. ej., echo-request y echo-reply para pings). Esto es útil para permitir diagnósticos sin dejar la puerta abierta a todo ICMP.

También existe el módulo mac para filtrar por dirección MAC con --mac-source. Útil si quieres autorizar un equipo administrado con IP dinámica para que haga ping al cortafuegos sin depender de la IP.

Y, quizá el más importante a nivel operativo, el módulo state (o conntrack) con --state NEW, ESTABLISHED, RELATED. Este permite permitir respuestas de conexiones ya establecidas, reduciendo drásticamente el número de reglas necesarias.

Para agrupar puertos, multiport añade --sports y --dports con listas separadas por comas. Es cómodo para abrir HTTP, HTTPS y SSH en una sola regla.

Objetivos (targets) más allá de ACCEPT/DROP: NAT y compañía

Además de aceptar o descartar, iptables puede reescribir direcciones y puertos para conectar redes privadas con Internet o publicar servicios internos.

MASQUERADE (en POSTROUTING de la tabla nat) sustituye la IP de origen por la IP de salida del cortafuegos, ideal cuando la IP pública es dinámica (DHCP). Es el NAT típico de salida para toda una LAN.

SNAT (también en POSTROUTING) fija explícitamente la IP/puerto de origen con --to-source. Se usa cuando tienes IP pública estática y quieres controlar con precisión la traducción.

DNAT (en PREROUTING o OUTPUT) cambia la IP de destino con --to-destination. Es el famoso “abrir puertos”: recibes tráfico en la IP pública y lo rediriges a un servidor en la DMZ, por ejemplo un web interno en el 192.168.1.2.

Ejemplo sencillo: filtrar tránsito entre dos redes

Imagina una máquina actuando como router/cortafuegos entre dos subredes. Si quieres que solo el host B hable con C y únicamente por TCP, la tabla será filter y la cadena correcta es FORWARD, porque el tráfico atraviesa el equipo.

Primero aplicarías una política por defecto DROP en FORWARD y luego autorizarías explícitamente el tráfico B→C en TCP (y si procede, C→B). Este patrón “denegar por defecto y permitir lo mínimo” es la base de una postura de seguridad sólida.

Casos cotidianos en una pasarela: reglas tipo

Una pasarela con dos interfaces, por ejemplo eth1 (LAN) y eth0 (WAN), suele necesitar reenviar paquetes de la LAN hacia Internet. Para ello, añade FORWARD -i eth1 -o eth0 -j ACCEPT, y permite en sentido inverso solo ESTABLISHED,RELATED con -m state.

En el propio cortafuegos, conviene autorizar tráfico entrante que sea respuesta de conexiones salientes con INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT, y permitir siempre el loopback: INPUT -i lo -j ACCEPT.

Para que los equipos de la LAN naveguen, aplica NAT de salida: -t nat -A POSTROUTING -s 192.168.0.0/24 -o eth0 -j SNAT --to-source X.Y.Z.W (o MASQUERADE si la IP es dinámica). Esto traduce las IP privadas a tu IP pública.

Un endurecimiento básico es bloquear paquetes entrantes por WAN con IPs de origen indebidas (tu propia IP pública, rangos privados 192.168.0.0/24, 127.0.0.0/8, etc.), ya que suelen indicar suplantación.

Para exponer servicios en el cortafuegos (p. ej., SMTP 25, HTTP 80, HTTPS 443 o SSH 22), puedes permitir paquetes TCP con flag SYN para esos puertos de destino. Si deseas acotar por IP de destino, añade -d a la IP del servicio.

Servicios de infraestructura habituales: DHCP (tráfico desde puerto 68 al 67) en la interfaz LAN, y DNS desde el resolver autorizado (UDP 53) si filtras por origen. Estas aperturas permiten que los clientes obtengan IP y resuelvan nombres.

Si toca cerrar accesos, DROP a SSH/Telnet entrante es directo; también puedes REJECT salidas hacia IPs vetadas de la red local para que el emisor reciba notificación de rechazo.

Instalación y gestión del servicio en sistemas Red Hat/CentOS

En entornos legacy con CentOS/RHEL 5/6, bastaba con instalar con yum -y install iptables. Aunque hoy muchas distros nuevas favorecen nftables, iptables sigue presente en sistemas en producción y appliances.

La integración con servicios SysV permitía gestionar y persistir reglas: service iptables start|stop|restart y service iptables save, guardando en /etc/sysconfig/iptables. Para habilitar al arranque: chkconfig iptables on en los niveles 2–5.

En sistemas modernos, aunque cambian los wrappers, la idea persiste: define reglas, pruébalas y persístelas de forma que sobrevivan a reinicios, ya sea con herramientas del sistema o scripts.

Listados, borrados y edición de reglas con precisión

Para ver el estado con números de regla, usa iptables -L --line-numbers -n -v. Así podrás eliminar por índice con -D INPUT 3 o reemplazar con -R sin confusiones.

Si necesitas un borrado selectivo, limpia solo la cadena o tabla que toque (-F FORWARD o -F -t nat). Evita barridos globales en remoto sin “red de seguridad” o puedes perder el acceso SSH.

Como práctica habitual, coloca primero reglas que permitan tu sesión SSH, aplica cambios gradualmente y ten una ventana de reversión (por ejemplo, un cron que restaure reglas en 5 minutos si no confirmas).

Persistencia con iptables-save y iptables-restore

Para salvar tu configuración, iptables-save > /ruta/backup/iptables.rules genera un volcado legible por máquina con todas las tablas. Es perfecto para control de cambios y para migraciones.

Para cargarlo, usa iptables-restore < /ruta/backup/iptables.rules. Puedes automatizar la restauración al arranque con systemd, scripts init o un cron @reboot, asegurando que el cortafuegos quede activo tras un reinicio.

Añade a esto buenas prácticas operativas: ejecuta con privilegios adecuados, guarda los ficheros fuera de /tmp y alínealos con el entorno (interfaces y subredes correctas) para evitar sorpresas.

DMZ en detalle: un ejemplo completo y realista

Supón un cortafuegos Linux conectado a un router en modo “monopuesto” (sin NAT), con tres interfaces: eth0 (LAN 192.168.1.1/24), eth1 (DMZ 192.168.2.1/24) y eth2 (WAN con IP por DHCP). La DMZ aloja un servidor web Apache (192.168.2.2) y uno FTP (192.168.2.3).

Objetivos de la política: publicar HTTP/HTTPS y FTP de la DMZ hacia Internet, permitir administración por SSH desde la LAN al cortafuegos, y que la LAN pueda navegar (HTTP/HTTPS), transferir por FTP y resolver DNS. Todo lo demás, denegado.

A grandes rasgos: en filter/FORWARD permite tránsito LAN→WAN con respuesta, y WAN→DMZ solo a los puertos publicados con ESTABLISHED,RELATED para las respuestas. En nat/PREROUTING, aplica DNAT para publicar servicios; en nat/POSTROUTING, SNAT/MASQUERADE para salida de LAN/DMZ.

Ejemplos de aperturas: DNAT 80/443 hacia 192.168.2.2 y 21/20 (según modo) hacia 192.168.2.3 con los correspondientes FORWARD permitiendo esos puertos. Asegura el canal de control y datos para FTP (activo/pasivo) o limita el rango pasivo y refléjalo en el cortafuegos.

Para la LAN: permite salida a 80, 443, 21 y 53 y su retorno, aplicando NAT de salida en POSTROUTING. En el cortafuegos, autoriza SSH entrante solo desde la subred 192.168.1.0/24 y bloquea accesos no deseados desde la WAN.

No olvides la higiene: DROP a rangos inválidos por la WAN (privados, loopback, tu propia pública) y registra lo que te interese. Con políticas por defecto restrictivas y aperturas mínimas, tu exposición se reduce al mínimo imprescindible.

Buenas prácticas y trucos operativos

Trabaja siempre con un plan: documenta qué permites y por qué, verifica el flujo esperado con un diagrama simple y aplica reglas en el orden correcto para evitar solapamientos.

Usa combinación de módulos con cabeza: state/conntrack para respuestas, tcp con --syn en aperturas, y multiport para agrupar. Así simplificas y reduces el riesgo de inconsistencias.

Para entornos con cambios frecuentes, considera separar reglas por función: cadenas personalizadas (con -N) llamadas desde INPUT/OUTPUT/FORWARD, de modo que mantener o revertir piezas sea más limpio.

La transición a nftables está en marcha en muchas distros, pero si tu plataforma/producto usa iptables, conocer a fondo estas piezas te dará control total. Y si migras, entenderás sin problema el mapa mental equivalente en nftables.

Con lo visto ya dispones de una base sólida para desplegar y mantener iptables en producción: comprendes la arquitectura (tablas, cadenas y flujo), dominas los comandos esenciales, aplicas NAT y publicación con DNAT/SNAT y sabes montar una DMZ segura. A partir de aquí, queda ajustar a tu caso concreto, auditar periódicamente y mantener tus reglas tan claras como tu modelo de red.