trustedsec/reelFramework de simulation de phishing et de sensibilisation pour campagnes basées sur des nœuds, capture d'identifiants, livraison SMTP, CAPTCHA et rejeu facultatif des identifiants de navigateur.
Framework de simulation de phishing et de sensibilisation à la sécurité avec workflows configurables, gestion de campagnes et proxy d'identifiants optionnel.
cd dedans../deploy.sh - cela configurera les prérequis pour vous, en supposant que vous êtes sur Ubuntu../start.sh --preload-ml. Cela démarrera les serveurs et préchargera les modèles de ML que nous utilisons.Vous obtenez l'interface d'administration sur http://localhost:8000 et le serveur de phishing sur http://localhost:1234. Connexion par défaut : admin / admin123. Changez le mot de passe après la première connexion.
Redirigez le port 8000 vers votre machine locale via SSH pour accéder au panneau d'administration. N'exposez PAS le panneau d'administration ni le serveur Flask (port 1234) directement sur Internet.
deploy.sh installera un serveur Caddy sur le même hôte ; tout est construit en supposant que vous utiliserez Caddy comme proxy inverse. Vous n'êtes pas obligé, mais ici il y a des dragons.
Options facultatives pour start.sh :
--with-caddy — Démarre Caddy via Docker (tests locaux uniquement).--preload-ml — Pré-télécharge le modèle de détection de phishing (~1,3 Go) ; évite le délai de première utilisation avec le plugin Détecteur de phishing.--reset-db — Remet à zéro la base de données et la réinitialise.--admin-only — Démarre uniquement le serveur d'administration (port 8000).--phishing-only — Démarre uniquement le serveur de phishing (port 1234).--skip-init — Ignore l'initialisation de la base de données.--skip-setup — Ignore la configuration du venv/dépendances ; charge simplement .env et démarre les serveurs.Sans start.sh, après avoir installé les dépendances et initialisé la base de données, vous pouvez lancer les deux serveurs avec : uv run python -m cli start.
Python : Voir requirements.txt. La pile de base comprend Flask, SQLAlchemy, Jinja2, Pydantic, Flask-Login, python-jose, passlib, cryptography et Flask-WTF. Le plugin Détecteur de phishing utilise transformers et torch. Le proxy d'identifiants utilise Playwright ; les intégrations optionnelles utilisent OpenAI/Anthropic et boto3 (AWS Connect).
Développement : requirements-dev.txt ajoute pytest, pytest-cov et les outils de test associés. Installez avec uv pip install -r requirements-dev.txt pour exécuter les tests et la couverture.
Système (production) : Le script de déploiement cible Ubuntu/Debian. Il installe uv, Caddy (proxy inverse) et des paquets système tels que libmagic1. Pour le proxy d'identifiants, start.sh exécute uv run playwright install chromium pour installer Chromium.
Préparation de la production sur Ubuntu. Idempotent. Il :
requirements.txt..env à partir de .env.example s'il est manquant et génère SECRET_KEY et JWT_SECRET_KEY s'ils ne sont pas définis.storage/caddy/data, storage/caddy/config, storage/uploads, storage/templates, storage/assets, instance).--init-db (exécute uv run python -m cli init --force).Il ne démarre pas l'application. En production : démarrez Caddy (proxy inverse), puis démarrez l'application avec ./start.sh ou un gestionnaire de processus afin que tout le trafic atteigne l'application via le proxy.
Démarrage en développement et en local. Il :
.env et garantit SECRET_KEY et JWT_SECRET_KEY (les génère si des valeurs par défaut sont présentes).requirements.txt.uv run playwright install chromium pour le proxy d'identifiants.--preload-ml (~1,3 Go).--skip-init). Utilisez --reset-db pour supprimer et réinitialiser.--with-caddy (tests locaux uniquement).uv run python -m cli start ; utilisez --admin-only ou --phishing-only pour n'en lancer qu'un.En production, l'application doit être exécutée derrière un proxy inverse. N'exposez pas les serveurs de développement Flask directement sur Internet.
Le proxy inverse est responsable de la terminaison TLS, des en-têtes Host corrects, du routage des chemins et des domaines, et de la séparation du trafic d'administration du trafic de campagne. L'application écoute sur localhost ou sur un port interne ; le proxy gère le HTTPS public et transmet au serveur d'administration (par exemple le port 8000) et au serveur de phishing (par exemple le port 1234) selon votre configuration.
Recommandé : Utilisez Caddy comme proxy inverse. deploy.sh installe Caddy via APT. Le projet inclut des exemples de Caddyfile (par exemple Caddyfile.minimal). Après avoir exécuté deploy.sh, démarrez Caddy (par exemple caddy run --config /path/to/Caddyfile.minimal), puis démarrez l'application avec ./start.sh ou un gestionnaire de processus. Tout proxy inverse équivalent (nginx, Traefik, etc.) est acceptable tant que l'application n'est pas exposée directement.
Reel est un framework de simulation de phishing et de sensibilisation à la sécurité. Les opérateurs utilisent l'interface d'administration pour gérer les campagnes, les workflows, les modèles et les cibles. Le serveur de phishing sert les pages de destination des campagnes et exécute des workflows — des graphes de plugins basés sur des nœuds — à chaque requête.
Il y a deux points d'entrée de l'application dans app.py : create_app() pour le serveur de phishing et create_admin_app() pour l'interface d'administration. Les campagnes peuvent être entrantes (un visiteur suit un lien ; les workflows GET et POST gèrent les vues de page et les soumissions de formulaires) ou sortantes (le système envoie des e-mails ou des appels via des workflows d'envoi). Caddy peut être utilisé pour le routage des campagnes par domaine. Le proxy d'identifiants utilise Playwright pour l'automatisation du navigateur afin de rejouer les identifiants capturés sur les sites cibles.
Un utilisateur visite une URL de campagne (par exemple /<campaign_uid>). Le serveur de phishing route par UID de campagne. Pour les requêtes GET, il exécute le workflow GET de la campagne (par exemple, rendre la page de destination, CAPTCHA) ; pour les requêtes POST, il exécute le workflow POST (par exemple, valider les entrées, capturer les identifiants, rediriger). Les workflows sont de type campagne et déclarent le support des méthodes HTTP (GET, POST ou BOTH). Le contexte d'exécution inclut campaign, request, session et variables. La réponse est tirée de clés de contexte telles que _response_html, _response_redirect ou _response_json. Les workflows entrants sont utilisés pour les pages de destination, les CAPTCHA, la capture d'identifiants, les redirections et la journalisation.