Tres de los cinco hallazgos del pentest anterior eran, en el fondo, problemas de red: un panel publicado en la interfaz externa del host, un subdominio que apuntaba a una IP ajena y un servicio accesible desde donde no debía. Y siguen pendientes desde 05-01 los tres grandes: PostgreSQL escuchando en 0.0.0.0:5432, SSH abierto a todo Internet y la consultora con acceso permanente. Esta lección dibuja la red de Nimbus tal como está, la rediseña por zonas, cierra esos agujeros, monta el acceso remoto y el DNS como deben estar, y termina comprobando con pruebas de conectividad que la segmentación funciona de verdad: un diseño no probado es solo un dibujo bonito.

1. La red de Nimbus hoy, con sus problemas
2. Segmentación: el control con mejor relación coste/impacto
3. Cortafuegos: tipos, política por defecto y reglas de salida
4. Acceso remoto seguro: VPN, bastión y acceso just-in-time
5. Wifi corporativa y de invitados
6. DNS: resolución, filtrado y protección del dominio
7. Protección frente a DoS y DDoS
8. Detección en red y el problema del tráfico cifrado
9. Zero Trust aplicado a la red
10. Verificar que la segmentación funciona

Siete problemas, ordenados por gravedad:

Ninguno requiere comprar nada para corregirse. Los siete son configuración, y esa es la mejor noticia de la lección.

La segmentación divide la red en zonas y controla explícitamente qué puede hablar con qué. Es el control que mejor relación coste/impacto tiene porque no impide la intrusión, pero impide que la intrusión se convierta en catástrofe: convierte «comprometieron un portátil» en «comprometieron un portátil», y no en «comprometieron la empresa».

Es la lección de Target (02-06): los atacantes entraron por el proveedor de climatización y llegaron a los terminales de pago porque entre ambos no había ninguna frontera. Y es también el día 1-4 del incidente de Nimbus: desde la red de administración se alcanzaba la zona de datos sin ningún control intermedio.

Vocabulario mínimo. Una VLAN separa dominios de difusión en el mismo switch físico (es lógica, no cableado nuevo); una subred es el rango IP asociado; el tráfico entre VLAN pasa por un dispositivo que enruta y ahí es donde se aplica la política. En la nube el equivalente son las subredes de la VPC y los grupos de seguridad, que son cortafuegos por instancia y no por perímetro: eso permite microsegmentación, es decir, que dos servidores de la misma subred no puedan hablar entre sí si no deben.

Diseño objetivo de la oficina:

Y en la nube:

La corrección de los dos agujeros históricos es literalmente esto: 5432 deja de aceptar 0.0.0.0/0 y solo acepta la subred de aplicación; 22 deja de aceptar 0.0.0.0/0 en cada servidor y solo se alcanza desde el bastión, que a su vez solo se alcanza desde la VPN. Veinte minutos de trabajo para el riesgo mejor puntuado del registro de 04-01.

Dos principios gobiernan la configuración. El primero: política por defecto de denegar. Se cierra todo y se abre lo justificado, con un comentario que diga por qué. Una regla sin justificación documentada es una regla que nadie se atreverá a quitar dentro de tres años.

El segundo, el que casi nadie aplica: filtrar también la salida. Casi todas las organizaciones controlan qué entra y dejan salir cualquier cosa hacia cualquier sitio. Pero la exfiltración de 1,2 TB de 02-06 y el canal de mando y control son tráfico de salida. Un servidor de base de datos no necesita navegar por Internet.

En la nube, la misma política expresada como grupos de seguridad:

Referenciar grupos y no rangos de IP es la mejor práctica más rentable de la nube: la regla sigue siendo correcta cuando la API escala, se sustituye o cambia de IP, y expresa la intención («la aplicación habla con los datos») en lugar de un accidente de direccionamiento.

