1) Documentación de todos los comandos que ejecutaste (qué hacen y por qué)
git clone https://github.com/0xbitx/DEDSEC_WI-FIDAR.git
Para qué sirve: descarga el repositorio completo a tu máquina.
Por qué: necesitas el binario y el README.
Tu primer error asociado:
fatal: no se pudo crear un árbol de trabajo … Permiso denegado
Esto te pasó porque estabas en /home (directorio que normalmente solo root administra). En Linux, un usuario normal no debería escribir en /home como raíz del sistema.
comando:: sudo git clone …
Para qué: clonar como root cuando no tienes permisos de escritura.
Por qué funcionó: root sí puede escribir en /home.
Problema colateral: el repo queda con propietario root, y luego tu usuario no puede crear/modificar archivos dentro (como .venv). Por eso viste errores de permisos al intentar crear el entorno virtual.
comando:: sudo pip install scapy, tabulate, pandas, matplotlib, pyudev, psutil
Para qué (intención): instalar dependencias Python globalmente.
Qué pasó realmente (dos problemas):
Comas: pip no espera comas. Lo correcto sería pip install scapy tabulate … Con comas, pip interpreta nombres raros.
PEP 668 / externally-managed-environment: Kali (y Debian modernos) bloquean pip a nivel de sistema para no romper el Python del OS (evitar que pip pise paquetes que gestiona apt).
Por eso te devuelve:
error: externally-managed-environment
y te sugiere usar apt, venv o pipx.
Por qué: el Python del sistema es “externally managed” por el gestor de paquetes (APT). Mezclar pip global con APT puede romper dependencias de herramientas del sistema.
comando:: sudo apt update
Para qué: refrescar índices de paquetes disponibles.
Por qué: necesario antes de instalar paquetes nuevos o actualizar versiones.
comando:: sudo apt install -y python3-pip python3-venv python3-dev
Para qué:
python3-pip: instala el gestor de paquetes pip (para Python).
python3-venv: permite crear entornos virtuales (python -m venv).
python3-dev: headers y herramientas para compilar dependencias Python con extensiones nativas (algunas librerías lo necesitan).
Por qué: intentabas tener un entorno Python funcional para instalar dependencias.
python3 -m venv .venv
Para qué: crear un entorno virtual aislado para instalar paquetes con pip sin tocar el sistema.
Por qué es lo correcto en Kali: evita el bloqueo PEP668 y mantiene limpio el Python del sistema.
Tu error:
Permission denied: ‘/home/DEDSEC_WI-FIDAR/.venv’
Esto ocurrió porque el repo lo clonaste con sudo y quedó propiedad de root, así que tu usuario no podía crear .venv dentro.
source .venv/bin/activate
Para qué: activar el entorno virtual en la shell (para que python y pip apunten al .venv).
Por qué te falló: como .venv no se creó, no existía activate.
comando:: sudo python3 -m venv .venv
Para qué: crear el venv como root para saltarte permisos.
Por qué no es recomendable: te deja un .venv propiedad de root, y luego vuelves a tener líos de permisos (y además mezclas ejecución/instalación con root).
chmod +x dedsec_wi-fidar
Para qué: marcar el fichero como ejecutable (x) para poder lanzarlo como ./dedsec_wi-fidar.
Por qué no te funcionó al principio:
Aunque ls -l te enseñaba -rwx…, getfacl mostraba que realmente tenías permisos efectivos sin x (por ACL). El sistema decide permisos efectivos según ACL si están presentes.
comando:: sudo .venv/bin/python3 ./dedsec_wi-fidar
Para qué (tu intención): ejecutar el programa usando el Python del venv.
Por qué falló: porque dedsec_wi-fidar no es Python, es binario EL
Qué ocurre con este binario (dedsec_wi-fidar) y por qué te pasó todo esto
El archivo dedsec_wi-fidar no es un script Python, es un ejecutable binario (formato ELF en Linux). Por eso, cuando intentaste lanzarlo con python3, Python lo leyó como si fuera un fichero de texto y falló.
Además, aunque el binario llegó a ejecutarse “correctamente” en algún momento, lo que hemos visto en tus salidas indica que:
El binario tiene un encabezado ELF anómalo/corrupto (class = 0xFF, data = 0xFF, tamaños imposibles como 65535).
No hay código fuente en el repo (find no encontró .py ni .sh), así que solo podemos tratarlo como un “blob” binario.
Te exigía root (“you must be root…”), lo que sugiere que intenta tocar interfaz WiFi, modo monitor, netlink, o ejecutar herramientas que requieren privilegios.
Esto no significa automáticamente “malware”, pero sí significa: no es auditable y no sigue las convenciones normales de un binario Linux.
1) Documentación de todos los comandos que ejecutaste (qué hacen y por qué)
git clone https://github.com/0xbitx/DEDSEC_WI-FIDAR.git
Para qué sirve: descarga el repositorio completo a tu máquina.
Por qué: necesitas el binario y el README.
Tu primer error asociado:
fatal: no se pudo crear un árbol de trabajo … Permiso denegado
Esto te pasó porque estabas en /home (directorio que normalmente solo root administra). En Linux, un usuario normal no debería escribir en /home como raíz del sistema.
comando:: sudo git clone …
Para qué: clonar como root cuando no tienes permisos de escritura.
Por qué funcionó: root sí puede escribir en /home.
Problema colateral: el repo queda con propietario root, y luego tu usuario no puede crear/modificar archivos dentro (como .venv). Por eso viste errores de permisos al intentar crear el entorno virtual.
comando:: sudo pip install scapy, tabulate, pandas, matplotlib, pyudev, psutil
Para qué (intención): instalar dependencias Python globalmente.
Qué pasó realmente (dos problemas):
Comas: pip no espera comas. Lo correcto sería pip install scapy tabulate … Con comas, pip interpreta nombres raros.
PEP 668 / externally-managed-environment: Kali (y Debian modernos) bloquean pip a nivel de sistema para no romper el Python del OS (evitar que pip pise paquetes que gestiona apt).
Por eso te devuelve:
error: externally-managed-environment
y te sugiere usar apt, venv o pipx.
Por qué: el Python del sistema es “externally managed” por el gestor de paquetes (APT). Mezclar pip global con APT puede romper dependencias de herramientas del sistema.
comando:: sudo apt update
Para qué: refrescar índices de paquetes disponibles.
Por qué: necesario antes de instalar paquetes nuevos o actualizar versiones.
comando:: sudo apt install -y python3-pip python3-venv python3-dev
Para qué:
python3-pip: instala el gestor de paquetes pip (para Python).
python3-venv: permite crear entornos virtuales (python -m venv).
python3-dev: headers y herramientas para compilar dependencias Python con extensiones nativas (algunas librerías lo necesitan).
Por qué: intentabas tener un entorno Python funcional para instalar dependencias.
python3 -m venv .venv
Para qué: crear un entorno virtual aislado para instalar paquetes con pip sin tocar el sistema.
Por qué es lo correcto en Kali: evita el bloqueo PEP668 y mantiene limpio el Python del sistema.
Tu error:
Permission denied: ‘/home/DEDSEC_WI-FIDAR/.venv’
Esto ocurrió porque el repo lo clonaste con sudo y quedó propiedad de root, así que tu usuario no podía crear .venv dentro.
source .venv/bin/activate
Para qué: activar el entorno virtual en la shell (para que python y pip apunten al .venv).
Por qué te falló: como .venv no se creó, no existía activate.
comando:: sudo python3 -m venv .venv
Para qué: crear el venv como root para saltarte permisos.
Por qué no es recomendable: te deja un .venv propiedad de root, y luego vuelves a tener líos de permisos (y además mezclas ejecución/instalación con root).
chmod +x dedsec_wi-fidar
Para qué: marcar el fichero como ejecutable (x) para poder lanzarlo como ./dedsec_wi-fidar.
Por qué no te funcionó al principio:
Aunque ls -l te enseñaba -rwx…, getfacl mostraba que realmente tenías permisos efectivos sin x (por ACL). El sistema decide permisos efectivos según ACL si están presentes.
comando:: sudo .venv/bin/python3 ./dedsec_wi-fidar
Para qué (tu intención): ejecutar el programa usando el Python del venv.
Por qué falló: porque dedsec_wi-fidar no es Python, es binario ELF. Python lo interpreta como texto ⇒ error:
SyntaxError: Non-UTF-8 code starting with ‘\xff’ …
Ese \xff es literalmente un byte del binario, no texto.
file -b dedsec_wi-fidar
Para qué: identificar el tipo real de fichero.
Resultado: ELF (embedded), unknown class 255
Interpretación: es un ELF, pero con un encabezado que no cuadra con un ELF normal.
xxd -l 32 dedsec_wi-fidar
Para qué: ver los primeros bytes (header).
Por qué: confirmar si es ELF (7f 45 4c 46) y ver la clase (01/02).
Lo que viste:
empieza por .ELF (correcto)
pero seguido por ff ff ff ff donde deberían ir valores válidos.
readelf -h dedsec_wi-fidar
Para qué: parsear el header ELF y mostrar arquitectura/entrypoint/secciones.
Qué te dijo:
“probablemente corrupto”
clase/datos/version/ABI desconocidos
headers con tamaños absurdos
0 program headers
Por qué esto importa: muchas herramientas (loader, depuradores, análisis) esperan un ELF estándar. Un header raro puede implicar:
binario packed / ofuscado,
binario manipulado,
o directamente roto.
strings -n 8 dedsec_wi-fidar | head
Para qué: extraer cadenas ASCII/UTF-8 visibles del binario.
Resultado: casi todo basura, sin mensajes claros.
Interpretación: o está muy ofuscado/compactado, o no contiene cadenas legibles.
ldd ./dedsec_wi-fidar
Para qué: listar librerías dinámicas requeridas.
Resultado: “no es un ejecutable dinámico”
Interpretación: podría ser estático o no interpretable como ELF dinámico normal (con ese header raro, esto encaja).
./dedsec_wi-fidar → permiso denegado
Por qué pasó: porque ACL estaba quitando el permiso de ejecución aunque tú pensabas que lo tenía.
comando:: lsattr dedsec_wi-fidar
Para qué: ver atributos extendidos de filesystem (immutable, append-only, etc.).
Tu salida: e (extents) → normal en ext4, no es un bloqueo.
getfacl dedsec_wi-fidar
Para qué: ver ACL reales (más fiable que solo ls -l cuando hay ACL).
Aquí viste la causa real: no había x.
comando:: sudo setfacl -b dedsec_wi-fidar
Para qué: borrar ACL y volver a permisos POSIX normales.
Por qué: para que chmod sea “lo que manda”.
chmod 755 dedsec_wi-fidar y getfacl dedsec_wi-fidar
Para qué: dejarlo ejecutable y verificable.
Por qué: ya quedó ejecutable (rwxr-xr-x).
2) ¿Qué “es” este binario entonces? (hipótesis razonables)
Con lo que has mostrado, lo más probable es una de estas:
Binario empaquetado/ofuscado (packer custom / formato “embedded”)
Esto explicaría:
strings casi vacío
readelf raro
file “embedded”
Binario corrupto pero que en tu entorno “parece ejecutar”
A veces la ejecución llega a arrancar si el loader tolera algo o si es en realidad un stub que luego hace otra cosa.
Artefacto subido incorrectamente al repo
Un binario mal generado o truncado también produce headers absurdos.
Como no hay código fuente, no podemos verificar intenciones ni seguridad.
3) Por qué te pedía root (“you must be root…”)
Casi seguro porque necesita alguna de estas capacidades:
poner interfaz WiFi en modo monitor / cambiar canales,
acceder a netlink / ioctl de red,
leer información de dispositivos (udev),
o ejecutar herramientas que requieren privilegios.
Nota: pedir root no es “prueba de maldad”, pero combinado con binario opaco sí es riesgo.
4) Qué haría “bien” si el objetivo es WiFi “radar” (defensivo/monitorización)
Si tu objetivo es ver redes cercanas, RSSI, cambios, etc., lo correcto es usar herramientas mantenidas y auditables (Kali ya trae o empaqueta):
kismet para detección + logging + UI
wavemon para monitorización simple
aircrack-ng/airodump-ng para enumeración en monitor
Si me dices qué quieres exactamente (p.ej. “listar APs con RSSI en tiempo real y guardar CSV”), te doy un setup limpio con una de estas.
Si quieres que lo “documente” todavía más
Puedo ayudarte a crear un informe tipo:
cadena de eventos,
causa raíz de cada error,
corrección aplicada,
riesgos y recomendación final.
Para completarlo, solo me falta: ¿en qué momento dices que “lo ejecutaste correctamente” y qué salida te dio? (copia/pega esa salida o cuéntame qué hacía).
1) Revisión del repositorio (GitHub)
Repositorio: 0xbitx/DEDSEC_WI-FIDAR
Contenido observado en el repo (según la página de GitHub):
LICENSE
README.md
dedsec_wi-fidar (único “artefacto” ejecutable)
No hay ficheros fuente .py, .c, .cpp, .sh ni releases publicados.
Lo que promete el README:
“Linux-based Wi‑Fi mapping tool… escanea redes Wi‑Fi y estima distancia”.
Instalación recomendada (en el propio README):
comando:: sudo pip install scapy, tabulate, pandas, matplotlib, pyudev, psutil
chmod +x dedsec_wi-fidar
comando:: sudo ./dedsec_wi-fidar
Probado en Kali/Parrot/Ubuntu.
Incluye “DISCLAIMER” y dirección BTC para donaciones.
Observación crítica de cadena de suministro (supply chain):
Distribuye únicamente un binario sin código fuente verificable ni releases firmados.
Pide ejecución como root.
Recomienda sudo pip install … (mala práctica en Debian/Kali por PEP 668 y por riesgo de romper el Python del sistema).
2) Evidencias técnicas del binario en tu sistema (lo que sabemos ya)
A partir de tus comandos y salidas:
2.1 Identificación como ELF no estándar / posiblemente corrupto
file dedsec_wi-fidar:
ELF (embedded), unknown class 255
readelf -h dedsec_wi-fidar:
Clase: <desconocido: ff>
Datos: <desconocido: ff>
Version: 255 <unknown>
Size of this header: 65535
Number of program headers: 0
Aviso explícito: “encabezado … probablemente corrupto”.
Interpretación:
Un ELF “normal” tiene EI_CLASS = 01 (32-bit) o 02 (64-bit) y EI_DATA = 01/02.
Valores FF y tamaños como 65535 son anómalos.
Esto puede indicar:
binario “packed/ofuscado” con loader propio o anti-análisis,
binario manipulado para romper herramientas,
binario corrupto/truncado.
2.2 Señales de compresión/packing
En strings aparecen referencias como:
ZLIB_1.2.0
Interpretación:
Muchos “packers” o stubs usan zlib para cargar/descomprimir payload en runtime.
No prueba malicia por sí solo, pero sí sugiere “contenedor”/payload interno.
2.3 Ausencia de indicadores funcionales legibles
strings muestra mayormente texto “basura” con pocas cadenas interpretables.
Esto es consistente con: ofuscación/packing o binario no convencional.
3) Sospechas razonables (y por qué)
Nota: “sospecha” ≠ “prueba”. Sin fuente ni ejecución instrumentada no puede afirmarse intención maliciosa.
Sospecha A: riesgo elevado de supply chain / binario no auditable
Por qué:
El repo solo contiene un binario, sin fuente, sin pipeline de build, sin reproducibilidad.
No hay “Releases” publicados ni firmas/hash oficiales por versión.
Pide root.
Riesgo:
No se puede revisar qué hace realmente.
Puede contener funcionalidad adicional no documentada (telemetría, backdoor, etc.) o simplemente estar mal construido.
Sospecha B: binario ofuscado o anti-análisis
Por qué:
Header ELF anómalo.
Pocas cadenas legibles.
Indicios de zlib.
Riesgo:
Dificulta análisis por herramientas estándar (readelf, objdump, ldd), típico en binarios “packed”.
Puede esconder payload que se desempaqueta en memoria.
Sospecha C: en el mejor caso, herramienta “gris” que requiere root y toca WiFi
Por qué:
La funcionalidad declarada (“Wi‑Fi mapping”) suele requerir:
acceso a netlink / ioctl,
modo monitor,
lectura de RSSI/frames,
escaneo de interfaces.
Eso suele implicar privilegios (root o capabilities).
Riesgo operativo:
Puede interferir con conectividad WiFi, cambiar modo/canal, desasociar, etc.
En una VM con red en bridge: expone tu LAN doméstica.
4) Cómo analizarlo de forma segura (sandbox + estático)
4.1 Preparación de sandbox (recomendado)
Objetivo: reducir impacto si el binario es malicioso o intrusivo.
Checklist mínimo antes de ejecutar:
Snapshot de la VM (imprescindible).
Cambiar la red:
Mejor: sin red (primeras pruebas).
Alternativa: NAT (evita exposición directa a tu LAN).
Evitar: bridge (es el modo más arriesgado).
Usuario:
No ejecutar como root salvo que sea estrictamente necesario.
Si exige root, asumir riesgo y aumentar instrumentación.
Registrar baseline:
procesos, conexiones, ficheros modificados.
Por qué: si el binario intenta escanear LAN, exfiltrar o pivotar, el bridge lo facilita; NAT/sin red limita mucho el daño.
5) Análisis estático (sin ejecutar)
5.1 Identidad y huella del artefacto
Comandos:
bash
Copy
sha256sum dedsec_wi-fidar
stat dedsec_wi-fidar
file dedsec_wi-fidar
Para qué sirven:
sha256sum: hash para identificar de forma única el binario (útil para comparar con otros análisis, VirusTotal, etc.).
stat: tamaño, fechas, permisos.
file: tipo general (aunque aquí devuelve “embedded/unknown class”).
5.2 Inspección de cabecera y estructura
bash
Copy
xxd -l 64 dedsec_wi-fidar
readelf -h dedsec_wi-fidar
Para qué:
xxd: ver bytes iniciales (mágico ELF, clase, endianness).
readelf -h: arquitectura declarada, entrypoint, offsets.
Qué buscar:
EI_CLASS y EI_DATA válidos.
Presencia de Program Headers (PT_LOAD) en binarios normales.
5.3 Búsqueda de strings indicativas (IOCs/funcionalidad)
bash
Copy
strings -n 6 dedsec_wi-fidar | head -n 200
strings -n 6 dedsec_wi-fidar | grep -Ei ‘http|https|\.onion|dns|socket|curl|wget|ssh|scp|nc|bash’ | head
strings -n 6 dedsec_wi-fidar | grep -Ei ‘iw|ip |ifconfig|rfkill|nmcli|wpa|airmon|airodump|kismet|tcpdump’ | head
Para qué:
Encontrar URLs, dominios, comandos ejecutados, herramientas invocadas, librerías, rutas /etc, /proc, /sys, etc.
En herramientas “WiFi”, sería razonable ver iw, ip, rfkill, etc. Si no aparece nada, aumenta sospecha.
5.4 Detección de packers (básico)
bash
Copy
grep -aobU “UPX!” dedsec_wi-fidar | head
Para qué:
Detectar UPX (packer común). Si hay UPX, normalmente se puede desempaquetar y analizar mejor (aunque no siempre).
6) Análisis dinámico (sandbox) con instrumentación
6.1 Registrar llamadas al sistema (strace)
Instalación:
bash
Copy
comando:: sudo apt update
comando:: sudo apt install -y strace
Ejecución instrumentada:
bash
Copy
comando:: sudo strace -f -o /tmp/wifidar.strace ./dedsec_wi-fidar
Filtrado de señales de comportamiento:
bash
Copy
grep -E ‘execve\(|openat\(|connect\(|sendto\(|recvfrom\(|socket\(’ /tmp/wifidar.strace | head -n 200
Para qué sirve:
strace registra qué hace el programa realmente: ficheros que abre, sockets que crea, hosts a los que conecta, comandos que ejecuta.
Qué buscar:
execve() de utilidades del sistema (iw, ip, bash, etc.).
connect() a IPs externas (salida a Internet).
Acceso a rutas sensibles (/etc/shadow, ~/.ssh, /proc, /sys, etc.).
6.2 Monitorización de red (en NAT o red controlada)
Sin entrar en instrucciones ofensivas, el enfoque defensivo es:
observar si intenta resolver DNS, abrir conexiones, hacer broadcast, etc.
Herramientas típicas:
ss -tpn (conexiones)
ip a, ip r (interfaces/rutas)
6.3 Monitorización de cambios en el filesystem
En un directorio controlado:
capturar estado antes/después (lista de ficheros, timestamps).
revisar si crea persistencia (cron, systemd, etc.).
7) Recomendación final (para el doc)
No ejecutar en una VM con red en bridge hacia tu red doméstica.
Considerar el binario como no confiable por ausencia de fuente + header ELF anómalo + petición de root.
Si se necesita funcionalidad “WiFi mapping/monitorización”, usar herramientas mantenidas y auditables en Kali (p.ej., kismet, iw, etc.) en lugar de un binario opaco.
1. Eliminación del Repositorio y Entorno Virtual
Dado que clonaste el repositorio directamente en /home (un lugar poco habitual para un usuario normal) y con sudo, ejecuta lo siguiente:
Bash
# Entra en el directorio superior donde está la carpeta
cd /home
# Borra la carpeta del repositorio y todo su contenido (incluido el .venv oculto)
comando:: sudo rm -rf DEDSEC_WI-FIDAR
2. Limpieza de posibles residuos de Python
Aunque el bloqueo de PEP 668 probablemente evitó que se instalaran librerías a nivel de sistema, es buena práctica verificar que no haya “basura” en la caché de pip o paquetes mal instalados:
Bash
# Limpia la caché de pip para evitar conflictos de versiones en el futuro
comando:: sudo pip cache purge
# Opcional: Verifica que no haya paquetes extraños instalados globalmente
pip list | grep -E “scapy|tabulate|pandas|matplotlib|pyudev|psutil”
Si el último comando no devuelve nada, tu Python del sistema está limpio.
3. Limpieza de historial (Higiene de Seguridad)
Como administrador, querrás que tu historial de comandos no guarde registros de ejecuciones fallidas de binarios potencialmente maliciosos:
Bash
history -c && history -w
Próximo Paso: Preparando el Sandbox
Para cuando vayas a instalarlo de nuevo en tu entorno aislado, te sugiero esta metodología de despliegue seguro:
A. Aislamiento de Red
Antes de ejecutar el binario en el sandbox, configura la tarjeta de red de la VM en modo “Host-only” o desconéctala por completo. Si el binario es un troyano que intenta conectar con un C2 (Command & Control), lo dejarás “mudo”.
B. Análisis de Ejecución (Strace)
En lugar de lanzarlo directamente, “envuélvelo” en un trazador de llamadas al sistema. Esto te permitirá ver qué archivos intenta leer o a qué IPs intenta conectar en tiempo real:
Bash
# Instala strace en tu sandbox
comando:: sudo apt install strace -y
# Ejecuta el binario monitorizando archivos y red
comando:: sudo strace -e trace=openat,connect ./dedsec_wi-fidar
¿Te gustaría que te ayude a preparar un script de monitorización simple para tu sandbox que detecte si este programa intenta crear archivos de persistencia o modificar el /etc/shadow?
REMNUX LABORATORIO
Guía Técnica: Configuración de Red en REMnux (Troubleshooting)
Contexto Inicial
REMnux es una distribución “hardened” (endurecida). Por seguridad, suele venir con configuraciones de red restrictivas para evitar que el malware se comunique con el exterior sin control.
1. El Problema del Estado “Unmanaged”
Síntoma: nmcli muestra la interfaz (ens33) como unmanaged. Causa: Conflicto de jerarquía. En sistemas basados en Debian, si una interfaz está mencionada en el archivo antiguo /etc/network/interfaces, el gestor moderno (NetworkManager) la ignora por seguridad para no duplicar configuraciones.
Solución Documentada:
Limpiar el archivo de interfaces: Dejarlo solo con el loopback.
Bash
comando:: sudo bash -c ‘echo -e “auto lo\niface lo inet loopback” >
/etc/network/interfaces’
-
Habilitar la gestión en NetworkManager: Editar /etc/NetworkManager/NetworkManager.conf y cambiar managed=false a true.
*Reiniciar el servicio:*
Bash
comando:: sudo systemctl restart NetworkManager
2. Configuración de IP Estática (Modo Manual)
Cuando el DHCP no responde (se queda en DHCPDISCOVER), la mejor práctica en un laboratorio de ciberseguridad es forzar una IP estática para tener control total del tráfico.
Comandos de Configuración:
Bash
# 1. Limpiar configuración vieja
comando:: sudo ip addr flush dev ens33
# 2. Asignar IP y Máscara (Tu red específica)
comando:: sudo ip addr add 10.10.10.6/24 dev ens33
# 3. Levantar la tarjeta
comando:: sudo ip link set ens33 up
3. Resolución del Conflicto de Rutas (Default Gateway)
El Error: RTNETLINK answers: File exists. Explicación: Intentaste añadir una ruta por defecto cuando ya existía una (hacia la .2). Linux solo permite una puerta de enlace principal. Si el gateway configurado en la VM no coincide exactamente con el “NAT Settings” de VMware, el paquete llega al router pero no sale a Internet.
Solución Documentada:
Bash
# Borrar la ruta incorrecta existente
comando:: sudo ip route del default
# Añadir la ruta correcta (Hacia tu router .1)
comando:: sudo ip route add default via 10.10.10.1
4. Configuración de DNS (Resolución de Nombres)
Incluso con IP y Gateway, sin DNS no puedes navegar por nombres (ej. github.com). En REMnux, a veces el archivo se bloquea o no se actualiza.
Solución Documentada:
Bash
comando:: sudo bash -c ‘echo “nameserver 8.8.8.8” > /etc/resolv.conf’
5. Verificación en el Host (VMware Workstation)
Si la VM está perfecta pero sigue sin internet, el problema es el “Router Virtual” de VMware en Windows.
Puntos de control en Virtual Network Editor:
-
Subnet IP: Debe ser 10.10.10.0.
-
Subnet Mask: 255.255.255.0.
-
NAT Settings → Gateway IP: Debe coincidir con lo que pongas en la VM (en tu caso 10.10.10.1).
-
Servicios: En Windows, los servicios VMware NAT Service y VMware DHCP Service deben estar “Running”.
Resumen de Comandos “Cheat Sheet” para tu Próximo Sandbox
Si mañana montas otra VM y no tiene red, este es tu “Kit de Emergencia”:
-
ip a (Ver si tienes IP).
-
ip route show (Ver a dónde apuntas).
-
ping 10.10.10.1 (¿Llego a mi router?).
-
ping 8.8.8.8 (¿Salgo de mi casa?).
-
sudo dhclient -v ens33 (Pedir IP si prefieres DHCP).
Mentoría: Siguiente Paso
Ahora que tu laboratorio está blindado y con conexión, toca la parte de Ciberseguridad pura.
Ya tienes REMnux listo. Te sugiero que descargues de nuevo el binario dedsec_wi-fidar dentro de REMnux y, antes de ejecutarlo, lances este comando que viene incluido:
Bash
capa ./dedsec_wi-fidar
¿Quieres que analicemos juntos qué nos dice capa sobre las intenciones ocultas de ese binario? Es la mejor forma de empezar un análisis de malware serio.