10 KiB

Raw Blame History

Discussão de Infraestrutura: Agente de IA Pathfinder

Este documento detalha a arquitetura determinística projetada para o Nginx Pathfinder Proxy, focando em alta performance, segurança ativa e operações sem downtime.

🏛️ Arquitetura do Sistema

A solução baseia-se em um modelo de Container Principal + Sidecar, permitindo que a segurança e a automação operem sem interferir na performance do proxy.

graph TD
    User((Usuário / Internet)) -->|UDP 443 HTTP/3| Nginx[Nginx Master Container]
    User -->|TCP 80/443 HTTP/1.1/2| Nginx
    
    subgraph "Nginx Master (High-End)"
        Nginx -->|ModSecurity v3| WAF[WAF / OWASP CRS]
        WAF -->|Audit Logs| Logs[(Detailed JSON Logs)]
    end
    
    subgraph "Sidecar: Security & Automation"
        F2B[Fail2Ban Sidecar] -->|Lê| Logs
        F2B -->|Escreve| Blacklist[blacklist.conf]
    end
    
    Blacklist -->|Incluso via| Nginx
    
    subgraph "Persistent Storage (Windows Host)"
        Prod[./producao - Docker & Binários]
        Sites[./sites-ativos - Configs & SSL]
        LogDir[./sites-ativos/logs - Persistência]
    end

<EFBFBD> Pilares Técnicos Detalhados

1. Nginx "Turbo" (Produção)

Para suportar o estado da arte, o binário será compilado com os seguintes módulos:

QUIC/HTTP/3: Utilizando quictls para garantir criptografia moderna e performance em redes instáveis.
ModSecurity v3: Conector nativo para inspeção de pacotes em tempo real.
Brotli: Compressão superior ao Gzip para reduzir latência.
Headers More: Para ocultar a versão do Nginx e manipular headers de segurança de forma granular.

2. Fluxo de Segurança Ativa (WAF + Fail2Ban)

O sistema não apenas bloqueia, ele aprende e isola:

Detecção: O ModSecurity identifica uma tentativa de SQLi ou XSS e registra no error.log.
Registro: O Nginx gera logs no formato detailed_proxy (JSON) em sites-ativos/logs.
Processamento: O Fail2Ban (Sidecar) monitora o arquivo JSON. Ao encontrar um IP reincidente, ele o adiciona ao arquivo blacklist.conf.
Bloqueio: O Nginx, que possui um include snippets/blacklist.conf global, bloqueia o IP instantaneamente no próximo reload ou via processamento de hash dinâmico.

3. Gestão de Certificados SSL (Zero Downtime)

O monitoramento e renovação serão totalmente automatizados:

Certbot Portátil: O Agente de IA (Antigravity) pode disparar o Certbot internamente.
Desafio Webroot: Utiliza a pasta sites-ativos/snippets/acme_challenge.conf para validar domínios sem interromper o tráfego 443.
Reload Seguro: Após a renovação, um script de "safe-deploy" valida a sintaxe e aplica os novos certificados.

📂 Estrutura de Diretórios Final

/
├── producao/               # O "Motor" (Imutável)
│   ├── Dockerfile          # Build Multi-stage (Compilação)
│   ├── docker-compose.yml  # Orquestração (Nginx + Fail2Ban)
│   └── entrypoint.sh       # Scripts de boot e SSH
├── sites-ativos/           # A "Inteligência" (Editável pelo Agente)
│   ├── nginx.conf          # Configuração mestre
│   ├── conf.d/             # Arquivos .conf dos sites (Ex: site1.com.br.conf)
│   ├── snippets/           # Peças reutilizáveis (Coração do reuso)
│   │   ├── log_formats.conf# Seu padrão detailed_proxy
│   │   ├── ssl_params.conf # Configs HTTP/3 e Cifras
│   │   ├── modsecurity.conf# Ativação do WAF
│   │   └── blacklist.conf  # IPs banidos dinamicamente
│   └── logs/               # Onde a mágica do monitoramento acontece
└── DISCUSSAO_INFRA_AGENTE.md # Este documento de planejamento

🛠️ O Script `safe-deploy.sh` (O "Gatilho" do Agente)

Para garantir que eu (o Agente) nunca quebre o seu ambiente, toda alteração passará por este fluxo:

#!/bin/bash
# 1. Validação de Sintaxe
OUT=$(docker exec nginx-proxy nginx -t 2>&1)
if [ $? -eq 0 ]; then
    # 2. Aplicação Atômica
    docker exec nginx-proxy nginx -s reload
    echo '{"status": "success", "msg": "Configuração aplicada via Reload"}'
else
    # 3. Reporte de Erro para IA
    echo "{\"status\": \"error\", \"details\": \"$OUT\"}"
    exit 1
fi

📊 Dimensionamento de Recursos (Sizing)

Para uma carga de milhões de requisições por semana (média de ~12 RPS com picos de ~500 RPS), aqui está a estimativa de consumo de RAM:

Componente	Consumo Estimado (Pico)	Por que consome?
Nginx (Workers)	500MB - 1GB	Buffers de proxy, conexões ativas e SSL/TLS.
ModSecurity v3	1GB - 2GB	WAF é pesado. Processar regras OWASP consome RAM por worker.
Fail2Ban Sidecar	300MB - 800MB	Parse de JSON e banco de dados SQLite de banimentos.
Cache Index (Keys)	100MB (Fixo)	Espaço reservado para o índice de cache na RAM.
TOTAL ESTIMADO	3GB - 5GB	Recomendação: Servidor com 8GB RAM.

