limeyard

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.

Warum es sich geändert hat

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:

• Drei von fünf Engines hatten keine Ground Truth. Jede App war 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.
• 11 von 101 Detection-Templates hatten jemals ausgelöst. Die anderen 90 wurden ohne jegliches Live-Ziel ausgeliefert.
• Nichts maß Präzision. Jedes Ziel war tatsächlich verwundbar, also war „null Falsch-Positive" unfalsifizierbar.

Schnellstart

Du brauchst Docker (mit dem Compose-Plugin) und git. Sonst nichts.

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:

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:

Von Hand, ohne den Installer:

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.

Branches

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.

Konzepte

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

Layout

Bedienfeld

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.

Das Panel aktualisiert sich selbst: limed streamt Zustandsübergänge über SSE, sodass ein von der CLI gestartetes Ziel ohne Aktualisierung erscheint. Der Header trägt die CPU, den RAM und die freie Festplatte des Hosts aus demselben Stream, eingefärbt nur, wenn sie es wert sind, bemerkt zu werden. Jede Tabelle sortiert durch Klicken auf einen Spaltenkopf; ein zweiter Klick kehrt die Richtung um.

Nach einer Änderung am Panel oder am Daemon, baue das Paar neu:

Um am Panel gegen einen laufenden Daemon zu arbeiten, ohne das Image neu zu bauen:

API

Jeder Aufruf außer /api/health braucht X-Lime-Token.

Netzwerke

Drei Tiers, weil eines das ursprüngliche Problem war.

• lime-web Bridge. Web- und API-Ziele, veröffentlicht auf 127.0.0.1:70xx.
• lime-lab Bridge, 10.66.0.0/16, statische IPs, keine Host-Bindung. Ein Scanner tritt diesem Netzwerk als Container bei und sieht ein echtes Subnetz mit echten Hosts und echten Ports statt einer Loopback-Portliste.
• lime-edge der WAF-Tier, mit erreichbarem Origin, aber abwesend aus DNS.

DNS ist autoritatives BIND auf .test-Zonen (RFC 6761 reserviert es). Docker-Netzwerk- Aliase sind absichtlich nicht die Quelle der Wahrheit: Sie erscheinen nie in einer Zonen- Übertragung und würden die Topologie mit dem Lösungsschlüssel in Widerspruch bringen.

Ports

Bewertung

Jedes Ziel liefert eine truth.yml. Der Scorer verwandelt Findings in Präzision, Recall und F1, pro Ziel und pro Klasse:

Drei Dinge werden gezählt, nicht eines. Recall: Haben wir gefunden, was da ist. Präzision: Haben wir vermieden zu melden, was nicht da ist, gemessen an den negative-Einträgen, die jeder Lösungsschlüssel trägt. Scope: Was wir korrekt nicht versucht haben, festgehalten, damit es niemand jedes Quartal neu aufrollt.

Das mirage-Ziel existiert nur für das zweite. Nichts darin ist verwundbar und alles darin sieht so aus, als wäre es das, also ist jedes Finding dagegen ein Falsch- Positiv durch Konstruktion.

Mitwirken

CONTRIBUTING.md enthält das Ganze: was ein Beitrag üblicherweise ist, die Invarianten, die ./lime audit erzwingt, und warum eine Korrektur eines Lösungsschlüssels hier mehr wert ist als ein neues Feature. Die Kurzfassung der Regeln steht unten. Alle Teilnehmenden sind an den Verhaltenskodex gebunden.

Ein Ziel hinzufügen

Regeln, die das Labor sauber halten:

