Firewalls de base a pro: análisis del curso interactivo Basic Firewalls

Un firewall mal entendido se convierte en una caja que "está porque tiene que estar"; un firewall bien entendido es la primera decisión de ingeniería de cualquier arquitectura segura. El curso interactivo Basic Firewalls ataca precisamente ese malentendido: no enseña a pulsar botones en un panel comercial, sino a razonar como quien diseña política de control de tráfico. Qué se permite, qué se bloquea, qué se registra y quién responde de cada excepción.

El curso está pensado para estudiantes de redes, ciberseguridad y administración de sistemas, y también para perfiles de desarrollo que de repente tienen que exponer un servicio a Internet y no saben por dónde empezar. Yo lo usaría como material de arranque antes de tocar cualquier firewall real: pfSense, iptables/nftables, un grupo de seguridad de cloud o un WAF gestionado. Quien lo completa sale con un modelo mental claro de zonas, reglas con estado, NAT, inspección de capa 7 y operación continua, además de un vocabulario común para discutir decisiones con equipos de seguridad.

En este artículo recorro el curso sección a sección (verificando cada detalle contra su código fuente), explico cómo está construido técnicamente y propongo un plan de estudio concreto. La tesis del curso cabe en una frase que aparece en su propia portada: un firewall no protege por magia: aplica política sobre tráfico observable.

Qué encontrarás en el curso

Basic Firewalls es una aplicación web estática de una sola página, publicada en GitHub Pages, que combina once secciones: un hero con el modelo mental de política y decisión, una franja de datos clave, un mapa interactivo del ecosistema de firewalls, un simulador paso a paso de decisión de flujo, una anatomía de reglas, un laboratorio local de análisis de flujo, una checklist de riesgos operativos, un quiz autocorregido con explicaciones, una guía rápida de repaso, un glosario esencial y un directorio filtrable de referencias oficiales. Todo el contenido está en español y se puede recorrer en orden o saltando a lo que interese desde la navegación superior: Mapa, Flujo, Reglas, Lab, Riesgos, Quiz y Refs.

La franja de datos clave resume tres ideas que atraviesan todo el curso: un mínimo de cinco campos por regla (origen, destino, servicio, acción y registro), un alcance que va de L3 a L7 (desde filtrado IP y puertos hasta proxy, TLS, identidad y WAF) y un objetivo de cero confianza implícita: cada acceso debe justificarse.

Anatomía del contenido, sección a sección

El modelo mental: política sobre tráfico observable

La portada evita el marketing y plantea el enfoque defensivo desde el primer párrafo: aprender a decidir qué tráfico permitir, bloquear, registrar y revisar. La tarjeta lateral del hero condensa el mensaje: un firewall define zonas, reglas, estado, excepciones y logs. Es una definición operativa, no académica, y marca el tono del resto del curso: cada concepto se presenta por su función en la decisión, no como entry de enciclopedia.

El mapa interactivo del ecosistema de firewall

El corazón conceptual del curso es un grafo interactivo con once componentes conectados por quince relaciones. Cada nodo tiene tipo, descripción y tres detalles accionables. Los componentes son: Política (gobierno: traduce requisitos de negocio y riesgo en reglas verificables), Zonas (arquitectura: separan niveles de confianza), ACL (regla: lista ordenada donde el orden importa y las reglas sombra son deuda), Estado (motor: recuerda conexiones para permitir respuestas legítimas), NAT (traducción: cambia direcciones o puertos pero no equivale a firewall), Proxy (intermediario: termina o media conversaciones de aplicación), WAF (aplicación: inspecciona HTTP contra inyección o XSS), NGFW (inspección: añade visibilidad de aplicación, usuarios, reputación e IPS), Logs (telemetría: permiten probar, depurar y detectar), Revisión (operación: evita que la política se degrade) y Zero trust (estrategia: reduce confianza implícita sin eliminar firewalls).

Lo interesante es que el grafo codifica dependencias reales: la política conecta con zonas y ACL; el estado y el NAT alimentan los logs; el NGFW se apoya en proxy y WAF; la revisión alimenta la política; y zero trust conecta con política y zonas. Pulsar un nodo muestra su ficha completa, así que el mapa funciona como un glosario navegable con estructura causal. Las aristas cuentan una historia: los logs son el punto de convergencia de casi todos los motores, y sin revisión la política se corrompe con el tiempo.