[!IMPORTANT] O Nginx é ultra eficiente, mas o ModSecurity v3 é um motor robusto de inspeção. Em picos de tráfego, ele é quem mais "bebe" RAM para garantir que nenhum ataque passe pelas regras.

⚡ Estratégia de Cache Dinâmico

O Nginx possui uma limitação técnica: a diretiva proxy_cache_path (que define o local e o tamanho da zona) deve ser declarada no bloco http de forma estática. Não é possível usar variáveis para o nome da zona ou o caminho em tempo de execução.

Proposta para contornar o "Manual":

Opção A: Zona Universal Inteligente (Recomendada)

Em vez de criar uma zona para cada site, usamos uma única zona robusta (dynamic_cache) de, por exemplo, 50GB.

Vantagem: Totalmente dinâmica. Um novo site não precisa de NADA no cache_zones.conf.
Isolamento Tecnológico: Garantido pela diretiva proxy_cache_key.
Risco de "Entregar Informação Errada": Praticamente ZERO, desde que a chave de cache seja única.

🛡️ Segurança e Isolamento de Cache

A pergunta vital: Um site pode "vazar" para o outro?

Como o Nginx identifica o que entregar: O Nginx gera um hash MD5 da string definida em proxy_cache_key. Nossa chave atual: "$scheme$request_method$host$request_uri"
- $host: Este é o segredo. Se um usuário acessa itguys.com.br e outro cliente.com.br, os hashes serão completamente diferentes, mesmo que o caminho seja o mesmo (/index.html). O Nginx nunca confundirá os arquivos no disco.
Risco de Cache Poisoning (Envenenamento): O risco real não é o vazamento entre sites, mas sim alguém "enganar" o cache para guardar uma versão maliciosa de um arquivo.
- Mitigação no Pathfinder: Nossa configuração já utiliza $host (que é validada pelo Nginx) e não headers não-confiáveis como X-Forwarded-Host na chave de cache.
- Proteção Adicional: Sempre incluímos o proxy_set_header Host $host nos nossos snippets para garantir que o backend receba o host correto e o cache reflita a realidade.
Isolamento de Disco (Quota): O único "risco" do cache partilhado é um site "comilão" ocupar os 20GB sozinho e forçar a limpeza dos arquivos dos outros sites (LRU).
- Solução: Se um site for crítico e volumoso, aí sim criamos uma zona isolada (Opção B).

Opção B: Automação pelo Agente (Eu)

Como este ambiente é operado por mim (IA), eu posso automatizar o que o Nginx não faz nativamente.

Fluxo: Ao detectar que você pediu um site novo com "Cache Isolado", eu mesmo incluo a linha no cache_zones.conf e rodo o safe-deploy.sh.
Resultado: Para você, parecerá dinâmico, pois eu farei o trabalho manual.

Opção C: Mapeamento de Zonas

Podemos usar um map para centralizar a escolha da zona:

map $host $site_cache_zone {
    host1.com  high_priority_cache;
    default    dynamic_cache;
}

🚀 Cache Híbrido: RAM + Disco

Uma dúvida comum: Como garantir que o cache seja ultra-rápido (RAM) mas ainda assim suporte grandes volumes (Disco)?

1. O Modelo Nativo do Nginx (Híbrido Automático)

O Nginx já divide o trabalho:

Metadados (RAM): O keys_zone (ex: 100MB) fica 100% na RAM. Ele é o índice. Quando chega um request, o Nginx checa a RAM primeiro.
Conteúdo (Disco + OS Page Cache): O arquivo em si fica no disco. No entanto, o Linux é inteligente: se um arquivo é acessado muitas vezes, o sistema operacional o mantém no Page Cache (RAM livre do servidor).
Resultado: Na prática, seus arquivos "quentes" já estarão na RAM sem você fazer nada.

2. Turbinando com RAM Disk (`tmpfs`)

Se quisermos forçar que certos arquivos NUNCA toquem o disco (latência zero real):

Como funciona: Montamos uma pasta no Docker usando tmpfs.
Vantagem: Velocidade absurda (pense em micro-assets ou APIs voláteis).
Desvantagem: Se o container reiniciar, esse cache some (volátil) e consome RAM real do seu host.

3. Nossa Estratégia Sugerida

Para o Pathfinder Proxy, manteremos o Modelo de Disco (SSD):

Confiamos no Page Cache do Linux para os arquivos frequentes.
Mantemos a persistência (se o Nginx reiniciar, o cache continua lá).
Não arriscamos travar o servidor por falta de RAM se o cache crescer rápido demais.

[!TIP] Dica de Performance: O parâmetro use_temp_path=off que já incluímos no seu config faz com que o Nginx escreva o arquivo diretamente na pasta final, evitando cópias desnecessárias no disco.

🚀 Próximos Passos (Mão na Massa)

Construir o Dockerfile com compilação quictls e modsecurity. (CONCLUÍDO)
Atualizar o docker-compose.yml para incluir o Sidecar do Fail2Ban. (CONCLUÍDO)
Refatorar cache_zones.conf para o modelo de Zona Universal.
Testar a primeira emissão de SSL via Certbot no novo modelo.

João, este detalhamento cobre todas as suas preocupações? Se sim, podemos iniciar o Passo 1.

10 KiB Raw Blame History Unescape Escape