deja pasar un paquete
Un firewall Linux con tres patas (Internet, LAN y DMZ) y un Windows Defender Firewall, simulados en el navegador con el comportamiento real de netfilter: cadenas, conntrack, DNAT y MASQUERADE. Con CyberFirewall Lab vas a trazar paquetes regla a regla, romper la configuración para ver qué pasa, escanearla con Nmap, publicar servicios nuevos y resolver los cuatro retos del laboratorio.
Qué vas a aprender
- Por qué un paquete va a la cadena INPUT, FORWARD u OUTPUT, y qué pasa cuando ninguna regla coincide.
- Que en Linux el orden de las reglas importa y en Windows no.
- Cómo conntrack deja volver las respuestas con una sola regla, y qué pasa si falta.
- Qué hacen DNAT y MASQUERADE, y por qué el filtrado ve la dirección ya traducida.
- Leer un escaneo de Nmap (open, closed, filtered, unfiltered, open|filtered) y saber qué regla lo provoca.
- Exportar las reglas a un script
iptables/nftablesreal.
Cómo usar esta guía
localStorage): si cierras la pestaña y vuelves, siguen ahí. Para empezar de cero se usa el botón ↺ Reset, que restaura las reglas de ejemplo de los dos motores.
La barra superior
El centro de la pantalla
La parte de abajo
Un firewall decide qué tráfico pasa entre redes de distinta confianza.
203.0.113.1. Los atacantes del laboratorio están en 198.51.100.x.172.16.0.0/24. Servidores que se publican a Internet: srv-web 172.16.0.10 (TCP 22, 80, 443 y UDP 53).192.168.1.0/24. Equipos internos: pc-50 192.168.1.50, un Windows con 135, 445 y 3389.Por qué existe la DMZ
Los servidores que dan servicio a Internet son los que más ataques reciben. Si uno cae, el atacante no debe poder saltar desde él a la red interna. Por eso se colocan en una red aparte (la DMZ), con una regla de oro: Internet puede llegar a lo publicado en la DMZ, la LAN puede llegar a la DMZ, pero la DMZ no puede abrir conexiones hacia la LAN.
Firewall de red y firewall de host
| Firewall de red | Firewall de host | |
|---|---|---|
| Protege | Redes enteras, desde el punto por donde pasa el tráfico | Solo al propio equipo |
| Ejemplo | Un Linux con iptables/nftables entre WAN, LAN y DMZ | Windows Defender Firewall, ufw en un servidor |
| Filtra el tráfico que lo atraviesa | Sí (cadena FORWARD) | No |
203.0.113.0/24 y 198.51.100.0/24, RFC 5737) o privadas (RFC 1918). No existen en Internet.La cadena no se elige: la decide el destino
| Cadena | Paquetes que recorre | Ejemplo |
|---|---|---|
| INPUT | Los que van al propio firewall (a una de sus IP) | SSH al firewall, ping al firewall |
| FORWARD | Los que lo atraviesan de una red a otra | La LAN navega, Internet visita la web de la DMZ |
| OUTPUT | Los que genera el firewall | El firewall consulta un DNS |
Antes y después del filtrado hay dos etapas de NAT: PREROUTING (al entrar, donde se hace el DNAT) y POSTROUTING (al salir, donde se hace el SNAT o MASQUERADE).
enrutado: PREROUTING (DNAT) → Enrutamiento → FORWARD → POSTROUTING (SNAT) al firewall: PREROUTING → Enrutamiento → INPUT → proceso local desde él: proceso local → OUTPUT → POSTROUTING
Cómo decide una cadena
- Mira las reglas de esa cadena de arriba abajo.
- La primera que coincide en todos sus campos decide (first match). Las de debajo ya no se miran.
- Si ninguna coincide, se aplica la política de la cadena.
| Acción | Qué hace |
|---|---|
| ACCEPT | Deja pasar. |
| DROP | Descarta en silencio: el que envía no recibe nada. |
| REJECT | Descarta y avisa: por defecto con un ICMP port-unreachable; con --reject-with tcp-reset (solo TCP), con un RST. |
Los campos de una regla
Interfaz de entrada (-i) y de salida (-o), protocolo, IP o red de origen y destino (con CIDR: 192.168.1.0/24), puertos (uno, lista 80,443 o rango 1024-65535) y estado conntrack. Un campo en ANY coincide con todo. Los puertos solo existen en TCP y UDP; en INPUT no hay interfaz de salida y en OUTPUT no hay interfaz de entrada.
Una conexión tiene dos sentidos: la ida (el cliente pide) y la vuelta (el servidor responde). Sin memoria, haría falta una regla para cada sentido, y la de vuelta abriría agujeros. El módulo conntrack apunta cada conexión en una tabla y etiqueta cada paquete con un estado:
| Estado | Significa |
|---|---|
| NEW | Abre una conexión que no estaba en la tabla (un SYN, el primer paquete UDP). |
| ESTABLISHED | Pertenece a una conexión ya vista, en cualquiera de los dos sentidos. |
| RELATED | Relacionado con una conexión existente (por ejemplo, un error ICMP sobre ella). |
| INVALID | No encaja con nada (un SYN+ACK que nadie pidió). Se descarta. |
El patrón de todo firewall con estado
- Al principio de cada cadena:
ESTABLISHED,RELATED → ACCEPT. Una sola regla deja volver todas las respuestas. - Después:
INVALID → DROP. - Después: una regla
NEW → ACCEPTpor cada cosa que se permita abrir. - Política DROP para el resto.
Una rareza real: tcp_loose
Por defecto, Linux tiene nf_conntrack_tcp_loose=1: un ACK suelto, sin SYN previo, se acepta como NEW para no romper conexiones si el firewall se reinicia. Por eso conviene exigir el flag SYN en las reglas NEW. El laboratorio reproduce este comportamiento.
Dos traducciones
| MASQUERADE (SNAT) | DNAT (port forwarding) | |
|---|---|---|
| Para qué | Que la LAN y la DMZ salgan a Internet con la IP pública | Publicar un servidor interno en la IP pública |
| Qué cambia | La IP de origen: 192.168.1.50 → 203.0.113.1 | La IP (y puerto) de destino: 203.0.113.1:443 → 172.16.0.10:443 |
| Dónde | POSTROUTING, al salir por eth0 | PREROUTING, nada más entrar por eth0 |
| La respuesta | conntrack la deshace al volver (de-SNAT) | conntrack la deshace al volver (de-DNAT) |
172.16.0.10), no con la IP pública. Una regla de FORWARD escrita contra 203.0.113.1 nunca coincide (reto 4). Por la misma razón, un DNAT puede publicar un puerto público distinto del interno: 8080 por fuera, 80 por dentro.Windows Defender Firewall: otra lógica
| Linux (iptables / nftables) | Windows Defender Firewall | |
|---|---|---|
| Qué filtra | Lo que llega, lo que sale y lo que atraviesa | Solo lo que llega al equipo o sale de él |
| Orden | Importa: gana la primera regla que coincide | No importa: bloqueo explícito > permiso explícito > acción predeterminada |
| Si nada coincide | Política de la cadena | Acción predeterminada de entrada o salida del perfil |
| Respuestas | Hace falta la regla ESTABLISHED,RELATED | Entran solas si la conexión se permitió |
| Rechazar | DROP calla; REJECT responde | Bloquear siempre descarta en silencio |
Windows aplica además perfiles según la red a la que está conectado: Dominio, Privado o Público. Una regla puede valer para todos o solo para uno.
Técnicas de escaneo
| Opción | Envía | Sirve para |
|---|---|---|
-sS | Un SYN y no completa la conexión (half-open) | Saber qué puertos están abiertos |
-sT | Conexión completa con connect() | Lo mismo, sin privilegios de root |
-sA | Un ACK suelto | Mapear el firewall: no dice si un puerto está abierto, sino si está filtrado |
-sU | Datagramas UDP | Puertos UDP (DNS, NTP, SNMP…) |
Los estados y qué los provoca
| Estado | Respuesta (REASON) | Causa típica |
|---|---|---|
| open | syn-ack / udp-response | Una regla deja pasar y hay un servicio escuchando |
| closed | reset | Se llega al equipo pero no escucha nadie, o un REJECT --reject-with tcp-reset |
| filtered | no-response o port-unreach | DROP (silencio) o REJECT genérico (ICMP) |
| unfiltered | reset a un -sA | El ACK atraviesa el firewall y alguien responde RST |
| open|filtered | no-response en UDP | En UDP, el silencio puede ser un puerto abierto que no contesta o un DROP |
Pulsa ▶ Abrir el laboratorio. Comprueba que está activo Linux (iptables/nftables) y pulsa ↺ Reset. El navegador pregunta si quieres restaurar las reglas de ejemplo: Aceptar.
Pulsa 🛡 Auditoría.
La configuración de ejemplo es correcta. En este ejercicio vas a entender por qué, romperla para ver las consecuencias y ampliarla sin perder el 100.
Usa el desplegable Todas las cadenas de la tabla para ver solo INPUT, después solo FORWARD. Vuelve a Todas las cadenas.
Compara con el patrón de la teoría 3. ¿Qué reglas son las de vuelta? ¿Por qué hay dos?
Ver respuesta
ESTABLISHED,RELATED → ACCEPT). Hay una por cadena: la #1 para las respuestas que llegan al firewall (INPUT) y la #2 para las que lo atraviesan (FORWARD). Cada cadena se evalúa por separado.Pulsa Calculadora CIDR. Haz estas tres pruebas con Comprobar bit a bit:
| Red de la regla | IP a comprobar |
|---|---|
192.168.1.0/24 | 192.168.1.45 |
172.16.0.0/12 | 172.31.5.5 |
172.16.0.0/12 | 172.32.0.1 |
IP AND máscara y mira si sale la red. Por eso 172.32.0.1 no es privada aunque «se parezca» a 172.16.En INYECTOR Y TRAZADOR, elige LAN → web de la DMZ (SYN) en Paquetes de ejemplo… y pulsa ▶ Trazar paquete. Mira cómo se iluminan las reglas una a una.
eth1 (LAN) → FORWARD → eth2 (DMZ). conntrack: NEW. Debajo: ✘ #2 … estado NEW no está en ESTABLISHED,RELATED · ✘ #3 … · ✘ #8 La LAN sale a Internet: salida por eth0 y el paquete sale por eth2 · ✔ #9 … coinciden todos los campos → ACCEPT.¿Por qué no se mira la regla #10 ni la #11?
Ver respuesta
Pulsa ⇄ Respuesta: el formulario se rellena con el paquete de vuelta (de 172.16.0.10:80 a 192.168.1.50:51200, flags SYN+ACK). Pulsa ▶ Trazar paquete.
eth2 (DMZ) → FORWARD → eth1 (LAN). conntrack: ESTABLISHED — Respuesta de la conexión #N (vista en los dos sentidos).Traza LAN → web de Internet (sale con MASQUERADE) y después su ⇄ Respuesta.
POSTROUTING SNAT: 192.168.1.50:51320 → 203.0.113.1:51320. Respuesta: el formulario trae destino 203.0.113.1:51320; el trazado da ACEPTADO por la regla #2 y PREROUTING de-SNAT: 203.0.113.1:51320 → 192.168.1.50:51320.¿Por qué la respuesta de Internet va dirigida a 203.0.113.1 y no a 192.168.1.50?
Ver respuesta
Traza Internet → 203.0.113.1:443 (DNAT a la DMZ) y su respuesta.
PREROUTING DNAT: 203.0.113.1:443 → 172.16.0.10:443, ruta eth0 (WAN) → FORWARD → eth2 (DMZ), ACEPTADO por la regla #10. Respuesta: ACEPTADO por la #2, con POSTROUTING de-DNAT: 172.16.0.10:443 → 203.0.113.1:443.El paquete iba a la IP del firewall (203.0.113.1). ¿Por qué recorre FORWARD y no INPUT?
Ver respuesta
Traza estos tres paquetes de ejemplo y apunta quién decide:
| Paquete de ejemplo | Veredicto |
|---|---|
| Internet → SSH del firewall | DESCARTADO (DROP) · Regla #7 (cadena INPUT) |
| Internet → RDP de un PC de la LAN | DESCARTADO (DROP) · Política de FORWARD: DROP |
| DMZ comprometida → SMB de la LAN | RECHAZADO (REJECT) · Regla #11 · responde con ICMP port-unreachable |
El RDP desde Internet no tiene ninguna regla de bloqueo. ¿Por qué no pasa?
Ver respuesta
Traza los tres últimos de la lista:
| Paquete de ejemplo | Veredicto |
|---|---|
| ACK suelto desde Internet (sondeo -sA) | DESCARTADO · Regla #7. conntrack: NEW, con la explicación de nf_conntrack_tcp_loose=1 |
| SYN+ACK sin conexión previa (INVALID) | DESCARTADO · Regla #3. conntrack: INVALID |
| IP de la LAN entrando por la WAN (spoofing) | DESCARTADO · Política de FORWARD: DROP |
El paquete falsificado lleva origen 192.168.1.50 y entra por eth0. ¿Por qué no lo acepta la regla #9 («La LAN usa la web de la DMZ»)?
Ver respuesta
Abajo, abre la pestaña conntrack y después NAT. Mira también Registros y la columna TRÁFICO de la tabla de reglas.
[SNAT] o [DNAT]. NAT: las traducciones activas, como DNAT 198.51.100.25:50500 ➔ 203.0.113.1:443 ➔ 172.16.0.10:443. Registros: líneas del kernel como [CFW r10 ACCEPT] IN=eth0 OUT=eth2 … PROTO=TCP … DPT=443 … SYN.Pulsa conntrack -F para vaciar la tabla antes de seguir.
Con la tabla conntrack vacía, pulsa el 🟢 de la regla #2 (FORWARD, vuelta): pasa a ⚪ (desactivada). Traza LAN → web de Internet y después su ⇄ Respuesta. Abre la 🛡 Auditoría.
Vuelve a activar la #2 (⚪ → 🟢) y vacía conntrack.
Un usuario dice: «tengo Internet a medias: el navegador conecta pero nunca carga nada». ¿Qué regla revisarías primero?
Ver respuesta
ESTABLISHED,RELATED) en FORWARD: que exista y que esté por encima de cualquier DROP. Conntrack sabe que es una respuesta, pero alguna regla tiene que aceptarla.En la barra superior, cambia FORWARD a ACCEPT. Traza Internet → RDP de un PC de la LAN y abre la Auditoría.
Vuelve a poner FORWARD en DROP y vacía conntrack.
Pulsa ⚡ Nmap. Objetivo 203.0.113.1 · IP pública del firewall, técnica -sS · SYN (half-open), desde Internet (198.51.100.99). Pulsa Ejecutar escaneo.
sudo nmap -Pn -sS --reason -p 21,22,23,53,80,135,443,445,3389,8080 203.0.113.1. 80/tcp open y 443/tcp open con syn-ack ttl 63; los otros 8 puertos, filtered con no-response. En POR QUÉ CADA RESULTADO: el 22, DROP en la regla #7; el resto, política DROP de INPUT.El escaneo va a la IP del firewall, pero 80 y 443 responden con TTL 63. ¿Quién está respondiendo?
Ver respuesta
Pulsa + Nueva regla y, arriba del formulario, la plantilla Rechazar con RST. Rellena: Rechazar TCP 8080 con RST, cadena INPUT, acción REJECT, TCP, entra por eth0 · WAN, puerto de destino 8080. Pulsa Guardar regla y repite el escaneo.
reset ttl 64 — REJECT --reject-with tcp-reset (regla #12): el firewall finge que el puerto está cerrado.¿Por qué ahora el TTL es 64?
Ver respuesta
Escanea 192.168.1.50 · pc-50 (LAN) con -sS desde DMZ (172.16.0.66): es lo que haría un atacante que ha tomado el servidor web.
port-unreach ttl 64: REJECT (regla #11) devuelve ICMP port-unreachable: con TCP Nmap lo interpreta como filtrado.tcp-reset imita un puerto cerrado (closed, reset).Vuelve a escanear 203.0.113.1 desde Internet, ahora con -sA · ACK (mapear reglas).
reset); el resto, filtered. Para el 80 y el 443: El ACK atraviesa el firewall (como NEW por tcp_loose) y el equipo responde RST.Con -sA el 8080 aparece igual que el 80 y el 443. ¿Qué información pierde el atacante y cuál gana?
Ver respuesta
Escanea 203.0.113.1 desde Internet con -sU · UDP.
no-response — Nmap no recibe nada y no puede distinguir abierto de filtrado.A partir de aquí la guía te dice qué conseguir y dónde, pero ya no cada clic.
Publica la web de la DMZ también en el puerto público 8080: en la pestaña NAT de abajo, añade un port forwarding TCP 8080 ➔ 172.16.0.10 : 80 (botón Añadir). No toques las reglas de filtrado. Escanea otra vez 203.0.113.1 desde Internet con -sS.
syn-ack ttl 63.Dos preguntas. ¿Qué regla de FORWARD deja pasar el 8080, si no has creado ninguna? ¿Y por qué la regla #12 (REJECT del 8080) ya no actúa?
Pista
198.51.100.25:50700 a 203.0.113.1:8080 y lee las líneas de NAT y de la cadena.Ver solución
PREROUTING DNAT: 203.0.113.1:8080 → 172.16.0.10:80 y lo acepta la regla #10, que permite el puerto 80: el filtrado ve el puerto ya traducido. Y la #12 está en INPUT; tras el DNAT, el paquete ya no va al firewall sino a la DMZ, así que recorre FORWARD.El servidor de la DMZ también es DNS (UDP 53). Publícalo en la IP pública y compruébalo con -sU desde Internet. Hazlo en dos pasos y escanea después de cada uno.
- Port forwarding UDP 53 ➔ 172.16.0.10 : 53.
- Una regla de filtrado que lo permita. En el formulario, prueba primero a dejar el protocolo en Cualquiera con puerto de destino 53.
Pista
Ver solución
udp-response ttl 63. Auditoría: 100/100.Crea esta regla: Bloquear HTTPS de la DMZ desde Internet, FORWARD, DROP, TCP, entra por eth0, sale por eth2, NEW, destino 172.16.0.10, puerto 443. Queda la última de la tabla.
Súbela con ▲ hasta que quede justo encima de la #10 (son 4 pulsaciones) y escanea 203.0.113.1 con -sS desde Internet.
Bórrala con 🗑.
Abajo, la #14 no hacía nada; arriba, cambió el resultado. ¿Por qué la #10 no se marcó como sombreada cuando la #14 estaba encima?
Ver respuesta
Mira la pestaña iptables del panel de script y después nftables.
iptables -A INPUT -i eth0 -p tcp --dport 8080 … -j REJECT --reject-with tcp-reset, iptables -A FORWARD -i eth0 -o eth2 -p udp -d 172.16.0.10 --dport 53 … -j ACCEPT y, en la sección NAT, -j DNAT --to-destination 172.16.0.10:80 (8080) y 172.16.0.10:53 (UDP). nftables: policy drop en input y forward, reject with tcp reset y dnat to 172.16.0.10:80.Pulsa ⇩ Exportar y descarga iptables .sh y Copia de seguridad .json: se guardan cyberfirewall-iptables.sh y cyberfirewall-config.json. Son parte de la entrega, y el .json lo necesitarás en la fase 8.
iptables -F) y pone la política en DROP. En una máquina remota te dejaría sin acceso si las interfaces no se llaman igual.
Pulsa 🎯 Retos y, en el RETO 2, Cargar reto. Lee las tres reglas y pulsa Comprobar (vuelve a abrir Retos).
Arréglalo solo reordenando (sin borrar ni desactivar) y comprueba.
Pista
Ver solución
Carga el RETO 4 y comprueba. Después vacía conntrack y traza un SYN de 198.51.100.25:50900 a 203.0.113.1:443.
PREROUTING DNAT: 203.0.113.1:443 → 172.16.0.10:443 y ✘ #2 HTTPS publicado: destino 172.16.0.10 fuera de 203.0.113.1.Pista
Ver solución
203.0.113.1 a 172.16.0.10 y guarda. Comprobar: ✔ ¡Reto superado!, y Internet sigue sin llegar al SSH de la DMZ ni a la LAN.Carga el RETO 1 y comprueba.
La respuesta del PC no vuelve. ¿Significa eso que el ataque ha fallado?
Ver respuesta
Prueba a desactivar la regla #2 y comprueba otra vez.
Pista
Ver solución
Pulsa Windows Defender. Los retos de Linux no han tocado sus reglas.
Traza los ocho paquetes de ejemplo de Windows.
| Paquete | Veredicto |
|---|---|
| Internet → HTTPS del servidor | PERMITIDO · Regla #1 |
| Internet → SMB (445) | BLOQUEADO · Regla #3 |
| Internet → RDP (3389) | BLOQUEADO · Acción predeterminada |
| LAN → RDP (3389) | BLOQUEADO · Acción predeterminada |
| Ping desde la LAN | PERMITIDO · Regla #4 |
| El servidor abre Telnet hacia fuera | BLOQUEADO · Regla #5 |
| El servidor navega (HTTPS saliente) | PERMITIDO · acción de salida |
| Tráfico que solo atraviesa el equipo | NO LO EVALÚA |
La regla #2 permite RDP desde la LAN. ¿Por qué se bloquea «LAN → RDP»? ¿Y por qué no evalúa el último paquete?
Pista
Ver solución
Traza Internet → HTTPS del servidor y su ⇄ Respuesta. Después crea un permiso: SMB para la LAN, Entrada, permitir, TCP, origen 192.168.1.0/24, puerto de destino 445, perfil Todos. Traza un SYN de 192.168.1.50:50510 a 192.168.1.1:445 y abre la Auditoría.
Borra la regla #6.
En Linux, ¿qué habría pasado si pones ese permiso encima del bloqueo?
Ver respuesta
Carga el RETO 3 y comprueba.
Pista
Ver solución
Los retos han sustituido tus reglas. Recupéralas con el archivo cyberfirewall-config.json de la fase 5.
Pista
Sin mirar la guía, predice el resultado de estos tres paquetes y después trázalos (vacía conntrack antes):
- TCP SYN de
198.51.100.40:51000a203.0.113.1:8080. - UDP de
198.51.100.40:52000a203.0.113.1:53. - TCP SYN de
172.16.0.10:39000a192.168.1.50:3389.
Ver solución
Qué entregas
cyberfirewall-iptables.shycyberfirewall-config.jsonde la fase 5.- Las respuestas a estas preguntas, con tus propias palabras:
- Explica por qué un paquete dirigido a la IP pública del firewall puede acabar en la cadena FORWARD y no en INPUT.
- Tu firewall tiene la regla de vuelta en INPUT pero no en FORWARD. ¿Qué funciona y qué no? Usa lo que viste en la fase 3.
- Un compañero quiere bloquear el puerto 8080 desde Internet y se debate entre DROP, REJECT y REJECT con tcp-reset. Explica qué vería un atacante con Nmap en cada caso y cuál elegirías.
- En el reto 1, el ataque de la DMZ a la LAN «no recibía respuesta». Explica por qué eso no es seguridad.
- Explica con el reto 3 por qué en Windows no basta con añadir un permiso encima de un bloqueo, y cómo resolverías «RDP solo para una IP».
Autoevaluación
Marca lo que eres capaz de hacer sin mirar la guía:
Tu progreso en esta guía
—
| Término | Significado |
|---|---|
| ACCEPT / DROP / REJECT | Dejar pasar, descartar en silencio, descartar avisando. |
| Cadena | Lista de reglas que se evalúa en un punto del recorrido: INPUT, FORWARD u OUTPUT. |
| CIDR | Notación de red con prefijo: 192.168.1.0/24. |
| conntrack | Seguimiento de conexiones del kernel Linux: da a cada paquete su estado. |
| DMZ | Red separada para los servidores publicados a Internet. |
| DNAT | Traducción de la dirección de destino; publica un servicio interno (port forwarding). |
| ESTABLISHED / RELATED | Paquete de una conexión ya vista / relacionado con ella. |
| First match | En iptables decide la primera regla que coincide. |
| INVALID | Paquete que conntrack no puede asociar a ninguna conexión. |
| MASQUERADE | SNAT automático con la IP de la interfaz de salida. |
| NEW | Paquete que abre una conexión nueva. |
| nftables | Sucesor de iptables en Linux, con la misma base (netfilter). |
| Perfil (Windows) | Dominio, Privado o Público: conjunto de reglas según la red conectada. |
| Política | Acción de una cadena cuando ninguna regla coincide. |
| PREROUTING / POSTROUTING | Etapas de NAT al entrar (DNAT) y al salir (SNAT). |
| Regla sombreada | Regla que nunca decide porque otra anterior la cubre entera con otra acción. |
| RST | Flag TCP que rechaza una conexión; Nmap lo lee como puerto cerrado. |
| tcp_loose | Opción de conntrack que acepta un ACK suelto como NEW. |
| TTL | Contador de saltos de IP; delata cuántos routers ha cruzado una respuesta. |