El simulador de decisión de flujo en seis pasos

La sección "Flujo" descompone qué le ocurre a un paquete cuando atraviesa un firewall, en seis etapas navegables con anterior y siguiente:

1. Entrada: identificar zona y dirección. El flujo llega por una interfaz física o virtual; la zona de origen marca el primer límite de confianza y la dirección puede ser inbound, outbound o lateral.
2. Normalización: validar paquete y sesión. Antes de decidir se descartan campos inválidos y se comprueba si el flujo pertenece a una sesión existente: cabeceras válidas, estado TCP o UDP, fragmentación e ICMP necesarios.
3. Coincidencia: buscar regla aplicable. Las reglas se recorren en orden y la primera coincidencia válida define la acción, comparando origen y destino, servicio o aplicación y, si existe, usuario, etiqueta o contexto.
4. Inspección: aplicar controles profundos. Si la política lo requiere, el flujo pasa por inspección TLS, IPS, antivirus, proxy o WAF, sopesando riesgo del destino, tipo de aplicación y coste de latencia y privacidad.
5. Acción: permitir, bloquear o modificar. Deny silencioso o reject explícito, NAT antes o después según plataforma, rate limit para abuso.
6. Evidencia: registrar y revisar. La decisión debe dejar evidencia: regla aplicada, bytes y duración, motivo de bloqueo y severidad.

Este es el esquema que yo echaría en falta en la mayoría de cursos: la mayoría explican qué es una ACL, pero no qué pasa dentro del motor entre la llegada del paquete y la línea de log.

  Paquete entrante
        |
  [1] Interfaz + zona origen + dirección
        |
  [2] Validar cabeceras / estado de sesión
        |
  [3] Recorrer ACL en orden --> primera coincidencia
        |
  [4] Inspección (TLS, IPS, proxy, WAF)
        |
  [5] Acción: allow / deny / reject / NAT / rate-limit
        |
  [6] Log: regla, bytes, duración, motivo

Anatomía de una regla: siete partes

La sección "Reglas" descompone una regla de firewall en siete partes seleccionables, cada una con ejemplos concretos:

• Origen (quién inicia): zona, red, host, identidad o grupo, como "LAN usuarios", "grupo administradores", "subnet 10.20.0.0/16", "workload con etiqueta app=api".
• Destino (qué se protege): cuanto más concreto el recurso, menor superficie de ataque, como "DMZ web", "base de datos interna", "resolver DNS corporativo", "servicio cloud publicado".
• Servicio (protocolo y puerto): transporte, puerto y aplicación detectada; el curso advierte de que la aplicación SSH puede viajar aunque use otro puerto.
• Acción: allow, deny, reject, inspect, dnat o rate-limit, siempre alineada con la política.
• Estado (memoria de sesión): established, related, new, timeout UDP, SYN sin handshake completo; permite que el retorno de una conexión legítima no necesite una regla de vuelta demasiado amplia.
• Logging (evidencia útil): registrar todo no siempre ayuda; lo importante es registrar decisiones críticas con ID de regla, usuario, motivo de bloqueo y bytes, paquetes y duración.
• Ciclo de vida (propiedad y caducidad): una excepción sin dueño ni fecha se convierte en regla permanente por accidente; hace falta ticket de cambio, fecha de revisión, dueño técnico y justificación de negocio.

Ese séptimo punto (el ciclo de vida) es el que diferencia un curso básico de uno que enseña a operar: la mayoría de material didáctico termina en la acción, y aquí la regla sigue viva después de desplegada.

El laboratorio de análisis de flujo

La sección "Lab" es la parte más práctica: un formulario donde defines zona de origen (Internet, LAN usuarios, DMZ, administración), zona de destino, protocolo, puerto y una nota en lenguaje natural que describe la regla propuesta. Al analizar, el motor del curso evalúa el flujo con heurísticas codificadas en JavaScript y devuelve una decisión (Permitir, Permitir con controles, Revisar antes de permitir o Bloquear), una etiqueta de severidad (Bajo, Medio, Alto, Crítico, Inválido), una puntuación de riesgo de 0 a 100, una traza de ejecución y una lista de hallazgos accionables.