Lo que cuesta de verdad el filtrado de salida es la primera semana: aparecen dependencias que nadie había documentado. Es exactamente el motivo por el que merece la pena, porque esas dependencias desconocidas son también la superficie que el atacante usa. Se despliega primero en modo registro, se leen los SALIDA-BLOQUEADA durante dos semanas, se abre lo legítimo y entonces se activa.

WireGuard es libre, rápido, cabe en 4.000 líneas de código auditable y su configuración entra en una pantalla.

Tres decisiones importan. Una IP fija por persona convierte los registros de firewall en trazabilidad real. La autenticación es por clave, sin contraseñas que adivinar, pero eso obliga a un procedimiento de alta y baja: la baja de un empleado incluye borrar su [Peer], y si no está en la lista de comprobación de salida, el acceso sobrevive a la persona. Y la VPN da acceso a la red, no a los sistemas: estar en la VPN no debe bastar para entrar en la base de datos; sigue haciendo falta autenticación en cada servicio.

ProxyJump es la pieza clave: el bastión reenvía la conexión, pero la autenticación ocurre de extremo a extremo y la clave privada no toca el bastión. Es la diferencia con el viejo hábito de copiar la clave al salto, que convierte al bastión en el punto único de compromiso total. El bastión, además, registra todas las sesiones y es el único host con 22 accesible, y solo desde la VPN.

El acceso just-in-time invierte el modelo: en lugar de un acceso permanente que se revoca cuando alguien se acuerda, no hay acceso hasta que se solicita, se aprueba y se concede con caducidad automática. Es el control C-03 de 04-03, y para A-19 la implementación acordada en 04-04 es:

• Cuentas nominales, una por técnico de la consultora. Se acabó svc-consultora compartida: sin nombre no hay responsabilidad ni investigación posible.
• MFA obligatorio, el control que por sí solo habría evitado el incidente.
• Solicitud con ticket que indica sistema, motivo y duración; aprobación de Lucía o Marta.
• Caducidad de 8 horas, aplicada por el sistema y no por la memoria de nadie.
• Acceso solo al sistema concreto, no a la red completa.
• Alerta D-03 de 05-02 si aparece una autenticación fuera de la ventana pactada.
• Revocación de la excepción de 2023 sin caducidad del registro de 04-02, que es lo que mantenía vivo el acceso permanente.

Para Nimbus: WPA3 donde el hardware lo permita y WPA2-Enterprise en el resto, con credencial individual contra el proveedor de identidad. La clave única compartida por 38 personas está en decenas de móviles, ha pasado por chats y no se cambia desde 2022.

La red de invitados debe estar realmente aislada: VLAN 30 propia, sin ruta hacia ninguna otra VLAN, aislamiento entre clientes activado (que dos invitados no se vean entre sí), límite de ancho de banda, portal con condiciones de uso y clave rotada. El error habitual es usar el mismo punto de acceso con distinto SSID pero sin separación de VLAN: eso es la misma red con dos nombres.

Dos cosas que no son controles, y conviene decirlo sin rodeos: el filtrado por MAC —las MAC se clonan con un comando y se ven en el aire aunque el tráfico esté cifrado— y ocultar el SSID —la red sigue anunciándose en cada conexión de un cliente, y además obliga a los portátiles a ir buscándola activamente, lo que facilita los puntos de acceso falsos—. Consumen tiempo de administración y dan una falsa sensación de seguridad.

El riesgo del wifi público afecta a la mitad de la plantilla. Hoy TLS protege el contenido (03-05), así que el escenario clásico de «te leen la contraseña» es en gran medida histórico; lo que sigue siendo real es el punto de acceso falso que suplanta a un portal conocido y el envenenamiento de DNS local. La medida efectiva es simple y ya está montada: VPN siempre activa fuera de la oficina, con DNS forzado por el túnel, más HSTS en todos los dominios propios.

El DNS es el control más barato que existe y el más olvidado. Tres frentes:

