limeyard

Lab Docker délibérément vulnérable avec un parc DNS routable et des clés de réponse lisibles par machine par cible, évaluant localement la précision, le rappel et la portée du scanner.

Pourquoi il a changé

L'ancienne flotte obtenait 9 sur 9, zéro manque, zéro faux positif. Un benchmark qui ne peut pas échouer ne peut pas détecter une régression. Trois choses étaient structurellement erronées :

• Trois des cinq moteurs n'avaient pas de vérité terrain. Chaque application était 127.0.0.1:70xx, donc l'énumération de sous-domaines n'avait rien à énumérer, le scan de ports recevait sa réponse, et le fingerprinting de services ne voyait jamais de démon non-HTTP.
• 11 des 101 modèles de détection s'étaient déjà déclenchés. Les 90 autres étaient livrés sans aucune cible live, de quelque nature que ce soit.
• Rien ne mesurait la précision. Chaque cible était réellement vulnérable, donc « zéro faux positif » était infalsifiable.

Démarrage rapide

Vous avez besoin de Docker (avec le plugin compose) et de git. Rien d'autre.

Cela clone le labo dans ./limeyard, écrit son .env avec un nouveau jeton d'API, construit et démarre le plan de contrôle, puis demande quoi exécuter. Avant que quoi que ce soit ne démarre, il montre ce que coûte la sélection, mesuré au repos sur la machine de référence, par rapport à ce que votre machine a de libre :

Non interactif : curl ... | bash -s -- --light --yes (ou --all, --none, --pick dvwa,juice-shop,estate). Placez le checkout ailleurs avec LIMEYARD_DIR=/path.

Le panneau est alors sur http://127.0.0.1:7000, et les mêmes choses à la main :

À la main, sans l'installateur :

Chaque manifeste porte un bloc resources mesuré (conteneurs, RAM au repos, disque des images, CPU au repos). L'assistant, la bande de sélection du panneau et la page de chaque cible en font la somme, donc l'estimation est la même partout.

Branches

Deux, et seulement deux.

• main est ce que l'installateur clone et ce que vous obtenez si vous ne faites rien. Elle avance par pull request, jamais par push direct.
• dev est la branche par défaut et là où le travail atterrit. Ouvrez les pull requests contre elle.

Concepts

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

Arborescence

Panneau de contrôle

docker compose up -d démarre deux conteneurs et rien d'autre : limeyard_control (le démon limed, qui détient le socket Docker) et limeyard_ui (le panneau SvelteKit). Les deux se lient uniquement au loopback. Le panneau est sur http://127.0.0.1:7000 et l'API brute sur http://127.0.0.1:7099. Les deux nécessitent .env, et LIME_TOKEN dedans est obligatoire : le panneau détient le jeton côté serveur et le navigateur ne le voit jamais.

Le panneau se met à jour tout seul : limed diffuse les transitions d'état via SSE, donc une cible démarrée depuis la CLI apparaît sans rafraîchissement. L'en-tête porte le CPU, la RAM et le disque libre de l'hôte depuis le même flux, colorés uniquement quand ils méritent d'être remarqués. Chaque table se trie en cliquant sur un en-tête de colonne ; un second clic inverse la direction.

Après une modification du panneau ou du démon, reconstruisez la paire :

Pour travailler sur le panneau contre un démon en cours d'exécution sans reconstruire l'image :

API

Chaque appel sauf /api/health nécessite X-Lime-Token.

Réseaux

Trois niveaux, parce qu'un seul était le problème d'origine.

• lime-web bridge. Cibles web et API, publiées sur 127.0.0.1:70xx.
• lime-lab bridge, 10.66.0.0/16, IP statiques, aucune liaison à l'hôte. Un scanner rejoint ce réseau en tant que conteneur et voit un vrai sous-réseau avec de vrais hôtes et de vrais ports au lieu d'une liste de ports loopback.
• lime-edge le niveau WAF, avec l'origine joignable mais absente du DNS.

Le DNS est un BIND faisant autorité sur les zones .test (la RFC 6761 la réserve). Les alias de réseau Docker ne sont délibérément pas la source de vérité : ils n'apparaissent jamais dans un transfert de zone, et feraient diverger la topologie de la clé de réponse.

Ports

Notation

Chaque cible livre un truth.yml. Le scorer transforme les findings en précision, rappel et F1, par cible et par classe :

Trois choses sont comptées, pas une. Rappel : avons-nous trouvé ce qui est là. Précision : avons-nous évité de signaler ce qui n'y est pas, mesuré par rapport aux entrées negative que porte chaque clé de réponse. Périmètre : ce que nous n'avons correctement pas tenté, enregistré pour que personne ne le remette en question chaque trimestre.

