1.4 Redes en el laboratorio

El modo de red que eliges para tus máquinas virtuales no es solo una cuestión de conectividad — es una decisión de seguridad. Una VM mal aislada puede exponer tu red doméstica a payloads activos, contaminar operaciones entre sí, o filtrar tráfico que no debería salir. Antes de encender cualquier máquina vulnerable, tienes que entender qué está conectado a qué.

1.4.1 NAT, Host-Only, Bridge e Internal Network — cuándo usar cada modo

Todos los hypervisores principales (VirtualBox, VMware, KVM/QEMU) implementan los mismos cuatro modos de red con nombres ligeramente distintos pero comportamiento equivalente. Entender qué hace cada uno — y cuándo usarlo — es la base de cualquier laboratorio bien construido.

NAT — Network Address Translation

Con NAT, el anfitrión actúa como router para la VM. La VM obtiene una IP privada en una subred gestionada por el hypervisor (típicamente 10.0.2.x en VirtualBox, 192.168.x.x en VMware). Todo el tráfico de la VM hacia internet sale con la IP del anfitrión — la VM está enmascarada detrás de él.

Comunicación	¿Posible?
VM → Internet	✅ Sí — a través del anfitrión
VM → Anfitrión	✅ Sí — limitada (solo hacia la gateway del NAT)
Anfitrión → VM	⚠️ Solo con port forwarding configurado manualmente
Red física → VM	❌ No — la VM es invisible desde fuera
VM ↔ VM (mismo NAT)	⚠️ Depende del hypervisor — generalmente no sin configuración adicional

Cuándo usar NAT:

VM de ataque con acceso a internet: tu Kali necesita descargar herramientas, actualizar repositorios o acceder a recursos externos — sin exponer nada a tu red doméstica
VM de un solo uso con acceso temporal a internet: instalar dependencias y luego aislar
Cuando la VM no necesita ser accesible desde fuera: si solo necesitas salida, NAT es la opción más limpia

⚠️

Precaución con VMs de malware en NAT: Una VM con malware activo en modo NAT puede conectarse a internet — al C2 del malware, a servidores de exfiltración, a actualizadores automáticos. Si quieres analizar malware, NAT no es suficiente aislamiento. Usa Internal Network o una red completamente aislada.

Bridge — Adaptador puente

Con Bridge, la VM se conecta directamente a la interfaz de red física del anfitrión. El hypervisor crea un puente virtual que hace que la VM sea indistinguible de cualquier otro equipo en tu red física. Obtiene una IP del mismo router, con la misma máscara de subred, y es visible para todos los equipos de la red.

Comunicación	¿Posible?
VM → Internet	✅ Sí — directamente, con IP propia
VM ↔ Anfitrión	✅ Sí — como dos equipos en la misma red
Red física → VM	✅ Sí — cualquier equipo de la red puede ver y acceder a la VM
VM ↔ VM	✅ Sí — si ambas están en Bridge

Cuándo usar Bridge:

VM que necesita ser accesible desde otros equipos de la red: un servidor web de pruebas que un compañero necesita probar, una VM de Active Directory a la que se conectan otras máquinas físicas o virtuales
Laboratorio de AD donde las máquinas Windows deben verse entre sí y con tu red: para que el DNS, Kerberos y SMB funcionen correctamente, a veces es necesario que las VMs estén en el mismo segmento que el anfitrión
Captura de tráfico de red física: si necesitas hacer sniffing del tráfico real de tu red desde una VM

🚫

Bridge en laboratorios de seguridad: Nunca uses Bridge para VMs vulnerables como Metasploitable, DVWA o máquinas de CTF sin verificar primero que estás en una red de confianza. Una VM con servicios vulnerables en Bridge es accesible para cualquier equipo de tu red local — y si estás en una red compartida (universidad, coworking, hotspot público), para cualquiera en esa red.

Host-Only — Solo anfitrión

