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 von deiner eigenen Maschine aus. redStackPRO hält niemals deine Cloud-Anmeldedaten.
[!IMPORTANT] redStackPRO befindet sich im Prerelease (Beta). Das Schema und die Features sind noch in Bewegung. GCP und AWS sind End-to-End getestet; Azure, Proxmox und ESXi stehen auf der Roadmap. Rechne mit rauen Kanten und pinne auf eine veröffentlichte Version, wenn du Stabilität brauchst.
Auf eine raue Kante gestoßen oder Feedback? Eröffne ein Issue unter Issues. Wenn es ein Deploy war, hänge das bereinigte
logs/deploy-*.logan, das der Lauf geschrieben hat (es zeichnet Versionen, Provider und den Abbruchpunkt auf, mit entfernten Secrets), damit es schnell analysiert werden kann. Deine Berichte prägen das Release.
redStackPRO bringt Angriffsinfrastruktur und Ziel-Ranges auf dieselbe 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 einem eigenen gepeerten Netzwerk, mit den Teamservern, dem Collector und den Operatoren hinter einer Jumpbox.
Mehrere Operatoren, ein Stack. Eine Angriffsinfrastruktur-Jumpbox 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 eine persönliche VPN-Anmeldeinformation, die
beim Apply auf der Jumpbox generiert wird: Die Schlüssel verlassen die Box nie
und gelangen nie in den Export, nur die Client-Konfigurationsdatei tut es. Die
Portal-Logins teilen sich heute das eine Lab-Passwort, daher kommt die
Isolation pro Operator aus den eigenen VPN-Anmeldeinformationen jedes Operators,
nicht aus dem Portal-Login; individuelle Portal-Passwörter stehen auf der
Roadmap. Bei einem VPN-Zugriffsmodus schließt sich das Portal zum 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 ge-phishten Workstation zum Forest.
GOAD, das vollständige Lab: drei Domains über zwei Forests, fünf Maschinen und ihre Vertrauensstellungen, die Referenz-Range, der die geschriebene 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 autorisierte Nutzung. redStackPRO baut offensive Infrastruktur und absichtlich verwundbare Ranges. Nutze es nur in Lab-Umgebungen, die dir gehören oder die du ausdrücklich autorisiert bist zu testen, niemals gegen Systeme, für die du keine schriftliche Genehmigung hast.
Pre-Release, und das Topologie-Schema ist noch in Bewegung. Die Pipeline selbst funktioniert End-to-End: Eine Topologie kompiliert zu Terraform und Ansible, und der Export deployt.
| Provider | Zustand |
|---|---|
| GCP, AWS | Unterstützt und End-to-End getestet, sowohl für Ziel-Ranges 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 das veröffentlichte Image, statt es zu bauen:
docker run -p 8000:8000 -v redstackpro-data:/data \
ghcr.io/devzero-security/redstackpro:0.9.0
Die Canvas lauscht im Container auf 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 bringt außerdem ein optionales Postgres-Backend für ein geteiltes Deployment mit:
REDSTACKPRO_DATABASE_URL=postgresql+psycopg://redstackpro:redstackpro@db:5432/redstackpro \
docker compose --profile postgres up
Das Image ist nur die Kompositionsschicht. Es bringt weder Terraform noch Ansible mit und hält niemals deine Cloud-Anmeldedaten: Du führst den Export, den es erzeugt, von deiner eigenen Maschine aus, genau wie im From-Source-Ablauf unten.
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.