
Laboratorio local de pruebas de penetración usando docker-compose.
Ya no estoy desarrollando activamente esto, pero corregiré errores y revisaré issues y pull requests. Se agradece la ayuda :)
Este laboratorio de pentest local utiliza docker compose para levantar múltiples servicios víctimas y un servicio atacante que ejecuta Kali Linux. Si ejecutas este laboratorio por primera vez, tomará tiempo descargar todas las imágenes docker diferentes.
Comandos ejecutados:
./lab.sh --help./lab.sh --check-dependencies./lab.sh --up --all-services./lab.sh --info./lab.sh --overview allssh root@kali -o "UserKnownHostsFile /dev/null"./lab.sh --downEl laboratorio debería funcionar sin problemas si todas las dependencias necesarias están instaladas. Al iniciar, el laboratorio ejecutará una verificación de dependencias.
git clone https://github.com/oliverwiegers/pentest_lab
cd pentest_lab
./lab.sh -u
Por defecto, el laboratorio iniciará todos los servicios víctimas y un servicio de equipo rojo. Se pueden iniciar y agregar otros servicios. Más información sobre esto más abajo.
Para más información sobre el uso, considera leer el mensaje de ayuda mostrado por ./lab.sh -h | --help.
El laboratorio tiene una verificación de dependencias incorporada que se ejecuta al inicio. También se puede ejecutar manualmente ./lab.sh -C.
Para facilitar su uso, se agregó una interfaz Heimdall que está expuesta en localhost:7000.
Allí se listan todos los servicios que están expuestos a tu máquina local y a los que se puede acceder mediante navegador.
Los cambios que se hagan en la interfaz se guardan automáticamente en ./etc/heimheimdall. Este directorio se convierte luego en ./etc/heimdall.tar al detener el laboratorio. Este archivo tar se extraerá al inicio. Tanto ./etc/heimdall.tar como ./etc/heimdall están ignorados por git por defecto.
El wallpaper utilizado se puede encontrar aquí.
Este laboratorio reconoce los siguientes cuatro tipos de servicios.
El servicio de equipo rojo por defecto (el servicio Kali) es una instancia básica de Kali. No obstante, el metapaquete kali-tools-web está instalado. Para un laboratorio de pruebas de aplicaciones web, las herramientas básicas de prueba web parecen útiles.
Esto se puede cambiar editando el Dockerfile a partir del cual se construye la imagen. Se encuentra en ./dockerfiles/kali.
El servicio kali instala estos dotfiles por defecto. Esto también se puede cambiar ajustando el Dockerfile.
Aunque los servicios de monitorización también son servicios de equipo azul, están separados en una categoría diferente.
Este stack proporciona funcionalidad de observación de logs y rendimiento.
Para más información sobre instancias individuales, ver más abajo.
Actualmente, la configuración de monitorización está compuesta por los siguientes servicios:
La instancia de Grafana proporciona dos paneles: uno para logs y otro para métricas.
Estos son bastante básicos. Se podrían añadir más agregando paneles a través de la interfaz de Grafana. Estos paneles se perderán cuando se elimine el volumen de grafana. Para agregar paneles de forma permanente, consulta la Documentación de Provisioning de Grafana. Los directorios utilizados para el provisioning se encuentran en ./etc/grafana/.
Para cambiar la configuración a través de la interfaz de Grafana, debes iniciar sesión como admin. Las credenciales son las predeterminadas: admin:admin. #hacktheplanet
Para que Loki pueda recopilar logs de docker, este laboratorio instala el Loki Docker Driver como plugin de Docker.
Para que Prometheus pueda acceder a las métricas de rendimiento de los contenedores que se ejecutan en el clúster, se utiliza cAdvisor.
Para agregar servicios adicionales, se necesita un poco de conocimiento de archivos docker-compose.yml. El docker-compose.yml en la raíz de este repositorio se genera automáticamente cuando el laboratorio se inicia. Este proceso utiliza los archivos yaml ubicados en ./etc/services.
➜ pentest_lab tree ./etc/services
./etc/services
├── blue_team
│ └── endlessh.yml
├── default.yml
├── monitoring
│ ├── cadvisor.yml
│ ├── grafana.yml
│ ├── loki.yml
│ └── prometheus.yml
├── red_team
└── victim
├── beginner
│ ├── bwapp.yml
│ ├── dvwa.yml
│ ├── hackazon.yml
│ ├── tiredful.yml
│ ├── webgoat.yml
│ └── xvwa.yml
├── expert
│ └── juice-shop.yml
└── intermediate
└── ninjas.yml
Qué servicios se iniciarán se controla invocando ./lab.sh con las opciones correspondientes. Para deshabilitar permanentemente un servicio, elimina la extensión .yml.
Un ejemplo de un servicio víctima sería:
bwapp:
labels:
class: 'victim'
cluster: 'pentest_lab'
level: 'beginner'
image: raesene/bwapp
ports:
- '8080:80'
networks:
pentest_lab:
ipv4_address: 10.5.0.100
hostname: bwapp
volumes:
- bwapp-data:/var/lib/mysql
Nota: Si un servicio requiere algún tipo de instalación en el primer uso, usa docker inspect <nombre_de_imagen> para averiguar dónde almacena los datos la imagen docker y agrega un volumen que apunte a ese directorio. En el ejemplo anterior, esto es:
volumes:
- bwapp-data:/var/lib/mysql
Esto asegura que no tengas que configurar el servicio de nuevo cada vez que reinicies el laboratorio. Pero si quieres restablecer el laboratorio y empezar de nuevo por completo, puedes usar ./lab.sh -p | --prune. Esto eliminará todos los recursos propiedad del laboratorio.
La razón por la que usamos direcciones IP estáticas es que la caja Kali necesita tener una dirección IP que no cambie para simplificar el inicio de sesión SSH. Más información en la sección Consejos/Trucos más abajo.
Si agregas servicios y hay información adicional que sea útil para cualquiera que ejecute este laboratorio, puedes agregar esta información a ./etc/services_info. El contenido de este archivo se imprimirá tal cual, línea por línea, al ejecutar ./lab.sh -i.
Para una conexión fácil al servicio Kali, se podría agregar lo siguiente a $HOME/.ssh/config:
Host kali
User root
Hostname 10.5.0.5
UserKnownHostsFile /dev/null
StrictHostKeyChecking accept-new
Así que en lugar de ssh [email protected] -o "UserKnownHostsFile /dev/null" se podría ejecutar ssh kali.
Para usuarios de tmux, lo siguiente se conectará automáticamente a una sesión de tmux:
Host kali
User root
Hostname 10.5.0.5
UserKnownHostsFile /dev/null
StrictHostKeyChecking accept-new
RequestTTY yes
RemoteCommand tmux -L tmux new-session -As hacktheplanet