Absichtlich verwundbares Docker-Lab mit einem routbaren DNS-Bestand und maschinenlesbaren Antwortschlüsseln pro Ziel, das die Präzision, Trefferquote und den Umfang von Scannern lokal bewertet.
Ein Sicherheitstest-Labor. Eine Flotte absichtlich verwundbarer Ziele, ein routingfähiges Netzwerk-Ensemble mit autoritativem DNS zur Asset-Erkennung zum Aufzählen, ein maschinenlesbarer Lösungsschlüssel pro Ziel und ein Bedienfeld, um alles zu steuern.
Alles hier ist absichtlich verwundbar. Nur lokales Testen. Nicht ins Internet oder ein nicht vertrauenswürdiges Netzwerk exponieren. Veröffentlichte Ports binden an
127.0.0.1; Laborziele binden an gar nichts.Unser eigener Scanner erhält absichtlich RCE innerhalb dieser Container, daher wird der Container als Sicherheitsgrenze behandelt: jedes Image ist per Digest gepinnt, jeder Dienst verwirft alle Capabilities und fügt ein Minimum wieder hinzu, und
./lime auditerzwingt dies. Lies SECURITY.md vor dem ersten Start, einschließlich des Teils darüber, was Container-Isolation nicht abdeckt.
Das Bedienfeld auf http://127.0.0.1:7000, das das Labor im laufenden Betrieb zeigt.
limeyard war vuln_apps. Es wurde umbenannt, weil es aufgehört hat, ein Ordner von
Anwendungen zu sein: Es enthält jetzt nackte Dienste, eine DNS-Zone, ein WAF-Paar, ein Präzisionsziel
und APK-Fixtures, von denen keines Apps sind.
Die alte Flotte erzielte 9 von 9, null Fehlschläge, null Falsch-Positive. Ein Benchmark, der nicht fehlschlagen kann, kann keine Regression erkennen. Drei Dinge waren strukturell falsch:
127.0.0.1:70xx,
also hatte Subdomain-Enumeration nichts aufzuzählen, Port-Scanning bekam
seine Antwort geliefert, und Service-Fingerprinting sah nie einen Nicht-HTTP-Daemon.Du brauchst Docker (mit dem Compose-Plugin) und git. Sonst nichts.
curl -fsSL https://raw.githubusercontent.com/clickswave/limeyard/main/install.sh | bash
Das klont das Labor nach ./limeyard, schreibt seine .env mit einem frischen API-
Token, baut und startet die Control Plane und fragt dann, was ausgeführt werden soll. Bevor
irgendetwas startet, zeigt es, was die Auswahl kostet, gemessen im Leerlauf auf der
Referenzbox, gegen das, was deine Maschine frei hat:
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]
Nicht-interaktiv: curl ... | bash -s -- --light --yes (oder --all,
--none, --pick dvwa,juice-shop,estate). Lege den Checkout woanders ab mit
LIMEYARD_DIR=/path.
Das Panel ist dann unter http://127.0.0.1:7000, und dieselben Dinge von Hand:
./lime setup # der Assistent erneut, jederzeit
./lime start --all # jedes leichte Ziel
./lime start crapi --heavy # ein schweres, explizit
./lime scenario-up estate # das Netzwerk-Ensemble: DNS, vhosts, Dienste
./lime status # was läuft
./lime stop --all --heavy # alles herunterfahren; Images und Volumes bleiben
./lime credits # wer jedes Ziel geschrieben hat, und unter welcher Lizenz
./lime doctor # Umgebungs-, Attributions- und Festplattenprüfungen
./lime doctor --fix # jede automatische Abhilfe der Prüfungen anwenden, dann erneut prüfen
./lime audit # Container-Hardening + Supply-Chain-Invarianten
./lime pin # Image-Drift gegen die Registry melden
Von Hand, ohne den 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 # erforderlich, siehe SECURITY.md
docker compose up -d --build # Control Plane + UI auf http://127.0.0.1:7000
./lime setup
Jedes Manifest trägt einen gemessenen resources-Block (Container, Leerlauf-RAM,
Image-Festplatte, Leerlauf-CPU). Der Assistent, der Auswahlstreifen des Panels und die
Seite jedes Ziels summieren daraus, sodass die Schätzung überall dieselbe ist.
Zwei, und nur zwei.
main ist das, was der Installer klont und was du bekommst, wenn du nichts tust.
Es bewegt sich per Pull Request, niemals per direktem Push.dev ist der Standard-Branch und wo Arbeit landet. Öffne Pull Requests
dagegen.| target | eine Sache unter Test, von einer deklarierten kind. Besitzt eine Compose-Datei, optionales Setup und ihren eigenen Lösungsschlüssel. Läuft als eigenes isoliertes Compose-Projekt, sodass zwei Ziele, die Postgres verwenden, nie eines teilen |
| scenario | mehrere Ziele, die in eine Netzwerktopologie mit autoritativem DNS verdrahtet sind. Woran Asset-Erkennung gemessen wird |
| truth | der maschinenlesbare Lösungsschlüssel. Siehe truth/schema.md |
| doctor | eine Liste von Prüfungen mit jeweils einem Urteil: Umgebung, Attribution, Supply Chain, Hardening. Prüfungen mit einer eindeutigen Abhilfe tragen einen Ein-Klick-Fix im Panel (/doctor) und --fix auf der CLI: Netzwerke erstellen, Festplatte zurückgewinnen, Images pinnen, Quellen abrufen, laufende Ziele erneut verifizieren, Off-Loopback-Binds umschreiben. Attribution, Portkonflikte und Hardening brauchen einen Menschen |
Arten: 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/ der Daemon: CLI + HTTP API + Scorer
control/ui/ das SvelteKit-Bedienfeld
truth/ der Vertrag, und datierte Scorecards
docker compose up -d startet zwei Container und sonst nichts: limeyard_control
(der limed-Daemon, der den Docker-Socket hält) und limeyard_ui (das SvelteKit-
Panel). Beide binden nur an Loopback. Das Panel ist unter http://127.0.0.1:7000 und die
rohe API unter http://127.0.0.1:7099. Beide brauchen .env, und LIME_TOKEN darin ist
obligatorisch: Das Panel hält das Token serverseitig und der Browser sieht es nie.