Cómo construir un laboratorio doméstico seguro de seguridad
La primera configuración útil más segura es una VM de Kali y OWASP Juice Shop en una red solo para el host. Y espera para comprar un mini PC hasta que sepas qué ejercicio ejecutarán esas dos máquinas.
La mayoría de los laboratorios domésticos fallan antes del primer escaneo porque su propietario compró hardware en lugar de elegir una pregunta. Un host modesto con un objetivo aislado puede enseñar más que un rack costoso de VMs que pasas el fin de semana reparando.
Esta guía te lleva durante ese primer fin de semana. Empieza eligiendo la habilidad. Dimensiona el host, aísla la red y verifica el laboratorio. Después, amplíalo hacia el trabajo ofensivo, defensivo o de análisis de malware.
En este artículo
- Elige la habilidad antes que la máquina
- El host más pequeño que no hará que odies la virtualización
- Construye la red para que un error permanezca dentro del laboratorio
- Construye Kali y un objetivo durante tu primer fin de semana
- Las instantáneas, los permisos y las notas forman parte del laboratorio
- Añade monitorización cuando quieras aprender detección junto con la explotación
- El análisis de malware es un laboratorio diferente, no la siguiente VM objetivo
- Pásate a Proxmox solo cuando la configuración actual sea la limitación
Elige la habilidad antes que la máquina
Un laboratorio doméstico de seguridad puede servir para cuatro trabajos diferentes:
- La práctica ofensiva utiliza Kali o Parrot, herramientas de reconocimiento, proxies web y objetivos vulnerables.
- La práctica del blue team necesita logs, tráfico de ataque generado, visibilidad de endpoints y telemetría de red.
- El análisis de malware requiere un entorno de detonación dedicado y una contención mucho más estricta.
- La investigación general de seguridad puede centrarse en DNS, VPN, hardening, controles de red o experimentos de infraestructura.
La guía de laboratorio doméstico de Lance Grover sostiene, con buen criterio, que casi nadie debería construir las cuatro cosas simultáneamente. Elige primero una pregunta.
Para esta guía, pregúntate: ¿puedes descubrir y documentar una vulnerabilidad web de forma segura? La configuración práctica utiliza Kali y OWASP Juice Shop. Terminarás descubriendo y documentando un servicio, conservando las pruebas, restaurando la línea base y redactando una nota de remediación.
Tu certificación marca el énfasis. Para OSCP, dedica el fin de semana a la enumeración, la explotación y la elaboración de informes. Para CEH v13, céntrate en las pruebas web y el descubrimiento de vulnerabilidades. Para el trabajo de SOC, conserva el atacante y el objetivo, y añade la telemetría más adelante.
El Ethical Hacking Institute describe un laboratorio como un lugar para practicar el recorrido completo, desde el reconocimiento hasta la elaboración de informes. Ese es el modelo mental correcto. Que Kali arranque es el principio, no el logro.
El host más pequeño que no hará que odies la virtualización
Para esta configuración, prioriza la RAM: 16GB es funcional y 32GB es cómodo. Ocho gigabytes es un mínimo que permite arrancar, no una recomendación que daría a un principiante.
Los rangos de hardware de Grover sitúan un ordenador de empresa reacondicionado aproximadamente entre $60–150, un mini PC entre $250–400 y un host de hypervisor dedicado en $500 o más. Esas cifras cubren el host, no todas las partes del laboratorio.
| Nivel del host | Objetivo de RAM | Mejor uso | Coste aproximado del host |
|---|---|---|---|
| Inicio más económico razonable | 16GB | Kali más un objetivo ligero | $60–150 |
| Host inicial cómodo | 32GB | Kali, Windows, varios objetivos o monitorización ocasional | $250–400 |
| Host de laboratorio dedicado | 64GB+ | Varios roles siempre activos e infraestructura repetible | $500+ |
Un OptiPlex o EliteDesk usado suele ser suficiente para el primer nivel. Un mini PC es una alternativa compacta. En cuanto al almacenamiento, 256GB puede contener un laboratorio mínimo; 512GB ofrece un margen de trabajo más cómodo, mientras que una unidad más grande resulta útil cuando conservas varias imágenes de Windows, instantáneas o datos de monitorización.
La guía de laboratorio de koushikos enumera 8GB de RAM y un SSD de 256GB como hardware mínimo, con 16GB o más y una unidad NVMe de 512GB en su configuración recomendada. Del mismo modo, el Ethical Hacking Institute sitúa 16GB como mínimo para dos o tres VMs simultáneas y recomienda 32GB o más.
Esas cifras describen cargas de trabajo diferentes. Dieciséis gigabytes son razonables para Kali y un objetivo ligero. Añade Windows, Ghidra o una VM de monitorización y la presión sobre la memoria aparece rápidamente. Grover describe la ejecución de Windows, Kali y Ghidra con 16GB antes de que el sistema fallara bajo carga. Su consejo es sencillo: “compra la RAM que crees que necesitarás y luego compra más”.
Nadie puede darte un número garantizado de VMs basándose solo en la RAM; la sobrecarga del hypervisor, el sistema operativo del host, las imágenes objetivo y la carga de monitorización lo determinan. Mide la presión de memoria en tu máquina antes de comprar más hardware.
Si ya tienes un ordenador de 16GB y software de hypervisor gratuito, el coste incremental puede ser cero. Comprar un ordenador de empresa usado de 16GB sitúa el gasto realista en hardware aproximadamente entre $60–150. Las cifras de $520–790 de la guía de koushikos describen una configuración más completa que la configuración mínima del primer fin de semana.
Construye la red para que un error permanezca dentro del laboratorio
“Usa una VLAN” es un consejo perezoso para un primer fin de semana; una red solo para el host es más fácil de verificar. Instala sistemas vulnerables únicamente después de comprobar cada adaptador virtual.
La topología inicial es:
La máquina host se conecta a una red virtual aislada con la VM atacante de Kali y la VM objetivo de Juice Shop
La red solo para el host conecta el host y las VMs participantes sin proporcionarles una ruta normal a Internet. La red interna conecta las VMs entre sí y excluye al host. NAT proporciona a una VM una ruta a Internet; úsala únicamente para actualizaciones controladas y elimínala después de los objetivos vulnerables.
Un adaptador en modo bridge coloca la VM directamente en la misma red física que tus dispositivos domésticos. No conectes VMs vulnerables en modo bridge a tu LAN doméstica. Un único adaptador configurado accidentalmente en modo bridge puede poner el laboratorio en tu red doméstica.
Evita que la subred del laboratorio se solape con la red doméstica. Los rangos privados idénticos hacen que el enrutamiento sea confuso precisamente cuando necesitas saber adónde va el tráfico.
Los ejemplos de Grover sobre una smart TV y un termostato señalan otro aspecto útil: el filtrado DNS no es aislamiento. Su smart TV evitó Pi-hole usando 8.8.8.8 codificado y su termostato realizó conexiones salientes a 23 IP externas. Los controles que dependen de que un dispositivo coopere son más débiles que una frontera de red.
Docker requiere la misma precaución. Los contenedores comparten el kernel del host, por lo que los objetivos en contenedores merecen un aislamiento estricto del host y de la red doméstica. Para esta primera configuración, una VM objetivo es más fácil de entender y de restaurar.
Construye Kali y un objetivo durante tu primer fin de semana
Utiliza este plan de viernes a domingo como calendario aproximado. El tiempo depende de tus descargas, del hardware del host y del método de instalación del objetivo.
Instala y aísla el laboratorio el viernes
VirtualBox es una opción predeterminada de escritorio accesible. VMware Workstation o Player ofrece otra experiencia de escritorio madura, y Hyper-V encaja de forma natural en hosts Windows. Proxmox puede esperar.
Instala el hypervisor que hayas elegido. En VirtualBox, abre Tools, después Network Manager y luego Host-only Networks. Crea una red solo para el host y deja DHCP activado, a menos que tengas un motivo para gestionar las direcciones manualmente. Otros hypervisors utilizan etiquetas diferentes. Necesitas una red virtual privada sin conexión en modo bridge.
Si el hypervisor indica que VT-x o AMD-V no están disponibles, comprueba la BIOS o UEFI antes de solucionar problemas de las VMs.
Crea dos máquinas:
- Kali: un adaptador solo para el host; añade NAT únicamente durante las actualizaciones.
- Juice Shop: un adaptador solo para el host.
- Host: acceso a la red solo para el host para la administración.
No asignes todos los adaptadores a todas las VMs.
Construye el atacante y el objetivo el sábado
Instala Kali Linux como VM atacante. Asigna entre 4–8GB de RAM si el host puede permitírselo, dejando suficiente para el sistema operativo del host. Parrot es una alternativa razonable, pero este ejemplo práctico utiliza Kali.
Para Juice Shop, utiliza una imagen de VM prediseñada si está disponible en la fuente de distribución del objetivo. De lo contrario, ejecuta Juice Shop dentro de una VM Linux pequeña cuyo único adaptador de red sea solo para el host. No ejecutes el objetivo directamente en tu red doméstica. Si utilizas un contenedor, mantén el contenedor y su host dentro del mismo límite aislado del laboratorio.
Un objetivo diferente cambia el ejercicio. DVWA y WebGoat son adecuados para pruebas web. Metasploitable 2 cubre una explotación introductoria más amplia. Las imágenes de VulnHub ofrecen otros sistemas deliberadamente vulnerables. Estos objetivos no son intercambiables.
Utiliza NAT temporalmente para las actualizaciones y después desconéctalo de Juice Shop.
Verifica, prueba y documenta el domingo
Inspecciona el modo del adaptador de cada VM en el hypervisor. Tienes una configuración aprobada cuando:
- Kali puede hacer ping o conectarse al servicio objetivo a través de la red del laboratorio.
- El objetivo tiene un adaptador, una dirección del rango del laboratorio y ninguna ruta predeterminada.
- La LAN del host no puede alcanzar la dirección del objetivo.
- Ninguna VM tiene un adaptador en modo bridge.
Desde Kali, inspecciona la dirección y la tabla de rutas:
ip addr
ip route
ping -c 3 <target-ip>Identifica la red solo para el host a partir de la dirección mostrada por ip addr y la ruta mostrada por ip route. Por ejemplo, si Kali tiene 192.168.56.10/24, el rango aislado del laboratorio es 192.168.56.0/24. Utiliza tu rango real y escanea únicamente ese rango aislado:
nmap -sn 192.168.56.0/24
nmap -sV -p- <target-ip>El primer escaneo debería encontrar las máquinas del laboratorio. El segundo identifica los servicios del objetivo. Verifica el adaptador y la ruta predeterminada del objetivo dentro de la propia VM o mediante el hypervisor; comprobar únicamente la dirección no demuestra el aislamiento.
Abre Juice Shop en un navegador y elige Burp Suite u OWASP ZAP. Elige un proxy de interceptación. Mapea la aplicación e identifica una vulnerabilidad. Guarda la solicitud, la respuesta, la funcionalidad afectada y las capturas de pantalla o la salida de terminal que respalden el hallazgo.
Mantén todas las pruebas dentro del alcance documentado de Juice Shop. No hagas pivoting desde el laboratorio hacia el host o la red doméstica.
Termina con un informe breve que contenga:
- Alcance y fecha
- Topología del laboratorio
- Dirección y versión del objetivo
- Pasos para reproducir
- Pruebas
- Impacto de seguridad
- Remediación
Una VM de Kali que arranca no demuestra casi nada. El informe es lo que hace útil el ejercicio.
Las instantáneas, los permisos y las notas forman parte del laboratorio
Toma una instantánea limpia después de que la frontera de red supere sus pruebas:
juice-shop-baseline-YYYY-MM-DD
Antes de la explotación o de un cambio importante de configuración, toma otra instantánea. Restaura deliberadamente la línea base y verifica que Kali y Juice Shop sigan comunicándose. Las instantáneas forman parte del flujo de pruebas. Utilízalas como puntos de restauración del laboratorio.
Como dice ITU Online, “Los buenos laboratorios son aburridos de mantener”. Ese es el objetivo. Una infraestructura aburrida deja tiempo para el ejercicio.
Registra:
- Nombres y roles de las VMs
- Memoria y CPU asignadas
- Adaptadores de red
- Subred y direcciones del laboratorio
- Versión del objetivo
- Comandos ejecutados
- Hallazgos y pruebas
- Nombres de las instantáneas
- Pasos de limpieza
Si utilizas Git, mantén las credenciales, las muestras privadas y los datos sensibles fuera del repositorio. Los scripts, las notas y los informes pueden convertirse en material útil para tu portfolio cuando muestran qué probaste y cómo llegaste al resultado.
Prueba sistemas que sean de tu propiedad; para sistemas de terceros, obtén permiso explícito por escrito antes de realizar pruebas. Evita herramientas o software crackeados. Un laboratorio que posees y aíslas mantiene la práctica dentro de un límite que controlas.
Antes de dar por terminado el fin de semana, registra el objetivo. Confirma los modos de los adaptadores, restaura la instantánea de línea base, guarda las pruebas y redacta la remediación.
Añade monitorización cuando quieras aprender detección junto con la explotación
Un laboratorio de blue team comienza con tráfico y una pregunta. Un dashboard vacío de SIEM es otra tarea de mantenimiento.
Conserva Kali y un objetivo y después añade un rol de monitorización. Genera tráfico de ataque controlado e investiga los logs de endpoint y la telemetría de red resultantes. Shield Operations y el Ethical Hacking Institute orientan Wazuh hacia la visibilidad de endpoints y Zeek o Suricata hacia la detección centrada en la red. Elastic puede centralizar y buscar eventos, pero también añade exigencias de recursos y mantenimiento.
Utiliza esta progresión:
- Empieza con logs del objetivo y del atacante.
- Añade Wazuh cuando necesites visibilidad de endpoints.
- Añade Zeek o Suricata cuando necesites detección de red.
- Considera Elastic después de tener un flujo de investigación.
La tabla de asignación de VMs de la guía de koushikos ofrece una asignación indicativa para SIEM de 4–8 vCPU y 8–16GB de RAM. Utilízala como cifra de planificación, no como un mínimo universal. El resultado lo determinan la herramienta elegida y el volumen de eventos.
Haz que Kali realice descubrimientos contra un objetivo y después pregúntate qué pruebas debería encontrar un defensor. Esa pregunta convierte un exploit en práctica de detección.
El análisis de malware es un laboratorio diferente, no la siguiente VM objetivo
El análisis de malware necesita un límite más estricto que las pruebas web normales. Planifica un entorno de detonación dedicado, controles de red rigurosos, instantáneas y herramientas como Cuckoo o CAPEv2. Mantenlo separado de la red doméstica y, siempre que sea posible, del laboratorio ofensivo cotidiano.
Una VM de Windows estéril puede comportarse de forma diferente a un endpoint real. Grover describe cómo un malware identificó un sandbox y se negó a detonar. Hacer que una VM parezca habitada para derrotar ese comportamiento queda fuera de esta guía y no es un paso seguro para principiantes.
Utiliza una red controlada y conserva un punto de restauración limpio antes del análisis. Mantén los datos personales y las credenciales reales fuera del entorno. El objetivo es la contención: define qué puede salir del laboratorio antes de introducir una muestra.
El laboratorio de Kali y Juice Shop del primer fin de semana es el entorno equivocado para ejecutar malware. Si no puedes explicar cómo se impide que una muestra llegue a tu red doméstica, detente ahí.
Pásate a Proxmox solo cuando la configuración actual sea la limitación
Proxmox es un paso de graduación útil cuando tu configuración actual se convierte en la limitación. Haz el cambio cuando varias VMs siempre activas, redes virtuales repetibles o la competencia por los recursos hagan que el hypervisor de escritorio sea el cuello de botella.
Un orden de actualización sensato es:
- Añade RAM.
- Aumenta la capacidad del SSD o NVMe.
- Reserva recursos para la monitorización.
- Pásate a hardware de hypervisor y red dedicado cuando los servicios persistentes lo requieran.
- Para un host que contenga credenciales, notas o muestras, añade cifrado de disco completo y una contraseña de BIOS; estas medidas protegen la propia máquina si se pierde o si alguien obtiene acceso físico.
Antes de cada ejercicio, utiliza la misma comprobación previa:
- Registra el objetivo y el alcance.
- Comprueba el modo de cada adaptador.
- Confirma la instantánea de línea base.
- Escribe la condición de parada.
Después ejecuta el ejercicio, guarda las pruebas y redacta la remediación. Amplía solo cuando la siguiente pregunta requiera otra máquina.