Resolución segura y filtrado. Todos los equipos usan el resolutor corporativo (o el del túnel VPN), nunca el que ofrezca la wifi del bar. Un DNS filtrante bloquea la resolución de dominios maliciosos, de dominios recién registrados y de categorías no deseadas. Es un control desproporcionadamente eficaz: corta el phishing en el clic y corta el mando y control en la primera llamada a casa, funciona igual en el portátil de casa y en la oficina, y hay opciones gratuitas o de pocos euros por usuario. Para Nimbus es, junto al MFA, la mejor compra por euro del catálogo. DNSSEC protege la integridad de las respuestas y se activa en el dominio propio; DoH/DoT cifran la consulta, con la contrapartida de que un DoH descontrolado en el navegador salta el filtrado corporativo, así que se configura de forma explícita.

Protección del propio dominio. nimbusreservas.example es el activo A-08, crítico, y perderlo es perder el correo, la web y la capacidad de emitir certificados. Cuatro medidas: bloqueo de transferencia en el registrador (registrar lock), MFA en la cuenta del registrador con dos personas con acceso, renovación automática con alerta a 90 días —han caído empresas enteras por un dominio no renovado—, y revisión trimestral de la zona, que es donde aparecen los registros olvidados.

Toma de control de subdominios. Es lo que encontró el pentest en 05-03. Ocurre cuando un registro CNAME o A sigue apuntando a un recurso que ya no controlas —un bucket borrado, un servicio dado de baja, una IP liberada—: cualquiera puede reclamar ese recurso y servir contenido bajo tu dominio, con tu certificado válido y, si las cookies son de dominio amplio, con acceso a las sesiones de tus usuarios.

Conviene ser honesto sobre lo que puede y no puede hacer una empresa de 38 personas.

Medidas realistas: CDN o proxy inverso con protección anti-DDoS delante de la API y de la web (hay planes gratuitos suficientes para este tamaño), lo que además oculta la IP real del origen —que entonces debe aceptar tráfico solo desde la CDN, o el atacante la esquiva—; límite de tasa por IP, por cliente y por tenant (02-04 y 05-05); autoescalado con techo, porque sin límite el ataque deja de ser una caída y pasa a ser una factura; y paginación obligatoria en los endpoints que devuelven listas.

Qué hacer durante un ataque, en orden: confirmar que es un ataque y no un pico legítimo o un fallo propio; activar el modo de protección de la CDN; no desactivar el registro (se pierde la evidencia justo cuando hace falta); bloquear por patrón en el borde y no en el origen; comunicar a los clientes con honestidad (04-05); y no pagar ninguna extorsión asociada. Y después: post mortem y ajuste de umbrales.

Dónde se colocan los sensores importa tanto como cuáles se eligen:

Qué se pierde con el cifrado. Hoy más del 90 % del tráfico va cifrado, así que un IDS de firmas ve mucho menos que hace diez años. Lo que sigue siendo visible sin descifrar nada es mucho: quién habla con quién, cuánto, en qué dirección y con qué ritmo; el nombre del servidor en el saludo TLS y las consultas DNS; el certificado y la huella del cliente TLS. Con eso basta para detectar exfiltración, mando y control periódico y destinos anómalos. Por eso los registros de flujo y de DNS rinden más, y salen mucho más baratos, que intentar mirar dentro.

La alternativa —inspección TLS, es decir, terminar el cifrado en un equipo intermedio para leer el contenido— tiene un coste que va más allá de lo técnico: obliga a instalar una autoridad de certificación propia en cada equipo, expone en ese punto todo lo que la gente hace, incluida su banca y su salud, y crea un objetivo de altísimo valor. Para Nimbus la conclusión es clara: no se hace inspección TLS sobre los equipos de empleados; se invierte en flujo, DNS y telemetría del endpoint, que dan casi la misma señal sin ese coste. (Nota de validación legal y laboral: en España, cualquier medida que permita acceder al contenido de las comunicaciones de la plantilla exige información previa, proporcionalidad y, según el caso, negociación con la representación de los trabajadores; requiere validación jurídica antes de implantarse. Se desarrolla en 06-03 y 06-06.)

