Pentest Lab Laboratorio Pentesting Local utilizando Docker-Compose
Pentest Lab Laboratorio Pentesting Local utilizando Docker-Compose

Pentest Lab: Laboratorio de Pentesting Local utilizando Docker-Compose

Una de las características más potentes de Docker es su capacidad para crear entornos preconfigurados que ayudan a ejecutar aplicaciones en diferentes escenarios. Esto es extremadamente útil para pentesters e investigadores de seguridad que quieren probar sus hallazgos contra diferentes configuraciones y ajustes sin tener que configurar 7stus propios entornos de desarrollo o de prueba en sus propias máquinas.

Este laboratorio de Pentesting local aprovecha docker compose para hacer girar múltiples servicios de víctima y un servicio de atacante que ejecuta Kali Linux. Si ejecutas este laboratorio por primera vez, te llevará algún tiempo descargar todas las diferentes imágenes docker.

Comandos ejecutados:

  • ./lab.sh --help
  • ./lab.sh --check-dependencies
  • ./lab.sh --up --all-services
  • ./lab.sh --info
  • ./lab.sh --overview all
  • ssh root@kali -o "UserKnownHostsFile /dev/null"
  • ./lab.sh --dow

Uso

El laboratorio debería funcionar de forma inmediata si todas las dependencias necesarias están instaladas. Al iniciar el laboratorio se ejecutará una comprobación de dependencias.

Iniciar el laboratorio

git clone https://github.com/oliverwiegers/pentest_lab
cd pentest_lab
./lab.sh -u

Por defecto, el laboratorio iniciará todos los servicios de víctimas y un servicio de equipo rojo. Se pueden iniciar y añadir otros servicios. Más información sobre esto a continuación.

Para más información sobre el uso, considera la posibilidad de leer el mensaje de ayuda mostrado por:

./lab.sh -h | --help

Dependencias:

  • bash
  • find
  • sed
  • yq (La versión de Python. No yq-go.)
  • docker
  • docker-compose

El laboratorio tiene una comprobación de dependencias incorporada que se ejecuta al inicio. También se puede ejecutar manualmente:

./lab.sh -C

Heimdall

Para facilitar el uso se ha añadido una interfaz Heimdall que se expone a localhost:7000. Todos los servicios que están expuestos a tu máquina local y pueden ser accedidos a través del navegador están listados allí. Los cambios que se realicen en la interfaz se guardan automáticamente en ./etc/heimdall. Este directorio se convierte entonces en ./etc/heimdall.tar al detener el laboratorio. Este archivo tar será extraído en el arranque. Tanto ./etc/heimdall.tar como ./etc/heimdall son ignorados por git por defecto.

https://github.com/linuxserver/Heimdall
Pentest Lab con interfaz Heimdall
Pentest Lab con interfaz Heimdall

El fondo de pantalla usado se puede encontrar aquí.

https://wallpapercave.com/w/wp6241750

Servicios

Este laboratorio conoce los siguientes cuatro tipos de servicios.

  • red_team
  • blue_team
  • victim
  • monitoring

El servicio por defecto del equipo rojo (red team) – el servicio Kali – es una instancia Kali bastante básica. No obstante,, el metapaquete kali-tools-web está instalado. Para un laboratorio de pruebas de aplicaciones web las herramientas básicas de pruebas web parecen ser útiles. Esto se puede cambiar editando el Dockerfile desde el que se construye la imagen. Este se encuentra en ./dockerfiles/kali. El servicio Kali instala estos dotfiles por defecto. Esto también se puede cambiar modificando el Dockerfile.

https://github.com/oliverwiegers/dotfiles

Servicios víctimas

https://github.com/bkimminich/juice-shop
https://github.com/rapid7/hackazon
https://github.com/payatu/Tiredful-API
https://owasp.org/www-project-webgoat/
https://github.com/s4n7h0/xvwa

Servicios de control

Servicios de monitoreo de Pentest Lab
Servicios de monitoreo de Pentest Lab

Aunque los servicios de monitorización también son servicios de blue_team, están divididos en una categoría diferente.

Esta pila proporciona funciones de registro y observación del rendimiento.

Para más información sobre las instancias individuales, véase más abajo.

Actualmente la configuración de la monitorización se compone de los siguientes servicios:

  • Grafana – Visualiza registros y métricas..
  • Loki – Envía los registros de Docker a Grafana.
  • Prometheus – Envía las métricas a Grafana.
  • cAdvisor – Recoge el uso de recursos de los contenedores y las métricas y las envía a Prometheus. https://github.com/google/cadvisor

Grafana

La instancia de Grafana proporciona dos tableros, uno para los registros y otro para las métricas.

Estos son bastante básicos. Se pueden añadir más tableros a través de la interfaz de Grafana. Estos tableros se perderán cuando se elimine el volumen de Grafana. Para añadir tableros de forma permanente, consulta los documentos de aprovisionamiento de Grafana. Los directorios utilizados para el aprovisionamiento se encuentran en ./etc/grafana/.

Para cambiar la configuración a través de la interfaz de Grafana hay que iniciar sesión como administrador. Las credenciales son las predeterminadas: admin:admin. #hacktheplanet

Loki

Para que Loki sea capaz de recoger los logs de Docker, este laboratorio instala el Loki Docker Driver como plugin de Docker.

Prometheus / cAdvisor

Para que Prometheus pueda acceder a las métricas de rendimiento de los contenedores que se ejecutan en el cluster se utiliza cAdvisor.

Añadir servicios

Para añadir servicios adicionales se necesita un poco de conocimiento de los archivos docker-compose.yml. El docker-compose.yml en la raíz de este repositorio se genera automáticamente cuando se inicia el laboratorio. 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

Los servicios que se iniciarán se controlan invocando ./lab.sh con las opciones correspondientes. Para desactivar permanentemente un servicio, elimina la extensión del archivo .yml.

Un ejemplo de 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 su primer uso, utiliza docker inspect <nombre_imagen> para averiguar dónde almacena los datos la imagen docker y añade un volumen que apunte a este 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 reiniciar el laboratorio y empezar completamente de nuevo puedes usar ./lab.sh -p | --prune. Esto borrará todos los recursos propiedad del laboratorio.

Rangos de IP

La razón por la que se usa 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.

  • Re team services start at 10.5.0.5
    • The Kali service has 10.5.0.5.
  • Blue team services start at 10.5.0.50
  • Victim services start at 10.5.0.100
  • Monitoring services start at 10.5.0.200
  • Los servicios de Red Team comienzan en 10.5.0.5
    • El servicio Kali tiene 10.5.0.5.
  • Los servicios de Blue team comienzan en 10.5.0.50
  • Los servicios para víctimas/Victim comienzan en 10.5.0.100
  • Los servicios de control/Monitoring comienzan en 10.5.0.200

Información sobre el servicio

Si agregas servicios y hay información adicional que es ú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 ejecutando ./lab.sh -i.

Consejos/Trucos

SSH

Para una fácil conexión al servicio Kali se puede añadir lo siguiente a $HOME/.ssh/cofig:

Host kali
    User root
    Hostname 10.5.0.5
    UserKnownHostsFile /dev/null
    StrictHostKeyChecking accept-new

Así que en lugar de:

ssh root@10.5.0.5 -o "UserKnownHostsFile /dev/null"

uno podría ejecutar ssh kali.

Para los usuarios de tmux lo siguiente se adjuntará a una sesión de tmux automáticamente:

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

También te podría interesar aprende cómo crear un Laboratorio de Pentesting para Android.

https://github.com/oliverwiegers/pentest_lab

Mi Carro Close (×)

Tu carrito está vacío
Ver tienda