La cible mirage n'existe que pour la seconde. Rien en elle n'est vulnérable et tout en elle ressemble à ce qui l'est, donc tout finding contre elle est un faux positif par construction.

Contribuer

CONTRIBUTING.md contient tout : ce qu'est habituellement une contribution, les invariants que ./lime audit fait respecter, et pourquoi une correction d'une clé de réponse vaut plus ici qu'une nouvelle fonctionnalité. La version courte des règles est ci-dessous. Toute personne participant est tenue au code de conduite.

Ajouter une cible

Règles qui gardent le labo propre :

• Ne liez que le port de la cible, à 127.0.0.1.
• Les cibles mono-conteneur rejoignent [lime-web] uniquement. N'ajoutez pas de réseau par projet : trop de réseaux et Docker épuise son pool d'adresses.
• Les cibles avec une base de données rejoignent [default, lime-web] et placent la base de données sur [default] uniquement. Chaque cible obtient son propre service de base de données et son volume.
• Les cibles qui existent pour être découvertes plutôt que parcourues rejoignent [lime-lab] avec une IP statique et ne publient aucun port hôte.
• upstream est obligatoire. lime doctor fait échouer une cible sans lui et le gestionnaire refuse d'en enregistrer une. Voir ci-dessous.
• limeyard ne vend aucune source tierce. Mettez repo: et compose: dans le manifeste et la source est récupérée à l'exécution dans <target>/src à la place.
• Enregistrez ce que ça coûte. Démarrez-la, laissez-la se stabiliser, et ./lime measure <slug> affiche le bloc resources à coller. L'installateur et le panneau additionnent ces valeurs pour avertir quelqu'un avant qu'il ne la démarre, donc une estimation ici est un mensonge là-bas.

Confiance et isolation

Les cibles sont le logiciel délibérément vulnérable d'autres personnes, donc la provenance est enregistrée plutôt que supposée, et le runtime est contraint plutôt que de confiance. SECURITY.md contient le tableau complet ; la version courte :

• Chaque image est épinglée par digest, pas une étiquette flottante, au digest qui a été tiré et testé ici. ./lime pin signale la dérive.
• Les éditeurs sont documentés par image : Docker Official Images, comptes d'organisation de projet (OWASP, ISC, Traefik, Prometheus), ou l'espace de noms propre de l'auteur. Les deux maillons les plus faibles, raesene/bwapp (archivé, dernière reconstruction 2022, aucune licence) et delfer/alpine-ftp-server (un individu), sont nommés comme tels.
• Chaque service s'exécute avec no-new-privileges, cap_drop: ALL plus un minimum de cap_add par image, un plafond de pid et un plafond de mémoire. Les niveaux de base de données reposent sur des réseaux internal: true sans route vers l'extérieur.
• limed détient le socket Docker, qui est root sur l'hôte, donc il exige un secret partagé à chaque appel. Une cible compromise peut l'atteindre et n'apprendre rien.
• ./lime audit échoue sur privileged, le réseau hôte, un montage de socket dans une cible, un bind hors loopback, une image non épinglée ou un jeton manquant.

Rien ici ne défend contre une évasion de conteneur au niveau du noyau. Pour cela, utilisez une VM jetable.

Attribution

Presque tout ici a été écrit par quelqu'un d'autre, et plusieurs cibles ne déclarent aucune licence. Donc créditer l'auteur est un verrou strict, pas une convention :

• target.yml porte un bloc upstream obligatoire : auteur, repo, licence, et la date à laquelle nous avons vérifié pour la dernière fois qu'il se construit. packager enregistre la personne qui a conteneurisé quelque chose quand cela diffère de qui l'a écrit.
• Chaque carte du tableau de bord affiche l'auteur sous le nom de la cible, lié à la source, avec la licence à côté. Une licence de none declared s'affiche comme un avertissement, ce qui est aussi le signal de ne-pas-redistribuer.
• La vue détaillée de chaque cible s'ouvre sur un bloc de crédit, au-dessus de la liste des vulnérabilités, avec notre clé de réponse clairement séparée des docs propres de l'upstream.
• /credits dans l'UI et ./lime credits listent chaque cible, auteur et licence. ./lime credits --markdown régénère la section ci-dessous.

Crédits

limeyard exécute le travail d'autres personnes. Chaque cible et scénario ci-dessous a été construit par quelqu'un d'autre sauf mention de Clickswave.

api

bench

control

cve

edge

mobile

scenario

service

web