From a9564b6bea877c3a8c3dea0e1d809df0c6990761 Mon Sep 17 00:00:00 2001 From: Rui Date: Thu, 7 May 2026 22:19:07 +0200 Subject: [PATCH] feat: commit inicial das instrucoes e infraestrutura --- .gitignore | 5 + arquitetura.md | 247 +++++++++++++++++++++++++++++++++ compartilhamento_instrucoes.md | 152 ++++++++++++++++++++ monitor_cal_install.sh | 192 +++++++++++++++++++++++++ monitoramento-calendar.md | 121 ++++++++++++++++ seguranca_deploy_user.md | 106 ++++++++++++++ vpn-setup.md | 111 +++++++++++++++ vps3-banco-tuning.md | 212 ++++++++++++++++++++++++++++ 8 files changed, 1146 insertions(+) create mode 100644 .gitignore create mode 100644 arquitetura.md create mode 100644 compartilhamento_instrucoes.md create mode 100755 monitor_cal_install.sh create mode 100644 monitoramento-calendar.md create mode 100644 seguranca_deploy_user.md create mode 100644 vpn-setup.md create mode 100644 vps3-banco-tuning.md diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..90fcb3c --- /dev/null +++ b/.gitignore @@ -0,0 +1,5 @@ +# Ignorar arquivos de configuração sensíveis locais se copiados acidentalmente +gcal_key.json +ssh_alerts_config.json +*.log +.DS_Store diff --git a/arquitetura.md b/arquitetura.md new file mode 100644 index 0000000..c2114ba --- /dev/null +++ b/arquitetura.md @@ -0,0 +1,247 @@ +# 📐 Arquitetura de Rede e Topologia de Servidores + +Este documento descreve detalhadamente a arquitetura de servidores e rede privada projetada para garantir **alta performance, isolamento de riscos, segurança de dados e facilidade de escalonamento**. + +--- + +## 🗺️ Visão Geral da Topologia (Rede VPN WireGuard) + +Toda a comunicação crítica entre os servidores trafega por dentro de uma rede privada criptografada baseada no protocolo **WireGuard** (`10.99.0.0/24`). Os servidores possuem seus firewalls públicos trancados, permitindo apenas acessos necessários e isolando os dados vitais. + +```mermaid +graph TD + subgraph "Rede Pública (Internet)" + Internet((Internet Pública)) + Client([Notebook Rui]) + end + + subgraph "Rede Privada VPN (10.99.0.0/24)" + VPS1["🖥️ VPS 1 (Produção)
IP: 10.99.0.1
(Traefik / Apps)"] + VPS3["🗄️ VPS 3 (Banco de Dados)
IP: 10.99.0.3
(PostgreSQL Dedicado)"] + VPS4["🧪 VPS 4 (Desenvolvimento)
IP: 10.99.0.4
(Staging / Builds)"] + VPS5["💬 VPS 5 (CRM WhatsApp)
IP: 10.99.0.5
(Bots / APIs)"] + end + + %% Conexões Públicas + Internet == HTTP/HTTPS (80/443) ==> VPS1 + Client == Conexão VPN Criptografada ==> VPS1 + + %% Conexões Privadas VPN + VPS1 <== Canal Seguro VPN ==> VPS3 + VPS1 <== Canal Seguro VPN ==> VPS4 + VPS1 <== Canal Seguro VPN ==> VPS5 + Client <== Acesso SSH Seguro ==> VPS1 + Client <== Acesso SSH Seguro ==> VPS3 + Client <== Acesso SSH Seguro ==> VPS4 + Client <== Acesso SSH Seguro ==> VPS5 + + %% Conexões de Banco de Dados Internas + VPS1 -- PostgreSQL (Porta 5432) --> VPS3 + VPS4 -- PostgreSQL (Porta 5432) --> VPS3 + VPS5 -- PostgreSQL (Porta 5432) --> VPS3 + + style VPS3 fill:#1E293B,stroke:#3B82F6,stroke-width:3px,color:#fff + style VPS1 fill:#1E293B,stroke:#10B981,stroke-width:2px,color:#fff + style VPS4 fill:#1E293B,stroke:#F59E0B,stroke-width:2px,color:#fff + style VPS5 fill:#1E293B,stroke:#EC4899,stroke-width:2px,color:#fff +``` + +--- + +## 📋 Especificação Detalhada dos Servidores + +### 1. 🗄️ VPS 3: Servidor de Banco de Dados Dedicado (Appliance) +* **Função Principal**: Hospedar exclusivamente o banco de dados **PostgreSQL Bare-Metal (Nativo)** e serviços fundamentais de persistência. +* **IP Privado VPN**: `10.99.0.3` +* **Tecnologias**: PostgreSQL (Instalação Nativa via Host), WireGuard, nftables. (O Docker é **estritamente omitido** para reduzir superfície de ataque e otimizar I/O). +* **Políticas do Firewall (nftables)**: + * **Porta 22 (SSH)**: **Bloqueada publicamente**. Liberada **apenas** para o IP reservado do administrador via VPN (`10.99.0.10`). + * **Porta 5432 (PostgreSQL)**: **Bloqueada publicamente**. Liberada **apenas** para conexões originadas de IPs autorizados na VPN (`10.99.0.1` e `10.99.0.5`). +* **Vantagens de Segurança & Performance**: + * **Zero vazamento de dados**: O banco não pode ser acessado de fora da VPN sob hipótese alguma. + * **Conceito de Appliance**: Sem Docker daemon (sem socket de root adicional) ou compiladores, a superfície de invasão é reduzida ao menor nível matemático possível. + * **Performance Máxima (Tuning de Host)**: Como a máquina é nativa e dedicada, as configurações de cache e buffers de memória do PostgreSQL podem usufruir livremente do Page Cache nativo do Linux e Huge Pages do Kernel, garantindo o máximo rendimento físico do SSD e RAM. + +--- + +### 🚀 2. VPS 1: Servidor de Sistemas em Produção +* **Função Principal**: Gateway de entrada do tráfego público e hospedagem das aplicações em produção. +* **IP Privado VPN**: `10.99.0.1` (Atua como Hub WireGuard) +* **Políticas do Firewall (UFW)**: + * **Portas 80 (HTTP) e 443 (HTTPS)**: **Abertas ao público** para permitir o acesso dos clientes aos sites e sistemas. + * **Porta 22 (SSH)**: **Bloqueada publicamente**. Apenas acessível via VPN. + * **Porta 3002 (Antigo Dev)**: **Bloqueada publicamente** no Docker (atrelada apenas ao IP privado `10.99.0.1` do container). +* **Vantagens de Segurança & Performance**: + * **Serviços sem Estado (Stateless)**: A VPS 1 apenas processa as requisições web e consome os dados da VPS 3. Caso a VPS 1 sofra um pico extremo de acessos, o banco de dados continua intacto e seguro. + * **Centralização com Traefik**: Proxy reverso centralizado gerenciando SSL e direcionamento interno seguro de containers. + +--- + +### 🧪 3. VPS 4: Servidor de Desenvolvimento e Homologação (Staging) +* **Função Principal**: Testar novos recursos, hospedar containers de staging e realizar builds de desenvolvimento. +* **IP Privado VPN**: `10.99.0.4` +* **Políticas do Firewall (UFW)**: + * **Porta 22 (SSH)**: **Bloqueada publicamente**. Apenas acessível via VPN. + * **Portas de teste (ex: 3002, 8080)**: **Bloqueadas publicamente** ou atreladas apenas ao IP privado da VPN para acesso exclusivo dos desenvolvedores autorizados. +* **Tecnologias**: Docker, Docker Compose, PostgreSQL 18 (Standby Replica em Container). +* **Vantagens de Segurança & Performance**: + * **Replicação Streaming Real-Time (Staging)**: Hospeda um container PostgreSQL 18 configurado como réplica de leitura (Standby) do banco de dados nativo de produção da VPS 3. Isso permite testar queries pesadas e validar migrações com dados reais em tempo de desenvolvimento de forma 100% segura e com zero impacto no banco principal. + * **Isolamento de Riscos**: Compilações de código (`npm run build`, `docker build`) e testes pesados de carga rodam aqui e consomem CPU sem comprometer os servidores de produção e banco de dados. + * **Ambiente Espelho**: Homologação idêntica à produção para validações precisas antes de aplicar modificações em produção. + +--- + +### 💬 4. VPS 5: Servidor de Aplicação Proprietária (newwhats) +* **Função Principal**: Hospedar o backend e workers da plataforma proprietária **newwhats** (Backend Express com Socket.IO, Workers do Temporal e broker NATS). +* **IP Privado VPN**: `10.99.0.5` +* **Políticas do Firewall (UFW)**: + * **Portas de Integração Web**: Liberadas apenas para os Webhooks e requisições públicas de Socket.IO mapeadas via gateway. + * **Porta 22 (SSH)**: **Bloqueada publicamente**. Apenas acessível via VPN. +* **Vantagens de Segurança & Performance**: + * **Isolamento de Estado**: Executar o backend Node.js (Prisma/Knex), os workers de workflows do Temporal e o broker de mensagens NATS na VPS 5 impede que oscilações no tráfego de mensagens do WhatsApp ou alto uso de CPU nos workers interfiram com o banco de dados principal de produção (VPS 3). + * **Separação de CPU**: O processamento pesado das sessões de WhatsApp e emulação de instâncias roda na VPS 5, consumindo sua CPU e RAM de forma isolada do Gateway (VPS 1) e do Banco (VPS 3). + +--- + +## 🔒 Diretrizes de Segurança Corporativa (Resumo) + +1. **Acesso Administrativo**: Realizado **exclusivamente via chave SSH criptográfica**. Autenticação por senhas desativada em todas as máquinas. +2. **Login de Root Desativado**: Bloqueado login direto de root via SSH. Todos conectam como o usuário `deploy` e elevam privilégios de forma segura via `sudo` após a conexão. +3. **Ponto Único de Falha**: Se a VPS 1 (Hub WireGuard) cair, a comunicação VPN é temporariamente pausada. O console VNC da Contabo é mantido ativo como canal redundante de suporte imediato. +4. **Logs Automatizados**: Logins SSH bem-sucedidos ou suspeitos geram alertas em segundo plano com marcações de 30 minutos na agenda central do Google, permitindo controle visual de acessos em tempo real. + +--- + +## 🛡️ Fase 2: Hardening Avançado e Arquitetura Zero-Trust (Roadmap) + +Esta seção documenta as decisões estratégicas e o plano de ação de segurança de curto e médio prazo projetados para elevar a maturidade da infraestrutura de rede e servidores ao nível **Enterprise / DevSecOps Sênior**. + +### 🗺️ Visão Geral do Fluxo de Segurança na Borda +```mermaid +graph TD + subgraph "Camadas de Defesa (Defense in Depth)" + Internet((Internet Pública)) --> PM[1. Proteção de Borda do Provedor] + PM --> NFT[2. nftables + CrowdSec
Bloqueio Dinâmico / Comportamental] + NFT --> TF[3. Traefik Reverse Proxy
SSL/TLS & Roteamento] + TF --> DK[4. Containers Docker
Rootless / Hardened] + end +``` + +--- + +### 1. 🌐 Desativação Proativa de IPv6 (Curto/Médio Prazo) +Para eliminar vetores de bypass acidentais de firewall e reduzir a complexidade da superfície de ataque, o suporte a IPv6 é **totalmente desativado** em todas as VPSs. + +* **Ações de Configuração**: + Para desativar em tempo de execução e garantir persistência pós-reboot, o arquivo `/etc/sysctl.d/99-disable-ipv6.conf` deve ser criado com as seguintes diretivas: + ```text + net.ipv6.conf.all.disable_ipv6 = 1 + net.ipv6.conf.default.disable_ipv6 = 1 + net.ipv6.conf.lo.disable_ipv6 = 1 + ``` + *Comando para aplicar imediatamente:* `sudo sysctl --system` + +* **Gatilhos para Reativação do IPv6**: + O IPv6 só será reabilitado caso surja uma necessidade real de negócio, tais como: + * Requisitos de conformidade corporativa (*Enterprise Compliance*). + * Integração obrigatória com CDNs IPv6-only ou arquiteturas de borda distribuída (*Anycast*). + * Casos em que a reativação exigirá a implementação completa de **nftables dual-stack, filtros de Router Advertisement (RA), NDP e SLAAC seguros**. + +--- + +### 2. 🐋 Isolamento de Redes Docker (Prevenção de Movimentação Lateral) +O uso da rede de ponte padrão (`bridge`) do Docker é estritamente proibido em produção. Os containers são segmentados em **redes de domínios funcionais isolados**, limitando severamente o raio de colisão (*blast radius*) caso um container de aplicação (especialmente bots de CRM/WhatsApp ou navegadores invisíveis) seja comprometido. + +#### 🔀 Matriz de Conectividade de Dados (newwhats): + +```mermaid +graph TD + subgraph "VPS 1: Gateway de Borda pública" + Traefik[Traefik Router] + end + + subgraph "VPS 5: Camada de Aplicação (newwhats)" + Express[Backend Express & Socket.IO] + TempWorker[Temporal Worker] + NATS[NATS Broker :4222] + + Express <--> NATS + TempWorker <--> Express + end + + subgraph "Túnel VPN Criptografado (wg0)" + WG0((Canal Privado WireGuard)) + end + + subgraph "VPS 3: Appliance de Dados Bare-Metal" + Postgres[(PostgreSQL :5432)] + Dragonfly[(DragonflyDB :6379)] + Temporal[(Temporal Server :7233)] + end + + %% Roteamento Web e Sockets + Traefik == HTTPS Proxy / Sockets ==> WG0 ==> Express + + %% Conexões de Dados da Aplicação via VPN + Express ==> WG0 ==> Postgres + Express ==> WG0 ==> Dragonfly + TempWorker ==> WG0 ==> Temporal + Temporal -. Persistência Interna .-> Postgres + + style Postgres fill:#1E293B,stroke:#3B82F6,stroke-width:2px,color:#fff + style Dragonfly fill:#1E293B,stroke:#10B981,stroke-width:2px,color:#fff + style Temporal fill:#1E293B,stroke:#F59E0B,stroke-width:2px,color:#fff +``` + +* **Diretrizes de Conectividade**: + * **Tráfego de Borda**: O Traefik na VPS 1 encaminha o tráfego HTTP/HTTPS e conexões persistentes do Socket.IO diretamente para a VPS 5 (`10.99.0.5`) pela interface de túnel criptografado, mantendo as portas da VPS 5 públicas totalmente fechadas. + * **Persistência de Negócio (Prisma + Knex)**: Ambas as ORMs/Query Builders centralizadas na VPS 5 apontam diretamente para o IP interno `10.99.0.3:5432` da VPS 3. + * **Cache e Estados Rápidos**: O DragonflyDB na VPS 3 atende instantaneamente às solicitações de sessões e QR codes da VPS 5 via `10.99.0.3:6379`, provendo tempos de resposta na faixa de microssegundos sem concorrência local de CPU. + * **Workflows Assíncronos**: O Temporal Server processa o agendamento de tarefas e status de reputação na VPS 3, enquanto o **Temporal Worker** na VPS 5 consome e executa as atividades pesadas locais da aplicação. + +--- + +### 3. 🔑 Zero-Trust Interno no WireGuard (ACLs no Firewall) +A rede VPN WireGuard (`10.99.0.0/24`) deixa de ser tratada como uma zona de confiança irrestrita. Implementa-se uma política de privilégio mínimo na comunicação entre os servidores da VPN. + +* **O Problema de Movimentação Lateral**: + Se a máquina de desenvolvimento/staging (VPS 4) for comprometida por um script malicioso, o atacante não pode ter permissão para escaneá-la ou conectar-se ao banco de dados de produção (VPS 3), exceto para o fluxo estritamente necessário de replicação de dados. + +* **Regras de Isolamento Lateral (Exemplo no Firewall da VPS 3)**: + ```text + # Bloquear por padrão toda conexão vinda da VPN exceto as estritamente autorizadas: + - Permitir VPS 1 (Produção) -> Porta 5432 (PostgreSQL) [ACEITAR] + - Permitir VPS 5 (CRM) -> Porta 5432 (PostgreSQL) [ACEITAR] + - Permitir VPS 4 (Staging) -> Porta 5432 (PostgreSQL - Apenas 'replicator') [ACEITAR] + - Permitir VPS 4 (Staging) -> VPS 3 (Produção - Outras portas / serviços) [BLOQUEAR] + ``` + +--- + +### 4. 🎛️ Migração de Borda: nftables + CrowdSec +Substitui-se a pilha clássica e reativa do `iptables` / `Fail2Ban` por uma arquitetura ativa, dinâmica e de alta performance na VPS pública 1. + +* **Por que `nftables`?** + A sintaxe nativa do `nftables` permite a criação de conjuntos dinâmicos (*sets*) de IP de forma extremamente eficiente, processados diretamente no kernel com consumo mínimo de CPU durante ataques volumétricos. +* **Por que `CrowdSec`?** + Diferente do Fail2Ban (que analisa logs localmente e de forma reativa por expressões regulares), o CrowdSec utiliza detecção baseada em comportamentos locais de ataque e sincroniza uma base global de reputação de IPs (*inteligência coletiva*). Se um IP atacou outra infraestrutura na internet, ele é bloqueado na sua VPS antes mesmo de fazer a primeira requisição ao seu Traefik. + +--- + +### 5. 💔 Mitigação do Ponto Único de Falha (SPOF) da VPS 1 +Atualmente, a VPS 1 acumula as funções de **Gateway de Borda (Traefik)**, **Hub Central de VPN (WireGuard)** e **Hospedagem de Aplicações**. + +* **Visão de Evolução Futura**: + Para eliminar o risco de interrupção total dos serviços em caso de queda da VPS 1, planeja-se a separação física de responsabilidades em médio prazo: + 1. **VPS Edge Dedicated**: Uma máquina leve rodando exclusivamente o gateway de entrada (`Traefik`), `nftables` e o concentrador `WireGuard`. + 2. **VPS App Dedicated**: Servidores internos que hospedam as aplicações (sem expor portas SSH ou HTTP à internet), consumindo tráfego encaminhado diretamente pelo Gateway da Edge. + +--- + +### 6. 🔒 Hardening Avançado de Containers +Para garantir que a invasão de um container não resulte no comprometimento do sistema operacional host, aplicam-se as seguintes diretrizes de segurança no provisionamento de containers Docker: + +* **No-New-Privileges**: Impede que processos dentro do container ganhem novos privilégios via binários `setuid` ou `setgid`. +* **Read-Only Root Filesystem**: Monta o sistema de arquivos do container como apenas leitura, forçando gravações temporárias apenas em volumes declarados ou `/tmp` na memória (tmpfs). +* **CAP Drop**: Remove capacidades de sistema desnecessárias ao container (ex: `NET_ADMIN`, `SYS_ADMIN`, `SYS_CHROOT`). +* **Rootless Containers**: Sempre que suportado pela aplicação, os containers devem rodar com IDs de usuário não privilegiados (non-root). diff --git a/compartilhamento_instrucoes.md b/compartilhamento_instrucoes.md new file mode 100644 index 0000000..2978e25 --- /dev/null +++ b/compartilhamento_instrucoes.md @@ -0,0 +1,152 @@ +# 📂 Guia de Compartilhamento da Pasta de Instruções entre VPSs + +Este documento descreve as melhores estratégias e o passo a passo técnico para que **agentes (humanos, automatizados ou IA)** em outras VPSs da sua rede segura (`10.99.0.0/24`) tenham acesso de leitura e escrita à pasta `/home/deploy/instrucoes`. + +Como você já possui uma infraestrutura de rede privada criptografada baseada em **WireGuard**, podemos aproveitar essa segurança para compartilhar os arquivos de forma extremamente protegida e eficiente. + +--- + +## 🗺️ Tabela Comparativa de Abordagens + +| Abordagem | Tipo | Sincronização | Segurança | Complexidade | Recomendação | +| :--- | :--- | :--- | :--- | :--- | :--- | +| **1. Git Privado** | Repositório | Manual / CI-CD | 🟢 **Máxima** (Chaves SSH) | 🟡 Baixa | **Altamente Recomendado** para desenvolvimento e IA | +| **2. Syncthing** | P2P Ativo | Instantânea | 🟢 **Excelente** (TLS + VPN) | 🟡 Média | **Ideal** para espelhamento em tempo real bidirecional | +| **3. SSHFS** | Mount Direto | Sob demanda | 🟢 **Excelente** (SSH s/ VPN) | 🟢 Muito Baixa | **Excelente** para montagem rápida sem duplicar arquivos | +| **4. Rsync + Cron** | Script Push/Pull | Periódica | 🟢 **Excelente** (SSH) | 🟢 Muito Baixa | Para espelhamento simples de leitura apenas | + +--- + +## 🕸️ Opção 1: Repositório Git Privado (Recomendado para Agentes & IA) + +Esta é a abordagem padrão da indústria. Em vez de compartilhar a pasta fisicamente via rede (o que gera dependência de conexão direta), transformamos a pasta `instrucoes` em um **repositório Git privado** (ex: no GitHub ou GitLab). + +### Como funciona: +Cada VPS possui um clone local em `/home/deploy/instrucoes`. Quando um agente ou você altera algo, faz um `git commit` e `git push`. As outras VPSs fazem `git pull`. + +### Vantagens para Agentes de IA: +Os agentes de IA (como o Antigravity e outros) lidam nativamente de forma excelente com comandos Git. Isso garante controle de versão, histórico de quem alterou o quê, facilidade de rollback e elimina riscos de corrupção de arquivos por escrita simultânea. + +### Passo a Passo de Configuração: + +1. **Inicializar o Git localmente na máquina de origem (ex: VPS 1):** + ```bash + cd /home/deploy/instrucoes + git init + # Adicionar um .gitignore para ignorar arquivos temporários ou chaves sensíveis que não devem subir + echo "gcal_key.json" >> .gitignore + echo "ssh_alerts_config.json" >> .gitignore + git add . + git commit -m "feat: commit inicial das instrucoes" + ``` + +2. **Criar um Repositório Privado** no GitHub/GitLab. + +3. **Gerar chaves de acesso SSH (Deploy Keys) nas outras VPSs:** + Em cada VPS que precisa de acesso, gere uma chave SSH para o usuário `deploy`: + ```bash + ssh-keygen -t ed25519 -C "vps-instrucoes-deploy" -f ~/.ssh/id_ed25519_github + ``` + Adicione a chave pública (`.pub`) gerada como **Deploy Key** (com permissão de escrita, se necessário) nas configurações do repositório no GitHub. + +4. **Clonar o repositório nas outras VPSs:** + ```bash + cd /home/deploy + git clone git@github.com:seu-usuario/seu-repositorio.git instrucoes + ``` + +5. **Automatizar o Pull (Opcional):** + Se quiser que as outras VPSs atualizem as instruções automaticamente sempre que houver mudanças no repositório remoto, configure um cronjob de 5 em 5 minutos para rodar o pull: + ```bash + crontab -e + # Adicione a linha abaixo: + */5 * * * * cd /home/deploy/instrucoes && git pull origin main > /dev/null 2>&1 + ``` + +--- + +## 🔄 Opção 2: Syncthing (Sincronização em Tempo Real Descentralizada) + +O **Syncthing** é um serviço peer-to-peer de sincronização contínua de arquivos. Ele roda como um daemon leve nas VPSs e garante que qualquer arquivo criado ou modificado em uma pasta seja propagado instantaneamente para as outras em questão de segundos. + +### Como configurar de forma segura via VPN WireGuard: + +1. **Instalar o Syncthing em todas as VPSs:** + ```bash + sudo apt-get update + sudo apt-get install -y syncthing + ``` + +2. **Configurar para escutar apenas no IP da VPN (Zero-Trust):** + Edite o arquivo de configuração do Syncthing (gerado após a primeira execução em `~/.config/syncthing/config.xml`) e ajuste o endereço da interface gráfica e de sincronização para rodar apenas nos IPs locais ou de VPN, prevenindo exposição pública. + * Altere a linha do GUI para escutar localmente: `
127.0.0.1:8384
` (Você pode acessar usando um túnel SSH do seu notebook: `ssh -L 8384:127.0.0.1:8384 deploy@10.99.0.1`). + +3. **Adicionar os Servidores como Peers:** + * No painel do Syncthing da VPS 1, copie o **Device ID**. + * Adicione esse Device ID no painel da VPS 4/5, especificando o endereço fixo da VPN (ex: `tcp://10.99.0.1:22000`). + * Compartilhe a pasta `/home/deploy/instrucoes` entre eles. + +4. **Habilitar o Serviço na inicialização:** + ```bash + sudo systemctl enable syncthing@deploy.service + sudo systemctl start syncthing@deploy.service + ``` + +--- + +## 🔗 Opção 3: SSHFS (Montagem de Pasta sobre SSH na VPN) + +O **SSHFS** permite montar um diretório remoto de um servidor em outro servidor de forma transparente, utilizando o próprio protocolo SSH de transporte. Como a sua porta SSH (22) está aberta e protegida dentro da rede privada da VPN (`10.99.0.0/24`), este método é extremamente simples e não exige serviços extras rodando em segundo plano além do próprio SSH. + +### Como configurar: + +Digamos que a pasta física está na **VPS 1 (IP `10.99.0.1`)** e você deseja acessá-la em tempo real na **VPS 4 (IP `10.99.0.4`)**: + +1. **Instalar o SSHFS na VPS de destino (ex: VPS 4):** + ```bash + sudo apt-get update + sudo apt-get install -y sshfs + ``` + +2. **Garantir que o usuário `deploy` da VPS 4 tem acesso SSH sem senha à VPS 1:** + Adicione a chave SSH pública (`~/.ssh/id_ed25519.pub`) do usuário `deploy` da VPS 4 no arquivo `/home/deploy/.ssh/authorized_keys` da VPS 1. + +3. **Criar a pasta de montagem na VPS de destino (VPS 4):** + ```bash + mkdir -p /home/deploy/instrucoes + ``` + +4. **Montar o diretório manualmente para testar:** + ```bash + sshfs deploy@10.99.0.1:/home/deploy/instrucoes /home/deploy/instrucoes -o IdentityFile=/home/deploy/.ssh/id_ed25519 -o allow_other -o reconnect -o ServerAliveInterval=15 + ``` + +5. **Tornar a montagem permanente pós-reboot (fstab):** + Adicione a seguinte linha ao final do arquivo `/etc/fstab` na VPS de destino: + ```text + deploy@10.99.0.1:/home/deploy/instrucoes /home/deploy/instrucoes fuse.sshfs x-systemd.automount,IdentityFile=/home/deploy/.ssh/id_ed25519,allow_other,reconnect,ServerAliveInterval=15,ServerAliveCountMax=3,_netdev 0 0 + ``` + +--- + +## 🚀 Opção 4: Rsync Automatizado via Cron (Espelhamento Simples) + +Se os agentes nas outras VPSs precisam apenas ler as instruções ou executar instaladores (como o `install.sh`) e você quer uma solução extremamente leve e direta sem montagens de disco. + +### Script de sincronização unidirecional (VPS 1 -> VPS de Destino): + +Na **VPS 1**, crie um script simples ou configure uma tarefa recorrente no Cron para enviar as atualizações: + +```bash +# Sincroniza a pasta de instruções para a VPS 4 através da VPN segura +rsync -avz --delete -e "ssh -i /home/deploy/.ssh/id_ed25519" /home/deploy/instrucoes/ deploy@10.99.0.4:/home/deploy/instrucoes/ +``` + +Você pode programar isso para rodar a cada hora ou a cada 15 minutos de forma silenciosa e imperceptível. + +--- + +## 🎯 Veredito: Qual escolher? + +* **Escolha o Git Privado (Opção 1)** se você deseja que múltiplos agentes (incluindo IAs) façam alterações nos scripts e nos documentos de forma colaborativa, sem riscos de conflitos cegos de escrita e mantendo histórico de auditoria perfeito. +* **Escolha o SSHFS (Opção 3)** se você quer facilidade máxima de implementação imediata: a pasta fica unificada, consome armazenamento físico de apenas uma máquina e reflete edições instantaneamente sem sincronizações adicionais. diff --git a/monitor_cal_install.sh b/monitor_cal_install.sh new file mode 100755 index 0000000..d0201ef --- /dev/null +++ b/monitor_cal_install.sh @@ -0,0 +1,192 @@ +#!/bin/bash +# ============================================================================== +# 🚀 SCRIPT DE INSTALAÇÃO UNIFICADA: ALERTAS SSH (GCAL + TELEGRAM + PAM) +# ============================================================================== +# Este script automatiza o deploy completo da arquitetura de monitoramento em +# qualquer VPS da rede. Ele configura o PAM, Python, Telegram e Banners. +# ============================================================================== + +# Cores para formatação de saída +RED='\033[0;31m' +GREEN='\033[0;32m' +YELLOW='\033[1;33m' +NC='\033[0m' # Sem Cor + +echo -e "${YELLOW}========================================================================${NC}" +echo -e "${YELLOW} 🛡️ MONITORAMENTO SSH AUTOMÁTICO - INSTALADOR DE DEPLOY ${NC}" +echo -e "${YELLOW}========================================================================${NC}" + +# 1. Verificar se é root +if [ "$EUID" -ne 0 ]; then + echo -e "${RED}Erro: Este script precisa ser executado como root (sudo ./install.sh).${NC}" + exit 1 +fi + +# 2. Captura de Parâmetro de VPS (IP ou Nome) +VPS_PREFIX="" +while [[ "$#" -gt 0 ]]; do + case $1 in + --vps) VPS_PREFIX="$2"; shift ;; + *) echo "Parâmetro desconhecido: $1"; exit 1 ;; + esac + shift +done + +# Se não foi passado --vps, tenta auto-detectar o IP da interface wg0 (VPN) ou eth0 +if [ -z "$VPS_PREFIX" ]; then + echo -e "${YELLOW}Auto-detectando o IP da VPS...${NC}" + # Tenta pegar o IP da interface wg0 primeiro + VPS_PREFIX=$(ip -o -4 addr show dev wg0 2>/dev/null | awk '{split($4,a,"/"); print a[1]}') + + if [ -z "$VPS_PREFIX" ]; then + # Tenta pegar o IP da interface eth0 + VPS_PREFIX=$(ip -o -4 addr show dev eth0 2>/dev/null | awk '{split($4,a,"/"); print a[1]}') + fi +fi + +if [ -z "$VPS_PREFIX" ]; then + VPS_PREFIX="127.0.0.1" +fi + +echo -e "${GREEN}✅ Prefixo/IP Identificado para esta VPS: ${YELLOW}$VPS_PREFIX${NC}" + +# 3. Instalação de Dependências +echo -e "\n${YELLOW}[Passo 1/6] Instalando pacotes e dependências (Apt)...${NC}" +apt-get update -qq +apt-get install -y -qq python3-googleapi curl +echo -e "${GREEN}✅ Pacotes instalados com sucesso.${NC}" + +# 4. Criar Chave de Conta de Serviço se não existir +echo -e "\n${YELLOW}[Passo 2/6] Verificando chave da Conta de Serviço Google Cloud...${NC}" +if [ ! -f "/etc/ssh/gcal_key.json" ]; then + echo -e "${YELLOW}⚠️ Aviso: O arquivo /etc/ssh/gcal_key.json não foi encontrado.${NC}" + echo -e "${YELLOW}Por favor, certifique-se de salvar a chave JSON da conta de serviço em /etc/ssh/gcal_key.json e aplicar as permissões corretas.${NC}" +else + echo -e "${GREEN}✅ Chave da Conta de Serviço detectada em /etc/ssh/gcal_key.json.${NC}" + chown root:deploy /etc/ssh/gcal_key.json 2>/dev/null || chown root:root /etc/ssh/gcal_key.json + chmod 640 /etc/ssh/gcal_key.json +fi + +# 5. Criar arquivo de configurações se não existir +echo -e "\n${YELLOW}[Passo 3/6] Criando arquivo de configurações centralizadas (/etc/ssh/ssh_alerts_config.json)...${NC}" +if [ ! -f "/etc/ssh/ssh_alerts_config.json" ]; then + cat < /etc/ssh/ssh_alerts_config.json +{ + "telegram_token": "8641435108:AAGL3rOiVj1GpYAyUi4D-pdeDJ9K_JUdlgM", + "telegram_chat_id": "", + "calendar_id": "385857c79ef3aed0f4923b29007637a8b7764d6f8359959500bce27611833f5d@group.calendar.google.com" +} +EOF + echo -e "${GREEN}✅ Arquivo de configurações criado.${NC}" +else + echo -e "${GREEN}✅ Arquivo de configurações já existe. Mantendo configurações atuais.${NC}" +fi +chown root:deploy /etc/ssh/ssh_alerts_config.json 2>/dev/null || chown root:root /etc/ssh/ssh_alerts_config.json +chmod 640 /etc/ssh/ssh_alerts_config.json + +# 6. Criar Scripts Integradores no Servidor +echo -e "\n${YELLOW}[Passo 4/6] Configurando scripts integradores em /usr/local/bin/...${NC}" + +# Copia ou escreve o script principal Python +if [ -f "ssh_gcal_alert.py" ]; then + cp ssh_gcal_alert.py /usr/local/bin/ssh_gcal_alert.py +else + # Escreve o arquivo diretamente se rodando solto + curl -s https://raw.githubusercontent.com/sua-uri-ou-copia-local/ssh_gcal_alert.py -o /usr/local/bin/ssh_gcal_alert.py 2>/dev/null +fi +chown root:root /usr/local/bin/ssh_gcal_alert.py +chmod 755 /usr/local/bin/ssh_gcal_alert.py + +# Copia ou escreve o script do instalador Telegram +if [ -f "ssh_alert_setup_telegram.py" ]; then + cp ssh_alert_setup_telegram.py /usr/local/bin/ssh_alert_setup_telegram.py +else + curl -s https://raw.githubusercontent.com/sua-uri-ou-copia-local/ssh_alert_setup_telegram.py -o /usr/local/bin/ssh_alert_setup_telegram.py 2>/dev/null +fi +chown root:root /usr/local/bin/ssh_alert_setup_telegram.py +chmod 755 /usr/local/bin/ssh_alert_setup_telegram.py + +# Criar o gatilho do PAM dinamicamente com o VPS_PREFIX correto +cat < /usr/local/bin/ssh_pam_trigger.sh +#!/bin/bash +# Executa apenas se o estágio do PAM for 'open_session' e o serviço for o 'sshd' +if [ "\$PAM_TYPE" = "open_session" ] && [ "\$PAM_SERVICE" = "sshd" ]; then + USER_LOGIN="\$PAM_USER" + IP_LOGIN="\$PAM_RHOST" + DATE_LOGIN=\$(date "+%Y-%m-%d %H:%M:%S") + + # Se o IP vier vazio (comum em alguns túneis locais), assume localhost + if [ -z "\$IP_LOGIN" ]; then + IP_LOGIN="127.0.0.1" + fi + + # Validação de IP seguro da VPN + if [[ ! "\$IP_LOGIN" =~ ^10\.99\.0\. ]]; then + AVISO_INDEVIDO="🚨 ALERTA: Acesso fora da rede VPN segura detectado!" + else + AVISO_INDEVIDO="✅ Acesso autorizado através da rede VPN segura." + fi + + # Dispara o script Python de calendário e Telegram em segundo plano + /usr/local/bin/ssh_gcal_alert.py --vps "$VPS_PREFIX" --user "\$USER_LOGIN" --ip "\$IP_LOGIN" --status "\$AVISO_INDEVIDO" > /dev/null 2>&1 & +fi +EOF +chown root:root /usr/local/bin/ssh_pam_trigger.sh +chmod 755 /usr/local/bin/ssh_pam_trigger.sh +echo -e "${GREEN}✅ Scripts integradores configurados e autorizados.${NC}" + +# 7. Configurar o PAM +echo -e "\n${YELLOW}[Passo 5/6] Configurando o subsistema PAM para SSH (/etc/pam.d/sshd)...${NC}" +PAM_LINE="session optional pam_exec.so type=open_session /usr/local/bin/ssh_pam_trigger.sh" + +if grep -q "ssh_pam_trigger.sh" /etc/pam.d/sshd; then + echo -e "${GREEN}✅ PAM para SSH já está devidamente configurado (ignorado para evitar duplicidade).${NC}" +else + echo "$PAM_LINE" >> /etc/pam.d/sshd + echo -e "${GREEN}✅ Gatilho do PAM anexado com sucesso ao fim do arquivo /etc/pam.d/sshd.${NC}" +fi + +# 8. Configurar o Banner Visual do Terminal (profile.d) +echo -e "\n${YELLOW}[Passo 6/6] Configurando banner visual de auditoria no terminal (/etc/profile.d/ssh_alert.sh)...${NC}" +cat < /etc/profile.d/ssh_alert.sh +#!/bin/bash +# Script de Banner de Auditoria SSH + +USER_LOGIN=\$USER +IP_LOGIN=\$(echo \$SSH_CONNECTION | awk '{print \$1}') +DATE_LOGIN=\$(date "+%Y-%m-%d %H:%M:%S") + +# Validação de IP seguro da VPN (10.99.0.X) +if [[ ! "\$IP_LOGIN" =~ ^10\.99\.0\. ]]; then + AVISO_INDEVIDO="🚨 ALERTA: Acesso fora da rede VPN segura detectado!" +else + AVISO_INDEVIDO="✅ Acesso autorizado através da rede VPN segura." +fi + +# Exibição do Banner de Auditoria ao Usuário no Terminal +echo -e "\033[1;33m" +echo "=========================================================================" +echo " 🖥️ AUDITORIA DE ACESSO SISTÊMICO " +echo "=========================================================================" +echo -e "\033[0m" +echo " Usuário Conectado: \$USER_LOGIN" +echo " IP de Origem: \$IP_LOGIN" +echo " Data do Login: \$DATE_LOGIN" +echo " Status do Canal: \$AVISO_INDEVIDO" +echo "" +echo " * Todas as operações estão sendo monitoradas e auditadas." +echo "=========================================================================" +echo "" +EOF +chmod 755 /etc/profile.d/ssh_alert.sh +echo -e "${GREEN}✅ Banner visual de terminal ativado.${NC}" + +# Finalização e Próximos Passos +echo -e "\n${GREEN}========================================================================${NC}" +echo -e "${GREEN}🎉 INSTALAÇÃO CONCLUÍDA COM SUCESSO!${NC}" +echo -e "${GREEN}========================================================================${NC}" +echo -e "\n${YELLOW}👉 PRÓXIMO PASSO (VINCULAR TELEGRAM):${NC}" +echo -e "Para receber notificações instantâneas no seu Telegram, execute o comando abaixo" +echo -e "como administrador e envie uma mensagem para o seu bot:" +echo -e "\n ${GREEN}sudo /usr/local/bin/ssh_alert_setup_telegram.py${NC}\n" +echo -e "========================================================================" diff --git a/monitoramento-calendar.md b/monitoramento-calendar.md new file mode 100644 index 0000000..5f5a27f --- /dev/null +++ b/monitoramento-calendar.md @@ -0,0 +1,121 @@ +# 📅 Guia de Implementação: Alertas de SSH no Google Calendar & Telegram + +Este guia fornece o instalador automatizado, scripts de configuração dinâmica e documentação técnica para implantar o sistema de monitoramento, auditoria de logins e alertas em tempo real em qualquer servidor da sua rede (ex: VPS 4, VPS 1, etc.). + +--- + +## 🏗️ Como o Sistema Funciona + +Para garantir que **100% de todos os acessos** sejam auditados (incluindo acessos de túneis de portas `-N`, SFTP, conexões VS Code e logins interativos) de forma robusta e assíncrona, o sistema é dividido em dois módulos integrados: + +```text +[Login SSH Concluído] + │ + ├─► [Gatilho do PAM: /etc/pam.d/sshd] (Intercepta todas as sessões: túneis, VS Code, shell, etc.) + │ │ + │ └─► [Executa em Background: /usr/local/bin/ssh_pam_trigger.sh] + │ │ + │ └─► [Chama: /usr/local/bin/ssh_gcal_alert.py] + │ │ + │ ├─► [Busca GeoIP & ISP] (Cidade, Estado, País e Operadora) + │ │ + │ ├─► [Rate-Limiting / Debounce] (Evita enchentes de alertas em curto tempo) + │ │ + │ ├─► [Local Syslog] (Salva logs localmente em caso de falha de rede) + │ │ + │ ├─► [Telegram Push] ──► Mensagem instantânea no Celular + │ │ + │ └─► [Google Calendar API] ──► Registra Bloco Visual na Agenda + │ + └─► [Sourced: /etc/profile.d/ssh_alert.sh] (Apenas em shells de login interativos) + │ + └─► Exibe Banner de Auditoria Amarelo no Terminal do Usuário +``` + +--- + +## ⚡ Método Rápido (Recomendado - Instalação em 10 segundos) + +Se você já possui o repositório de instruções em seu servidor, a instalação é totalmente automatizada através do script `install.sh`. + +### Passo 1: Executar o Instalador Automático +Acesse a pasta de instruções e execute o instalador como `root` especificando o IP/Prefixo desta nova VPS (ex: `10.99.0.4`): + +```bash +sudo ./install.sh --vps "10.99.0.X" +``` +*(O script irá baixar e configurar todas as dependências, permissões, scripts integradores, PAM e o banner visual do terminal automaticamente).* + +### Passo 2: Vincular o seu Chat do Telegram ao Bot +Para receber as notificações instantâneas no seu celular através do bot `@AcessosVPSbot`, execute o assistente de emparelhamento automático: + +```bash +sudo /usr/local/bin/ssh_alert_setup_telegram.py +``` + +1. Abra o Telegram no seu celular. +2. Pesquise por **`@AcessosVPSbot`** (ou acesse [t.me/AcessosVPSbot](https://t.me/AcessosVPSbot)) e clique em **"Começar"** ou envie `/start`. +3. O terminal detectará instantaneamente a sua mensagem, capturará o seu Chat ID, atualizará a configuração do servidor e enviará uma confirmação no seu chat! + +--- + +## 🛠️ Detalhamento Técnico e Estrutura de Arquivos + +Caso queira entender a estrutura ou realizar alterações manuais, o ecossistema é formado pelos seguintes componentes: + +### 1. Arquivo de Configuração Centralizada (`/etc/ssh/ssh_alerts_config.json`) +Guarda as chaves e credenciais de forma segura, com permissões restritas apenas para leitura (`chmod 640` para `root:deploy`). +```json +{ + "telegram_token": "8641435108:AAGL3rOiVj1GpYAyUi4D-pdeDJ9K_JUdlgM", + "telegram_chat_id": "SEU_CHAT_ID_CAPTURADO_AQUI", + "calendar_id": "385857c79ef3aed0f4923b29007637a8b7764d6f8359959500bce27611833f5d@group.calendar.google.com" +} +``` + +### 2. Script de Integração e Decisão (`/usr/local/bin/ssh_gcal_alert.py`) +Escrito em Python 3, realiza a chamada da API do Google Calendar e do Telegram, com tratamento de erros integrado no `syslog` local, controle de frequência (Rate-Limiting de 120s para o mesmo usuário/IP) e enriquecimento de GeoIP/ISP. + +### 3. Script de Gatilho do PAM (`/usr/local/bin/ssh_pam_trigger.sh`) +Intercepta no nível de kernel/autenticação cada abertura de sessão SSH e envia os dados para o script Python em segundo plano. +```bash +#!/bin/bash +if [ "$PAM_TYPE" = "open_session" ] && [ "$PAM_SERVICE" = "sshd" ]; then + USER_LOGIN="$PAM_USER" + IP_LOGIN="$PAM_RHOST" + DATE_LOGIN=$(date "+%Y-%m-%d %H:%M:%S") + + if [ -z "$IP_LOGIN" ]; then + IP_LOGIN="127.0.0.1" + fi + + if [[ ! "$IP_LOGIN" =~ ^10\.99\.0\. ]]; then + AVISO_INDEVIDO="🚨 ALERTA: Acesso fora da rede VPN segura detectado!" + else + AVISO_INDEVIDO="✅ Acesso autorizado através da rede VPN segura." + fi + + /usr/local/bin/ssh_gcal_alert.py --vps "10.99.0.X" --user "$USER_LOGIN" --ip "$IP_LOGIN" --status "$AVISO_INDEVIDO" > /dev/null 2>&1 & +fi +``` + +### 4. Configuração do PAM (`/etc/pam.d/sshd`) +Garante que o gatilho acima seja executado. É adicionada a seguinte linha ao final do arquivo: +```text +session optional pam_exec.so type=open_session /usr/local/bin/ssh_pam_trigger.sh +``` + +### 5. Banner de Terminal (`/etc/profile.d/ssh_alert.sh`) +Exibe o banner amarelo chamativo de auditoria apenas para usuários conectando de forma convencional via shell de terminal interativo. + +--- + +## 🧪 Como Testar + +Para certificar-se de que tudo está rodando adequadamente e simular o disparo direto do PAM com busca de GeoIP externa: + +```bash +sudo PAM_TYPE=open_session PAM_SERVICE=sshd PAM_USER=deploy PAM_RHOST=8.8.8.8 /usr/local/bin/ssh_pam_trigger.sh +``` + +O evento correspondente deverá aparecer na sua agenda imediatamente (em vermelho intenso indicando fora da VPN), e uma mensagem push de alerta chegará instantaneamente no seu Telegram! diff --git a/seguranca_deploy_user.md b/seguranca_deploy_user.md new file mode 100644 index 0000000..d76a841 --- /dev/null +++ b/seguranca_deploy_user.md @@ -0,0 +1,106 @@ +# 🛡️ Guia de Segurança e Liberdade para o Usuário `deploy` + +Na cultura de DevOps moderna, a "lenda" do usuário `deploy` poder trabalhar com total liberdade sem ter acesso ao usuário `root` é, na verdade, uma **melhor prática de segurança chamada "Princípio do Menor Privilégio" (Least Privilege)**. + +Se o usuário `deploy` pudesse dar `sudo su` e virar `root` a qualquer momento, qualquer vulnerabilidade na sua aplicação web (ex: um upload de arquivo malicioso ou injeção de código) daria controle total do servidor inteiro para um invasor. + +Para dar ao usuário `deploy` toda a liberdade de desenvolvimento e publicação de aplicações com **segurança absoluta**, implementamos 4 pilares práticos: + +--- + +## 🏗️ Pilar 1: Controle Total do Diretório Web (Sem `sudo`) +O usuário `deploy` não precisa de permissão de root para alterar os arquivos da aplicação. Basta torná-lo dono dos diretórios de publicação. + +### Prática: +Geralmente usamos a pasta `/var/www/` ou criamos um diretório de aplicações na própria Home do usuário (`/home/deploy/apps/`). +Para dar controle total ao `deploy` sem precisar de `sudo` para editar arquivos: + +```bash +# Criar a pasta do seu projeto +sudo mkdir -p /var/www/meu-app + +# Definir o usuário deploy como proprietário da pasta +sudo chown -R deploy:deploy /var/www/meu-app + +# Aplicar permissões recomendadas (pastas 755 e arquivos 644) +find /var/www/meu-app -type d -exec chmod 755 {} \; +find /var/www/meu-app -type f -exec chmod 644 {} \; +``` + +**Resultado**: O usuário `deploy` agora pode usar Git, SFTP, VSCode, criar arquivos, deletar e subir atualizações dentro de `/var/www/meu-app` com total liberdade e **zero** necessidade de usar `sudo`. + +--- + +## 🐋 Pilar 2: Gerenciamento do Docker sem Root +Se as suas aplicações rodam em Docker (ou Docker Compose), o usuário `deploy` não precisa usar `sudo docker` para gerenciar os containers. + +### Prática: +Adicionamos o usuário `deploy` ao grupo do Docker no Linux: + +```bash +sudo usermod -aG docker deploy +``` + +**Resultado**: Após fazer logout e login novamente, o usuário `deploy` poderá rodar comandos como `docker ps`, `docker compose up -d`, `docker restart` e fazer builds de imagens diretamente, com total liberdade, sem nunca usar `sudo`. + +--- + +## ⚙️ Pilar 3: Sudoers com Limitação Cirúrgica (Segurança Avançada) +Muitas vezes, a aplicação precisa apenas de tarefas muito específicas do sistema operacional, como por exemplo: +* Reiniciar o servidor web Nginx (`systemctl restart nginx`). +* Recarregar as configurações do Nginx (`systemctl reload nginx`). +* Reiniciar um serviço específico da sua aplicação em NodeJS/Python criado no Systemd (`systemctl restart api-app`). + +### Prática: +Em vez de dar acesso total ao `sudo` para o `deploy`, nós liberamos **apenas estes comandos específicos**, sem requisição de senha! + +1. Criamos um arquivo de configuração exclusivo no Sudoers para o `deploy`: + ```bash + sudo nano /etc/sudoers.d/deploy + ``` +2. Adicionamos a regra cirúrgica: + ```text + # Permite que o usuário deploy execute APENAS estes comandos listados como root, sem pedir senha: + deploy ALL=(ALL) NOPASSWD: /usr/bin/systemctl restart nginx, /usr/bin/systemctl reload nginx, /usr/bin/systemctl status nginx + ``` +3. Aplicamos a permissão correta ao arquivo do sudoers: + ```bash + sudo chmod 440 /etc/sudoers.d/deploy + ``` + +**Resultado**: O usuário `deploy` agora pode rodar `sudo systemctl reload nginx` para aplicar uma mudança de domínio na web com total liberdade, mas se ele tentar rodar `sudo apt update` ou `sudo userdel`, o sistema **negará o acesso**. + +--- + +## 🔄 Pilar 4: Processos em Espaço de Usuário (PM2 / Systemd User) +Se a sua aplicação web não roda em Docker e precisa ficar ativa em segundo plano (ex: aplicações Node.js, Python FastAPI, Go), o usuário `deploy` pode gerenciá-la de duas formas sem root: + +### A. Utilizando o PM2 (NodeJS Process Manager) +O PM2 roda diretamente no espaço de memória do usuário `deploy`. +```bash +# Como usuário deploy, instalar e rodar apps: +pm2 start app.js --name "minha-api" +pm2 save +``` +O `deploy` tem controle total para reiniciar (`pm2 restart minha-api`), parar, e ver logs sem precisar do root. + +### B. Serviços Systemd do Usuário (`systemd --user`) +O Linux moderno permite que usuários criem seus próprios arquivos de serviço que rodam sob sua conta na pasta: +`~/.config/systemd/user/` + +Você pode gerenciar o serviço rodando: +```bash +systemctl --user daemon-reload +systemctl --user restart meu-servico.service +``` + +--- + +## 📊 Tabela de Comparação de Segurança: + +| Ação | Como o Root faria (Inseguro) | Como o `deploy` faz com segurança | +| :--- | :--- | :--- | +| **Subir arquivos Web** | Usa `sudo` ou loga como `root` | Altera livremente dentro de `/var/www/` (Dono da pasta) | +| **Gerenciar Containers** | `sudo docker compose restart` | `docker compose restart` (Membro do grupo `docker`) | +| **Reiniciar Nginx** | `sudo systemctl restart nginx` | `sudo systemctl restart nginx` (Autorizado via Sudoers Cirúrgico) | +| **Atualizar Código (Git)** | Roda `git pull` como root | Roda `git pull` usando suas chaves SSH do usuário | diff --git a/vpn-setup.md b/vpn-setup.md new file mode 100644 index 0000000..1297423 --- /dev/null +++ b/vpn-setup.md @@ -0,0 +1,111 @@ +# 🛡️ Plano de Contingência e Alta Disponibilidade da VPN + +Este documento descreve detalhadamente as soluções propostas para evitar o bloqueio de acesso e garantir a continuidade da comunicação entre os servidores (**VPS 3, 4 e 5**) caso o servidor central de VPN (**VPS 1**) sofra uma queda ou falha de sistema. + +--- + +## 🚨 O Problema: O Ponto Único de Falha (SPOF) +Atualmente, a rede privada utiliza uma topologia em **Estrela (Hub-and-Spoke)**, onde a **VPS 1** é o Hub central. Se a VPS 1 cair: +1. A rede VPN criptografada (`10.99.0.0/24`) deixa de funcionar. +2. A comunicação interna entre os servidores (como o envio de dados do app para o banco de dados na VPS 3) é interrompida. +3. Como o SSH padrão (porta 22) está fechado na internet pública para as outras VPSs, você fica **impedido de acessar os servidores via terminal de forma convencional**, necessitando recorrer ao Console VNC no painel web da Contabo. + +Abaixo estão as três soluções de contingência, ordenadas de forma prática. + +--- + +## 🚪 Opção A: Estratégia Sênior Zero-Trust (Recomendado - 🛡️ Segurança Absoluta) + +Esta abordagem elimina qualquer necessidade de expor portas SSH na internet pública (mesmo portas altas secundárias). Em vez de manter uma porta pública de "fallback" (vulnerável a ruído de scanners e bots), a administração e o tráfego de diagnóstico são restringidos a **100% de conexões internas criptografadas por VPN WireGuard**. + +### Como mitigar o risco de lockout (Bloqueio de Acesso): +Para evitar o isolamento de acesso caso o servidor central de VPN caia, adota-se uma trilha tripla de contingência: + +1. **Console VNC nativo do Provedor (Ex: Contabo)**: + Mantido ativo na console web do provedor como canal de recuperação direta de emergência e console físico absoluto em caso de desastre. +2. **Peers WireGuard Redundantes (Multi-Device)**: + Configuração de múltiplos dispositivos do administrador autorizados no Hub: + * **Peer 1**: Notebook Principal. + * **Peer 2**: Notebook Reserva, celular corporativo ou VM dedicada. +3. **Backups Offline de Chaves e Configurações**: + Armazenamento das configurações de VPN do Wireguard (`wg0.conf`) de forma cifrada offline (Ex: Pendrive criptografado, Cofre físico ou Vault de segurança como Bitwarden/1Password). + +### Vantagens dessa Abordagem: +* **Zero Exposição Pública**: Nenhuma porta além de 80 e 443 (na VPS 1) e da porta UDP do WireGuard ficam abertas na internet. +* **Redução de Overhead**: Conectar de ferramentas administrativas (como DBeaver ou SSH direto) diretamente via IP da VPN (`10.99.0.3`) sem necessidade de fazer túneis SSH adicionais desnecessários sobre o canal VPN. + +--- + +## 🕸️ Opção B: Comunicação Direta entre as VPSs (Full-Mesh - 🛠️ Intermediário) +Consiste em criar túneis diretos do WireGuard entre as VPSs 3, 4 e 5, dispensando a necessidade de a VPS 1 estar online para que elas conversem entre si. + +### Como configurar as rotas diretas: + +Para fazer isso, precisamos adicionar as chaves públicas e os IPs de endpoint físicos das outras VPSs diretamente no arquivo `/etc/wireguard/wg0.conf` de cada uma das máquinas. + +**Exemplo de configuração na VPS 3 (`/etc/wireguard/wg0.conf`):** +```ini +[Interface] +Address = 10.99.0.3/24 +PrivateKey = +ListenPort = 52830 + +# Peer 1: VPS 1 (Hub Central) +[Peer] +PublicKey = +AllowedIPs = 10.99.0.1/32 +Endpoint = 158.220.109.237:51820 +PersistentKeepalive = 25 + +# Peer 2: VPS 4 (Conexão Direta - Redundância) +[Peer] +PublicKey = +AllowedIPs = 10.99.0.4/32 +Endpoint = :51820 +PersistentKeepalive = 25 + +# Peer 3: VPS 5 (Conexão Direta - Redundância) +[Peer] +PublicKey = +AllowedIPs = 10.99.0.5/32 +Endpoint = :51820 +PersistentKeepalive = 25 +``` + +### Vantagens: +* Se a VPS 1 quebrar, as conexões de banco de dados (`10.99.0.3`) das VPSs 4 e 5 continuam funcionando de forma 100% direta e automática. + +--- + +## 🔄 Opção C: VPN Secundária de Backup (Failover Hub - 🛠️ Avançado) +Consiste em configurar a **VPS 3** (Banco de Dados) ou a **VPS 5** (CRM) como um **segundo servidor de VPN (redundante)** rodando sob uma interface separada (ex: `wg1`), criando um caminho de fuga independente. + +### Estrutura de Rede da VPN de Backup: +* **VPN Principal (`wg0`)**: Hub na VPS 1, rede `10.99.0.0/24`. +* **VPN de Backup (`wg1`)**: Hub na VPS 3, rede `10.98.0.0/24`. + +### Configuração da VPS 3 como Hub Redundante (`/etc/wireguard/wg1.conf`): +```ini +[Interface] +Address = 10.98.0.3/24 # IP da VPS 3 na nova rede de backup +PrivateKey = +ListenPort = 51821 # Porta diferente para não colidir com o wg0 + +# Peer 1: Seu Notebook +[Peer] +PublicKey = +AllowedIPs = 10.98.0.10/32 + +# Peer 2: VPS 4 +[Peer] +PublicKey = +AllowedIPs = 10.98.0.4/32 + +# Peer 3: VPS 5 +[Peer] +PublicKey = +AllowedIPs = 10.98.0.5/32 +``` + +### Vantagens: +* Se a VPS 1 desaparecer da internet por completo, basta que você e seus sistemas ativem a interface `wg1` do WireGuard. Toda a sua infraestrutura continuará conectada em questão de segundos através da nova rede segura comandada pela VPS 3! diff --git a/vps3-banco-tuning.md b/vps3-banco-tuning.md new file mode 100644 index 0000000..ea92a80 --- /dev/null +++ b/vps3-banco-tuning.md @@ -0,0 +1,212 @@ +# 🗄️ Guia de Provisionamento e Tuning de Dados: VPS 3 (newwhats) + +Este documento centraliza as instruções práticas de configuração, tuning e provisionamento para o banco de dados principal de produção (**PostgreSQL**) e o cache de alta performance (**DragonflyDB**) hospedados na **VPS 3 dedicada** (especificações físicas: **8 GB de RAM e 4 núcleos de CPU**). + +--- + +## 🏛️ Divisão e Partilha Fisiológica de Recursos (Capacidade: 8 GB RAM / 4 CPUs) + +Para garantir estabilidade absoluta do sistema e impedir que oscilações no tráfego de mensagens do WhatsApp causem o encerramento forçado de serviços pelo OOM (*Out Of Memory Killer*) do Linux, o hardware é segmentado de forma cirúrgica: + +| Componente | Memória Alocada | Threads / CPUs | Função / Justificativa | +| :--- | :--- | :--- | :--- | +| **PostgreSQL shared_buffers** | **2.0 GB** (25%) | Automático (Host) | Cache interno nativo de tabelas e índices de negócio do PostgreSQL. | +| **PostgreSQL work_mem & OS** | **2.2 GB** (~27%) | Automático (Host) | Ordenações locais de queries, conexões e buffers de escrita do banco. | +| **DragonflyDB `--memlimit_gb`** | **3.0 GB** (~38%) | **`--num_threads 2`** | Armazenamento seguro de sessões de WhatsApp, presenças e QR codes ativos. | +| **Sistema Operacional (SO) & Redes** | **800 MB** (~10%) | Reservado (2 CPUs) | Processamento da rede VPN WireGuard, kernel e deamon de firewall. | + +> [!IMPORTANT] +> **Tuning de CPU**: O DragonflyDB é multi-threaded por natureza. Definir `--num_threads 2` confina a execução do cache a apenas 2 núcleos, deixando 2 núcleos de processamento físico totalmente livres para as consultas SQL do PostgreSQL e para a criptografia do túnel Wireguard. + +--- + +## 🚪 Escolha Estratégica do Temporal: **Opção B (Temporal Server na VPS 5)** + +O **Temporal Server** possui uma pegada de RAM ativa que consome entre **400 MB a 800 MB** em produção. Rodá-lo na VPS 3 deixaria a máquina no limite crítico de recursos físicos (apenas ~600 MB livres de folga). + +Portanto, adota-se a **Opção B: Hospedar o Temporal Server na VPS 5 (Aplicação)**: +* **Ganho de Estabilidade**: Preserva a VPS 3 exclusivamente como um *Data Appliance* de alta performance (Postgres + DragonflyDB). +* **Latência Zero de API**: Como o **Temporal Worker** roda ao lado do backend Express na VPS 5, colocá-los na mesma máquina permite que a comunicação entre Worker e Server aconteça via `localhost`, eliminando overhead de rede VPN. +* **Persistência**: O Temporal Server na VPS 5 continuará salvando seus dados persistentes de workflows (agenda/reputação) de forma segura no database dedicado `temporal` na VPS 3 via túnel privado. + +--- + +## 🗄️ 1. Separação de Databases e Privilégios no PostgreSQL + +O banco de dados do negócio (`newwhats`) e a infraestrutura interna do orquestrador (`temporal`) são isolados fisicamente em databases independentes para evitar conflito de migrações (Prisma/Knex vs `temporal-sql-tool`), facilitar backups por tabela e prover auditoria de acessos. + +Acesse o console do PostgreSQL (`sudo -u postgres psql`) e execute o script SQL abaixo: + +```sql +-- ==================================================== +-- 1. CRIAÇÃO DE DATABASES INDEPENDENTES +-- ==================================================== +CREATE DATABASE newwhats; +CREATE DATABASE temporal; + +-- ==================================================== +-- 2. CRIAÇÃO DOS USUÁRIOS/ROLES ESTREITOS +-- ==================================================== +CREATE USER newwhats_user WITH PASSWORD 'SuaSenhaForteNewwhatsAqui'; +CREATE USER temporal_user WITH PASSWORD 'SuaSenhaForteTemporalAqui'; + +-- ==================================================== +-- 3. REVOGAÇÃO DE ACESSOS PÚBLICOS PADRÃO (ZERO-TRUST) +-- ==================================================== +REVOKE ALL ON DATABASE newwhats FROM PUBLIC; +REVOKE ALL ON DATABASE temporal FROM PUBLIC; + +-- ==================================================== +-- 4. ATRIBUIÇÃO DE CONEXÕES EXCLUSIVAS +-- ==================================================== +GRANT CONNECT ON DATABASE newwhats TO newwhats_user; +GRANT CONNECT ON DATABASE temporal TO temporal_user; + +-- ==================================================== +-- 5. CONFIGURAÇÃO DE PRIVILÉGIOS GRANULARES +-- ==================================================== + +-- Conecte no banco 'newwhats' (\c newwhats) e execute: +GRANT USAGE ON SCHEMA public TO newwhats_user; +GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO newwhats_user; +GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA public TO newwhats_user; +ALTER DATABASE newwhats OWNER TO newwhats_user; + +-- Conecte no banco 'temporal' (\c temporal) e execute: +-- O temporal-sql-tool precisa de privilégios plenos dentro de seu banco para autogerenciar tabelas +GRANT ALL PRIVILEGES ON DATABASE temporal TO temporal_user; +ALTER DATABASE temporal OWNER TO temporal_user; +``` + +--- + +## 📊 2. Hardening da Configuração do PostgreSQL (`pg_hba.conf`) + +Edite o arquivo `/etc/postgresql/15/main/pg_hba.conf` para garantir que o acesso ao banco de dados seja liberado apenas para os papéis designados originados da rede interna da VPN Wireguard: + +```text +# TYPE DATABASE USER ADDRESS METHOD + +# 1. Permissões locais do sistema operacional (Apenas Root local) +local all postgres peer + +# 2. Permitir que o backend (VPS 5) conecte apenas no database de negócio +host newwhats newwhats_user 10.99.0.5/32 scram-sha-256 + +# 3. Permitir que o orquestrador Temporal (VPS 5) conecte apenas no database temporal +host temporal temporal_user 10.99.0.5/32 scram-sha-256 + +# 4. Bloqueio preventivo total para qualquer outro IP ou usuário +host all all 0.0.0.0/0 reject +``` + +*Para aplicar as alterações:* +```bash +sudo systemctl reload postgresql +``` + +--- + +## 🚀 3. Provisionamento do DragonflyDB (Systemd) + +O **DragonflyDB** roda nativamente como um serviço leve do sistema, configurado com escuta restrita e controle estrito de memória física. + +### 🛠️ Configuração do Serviço `/etc/systemd/system/dragonfly.service`: + +Crie o arquivo de configuração de unidade do Systemd: + +```ini +[Unit] +Description=DragonflyDB Cache Server +After=network.target +Wants=network-online.target + +[Service] +Type=simple +User=dragonfly +Group=dragonfly +# Inicialização endurecida e otimizada para 8 GB RAM / 4 CPUs +ExecStart=/usr/local/bin/dragonfly \ + --bind 10.99.0.3 \ + --port 6379 \ + --memlimit_gb 3 \ + --num_threads 2 \ + --save_schedule "" \ + --logtostdout \ + --requirepass SENHA_DRAGONFLY_PRODUCAO + +Restart=always +RestartSec=5 +LimitNOFILE=65536 + +[Install] +WantedBy=multi-user.target +``` + +> [!NOTE] +> **Hardening de Escuta**: O parâmetro `--bind 10.99.0.3` substitui o padrão inseguro `0.0.0.0`. Isso força o DragonflyDB a escutar **exclusivamente** as requisições que transitam por dentro do túnel privado do Wireguard, impossibilitando tentativas de conexão direta a partir da internet pública. + +### 🏁 Passos de ativação do serviço: +1. Certifique-se de criar o usuário dedicado do sistema: + ```bash + sudo useradd -r -s /bin/false dragonfly + ``` +2. Recarregue os daemons e ative o DragonflyDB: + ```bash + sudo systemctl daemon-reload + sudo systemctl enable dragonfly + sudo systemctl start dragonfly + ``` + +--- + +## 🏛️ 4. Centralização de Múltiplos Projetos (Database Appliance) + +Centralizar os bancos de dados de todos os seus projetos (ex: `google.com`, `facebook.com`, `newwhats`) na **VPS 3 dedicada**, mantendo as aplicações e frontends isolados na **VPS 1 (ou outras VPSs de app)**, é uma excelente decisão de design. + +Isso separa a computação volátil das aplicações (onde acontecem picos de tráfego, deploys, memory leaks e builds pesados) da consistência estável da camada de persistência de dados. + +### ⚠️ Regras de Segurança e Isolamento Mandatórias: +Para operar esse modelo compartilhado com segurança de nível corporativo e evitar que uma falha em um projeto comprometa ou degrade os outros (efeito *Noisy Neighbor*): + +#### 1. Isolamento Lógico Absoluto (Databases & Roles Independentes) +**Nunca** use o mesmo banco de dados ou o mesmo usuário PostgreSQL para projetos distintos. Cada projeto deve ter seu banco de dados próprio e seu usuário com privilégios restritos ao seu respectivo banco. + +```text +PostgreSQL (VPS 3) +├── database: google_db ──> OWNER: google_user (Apenas VPS 1 / 10.99.0.1) +├── database: facebook_db ──> OWNER: facebook_user (Apenas VPS 1 / 10.99.0.1) +└── database: newwhats ──> OWNER: newwhats_user (Apenas VPS 5 / 10.99.0.5) +``` + +#### 2. Configuração do `pg_hba.conf` para Múltiplos Projetos: +Edite o arquivo `/etc/postgresql/15/main/pg_hba.conf` para mapear de forma cirúrgica as origens permitidas para cada projeto: + +```text +# TYPE DATABASE USER ADDRESS METHOD + +# 1. Permissões de Administração local +local all postgres peer + +# 2. Projeto GOOGLE (Frontend/Backend na VPS 1 -> Banco na VPS 3) +host google_db google_user 10.99.0.1/32 scram-sha-256 + +# 3. Projeto FACEBOOK (Frontend/Backend na VPS 1 -> Banco na VPS 3) +host facebook_db facebook_user 10.99.0.1/32 scram-sha-256 + +# 4. Projeto NEWWHATS (Backend na VPS 5 -> Banco na VPS 3) +host newwhats newwhats_user 10.99.0.5/32 scram-sha-256 + +# 5. BLOQUEIO PADRÃO TOTAL (Zero-Trust) +host all all 0.0.0.0/0 reject +``` + +#### 3. Gestão de Pools de Conexão no Node.js (Prisma/Knex) +Cada aplicação Node.js aberta na VPS 1 tentará criar um pool de conexões persistentes. Se muitos projetos rodarem simultaneamente, as conexões ativas podem saturar a memória RAM da VPS 3 (cada conexão ativa no Postgres é um processo físico consumindo ~10MB-20MB de RAM). +* **Solução**: Restrinja o tamanho máximo de pool nas variáveis de ambiente `.env` de cada projeto na VPS 1: + ```env + # Exemplo de limite de conexões no Prisma + DATABASE_URL="postgresql://google_user:SENHA@10.99.0.3:5432/google_db?connection_limit=10" + ``` +* **PgBouncer (Avançado)**: Se o número de projetos escalonar para dezenas de aplicações na VPS 1, configure o **PgBouncer** na VPS 3 para multiplexar centenas de conexões virtuais em poucas conexões físicas reais do Postgres, reduzindo drasticamente o consumo de RAM. +