Zero Trust no se compra: se implanta por fases, y para Nimbus las tres primeras ya están en marcha o son gratuitas:

La advertencia práctica: una VPN no es Zero Trust. Una VPN que da acceso a toda la red interna reproduce el perímetro con otro nombre; se convierte en un paso hacia Zero Trust solo cuando lo que hay detrás está segmentado y cada servicio autentica por su cuenta.

Este es el apartado que más veces se salta y el que decide si todo lo anterior es real. Un diseño de red no probado es un dibujo, y la forma de probarlo es intentar, desde cada zona, alcanzar lo que no debería alcanzarse.

Cuatro detalles que hacen útil este script. Declara la expectativa, así que sirve de documentación ejecutable del diseño. Incluye un control positivo (1.1.1.1:53 debe estar abierto): si todo sale «cerrado», lo más probable es que el problema sea el propio script o que no haya red, no que la segmentación sea perfecta. Devuelve código de salida distinto de cero, lo que permite ejecutarlo desde el CI de infraestructura tras cada cambio. Y se ejecuta desde cada zona, porque la respuesta depende del origen: eso significa lanzarlo desde un portátil en la VLAN de usuarios, desde la wifi de invitados, desde el bastión y desde preproducción.

Para una comprobación más amplia, nmap desde cada zona contra las demás documenta el mapa real:

El error a evitar, y es el más común de la lección: dar por buena la segmentación porque el diagrama es correcto y las reglas «están puestas». Las reglas se solapan, los grupos de seguridad se heredan, alguien abre algo «un momento» para depurar y no lo cierra, y una tabla de rutas convierte dos zonas separadas en una sola. La única prueba de que dos zonas están separadas es intentar cruzarlas y no poder.

• Red plana «porque somos pocos». El tamaño no protege (02-06): con 38 personas y 40 portátiles, un solo equipo comprometido alcanza todo.
• Invitados con SSID distinto pero sin VLAN separada. Es la misma red con dos nombres.
• Confiar en el filtrado MAC o en ocultar el SSID. No son controles; son trabajo administrativo con sensación de seguridad.
• Abrir SSH a Internet y «compensarlo» con fail2ban. El control correcto es que no sea alcanzable; fail2ban es la segunda línea, no la primera.
• No filtrar la salida. Es lo que permite la exfiltración y el mando y control. Empieza en modo registro y activa en dos semanas.
• VPN que da acceso a toda la red interna. Es el perímetro con otro nombre; detrás debe haber segmentación y autenticación por servicio.
• Dejar registros DNS de recursos dados de baja. Es la puerta a la toma de control de subdominios, con tu dominio y tu certificado.
• Consejo: empieza por los tres cierres de veinte minutos. 5432 a la subred de aplicación, 22 solo desde el bastión y la VPN, y la excepción de A-19 revocada. Es el mayor descenso de riesgo por hora invertida de todo el curso.
• Consejo: pon el script de verificación en el CI de infraestructura. Si una regla se abre por error, lo sabrás el mismo día y no en el próximo pentest.
• Consejo: el DNS filtrante es la mejor compra por euro después del MFA. Corta phishing y mando y control, funciona dentro y fuera de la oficina y cuesta unos pocos euros por usuario.

Escribe, para cada uno de los tres hallazgos pendientes desde 05-01 —PostgreSQL en 0.0.0.0:5432, SSH abierto a 0.0.0.0/0 y el acceso permanente de la consultora (A-19)—: el cambio concreto, el riesgo del registro de 04-01 que reduce, el tiempo estimado y cómo verificarías que está hecho.

Un antiguo becario dejó documentada esta configuración de la oficina:

1. Reescribe el diseño en zonas con sus rangos y su matriz de comunicación permitida.
2. Indica qué dos «controles» hay que retirar y por qué.
3. Propón tres reglas de salida y explica qué ataque corta cada una.

