Configuración de iptables/nftables para microsegmentación de red
Introducción
En entornos de hosting y servidores modernos, la seguridad de la red ya no puede depender únicamente de un firewall perimetral. La microsegmentación de red, implementada mediante iptables (para sistemas legacy con netfilter) o nftables (su sucesor moderno en Linux), permite dividir la infraestructura en zonas lógicas con políticas de control de acceso granulares. Este artículo detalla cómo diseñar e implementar una arquitectura de microsegmentación utilizando estas herramientas, cubriendo desde principios fundamentales hasta configuraciones avanzadas con flujos de trabajo paso a paso.
Fundamentos de Microsegmentación con Netfilter
¿Por qué microsegmentación?
La microsegmentación mitiga el movimiento lateral de amenazas. En un servidor de hosting compartido, por ejemplo, un cliente comprometido no debería poder alcanzar los contenedores de otros clientes, la base de datos interna o el panel de control. Con iptables/nftables, segmentamos por:
- Interfaces de red:
eth0(pública),eth1(almacenamiento),docker0(contenedores). - Direcciones IP origen/destino: Subredes de clientes, rangos de administración.
- Puertos y protocolos: TCP/UDP específicos para servicios.
- Estados de conexión:
stateen iptables,ct stateen nftables.
iptables vs nftables: tabla comparativa
| Característica | iptables | nftables |
|---|---|---|
| Sintaxis | Lineal, cadenas fijas (INPUT, OUTPUT, FORWARD) | Jerárquica, tablas y cadenas con nombres arbitrarios |
| Rendimiento | Bueno, pero con conjuntos grandes se degrada | Superior, compilación en bytecode, conjuntos atómicos |
| Gestión de estado | Módulo conntrack | Nativo, ct |
| Conjuntos (sets) | Limitado a ipset | Nativo: set, map, vmap |
| Atómico | No (cambios secuenciales) | Sí (transacciones con nft -f) |
| Legibilidad | Baja para reglas complejas | Alta, estructura de árbol |
| Compatibilidad | Total con scripts legacy | Requiere migración, pero coexiste |
Nota importante: A partir de RHEL 9, Debian 12 y Ubuntu 22.04,
nftableses el firewall por defecto.iptablessuele ser un wrapper anft(modo legacy). Recomendamos implementar nuevas configuraciones directamente ennftables.
Diseño de la Arquitectura de Microsegmentación
Definición de zonas lógicas
Para un servidor de hosting con múltiples servicios, definimos las siguientes zonas:
- ZONA_PUBLICA: Interfaz
eth0, tráfico desde Internet. - ZONA_ADMIN: Subred de gestión (ej. 10.0.0.0/24).
- ZONA_WEB: Contenedores/VM con sitios web (172.16.0.0/24).
- ZONA_DB: Servidores de base de datos (172.16.1.0/24).
- ZONA_CACHE: Redis/Memcached (172.16.2.0/24).
- ZONA_ALMACENAMIENTO: NFS/iSCSI (192.168.100.0/24).
Políticas por defecto
Aplicamos el principio de mínimo privilegio:
- INPUT: DROP por defecto (solo tráfico entrante explícitamente permitido).
- OUTPUT: ACCEPT por defecto (pero podemos restringir si es necesario).
- FORWARD: DROP por defecto (nada se reenvía sin regla explícita).
Implementación Paso a Paso con nftables
1. Estructura de tablas y cadenas
Creamos una tabla microseg con familias inet (IPv4+IPv6) para simplicidad:
nft add table inet microseg
nft add chain inet microseg input { type filter hook input priority 0 \; policy drop \; }
nft add chain inet microseg output { type filter hook output priority 0 \; policy accept \; }
nft add chain inet microseg forward { type filter hook forward priority 0 \; policy drop \; }
Explicación:
hook inputmaneja paquetes entrantes al servidor,forwardcontrola tráfico que atraviesa el servidor (routing entre interfaces),outputgobierna paquetes generados localmente. La políticadropen input y forward fuerza a escribir reglas explícitas.
2. Reglas para tráfico de bucle local
nft add rule inet microseg input iif lo accept
nft add rule inet microseg output oif lo accept
Permitimos todo el tráfico en lo (loopback) porque es esencial para servicios locales.
3. Segmentación por interfaces
3.1. Zona pública (eth0)
Solo servicios expuestos al exterior:
# SSH desde cualquier origen (con rate limiting)
nft add rule inet microseg input iif eth0 tcp dport 22 ct state new limit rate 5/minute accept
nft add rule inet microseg input iif eth0 tcp dport 22 ct state new log prefix "SSH_ATTEMPT: " drop
# HTTP/HTTPS
nft add rule inet microseg input iif eth0 tcp dport { 80, 443 } accept
# ICMP (ping) limitado
nft add rule inet microseg input iif eth0 icmp type echo-request limit rate 10/second accept
nft add rule inet microseg input iif eth0 icmp type echo-request drop
Por qué:
ct state newcombinado conlimit ratepreviene ataques de fuerza bruta SSH. El logging antes del drop permite auditoría. HTTP/HTTPS se permite sin restricción de origen (son servicios públicos).
3.2. Zona de administración (subred 10.0.0.0/24)
Acceso completo desde la red interna de gestión:
nft add rule inet microseg input iif eth0 ip saddr 10.0.0.0/24 accept
nft add rule inet microseg forward iif eth0 oif eth1 ip saddr 10.0.0.0/24 accept
3.3. Zona web a zona DB
Los contenedores web (172.16.0.0/24) solo pueden acceder a MySQL (3306) y PostgreSQL (5432) en la zona DB:
nft add rule inet microseg forward iif eth0 ip saddr 172.16.0.0/24 oif eth1 ip daddr 172.16.1.0/24 tcp dport { 3306, 5432 } accept
nft add rule inet microseg forward iif eth0 ip saddr 172.16.0.0/24 oif eth1 ip daddr 172.16.1.0/24 drop
3.4. Zona cache (Redis) solo accesible desde web
nft add rule inet microseg forward iif eth0 ip saddr 172.16.0.0/24 oif eth2 ip daddr 172.16.2.0/24 tcp dport 6379 accept
nft add rule inet microseg forward iif eth0 ip saddr 172.16.0.0/24 oif eth2 ip daddr 172.16.2.0/24 drop
4. Gestión de estado (connection tracking)
Para permitir respuestas de conexiones establecidas:
nft add rule inet microseg input ct state established,related accept
nft add rule inet microseg forward ct state established,related accept
Esto es crítico: sin estas reglas, las respuestas de paquetes salientes (ej. actualizaciones desde servidores web) serían bloqueadas en el hook input/forward.
5. Uso de conjuntos (sets) para escalabilidad
Cuando tenemos múltiples IPs de administración o puertos, usamos sets:
nft add set inet microseg admin_ips { type ipv4_addr \; flags interval \; }
nft add element inet microseg admin_ips { 10.0.0.0/24, 192.168.1.0/24 }
nft add rule inet microseg input ip saddr @admin_ips accept
Ventaja: Los sets son atómicos y más rápidos que múltiples reglas. Se pueden actualizar con
nft add elementsin recargar todo el firewall.
6. Políticas de salida (output filtering)
Aunque la política por defecto es accept, podemos restringir salidas para contenedores:
nft add chain inet microseg output_web { type filter hook output priority 1 \; }
nft add rule inet microseg output_web oif eth0 ip saddr 172.16.0.0/24 tcp dport { 80, 443 } accept
nft add rule inet microseg output_web oif eth0 ip saddr 172.16.0.0/24 drop
Implementación con iptables (para sistemas legacy)
1. Políticas por defecto
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
2. Reglas de microsegmentación (equivalente a nftables)
# Loopback
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
# Estado establecido
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
# SSH con rate limiting
iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -m limit --limit 5/min -j ACCEPT
iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -j LOG --log-prefix "SSH_BLOCK: " --log-level 4
iptables -A INPUT -i eth0 -p tcp --dport 22 -m state --state NEW -j DROP
# Web público
iptables -A INPUT -i eth0 -p tcp -m multiport --dports 80,443 -j ACCEPT
# Administración
iptables -A INPUT -i eth0 -s 10.0.0.0/24 -j ACCEPT
iptables -A FORWARD -i eth0 -o eth1 -s 10.0.0.0/24 -j ACCEPT
# Web a DB
iptables -A FORWARD -i eth0 -s 172.16.0.0/24 -o eth1 -d 172.16.1.0/24 -p tcp -m multiport --dports 3306,5432 -j ACCEPT
iptables -A FORWARD -i eth0 -s 172.16.0.0/24 -o eth1 -d 172.16.1.0/24 -j DROP
Limitación iptables: No hay conjuntos nativos; usar
ipsetpara escalar:ipset create admin_ips hash:net ipset add admin_ips 10.0.0.0/24 iptables -A INPUT -i eth0 -m set --match-set admin_ips src -j ACCEPT
Automatización y Persistencia
nftables: Guardado y restauración
nft list ruleset > /etc/nftables.conf
nft -f /etc/nftables.conf # Recarga atómica
Para systemd:
systemctl enable nftables
systemctl start nftables
iptables: Script de persistencia
iptables-save > /etc/iptables/rules.v4
ip6tables-save > /etc/iptables/rules.v6
Y en /etc/network/interfaces o con iptables-persistent.
Monitoreo y Logging
Logging selectivo por zona
# nftables
nft add rule inet microseg input iif eth0 ip saddr 0.0.0.0/0 log prefix "DROP_PUBLIC: " drop
# iptables
iptables -A INPUT -i eth0 -j LOG --log-prefix "DROP_PUBLIC: " --log-level 4
iptables -A INPUT -i eth0 -j DROP
Recomendación: Usar
limit rateen logs para evitar llenar disco:nft add rule inet microseg input iif eth0 log prefix "DROP_PUBLIC: " limit rate 10/minute drop
Ver contadores de reglas
nft list ruleset -a
iptables -L -v -n --line-numbers
Pruebas de la Microsegmentación
1. Verificar conectividad esperada
# Desde admin a web
ping 172.16.0.1 # Debe funcionar
# Desde web a DB
nc -zv 172.16.1.10 3306 # Debe funcionar
# Desde web a cache
nc -zv 172.16.2.10 6379 # Debe funcionar
2. Verificar bloqueos
# Desde Internet a DB (puerto 3306)
nc -zv <IP_PUBLICA> 3306 # Debe fallar
# Desde web a Internet (excepto 80/443)
curl http://google.com:22 # Debe fallar
3. Auditoría con nft monitor
nft monitor trace # Muestra paquetes evaluados contra reglas
Estrategias Avanzadas
Microsegmentación por etiquetas (con nftables maps)
Podemos usar vmap para decisiones basadas en puerto destino:
nft add map inet microseg port_policy { type inet_service : verdict \; }
nft add element inet microseg port_policy { 22 : accept, 80 : accept, 443 : accept, 3306 : drop }
nft add rule inet microseg input iif eth0 tcp dport vmap @port_policy
Integración con Docker/Containers
Docker crea interfaces docker0 y veth*. Regla para aislar contenedores:
# Solo contenedores en la misma red pueden comunicarse
nft add rule inet microseg forward iif docker0 oif docker0 ip saddr 172.17.0.0/16 ip daddr 172.17.0.0/16 accept
nft add rule inet microseg forward iif docker0 oif docker0 drop
Nota: Docker manipula iptables/nftables por defecto. Para evitar conflictos, usar
--iptables=falseen el daemon de Docker y gestionar manualmente.
Resolución de Problemas Comunes
| Problema | Causa probable | Solución |
|---|---|---|
| No puedo acceder a SSH | Regla de rate limiting demasiado restrictiva | Aumentar limit rate o verificar con nft monitor trace |
| Contenedores no llegan a DB | Falta regla forward o ruta incorrecta | Verificar ip route y reglas forward con nft list chain |
| Logs masivos en syslog | Log sin limit rate | Añadir limit rate 10/minute a reglas de log |
| Reglas se pierden al reiniciar | No se guardó ruleset | Configurar persistencia con systemd o script |
Conclusión
La microsegmentación con nftables (o iptables legacy) es una técnica fundamental para hardening de servidores de hosting. Al implementar políticas de mínimo privilegio por zona, reducimos drásticamente la superficie de ataque y limitamos el movimiento lateral. nftables ofrece ventajas claras en rendimiento, legibilidad y atomicidad sobre iptables, por lo que recomendamos su adopción en nuevas instalaciones.
El flujo presentado —definir zonas, crear tablas/cadenas, aplicar reglas con sets, gestionar estado, y automatizar— proporciona una base sólida para entornos desde VPS individuales hasta clústeres de hosting. La clave está en la revisión periódica de reglas y logs, adaptando la segmentación a medida que evoluciona la infraestructura.
