Network Segmentation Lab

Contexto y motivación

En una red plana, un portátil comprometido en recepción tiene la misma ruta hacia la base de datos que el administrador. Segmentar y denegar por defecto es la respuesta de siempre, y deja una pregunta incómoda, cómo sabes que lo que crees bloqueado lo está de verdad. Revisar reglas a mano solo comprueba los casos que se te ocurren.

Aquí los flujos que sí deben existir se declaran en un único fichero, cada uno con el motivo escrito, y de ahí salen dos cosas, las reglas del firewall y la lista de todo lo que debe fallar. Esa lista es el producto cartesiano de orígenes, destinos y puertos menos lo permitido, así que cubre las combinaciones que nadie habría pensado en revisar.

Terraform levanta nueve máquinas desde cero sobre un Proxmox VE 9 anidado con 11 GB de RAM, el firewall OPNsense, cuatro servidores AlmaLinux con SELinux en enforcing y cuatro clientes repartidos por los segmentos, uno de ellos fuera del perímetro para poder probar la publicación web y la VPN desde fuera. Ansible instala BIND, PostgreSQL, Samba y Nginx de forma idempotente, y un script sincroniza las reglas del firewall con el fichero de flujos por API y avisa si alguien las ha tocado por su cuenta.

Tecnologías

Proxmox VE 9TerraformAnsiblePython (pytest)AlmaLinux 9SELinuxWireGuard

Características principales

  • 297 comprobaciones derivadas de 21 flujos declarados, 31 permisos y 266 bloqueos, todos verificados contra el laboratorio
  • 53 reglas de firewall generadas desde el fichero de flujos, sin deriva entre lo declarado y lo aplicado
  • Los tests no entran por SSH a la red que prueban, hablan con el hipervisor y ejecutan dentro de cada máquina por un wrapper que valida antes que pertenece al laboratorio
  • Comando de caos que inserta una regla permisiva a propósito, lanza la suite esperando verla en rojo, la retira y comprueba que vuelve a verde
  • Playbook idempotente, segunda pasada con cero cambios en los cuatro servidores y ninguno en modo permisivo
  • VPN WireGuard que alcanza la red de administración y ninguna otra, comprobado desde un cliente externo
  • 22 incidencias documentadas con su diagnóstico y su solución

Galería

Conclusión

Es un laboratorio y lo digo en el repositorio. No hay alta disponibilidad ni detección de intrusiones, las credenciales son de prueba y todo corre sobre virtualización anidada. Lo que demuestra es la política de red y su verificación, no el rendimiento.

Con todo montado, la suite detectó que los clientes de invitados alcanzaban la web de la DMZ. El fallo era mío, había traducido salir a Internet como destino `any`, y `any` incluye las redes internas, así que permitir navegar abría de paso el camino a los otros segmentos. La regla parecía correcta y la intención lo era. Eso no lo encuentra una lista de denegaciones escrita a mano, porque nadie escribe la combinación que no se le ha ocurrido.

Enlaces

Ver código en GitHub