IMPLEMENTACIÓN DE LABORATORIOS DE CIBERSEGURIDAD PARA LA SIMULACIÓN DE ATAQUES Y PRUEBAS DE INTRUSIÓN EN ENTORNOS AISLADOS
Resumen
En este trabajo se aborda el desafío de formar profesionales en ciberseguridad mediante la implementación de laboratorios accesibles y económicos para entornos académicos. Se presenta un enfoque para reducir costos sin comprometer la calidad educativa: contenedores Docker (Kali Linux, OWASP Juice Shop, Metasploitable). Estos laboratorios simulan ataques controlados en entornos aislados y seguros, permitiendo a los estudiantes practicar técnicas de reconocimiento, explotación y post-explotación sin riesgos para infraestructuras reales. Los resultados demuestran la efectividad de estas soluciones, destacando la escalabilidad de los contenedores, lo que optimiza significativamente el proceso de enseñanza-aprendizaje en instituciones con recursos limitados.
1. Introducción
La creciente complejidad de las ciberamenazas demanda profesionales con habilidades prácticas sólidas, capaces de enfrentar escenarios reales. En este contexto, los laboratorios de ciberseguridad se vuelven fundamentales en entornos académicos, ya que permiten a los estudiantes experimentar, equivocarse y aprender en un ambiente controlado, sin riesgo para infraestructuras reales [Chaparro,2024]. Sin embargo, la implementación de laboratorios tradicionales conlleva costos elevados en hardware, software y mantenimiento, limitando su accesibilidad a los estudiantes como en [García,2024] que ofrece un entorno completo basado en nube privada. En este trabajo se analizan las posibilidades que ofrecen las tecnologías de virtualización, como contenedores Docker, para reducir drásticamente estos costos sin comprometer la calidad educativa. El objetivo es demostrar cómo estas herramientas facilitan la creación de entornos de prueba aislados, escalables y económicos, que replican vulnerabilidades y ataques complejos, optimizando así el proceso de enseñanza-aprendizaje en instituciones educativas con recursos limitados. En [Martínez-García,2024], se desarrolla un laboratorio basado en raspberry de bajas prestaciones, y se busca en una futura línea de investigación el uso de sistemas operativos y aplicaciones minimalistas para optimizar el rendimiento del sistema.
2. Métodos
2.1 Prerrequisitos
La implementación del laboratorio requiere una preparación técnica específica del sistema anfitrión. Para entornos con sistema operativo Windows, es esencial habilitar WSL 2 mediante PowerShell con permisos de administrador, seguido de la instalación del kernel de WSL 2 y la configuración de esta versión como predeterminada. En sistemas Linux, se recomienda una distribución basada en Debian [Debian,2025]. Posteriormente, se instala Docker Engine y Docker Compose, verificando su funcionamiento con contenedores de prueba. La integración entre WSL 2 y Docker Desktop en Windows es crucial para garantizar la compatibilidad. Se asignan recursos mínimos de 4 GB de RAM y 20 GB de almacenamiento para operar múltiples contenedores simultáneamente.
Habilitar WSL 2 (Windows 10/11 Pro o Superior)
Ejecutar las instrucciones en PowerShell (Admin):
dism.exe /online /enable-feature/featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
Reiniciar el sistema
2.1.1. Instalación de una distribución Linux en WSL
Se Accede a Microsoft Store y buscar la distribución deseada, como Debian. Proceder con la instalación y, una vez completada, iniciar la distribución desde el menú de inicio. O si ya conoce la distribución puede escribirla directamente.
wsl —install -d Debian
Configuración inicial de Debian
Durante el primer inicio, se solicitará la creación de un usuario y contraseña. Estos datos son independientes de las credenciales de Windows y se utilizarán para gestionar la instancia de WSL.
Obtener la versión estable de Docker Desktop desde el sitio oficial de Docker y ejecutar el instalador con las opciones predeterminadas, asegurándose de marcar la instalación de componentes adicionales requeridos para docker [Docker,2025].
Es recomendable el uso de Docker desktop para facilitar la administración de los contenedores. En la referencia de Docker hay que descargarlo e instalarlo también en Debian.
Es importante integrarlo con Debian. En la figura 1 se describen los pasos para hacerlo.
Por último, verificar la instalación con los comandos:
docker --version
Docker compose --version
Probar la ejecución de un contenedor con el siguiente comando:
docker run hello-world
2.2 Arquitectura del Laboratorio de Pruebas
La arquitectura general de los laboratorios se muestra en la figura 2, donde se muestra el contenedor de kali Linux que tiene las herramientas que se utilizan para realizar los ataques y están unidos por la red de Docker Network a los contenedores que tienen configurados los servicios vulnerables, todo ello en un solo host basado en Linux o Windows
Fuente: elaboración propia
Figura 2 Arquitectura basada en contenedores.
La estructura del laboratorio se organiza en directorios modulares para facilitar la gestión y escalabilidad. En la figura 3 se muestra como cada contenedor reside en su propia carpeta, conteniendo archivos de configuración específicos como Dockerfile y scripts. Esta organización permite la replicabilidad del entorno y la personalización de componentes individuales sin afectar el sistema general. La raíz del proyecto, que puede colocarse dentro de la carpeta de documentos del usuario, incluye el archivo docker-compose.yml.
Fuente: elaboración propia
Figura 3 Estructura de directorios recomendada.
2.3 Contenedores Preconfigurados
El laboratorio utiliza imágenes especializadas para emular entornos vulnerables y herramientas de evaluación. El archivo que contiene todo el código de la red, los volúmenes, los servicios interconectados y la ubicación de los contenedores es docker-compose.yml, éste y los archivos Dockerfile son sensibles a la identación. El código que debe contener el archivo docker-compose.yml es el siguiente:
services:
kali:
build: ./kali
container_name: kali_lab
hostname: kali-lab
networks:
pentest-net:
aliases:
- kali
volumes:
- ./kali_lab_data:/home/pentester/lab_data
environment:
- TZ=America/Mexico_City
deploy:
resources:
limits:
cpus: '2'
memory: 4GB
tty: true
stdin_open: true
privileged: true
dvwa:
build: ./dvwa
container_name: dvwa
networks:
pentest-net:
aliases:
- dvwa
ports:
- "8080:80"
restart: unless-stopped
juiceshop:
build: ./juiceshop
container_name: juiceshop
networks:
pentest-net:
aliases:
- juiceshop
ports:
- "3000:3000"
volumes:
- ./juiceshop/config:/juiceshop/config
- ./juiceshop/data:/juiceshop/data
environment:
- NODE_ENV=production
restart: unless-stopped
metasploitable2:
build: ./metasploitable2
container_name: metasploitable2
networks:
pentest-net:
aliases:
- metasploitable2
ports:
- "21:21"
- "22:22"
- "23:23"
- "80:80"
- "4445:445"
- "3306:3306"
webgoat:
build: ./webgoat
container_name: webgoat
networks:
pentest-net:
aliases:
- webgoat
ports:
- "8082:8080"
- "9090:9090"
environment:
- TZ=America/Mexico_City
restart: unless-stopped
volumes:
- webgoat_data:/home/webgoat/.webgoat-8.0.0
- webwolf_data:/home/webgoat/.webwolf-8.0.0
pwnedsql:
build: ./pwnedsql
container_name: pwnedsql
networks:
pentest-net:
aliases:
- pwnedsql
ports:
- "3307:3306"
environment:
- TZ=America/Mexico_City
- MYSQL_ROOT_PASSWORD=root123
- MYSQL_DATABASE=vulnerable_db
- MYSQL_USER=victim_user
- MYSQL_PASSWORD=weakpassword
restart: unless-stopped
volumes:
- pwnedsql_data:/var/lib/mysql
- ./pwnedsql/my.cnf:/etc/mysql/conf.d/my.cnf
networks:
pentest-net:
driver: bridge
internal: false
volumes:
webgoat_data:
driver: local
webwolf_data:
driver: local
pwnedsql_data:
driver: local
2.4 Características de la red aislada
La red personalizada pentest-net se configura como tipo bridge. Esta red permite comunicación exclusiva entre contenedores del laboratorio y opera en modo interno, bloqueando toda conectividad externa o acceso a Internet.
Es importante tomar en cuenta que la red networks debe estar conectada al exterior al momento de configurar y construir los contenedores: internal: false, posteriormente se debe deshabilitar cambiando a internal: true, con ello, se impide el acceso desde el exterior.
2.5 Despliegue del contenedor Kali Linux
Kali se construye desde la imagen oficial kalilinux/kali-rolling, [Kali, 2025] como un contenedor personalizado con herramientas esenciales como Metasploit [Metasploit,2025], Nmap [nmap,2025] y Burp Suite [Burp Suite,2025] entre otras. Se configura un usuario no privilegiado denominado pentester para prácticas seguras y se montan volúmenes persistentes para almacenar resultados de pruebas. El despliegue se ejecuta desde la línea de comandos mediante docker compose build y Docker compose up, integrando los contenedores a la red pentest-net. El código del archivo Dockerfile en la carpeta kali queda de la siguiente manera:
FROM kalilinux/kali-rolling
LABEL maintainer="Lab de Pentesting"
LABEL description="Kali Linux seguro para laboratorio"
ENV DEBIAN_FRONTEND=noninteractive \
TZ=America/Mexico_City
RUN echo "Configurando Kali Linux ..." && \
apt-get update -y && \
apt-get full-upgrade -y && \
apt-get install -y --no-install-recommends \
iputils-ping netcat-traditional \
nmap \
metasploit-framework \
kali-tools-exploitation \
hydra \
sqlmap \
wireshark \
john \
git \
python3-pip \
python3-dev \
libffi-dev \
libssl-dev \
default-jdk \
wget \
nano \
ssh-client \
&& apt-get clean \
&& rm -rf /var/lib/apt/lists/*
# Instalar Burp Suite Community
RUN mkdir -p /opt/burpsuite && \
cd /opt/burpsuite && \
wget -q "https://portswigger.net/burp/releases/download?product=community&version=latest&type=Jar" -O burpsuite.jar && \
echo '#!/bin/sh\njava -jar /opt/burpsuite/burpsuite.jar' > /usr/local/bin/burpsuite && \
chmod +x /usr/local/bin/burpsuite
RUN useradd -m -s /bin/bash pentester && \
echo 'pentester:PasswordSeguro123!' | chpasswd && \
chmod 700 /home/pentester && \
mkdir -p /home/pentester/lab_data && \
chown pentester:pentester /home/pentester/lab_data
WORKDIR /home/pentester
USER pentester
CMD ["/bin/bash", "-l"]
2.6. Despliegue de servicios vulnerables para entorno de pruebas
Un servicio vulnerable en un laboratorio de pruebas es un software, aplicación o sistema, intencionalmente configurado con fallos de seguridad conocidos o desconocidos, diseñado para ser explotado de manera controlada con fines educativos, de investigación o evaluación de seguridad.
2.6.1. Servicio SSH/FTP Metasploitable
Basado en la imagen phocean/msf, este contenedor emula un sistema Linux con servicios mal configurados. Los puertos 21 (FTP) y 22 (SSH) quedan expuestos intencionalmente con credenciales débiles y versiones de software vulnerables.
Este entorno es particularmente útil para practicar técnicas de escalamiento de privilegios y explotación de servicios de red. El código del archivo Dockerfile en la carpeta metasploitable2 queda de la siguiente manera:
Basado en Ubuntu 16.04 LTS (Xenial Xerus)
FROM ubuntu:16.04
Configuración básica
ENV DEBIAN_FRONTEND=noninteractive
Instalar paquetes necesarios
RUN apt-get update && apt-get install -y \
sudo openssh-server vsftpd apache2 postfix \
dovecot-imapd samba bind9 mysql-server-5.7 \
postgresql tomcat7 vnc4server nfs-kernel-server \
snmp telnetd tftp php7.0 libapache2-mod-php7.0 \
&& apt-get clean && rm -rf /var/lib/apt/lists/*
Crear directorio para configuraciones
RUN mkdir -p /metasploitable-config
Copiar archivos de configuración
COPY metasploitable-config/ /metasploitable-config/
Configurar servicios vulnerables
RUN echo ‘root:password’ | chpasswd && echo ‘PermitRootLogin yes’ >> /etc/ssh/sshd_config && \
mv /metasploitable-config/vsftpd.conf /etc/vsftpd.conf && \
mv /metasploitable-config/phpinfo.php /var/www/html/ && \
chmod 755 /var/www/html/phpinfo.php && \
chmod 777 /tmp && chmod -R 777 /var/www/ && \
service mysql start && mysql < /metasploitable-config/mysql-config.sql && \
rm -rf /metasploitable-config
Exponer puertos
EXPOSE 21 22 23 25 53 80 110 111 139 445 512 513 514 1524 2049 3306 5432 5900 6667
Script para iniciar servicios
COPY metasploitable-config/services-start.sh /services-start.sh
RUN chmod +x /services-start.sh
Iniciar servicios
CMD [“/services-start.sh”]
El primer archivo de configuración es mysql-config.sql con el siguiente contenido:
UPDATE mysql.user SET authentication_string=PASSWORD('password') WHERE User='root';
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY 'password' WITH GRANT OPTION;
DROP DATABASE IF EXISTS test;
CREATE DATABASE vulnerable_db;
USE vulnerable_db;
CREATE TABLE users (id INT, username VARCHAR(255), password VARCHAR(255));
INSERT INTO users VALUES (1, 'admin', 'admin123');
FLUSH PRIVILEGES;
Nótese que se usa la palabra password y usuario root como autentificación. En la tabla users se agrega también el usuario admin y clave admin123.
El código del archivo del archivo phpinfo.php es:
El código del archivo postgres-config.sql queda de la siguiente manera:
ALTER USER postgres WITH PASSWORD 'postgres';
CREATE DATABASE vulnerable_db;
\c vulnerable_db
CREATE TABLE users (id INT, username VARCHAR(255), password VARCHAR(255));
INSERT INTO users VALUES (1, 'admin', 'admin123');
Se usa como clave lo mismo que el nombre de usuario y se inserta el usuario admin y clave admin123.
El archivo de configuración para vfstpd.conf es:
listen=YES
anonymous_enable=YES
local_enable=YES
write_enable=YES
anon_upload_enable=YES
anon_mkdir_write_enable=YES
anon_other_write_enable=YES
no_anon_password=YES
xferlog_enable=YES
connect_from_port_20=YES
secure_chroot_dir=/var/run/vsftpd/empty
pam_service_name=vsftpd
rsa_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
rsa_private_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
Esta configuración permite la escritura lo que hace posible crear, modificar y eliminar archivos y directorios y también permite el acceso a usuarios anónimos sin clave. Como el usuario anonymous/ftp o cualquier correo como contraseña. Permite también subir archivos y conectarse en texto plano al servicio de ftp. Con xferlog_enable=YES, sólo se guardan las transferencias y no las órdenes completas para ello se necesitaría log_ftp_protocol=YES. Sin la opción chroot_local_user=YES, los usuarios pueden navegar por todo el sistema. Tampoco hay restricciones de IP ni tasa límite, lo que permite ataques de fuerza bruta. Se pueden agregar usuarios adicionales con la siguiente orden en Dockerfile:
RUN useradd -m ftpuser && echo “ftpuser:password123” | chpasswd.
Y crear también archivos sensibles:
echo "Secreto:credenciales=admin:password" > /var/ftp/confidencial.txt
El último archivo services-start.sh permite iniciar todos los servicios del contenedor. Su contenido es el siguiente:
#!/bin/bash
service ssh start
service vsftpd start
service apache2 start
service postfix start
service dovecot start
service smbd start
service bind9 start
service mysql start
service postgresql start
service tomcat7 start
service nfs-kernel-server start
# Mantener el contenedor en ejecución
tail -f /dev/null
2.6.2. OWASP Juice Shop
Se implementa utilizando la imagen oficial bkimminich/juice-shop, una aplicación web moderna diseñada específicamente para prácticas de seguridad. La orden de despliegue configura el servicio en el puerto 3000 tanto en el host como en el contenedor, integrado directamente a la red aislada del laboratorio. La aplicación ofrece más de 100 vulnerabilidades intencionales de OWASP Top 10, incluyendo inyecciones SQL, XSS, y fallos de autenticación [OWASP,2025]. El contenido del archivo Dockerfile es:
FROM bkimminich/juice-shop:v13.3.0
ENV DEBIAN_FRONTEND=noninteractive
LABEL maintainer="Lab de JuiceShop"
LABEL description="juiceShop para laboratorio de pentesting"
EXPOSE 3000
CMD ["npm", "start"]
Se realiza una prueba de acceso desde el navegador con la siguiente url: http://localhost:3000
2.6.3. Damn Vulnerable Web App (DVWA)
La imagen vulnerables/web-dvwa proporciona un entorno PHP/MySQL preconfigurado con vulnerabilidades clásicas. Al mapear el puerto 8080 del contenedor al puerto 80 en el host, se replica un entorno web realista. El sistema incluye un panel de configuración de seguridad ajustable que permite modificar el nivel de dificultad para las pruebas, desde bajo hasta imposible. El contenido del archivo Dockerfile es:
FROM vulnerables/web-dvwa
LABEL maintainer="Lab de Pentesting"
LABEL description="DVWA para laboratorio de pentesting"
EXPOSE 80
Se realiza una prueba de acceso desde el navegador con la siguiente url: localhost:8080
2.6.4. Base de Datos MySQL Vulnerable
La imagen pwnedsql/mysql-vuln despliega una instancia de MySQL con múltiples vulnerabilidades de inyección SQL preconfiguradas. El puerto 3306 queda accesible para permitir pruebas directas de explotación de bases de datos. Incluye conjuntos de datos de ejemplo con información sensible mal protegida, ideal para ejercicios de extracción de datos. El código en el archivo Dockerfile correspondiente es:
FROM mysql:5.7.35
LABEL maintainer="Pentest Team"
LABEL description="MySQL Vulnerable para prácticas de inyección SQL"
# Eliminar configuraciones obsoletas
RUN sed -i '/secure-auth/d' /etc/mysql/my.cnf && \
echo "[mysqld]\ndefault-authentication-plugin = mysql_native_password" >> /etc/mysql/conf.d/auth.cnf
COPY vulnerable-db.sql /docker-entrypoint-initdb.d/
COPY my.cnf /etc/mysql/conf.d/
ENV MYSQL_ROOT_PASSWORD=root123 \
MYSQL_DATABASE=vulnerable_db \
MYSQL_USER=victim_user \
MYSQL_PASSWORD=weakpassword
EXPOSE 3306
HEALTHCHECK --interval=30s --timeout=10s --start-period=60s \
CMD mysqladmin ping -uroot -proot123 || exit 1
Se tienen dos archivos de configuración que deben de estar en la carpeta pwnedsql, el primero es my.cnf su código es el siguiente:
[mysqld]
secure-file-priv = ""
local-infile = 1
log_warnings = 2
default-authentication-plugin = mysql_native_password
skip-name-resolve
El Segundo es vulnerable-db.sql:
CREATE DATABASE IF NOT EXISTS vulnerable_db;
USE vulnerable_db;
CREATE TABLE users (
id INT AUTO_INCREMENT PRIMARY KEY,
username VARCHAR(50),
password VARCHAR(50),
email VARCHAR(100),
credit_card VARCHAR(20),
is_admin TINYINT(1)
);
INSERT INTO users VALUES
(1, 'admin', 'supersecret', '[email protected]', '4111111111111111', 1),
(2, 'alice', 'alice123', '[email protected]', '5555555555554444', 0),
(3, 'bob', 'password', '[email protected]', '378282246310005', 0);
DELIMITER //
CREATE PROCEDURE vulnerable_proc(IN userid INT)
BEGIN
SET @sql = CONCAT('SELECT * FROM users WHERE id = ', userid);
PREPARE stmt FROM @sql;
EXECUTE stmt;
DEALLOCATE PREPARE stmt;
END //
DELIMITER ;
GRANT ALL PRIVILEGES ON *.* TO 'victim_user'@'%' IDENTIFIED BY 'weakpassword';
FLUSH PRIVILEGES;
Aquí es donde se crea una base de datos con vulnerabilidades conocidas.
2.7. Verificación del despliegue
Para confirmar el correcto funcionamiento de todos los servicios:
Ejecutar docker ps para verificar el estado de los contenedores
Realizar pruebas de conectividad básica desde el contenedor Kali a cada uno de los contenedores con el comando:
docker exec -it kali_lab ping metasploitable2
Verificar los logs específicos de cada servicio, por ejemplo el de metasplotable2 con el comando:docker logs metasploitable2
2.8. Consideraciones de Seguridad
Cada servicio está diseñado con propósitos educativos y debe permanecer aislado en la red interna del laboratorio de pruebas. Después de configurar adecuadamente los contenedores se recomienda:
Restringir el acceso físico a la red. Cambiar las instrucciones internal: false a internal:true
Monitorear el tráfico de red durante las pruebas.
Eliminar los contenedores al finalizar las sesiones de práctica.
Nunca exponer estos servicios en redes públicas o productivas.
3. Resultados
La implementación del laboratorio basado en contenedores Docker demostró ser altamente efectiva para la creación de entornos de práctica en ciberseguridad. Se logró configurar exitosamente una infraestructura completa que incluye herramientas de pentesting (Kali Linux) y múltiples servicios vulnerables (OWASP Juice Shop, DVWA, Metasploitable) en un entorno aislado. La red personalizada pentest-net operó correctamente en modo interno, garantizando el aislamiento completo del exterior una vez configurada con internal: true.
Los contenedores mostraron un óptimo rendimiento con la asignación de recursos especificada (4 GB de RAM, 2 núcleos de CPU), permitiendo la ejecución simultánea de múltiples servicios sin afectar el sistema anfitrión. La verificación de conectividad mediante docker exec -it kali_lab ping metasploitable2 confirmó la correcta comunicación entre todos los componentes del laboratorio. El acceso a los servicios se validó satisfactoriamente a través de los puertos designados: Juice Shop en puerto 3000, DVWA en puerto 8080, y los servicios de Metasploitable en sus puertos respectivos.
La estructura modular de directorios facilitó la gestión y replicabilidad del ambiente, mientras que los volúmenes persistentes aseguraron la conservación de los resultados de las prácticas entre sesiones. El proceso de despliegue completo, desde la instalación de los prerrequisitos hasta la puesta en marcha de todos los contenedores, demostró ser reproducible y consistentemente exitoso en equipos con diferentes características de hardware con las configuraciones mínimas especificadas.
4. Discusión
Los resultados obtenidos validan la efectividad del enfoque basado en contenedores para la implementación de laboratorios de ciberseguridad en entornos académicos. La arquitectura propuesta aborda exitosamente el desafío de reducir costos sin comprometer la calidad educativa, eliminando la necesidad de hardware especializado y permitiendo la ejecución en equipos estándar.
La escalabilidad de la solución con contenedores permite adaptar el laboratorio a diferentes necesidades educativas, desde ejercicios básicos hasta escenarios complejos de múltiples capas. El aislamiento de red efectivo garantiza que las prácticas de hacking ético se realicen en un ambiente completamente controlado, eliminando riesgos para infraestructuras externas y cumpliendo con los protocolos éticos requeridos.
La diversidad de servicios vulnerables implementados (aplicaciones web, servicios de red, bases de datos) proporciona un espectro completo de vectores de ataque para prácticas educativas. Esto permite a los estudiantes desarrollar habilidades comprensivas que van desde el reconocimiento básico hasta técnicas avanzadas de explotación y post-explotación.
La principal limitación identificada reside en la familiaridad inicial con tecnologías de contenedores, aunque la documentación detallada mitiga esta barrera. El modelo demostró ser significativamente más económico que laboratorios físicos tradicionales, con costos marginales por estudiante una vez establecida la infraestructura base.
Los principios arquitectónicos y metodológicos documentados pueden extenderse a otros entornos de aprendizaje que requieran ambientes controlados para prácticas técnicas.
5. Conclusiones
La implementación de laboratorios de ciberseguridad mediante contenedores demuestra ser una solución eficaz y accesible para entornos académicos con recursos limitados. Los resultados confirman que esta aproximación tecnológica permite crear ambientes de práctica realistas y seguros, capaces de emular vulnerabilidades complejas y vectores de ataque diversos sin comprometer infraestructuras reales.
El enfoque basado en contenedores ofrece ventajas significativas en términos de escalabilidad, portabilidad y eficiencia de recursos. La arquitectura modular facilita la replicabilidad del laboratorio y su adaptación a diferentes necesidades pedagógicas.
La diversidad de servicios vulnerables implementados proporciona un espectro completo para el desarrollo de competencias técnicas. Los estudiantes pueden desarrollar habilidades de pentesting en un ambiente controlado que fomenta la experimentación y el aprendizaje mediante prueba y error.
Este modelo representa una alternativa viable y de bajo costo frente a los laboratorios físicos tradicionales o laboratorios en línea, reduciendo barreras de acceso a la educación práctica en ciberseguridad. La documentación y metodología presentadas establecen un marco replicable para instituciones educativas que buscan implementar laboratorios especializados sin inversiones prohibitivas en hardware o infraestructura.
Este trabajo contribuye a democratizar el acceso a la educación en ciberseguridad, proporcionando una base sólida para la formación de profesionales capaces de enfrentar los desafíos actuales del panorama de amenazas digitales.
6. Bibliografía y Referencias
[1] Bjoern Kimminich & the OWASP Juice Shop contributors The OWASP Foundation, https://owasp.org/www-project-juice-shop/, 2025
[2] Burp Suite, Trusted by security professionals, https://portswigger.net/, 2025
[3] Chaparro Gutiérrez, J y Moreno Cortés, J. (2024). Creación de un laboratorio de pruebas de seguridad para fomentar la experiencia de aprendizaje en ciberseguridad.
https://bibliotecadigital.usb.edu.co/entities/publication/84d5c6fd-bb16-4e70-af44-2cfa12094a00
[4] Debian, El sistema operativo completamente libre, https://www.debian.org/, 2025
[5] Docker Instalación de docker desktop,
https://www.docker.com/products/docker-desktop/, 2025
[6] García Mena, Jose(2024), Desarrollo de un entorno de simulación como laboratorio de prácticas especializado en ciberseguridad.
https://openaccess.uoc.edu/server/api/core/bitstreams/77971f44-41a0-457e-9e1c-9cc90a3c2c1d/content
[7] Holzen Atocha Martínez-García, Enrique Camacho-Pérez. Ligia Beatriz Chuc-Us, EthkLab: Laboratorio de bajo costo para aprendizaje práctico en temas de ciberseguridad.
https://www.ride.org.mx/index.php/RIDE/article/view/2052, 2024
[8] Kali, Using Kali Linux Docker Images
https://www.kali.org/docs/containers/using-kali-docker-images/, 2025
[9] Metasploit, The wolrd’s most used penetration testing framework,
https://www.metasploit.com/, 2025
[10]nmap, Discover your network, https://nmap.org/, 2025
[11]Microsoft, Instalación de Linux en Windows con WSL.
https://learn.microsoft.com/es-es/windows/wsl/install, 2025.
[12]Santillan, H., Arévalo Satán , J. A. ., & Wong , P. . (2024). Un análisis integral de la infraestructura de ciberseguridad en ambientes académicos. Ingeniería, 35(1), 11–23. https://doi.org/10.15517/ri.v35i1.60075