Con Host-Only, el hypervisor crea una interfaz de red virtual en el anfitrión (en VirtualBox se llama vboxnet0, en VMware vmnet1) y conecta las VMs a esa red privada. El anfitrión puede comunicarse con las VMs a través de esa interfaz virtual, pero las VMs no tienen acceso a internet ni a la red física.

Comunicación	¿Posible?
VM → Internet	❌ No (sin configuración adicional)
VM ↔ Anfitrión	✅ Sí — a través de la interfaz virtual del anfitrión
Red física → VM	❌ No
VM ↔ VM	✅ Sí — si ambas están en la misma red Host-Only

Cuándo usar Host-Only:

Escenario de ataque/defensa entre anfitrión y VMs: tu anfitrión actúa como atacante o como monitor, y las VMs son los objetivos — sin exposición a la red física
VMs vulnerables que el anfitrión necesita gestionar: puedes hacer SSH desde tu anfitrión a Metasploitable sin que el resto de tu red vea la VM
Servidor local de apoyo al laboratorio: una VM con un servidor DNS, un servidor de logs o un servidor de archivos que solo necesita comunicarse con el anfitrión

💡

Host-Only + NAT en la misma VM: Una configuración muy común en laboratorios es dar a la VM de ataque dos adaptadores: uno NAT (para internet) y uno Host-Only (para la red del laboratorio). Así Kali puede actualizar herramientas desde internet Y atacar las VMs vulnerables en la red aislada — sin que las VMs vulnerables tengan acceso a internet.

Internal Network — Red interna

Internal Network es igual que Host-Only con una diferencia crítica: el anfitrión no participa en la red. Solo las VMs que estén configuradas en la misma red interna pueden comunicarse entre sí. El anfitrión es invisible — ni puede ver las VMs ni las VMs pueden verlo a él.

Comunicación	¿Posible?
VM → Internet	❌ No
VM ↔ Anfitrión	❌ No
Red física → VM	❌ No
VM ↔ VM (misma red interna)	✅ Sí — aisladas del resto

Cuándo usar Internal Network:

Análisis de malware: la VM de análisis dinámico no debe poder comunicarse con internet real ni con el anfitrión — solo con las VMs de soporte del entorno de análisis (FakeNet, servidor DNS de respuesta falsa)
Laboratorio de red completamente aislado: simular una red corporativa completa (DC + clientes + servidores) sin ningún punto de salida
Entornos de máximo aislamiento: cuando necesitas garantizar que ningún tráfico puede salir del laboratorio bajo ninguna circunstancia

Tabla resumen y guía de decisión

Modo	Internet	↔ Anfitrión	↔ VMs	Red física	Uso principal en laboratorio
NAT	✅	⚠️ Limitada	⚠️ Parcial	❌	VM atacante con acceso a internet
Bridge	✅	✅	✅	✅	Laboratorio de AD, servidores accesibles desde la red
Host-Only	❌	✅	✅	❌	Laboratorio aislado gestionable desde el anfitrión
Internal	❌	❌	✅	❌	Análisis de malware, aislamiento máximo

💡

No hay un modo "mejor": La elección depende del escenario. En un laboratorio real se usan varios modos simultáneamente — una misma VM puede tener dos o tres adaptadores de red, cada uno en un modo distinto, para satisfacer requisitos de conectividad y aislamiento al mismo tiempo.

1.4.2 Configuración en VirtualBox, VMware y KVM

Saber qué hace cada modo es la teoría. Saber configurarlo en el hypervisor que usas es lo que te permite montar el laboratorio. Los tres hypervisores más usados en seguridad son VirtualBox (gratuito, multiplataforma), VMware Workstation/Fusion (comercial, muy usado en entornos profesionales) y KVM/QEMU (nativo en Linux, el más potente para laboratorios avanzados).

VirtualBox

VirtualBox es el hypervisor de referencia para empezar. Gratuito, de código abierto (mantenido por Oracle), disponible en Windows, Linux y macOS. La configuración de red se hace desde la GUI o desde VBoxManage por línea de comandos.

