devzero-security/redstackproEine Canvas für Red-Team-Infrastruktur und Cyber-Ranges. Stelle eine Topologie zusammen, exportiere ausführbares Terraform und Ansible und deploye es selbst. Deine Cloud-Anmeldedaten verlassen niemals deinen Rechner.
Eine Web-Canvas, auf der du Infrastruktur als Topologie aufbaust und dann ein vollständiges, lauffähiges Arbeitsverzeichnis aus Terraform und Ansible exportierst. Du führst es auf deiner eigenen Maschine aus. redStackPRO hält niemals deine Cloud-Anmeldedaten.
[!IMPORTANT] redStackPRO befindet sich im Prerelease (Beta). Die Funktionen ändern sich noch vor 1.0. GCP und AWS sind durchgängig getestet; Azure, Proxmox und ESXi stehen auf der Roadmap. Rechne mit Ecken und Kanten und pinne auf eine veröffentlichte Version, wenn du Stabilität brauchst.
Auf eine Ecke gestoßen oder Feedback? Eröffne ein Issue unter Issues. Wenn es um ein Deployment ging, hänge das bereinigte
logs/deploy-*.logan, das der Lauf geschrieben hat (es zeichnet Versionen, Provider und die Abbruchstelle auf, mit entfernten Secrets), damit es schnell analysiert werden kann. Deine Meldungen prägen das Release.
redStackPRO vereint Angriffsinfrastruktur und Ziel-Ranges auf derselben Canvas. Die beiden
Canvas-Modi sind Offense (Angriffsinfrastruktur) und Defense (defensive AD-Ranges); der
Export benennt seine Übergabe entsprechend OFFENSE-BRIEFING.md oder DEFENSE-BRIEFING.md.
Split-Horizon-C2, Angriffsinfrastruktur: zwei Eingangstüren, die kein gemeinsames Schicksal teilen, Apache vor Sliver und Nginx vor Mythic, jeder Redirector in seinem eigenen gepeerten Netz, mit den Teamservern, dem Collector und den Operatoren hinter einer Jumpbox.
Mehrere Operatoren, ein Stack. Eine Jumpbox für Angriffsinfrastruktur kann eine
Liste von operators (Handle plus Rolle) benennen, und jeder erhält einen Guacamole-Portal-Login
mit dem gemeinsamen Lab-Passwort. Setze den access_mode der Jumpbox auf wireguard oder
openvpn (Standard ist ein öffentliches Portal), und jeder Operator erhält zusätzlich
einen persönlichen VPN-Zugang, der beim Apply auf der Jumpbox erzeugt wird: Die Schlüssel verlassen niemals die Box
oder gelangen in den Export, nur die Client-Konfigurationsdatei tut es. Die Portal-Logins teilen sich derzeit
das eine Lab-Passwort, daher kommt die Isolation pro Operator aus dem jeweiligen
eigenen VPN-Zugang, nicht aus dem Portal-Login; individuelle Portal-Passwörter stehen auf der
Roadmap. Bei einem VPN-Zugriffsmodus schließt sich das Portal gegenüber dem Internet und wandert hinter
den Tunnel, während SSH offen bleibt, damit der Admin die Box weiterhin deployen und verwalten kann.
Füge einen Teamkollegen auf einer laufenden Jumpbox hinzu oder entferne ihn mit
sudo rsp-operator add <handle>. Siehe das
Wiki Deploying a Range.
Harbor, eine Ziel-Range: ein kleiner Unternehmenswald, eine Root-Domain und eine Child-Domain über eine Parent-Child-Vertrauensstellung, mit dem gewöhnlichen Pfad von einer phishierten Workstation zum Wald.
GOAD, das vollständige Lab: drei Domains über zwei Wälder, fünf Maschinen und ihre Vertrauensstellungen, die Referenz-Range, der die schriftliche Lösung folgt.
[!IMPORTANT] Der Export ist die Grenze. Die Canvas generiert Dateien; du führst sie unter deinen eigenen Anmeldedaten aus. redStackPRO deployt niemals etwas und hält niemals ein Secret.
[!CAUTION] Nur zur autorisierten Verwendung. redStackPRO erstellt offensive Infrastruktur und absichtlich verwundbare Umgebungen. Verwende es nur in Laborumgebungen, die dir gehören oder für die du ausdrücklich zur Prüfung autorisiert bist, niemals gegen Systeme, für die du keine schriftliche Erlaubnis hast.
Vorabversion, mit weiteren Ergänzungen vor 1.0. Die Pipeline selbst funktioniert durchgängig: Eine Topologie wird zu Terraform und Ansible kompiliert, und der Export lässt sich deployen.
| Provider | Status |
|---|---|
| GCP, AWS | Unterstützt und durchgängig getestet, sowohl für Zielumgebungen als auch für Angriffsinfrastruktur. |
| Azure, Proxmox, ESXi | Auf der Roadmap, noch nicht unterstützt. |
Die gesamte Canvas in einem Container, die API und die Web-App auf einem Port:
docker compose up # builds from this repo, http://127.0.0.1:8000
Oder ziehe stattdessen das veröffentlichte Image, anstatt es zu bauen:
docker run -p 8000:8000 -v redstackpro-data:/data \
ghcr.io/devzero-security/redstackpro:latest
Die Canvas lauscht im Container auf Port 8000. Um sie auf einem anderen Host-Port
bereitzustellen, ändere die linke Hälfte des Mappings (-p 8787:8000) oder setze
REDSTACKPRO_PORT für Compose (REDSTACKPRO_PORT=8787 docker compose up).
Compose enthält außerdem ein optionales Postgres-Backend für eine gemeinsame Bereitstellung:
REDSTACKPRO_DATABASE_URL=postgresql+psycopg://redstackpro:redstackpro@db:5432/redstackpro \
docker compose --profile postgres up
Das Image ist nur die Kompositionsschicht. Es enthält weder Terraform noch Ansible und speichert niemals deine Cloud-Anmeldedaten: Du führst den Export, den es erzeugt, von deinem eigenen Rechner aus aus, genau wie im folgenden Ablauf aus dem Quellcode.
Python 3.11 oder neuer und Node 24 für die Canvas.
git clone <this repo> && cd redStackPRO
python -m venv .venv && . .venv/bin/activate
pip install -e ".[dev]"
Die Canvas besteht aus zwei Prozessen, der API und der Web-App:
redstackpro serve # http://127.0.0.1:8000
cd frontend && npm install && npm run dev
redstackpro serve --port 8787 verschiebt die API auf einen anderen Port. Richte den
Canvas-Dev-Server mit REDSTACKPRO_API=http://127.0.0.1:8787 darauf aus.