clickswave/limeyardLab 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.
Un laboratoire de test de sécurité. Une flotte de cibles délibérément vulnérables, un patrimoine réseau routable avec un DNS faisant autorité pour la découverte d'actifs à énumérer, une clé de réponse lisible par machine par cible, et un panneau de contrôle pour tout piloter.
Tout ici est délibérément vulnérable. Test local uniquement. Ne l'exposez pas à Internet ni à un réseau non fiable. Les ports publiés se lient à
127.0.0.1; les cibles du labo ne se lient à rien du tout.Notre propre scanner obtient un RCE à l'intérieur de ces conteneurs à dessein, donc le conteneur est traité comme une frontière de sécurité : chaque image est épinglée par digest, chaque service abandonne toutes ses capacités et n'en rajoute qu'un minimum, et
./lime auditle fait respecter. Lisez SECURITY.md avant la première exécution, y compris la partie sur ce que l'isolation par conteneur ne couvre pas.
Le panneau de contrôle sur http://127.0.0.1:7000, montrant le labo en cours d'exécution.
limeyard était vuln_apps. Il a été renommé parce qu'il a cessé d'être un dossier
d'applications : il contient désormais des services nus, une zone DNS, une paire
de WAF, une cible de précision et des fixtures APK, dont aucun n'est une
application.
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 :
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.Vous avez besoin de Docker (avec le plugin compose) et de git. Rien d'autre.
curl -fsSL https://raw.githubusercontent.com/clickswave/limeyard/main/install.sh | bash
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 :
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 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 :
./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
À la main, sans l'installateur :
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
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.
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.| cible | une chose sous test, d'un kind déclaré. Possède un fichier compose, une configuration optionnelle, et sa propre clé de réponse. S'exécute comme son propre projet compose isolé, donc deux cibles utilisant Postgres n'en partagent jamais un |
| scénario | plusieurs cibles câblées dans une topologie réseau avec un DNS faisant autorité. Ce sur quoi la découverte d'actifs est notée |
| vérité | la clé de réponse lisible par machine. Voir truth/schema.md |
| doctor | une liste de vérifications avec un verdict chacune : environnement, attribution, chaîne d'approvisionnement, durcissement. Les vérifications avec un remède sans ambiguïté portent un correctif en un clic dans le panneau (/doctor) et --fix sur la CLI : créer des réseaux, récupérer du disque, épingler des images, récupérer les sources, revérifier les cibles en cours, réécrire les binds hors loopback. L'attribution, les conflits de ports et le durcissement nécessitent une personne |
Types : 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 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.