Tras aplicar la segmentación, Lucía ejecuta el script del §10 desde un portátil de la VLAN de usuarios y obtiene:

Interpreta cada fallo, indica la causa más probable y el orden en que los atacarías.

Ejercicio 1

La observación de fondo: el más importante de los tres no es técnico. Los dos primeros son reglas de firewall; el tercero exige una conversación contractual con un proveedor, y por eso lleva dos años pendiente. Es la diferencia entre 04-04 y esta lección.

Ejercicio 2

(1) Zonas y matriz. El diseño es el de la tabla del §2: VLAN 10 usuarios (10.20.10.0/24), 20 servidores locales (10.20.20.0/24), 30 invitados (10.20.30.0/24), 40 gestión (10.20.40.0/24) y 50 no confiables (10.20.50.0/24), con la TV de sala en la 50 y los puntos de acceso, el switch y el router en la 40.

Detalle que suele olvidarse: aislamiento también dentro de la VLAN de usuarios. Un portátil no necesita hablar con otro portátil, y ese tráfico es justo el del movimiento lateral y el del ransomware que se propaga por la red local.

(2) Los dos «controles» a retirar son el filtrado MAC y el SSID oculto. El primero se salta clonando una MAC visible en el aire, y a cambio genera trabajo cada vez que entra un dispositivo. El segundo no oculta nada —la red aparece en cuanto un cliente se conecta— y empeora la seguridad: obliga a los portátiles a ir preguntando por ese SSID allá donde vayan, lo que facilita que un punto de acceso falso responda «sí, soy yo». Se sustituyen por WPA3 o WPA2-Enterprise con credencial individual.

(3) Tres reglas de salida:

• Bloquear todo saliente salvo 80/443, DNS al resolutor interno y NTP. Corta el mando y control por puertos no estándar y buena parte del malware genérico, que suele llamar a casa por puertos altos.
• Bloquear DNS saliente (53, DoH conocido) hacia cualquier destino que no sea el resolutor corporativo. Corta la exfiltración por DNS —una técnica clásica precisamente porque el DNS casi nunca se filtra— y obliga a que todo el tráfico pase por el filtro de dominios.
• Bloquear SMB, RDP y SSH salientes desde la VLAN de usuarios hacia Internet. No hay caso de uso legítimo, y corta tanto la exfiltración a servidores externos como la conexión inversa desde un equipo comprometido.

Ejercicio 3

El tercer fallo es el más importante y hay que leerlo primero. 1.1.1.1:53 esperado ABIERTO y real CERRADO es el control positivo, y que falle invalida los demás resultados: puede que el portátil no tenga red, que el DNS saliente esté bloqueado por la nueva regla de egress (lo cual sería correcto y solo obliga a cambiar el control positivo por el resolutor interno) o que el script esté mal. Sin control positivo válido, los «OK» de las líneas 1, 3 y 5 no prueban nada: podrían ser cerrados por falta de conectividad y no por segmentación.

Interpretación de los otros dos:

• 10.30.10.11:22 abierto desde la VLAN de usuarios. El bastión está bien cerrado (línea 3 en OK), pero el servidor de la API sigue aceptando SSH desde fuera del bastión. Causa más probable: la regla se aplicó al grupo de seguridad nuevo, pero la instancia conserva una segunda pertenencia a un grupo antiguo más permisivo, y en la nube los grupos se suman, no se restan. Es el error clásico. Se revisa la lista completa de grupos de la instancia, no solo el que se acaba de editar.
• 10.20.40.1:443 abierto: el panel de gestión del router se alcanza desde la red de usuarios. Causa más probable: el dispositivo de gestión escucha en todas sus interfaces y no solo en la VLAN 40, o falta la regla entre VLAN. Se acota a la interfaz de gestión y se comprueba de nuevo.

