devzero-security/redstackproUne toile pour l'infrastructure d'équipe rouge et les cyber-ranges. Composez une topologie, exportez du Terraform et Ansible exécutables, et déployez-la vous-même. Vos identifiants cloud ne quittent jamais votre machine.
Un canevas web où vous construisez une infrastructure sous forme de topologie, puis exportez un répertoire de travail complet et exécutable de Terraform et Ansible. Vous l'exécutez depuis votre propre machine. redStackPRO ne détient jamais vos identifiants cloud.
[!IMPORTANT] redStackPRO est en préversion (bêta). Le schéma et les fonctionnalités évoluent encore. GCP et AWS sont testés de bout en bout ; Azure, Proxmox et ESXi sont sur la feuille de route. Attendez-vous à des aspérités, et épinglez une version publiée si vous avez besoin de stabilité.
Vous avez rencontré une aspérité, ou vous avez des retours ? Ouvrez une issue sur Issues. S'il s'agissait d'un déploiement, joignez le fichier
logs/deploy-*.lognettoyé écrit par l'exécution (il enregistre les versions, le fournisseur et l'endroit où il s'est arrêté, avec les secrets supprimés) afin qu'il puisse être analysé rapidement. Vos rapports façonnent la version.
redStackPRO place l'infrastructure d'attaque et les ranges cibles sur le même canevas. Les deux
modes du canevas sont Offense (infrastructure d'attaque) et Defense (ranges AD défensifs) ; l'
export nomme son handoff OFFENSE-BRIEFING.md ou DEFENSE-BRIEFING.md en conséquence.
Split horizon C2, infrastructure d'attaque : deux portes d'entrée qui ne partagent pas un destin, Apache devant Sliver et Nginx devant Mythic, chaque redirecteur sur son propre réseau appairé, avec les teamservers, le collecteur et les opérateurs derrière un jumpbox.
Plusieurs opérateurs, une seule stack. Un jumpbox d'infrastructure d'attaque peut nommer une
liste d'operators (handle plus rôle), et chacun obtient un identifiant de portail Guacamole
sur le mot de passe de lab partagé. Réglez l'access_mode du jumpbox sur wireguard ou
openvpn (par défaut, un portail public) et chaque opérateur obtient également un
identifiant VPN personnel généré sur le jumpbox à l'apply : les clés ne quittent jamais la machine
ni n'entrent dans l'export, seul le fichier de configuration client le fait. Les identifiants du portail partagent aujourd'hui
le même mot de passe de lab, donc l'isolation par opérateur provient de l'identifiant VPN propre à chaque opérateur,
pas de l'identifiant du portail ; les mots de passe individuels du portail sont sur la
feuille de route. En mode d'accès VPN, le portail se ferme à internet et passe derrière
le tunnel, tandis que SSH reste ouvert pour que l'admin puisse continuer à déployer et gérer la
machine. Ajoutez ou retirez un coéquipier sur un jumpbox en cours d'exécution avec
sudo rsp-operator add <handle>. Voir le
wiki Deploying a Range.
Harbor, un range cible : une petite forêt d'entreprise, un domaine racine et un enfant sur une relation d'approbation parent-enfant, avec le chemin ordinaire d'un poste de travail phishé jusqu'à la forêt.
GOAD, le lab complet : trois domaines répartis sur deux forêts, cinq machines et leurs approbations, le range de référence que suit la solution écrite.
[!IMPORTANT] L'export est la frontière. Le canevas génère des fichiers ; vous les exécutez avec vos propres identifiants. redStackPRO ne déploie jamais rien et ne détient jamais de secret.
[!CAUTION] Usage autorisé uniquement. redStackPRO construit de l'infrastructure offensive et des ranges délibérément vulnérables. Utilisez-le uniquement dans des environnements de lab que vous possédez ou pour lesquels vous êtes explicitement autorisé à tester, jamais contre des systèmes pour lesquels vous n'avez pas de permission écrite.
Préversion, et le schéma de topologie évolue encore. Le pipeline lui-même fonctionne de bout en bout : une topologie se compile en Terraform et Ansible, et l'export se déploie.
| Fournisseur | État |
|---|---|
| GCP, AWS | Pris en charge et testé de bout en bout, pour les ranges cibles et l'infrastructure d'attaque. |
| Azure, Proxmox, ESXi | Sur la feuille de route, pas encore pris en charge. |
Tout le canevas dans un seul conteneur, l'API et l'application web sur un seul port :
docker compose up # builds from this repo, http://127.0.0.1:8000
Ou récupérez l'image publiée au lieu de la construire :
docker run -p 8000:8000 -v redstackpro-data:/data \
ghcr.io/devzero-security/redstackpro:0.9.0
Le canevas écoute sur 8000 à l'intérieur du conteneur. Pour le servir sur un autre port
hôte, changez la moitié gauche du mapping (-p 8787:8000), ou définissez
REDSTACKPRO_PORT pour compose (REDSTACKPRO_PORT=8787 docker compose up).
Compose embarque aussi un backend Postgres optionnel pour un déploiement partagé :
REDSTACKPRO_DATABASE_URL=postgresql+psycopg://redstackpro:redstackpro@db:5432/redstackpro \
docker compose --profile postgres up
L'image n'est que la couche de composition. Elle n'embarque ni Terraform ni Ansible et ne détient jamais vos identifiants cloud : vous exécutez l'export qu'elle produit depuis votre propre machine, exactement comme dans le flux depuis les sources ci-dessous.
Python 3.11 ou plus récent, et Node 24 pour le canevas.
git clone <this repo> && cd redStackPRO
python -m venv .venv && . .venv/bin/activate
pip install -e ".[dev]"
Le canevas est composé de deux processus, l'API et l'application web :
redstackpro serve # http://127.0.0.1:8000
cd frontend && npm install && npm run dev
redstackpro serve --port 8787 déplace l'API sur un autre port. Pointez le
serveur de développement du canevas vers elle avec REDSTACKPRO_API=http://127.0.0.1:8787.