Trabalhando diariamente em operações críticas de Red Team e Threat Intelligence, aprendi que a infraestrutura que utilizamos dita o ritmo do engajamento. A maioria das ferramentas tradicionais de pentest opera de forma monolítica: a interface gráfica, o motor de processamento e o armazenamento de dados rodam em um único processo pesado na sua máquina local.

Mas se você quiser escalar suas operações, manter testes rodando 24/7 e, acima de tudo, preservar o seu OPSEC mantendo o seu IP residencial limpo, essa arquitetura clássica se torna um gargalo imenso.

É exatamente aqui que o Caido muda as regras do jogo. Desde a sua concepção, ele foi construído com uma arquitetura modular. Hoje, vou destrinchar como configuro o Caido em uma VPS e conecto o cliente local de forma segura, separando o poder de processamento da interface visual.

1. Entendendo a Separação Inteligente (Client vs Server)

Diferente das soluções monolíticas, o Caido divide o trabalho pesado da visualização:

  • Caido Daemon (Servidor): É o motor robusto escrito em Rust. É ele quem intercepta o tráfego, guarda o histórico, executa plugins e roda workflows. Ele não possui Interface Gráfica (GUI). Ele apenas expõe uma API.
  • Caido Client (Interface): É a aplicação web (feita em TypeScript/React) que você instala ou acessa no seu PC. Ela não processa tráfego; ela apenas se conecta ao Daemon via API para renderizar os dados e enviar os seus comandos.
Arquitetura Client-Server Caido
Figura 1: Fluxograma ilustrando a arquitetura Client-Server do Caido, com o tráfego roteado do computador local para o Daemon na VPS.

2. O Valor Tático de uma VPS

Subir o proxy na nuvem não é apenas um luxo técnico; traz vantagens operacionais diretas para o dia a dia de um engajamento:

  • OPSEC e Anonimato: Todo o tráfego de ataque e reconhecimento sai do IP da sua VPS. Seu IP residencial ou corporativo fica totalmente preservado das rotinas de WAF e Blue Teams.
  • Disponibilidade 24/7: Você pode iniciar um teste longo de automação (como fuzzing) na VPS a partir do seu Client. Depois, basta fechar a tampa do notebook, ir preparar um chimarrão, e o ataque continuará rodando na nuvem.
  • Performance Desacoplada: O consumo massivo de processamento e RAM fica no servidor em nuvem. Localmente, seu ambiente (no meu caso, um Ubuntu focado em hardening) fica livre de sobrecarga, lidando apenas com a renderização da interface.

3. Mão na Massa: Subindo o Motor na Nuvem

Por padrão, o Caido Daemon escuta apenas em 127.0.0.1:8080 (localhost) por questões de segurança. Não caia na tentação de expor essa porta diretamente para a internet. A API ainda não possui um controle de acesso nativo robusto o suficiente para ficar exposta publicamente.

O primeiro passo é acessar a sua VPS via SSH e iniciar o Daemon. Como o acesso será feito via túnel (explicarei a seguir), precisamos permitir que visitantes locais se conectem sem abrir o proxy para a internet.

Iniciando o Caido Daemon
Figura 2: Executando o binário `caido-cli` na VPS com as flags `--no-open` e `--allow-guests`.

Ao disparar o comando, o motor em Rust inicializa seus workers, atualiza o banco de dados e começa a escutar a porta 8080 localmente no servidor.

Logs do Caido Daemon iniciando
Figura 3: Logs do terminal confirmando que o `dispatcher-service` está no ar em 127.0.0.1:8080 na VPS.

4. OPSEC na Prática: O Túnel SSH

A forma correta e cirúrgica de acessar a API da VPS é através de um Túnel SSH (Local Port Forwarding).

Basicamente, você cria uma regra na sua máquina local dizendo: "Tudo o que eu enviar para a porta 8080 do meu PC, envie criptografado pelo SSH para a porta 8080 da VPS".

Comando SSH Tunnel
Figura 4: Criando o Local Port Forwarding no terminal local utilizando chaves Ed25519 para máxima segurança.

5. Conectando o Client Local

Com o túnel estabelecido, o seu tráfego local já está magicamente conectado ao servidor na nuvem. Ao acessar 127.0.0.1:8080 no seu navegador, a interface do Caido será carregada.

Visão Geral do Acesso
Figura 5: Interface do Caido rodando fluidamente no navegador local, com os logs de serviço passando no terminal em background.

Como configuramos a flag --allow-guests no servidor e estamos acessando via túnel, a plataforma nos reconhece e permite a operação.

Menu Guest no Caido Client
Figura 6: Menu lateral confirmando a sessão ativa como usuário Guest (Anonymous user).

Para que o proxy consiga interceptar tráfego HTTPS sem disparar alertas de segurança, precisamos gerar e confiar na Autoridade Certificadora (CA) do nosso Caido. Esse processo é o mesmo que faríamos localmente.

Instalação do Certificado CA
Figura 7: Painel de configurações do Caido para download e instalação do Certificado CA no navegador.

6. Configurando o Navegador e Interceptando o Alvo

Para garantir que o tráfego do pentest não se misture com a minha navegação pessoal, eu utilizo o Google Chrome com um diretório de perfil isolado (--use-data-dir) e forço o tráfego pelo túnel (--proxy-server).

Comando Google Chrome Proxy
Figura 8: Lançando uma instância isolada do Google Chrome no terminal, com o proxy já injetado.

Isso abre uma janela do navegador completamente "limpa", garantindo que extensões, cookies antigos ou abas abertas acidentalmente não interfiram no escopo do engajamento.

Navegador Chrome Aberto via Proxy
Figura 9: Instância do Chrome inicializada com um perfil temporário e tráfego 100% roteado para a VPS.

A partir deste ponto, o ambiente está armado. Todo o tráfego gerado nesse navegador viaja pelo túnel criptografado, é processado pelo motor do Caido na VPS, atinge o alvo, e as respostas são renderizadas no seu Client local de forma instantânea.

Tráfego Interceptado na VPS
Figura 10: Validação final com sucesso! Histórico HTTP sendo populado na interface local após navegação no ambiente de teste da Acunetix.

Desacoplar a interface do motor de processamento usando Caido não é apenas uma melhoria técnica; é uma evolução na maturidade operacional do seu pentest. Traz segurança, escalabilidade e a tranquilidade de saber que sua máquina local não vai travar no meio de um brute-force agressivo.