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 in cui costruisci l'infrastruttura come topologia, per poi esportare una directory di lavoro completa e funzionante di Terraform e Ansible. La esegui dalla tua macchina. redStackPRO non conserva mai le tue credenziali cloud.
[!IMPORTANT] redStackPRO è in prerelease (beta). Le funzionalità sono ancora in evoluzione prima della 1.0. GCP e AWS sono testati end to end; Azure, Proxmox ed ESXi sono in roadmap. Aspettati qualche asperità e fissa una versione rilasciata se hai bisogno di stabilità.
Hai incontrato un problema o hai un feedback? Apri una issue su Issues. Se riguarda un deploy, allega il file
logs/deploy-*.logripulito scritto dall'esecuzione (registra versioni, provider e il punto in cui si è fermata, con i segreti rimossi) così può essere analizzato rapidamente. Le tue segnalazioni contribuiscono a plasmare il rilascio.
redStackPRO mette l'infrastruttura d'attacco e le range target sulla stessa tela. Le due
modalità della tela sono Offense (infrastruttura d'attacco) e Defense (range AD difensive); l'
export nomina il proprio handoff OFFENSE-BRIEFING.md o DEFENSE-BRIEFING.md in base alla modalità.
Split horizon C2, infrastruttura d'attacco: due front door che non condividono lo stesso destino, Apache davanti a Sliver e Nginx davanti a Mythic, ciascun redirector sulla propria rete peered, con i teamserver, il collector e gli operatori dietro un jumpbox.
Più operatori, un solo stack. Un jumpbox dell'infrastruttura d'attacco può indicare un
elenco di operators (handle più ruolo), e ciascuno riceve un login al portale Guacamole
con la password di laboratorio condivisa. Imposta access_mode del jumpbox su wireguard o
openvpn (il default è un portale pubblico) e ogni operatore riceve 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. I login al portale oggi
condividono l'unica password di laboratorio, quindi l'isolamento per operatore deriva dalla
credenziale VPN di ciascun operatore, non dal login al portale; le password individuali del portale sono in
roadmap. In una modalità di accesso VPN il portale si chiude verso internet e passa dietro
il tunnel, mentre SSH resta aperto così l'amministratore può continuare a fare deploy 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, una range target: una piccola foresta aziendale, un dominio radice e un figlio su una trust parent-child, con il percorso ordinario da una workstation phishata alla foresta.
GOAD, il laboratorio completo: tre domini su due foreste, cinque macchine e le loro trust, la range di riferimento seguita dalla soluzione scritta.
[!IMPORTANT] L'export è il confine. La tela genera file; tu li esegui con le tue credenziali. redStackPRO non esegue mai deploy e non conserva mai un segreto.
[!CAUTION] Solo uso autorizzato. redStackPRO crea infrastrutture offensive e ambienti deliberatamente vulnerabili. Usalo solo in ambienti di laboratorio di tua proprietà o per cui sei esplicitamente autorizzato a eseguire test, mai contro sistemi per cui non hai il permesso scritto.
Pre-release, con ulteriori novità in arrivo prima della 1.0. La pipeline stessa funziona end-to-end: una topologia viene compilata in Terraform e Ansible, e l'export viene distribuito.
| Provider | Stato |
|---|---|
| GCP, AWS | Supportati e testati end-to-end, sia per i range target che per l'infrastruttura d'attacco. |
| Azure, Proxmox, ESXi | In roadmap, non ancora supportati. |
L'intera canvas in un unico container, l'API e la web app su un'unica 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:latest
La canvas è in ascolto sulla porta 8000 all'interno del container. Per servirla su una porta
host diversa, modifica la metà sinistra del mapping (-p 8787:8000), oppure imposta
REDSTACKPRO_PORT per compose (REDSTACKPRO_PORT=8787 docker compose up).
Compose include anche un backend Postgres opzionale per una distribuzione condivisa:
REDSTACKPRO_DATABASE_URL=postgresql+psycopg://redstackpro:redstackpro@db:5432/redstackpro \
docker compose --profile postgres up
L'immagine è solo il livello di composizione. Non include 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 canvas.
git clone <this repo> && cd redStackPRO
python -m venv .venv && . .venv/bin/activate
pip install -e ".[dev]"
La canvas è composta da 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 canvas 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 predefinito, scegli il tuo cloud nel selettore del provider nella toolbar (GCP o AWS), apri la scheda Export (compila man mano), poi Download. Ottieni uno zip della directory di lavoro descritta di seguito.
Oppure salta del tutto la canvas e compila un blueprint predefinito dalla riga di comando, stesso compilatore, stesso output:
redstackpro compile frontend/public/goad/goad-light.json -o export