• Binde nur den Zielport, an 127.0.0.1.
• Einzelcontainer-Ziele treten nur [lime-web] bei. Füge kein projektbezogenes Netzwerk hinzu: zu viele Netzwerke und Docker geht der Adresspool aus.
• Ziele mit einer Datenbank treten [default, lime-web] bei und platzieren die Datenbank nur auf [default]. Jedes Ziel bekommt seinen eigenen Datenbankdienst und sein eigenes Volume.
• Ziele, die existieren, um entdeckt statt durchsucht zu werden, treten [lime-lab] mit einer statischen IP bei und veröffentlichen keinen Host-Port.
• upstream ist obligatorisch. lime doctor lässt ein Ziel ohne es durchfallen und der Manager weigert sich, eines zu registrieren. Siehe unten.
• limeyard vendort keinen Drittanbieter-Quellcode. Setze repo: und compose: ins Manifest und die Quelle wird zur Laufzeit nach <target>/src abgerufen.
• Halte fest, was es kostet. Starte es, lass es sich einpendeln, und ./lime measure <slug> gibt den resources-Block zum Einfügen aus. Der Installer und das Panel addieren diese, um jemanden zu warnen, bevor er es startet, also ist eine Schätzung hier eine Lüge dort.

Vertrauen und Isolation

Ziele sind absichtlich verwundbare Software anderer Leute, also wird die Herkunft festgehalten statt angenommen, und die Laufzeit wird eingeschränkt statt vertraut. SECURITY.md enthält das vollständige Bild; die Kurzfassung:

• Jedes Image ist per Digest gepinnt, nicht ein schwebendes Tag, auf den Digest, der hier gezogen und getestet wurde. ./lime pin meldet Drift.
• Publisher sind pro Image dokumentiert: Docker Official Images, Projekt- Organisationskonten (OWASP, ISC, Traefik, Prometheus) oder der eigene Namespace des Autors. Die zwei schwächsten Glieder, raesene/bwapp (archiviert, zuletzt neu gebaut 2022, keine Lizenz) und delfer/alpine-ftp-server (eine Einzelperson), werden als solche benannt.
• Jeder Dienst läuft mit no-new-privileges, cap_drop: ALL plus einem minimalen cap_add pro Image, einer PID-Obergrenze und einer Speicherobergrenze. Datenbank-Tiers sitzen auf internal: true-Netzwerken ohne Route nach draußen.
• limed hält den Docker-Socket, was root auf dem Host ist, also verlangt es ein gemeinsames Geheimnis bei jedem Aufruf. Ein gekapertes Ziel kann es erreichen und nichts erfahren.
• ./lime audit schlägt fehl bei privileged, Host-Netzwerk, einem Socket-Mount in einem Ziel, einem Off-Loopback-Bind, einem ungepinnten Image oder einem fehlenden Token.

Nichts hier verteidigt gegen eine Container-Escape auf Kernel-Ebene. Dafür nutze eine Wegwerf-VM.

Attribution

Fast alles hier wurde von jemand anderem geschrieben, und mehrere Ziele deklarieren überhaupt keine Lizenz. Also ist das Nennen des Autors ein hartes Gate, keine Konvention:

• target.yml trägt einen erforderlichen upstream-Block: Autor, Repo, Lizenz und das Datum, an dem wir zuletzt verifiziert haben, dass es baut. packager hält die Person fest, die etwas containerisiert hat, wenn das von der Person abweicht, die es geschrieben hat.
• Jede Dashboard-Karte zeigt den Autor unter dem Zielnamen, verlinkt zur Quelle, mit der Lizenz daneben. Eine Lizenz von none declared wird als Warnung dargestellt, was auch das Nicht-Weiterverbreiten-Signal ist.
• Die Detailansicht jedes Ziels öffnet mit einem Credit-Block, über der Schwachstellenliste, mit unserem Lösungsschlüssel klar getrennt von den eigenen Docs des Upstreams.
• /credits in der UI und ./lime credits listen jedes Ziel, jeden Autor und jede Lizenz auf. ./lime credits --markdown regeneriert den Abschnitt unten.

Credits

limeyard führt die Arbeit anderer aus. Jedes Ziel und Szenario unten wurde von jemand anderem gebaut, sofern es nicht Clickswave sagt.

api

bench

control

cve

edge

mobile

scenario

service

web