Reel

फ़िशिंग सिमुलेशन और सुरक्षा जागरूकता फ्रेमवर्क, जिसमें कॉन्फ़िगरेबल वर्कफ़्लो, कैम्पेन प्रबंधन और वैकल्पिक क्रेडेंशियल प्रॉक्सी शामिल है।

---

त्वरित आरंभ (OPS उपयोग)

1. रिपॉजिटरी को क्लोन करें और उसमें cd करें।
2. ./deploy.sh चलाएँ - यह आपके लिए पूर्व-आवश्यकताएँ कॉन्फ़िगर कर देगा, यदि आप ubuntu पर हैं।
3. ./start.sh --preload-ml चलाएँ। यह सर्वरों को प्रारंभ करेगा और हमारे द्वारा उपयोग किए जाने वाले ML मॉडल को पहले से लोड करेगा।

आपको एडमिन UI http://localhost:8000 पर मिलता है और फ़िशिंग सर्वर http://localhost:1234 पर। डिफ़ॉल्ट लॉगिन: admin / admin123। पहले लॉगिन के बाद पासवर्ड बदलें।

एडमिन पैनल तक पहुँचने के लिए ssh पर 8000 को अपने लोकल पर फॉरवर्ड करें। एडमिन पैनल या flask सर्वर (पोर्ट 1234) को सीधे इंटरनेट पर एक्सपोज़ न करें।

deploy.sh उसी होस्ट पर एक caddy सर्वर स्थापित करेगा, सब कुछ इस धारणा के साथ बनाया गया है कि आप caddy को रिवर्स प्रॉक्सी के रूप में उपयोग करेंगे। आपको ऐसा करना आवश्यक नहीं है, परंतु ऐसा न करने पर जोखिम है।

start.sh के लिए वैकल्पिक फ़्लैग:

• --with-caddy — Docker के माध्यम से Caddy प्रारंभ करें (केवल लोकल परीक्षण)।
• --preload-ml — फ़िशिंग डिटेक्शन मॉडल पहले से डाउनलोड करें (~1.3GB); Phishing Detector प्लगइन उपयोग करते समय पहले उपयोग की देरी से बचाता है।
• --reset-db — डेटाबेस रीसेट करें और पुनः प्रारंभ करें।
• --admin-only — केवल एडमिन सर्वर प्रारंभ करें (पोर्ट 8000)।
• --phishing-only — केवल फ़िशिंग सर्वर प्रारंभ करें (पोर्ट 1234)।
• --skip-init — डेटाबेस आरंभीकरण छोड़ें।
• --skip-setup — venv/निर्भरता सेटअप छोड़ें; बस .env लोड करें और सर्वर प्रारंभ करें।

start.sh के बिना, निर्भरताएँ स्थापित करने और डेटाबेस आरंभ करने के बाद आप दोनों सर्वरों को इस प्रकार चला सकते हैं: uv run python -m cli start।

---

निर्भरताएँ

Python: requirements.txt देखें। मुख्य स्टैक में Flask, SQLAlchemy, Jinja2, Pydantic, Flask-Login, python-jose, passlib, cryptography और Flask-WTF शामिल हैं। Phishing Detector प्लगइन transformers और torch का उपयोग करता है। क्रेडेंशियल प्रॉक्सी Playwright का उपयोग करती है; वैकल्पिक एकीकरण OpenAI/Anthropic और boto3 (AWS Connect) का उपयोग करते हैं।

विकास: requirements-dev.txt में pytest, pytest-cov और संबंधित परीक्षण उपकरण जोड़े गए हैं। परीक्षण और कवरेज चलाने के लिए uv pip install -r requirements-dev.txt से इंस्टॉल करें।

सिस्टम (प्रोडक्शन): डिप्लॉय स्क्रिप्ट Ubuntu/Debian के लिए है। यह uv, Caddy (रिवर्स प्रॉक्सी), और libmagic1 जैसे सिस्टम पैकेज स्थापित करती है। क्रेडेंशियल प्रॉक्सी के लिए, start.sh Chromium स्थापित करने हेतु uv run playwright install chromium चलाता है।

---

स्क्रिप्ट्स

deploy.sh

