Tema 4

4. Preparación del laboratorio, máquinas vulnerables y entorno de trabajo seguro

Un laboratorio bien diseñado permite practicar técnicas ofensivas sin dañar sistemas reales, sin salir del marco legal y sin exponer la red personal o corporativa. La seguridad del entorno de práctica es parte del aprendizaje profesional.

Objetivo Construir un entorno de práctica controlado
Enfoque Aislamiento, seguridad y repetibilidad
Resultado Practicar pentesting sin afectar terceros

4.1 Introducción

El pentesting se aprende practicando, pero no se practica sobre sistemas ajenos ni sobre entornos productivos sin autorización. Para desarrollar criterio técnico hace falta un laboratorio propio, aislado y preparado para equivocarse sin causar daño.

Un laboratorio de pentesting permite ejecutar escaneos, enumerar servicios, validar vulnerabilidades, analizar tráfico, probar herramientas y estudiar rutas de ataque en objetivos diseñados para ese fin.

Este tema explica cómo organizar ese entorno: qué equipos usar, cómo separar redes, qué máquinas vulnerables instalar, cómo manejar snapshots, qué precauciones tomar y cómo evitar que una práctica se convierta en un incidente real.

4.2 Por qué necesitas un laboratorio

Un laboratorio cumple una función técnica y ética. Técnica, porque permite repetir ejercicios hasta comprenderlos. Ética, porque evita probar herramientas o técnicas sobre sistemas que no fueron autorizados.

  • Permite aprender sin depender de entornos externos.
  • Facilita repetir ejercicios desde cero.
  • Permite observar tráfico, logs y cambios de sistema con libertad.
  • Reduce el riesgo de afectar redes reales.
  • Ayuda a documentar procedimientos y resultados.
  • Permite comparar distintas herramientas ante el mismo escenario.
Un entorno de práctica no debe tener rutas innecesarias hacia redes productivas, datos personales, sistemas corporativos ni servicios públicos.

4.3 Requisitos mínimos de hardware

El laboratorio puede ser simple al inicio. No hace falta una infraestructura costosa para aprender fundamentos, pero sí conviene contar con recursos suficientes para ejecutar al menos una máquina atacante y una o dos máquinas objetivo.

Recurso Mínimo recomendado Ideal para mayor comodidad
Memoria RAM 8 GB 16 GB o más
Procesador 4 núcleos lógicos 6 a 8 núcleos o más
Disco 100 GB libres SSD con 200 GB o más
Virtualización Soporte VT-x o AMD-V habilitado Virtualización con snapshots fluidos
Red Conexión local estable Adaptadores separados para laboratorio avanzado

4.4 Software de virtualización

La virtualización permite ejecutar varios sistemas dentro de una misma computadora. Para un laboratorio de pentesting, es la opción más práctica porque facilita crear, aislar, pausar, clonar y restaurar máquinas.

  • VirtualBox: opción gratuita y suficiente para laboratorios iniciales.
  • VMware Workstation Player o Pro: alternativa robusta, con buen rendimiento y soporte de snapshots según edición.
  • Hyper-V: integrado en algunas ediciones de Windows, útil aunque puede requerir ajustes de compatibilidad.
  • Proxmox: opción avanzada para laboratorios dedicados en un servidor físico.

La elección no es lo más importante. Lo fundamental es entender cómo configurar redes virtuales, snapshots y aislamiento.

4.5 Máquina atacante

La máquina atacante es el sistema desde el cual se ejecutan herramientas de reconocimiento, análisis, enumeración y validación. En muchos laboratorios se usa una distribución orientada a seguridad, aunque también se puede trabajar desde un Linux general con herramientas instaladas manualmente.

Sistema Uso Comentario
Kali Linux Distribución con herramientas de pentesting preinstaladas Muy usada para aprendizaje y práctica
Parrot Security Distribución de seguridad con foco en privacidad y análisis Alternativa completa a Kali
Ubuntu o Debian Base general para instalar herramientas específicas Útil para aprender dependencias y configuración manual
Windows Pruebas con herramientas específicas del ecosistema Microsoft Interesante para Active Directory y análisis corporativo

4.6 Máquinas vulnerables

Las máquinas vulnerables son objetivos diseñados para practicar. Contienen servicios, configuraciones o aplicaciones inseguras de forma intencional. Deben ejecutarse solo en entornos controlados porque muchas tienen vulnerabilidades reales y conocidas.

  • Metasploitable: máquina Linux vulnerable para practicar enumeración y explotación de servicios.
  • OWASP Broken Web Apps: colección de aplicaciones web vulnerables.
  • OWASP Juice Shop: aplicación moderna para practicar fallas web y de API.
  • DVWA: Damn Vulnerable Web Application, útil para practicar vulnerabilidades web clásicas.
  • VulnHub: colección de máquinas descargables para entornos locales.
  • Hack The Box Academy o TryHackMe: laboratorios guiados en plataformas externas autorizadas.