Desde la GUI:

Selecciona la VM → Configuración → Red
Cada VM tiene hasta 4 adaptadores de red (Adaptador 1, 2, 3, 4)
En cada adaptador: marcar "Habilitar adaptador de red" y seleccionar el modo en el desplegable "Conectado a"
Para Host-Only: primero crear la red en Archivo → Administrador de red de anfitrión

Desde VBoxManage (línea de comandos):

bash — VirtualBox CLI

# Listar todas las VMs registradas
VBoxManage list vms

# Ver configuración de red de una VM
VBoxManage showvminfo "NombreVM" | grep "NIC"

# Configurar adaptador 1 en modo NAT
VBoxManage modifyvm "NombreVM" --nic1 nat

# Configurar adaptador 1 en modo Bridge (especificar interfaz física)
VBoxManage modifyvm "NombreVM" --nic1 bridged --bridgeadapter1 eth0

# Configurar adaptador 2 en modo Host-Only
VBoxManage modifyvm "NombreVM" --nic2 hostonly --hostonlyadapter2 vboxnet0

# Configurar adaptador en modo Internal Network (nombre personalizable)
VBoxManage modifyvm "NombreVM" --nic1 intnet --intnet1 "laboratorio-malware"

# Crear una red Host-Only nueva con DHCP
VBoxManage hostonlyif create
VBoxManage hostonlyif ipconfig vboxnet0 --ip 192.168.56.1 --netmask 255.255.255.0
VBoxManage dhcpserver add --ifname vboxnet0 --ip 192.168.56.100 \
    --netmask 255.255.255.0 --lowerip 192.168.56.101 \
    --upperip 192.168.56.254 --enable

# Port forwarding en NAT (acceder a puerto 22 de la VM desde el anfitrión)
VBoxManage modifyvm "NombreVM" --natpf1 "ssh,tcp,,2222,,22"
# Ahora puedes: ssh -p 2222 usuario@127.0.0.1

Topología recomendada para laboratorio básico en VirtualBox:

topología — laboratorio básico VirtualBox

## VM ATACANTE (Kali Linux)
Adaptador 1: NAT          # Internet para actualizar herramientas
Adaptador 2: Host-Only     # Red del laboratorio (vboxnet0: 192.168.56.0/24)

## VMs OBJETIVO (Metasploitable, DVWA, máquinas CTF)
Adaptador 1: Host-Only     # Solo accesibles desde la red del laboratorio
# Sin acceso a internet — no pueden exfiltrar ni actualizarse

## RESULTADO:
# Kali puede atacar las VMs objetivo ✅
# Kali puede actualizar herramientas desde internet ✅
# Las VMs objetivo no pueden salir a internet ✅
# Las VMs objetivo no son accesibles desde tu red física ✅

VMware Workstation / Fusion

VMware tiene su propio sistema de redes virtuales gestionado por el Virtual Network Editor (vmnetcfg). Los nombres de los modos son distintos pero el comportamiento es equivalente:

VirtualBox	VMware equivalente	Nombre en VMware
NAT	NAT	vmnet8 (por defecto)
Bridge	Bridged	vmnet0 (por defecto)
Host-Only	Host-Only	vmnet1 (por defecto)
Internal Network	LAN Segment / vmnetX personalizada	vmnet2-vmnet19 (configurables)

Desde la GUI de VMware Workstation:

Selecciona la VM → VM → Settings → Network Adapter
Elegir el modo en "Network connection"
Para redes personalizadas: Edit → Virtual Network Editor → Add Network
Para múltiples adaptadores: Add → Network Adapter en el panel de Settings

Desde vmrun y vmnetcfg (CLI):

bash — VMware CLI (Linux)

# Ver interfaces de red virtuales de VMware
ip addr show | grep vmnet

# Configurar red NAT (vmnet8) — editar /etc/vmware/vmnet8/nat/nat.conf
# Rango DHCP de vmnet8 por defecto: 192.168.172.0/24