Ubuntu पर प्रोडक्शन तैयारी। Idempotent। यह:

1. Ubuntu/Debian की जाँच करता है।
2. सिस्टम पैकेज स्थापित करता है (curl, ca-certificates, libmagic1, आदि)।
3. uv न होने पर उसे स्थापित करता है।
4. रिवर्स प्रॉक्सी के रूप में Caddy स्थापित करता है (APT)।
5. वर्चुअल वातावरण बनाता है और requirements.txt से Python निर्भरताएँ स्थापित करता है।
6. यदि .env नहीं है तो .env.example से .env बनाता है और यदि सेट नहीं हैं तो SECRET_KEY और JWT_SECRET_KEY उत्पन्न करता है।
7. आवश्यक डायरेक्टरी बनाता है (storage/caddy/data, storage/caddy/config, storage/uploads, storage/templates, storage/assets, instance)।
8. वैकल्पिक रूप से --init-db के साथ डेटाबेस आरंभ करता है (uv run python -m cli init --force चलाता है)।

यह एप्लिकेशन प्रारंभ नहीं करता। प्रोडक्शन के लिए: Caddy (रिवर्स प्रॉक्सी) प्रारंभ करें, फिर ./start.sh या किसी प्रोसेस मैनेजर के साथ ऐप प्रारंभ करें ताकि सारा ट्रैफ़िक प्रॉक्सी के माध्यम से ऐप तक पहुँचे।

start.sh

विकास और लोकल प्रारंभ। यह:

1. .env लोड करता है और SECRET_KEY तथा JWT_SECRET_KEY सुनिश्चित करता है (यदि डिफ़ॉल्ट मान मौजूद हों तो उन्हें उत्पन्न करता है)।
2. uv स्थापित है यह सत्यापित करता है।
3. यदि वर्चुअल वातावरण नहीं है तो बनाता है।
4. requirements.txt से निर्भरताएँ स्थापित करता है।
5. क्रेडेंशियल प्रॉक्सी के लिए uv run playwright install chromium चलाता है।
6. वैकल्पिक रूप से --preload-ml के साथ फ़िशिंग डिटेक्शन मॉडल पहले से डाउनलोड करता है (~1.3GB)।
7. यदि कोई डेटाबेस फ़ाइल मौजूद नहीं है तो डेटाबेस आरंभ करता है (जब तक --skip-init न दिया गया हो)। हटाने और पुनः आरंभ करने के लिए --reset-db का उपयोग करें।
8. वैकल्पिक रूप से --with-caddy के साथ Docker के माध्यम से Caddy प्रारंभ करता है (केवल लोकल परीक्षण)।
9. सर्वर प्रारंभ करता है: डिफ़ॉल्ट रूप से uv run python -m cli start के माध्यम से एडमिन और फ़िशिंग दोनों; केवल एक चलाने के लिए --admin-only या --phishing-only का उपयोग करें।

---

प्रोडक्शन डिप्लॉयमेंट

प्रोडक्शन में, एप्लिकेशन अवश्य रिवर्स प्रॉक्सी के पीछे चलना चाहिए। Flask डेवलपमेंट सर्वरों को सीधे इंटरनेट पर एक्सपोज़ न करें।

रिवर्स प्रॉक्सी TLS समाप्ति, सही Host हेडर, पाथ और डोमेन रूटिंग, तथा एडमिन ट्रैफ़िक को कैम्पेन ट्रैफ़िक से अलग करने के लिए ज़िम्मेदार है। ऐप localhost या आंतरिक पोर्ट पर सुनता है; प्रॉक्सी सार्वजनिक HTTPS संभालता है और आपकी कॉन्फ़िगरेशन के अनुसार एडमिन सर्वर (जैसे पोर्ट 8000) और फ़िशिंग सर्वर (जैसे पोर्ट 1234) पर फॉरवर्ड करता है।