Una máquina vulnerable no debe conectarse a una red abierta ni exponerse a internet. Está hecha para ser comprometida.

4.7 Diseño de red del laboratorio

El diseño de red es el punto más importante de seguridad. La máquina atacante y los objetivos deben poder comunicarse entre sí, pero no deberían tener acceso innecesario a la red doméstica, corporativa o a internet.

Los modos de red más comunes en virtualización son:

Modo Descripción Uso recomendado
NAT La VM sale a internet a través del host Actualizar herramientas en la máquina atacante
Bridged La VM aparece como equipo más de la red física Evitarlo para máquinas vulnerables salvo necesidad justificada
Host-only Comunicación entre host y VMs, sin salida directa a internet Práctica local controlada
Internal network Comunicación solo entre VMs de esa red interna Laboratorio aislado para objetivos vulnerables

4.8 Topología básica recomendada

Para comenzar, una topología simple es suficiente. La máquina atacante puede tener dos interfaces: una para internet mediante NAT y otra para la red aislada del laboratorio. Las máquinas vulnerables deberían estar solo en la red aislada.

  • Atacante: Kali Linux con una interfaz NAT y una interfaz host-only o interna.
  • Objetivo 1: máquina vulnerable Linux solo en red interna.
  • Objetivo 2: aplicación vulnerable web solo en red interna.
  • Host físico: acceso de administración, pero sin exponer los objetivos a internet.

Esta separación permite actualizar herramientas desde la máquina atacante y, al mismo tiempo, mantener los objetivos vulnerables aislados.

4.9 Direccionamiento IP y nombres

Conviene asignar un rango de red específico al laboratorio para evitar confusión con otras redes. Por ejemplo, una red interna como 192.168.56.0/24 o 10.10.10.0/24, según el software de virtualización utilizado.

Una tabla simple ayuda a documentar el entorno:

Equipo Rol IP sugerida Red
kali-lab Atacante 192.168.56.10 Laboratorio
metasploitable Objetivo vulnerable 192.168.56.20 Laboratorio
juice-shop Aplicación vulnerable 192.168.56.30 Laboratorio
win-lab Objetivo Windows de práctica 192.168.56.40 Laboratorio

4.10 Snapshots y restauración

Los snapshots permiten guardar el estado de una máquina virtual y volver a ese punto después de una práctica. Son esenciales en pentesting porque muchas pruebas modifican archivos, servicios, credenciales, logs o configuraciones.

  • Crear un snapshot limpio después de instalar y actualizar la máquina.
  • Crear otro snapshot antes de pruebas destructivas o de explotación.
  • Nombrar snapshots con fecha y propósito.
  • No acumular snapshots indefinidamente porque consumen espacio y pueden degradar rendimiento.
  • Restaurar objetivos vulnerables después de prácticas intensivas.
Antes de una práctica nueva, volver a un estado conocido evita resultados confusos causados por cambios de ejercicios anteriores.

4.11 Separación entre laboratorio y equipo personal

El host físico suele contener información personal, sesiones abiertas, claves SSH, archivos de trabajo y acceso a redes reales. Por eso no debe tratarse como parte del laboratorio vulnerable.

  • No guardar credenciales reales dentro de máquinas vulnerables.
  • No montar carpetas compartidas con información sensible.
  • No copiar herramientas o payloads al host sin necesidad.
  • No usar la misma contraseña personal en máquinas de laboratorio.
  • No ejecutar servicios vulnerables directamente en el sistema principal.
  • Evitar port forwarding desde la red física hacia objetivos vulnerables.

4.12 Actualización de herramientas

La máquina atacante debe mantenerse actualizada, pero los objetivos vulnerables no siempre deben actualizarse. Si se actualiza una máquina vulnerable, puede dejar de ser vulnerable y perder valor para el ejercicio.

Componente Actualizar Motivo
Máquina atacante Sí, con regularidad Corregir fallas, mejorar herramientas y mantener compatibilidad
Máquina vulnerable No necesariamente Puede eliminar vulnerabilidades necesarias para practicar
Software de virtualización Sí, con criterio Mejorar estabilidad y corregir problemas de seguridad
Host físico Debe mantenerse protegido porque sostiene todo el laboratorio

4.13 Herramientas iniciales del entorno

La mayoría de distribuciones de seguridad ya incluyen muchas herramientas, pero conviene entender para qué sirve cada grupo. El objetivo no es instalar todo, sino saber qué tipo de tarea resuelve cada herramienta.

  • Reconocimiento y red: ip, ping, traceroute, dig, whois, netstat, ss.
  • Escaneo: Nmap y herramientas similares para descubrir hosts, puertos y servicios.
  • Web: Burp Suite Community, OWASP ZAP, navegadores con extensiones de análisis.
  • Tráfico: Wireshark y tcpdump para observar paquetes.
  • Enumeración: clientes SMB, LDAP, FTP, SSH, HTTP y scripts específicos.
  • Notas: un sistema ordenado para registrar comandos, evidencias y observaciones.

