clickswave/limeyardLaboratorio Docker deliberadamente vulnerable con un dominio DNS enrutable y claves de respuesta legibles por máquina por objetivo, que puntúa localmente la precisión, la exhaustividad y el alcance del escáner.
Un laboratorio de pruebas de seguridad. Una flota de objetivos deliberadamente vulnerables, un entorno de red enrutable con DNS autoritativo para el descubrimiento de activos que enumerar, una clave de respuestas legible por máquina por objetivo y un panel de control para gestionarlo todo.
Todo aquí es deliberadamente vulnerable. Solo para pruebas locales. No lo expongas a internet ni a una red no confiable. Los puertos publicados se enlazan a
127.0.0.1; los objetivos del laboratorio no se enlazan a nada en absoluto.Nuestro propio escáner obtiene RCE dentro de estos contenedores a propósito, por lo que el contenedor se trata como un límite de seguridad: cada imagen está fijada por digest, cada servicio elimina todas las capacidades y añade de vuelta un mínimo, y
./lime auditlo hace cumplir. Lee SECURITY.md antes de la primera ejecución, incluida la parte sobre lo que el aislamiento de contenedores no cubre.
El panel de control en http://127.0.0.1:7000, mostrando el laboratorio mientras se ejecuta.
limeyard era vuln_apps. Se renombró porque dejó de ser una carpeta de
aplicaciones: ahora contiene servicios desnudos, una zona DNS, un par de WAF, un objetivo de precisión
y fixtures de APK, ninguno de los cuales son aplicaciones.
La flota antigua puntuaba 9 de 9, cero fallos, cero falsos positivos. Un benchmark que no puede fallar no puede detectar una regresión. Tres cosas estaban mal estructuralmente:
127.0.0.1:70xx,
así que la enumeración de subdominios no tenía nada que enumerar, el escaneo de puertos recibía
su respuesta, y el fingerprinting de servicios nunca veía un demonio no HTTP.Necesitas Docker (con el plugin compose) y git. Nada más.
curl -fsSL https://raw.githubusercontent.com/clickswave/limeyard/main/install.sh | bash
Eso clona el laboratorio en ./limeyard, escribe su .env con un token de API
nuevo, construye e inicia el plano de control, y luego pregunta qué ejecutar. Antes de
que empiece nada muestra cuánto cuesta la selección, medido en reposo en la
máquina de referencia, frente a lo que tu máquina tiene libre:
This selection, idle, on the box it was measured on:
17 targets, 1 scenarios, 45 containers
RAM about 2.9 GB resident (host has 22.4 GB available)
disk about 11.0 GB of images to pull (host has 111 GB free)
CPU near idle once up (3% of one core); pulling and first boots are the busy part
Start it? [y/N]
No interactivo: curl ... | bash -s -- --light --yes (o --all,
--none, --pick dvwa,juice-shop,estate). Coloca el checkout en otro lugar con
LIMEYARD_DIR=/path.
El panel está entonces en http://127.0.0.1:7000, y las mismas cosas a mano:
./lime setup # the wizard again, any time
./lime start --all # every light target
./lime start crapi --heavy # a heavy one, explicitly
./lime scenario-up estate # the network estate: DNS, vhosts, services
./lime status # what is up
./lime stop --all --heavy # everything down; images and volumes stay
./lime credits # who wrote each target, and under what licence
./lime doctor # environment, attribution and disk checks
./lime doctor --fix # apply every check's automatic remedy, then re-check
./lime audit # container hardening + supply chain invariants
./lime pin # report image drift against the registry
A mano, sin el instalador:
git clone https://github.com/clickswave/limeyard && cd limeyard
cp .env.example .env
echo "LIMEYARD_DIR=$PWD" >> .env
echo "LIME_TOKEN=$(openssl rand -hex 24)" >> .env # required, see SECURITY.md
docker compose up -d --build # control plane + UI on http://127.0.0.1:7000
./lime setup
Cada manifiesto lleva un bloque resources medido (contenedores, RAM en reposo,
disco de imágenes, CPU en reposo). El asistente, la franja de selección del panel y la página de cada
objetivo suman a partir de él, así que la estimación es la misma en todas partes.
Dos, y solo dos.
main es lo que clona el instalador y lo que obtienes si no haces nada.
Se mueve por pull request, nunca por push directo.dev es la rama por defecto y donde aterriza el trabajo. Abre pull requests
contra ella.| target | una cosa bajo prueba, de un kind declarado. Posee un archivo compose, setup opcional, y su propia clave de respuestas. Se ejecuta como su propio proyecto compose aislado, así que dos objetivos que usan Postgres nunca comparten uno |
| scenario | varios objetivos conectados en una topología de red con DNS autoritativo. Contra lo que se puntúa el descubrimiento de activos |
| truth | la clave de respuestas legible por máquina. Ver truth/schema.md |
| doctor | una lista de comprobaciones con un veredicto cada una: entorno, atribución, cadena de suministro, hardening. Las comprobaciones con un remedio inequívoco llevan un arreglo de un clic en el panel (/doctor) y --fix en la CLI: crear redes, reclamar disco, fijar imágenes, obtener fuentes, reverificar objetivos en ejecución, reescribir enlaces fuera de loopback. La atribución, los conflictos de puertos y el hardening necesitan una persona |
Kinds: web api bench cve service estate edge control mobile.
targets/<kind>/<slug>/ target.yml, compose.yml, setup.sh, truth.yml
scenarios/<slug>/ scenario.yml, compose.yml, zones/
control/limed/ the daemon: CLI + HTTP API + scorer
control/ui/ the SvelteKit control panel
truth/ the contract, and dated scorecards
docker compose up -d inicia dos contenedores y nada más: limeyard_control
(el demonio limed, que sostiene el socket de Docker) y limeyard_ui (el panel
SvelteKit). Ambos se enlazan solo a loopback. El panel está en http://127.0.0.1:7000 y la
API cruda en http://127.0.0.1:7099. Ambos necesitan .env, y LIME_TOKEN en él es
obligatorio: el panel sostiene el token del lado del servidor y el navegador nunca lo ve.