devzero-security/redstackproUn canvas per l'infrastruttura red team e i cyber range. Componi una topologia, esporta Terraform e Ansible eseguibili e distribuiscila autonomamente. Le tue credenziali cloud non lasciano mai la tua macchina.
Una tela web dove costruisci l'infrastruttura come topologia, poi esporti una directory di lavoro completa ed eseguibile di Terraform e Ansible. La esegui dalla tua macchina. redStackPRO non conserva mai le tue credenziali cloud.
[!IMPORTANT] redStackPRO è in prerelease (beta). Lo schema e le funzionalità sono ancora in evoluzione. GCP e AWS sono testati end to end; Azure, Proxmox ed ESXi sono nella roadmap. Aspettati spigoli, e fissa una versione rilasciata se ti serve stabilità.
Hai incontrato uno spigolo, o hai feedback? Apri una issue su Issues. Se era un deploy, allega il file
logs/deploy-*.logripulito che l'esecuzione ha scritto (registra versioni, provider e dove si è fermato, con i segreti rimossi) così può essere analizzato rapidamente. Le tue segnalazioni plasmano il rilascio.
redStackPRO mette l'infrastruttura di attacco e i range target sulla stessa tela. Le due
modalità della tela sono Offense (infrastruttura di attacco) e Defense (range AD difensivi); l'
export nomina il suo handoff OFFENSE-BRIEFING.md o DEFENSE-BRIEFING.md di conseguenza.
Split horizon C2, infrastruttura di attacco: due front door che non condividono un destino, Apache davanti a Sliver e Nginx davanti a Mythic, ogni redirector sulla propria rete peered, con i teamserver, il collector e gli operatori dietro un jumpbox.
Più operatori, un solo stack. Un jumpbox di infrastruttura di attacco può nominare una
lista di operators (handle più ruolo), e ognuno ottiene un login al portale Guacamole
sulla password condivisa del lab. Imposta l'access_mode del jumpbox a wireguard o
openvpn (il default è un portale pubblico) e ogni operatore ottiene anche una credenziale
VPN personale generata sul jumpbox all'apply: le chiavi non lasciano mai la macchina
né entrano nell'export, solo il file di configurazione client lo fa. I login al portale oggi
condividono l'unica password del lab, quindi l'isolamento per operatore deriva dalla credenziale
VPN di ciascun operatore, non dal login al portale; le password individuali del portale sono nella
roadmap. In una modalità di accesso VPN il portale si chiude a internet e si sposta dietro
il tunnel, mentre SSH resta aperto così l'admin può continuare a distribuire e gestire la
macchina. Aggiungi o rimuovi un compagno di squadra su un jumpbox in esecuzione con
sudo rsp-operator add <handle>. Vedi il
wiki Deploying a Range.
Harbor, un range target: una piccola foresta aziendale, un dominio root e un figlio su una trust parent-child, con il percorso ordinario da una workstation phished alla foresta.
GOAD, il lab completo: tre domini su due foreste, cinque macchine e le loro trust, il range di riferimento che la soluzione scritta segue.
[!IMPORTANT] L'export è il confine. La tela genera file; tu li esegui con le tue credenziali. redStackPRO non distribuisce mai nulla e non conserva mai un segreto.
[!CAUTION] Solo uso autorizzato. redStackPRO costruisce infrastruttura offensiva e range deliberatamente vulnerabili. Usalo solo in ambienti lab che possiedi o per cui sei esplicitamente autorizzato a testare, mai contro sistemi per cui non hai il permesso scritto.
Pre-release, e lo schema della topologia è ancora in evoluzione. La pipeline stessa funziona end to end: una topologia compila in Terraform e Ansible, e l'export distribuisce.
| Provider | Stato |
|---|---|
| GCP, AWS | Supportati e testati end to end, sia per range target che per infrastruttura di attacco. |
| Azure, Proxmox, ESXi | Nella roadmap, non ancora supportati. |
L'intera tela in un container, l'API e la web app su una sola porta:
docker compose up # builds from this repo, http://127.0.0.1:8000
Oppure scarica l'immagine pubblicata invece di compilarla:
docker run -p 8000:8000 -v redstackpro-data:/data \
ghcr.io/devzero-security/redstackpro:0.9.0
La tela ascolta sulla 8000 dentro il container. Per servirla su una porta host
diversa, cambia la metà sinistra del mapping (-p 8787:8000), oppure imposta
REDSTACKPRO_PORT per compose (REDSTACKPRO_PORT=8787 docker compose up).
Compose porta anche un backend Postgres opzionale per un deployment condiviso:
REDSTACKPRO_DATABASE_URL=postgresql+psycopg://redstackpro:redstackpro@db:5432/redstackpro \
docker compose --profile postgres up
L'immagine è solo il livello di composizione. Non porta Terraform o Ansible e non conserva mai le tue credenziali cloud: esegui l'export che produce dalla tua macchina, esattamente come nel flusso da sorgente qui sotto.
Python 3.11 o superiore, e Node 24 per la tela.
git clone <this repo> && cd redStackPRO
python -m venv .venv && . .venv/bin/activate
pip install -e ".[dev]"
La tela è due processi, l'API e la web app:
redstackpro serve # http://127.0.0.1:8000
cd frontend && npm install && npm run dev
redstackpro serve --port 8787 sposta l'API su una porta diversa. Punta il
dev server della tela su di essa con REDSTACKPRO_API=http://127.0.0.1:8787.
Aprilo, usa Load blueprint (il pulsante, o la palette delle modalità) per aprire un punto di partenza fornito, scegli il tuo cloud nel selettore provider della toolbar (GCP o AWS), apri la tab Export (compila mentre procedi), poi Download. Ottieni uno zip della directory di lavoro descritta sotto.
Oppure salta del tutto la tela e compila un blueprint fornito dalla riga di comando, stesso compilatore, stesso output:
redstackpro compile frontend/public/goad/goad-light.json -o export
La riga di comando usa GCP come default. Passa --provider aws per AWS.