4.14 Organización de evidencias y notas

Desde el inicio conviene documentar como si se tratara de un trabajo profesional. Esto desarrolla hábitos útiles para reportes reales y evita perder información entre pruebas.

Una estructura simple de carpetas puede incluir:

  • scope: alcance del laboratorio, IPs, nombres y objetivos.
  • recon: resultados de reconocimiento y escaneo.
  • evidence: capturas, respuestas relevantes y pruebas de concepto.
  • notes: hipótesis, pasos realizados y decisiones.
  • reports: borradores de hallazgos y conclusiones.
Una práctica sin notas enseña menos. Documentar comandos, resultados y errores ayuda a convertir la práctica en aprendizaje repetible.

4.15 Seguridad al descargar máquinas e imágenes

Las imágenes de laboratorio deben obtenerse desde fuentes confiables. Una máquina vulnerable descargada de internet ejecuta código dentro de tu equipo, por lo que no conviene tratarla como inofensiva.

  • Descargar desde sitios oficiales o comunidades reconocidas.
  • Verificar checksums cuando estén disponibles.
  • Evitar imágenes modificadas de procedencia dudosa.
  • Ejecutar máquinas vulnerables sin acceso a redes reales.
  • No iniciar sesión con credenciales personales dentro de ellas.
  • Eliminar o aislar imágenes que se comporten de forma inesperada.

4.16 Laboratorios locales y plataformas externas

Además del laboratorio local, existen plataformas de práctica que ofrecen entornos preparados y autorizados. Son útiles porque reducen problemas de configuración y permiten ejercicios guiados o escenarios realistas.

Tipo Ventajas Cuidados
Laboratorio local Control total, repetición, análisis de red y snapshots Requiere configurar aislamiento correctamente
Plataformas guiadas Aprendizaje ordenado y escenarios listos Respetar reglas de la plataforma y no salir del entorno
CTF Desafíos técnicos y práctica de pensamiento lateral No confundir CTF con pentesting profesional completo
Rangos corporativos Escenarios realistas de red y Active Directory Requieren más recursos y planificación

4.17 Buenas prácticas de operación

Un laboratorio debe operarse con disciplina. Aunque sea personal, conviene aplicar prácticas similares a las de un entorno profesional.

  • Encender solo las máquinas necesarias para el ejercicio.
  • Confirmar la red de cada VM antes de iniciar pruebas.
  • Guardar snapshots antes de cambios importantes.
  • Usar nombres e IPs documentados.
  • No mezclar ejercicios distintos sin limpiar el entorno.
  • Separar datos de práctica de datos personales.
  • Revisar periódicamente que no existan servicios expuestos hacia la red física.

4.18 Errores frecuentes al preparar el laboratorio

  • Usar modo bridged para máquinas vulnerables sin entender el riesgo.
  • Exponer aplicaciones vulnerables a internet por accidente.
  • Practicar con objetivos públicos sin autorización.
  • No tomar snapshots antes de pruebas invasivas.
  • Guardar contraseñas reales dentro del laboratorio.
  • No documentar IPs, usuarios, versiones y cambios.
  • Actualizar máquinas vulnerables y romper el escenario de práctica.
  • Confundir un CTF con una metodología completa de pentesting.

4.19 Checklist de laboratorio seguro

Antes de iniciar cualquier práctica, revisa esta lista:

  • La máquina atacante está actualizada.
  • Las máquinas vulnerables están en una red aislada.
  • No hay exposición accidental hacia internet.
  • Los objetivos tienen snapshots limpios disponibles.
  • Las IPs y roles están documentados.
  • No hay datos personales ni credenciales reales en los objetivos.
  • Las carpetas compartidas están desactivadas o controladas.
  • El ejercicio tiene un objetivo definido.
  • Las notas y evidencias se guardarán de forma ordenada.

4.20 Qué debes recordar de este tema

  • El laboratorio permite practicar legal y técnicamente en un entorno controlado.
  • Las máquinas vulnerables deben estar aisladas de redes reales e internet.
  • La virtualización y los snapshots hacen que la práctica sea repetible.
  • La máquina atacante puede tener salida a internet, pero los objetivos vulnerables no deberían necesitarla.
  • Documentar comandos, evidencias y cambios es parte del entrenamiento profesional.
  • La seguridad del laboratorio depende más del diseño de red que de la cantidad de herramientas instaladas.

4.21 Conclusión

Preparar un laboratorio seguro es el primer paso práctico del aprendizaje ofensivo responsable. Permite explorar técnicas reales sin cruzar límites legales, sin afectar sistemas de terceros y sin poner en riesgo información personal o corporativa.

En el próximo tema revisaremos los fundamentos de redes, sistemas operativos y servicios que necesitas dominar para que las herramientas de pentesting tengan sentido técnico y no se usen como cajas negras.