El motor detecta, entre otros casos: puertos fuera de rango (bloqueo directo), administración expuesta desde Internet hacia la zona admin (crítico), Internet hacia LAN directa (rompe la exposición mínima), puertos administrativos (22, 3389, 5900, 5985, 5986) abiertos desde Internet, puertos de base de datos (1433, 1521, 3306, 5432, 6379, 27017), publicaciones web típicas hacia DMZ en 80/443 (que reducen riesgo si mencionas WAF, rate limit, TLS y logs), DNS directo desde LAN hacia cualquier resolver, lenguaje excesivamente amplio en la nota ("any", "cualquiera", "todo"), ausencia de logging y excepciones temporales sin control. La puntuación suma y resta según señales y los umbrales deciden la etiqueta final.

Incluye tres flujos de ejemplo precargados que vale la pena analizar uno a uno: una publicación web correcta (Internet hacia DMZ por HTTPS 443, terminando en balanceador con WAF y rate limit), una solicitud urgente de RDP desde Internet hacia la consola de administración (spoiler: el motor la bloquea como crítica) y un DNS directo desde LAN hacia cualquier resolver externo. Jugar con variaciones de estos tres casos enseña más en diez minutos que leer una hora de teoría.

  Internet          DMZ              LAN              Admin
     |               |                |                 |
     |--- 443 ---> [WAF/balancer]     |                 |
     |               |                |                 |
     | .......................... X (RDP 3389) -----> |
     |               |          <- X (Internet->LAN)   |
     |               |<--[DB 3306 solo desde app]-- LAN

La checklist de riesgos operativos

La sección "Riesgos" organiza dieciséis señales de peligro en cinco modos filtrables por pestañas: Todos, Exposición, Deriva, Visibilidad y Capa 7. Algunas de las más valiosas:

• Críticas: un any-any con allow rompe la segmentación y dificulta la atribución; la entrada directa a LAN debería terminar en DMZ, proxy, WAF o capa de acceso controlada.
• Altas: SSH, RDP, WinRM o paneles de gestión expuestos desde Internet deben pasar por VPN, bastion o identidad fuerte; los puertos de SQL, Redis o MongoDB no deben quedar accesibles desde redes no confiables; los cambios sin ticket rompen la trazabilidad; un WAF en modo copiar y pegar (CRS sin ajuste por aplicación) abre la puerta a bypass y falsos positivos.
• Medias: DNS sin control hacia cualquier resolver; bloqueos sin logging; reglas temporales eternas sin caducidad; logging excesivo sin campos útiles; TLS inspeccionado sin estrategia de alcance y privacidad; confundir aplicación con puerto (el 443 no garantiza HTTPS legítimo).
• Baja: reglas sin hits recientes que siguen heredando riesgo.

La categoría "Deriva" merece atención especial: recoge los riesgos que no existen el día del despliegue sino que aparecen meses después (reglas sombra que nunca se ejecutan, excepciones que caducaron hace un año, cambios sin aprobación). Es la deriva la que convierte políticas correctas en agujeros, y pocos cursos la nombran.

Quiz autocorregido, guía de repaso y glosario

El quiz final tiene cinco preguntas de opción múltiple con explicación individual: la diferencia entre firewall y NAT (traducir direcciones no es controlar acceso), por qué importa el orden de las reglas (se aplica la primera coincidencia y una regla amplia puede ocultar reglas específicas posteriores), qué aporta un firewall stateful (memoria de conexiones para tratar respuestas legítimas), qué es una señal clara de riesgo (SSH abierto desde Internet hacia administración) y qué debe revisarse en un WAF (falsos positivos, falsos negativos y ajuste por aplicación). Al comprobar obtienes puntuación y corrección pregunta a pregunta, y puedes reiniciarlo.

