जानबूझकर कमजोर Docker लैब, जिसमें एक रूटेबल DNS एस्टेट और प्रत्येक लक्ष्य के लिए मशीन-पठनीय उत्तर कुंजियाँ हैं, जो स्कैनर की सटीकता, रिकॉल और दायरे को स्थानीय रूप से स्कोर करती है।
एक सुरक्षा परीक्षण लैब। जानबूझकर कमजोर बनाए गए लक्ष्यों का एक बेड़ा, संपत्ति खोज के लिए प्राधिकृत DNS वाला एक रूटेबल नेटवर्क एस्टेट जिसे प्रगणित किया जा सके, प्रत्येक लक्ष्य के लिए एक मशीन-पठनीय उत्तर कुंजी, और इन सबको चलाने के लिए एक नियंत्रण पैनल।
यहाँ सब कुछ जानबूझकर कमजोर है। केवल स्थानीय परीक्षण। इसे इंटरनेट या किसी अविश्वसनीय नेटवर्क पर उजागर न करें। प्रकाशित पोर्ट
127.0.0.1पर बाइंड होते हैं; लैब लक्ष्य बिल्कुल भी बाइंड नहीं होते।हमारा अपना स्कैनर इन कंटेनरों के अंदर जानबूझकर RCE प्राप्त करता है, इसलिए कंटेनर को एक सुरक्षा सीमा माना जाता है: प्रत्येक इमेज डाइजेस्ट द्वारा पिन की गई है, प्रत्येक सेवा सभी क्षमताएँ छोड़ती है और न्यूनतम वापस जोड़ती है, और
./lime auditइसे लागू करता है। पहले रन से पहले SECURITY.md पढ़ें, जिसमें कंटेनर आइसोलेशन क्या कवर नहीं करता, वह भाग भी शामिल है।
http://127.0.0.1:7000 पर नियंत्रण पैनल, चलते समय लैब दिखाते हुए।
limeyard पहले vuln_apps था। इसका नाम बदला गया क्योंकि यह अब अनुप्रयोगों का फ़ोल्डर नहीं रहा: अब इसमें बेयर सेवाएँ, एक DNS ज़ोन, एक WAF जोड़ी, एक सटीक लक्ष्य और APK फिक्स्चर हैं, जिनमें से कोई भी ऐप नहीं है।
पुराने बेड़े ने 9 में से 9 स्कोर किया, शून्य चूक, शून्य गलत सकारात्मक। जो बेंचमार्क विफल नहीं हो सकता वह रिग्रेशन का पता नहीं लगा सकता। संरचनात्मक रूप से तीन चीज़ें गलत थीं:
127.0.0.1:70xx था, इसलिए सबडोमेन प्रगणन के पास प्रगणित करने के लिए कुछ नहीं था, पोर्ट स्कैनिंग को उसका उत्तर थमा दिया गया था, और सेवा फिंगरप्रिंटिंग ने कभी कोई गैर-HTTP डेमॉन नहीं देखा।आपको Docker (compose प्लगइन के साथ) और git चाहिए। और कुछ नहीं।
curl -fsSL https://raw.githubusercontent.com/clickswave/limeyard/main/install.sh | bash
यह लैब को ./limeyard में क्लोन करता है, एक नए API टोकन के साथ इसकी .env लिखता है, कंट्रोल प्लेन को बनाता और शुरू करता है, फिर पूछता है कि क्या चलाना है। कुछ भी शुरू होने से पहले यह दिखाता है कि चयन की लागत क्या है, संदर्भ बॉक्स पर निष्क्रिय मापी गई, आपकी मशीन में जो खाली है उसके मुकाबले:
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]
गैर-इंटरैक्टिव: curl ... | bash -s -- --light --yes (या --all,
--none, --pick dvwa,juice-shop,estate)। चेकआउट को कहीं और रखें
LIMEYARD_DIR=/path के साथ।
इसके बाद पैनल http://127.0.0.1:7000 पर है, और वही चीज़ें हाथ से:
./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
हाथ से, इंस्टॉलर के बिना:
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
प्रत्येक मैनिफ़ेस्ट में एक मापा गया resources ब्लॉक होता है (कंटेनर, निष्क्रिय RAM, इमेज डिस्क, निष्क्रिय CPU)। विज़ार्ड, पैनल की चयन पट्टी और प्रत्येक लक्ष्य का पृष्ठ इससे योग करते हैं, इसलिए अनुमान हर जगह समान होता है।
दो, और केवल दो।
main वह है जिसे इंस्टॉलर क्लोन करता है और जो आपको मिलता है यदि आप कुछ नहीं करते। यह पुल रिक्वेस्ट द्वारा आगे बढ़ती है, कभी सीधे पुश द्वारा नहीं।dev डिफ़ॉल्ट ब्रांच है और जहाँ काम आता है। इसके विरुद्ध पुल रिक्वेस्ट खोलें।| target | परीक्षण के अधीन एक चीज़, घोषित kind की। एक compose फ़ाइल, वैकल्पिक सेटअप, और अपनी उत्तर कुंजी रखती है। अपने स्वयं के पृथक compose प्रोजेक्ट के रूप में चलती है, इसलिए Postgres का उपयोग करने वाले दो लक्ष्य कभी एक साझा नहीं करते |
| scenario | कई लक्ष्य प्राधिकृत DNS के साथ एक नेटवर्क टोपोलॉजी में जुड़े हुए। संपत्ति खोज जिसके विरुद्ध स्कोर की जाती है |
| truth | मशीन-पठनीय उत्तर कुंजी। देखें truth/schema.md |
| doctor | प्रत्येक के लिए एक निर्णय के साथ जाँचों की एक सूची: पर्यावरण, एट्रिब्यूशन, सप्लाई चेन, हार्डनिंग। स्पष्ट उपाय वाली जाँचों में पैनल (/doctor) में एक-क्लिक फिक्स और CLI पर --fix होता है: नेटवर्क बनाएँ, डिस्क पुनःप्राप्त करें, इमेज पिन करें, स्रोत प्राप्त करें, चल रहे लक्ष्यों को पुनःसत्यापित करें, ऑफ-लूपबैक बाइंड फिर से लिखें। एट्रिब्यूशन, पोर्ट टकराव और हार्डनिंग के लिए एक व्यक्ति चाहिए |
प्रकार: 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 दो कंटेनर शुरू करता है और कुछ नहीं: limeyard_control
(limed डेमॉन, Docker सॉकेट रखते हुए) और limeyard_ui (SvelteKit
पैनल)। दोनों केवल लूपबैक बाइंड करते हैं। पैनल http://127.0.0.1:7000 पर है और
कच्चा API http://127.0.0.1:7099 पर। दोनों को .env चाहिए, और इसमें LIME_TOKEN अनिवार्य है: पैनल टोकन को सर्वर-साइड रखता है और ब्राउज़र इसे कभी नहीं देखता।
| पृष्ठ | यह किस लिए है |
|---|---|
| Targets | प्रत्येक लक्ष्य, प्रकार और स्थिति से फ़िल्टर करें, क्रमबद्ध करें, Start, Stop, Restart के साथ बहु-चयन। लक्ष्य के लिए एक पंक्ति पर क्लिक करें |
| Target | तथ्य (पता, क्रेडेंशियल, स्टैक, अपस्ट्रीम, सत्यापन, इमेज डाइजेस्ट), लाइव लॉग, और इसके नकारात्मकों के साथ उत्तर कुंजी |
| Scenarios | एस्टेट: रिज़ॉल्वर, ज़ोन, सबनेट, और प्रति-कंटेनर स्थिति वाली एक होस्ट तालिका। ऊपर लाएँ, नीचे लाएँ, पुनः आरंभ करें |
| Scorecard | डेल्टा के साथ नवीनतम रन, प्रति-वर्ग और प्रति-लक्ष्य कवरेज, छूटे हुए आईडी, एक इतिहास जिसे आप देख सकते हैं, और दो-रन का अंतर |
| Ports | localhost पर क्या बाइंड होता है, और क्या केवल लैब ब्रिज पर मौजूद है |
| Doctor | प्रत्येक के लिए एक निर्णय के साथ जाँचों की एक सूची। Fix और Fix all पहले सटीक कमांड और फ़ाइल संपादन दिखाते हैं, जैसा लैब है उससे गणना करके, और पुष्टि पर उन्हें चलाते हैं। जो फिक्स अपनी जाँच को विफल छोड़ता है वह ऐसा बताता है |
| Credits | प्रत्येक लक्ष्य किसने लिखा और किस लाइसेंस के अंतर्गत |
पैनल स्वयं को अद्यतन करता है: limed SSE पर स्थिति संक्रमण स्ट्रीम करता है, इसलिए CLI से शुरू किया गया लक्ष्य बिना रीफ्रेश के दिखाई देता है। हेडर उसी स्ट्रीम से होस्ट का CPU, RAM और खाली डिस्क रखता है, रंग केवल तब जब वे ध्यान देने योग्य हों। प्रत्येक तालिका कॉलम हेडर पर क्लिक करके क्रमबद्ध होती है; दूसरा क्लिक दिशा पलट देता है।
पैनल या डेमॉन में बदलाव के बाद, जोड़ी को पुनः बनाएँ:
docker compose up -d --build