# Reiniciar los servicios de red de VMware
sudo vmware-networks --stop
sudo vmware-networks --start

# En VMware Fusion (macOS) — las interfaces son vmnet1, vmnet8
sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cfgcli -h

# Ver el estado de las redes virtuales
sudo /Applications/VMware\ Fusion.app/Contents/Library/vmnet-cli --status

LAN Segments en VMware (equivalente a Internal Network):

VMware permite crear "LAN Segments" — redes privadas aisladas donde solo las VMs asignadas a ese segmento pueden comunicarse entre sí, sin acceso al anfitrión ni al exterior. Se configuran desde VM → Settings → Network Adapter → LAN Segment → Manage LAN Segments.

💡

VMware vs VirtualBox para laboratorios avanzados: VMware tiene mejor rendimiento en entornos con muchas VMs activas simultáneamente y mejor soporte para anidamiento de virtualización (nested virtualization), necesario para algunos laboratorios de cloud o de Kubernetes. VirtualBox es suficiente para la mayoría de laboratorios de pentesting individual.

KVM / QEMU + libvirt

KVM (Kernel-based Virtual Machine) es el hypervisor nativo del kernel de Linux. No es una aplicación separada — es un módulo del kernel que convierte Linux en un hypervisor de tipo 1. QEMU proporciona la emulación de hardware y libvirt es la capa de gestión que permite controlarlo con herramientas como virsh, virt-manager o cockpit.

KVM es más complejo de configurar que VirtualBox o VMware, pero ofrece mejor rendimiento, mayor flexibilidad de red y es la base de los entornos cloud (AWS, GCP y Azure usan KVM internamente).

Tipos de red en KVM/libvirt:

Tipo KVM	Equivalente VirtualBox	Descripción
NAT (virbr0)	NAT	Red NAT por defecto. Las VMs salen a internet pero no son visibles desde fuera.
Bridge (br0)	Bridge	La VM conecta a la red física del anfitrión. Requiere crear un bridge en el anfitrión.
Isolated network	Internal Network	Red aislada sin acceso al exterior. Solo las VMs en esa red se ven entre sí.
macvtap	Bridge (avanzado)	La VM tiene su propia MAC en la red física. Mejor rendimiento que bridge tradicional.

Gestión de redes con virsh:

bash — KVM / virsh

# Ver redes virtuales disponibles
virsh net-list --all

# Ver detalles de la red por defecto (NAT)
virsh net-info default

# Ver la configuración XML de la red por defecto
virsh net-dumpxml default

# Crear una red aislada (isolated) desde un XML
cat > /tmp/red-laboratorio.xml << EOF
<network>
  <name>laboratorio</name>
  <ip address="192.168.100.1" netmask="255.255.255.0">
    <dhcp>
      <range start="192.168.100.10" end="192.168.100.50"/>
    </dhcp>
  </ip>
</network>
EOF

# Definir, iniciar y activar al arranque la red
virsh net-define /tmp/red-laboratorio.xml
virsh net-start laboratorio
virsh net-autostart laboratorio

# Conectar una VM existente a la nueva red
virsh attach-interface --domain NombreVM --type network \
    --source laboratorio --model virtio --config --live

# Ver interfaces de red de una VM
virsh domiflist NombreVM

# Crear bridge físico en el anfitrión (para modo Bridge)
# En sistemas con NetworkManager:
nmcli connection add type bridge con-name br0 ifname br0
nmcli connection add type bridge-slave ifname eth0 master br0
nmcli connection up br0

Creación de red aislada con virt-manager (GUI):

Abrir virt-manager → Edit → Connection Details → Virtual Networks
Click en + para crear nueva red
Asignar nombre, rango IP y seleccionar "Isolated virtual network" (sin reenvío a ninguna interfaz física)
En cada VM: Open → View → Details → NIC → cambiar la red

Topologías de laboratorio recomendadas

