limeyard

Laboratorio 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.

Perché è cambiato

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:

• Tre dei cinque motori non avevano ground truth. Ogni app era 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.
• 11 dei 101 template di detection erano stati attivati. Gli altri 90 venivano distribuiti senza alcun tipo di target live.
• Nulla misurava la precisione. Ogni target era genuinamente vulnerabile, quindi "zero falsi positivi" era non falsificabile.

Avvio rapido

Ti servono Docker (con il plugin compose) e git. Nient'altro.

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:

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:

A mano, senza l'installer:

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.

Branch

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.

Concetti

Tipi: web api bench cve service estate edge control mobile.

Struttura

Pannello di controllo

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.

Il pannello si aggiorna da solo: limed trasmette le transizioni di stato via SSE, quindi un target avviato dalla CLI compare senza refresh. L'intestazione porta la CPU, la RAM e il disco libero dell'host dallo stesso stream, colorati solo quando vale la pena notarli. Ogni tabella si ordina cliccando l'intestazione di una colonna; un secondo clic inverte la direzione.

Dopo una modifica al pannello o al demone, ricompila la coppia:

Per lavorare sul pannello contro un demone in esecuzione senza ricompilare l'immagine:

API

Ogni chiamata tranne /api/health richiede X-Lime-Token.

Reti

Tre livelli, perché uno solo era il problema originale.

• lime-web bridge. Target web e API, pubblicati su 127.0.0.1:70xx.
• lime-lab bridge, 10.66.0.0/16, IP statici, nessun binding sull'host. Uno scanner si unisce a questa rete come container e vede una vera subnet con veri host e vere porte invece di un elenco di porte su loopback.
• lime-edge il livello WAF, con l'origin raggiungibile ma assente dal DNS.

Il DNS è BIND autoritativo su zone .test (la RFC 6761 la riserva). Gli alias di rete Docker deliberatamente non sono la fonte di verità: non compaiono mai in un zone transfer e farebbero divergere la topologia dalla answer key.

Porte

Scoring

Ogni target distribuisce un truth.yml. Lo scorer trasforma i finding in precision, recall e F1, per target e per classe:

Si contano tre cose, non una. Recall: abbiamo trovato ciò che c'è. Precision: abbiamo evitato di segnalare ciò che non c'è, misurato rispetto alle voci negative che ogni answer key porta. Scope: ciò che correttamente non abbiamo tentato, registrato così nessuno lo rimette in discussione ogni trimestre.

Il target mirage esiste solo per il secondo. Nulla in esso è vulnerabile e tutto in esso sembra esserlo, quindi qualsiasi finding contro di esso è un falso positivo per costruzione.

Contribuire

CONTRIBUTING.md contiene tutto: cos'è di solito un contributo, le invarianti che ./lime audit impone e perché una correzione a una answer key vale più qui di una nuova funzionalità. La versione breve delle regole è qui sotto. Tutti coloro che partecipano sono tenuti al code of conduct.

Aggiungere un target

Regole che mantengono il lab pulito:

• Lega solo la porta del target, a 127.0.0.1.
• I target a container singolo si uniscono solo a [lime-web]. Non aggiungere una rete per progetto: troppe reti e Docker esaurisce il pool di indirizzi.
• I target con un database si uniscono a [default, lime-web] e mettono il database su [default] soltanto. Ogni target ottiene il proprio servizio database e volume.
• I target che esistono per essere scoperti anziché navigati si uniscono a [lime-lab] con un IP statico e non pubblicano alcuna porta sull'host.
• upstream è obbligatorio. lime doctor fa fallire un target senza di esso e il manager rifiuta di registrarne uno. Vedi sotto.
• limeyard non include sorgenti di terze parti. Metti repo: e compose: nel manifest e il sorgente viene scaricato a runtime in <target>/src.
• Registra quanto costa. Avvialo, lascialo assestare e ./lime measure <slug> stampa il blocco resources da incollare. L'installer e il pannello sommano questi per avvisare qualcuno prima che lo avvii, quindi una stima qui è una bugia là.

Fiducia e isolamento

I target sono software deliberatamente vulnerabile di altre persone, quindi la provenienza è registrata anziché presunta, e il runtime è vincolato anziché fidato. SECURITY.md ha il quadro completo; la versione breve:

• Ogni immagine è fissata tramite digest, non un tag mobile, al digest che è stato scaricato e testato qui. ./lime pin segnala la deriva.
• Gli editori sono documentati per immagine: Docker Official Images, account di organizzazioni di progetto (OWASP, ISC, Traefik, Prometheus) o il namespace dell'autore stesso. I due anelli più deboli, raesene/bwapp (archiviato, ultima ricostruzione 2022, nessuna licenza) e delfer/alpine-ftp-server (un singolo individuo), sono indicati come tali.
• Ogni servizio viene eseguito con no-new-privileges, cap_drop: ALL più un minimo cap_add per immagine, un tetto di pid e un tetto di memoria. I livelli database stanno su reti internal: true senza route verso l'esterno.
• limed detiene il socket Docker, che è root sull'host, quindi richiede un segreto condiviso su ogni chiamata. Un target compromesso può raggiungerlo e non apprendere nulla.
• ./lime audit fallisce su privileged, host networking, un mount del socket in un target, un bind fuori dal loopback, un'immagine non fissata o un token mancante.

Nulla qui difende da un container escape a livello di kernel. Per quello, usa una VM usa e getta.

Attribuzione

Quasi tutto qui è stato scritto da qualcun altro, e diversi target non dichiarano alcuna licenza. Quindi accreditare l'autore è un gate obbligatorio, non una convenzione:

• target.yml porta un blocco upstream obbligatorio: autore, repo, licenza e la data in cui abbiamo verificato l'ultima volta che compila. packager registra la persona che ha containerizzato qualcosa quando differisce da chi l'ha scritto.
• Ogni scheda della dashboard mostra l'autore sotto il nome del target, collegato alla fonte, con la licenza accanto. Una licenza none declared viene resa come un avviso, che è anche il segnale di non-ridistribuzione.
• La vista di dettaglio di ogni target si apre con un blocco di credito, sopra la lista delle vulnerabilità, con la nostra answer key chiaramente separata dalla documentazione di upstream.
• /credits nella UI e ./lime credits elencano ogni target, autore e licenza. ./lime credits --markdown rigenera la sezione qui sotto.

Crediti

limeyard esegue il lavoro di altre persone. Ogni target e scenario qui sotto è stato costruito da qualcun altro a meno che non dica Clickswave.

api

bench

control

cve

edge

mobile

scenario

service

web