अनुशंसित: रिवर्स प्रॉक्सी के रूप में Caddy का उपयोग करें। deploy.sh APT के माध्यम से Caddy स्थापित करता है। प्रोजेक्ट में Caddyfile उदाहरण शामिल हैं (जैसे Caddyfile.minimal)। deploy.sh चलाने के बाद, Caddy प्रारंभ करें (जैसे caddy run --config /path/to/Caddyfile.minimal) और फिर ./start.sh या किसी प्रोसेस मैनेजर के साथ एप्लिकेशन प्रारंभ करें। कोई भी समकक्ष रिवर्स प्रॉक्सी (nginx, Traefik, आदि) तब तक स्वीकार्य है जब तक ऐप सीधे एक्सपोज़ न हो।

---

प्रोजेक्ट का उद्देश्य

Reel एक फ़िशिंग सिमुलेशन और सुरक्षा जागरूकता फ्रेमवर्क है। ऑपरेटर admin UI का उपयोग करके कैम्पेन, वर्कफ़्लो, टेम्पलेट और लक्ष्यों का प्रबंधन करते हैं। फ़िशिंग सर्वर कैम्पेन की लैंडिंग पेज सर्व करता है और प्रत्येक अनुरोध पर वर्कफ़्लो—प्लगइन्स के नोड-आधारित ग्राफ—चलाता है।

app.py में दो एप्लिकेशन एंट्री पॉइंट हैं: फ़िशिंग सर्वर के लिए create_app() और admin UI के लिए create_admin_app()। कैम्पेन इनबाउंड (एक विज़िटर लिंक का अनुसरण करता है; GET और POST वर्कफ़्लो पेज व्यू और फॉर्म सबमिशन संभालते हैं) या आउटबाउंड (सिस्टम सेंडिंग वर्कफ़्लो के माध्यम से ईमेल या कॉल भेजता है) हो सकते हैं। Caddy का उपयोग कैम्पेन की डोमेन-आधारित रूटिंग के लिए किया जा सकता है। क्रेडेंशियल प्रॉक्सी लक्ष्य साइटों पर कैप्चर किए गए क्रेडेंशियल को दोबारा चलाने के लिए ब्राउज़र ऑटोमेशन हेतु Playwright का उपयोग करती है।

---

वर्कफ़्लो अवधारणाएँ

इनबाउंड

एक उपयोगकर्ता कैम्पेन URL (जैसे /<campaign_uid>) पर जाता है। फ़िशिंग सर्वर कैम्पेन UID द्वारा रूट करता है। GET अनुरोधों के लिए यह कैम्पेन का GET वर्कफ़्लो चलाता है (जैसे लैंडिंग पेज रेंडर करना, CAPTCHA); POST अनुरोधों के लिए यह POST वर्कफ़्लो चलाता है (जैसे इनपुट सत्यापित करना, क्रेडेंशियल कैप्चर करना, रीडायरेक्ट)। वर्कफ़्लो campaign प्रकार के होते हैं और HTTP मेथड समर्थन (GET, POST, या BOTH) घोषित करते हैं। निष्पादन संदर्भ में campaign, request, session, और variables शामिल होते हैं। प्रतिक्रिया संदर्भ कुंजियों जैसे _response_html, _response_redirect, या _response_json से ली जाती है। इनबाउंड वर्कफ़्लो का उपयोग लैंडिंग पेज, CAPTCHA, क्रेडेंशियल कैप्चर, रीडायरेक्ट और लॉगिंग के लिए किया जाता है।

आउटबाउंड

एक ऑपरेटर admin UI से किसी कैम्पेन से जुड़ा सेंडिंग वर्कफ़्लो चलाता है (कैम्पेन का "Workflow" / सेंडिंग वर्कफ़्लो)। सेंडिंग एक्ज़ीक्यूटर sending प्रकार का एकल वर्कफ़्लो चलाता है: यह लक्ष्यों का चयन करता है (जैसे CSV या ट्रैक किए गए उपयोगकर्ताओं से), वैकल्पिक रूप से सामग्री को सत्यापित या प्री-रेंडर करता है, फिर लक्ष्यों पर पुनरावृत्ति करता है—ईमेल रेंडर करना, रेट लिमिट लगाना, और प्लगइन (जैसे SMTP) के माध्यम से भेजना। यहाँ कोई विज़िटर GET/POST नहीं है; वर्कफ़्लो सामग्री उत्पन्न करता है और उसे लक्ष्यों की सूची में भेजता है।

सारांश: