clickswave/limeyardLaboratorio Docker deliberatamente vulnerabile con un'infrastruttura DNS instradabile e chiavi di risposta leggibili da macchina per ogni target, valutando localmente precisione, richiamo e ambito dello scanner.
Un laboratorio di security testing. Una flotta di target deliberatamente vulnerabili, un'infrastruttura di rete instradabile con DNS autoritativo per l'asset discovery da enumerare, una answer key leggibile dalla macchina per ogni target e un pannello di controllo per gestire tutto.
Tutto qui è deliberatamente vulnerabile. Solo test locale. Non esporlo a Internet o a una rete non attendibile. Le porte pubblicate si legano a
127.0.0.1; i target del lab non si legano a nulla.Il nostro scanner ottiene RCE all'interno di questi container di proposito, quindi il container è trattato come un confine di sicurezza: ogni immagine è fissata tramite digest, ogni servizio rimuove tutte le capability e ne riaggiunge un minimo, e
./lime auditlo impone. Leggi SECURITY.md prima del primo avvio, inclusa la parte su cosa l'isolamento dei container non copre.
Il pannello di controllo su http://127.0.0.1:7000, che mostra il lab in esecuzione.
limeyard era vuln_apps. È stato rinominato perché ha smesso di essere una cartella di applicazioni: ora contiene servizi nudi, una zona DNS, una coppia di WAF, un target di precisione e fixture APK, nessuno dei quali è un'app.
La vecchia flotta totalizzava 9 su 9, zero mancati, zero falsi positivi. Un benchmark che non può fallire non può rilevare una regressione. Tre cose erano strutturalmente sbagliate:
127.0.0.1:70xx, quindi l'enumerazione dei sottodomini non aveva nulla da enumerare, il port scanning riceveva la sua risposta e il service fingerprinting non vedeva mai un demone non-HTTP.Ti servono Docker (con il plugin compose) e git. Nient'altro.
curl -fsSL https://raw.githubusercontent.com/clickswave/limeyard/main/install.sh | bash
Questo clona il lab in ./limeyard, scrive il suo .env con un nuovo API token, compila e avvia il control plane, poi chiede cosa eseguire. Prima che qualsiasi cosa parta mostra quanto costa la selezione, misurato a riposo sulla macchina di riferimento, rispetto a quanto la tua macchina ha libero:
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]
Non interattivo: curl ... | bash -s -- --light --yes (oppure --all,
--none, --pick dvwa,juice-shop,estate). Metti il checkout altrove con
LIMEYARD_DIR=/path.
Il pannello è poi su http://127.0.0.1:7000, e le stesse cose 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, senza l'installer:
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
Ogni manifest porta un blocco resources misurato (container, RAM a riposo, disco delle immagini, CPU a riposo). Il wizard, la striscia di selezione del pannello e la pagina di ogni target sommano da lì, quindi la stima è la stessa ovunque.
Due, e solo due.
main è ciò che l'installer clona e ciò che ottieni se non fai nulla.
Si muove tramite pull request, mai tramite push diretto.dev è il branch predefinito ed è dove atterra il lavoro. Apri le pull request
contro di esso.| target | una cosa sotto test, di un kind dichiarato. Possiede un file compose, un setup opzionale e la propria answer key. Viene eseguito come proprio progetto compose isolato, quindi due target che usano Postgres non ne condividono mai uno |
| scenario | diversi target collegati in una topologia di rete con DNS autoritativo. È ciò contro cui viene valutata l'asset discovery |
| truth | la answer key leggibile dalla macchina. Vedi truth/schema.md |
| doctor | un unico elenco di controlli con un verdetto ciascuno: ambiente, attribuzione, supply chain, hardening. I controlli con un rimedio inequivocabile portano un fix con un clic nel pannello (/doctor) e --fix sulla CLI: crea reti, recupera disco, fissa immagini, scarica sorgenti, ri-verifica i target in esecuzione, riscrive i bind fuori dal loopback. Attribuzione, conflitti di porte e hardening richiedono una persona |
Tipi: 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 avvia due container e nient'altro: limeyard_control
(il demone limed, che detiene il socket Docker) e limeyard_ui (il pannello
SvelteKit). Entrambi si legano solo al loopback. Il pannello è su http://127.0.0.1:7000 e
l'API grezza su http://127.0.0.1:7099. Entrambi richiedono .env, e LIME_TOKEN al suo interno è
obbligatorio: il pannello detiene il token lato server e il browser non lo vede mai.
| pagina | a cosa serve |
|---|---|
| Targets | ogni target, filtra per tipo e stato, ordina, selezione multipla con Start, Stop, Restart. Clicca una riga per il target |
| Target | fatti (indirizzo, credenziali, stack, upstream, verifica, digest delle immagini), il log live e la answer key con i suoi negativi |
| Scenarios | l'estate: resolver, zone, subnet e una tabella degli host con lo stato per container. Avvia, ferma, riavvia |
| Scorecard | l'ultima esecuzione con i delta, copertura per classe e per target, id mancati, uno storico consultabile e un diff tra due esecuzioni |
| Ports | cosa si lega su localhost e cosa esiste solo sul bridge del lab |
| Doctor | un unico elenco di controlli con un verdetto ciascuno. Fix e Fix all mostrano prima i comandi esatti e le modifiche ai file, calcolati dal lab così com'è, e li eseguono alla conferma. Un fix che lascia il suo controllo fallito lo dice |
| Credits | chi ha scritto ogni target e sotto quale licenza |