¿Qué es Docker?

Docker es una plataforma para crear y ejecutar contenedores. Un contenedor es una forma de empaquetar una aplicación junto con sus dependencias, pero sin incluir un sistema operativo completo.

La diferencia clave: los contenedores comparten el kernel del anfitrión (tu Linux). No emulan hardware. Son procesos aislados con sus propias librerías, sistema de archivos y red, pero ligerísimos.

Analógico rápido:

• Una VM es como alquilar una casa entera: tienes tu cocina, tu salón, tu caldera, todo para ti solo.
• Un contenedor es un apartamento dentro de un edificio: compartes estructura, fontanería y ascensor, pero cada uno tiene su puerta con llave.

Eso hace que los contenedores:

• Arranquen en milisegundos.
• Ocupen megas, no gigas.
• Puedas tener decenas funcionando a la vez en un portátil normal.

Docker vs. VM en una tabla

Por qué Docker le sienta de cine a tu laboratorio de hacking

1. Ligereza extrema

2. Usar y tirar

magina que estás probando un SQLi y dejas la base de datos hecha un Cristo. Con Docker:

docker rm -f dvwa && docker run -d --rm -p 80:80 vulnerables/web-dvwa

docker rm -f dvwa && docker run -d --rm -p 80:80 vulnerables/web-dvwa

En tres segundos tienes la aplicación virgen otra vez. Sin restaurar snapshots de 15 GB, sin reinicios.

El flag --rm borra el contenedor automáticamente al pararlo, así que no acumulas basura.

3. Snapshots integradas y rápidas

Docker te permite hacer «fotos» del estado de un contenedor de varias formas:

• docker commit: guardas los cambios en una nueva imagen (como un snapshot de VM pero pesa mucho menos).
• Volúmenes: separas datos persistentes del contenedor; si rompes la app, borras el contenedor y levantas otro con el mismo volumen intacto.
• Checkpoint (experimental): congelas el estado de un contenedor en disco y lo restauras en milisegundos.

Para el laboratorio, lo más común es usar docker-compose down -v && docker-compose up -d y te olvidas.

4. Infraestructura como código

Tu laboratorio se describe en archivos docker-compose.yml. Son instrucciones claritas de qué servicios levantar, qué puertos exponer, qué redes internas crear, etc. Esto te permite:

• Compartir tu lab con colegas en un solo archivo.
• Versionarlo con Git.
• Levantar todo el entorno con docker-compose up -d en cualquier máquina con Docker.

5. Ecosistema de imágenes vulnerables

La comunidad de hacking ético tiene un montón de aplicaciones deliberadamente inseguras listas para descargar como imágenes Docker:

• DVWA (Damn Vulnerable Web Application)
• OWASP Juice Shop (la más moderna, con JWT, GraphQL…)
• Metasploitable2 (hay imágenes no oficiales ligeras)
• Vulnerable WordPress, bWAPP, NodeGoat, WebGoat…
• Incluso puedes correr un Kali completo como contenedor (kalilinux/kali-rolling) con herramientas metidas.

Esto te ahorra instalar LAMP, configurar PHP, MySQL… Un solo comando y a picar.

¿Cuándo no deberías usar Docker en tu laboratorio?

Docker no es una bala de plata. Hay escenarios donde las VMs siguen siendo necesarias:

• Metasploitable3: necesita un controlador de dominio Windows, servicios SMB complejos y hasta 15 GB de espacio. Docker no es el sitio para eso (de hecho, en el roadmap verás que le dedicamos su propia sección de VMs).
• Pruebas que requieran kernels específicos (exploits a nivel kernel, módulos custom): como el contenedor comparte kernel con el host, no puedes hacer mucho daño sin cargarte tu propio sistema.
• Active Directory completo: para simular un entorno corporativo con varios DCs, DNS, políticas de grupo… Necesitas VMs con Windows Server. Docker puede ayudar con algunos servicios (LDAP, Kerberos), pero no reemplaza un AD real.
• Cuando necesitas aislamiento real: si estás analizando malware peligroso, una VM con snapshots aisladas es más segura que un contenedor que comparte kernel (aunque con cuidado, Docker no es inseguro).

¿Es Docker seguro para mi laboratorio de hacking?

Sí, con matices. Como atacante, el contenedor vulnerable es tu víctima; no vas a romper tu anfitrión a menos que explotes una vulnerabilidad del propio motor Docker (raro en entornos actualizados). Aun así, buenas prácticas:

• Ejecuta los servicios vulnerables solo en redes internas que no tengan salida a Internet, como las VLANs que aprendiste a crear.
• No montes directorios sensibles de tu host dentro del contenedor (-v /:/host sería una locura).
• Si quieres un extra de seguridad, corre Docker en modo rootless o con un usuario sin privilegios.

Pero para hacer XSS, SQLi, command injection en un DVWA… puedes estar tranquilo. Ataque y derribo sin miedo.