devzero-security/redstackproUm canvas para infraestrutura de red team e cyber ranges. Componha uma topologia, exporte Terraform e Ansible executáveis e implante-a você mesmo. Suas credenciais de nuvem nunca saem da sua máquina.
Uma tela web onde você constrói infraestrutura como uma topologia e depois exporta um diretório de trabalho completo e executável de Terraform e Ansible. Você o executa a partir da sua própria máquina. O redStackPRO nunca armazena suas credenciais de nuvem.
[!IMPORTANT] O redStackPRO está em pré-lançamento (beta). O schema e os recursos ainda estão em movimento. GCP e AWS são testados de ponta a ponta; Azure, Proxmox e ESXi estão no roadmap. Espere arestas ásperas e fixe em uma versão lançada se precisar de estabilidade.
Encontrou uma aresta áspera ou tem feedback? Abra uma issue em Issues. Se foi um deploy, anexe o
logs/deploy-*.loghigienizado que a execução gravou (ele registra versões, provedor e onde parou, com segredos removidos) para que possa ser analisado rapidamente. Seus relatos moldam o lançamento.
O redStackPRO coloca infraestrutura de ataque e ranges alvo na mesma tela. Os dois
modos de tela são Offense (infraestrutura de ataque) e Defense (ranges AD defensivos); a
exportação nomeia seu handoff como OFFENSE-BRIEFING.md ou DEFENSE-BRIEFING.md para corresponder.
Split horizon C2, infraestrutura de ataque: duas portas de entrada que não compartilham um destino, Apache na frente do Sliver e Nginx na frente do Mythic, cada redirector em sua própria rede emparelhada, com os teamservers, coletor e operadores atrás de um jumpbox.
Múltiplos operadores, uma stack. Um jumpbox de infraestrutura de ataque pode nomear uma
lista de operators (handle mais função), e cada um recebe um login no portal Guacamole
na senha de laboratório compartilhada. Defina o access_mode do jumpbox como wireguard ou
openvpn (o padrão é um portal público) e cada operador também recebe uma credencial VPN pessoal
gerada no jumpbox no apply: as chaves nunca saem da máquina
nem entram na exportação, apenas o arquivo de configuração do cliente. Os logins do portal hoje
compartilham a mesma senha de laboratório, então o isolamento por operador vem da credencial VPN
de cada operador, não do login do portal; senhas individuais de portal estão no
roadmap. Em um modo de acesso VPN, o portal se fecha para a internet e se move para trás
do túnel, enquanto o SSH permanece aberto para que o admin possa continuar implantando e gerenciando a
máquina. Adicione ou remova um colega de equipe em um jumpbox em execução com
sudo rsp-operator add <handle>. Veja a
wiki Deploying a Range.
Harbor, um range alvo: uma pequena floresta corporativa, um domínio raiz e um filho sobre uma relação de confiança parent-child, com o caminho comum de uma estação de trabalho comprometida por phishing até a floresta.
GOAD, o laboratório completo: três domínios em duas florestas, cinco máquinas e suas relações de confiança, o range de referência que a solução escrita segue.
[!IMPORTANT] A exportação é a fronteira. A tela gera arquivos; você os executa sob suas próprias credenciais. O redStackPRO nunca implanta nada e nunca armazena um segredo.
[!CAUTION] Apenas uso autorizado. O redStackPRO constrói infraestrutura ofensiva e ranges deliberadamente vulneráveis. Use-o apenas em ambientes de laboratório que você possui ou está explicitamente autorizado a testar, nunca contra sistemas para os quais você não tem permissão por escrito.
Pré-lançamento, e o schema de topologia ainda está em movimento. O pipeline em si funciona de ponta a ponta: uma topologia compila para Terraform e Ansible, e a exportação implanta.
| Provedor | Estado |
|---|---|
| GCP, AWS | Suportados e testados de ponta a ponta, tanto para ranges alvo quanto para infraestrutura de ataque. |
| Azure, Proxmox, ESXi | No roadmap, ainda não suportados. |
Toda a tela em um contêiner, a API e o aplicativo web em uma porta:
docker compose up # builds from this repo, http://127.0.0.1:8000
Ou puxe a imagem publicada em vez de construí-la:
docker run -p 8000:8000 -v redstackpro-data:/data \
ghcr.io/devzero-security/redstackpro:0.9.0
A tela escuta na porta 8000 dentro do contêiner. Para servi-la em uma porta de host
diferente, altere a metade esquerda do mapeamento (-p 8787:8000), ou defina
REDSTACKPRO_PORT para o compose (REDSTACKPRO_PORT=8787 docker compose up).
O compose também carrega um backend Postgres opcional para uma implantação compartilhada:
REDSTACKPRO_DATABASE_URL=postgresql+psycopg://redstackpro:redstackpro@db:5432/redstackpro \
docker compose --profile postgres up
A imagem é apenas a camada de composição. Ela não carrega Terraform ou Ansible e nunca armazena suas credenciais de nuvem: você executa a exportação que ela produz a partir da sua própria máquina, exatamente como no fluxo a partir do código-fonte abaixo.
Python 3.11 ou mais recente, e Node 24 para a tela.
git clone <this repo> && cd redStackPRO
python -m venv .venv && . .venv/bin/activate
pip install -e ".[dev]"
A tela são dois processos, a API e o aplicativo web:
redstackpro serve # http://127.0.0.1:8000
cd frontend && npm install && npm run dev
redstackpro serve --port 8787 move a API para uma porta diferente. Aponte o
servidor de desenvolvimento da tela para ela com REDSTACKPRO_API=http://127.0.0.1:8787.
Abra-a, use Load blueprint (o botão, ou a paleta de modos) para abrir um ponto de partida fornecido, escolha sua nuvem no seletor de provedor da barra de ferramentas (GCP ou AWS), abra a aba Export (ela compila conforme você avança) e então Download. Você obtém um zip do diretório de trabalho descrito abaixo.
Ou pule a tela inteiramente e compile um blueprint fornecido a partir da linha de comando, mesmo compilador, mesma saída: