docs: consolidate READMEs and update for configuration-only model
This commit is contained in:
parent
af977eb2cb
commit
0d395f42c5
111
.bashrc
111
.bashrc
|
|
@ -1,111 +0,0 @@
|
||||||
# .bashrc para o container Nginx Pathfinder Proxy
|
|
||||||
|
|
||||||
# Cores para o prompt
|
|
||||||
export PS1='\[\033[01;32m\]\u@pathfinder\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
|
|
||||||
|
|
||||||
# Alias úteis
|
|
||||||
alias ll='ls -lah'
|
|
||||||
alias reload='nginx -s reload'
|
|
||||||
alias test='nginx -t'
|
|
||||||
|
|
||||||
# Vai para a pasta de configurações por padrão
|
|
||||||
cd /etc/nginx/conf.d
|
|
||||||
|
|
||||||
# Função para validar e recarregar o Nginx com feedback em português
|
|
||||||
nginx_ativar() {
|
|
||||||
echo "🔍 Iniciando validação técnica em /etc/nginx/conf.d..."
|
|
||||||
|
|
||||||
# Executa o teste de sintaxe do Nginx
|
|
||||||
OUTPUT=$(sudo nginx -t 2>&1)
|
|
||||||
|
|
||||||
if [ $? -eq 0 ]; then
|
|
||||||
echo "✅ Sintaxe validada com sucesso! Aplicando alterações..."
|
|
||||||
# Recarrega o serviço de forma segura (sem derrubar conexões)
|
|
||||||
sudo nginx -s reload
|
|
||||||
if [ $? -eq 0 ]; then
|
|
||||||
echo "🚀 Sucesso: O site foi ativado e o Nginx está operando com as novas configurações."
|
|
||||||
else
|
|
||||||
echo "❌ Erro crítico: Falha ao recarregar o processo do Nginx."
|
|
||||||
fi
|
|
||||||
else
|
|
||||||
echo "⚠️ Falha na Validação! As alterações NÃO foram aplicadas."
|
|
||||||
echo "Verifique os detalhes do erro abaixo:"
|
|
||||||
echo "------------------------------------------------------------"
|
|
||||||
echo "$OUTPUT"
|
|
||||||
echo "------------------------------------------------------------"
|
|
||||||
fi
|
|
||||||
}
|
|
||||||
|
|
||||||
# Ferramenta para selecionar e ativar sites do repositório Git
|
|
||||||
nginx_menu() {
|
|
||||||
REPO_URL="https://git.itguys.com.br/joao.goncalves/NgixProxy_Pathfinder.git"
|
|
||||||
TEMP_DIR="/tmp/site_repo"
|
|
||||||
BRANCH="sites-ativos"
|
|
||||||
|
|
||||||
echo "🌐 Conectando à branch [$BRANCH] do repositório..."
|
|
||||||
rm -rf "$TEMP_DIR"
|
|
||||||
git clone --depth 1 -b "$BRANCH" "$REPO_URL" "$TEMP_DIR" &>/dev/null
|
|
||||||
|
|
||||||
if [ $? -ne 0 ]; then
|
|
||||||
echo "❌ Erro ao conectar ao repositório Git ou branch não encontrada."
|
|
||||||
return 1
|
|
||||||
fi
|
|
||||||
|
|
||||||
# Busca arquivos .conf no repositório (recursivamente para garantir)
|
|
||||||
echo "📂 Analisando arquivos disponíveis..."
|
|
||||||
FILES=($(find "$TEMP_DIR" -maxdepth 2 -name "*.conf" ! -name "nginx.conf"))
|
|
||||||
|
|
||||||
if [ ${#FILES[@]} -eq 0 ]; then
|
|
||||||
echo "⚠️ Nenhum arquivo de site (.conf) encontrado na branch $BRANCH."
|
|
||||||
rm -rf "$TEMP_DIR"
|
|
||||||
return 1
|
|
||||||
fi
|
|
||||||
|
|
||||||
echo ""
|
|
||||||
echo "--- Selecione o site para ATIVAR ---"
|
|
||||||
|
|
||||||
# Criar array com caminhos relativos para exibição
|
|
||||||
SITES=()
|
|
||||||
for f in "${FILES[@]}"; do
|
|
||||||
SITES+=($(basename "$f"))
|
|
||||||
done
|
|
||||||
|
|
||||||
PS3='Escolha o número (ou q para sair): '
|
|
||||||
select SITE_NAME in "${SITES[@]}"; do
|
|
||||||
if [[ "$REPLY" == "q" ]]; then
|
|
||||||
echo "👋 Saindo..."
|
|
||||||
break
|
|
||||||
elif [[ -n "$SITE_NAME" ]]; then
|
|
||||||
# Acha o caminho original do arquivo selecionado
|
|
||||||
SELECTED_FILE=""
|
|
||||||
for f in "${FILES[@]}"; do
|
|
||||||
if [[ "$(basename "$f")" == "$SITE_NAME" ]]; then
|
|
||||||
SELECTED_FILE="$f"
|
|
||||||
break
|
|
||||||
fi
|
|
||||||
done
|
|
||||||
|
|
||||||
echo "📥 Ativando $SITE_NAME..."
|
|
||||||
sudo cp "$SELECTED_FILE" /etc/nginx/conf.d/
|
|
||||||
|
|
||||||
# Tenta copiar o nginx.conf global se ele existir no repo e não houver no destino
|
|
||||||
if [ ! -f /etc/nginx/nginx.conf ] && [ -f "$TEMP_DIR/nginx.conf" ]; then
|
|
||||||
echo "⚙️ Instalando nginx.conf base do repositório..."
|
|
||||||
sudo cp "$TEMP_DIR/nginx.conf" /etc/nginx/nginx.conf
|
|
||||||
fi
|
|
||||||
|
|
||||||
nginx_ativar
|
|
||||||
break
|
|
||||||
else
|
|
||||||
echo "❌ Opção inválida."
|
|
||||||
fi
|
|
||||||
done
|
|
||||||
|
|
||||||
rm -rf "$TEMP_DIR"
|
|
||||||
}
|
|
||||||
|
|
||||||
echo "--- Pathfinder Proxy Console ---"
|
|
||||||
echo "Comandos disponíveis:"
|
|
||||||
echo " nginx_ativar - Valida e recarrega as configs"
|
|
||||||
echo " nginx_menu - Busca e ativa sites do Git"
|
|
||||||
echo "--------------------------------"
|
|
||||||
|
|
@ -1,48 +0,0 @@
|
||||||
# Documentation and config folders
|
|
||||||
.gemini/
|
|
||||||
.git/
|
|
||||||
.github/
|
|
||||||
.vscode/
|
|
||||||
.idea/
|
|
||||||
|
|
||||||
# Legacy files (not needed in container)
|
|
||||||
legacy/
|
|
||||||
|
|
||||||
# Logs and debug files
|
|
||||||
*.log
|
|
||||||
debug_logs*.txt
|
|
||||||
nginx_test*.log
|
|
||||||
|
|
||||||
# Environment files
|
|
||||||
.env
|
|
||||||
.env.local
|
|
||||||
|
|
||||||
# Git files
|
|
||||||
.gitignore
|
|
||||||
.gitattributes
|
|
||||||
|
|
||||||
# Documentation
|
|
||||||
README.md
|
|
||||||
*.md
|
|
||||||
!nginx.conf
|
|
||||||
|
|
||||||
# Docker files (avoid recursive includes)
|
|
||||||
docker-compose*.yml
|
|
||||||
Dockerfile*
|
|
||||||
|
|
||||||
# Temporary and backup files
|
|
||||||
*.tmp
|
|
||||||
*.bak
|
|
||||||
*.swp
|
|
||||||
*.swo
|
|
||||||
*~
|
|
||||||
|
|
||||||
# OS files
|
|
||||||
.DS_Store
|
|
||||||
Thumbs.db
|
|
||||||
|
|
||||||
# SSL private keys (should be mounted as volume, not baked in)
|
|
||||||
ssl/*.key
|
|
||||||
|
|
||||||
# Disabled configs
|
|
||||||
*.disabled
|
|
||||||
|
|
@ -1,203 +0,0 @@
|
||||||
# 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.
|
|
||||||
|
|
||||||
```mermaid
|
|
||||||
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
|
|
||||||
```
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## <20> 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:
|
|
||||||
1. **Detecção:** O ModSecurity identifica uma tentativa de SQLi ou XSS e registra no `error.log`.
|
|
||||||
2. **Registro:** O Nginx gera logs no formato `detailed_proxy` (JSON) em `sites-ativos/logs`.
|
|
||||||
3. **Processamento:** O Fail2Ban (Sidecar) monitora o arquivo JSON. Ao encontrar um IP reincidente, ele o adiciona ao arquivo `blacklist.conf`.
|
|
||||||
4. **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
|
|
||||||
|
|
||||||
```text
|
|
||||||
/
|
|
||||||
├── 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:
|
|
||||||
|
|
||||||
```bash
|
|
||||||
#!/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?*
|
|
||||||
|
|
||||||
1. **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.
|
|
||||||
|
|
||||||
2. **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.
|
|
||||||
|
|
||||||
3. **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:
|
|
||||||
```nginx
|
|
||||||
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)**:
|
|
||||||
1. Confiamos no **Page Cache** do Linux para os arquivos frequentes.
|
|
||||||
2. Mantemos a persistência (se o Nginx reiniciar, o cache continua lá).
|
|
||||||
3. 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)
|
|
||||||
|
|
||||||
1. **[ ]** Construir o `Dockerfile` com compilação `quictls` e `modsecurity`. (CONCLUÍDO)
|
|
||||||
2. **[ ]** Atualizar o `docker-compose.yml` para incluir o Sidecar do Fail2Ban. (CONCLUÍDO)
|
|
||||||
3. **[ ]** Refatorar `cache_zones.conf` para o modelo de **Zona Universal**.
|
|
||||||
4. **[ ]** 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.**
|
|
||||||
80
README.md
80
README.md
|
|
@ -1,32 +1,54 @@
|
||||||
# Nginx Pathfinder - Infraestrutura (Produção)
|
# Nginx Pathfinder Proxy - Repositório de Configuração
|
||||||
|
|
||||||
Este diretório contém o "motor" do Proxy Reverso Pathfinder. Ele gerencia a imagem Docker, a orquestração de serviços e os componentes de segurança de baixo nível.
|
Este repositório é a fonte da verdade para as configurações do **Pathfinder Proxy**. Ele armazena as definições de domínios, segurança e parâmetros do Nginx e Fail2Ban.
|
||||||
|
|
||||||
## 🚀 O que este repositório faz:
|
|
||||||
* **Engine High-End:** Nginx 1.25 (Mainline) customizado.
|
|
||||||
* **Protocolos Modernos:** Suporte nativo a **HTTP/3 (QUIC)** e Brotli.
|
|
||||||
* **Segurança Nativa:** Compilado com **ModSecurity v3** (WAF).
|
|
||||||
* **Orquestração:** Gerencia o container Nginx e o Sidecar do **Fail2Ban**.
|
|
||||||
* **Auto-Healing:** Script `safe-deploy.sh` para validação atômica de configurações.
|
|
||||||
|
|
||||||
## 🏗️ Estrutura de Arquivos
|
|
||||||
```text
|
|
||||||
.
|
|
||||||
├── Dockerfile # Build Multi-stage (Compilação do Nginx + ModSec)
|
|
||||||
├── docker-compose.yml # Orquestração (Nginx + Fail2Ban + Volumes)
|
|
||||||
├── entrypoint.sh # Inicialização de serviços (Nginx, SSH)
|
|
||||||
├── safe-deploy.sh # Script para recarregar configs sem downtime
|
|
||||||
└── fail2ban/ # Configurações do sidecar de segurança
|
|
||||||
```
|
|
||||||
|
|
||||||
## ⚙️ Operação
|
|
||||||
Para gerenciar o ciclo de vida do container:
|
|
||||||
* **Build:** `docker compose build`
|
|
||||||
* **Start:** `docker compose up -d`
|
|
||||||
* **Logs da Infra:** `docker compose logs -f`
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
> [!IMPORTANT]
|
> [!IMPORTANT]
|
||||||
> **Configurações de Sites:** Este repositório NÃO contém as regras de sites ou certificados. Para editar domínios, snippets e regras do WAF, utilize o repositório:
|
> **Repositório de Configuração (Config Management):**
|
||||||
> [NGINX Pathfinder - Sites Ativos](../sites-ativos)
|
> Este repositório **NÃO** gerencia a execução do Docker, build de imagens ou certificados SSL. Ele serve apenas para versionar os arquivos `.conf` que serão baixados no servidor.
|
||||||
|
|
||||||
|
## 🧠 O que este repositório armazena:
|
||||||
|
* **Gerenciamento de Sites:** Definição de VHosts em `nginx/conf.d/`.
|
||||||
|
* **Snippets Reutilizáveis:** Componentes modulares (SSL, Proxy, WAF) em `nginx/snippets/`.
|
||||||
|
* **Segurança Dinâmica:** Estrutura para `blacklist.conf` (alimentada externamente).
|
||||||
|
* **Fail2Ban:** Regras de jails e filters customizados em `fail2ban/`.
|
||||||
|
|
||||||
|
## 📂 Estrutura de Pastas
|
||||||
|
```text
|
||||||
|
.
|
||||||
|
├── nginx/
|
||||||
|
│ ├── nginx.conf # Configuração mestre (Global)
|
||||||
|
│ ├── conf.d/ # Arquivos de site (Ex: ferreirareal.com.br.conf)
|
||||||
|
│ ├── snippets/ # Peças modulares (SSL, ModSec, Proxy, Blacklist)
|
||||||
|
│ ├── dynamic/ # Configurações dinâmicas (Blacklist - gerado pelo Fail2Ban)
|
||||||
|
│ └── modsec/ # Regras do WAF
|
||||||
|
└── fail2ban/ # Configurações do sidecar de segurança
|
||||||
|
```
|
||||||
|
|
||||||
|
## 🛠️ Como Adicionar um Site
|
||||||
|
1. Crie o arquivo em `nginx/conf.d/meusite.conf`.
|
||||||
|
2. Utilize os snippets para manter o padrão e segurança:
|
||||||
|
```nginx
|
||||||
|
server {
|
||||||
|
listen 443 quic reuseport; # Suporte a HTTP/3
|
||||||
|
listen 443 ssl;
|
||||||
|
server_name meusite.com.br;
|
||||||
|
|
||||||
|
# Certificados (Gerenciados no Servidor/Portainer)
|
||||||
|
ssl_certificate /etc/letsencrypt/live/meusite.com.br/fullchain.pem;
|
||||||
|
ssl_certificate_key /etc/letsencrypt/live/meusite.com.br/privkey.pem;
|
||||||
|
|
||||||
|
include snippets/ssl_params.conf;
|
||||||
|
include snippets/proxy_params.conf;
|
||||||
|
include snippets/modsecurity.conf;
|
||||||
|
|
||||||
|
location / {
|
||||||
|
proxy_pass http://ip_interno:porta;
|
||||||
|
}
|
||||||
|
}
|
||||||
|
```
|
||||||
|
3. Commit e Push para a branch `producao`.
|
||||||
|
4. No servidor (Portainer/Docker), faça o Pull das alterações.
|
||||||
|
|
||||||
|
## ⚙️ Notas Operacionais
|
||||||
|
* **Logs e SSL:** As pastas `logs`, `ssl` e `certbot` não são versionadas aqui para segurança. Elas existem apenas no servidor.
|
||||||
|
* **Fail2Ban:** O Fail2Ban lê os logs do Nginx e escreve bloqueios em `nginx/dynamic/blacklist.conf`.
|
||||||
|
|
@ -1,35 +0,0 @@
|
||||||
# Logs and debug files
|
|
||||||
*.log
|
|
||||||
debug_logs*.txt
|
|
||||||
nginx_test*.log
|
|
||||||
|
|
||||||
# Environment files
|
|
||||||
.env
|
|
||||||
.env.local
|
|
||||||
|
|
||||||
# Docker
|
|
||||||
docker-compose.override.yml
|
|
||||||
|
|
||||||
# SSL certificates (sensitive - should be managed separately)
|
|
||||||
ssl/*.key
|
|
||||||
ssl/*.crt
|
|
||||||
ssl/*.pem
|
|
||||||
|
|
||||||
# Editor files
|
|
||||||
.vscode/
|
|
||||||
.idea/
|
|
||||||
*.swp
|
|
||||||
*.swo
|
|
||||||
*~
|
|
||||||
|
|
||||||
# OS files
|
|
||||||
.DS_Store
|
|
||||||
Thumbs.db
|
|
||||||
|
|
||||||
# Temporary files
|
|
||||||
*.tmp
|
|
||||||
*.bak
|
|
||||||
|
|
||||||
# Disabled configs
|
|
||||||
*.disabled
|
|
||||||
.gemini/
|
|
||||||
|
|
@ -1,47 +0,0 @@
|
||||||
# Nginx Pathfinder - Sites e Configurações
|
|
||||||
|
|
||||||
Este diretório é o cérebro operacional do Proxy. Aqui ficam as definições de domínios, snippets de configuração e persistência de logs/segurança.
|
|
||||||
|
|
||||||
## 🧠 O que este repositório faz:
|
|
||||||
* **Gerenciamento de Sites:** Definição de VHosts em `conf.d/`.
|
|
||||||
* **Snippets Reutilizáveis:** Componentes de configuração (SSL, Proxy, WAF, ACME).
|
|
||||||
* **Segurança Dinâmica:** Gerenciamento da `blacklist.conf` alimentada pelo Fail2Ban.
|
|
||||||
* **Análise de Dados:** Logs detalhados em formato JSON (`detailed_proxy`).
|
|
||||||
* **Certificados:** Persistência de SSL via Certbot.
|
|
||||||
|
|
||||||
## 📂 Estrutura de Pastas
|
|
||||||
```text
|
|
||||||
.
|
|
||||||
├── nginx.conf # Configuração mestre (Global)
|
|
||||||
├── conf.d/ # Arquivos de site (Ex: dominio.com.br.conf)
|
|
||||||
├── snippets/ # Peças modulares (SSL, ModSec, Proxy, Blacklist)
|
|
||||||
├── modsec/ # Regras do WAF e OWASP CRS
|
|
||||||
└── logs/ # Logs JSON para análise e Fail2Ban
|
|
||||||
```
|
|
||||||
|
|
||||||
## 🛠️ Como Adicionar um Site
|
|
||||||
1. Crie o arquivo em `conf.d/meusite.conf`.
|
|
||||||
2. Utilize os snippets para manter o padrão:
|
|
||||||
```nginx
|
|
||||||
server {
|
|
||||||
listen 443 quic reuseport; # HTTP3
|
|
||||||
listen 443 ssl;
|
|
||||||
server_name meusite.com.br;
|
|
||||||
|
|
||||||
include snippets/ssl_params.conf;
|
|
||||||
include snippets/proxy_params.conf;
|
|
||||||
include snippets/modsecurity.conf;
|
|
||||||
|
|
||||||
location / {
|
|
||||||
proxy_pass http://ip_interno:porta;
|
|
||||||
}
|
|
||||||
}
|
|
||||||
```
|
|
||||||
3. Valide e aplique as mudanças usando o script na pasta de produção:
|
|
||||||
`../producao/safe-deploy.sh`
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
> [!NOTE]
|
|
||||||
> **Gestão do Motor:** Para atualizar a imagem docker, portas ou o Fail2Ban, utilize o repositório:
|
|
||||||
> [NGINX Pathfinder - Infraestrutura](../producao)
|
|
||||||
|
|
@ -1,13 +0,0 @@
|
||||||
# Site Configurations
|
|
||||||
Put your server blocks (vhosts) in this directory.
|
|
||||||
Example: `my-site.conf`
|
|
||||||
|
|
||||||
```nginx
|
|
||||||
server {
|
|
||||||
listen 80;
|
|
||||||
server_name example.com;
|
|
||||||
location / {
|
|
||||||
proxy_pass http://internal:8080;
|
|
||||||
}
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
@ -1,7 +0,0 @@
|
||||||
Container producao-nginx-run-1166b5318e75 Creating
|
|
||||||
Container producao-nginx-run-1166b5318e75 Created
|
|
||||||
nginx version: nginx/1.25.3
|
|
||||||
built by gcc 12.2.1 20220924 (Alpine 12.2.1_git20220924-r10)
|
|
||||||
built with OpenSSL 3.1.8 11 Feb 2025
|
|
||||||
TLS SNI support enabled
|
|
||||||
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --modules-path=/usr/lib/nginx/modules --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --user=nginx --group=nginx --with-http_ssl_module --with-http_v2_module --with-http_v3_module --with-http_realip_module --with-http_auth_request_module --with-http_sub_module --with-http_gzip_static_module --with-http_stub_status_module --with-threads --with-pcre-jit --add-module=/usr/src/ModSecurity-nginx --add-module=/usr/src/ngx_brotli --add-module=/usr/src/headers-more-nginx-module --with-cc-opt=-O3
|
|
||||||
Loading…
Reference in New Issue