Anatomía del laboratorio

1Por qué importa

Hay dos formas de aprender seguridad ofensiva y solo una termina bien. La primera es leer una técnica y probarla contra lo primero que responda; la segunda es montar un objetivo propio, romperlo, mirar los logs y reconstruirlo. La diferencia no es solo legal: la primera no enseña casi nada, porque cuando algo funciona no puedes ver por qué funcionó, y cuando falla no puedes distinguir si falló tu técnica o si el objetivo ya estaba parcheado.

Un laboratorio bien montado te da tres cosas que ningún objetivo ajeno te da nunca. Observabilidad: puedes leer los logs de las dos puntas del ataque a la vez. Reproducibilidad: si algo funcionó, lo puedes repetir mañana en el mismo estado exacto. Y reversibilidad: destruyes y reconstruyes en segundos, así que puedes permitirte romper cosas de verdad, que es la única manera de entenderlas.

Hay una cuarta razón, menos evidente y más importante: un laboratorio de seguridad es una máquina llena de software deliberadamente vulnerable. Si no está aislado, no es un laboratorio, es una brecha esperando su turno dentro de tu propia casa. La disciplina de aislamiento que vas a aprender aquí no es burocracia del curso; es lo único que separa “estoy practicando” de “he montado un punto de entrada en mi red doméstica”.

2Conceptos

3Explicación profunda

El laboratorio de referencia del curso tiene cinco servicios. No son cinco por gusto: cada uno representa una categoría de pieza que vas a encontrar en cualquier sistema real, y quitar cualquiera de ellos deja un hueco pedagógico concreto.

El detalle que más gente pasa por alto es el último. El atacante vive dentro del laboratorio, no en tu terminal. Cuesta un poco más al principio —hay que entrar con docker compose exec— y a cambio compra dos cosas. La primera es que tus herramientas ofensivas no se instalan en tu máquina de trabajo. La segunda es que, cuando pruebas si algo tiene salida a internet, la respuesta que obtienes es la del laboratorio y no la de tu portátil, que sí la tiene.

Dos redes, y por qué no una

Docker crea por defecto redes de tipo bridge: un puente virtual en tu máquina, con un rango propio, y reglas de NAT que le dan salida a internet a todo lo que se conecte. Ese comportamiento por defecto es exactamente lo que no queremos para software deliberadamente roto.

Añadir internal: true a una red cambia una sola cosa, y es la decisiva: Docker no programa la regla de enmascaramiento que da salida a esa red. Los contenedores siguen teniendo dirección, siguen viéndose entre ellos, siguen resolviendo nombres… y no tienen por dónde salir. No es un cortafuegos con reglas que se puedan equivocar: es la ausencia de una ruta.

De ahí sale la topología: lab_borde es una red normal, con salida, y solo la toca el proxy. lab_interna es interna, y ahí viven las otras cuatro piezas. El proxy tiene un pie en cada una. Esa asimetría es todo el diseño: hay exactamente un camino entre el laboratorio y el mundo, y está escrito en cuatro líneas que puedes auditar de un vistazo.

Resolución de nombres: por qué el laboratorio es reproducible

Cada red de Docker trae un resolutor propio. Dentro de una red, el nombre del servicio del compose resuelve a la dirección del contenedor, y se actualiza solo si el contenedor se recrea. Por eso el proxy puede escribir http://app en su configuración y funcionar en tu máquina, en la mía y dentro de dos años.

Es también la razón de que en este curso no aparezcan direcciones escritas a mano. Fijar una dirección literal en un laboratorio es la forma más rápida de que deje de levantar en otra máquina, y además rompe el hábito que quieres construir: en infraestructura moderna, las direcciones son efímeras y los nombres son el contrato.

Publicar un puerto no es “abrirlo un poco”

Un contenedor que no publica puertos no es alcanzable desde tu máquina, aunque escuche en el 80 dentro de sí mismo. Publicar es pedirle al host que reenvíe. Y la sintaxis tiene una trampa de diseño heredada: si escribes 8080:80, la parte de la dirección se omite y Docker asume 0.0.0.0, es decir, todas las interfaces de tu máquina.