Según el tipo de laboratorio que quieras montar, hay topologías estándar que funcionan bien en cualquiera de los tres hypervisores:

topologías de laboratorio

## TOPOLOGÍA 1: Pentesting básico (una máquina atacante + objetivos)
Kali Linux:
  - Adaptador 1: NAT          # Internet
  - Adaptador 2: Host-Only    # Red del laboratorio (192.168.56.0/24)
Metasploitable / DVWA / CTF:
  - Adaptador 1: Host-Only    # Solo accesibles desde la red del lab

## TOPOLOGÍA 2: Laboratorio de Active Directory
Windows Server (DC):
  - Adaptador 1: Host-Only    # Red interna del lab (192.168.100.0/24)
Windows 10/11 (clientes):
  - Adaptador 1: Host-Only    # Misma red que el DC
Kali Linux (atacante):
  - Adaptador 1: NAT          # Internet
  - Adaptador 2: Host-Only    # Acceso a la red del AD

## TOPOLOGÍA 3: Análisis de malware (máximo aislamiento)
VM de análisis (Windows con malware):
  - Adaptador 1: Internal     # Red interna aislada (sin internet, sin anfitrión)
VM de soporte (FakeNet / INetSim):
  - Adaptador 1: Internal     # Misma red interna — simula internet para el malware
# El malware cree que tiene internet pero solo ve la VM de soporte

## TOPOLOGÍA 4: Red corporativa simulada (pivoting)
Kali (atacante externo):
  - Adaptador 1: NAT          # "Internet"
  - Adaptador 2: Host-Only    # Red DMZ (192.168.10.0/24)
VM servidor web (DMZ):
  - Adaptador 1: Host-Only    # Red DMZ
  - Adaptador 2: Internal     # Red interna corporativa (10.10.10.0/24)
VMs red interna (DC, file server):
  - Adaptador 1: Internal     # Solo accesibles desde la red interna
# Kali no puede ver directamente la red interna — debe pivotar por el servidor web

💡

La topología 4 es clave para aprender pivoting: Simula un escenario realista donde comprometes un servidor DMZ y desde ahí necesitas moverte a la red interna. Los módulos 13 (Pivoting y túneles) y 17 (Active Directory) usan este tipo de topología. Monta esta red desde el principio aunque no la uses todavía — tener el laboratorio listo cuando llegues a esos temas ahorra mucho tiempo.

Verificar el aislamiento: no asumas, comprueba

Una vez configurada la red del laboratorio, verifica que el aislamiento funciona como esperas. No des por hecho que la configuración es correcta — compruébalo activamente.

bash — verificación de aislamiento

# Desde la VM objetivo (debe estar aislada): verificar que NO tiene internet
ping -c 3 8.8.8.8          # Debe fallar si está en Host-Only / Internal
curl -s https://icanhazip.com  # Debe fallar

# Desde la VM objetivo: verificar que puede ver a la VM atacante
ping -c 3 192.168.56.10   # IP de Kali en la red del laboratorio — debe funcionar

# Desde la VM atacante (Kali): verificar que tiene internet
ping -c 3 8.8.8.8          # Debe funcionar (por NAT)

# Desde la VM atacante: verificar que ve los objetivos
nmap -sn 192.168.56.0/24  # Debe mostrar las VMs objetivo

# Verificar que la VM objetivo NO es accesible desde la red física
# (ejecutar desde otro equipo de tu red doméstica)
nmap -sn 192.168.56.0/24  # No debe mostrar nada

# Ver tabla de rutas de una VM (entender qué tráfico va a dónde)
ip route show
# o en sistemas Windows dentro de la VM:
# route print

⚠️

IPv6 puede romper el aislamiento: Si tienes IPv6 activo en el anfitrión y en las VMs, el tráfico IPv6 puede eludir las restricciones de red configuradas para IPv4. Verifica que IPv6 está desactivado en las VMs de laboratorio que deben estar aisladas, o asegúrate de que las reglas de firewall cubren ambos protocolos.