Orden de trabajo: (1) arreglar el control positivo y repetir la prueba completa, porque hasta entonces no hay resultados fiables; (2) el SSH de la API, porque es acceso administrativo desde una zona de usuarios y equivale a no haber cerrado nada; (3) el panel del router, que es grave —controla la red— pero está un escalón por debajo. Y una conclusión transversal: este script debe ejecutarse en el CI de infraestructura tras cada cambio, porque los dos fallos son exactamente el tipo de residuo que nadie detecta hasta el siguiente pentest.

Has convertido la red de Nimbus de un dibujo con siete problemas en un diseño defendible, y lo has hecho sin comprar nada: los siete eran configuración. Sabes por qué la segmentación es el control con mejor relación coste/impacto —no impide la intrusión, impide que se convierta en catástrofe—, distingues VLAN, subred, grupo de seguridad y microsegmentación, y tienes el diseño objetivo por zonas de la oficina (usuarios, servidores, invitados, gestión, no confiables) y de la nube (pública con bastión, aplicación, datos, preproducción aislada), con la corrección concreta de 5432 acotado a la subred de aplicación y 22 alcanzable solo desde el bastión.

Conoces los tipos de cortafuegos y dónde va cada uno, la política por defecto de denegar, y el control que casi nadie aplica: filtrar la salida, con reglas nftables comentadas y su equivalente en grupos de seguridad que referencian grupos y no rangos de IP. Sabes que el filtrado de salida cuesta una primera semana de dependencias no documentadas y que ese es justo el motivo por el que merece la pena, y que se despliega en modo registro antes de activarse. Montas el acceso remoto con WireGuard —una IP fija por persona para que los registros identifiquen a alguien— y con bastión SSH usando ProxyJump, donde la clave privada nunca toca el salto; y sabes por qué una VPN no es Zero Trust si detrás no hay segmentación. Has cerrado A-19 con cuentas nominales, MFA, ticket, caducidad de 8 horas, alerta D-03 y la revocación de la excepción de 2023.

Sabes elegir entre WPA2-Personal, WPA2-Enterprise y WPA3, aislar de verdad la red de invitados y por qué el filtrado MAC y el SSID oculto no son controles —el segundo incluso empeora la seguridad—. Dominas el DNS en sus tres frentes: resolución y filtrado como la mejor compra por euro después del MFA, DNSSEC, protección del dominio A-08 con bloqueo de transferencia, MFA en el registrador y renovación automática, y la toma de control de subdominios con su comprobación trimestral. Sabes qué puede y qué no puede hacer Nimbus frente a DDoS —el de aplicación sí, el volumétrico no— y qué hacer durante un ataque. Sabes dónde colocar Suricata, Zeek y los registros de flujo, qué sigue siendo visible aunque todo vaya cifrado (quién habla con quién, cuánto, DNS y SNI) y por qué Nimbus no hará inspección TLS sobre los equipos de su plantilla. Y tienes Zero Trust como plan por fases, con las tres primeras gratuitas o en curso.

Sobre todo, te llevas la disciplina que separa el diseño de la realidad: el script de verificación de segmentación, con expectativas declaradas, control positivo, código de salida para el CI y ejecución desde cada zona. La única prueba de que dos zonas están separadas es intentar cruzarlas y no poder.

La red ya no regala el acceso. Pero fíjate en dónde queda ahora la superficie de ataque: el puerto 443 de la API sigue abierto a todo Internet, y tiene que estarlo, porque ahí vive el producto. Ninguna regla de firewall distingue una reserva legítima de un intento de leer los datos de otra clínica: esa distinción solo puede hacerla la aplicación. En Seguridad en Aplicaciones (05-05) entramos en el código: ciclo de desarrollo seguro, defensas concretas contra el Top 10 de OWASP con las correcciones escritas, autorización centralizada que generaliza la lección del IDOR, seguridad de APIs, gestión de secretos, cabeceras y CSP, y un pipeline de CI con SAST, DAST, SCA y escaneo de secretos que decide qué rompe el build y qué solo avisa.