Traducido: tu aplicación deliberadamente vulnerable queda accesible para cualquiera que comparta red contigo. La red del trabajo, la de la cafetería, la wifi de invitados del hotel. Escribir 127.0.0.1:8080:80 es una sola diferencia de nueve caracteres y significa “solo procesos de esta máquina”. En este curso esa forma no es una recomendación de estilo; es obligatoria en todos los laboratorios.

Y hay un agravante que casi nadie espera la primera vez: en Linux, Docker inserta sus reglas de reenvío en una cadena que se evalúa antes que las reglas del firewall del sistema. Un puerto publicado en todas las interfaces puede seguir siendo alcanzable aunque tu firewall diga que ese puerto está cerrado. Volveremos a esto en la lección de reset y firewall; por ahora quédate con que la seguridad del puerto la decide el compose, no el firewall.

4Ejemplo sencillo

# Un laboratorio es un edificio con una sola puerta

proxy       la porteria: unica puerta a la calle, y da a un portal cerrado
app         el piso que vas a forzar
db          la caja fuerte del piso
monitor     las camaras: existen para que puedas ver que paso
atacante    tu, dentro del edificio, sin llaves de la calle

# Lo que define el edificio no son las habitaciones, son las puertas

lab_borde     la calle          solo la porteria da a ella
lab_interna   el portal         todos se ven, nadie sale
127.0.0.1     tu propia acera   la porteria solo abre hacia ahi

5Ejemplo técnico

Levanta el laboratorio base y pregúntale a Docker —no al compose— cómo quedó de verdad. Estas tres respuestas son las que auditas cada vez que montas un entorno:

La primera comprobación es la que de verdad importa y casi nadie hace: contar las líneas con puertos. En este laboratorio debe haber exactamente una. Si aparecen dos, alguien publicó algo sin querer; si la que hay no lleva dirección delante, el laboratorio está expuesto a la red local aunque “funcione igual”.

La segunda muestra el resolutor interno funcionando. Ese es el mecanismo que permite que la configuración del proxy diga proxy_pass http://app; sin conocer ninguna dirección, y el que hace que el laboratorio se comporte igual en cualquier máquina.

6Diagrama

flowchart LR
    H[host 127.0.0.1:8080] --> P[proxy]
    P --> A[app]
    P --> M[monitor]
    subgraph interna[lab_interna internal:true]
      A
      M
      D[db]
      T[atacante]
    end
    A --> D
    T --> A
    T --> D

7Código

Todo lo anterior cabe en el esqueleto del compose. Estas son las líneas que definen la seguridad del laboratorio; el resto son detalles de las imágenes:

# las dos redes: aqui esta el 90% del diseno
networks:
  lab_borde:
    driver: bridge          # tiene salida; solo el proxy la toca
  lab_interna:
    driver: bridge
    internal: true           # sin ruta de salida: no es un filtro, es una ausencia

services:
  proxy:
    ports:
      - "127.0.0.1:8080:80"   # con direccion: solo esta maquina
    networks:
      - lab_borde              # un pie fuera...
      - lab_interna            # ...y otro dentro. La unica pieza asi.

  app:
    networks:
      - lab_interna            # sin "ports": inalcanzable desde el host

  atacante:
    networks:
      - lab_interna            # el atacante vive dentro, no en tu terminal

Léelo como se lee un plano y no como configuración. Las dos preguntas que responde son “¿cuántas piezas aparecen bajo ports?” y “¿cuántas piezas listan más de una red?”. Las respuestas correctas en un laboratorio son una y una, y tiene que ser la misma pieza. Cualquier otra combinación necesita una justificación escrita.

8Qué puede salir mal

9Cómo lo abusaría un atacante

10Cómo defenderlo

11Laboratorio

12Ejercicios

networks:
  lab_cache:
    driver: bridge
    internal: true

services:
  cache:
    image: redis:7-alpine
    networks: [lab_cache]
  app:
    networks: [lab_interna, lab_cache]
  atacante:
    networks: [lab_interna, lab_cache]

13Preguntas de comprensión

14Reto adicional

15Resumen

16Mis notas

17Recursos