// PROYECTO: Malware Sandbox Setup
// OS: REMnux
// ESTADO: Network Operational
REMnux es una distribución endurecida ("hardened") diseñada específicamente para el análisis de malware.
Por seguridad, suele venir con configuraciones de red muy restrictivas para evitar que una muestra maliciosa se comunique con el exterior sin nuestro control explícito.
En mi última sesión de laboratorio, tuve que lidiar con varios bloqueos de red que documento a continuación.
0x01 El Problema del Estado "Unmanaged"
Al intentar gestionar la red, nmcli mostraba mi interfaz principal (ens33) como unmanaged.
La causa es un conflicto de jerarquía típico en sistemas basados en Debian, y es que si una interfaz aparece en el archivo antiguo /etc/network/interfaces, el gestor moderno (NetworkManager) la ignora por seguridad para evitar duplicidades.
Liberación:
- Limpiar el archivo de interfaces (dejar solo loopback):
- sudo bash -c 'echo -e "auto lo\niface lo inet loopback" > /etc/network/interfaces'
- Habilitar la gestión en
/etc/NetworkManager/NetworkManager.confcambiandomanaged=falsea true. - Reiniciar el demonio:
- sudo systemctl restart NetworkManager
0x02 Configuración de IP Estática (Manual Mode)
En mi Sandbox, cuando el DHCP no responde (DHCPDISCOVER), prefiero forzar una IP estática.
Esto me otorga un control total sobre el tráfico que sale hacia mi pasarela de análisis.
# 1. Limpiar configuración residual sudo ip addr flush dev ens332. Asignar IP y Máscara (Red de Lab)
sudo ip addr add 10.10.10.6/24 dev ens33
3. Levantar la interfaz
sudo ip link set ens33 up
0x03. Resolución del Conflicto de Rutas
Un error común al añadir la puerta de enlace es el mensaje RTNETLINK answers: File exists.
Esto sucede cuando intentamos añadir una ruta por defecto existiendo ya otra (posiblemente hacia la .2).
En mi caso, el gateway de VMware estaba en la .1 y Linux solo permite una puerta de enlace principal.
# Borrar ruta predeterminada incorrecta sudo ip route del defaultAñadir ruta correcta hacia mi router virtual (.1)
sudo ip route add default via 10.10.10.1
0x04. Resolución de Nombres (DNS)
Incluso con IP y Gateway, sin DNS no hay navegación por nombres. En REMnux, el archivo de resolución a veces se bloquea. Lo fuerzo manualmente:
sudo bash -c 'echo "nameserver 8.8.8.8" > /etc/resolv.conf'
0x05. Verificación en el Host (VMware Workstation)
Si la VM está perfecta pero sigo sin salida, el problema reside en el "Router Virtual" de VMware en mi máquina Windows.
Verifico siempre estos tres puntos en el Virtual Network Editor:
- Subnet IP: Debe ser 10.10.10.0 con máscara 255.255.255.0.
- NAT Settings: El Gateway IP debe coincidir exactamente con el configurado en la VM (10.10.10.1).
- Servicios de Windows:
VMware NAT Servicedebe estar en estado "Running".
ip a(¿Tengo IP?)ip route show(¿A dónde apunto?)ping 10.10.10.1(¿Llego al router?)ping 8.8.8.8(¿Tengo salida externa?)
0x06. Siguiente fase: Análisis con CAPA
Con el laboratorio blindado y con conexión, toca pasar a la ciberseguridad ofensiva.
He descargado el binario dedsec_wi-fidar y antes de ejecutarlo en mi entorno controlado, utilizo capa para diseccionar sus capacidades y entender qué intenta hacer el ejecutable.
capa ./dedsec_wi-fidar
"Security is not a product, it's a mindset."
[ EOF ]