Red segmentada para pymes con OPNsense

Resumen — Diseño para una empresa ficticia de 40 personas con sede principal y una sucursal: cinco zonas de seguridad detrás de un firewall OPNsense con denegación por defecto, IPS Suricata, filtrado DNS, un túnel IPsec entre sedes con certificados, acceso remoto con TOTP y administración endurecida. La política del firewall se escribe una sola vez como código y de ella salen tanto la documentación como un verificador de conectividad automatizado e inofensivo. Entregable: diseño, política como código y herramientas, listos para construir; resultados del laboratorio aún sin medir.

1. Problema

• Contexto: una empresa ficticia de servicios profesionales, 40 empleados en tres áreas, una sede principal, una sucursal y un sitio web público. Hoy todo está en una única red plana.
• Por qué importa: en una red plana, un portátil infectado puede llegar a todos los servidores, a las copias de seguridad y a la página de administración del propio firewall. Los invitados del Wi-Fi también comparten esa red.
• Requisitos:
  1. El personal accede a internet y solo a los servicios internos que necesita.
  2. Los invitados solo acceden a internet.
  3. El sitio web es el único servicio publicado en internet (aparte de los puntos de acceso VPN).
  4. Una estación o un servidor web comprometidos no pueden llegar a interfaces de administración ni a otras zonas.
  5. La sucursal usa los servicios de la sede por un túnel cifrado; el personal remoto se conecta con MFA.
  6. La administración solo se hace desde una red dedicada, con MFA, y toda decisión queda registrada de forma central.
• Restricciones: herramientas libres y de código abierto; laboratorio aislado; direcciones de rangos privados y de documentación.
• Criterios de éxito: cada flujo de la política se comporta según el diseño al probarlo desde dentro de cada zona, y las verificaciones manuales (cifrado del túnel, MFA, IPS, filtrado DNS) se superan.

2. Arquitectura

El plan de direccionamiento completo y cada flujo probado con su justificación se generan desde la política: docs/ip-plan.md y docs/rules.md.

3. Construcción

Guías paso a paso para OPNsense 26.7 en docs/opnsense/ (en inglés):

1. Instalación e interfaces: bridges de Proxmox, VLAN, direccionamiento.
2. Reglas del firewall: alias y una regla por flujo permitido, con bloqueo registrado al final de cada zona.
3. NAT y salida: un solo servicio publicado; servidores y MGMT sin acceso directo a internet.
4. IPS Suricata: reglas ET Open; solo se bloquean firmas de alta confianza.
5. Filtrado DNS: listas de bloqueo en Unbound; los clientes no pueden saltarse el resolvedor.
6. IPsec entre sedes: cada parámetro con su motivo.
7. OpenVPN + TOTP: certificado + contraseña + código de un solo uso.
8. Endurecimiento de la administración: GUI/SSH solo desde MGMT, MFA, registros hacia Wazuh, copias de seguridad cifradas.

4. Plan de validación

• Verificación automática de conectividad (docs/validation.md): desde un host de prueba en cada zona, python3 -m labtools.checker --zone <ZONA> prueba los 56 flujos de la política con conexiones TCP, ecos UDP y consultas DNS normales hacia los propios hosts del laboratorio (los flujos desde internet, en la dirección WAN del firewall), y marca cada uno como PASS, FAIL (blocked) o FAIL (allowed).
• Verificaciones manuales (tests/test-plan.md): el tráfico IPsec va cifrado en la red, el inicio de sesión VPN falla sin el código TOTP, el IPS alerta ante una firma de prueba inofensiva, los dominios bloqueados no resuelven y un inicio de sesión fallido en el firewall llega a Wazuh.

5. Entregables y medición

Entregado en este repositorio:

• Arquitectura, diseño de zonas y plan de direccionamiento para dos sedes.
• Una matriz de 56 flujos (incluidos todos los puertos que necesita un cliente de Active Directory), cada uno con su justificación escrita, validada en CI (zonas desconocidas, flujos dentro de una misma zona, duplicados o justificaciones faltantes hacen fallar la compilación).
• Ocho guías de configuración de OPNsense y una guía para publicar configuraciones sin secretos.
• Un verificador de conectividad y un listener de destino cubiertos por pruebas automatizadas (incluidas sondas TCP/UDP reales), más una comprobación en CI de que la documentación generada coincide con la política.

Cómo se miden los resultados:

6. Lecciones de diseño y hoja de ruta

• Revisa los límites de licencia antes de elegir un producto. La prueba de FortiGate-VM parecía la opción obvia, pero no admitía ni el diseño básico de zonas; revisarlo primero evitó construir sobre un callejón sin salida.
• Escribe la política una sola vez. Tener zonas y flujos en un solo archivo YAML, del que salen la documentación y el verificador, elimina la desalineación habitual entre "lo que dice el diagrama" y "lo que hace el firewall".
• Prueba las denegaciones, no solo los permisos. Una política de denegación por defecto solo queda demostrada cuando los flujos bloqueados se prueban desde dentro de cada zona; por eso la política los lista explícitamente.
• Las sondas necesitan que alguien responda. Un flujo permitido hacia un puerto sin servicio se ve igual que uno bloqueado; por eso el diseño incluye un listener y marca los hosts cuyos servicios reales ya responden.
• Diseñar para clientes reales cambia los detalles. Los equipos unidos al dominio necesitan el controlador de dominio para DNS y los agentes del Lab 01 necesitan sus propios flujos; ambas cosas aparecieron solo al escribir las guías paso a paso.

Hoja de ruta: construir ambos firewalls con las guías, ejecutar el verificador desde las seis zonas y las verificaciones manuales, publicar aquí la conformidad medida y, más adelante, comparar con un FortiGate con licencia usando la misma política.

7. Reprodúcelo tú mismo

• Clonar: git clone https://github.com/santorest/lab-02-segmented-network.git
• Descargar el paquete: desde el sitio del portafolio (el SHA-256 aparece junto a la descarga).
• Tiempo estimado: 1–2 días.
• Limpieza: elimina las VM y los bridges; no se usan recursos en la nube.

8. Mapeo

Todas las pruebas se realizan en un entorno de laboratorio aislado de mi propiedad. No se incluyen datos, nombres de host ni configuraciones de ninguna organización real.