La guía de repaso condensa el método en cuatro bloques: inventario (activos, propietarios, servicios, criticidad y flujos legítimos antes de escribir reglas), zonas (usuarios, servidores, DMZ, administración, terceros, cloud y servicios compartidos), política (permitir solo lo necesario, documentar el motivo, deny final con logging útil) y operación (revisar hits, caducidad, cambios, falsos positivos, reglas sombra y excepciones). El glosario cierra con seis términos en formato desplegable: firewall, ACL, stateful, NAT, WAF y regla sombra.

Referencias oficiales filtrables

La última sección es un directorio de siete fuentes primarias con búsqueda por texto y filtro por tipo (NIST, IETF/RFC, IANA, OWASP): el NIST SP 800-41 Rev. 1 sobre firewalls y política, los RFC 2979 (comportamiento e interoperabilidad de firewalls), 6092 (filtrado stateful en CPE IPv6) y 8519 (modelo YANG de ACLs), el registro IANA de nombres de servicio y puertos, el OWASP Core Rule Set y el NIST SP 800-207 sobre arquitectura zero trust. Que el curso apunte a fuentes primarias en lugar de a tutoriales de blog dice mucho de su orientación: te da la base para citar y profundizar con fundamento.

Cómo está construido el curso

Técnicamente, el repositorio del curso es un ejemplo de austeridad bien entendida: HTML, CSS y JavaScript plano, sin frameworks, sin npm y sin paso de build. El README lo deja claro: puedes clonarlo y abrir index.html directamente en el navegador. La estructura es mínima: index.html (313 líneas), styles.css, script.js (941 líneas), el README, un fichero .nojekyll y una imagen de portada en assets/.

Toda la lógica vive en script.js como datos y funciones puras: un array components con los once nodos del mapa, graphEdges con las relaciones, journey con los seis pasos del flujo, parts con las siete partes de una regla, riskSignals con las dieciséis señales organizadas por modo, references con las siete fuentes, quizzes con las preguntas y sampleFlows con los tres flujos de ejemplo. Las funciones de render (renderGraph, renderJourney, renderParts, renderRisks, renderQuiz, renderReferences) generan el DOM desde esos datos, de modo que el contenido educativo es literalmente legible en el código.

El único componente externo es Cytoscape.js cargado desde CDN para dibujar el grafo del mapa conceptual; si no está disponible, renderGraphFallback genera una lista de botones equivalente, así que el curso funciona incluso sin conexión a la CDN. El laboratorio es una función evaluateFlow(flow) pura que recibe el formulario, acumula hallazgos y puntuación, y devuelve decisión, etiqueta, traza y hallazgos. El quiz se corrige con checkQuiz(), que suma aciertos y muestra la explicación de cada pregunta. Dos detalles de acabado: el tema claro/oscuro se persiste en localStorage, y las secciones aparecen con una animación de revelado vía IntersectionObserver.

Por qué esto importa si trabajas con IA

Aquí conecta el ángulo de IAcademy: cada vez más profesionales despliegan servicios de IA (un servidor de inferencia local, una API que envuelve un modelo, un RAG con datos sensibles) y la pregunta de seguridad que aparece primero es "¿por dónde entra el tráfico y quién puede llegar a este puerto?" y no "¿cómo hago prompt injection?". Esa pregunta es de firewall, y este curso la responde.

El debate on-premise frente a cloud es, en buena parte, un debate de zonas y exposición. Un servicio de IA on-premise necesita las mismas decisiones que el curso enseña: una zona de administración separada (nunca RDP o SSH directo desde Internet, como bloquea literalmente el laboratorio del curso), una DMZ o proxy de terminación delante del endpoint público, reglas específicas para los puertos de base de datos vectorial o de la API del modelo, y logs que permitan auditar quién consultó qué. En cloud, los grupos de seguridad y las reglas de NSG son ACLs con otro nombre: el orden, el principio de primera coincidencia, las reglas sombra y la deriva de excepciones temporales existen exactamente igual. Quien entiende el modelo del curso lo aplica igual a nftables que a una VPC.

Además, el firewall es la capa donde la defensa en profundidad empieza: no sustituye al código seguro ni al WAF ni a la gestión de identidad, pero acota la superficie sobre la que todo lo demás trabaja. El propio curso lo sitúa así al conectar zero trust con política y zonas: reducir la confianza implícita no elimina firewalls, los hace más granulares. Para equipos que construyen con IA, esa base decide si un error de configuración expone un modelo interno a Internet o queda contenido en una zona de la que nunca debía salir.

Cómo usarlo: un plan de estudio

El curso se puede completar en una sesión larga, pero rinde más repartido. Mi propuesta:

• Sesión 1 (45 min): mapa y flujo. Recorre los once componentes del mapa pulsando cada nodo y lee sus detalles. Después navega los seis pasos del simulador de decisión, dos veces: la primera leyendo, la segunda intentando anticipar el texto de cada etapa antes de avanzar.
• Sesión 2 (45 min): reglas y laboratorio. Estudia las siete partes de una regla y pasa directamente al Lab. Analiza los tres flujos de ejemplo sin modificarlos, lee los hallazgos, y luego empieza a variar: cambia el puerto, quita el logging de la nota, añade "cualquiera". Observa cómo cambia la decisión.
• Sesión 3 (30 min): riesgos. Recorre las cinco pestañas de la checklist. Ejercicio: apunta qué señales crees que existirían en una red que hayas administrado o usado.
• Sesión 4 (30 min): quiz y repaso. Haz el quiz sin mirar, lee las explicaciones de cada respuesta (también de las acertadas), y repasa la guía de cuatro bloques como lista de verificación mental.
• Sesión 5 (opcional): fuentes. Abre al menos el NIST SP 800-41 y el RFC 8519. Son más legibles de lo que parece y consolidan el vocabulario.

Como cierre práctico, un ejercicio que el propio curso invita a hacer: escribe en el Lab la regla que necesitarías para publicar tu propio servicio (por ejemplo, una API de IA en un puerto 8080 desde Internet hacia una zona de servidores) y itera la nota hasta que la decisión sea "Permitir" con riesgo bajo. Esa iteración es, en miniatura, el trabajo real de diseñar política.

Preguntas frecuentes

¿Para qué nivel está pensado el curso?

Parte de cero en firewalls pero no se queda ahí: llega hasta conceptos profesionales como reglas sombra, deriva de política, tuning de WAF e inspección TLS. Un estudiante de redes o un administrador junior lo aprovecha entero; alguien senior puede usarlo como repaso estructurado y como material para explicar el tema a otros.

¿Necesito instalar algo o tener un firewall real?

No. Es una aplicación estática que funciona en el navegador: sin npm, sin backend y sin build. El laboratorio simula el análisis de flujo en JavaScript, así que puedes romper reglas sin riesgo y sin infraestructura.

¿Qué diferencia hay entre firewall y NAT?

Es una de las preguntas del quiz y una confusión clásica: NAT traduce direcciones o puertos y el firewall decide si el tráfico debe pasar. Pueden convivir en el mismo equipo, pero son funciones distintas, y depender de NAT como mecanismo de seguridad es un error frecuente.

¿Sirve para firewalls de cloud?

Sí, conceptualmente. Grupos de seguridad, NSGs y reglas de VPC son ACLs ordenadas con zonas, exactamente el modelo que el curso enseña. Los riesgos de deriva, reglas amplias y exposición administrativa se trasladan uno a uno.

¿Qué es una regla sombra?

Una regla que nunca se ejecuta porque otra regla anterior, más amplia, captura el tráfico antes. Es deuda de configuración: parece que hay un control específico, pero en realidad nunca se aplica.

¿El curso cubre WAF y capa de aplicación?

Sí, como componente del mapa, como señales de riesgo específicas en la pestaña "Capa 7" y como pregunta del quiz: un WAF necesita ajuste por aplicación y hay que medir falsos positivos y falsos negativos; no sustituye corregir el código.

¿Cómo se guarda mi progreso?

El curso es una página única pensada para completarse en una o varias sesiones cortas; no requiere registro. Lo único que persiste entre visitas es la preferencia de tema claro u oscuro, guardada en el navegador.

¿Puedo usar el código para enseñar o adaptarlo?

El repositorio es público y el contenido está separado en estructuras de datos claras (componentes, pasos, señales, preguntas), lo que facilita reutilizar la mecánica con otro temario siempre que respetes los términos de la licencia y atribuyas la fuente.