Operação
ao redor
do código.

Como a
internet
funciona,
do seu lado.

Quando você digita um endereço no navegador e ele responde, uma sequência de meia dúzia de sistemas acontece em milissegundos. Conhecer essa sequência não é luxo — é o que diferencia quem debuga incidentes em minutos de quem passa madrugada chutando soluções.

A maioria dos desenvolvedores aprende a internet pelo lado de cima — HTTP, APIs, JSON. Esse capítulo trata do lado de baixo, da parte que normalmente "simplesmente funciona" até o dia que para. DNS, TCP, TLS — cada um pode quebrar de forma silenciosa e cada um tem ferramentas próprias de diagnóstico. Vou cobrir o que vale e omitir o que só importa pra quem opera infraestrutura de telecom.

1.1 A história — do ARPANET ao DNS distribuído

1.2 A jornada de um request — o que acontece quando você digita uma URL

Você abre o navegador, digita https://meuapp.com.br/pedidos, pressiona Enter. O que acontece nos próximos 200ms?

# Etapa 1 — DNS lookup (tipicamente 10-50ms na primeira vez, 0ms se cacheado)
Navegador: "qual o IP de meuapp.com.br?"
  → Resolver local (do seu ISP ou Cloudflare 1.1.1.1)
  → Root nameservers (".")
  → TLD nameservers (".br")
  → Authoritative nameservers (da Cloudflare, por exemplo)
  ← "meuapp.com.br = 104.21.42.17"

# Etapa 2 — TCP handshake (1 round-trip, ~20-100ms dependendo de distância)
Navegador → Servidor: SYN
Servidor → Navegador: SYN-ACK
Navegador → Servidor: ACK
  # Conexão TCP estabelecida

# Etapa 3 — TLS handshake (1-2 round-trips, ~40-200ms)
Navegador → Servidor: "falo TLS 1.3, suporto essas cipher suites"
Servidor → Navegador: "OK, aqui meu certificado, vamos usar X"
Navegador: valida certificado, deriva chaves
  # Conexão criptografada estabelecida

# Etapa 4 — HTTP request (1 round-trip, ~20-100ms)
Navegador → Servidor: GET /pedidos HTTP/2 Host: meuapp.com.br ...
Servidor → Navegador: HTTP/2 200 OK + corpo

# Total: tipicamente 200-500ms na PRIMEIRA visita.
# Visitas subsequentes: 50-150ms (DNS cacheado, conexão pode ser reaproveitada).

Cada uma dessas etapas pode falhar de jeitos diferentes, e cada uma tem ferramenta própria de diagnóstico. Erro de DNS retorna "site não encontrado". Erro de TCP retorna "connection refused" ou timeout. Erro de TLS retorna "certificado inválido". Erro de HTTP retorna status code. Saber em qual etapa o erro está é metade do trabalho de debug.

1.3 DNS por dentro — a hierarquia que faz a internet escalar

DNS é um sistema distribuído de tradução de nomes em endereços. Não há servidor central — há uma hierarquia onde cada nível conhece o próximo. Isso é o que permite a internet escalar para bilhões de domínios sem colapsar.

Os atores

• Stub resolver: o cliente DNS no seu sistema operacional. Quando o navegador pede um nome, é ele que faz a pergunta.
• Recursive resolver (ou recursor): servidor DNS do seu ISP, ou público (1.1.1.1 da Cloudflare, 8.8.8.8 do Google, 9.9.9.9 da Quad9). Faz o trabalho de descobrir a resposta seguindo a hierarquia.
• Root nameservers: 13 servidores (lógicos — fisicamente são centenas espalhados) que sabem quem é responsável por cada TLD (.com, .br, .org...).
• TLD nameservers: servidores responsáveis por cada extensão de topo. .br é gerenciado pelo NIC.br; .com pela Verisign.
• Authoritative nameservers: os servidores que têm a resposta para um domínio específico. Quando você usa Cloudflare como DNS, os nameservers da Cloudflare são authoritative pro seu domínio.

O fluxo completo, com exemplo real

Consulta para meuapp.com.br, sem nada cacheado:

1. Stub resolver → Recursive (1.1.1.1):
   "qual o A de meuapp.com.br?"

2. Recursive → Root (a.root-servers.net):
   "qual o A de meuapp.com.br?"
   ← "não sei, mas o .br é com esses nameservers"

3. Recursive → .br TLD (a.dns.br):
   "qual o A de meuapp.com.br?"
   ← "não sei, mas meuapp.com.br tem esses nameservers (kara.ns.cloudflare.com, etc)"

4. Recursive → Authoritative (Cloudflare):
   "qual o A de meuapp.com.br?"
   ← "104.21.42.17, TTL 300s"

5. Recursive → Stub: "104.21.42.17"
   (Recursive guarda em cache por TTL segundos)

6. Stub → Navegador: "104.21.42.17"
   (Sistema operacional pode cachear também)

Daqui pra frente, qualquer consulta nos próximos 300s 
pega do cache — não passa por esses 4 níveis de novo.

Isso parece complexo mas acontece em milissegundos. E em condições normais, 90% das consultas batem direto no cache do recursive sem ir até a authoritative. É o que torna o DNS rápido na prática.

1.4 Tipos de registro — o que cada um significa

Um domínio é, na verdade, um conjunto de registros DNS. Cada tipo de registro serve a um propósito. Os que você precisa conhecer:

A pegadinha do CNAME

CNAME parece o registro mais útil — "aponta esse nome pra esse outro nome". Mas tem duas armadilhas que pegam quase todo iniciante:

1. CNAME não pode coexistir com outros registros no mesmo nome. Se www.meusite.com tem CNAME, ele não pode ter A, MX, TXT etc. nesse mesmo nome. Por isso você não usa CNAME no domínio raiz (meusite.com) — esse precisa ter MX para email.
2. CNAME no apex (raiz) é tecnicamente proibido pela RFC. meusite.com como CNAME viola o padrão. Cloudflare e alguns DNS modernos implementam "CNAME flattening" (resolvem internamente e devolvem o A final), o que contorna a limitação. Mas se você usa registro.br direto, não pode CNAME no apex — precisa A com IP fixo, ou usar nameservers de provedor que faça flattening.

ANAME, ALIAS — primos do CNAME

Vários provedores DNS criaram registros próprios pra resolver o problema do apex: ANAME (DNSimple), ALIAS (DNS Made Easy, Cloudflare flatten). Funcionam como CNAME mas no apex. Não são padrão — funcionam só dentro do seu provedor DNS. Se você precisa apontar meusite.com direto para serviço externo (Vercel, Netlify), use o provedor DNS que oferece flattening ou aceite usar IPs fixos.

1.5 TTL e propagação — por que mudanças levam tempo

TTL (Time To Live) é o número de segundos que um recursive resolver pode cachear uma resposta antes de perguntar de novo. É configurado por registro, no servidor authoritative.

Implicação prática: quando você muda um registro, a mudança não propaga imediatamente. Resolvers ao redor do mundo têm a versão antiga em cache até o TTL anterior expirar.

# Cenário comum: vou mudar IP do meu servidor.
# IP atual: 1.2.3.4, TTL atualmente 86400 (24h).

# Sem planejamento:
14h00 - mudo registro A para 5.6.7.8
14h01 - alguns usuários veem novo IP (cache do resolver expira logo)
22h00 - maioria já vê novo IP
14h00+24h - todos veem novo IP

# Com planejamento:
1 dia ANTES da mudança:
  - mudo TTL de 86400 para 300 (5 minutos)
  - espero 24 horas (que era o TTL antigo) para garantir que todos
    os resolvers pegaram a nova versão com TTL curto

14h00 - mudo IP para 5.6.7.8
14h05 - praticamente todos veem novo IP
  
1 dia DEPOIS, se quiser:
  - aumento TTL de volta para 3600 ou 86400

TTL escolhido bem

1.6 Registrars: BR vs internacional

Para registrar um domínio você precisa de um registrar — empresa autorizada pelo órgão responsável pelo TLD. Para .com.br, é o registro.br. Para .com, são dezenas de empresas (GoDaddy, Namecheap, Cloudflare Registrar, Porkbun, etc.).

registro.br — o caso brasileiro

Modelo único no mundo: o NIC.br é uma entidade sem fins lucrativos, e registro.br é o registrar ÚNICO para .br. Não há "GoDaddy do .br". Você compra direto deles.

Vantagens:

• Preço fixo, transparente: R$ 40/ano em 2026 (verifique site oficial).
• Sem upsell agressivo, sem renovações disfarçadas a preço alto.
• Interface honesta, foco em técnica.
• Suporte direto (e-mail/web) bom.

Limitações:

• DNS deles é funcional mas básico. Sem CNAME flattening, sem analytics, sem features modernas.
• Painel é datado.
• Operações como transferência ou redelegação seguem padrão burocrático.

Registrars internacionais

Para domínios genéricos (.com, .dev, .io, .app), você escolhe entre muitos. Em 2026, três opções honestas:

• Cloudflare Registrar: vende a preço de custo (~$10/ano para .com). Sem upsell. Funciona bem se você já usa Cloudflare como DNS. Limitação: só registra TLDs específicos, não tem suporte humano premium.
• Porkbun: preços bons, interface boa, sem pegadinha. Bom para domínios secundários.
• Namecheap: tradicional, suporte decente, preços médios. Cuidado com renovações automáticas a preços maiores que o registro inicial.

Evite GoDaddy: cheio de upsells, interface confusa, histórico de incidentes de segurança. Funciona, mas há alternativas melhores.

Padrão recomendado em 2026

1. Registre seu domínio no registrar (registro.br, Cloudflare Registrar, Porkbun).
2. Use DNS de outro provedor (Cloudflare DNS é gratuito e excelente — vamos cobrir no próximo capítulo).
3. Aponte os nameservers no registrar para os do provedor DNS.

Essa separação (registrar para registro, provedor para DNS) é a configuração mais flexível e robusta. Você pode trocar de provedor DNS sem mexer no registrar; pode trocar de registrar mantendo DNS.

1.7 Trocando nameservers — o passo que muda tudo

Quando você compra um domínio, ele vem com nameservers do próprio registrar. Pra usar Cloudflare (ou outro), você precisa mudar os nameservers no painel do registrar.

# Antes:
# meudominio.com.br
#   NS: a.dnsbr.registro.br
#   NS: b.dnsbr.registro.br
#   (DNS gerenciado pelo registro.br)

# Você abre conta na Cloudflare, adiciona o domínio, ela gera:
# Nameservers atribuídos: kara.ns.cloudflare.com, walt.ns.cloudflare.com

# No painel do registro.br, em "DNS":
# Substituir os NS antigos pelos da Cloudflare.

# Depois:
# meudominio.com.br
#   NS: kara.ns.cloudflare.com
#   NS: walt.ns.cloudflare.com
#   (DNS agora gerenciado pela Cloudflare)

Após a troca, o TLD (.br) passa a delegar consultas para os nameservers da Cloudflare. Você gerencia registros A/MX/TXT/etc no painel da Cloudflare a partir dali.

Cuidados na troca

1. Adicione os registros no novo provedor ANTES de mudar os nameservers no registrar. Se você muda primeiro e depois adiciona, fica com janela de "domínio resolvendo para nada".
2. Mantenha o glue records corretos no registrar. Você só informa NS — o resto fica no provedor DNS.
3. Aguarde propagação antes de remover do antigo provedor. 24-48h é seguro. Use dig +trace pra confirmar.

1.8 Ferramentas de debug — o canivete suíço do DNS

Quando algo não funciona, essas ferramentas dizem o que está realmente acontecendo. Aprenda cada uma.

dig — a referência

# Consulta simples (A record)
$ dig meudominio.com.br

# Consulta tipo específico
$ dig meudominio.com.br MX
$ dig meudominio.com.br TXT
$ dig meudominio.com.br NS

# Consulta direto num resolver específico (útil pra testar Cloudflare vs ISP)
$ dig @1.1.1.1 meudominio.com.br
$ dig @8.8.8.8 meudominio.com.br

# Trace completo — mostra a hierarquia inteira (root → TLD → authoritative)
$ dig +trace meudominio.com.br

# Saída curta, só o valor
$ dig +short meudominio.com.br
104.21.42.17

# Consulta sem cache (pergunta direto ao authoritative)
$ dig @kara.ns.cloudflare.com meudominio.com.br

nslookup — alternativa multiplataforma

Funciona em Windows nativo (dig nem sempre). Saída mais simples, menos info técnica. Use quando dig não está disponível.

host — a mais simples

host meudominio.com.br retorna A, MX, IPv6 em uma linha cada. Bom pra checagem rápida.

Ferramentas web — quando não tem terminal

• dnschecker.org: mostra resposta de dezenas de resolvers ao redor do mundo. Útil pra ver propagação.
• mxtoolbox.com: bom para registros MX e diagnóstico de email.
• dig.whois.com.br: versão brasileira simples.
• 1.1.1.1/help (Cloudflare): mostra qual resolver você está usando agora.

Limpar cache local

# macOS
$ sudo dscacheutil -flushcache
$ sudo killall -HUP mDNSResponder

# Linux (systemd-resolved)
$ sudo systemd-resolve --flush-caches

# Windows
> ipconfig /flushdns

# Navegador (Chrome): chrome://net-internals/#dns

1.9 Estudo de caso — "o site sumiu"

$ dig +short meuapp.com.br
# Caso A: retorna IP → DNS OK, problema é em outra camada
# Caso B: retorna nada → problema é DNS, vai para passo 2

$ dig +trace meuapp.com.br
# Vai mostrar a cadeia inteira: root → .br → cloudflare.com → seu nameserver.
# Se quebra em algum ponto, mostra exatamente onde.

$ dig NS meuapp.com.br
# Confirma quais nameservers o TLD .br tem registrado para você.
# Eles batem com o que você configurou na Cloudflare?

$ ping 104.21.42.17
# Caso A: ping responde → conectividade OK, vai para passo 4
# Caso B: timeout → problema é de rede/firewall

$ traceroute 104.21.42.17
# Mostra onde a rota está quebrando.

$ nc -vz 104.21.42.17 443
# Testa se a porta 443 (HTTPS) está aceitando conexão.

$ curl -v https://meuapp.com.br
# Mostra detalhes do TLS handshake + resposta HTTP.
# Procure por:
#   - "SSL certificate problem" → cert expirado/inválido
#   - "Connection refused" → servidor não escuta
#   - "Could not resolve host" → DNS de novo
#   - "200 OK" → tudo OK, problema era do cliente!

$ openssl s_client -connect meuapp.com.br:443 -servername meuapp.com.br
# Detalhes completos do certificado: validade, emissor, SAN.

1.10 Erros comuns

1.11 Exercícios

$ dig +short google.com A
# 142.250.190.78 (varia por região)

$ dig +short google.com AAAA
# 2607:f8b0:4004:c1b::65

$ dig +short google.com MX
# 10 smtp.google.com.

$ dig +short google.com TXT
# "v=spf1 include:_spf.google.com ~all"
# "google-site-verification=..."
# (vários registros TXT)

$ dig +short google.com NS
# ns1.google.com. ... ns4.google.com.

# Para ver TTLs, use sem +short:
$ dig google.com
# Coluna entre o nome e o tipo é o TTL em segundos.

$ dig @1.1.1.1 app.empresa.com.br
$ dig @8.8.8.8 app.empresa.com.br
$ dig @9.9.9.9 app.empresa.com.br
$ dig @208.67.222.222 app.empresa.com.br  # OpenDNS

$ dig NS empresa.com.br +short
# Lista nameservers
$ dig @ns1.dnsprovider.com app.empresa.com.br
$ dig @ns2.dnsprovider.com app.empresa.com.br

Cloudflare
na prática:
a camada
gratuita.

Cloudflare é a ferramenta de maior alavancagem que existe para quem opera infra solo ou em time pequeno. Faz o trabalho de CDN, WAF, DDoS protection, DNS, certificado SSL, e analytics — tudo no plano gratuito. Quem não usa, está deixando dinheiro e segurança na mesa.

Você vai usar Cloudflare. A questão é se vai usar bem ou superficial. Esse capítulo cobre o que importa: setup correto desde o primeiro dia, configuração de proxy, SSL/TLS sem se queimar, regras úteis, e quando o gratuito basta e quando vale pagar. Vou ser honesto: cobre tudo o que projetos solo/pequenos precisam dela. Quando você cresce, paga por features específicas — mas isso é problema para depois.

2.1 A história — de CDN a plataforma

2.2 O que Cloudflare é, exatamente

Confusão comum: "Cloudflare é CDN, certo?" É, mas é mais. Em essência, Cloudflare é um proxy reverso global. Quando você ativa Cloudflare num domínio, todo o tráfego passa por ela antes de chegar ao seu servidor.

# Sem Cloudflare:
Usuário → DNS resolve → IP do seu servidor → Sua app responde

# Com Cloudflare (proxy ativado):
Usuário → DNS resolve → IP da Cloudflare (edge) → Cloudflare faz tudo abaixo,
                                                   e só então chama seu servidor:
                                                   ┌──────────────────────────┐
                                                   │ • Termina TLS (HTTPS)    │
                                                   │ • Bloqueia bots óbvios   │
                                                   │ • Aplica WAF (regras)    │
                                                   │ • Serve cache se tiver   │
                                                   │ • Aplica rate limit      │
                                                   │ • Loga analytics         │
                                                   └────────────┬─────────────┘
                                                                ↓
                                              IP do seu servidor → Sua app responde

Implicações:

• Seu IP fica escondido. O mundo vê IP da Cloudflare. Atacante precisa descobrir o IP real para atacar diretamente — e você pode dificultar isso.
• Tráfego passa por servidor próximo do usuário. Brasileiro acessa POP de São Paulo, americano POP de Ashburn. Latência cai.
• Cache no edge é grátis. Cloudflare guarda cópias do seu conteúdo estático em cada POP. Reduz carga no seu servidor.
• DDoS é absorvido por eles. Cloudflare tem capacidade de absorver ataques de centenas de Gbps; seu servidor sozinho cairia.
• HTTPS automático. Cloudflare emite e renova certificado para seu domínio, sem você se preocupar.

2.3 Setup inicial — do zero ao funcionando

O processo completo, do nada à proteção ativa, leva 15-30 minutos. Vou passar cada passo.

Passo 1 · Criar conta

Vá em cloudflare.com, crie conta gratuita. Email + senha. Ative 2FA imediatamente — sua conta Cloudflare controla seu domínio inteiro, então tratamento de segurança é nível "conta de banco".

Passo 2 · Adicionar seu domínio

No dashboard, "Add site". Digite seu domínio (ex: meudominio.com.br). Cloudflare:

1. Escaneia seu DNS atual e importa os registros existentes (A, MX, TXT, etc).
2. Mostra a lista importada — você confirma se está completa.
3. Atribui dois nameservers (algo tipo kara.ns.cloudflare.com e walt.ns.cloudflare.com).

Passo 3 · Mudar nameservers no registrar

No painel do registro.br (ou Porkbun, ou onde quer que seu domínio esteja registrado), substitua os nameservers atuais pelos dois da Cloudflare. Salva. Aguarda propagação — pode levar minutos a horas.

A Cloudflare verifica automaticamente. Quando os nameservers .br confirmarem que os NS oficiais são os deles, o site fica "Active" no painel. Daí pra frente, você gerencia DNS pelo painel da Cloudflare.

Passo 4 · Ativar proxy nos registros certos

Cada registro DNS na Cloudflare tem um ícone de "nuvem": laranja (proxy ativo) ou cinza (DNS apenas, sem proxy). Por default, A/AAAA/CNAME ficam laranja.

• Laranja (proxied): tráfego passa pela Cloudflare. IP escondido, cache aplicado, WAF ativo. Use em registros web (apex, www, app).
• Cinza (DNS only): Cloudflare só responde a query DNS, devolvendo seu IP real. Sem proxy. Use em registros que NÃO devem passar por HTTP: MX (email), subdomínios de SSH (ssh.meusite.com), serviços não-HTTP.

Passo 5 · Configurar SSL/TLS

Esse é o passo onde mais gente erra. Detalhamento próprio adiante.

2.4 Proxy laranja vs cinza — quando usar cada um

A regra geral: se é HTTP/HTTPS, deixe laranja. Se é qualquer outro protocolo, deixe cinza.

Por quê: o proxy da Cloudflare só sabe falar HTTP/HTTPS. Se você ativar laranja em ssh.meusite.com apontando para seu servidor SSH, o SSH para de funcionar (Cloudflare não sabe encaminhar SSH — ela bloqueia tudo que não é HTTP).

Casos comuns:

2.5 SSL/TLS modes — escolha que importa

Cloudflare oferece 4 modos de SSL/TLS no menu SSL/TLS → Overview. Cada um define como o tráfego é criptografado em duas pontas: usuário ↔ Cloudflare, e Cloudflare ↔ seu servidor.

# Off
# Usuário → Cloudflare: HTTP (não criptografado)
# Cloudflare → Servidor: HTTP
# Estado: inaceitável em 2026. Não use.

# Flexible
# Usuário → Cloudflare: HTTPS (criptografado)
# Cloudflare → Servidor: HTTP (não criptografado)
# Estado: PIOR que Off — dá falsa sensação de segurança ao usuário 
# enquanto tráfego ainda passa em claro internamente. Não use.

# Full
# Usuário → Cloudflare: HTTPS
# Cloudflare → Servidor: HTTPS, mas Cloudflare NÃO valida certificado
# Estado: aceita certificado self-signed. Útil para setup, mas vulnerável
# a MITM dentro da rede do servidor. Não use em produção.

# Full (strict)
# Usuário → Cloudflare: HTTPS
# Cloudflare → Servidor: HTTPS, com VALIDAÇÃO do certificado
# Estado: o único modo aceitável em produção. Sempre esse.

Por que Flexible é pior que Off

Parece contra-intuitivo, mas é verdade. Em Off, o navegador do usuário avisa "site não seguro" — usuário sabe que algo não está bem. Em Flexible, o cadeado verde aparece para o usuário, mas o tráfego entre Cloudflare e seu servidor é HTTP puro — qualquer intermediário na rede (provedor da VPS, datacenter, qualquer hop) pode ler/modificar. Pior dos mundos: segurança visual, sem segurança real.

Como configurar Full (strict)

Você precisa de certificado válido no seu servidor. Três opções:

1. Let's Encrypt no servidor: instala certificado real via certbot. Mais trabalho, mas é a opção certa para servidores fora do Coolify/PaaS.
2. Cloudflare Origin Certificate: certificado emitido pela Cloudflare, válido por até 15 anos, mas apenas reconhecido pela Cloudflare (não pelo navegador). Funciona perfeitamente em modo Full (strict). Mais simples — basta gerar no painel e colar no servidor.
3. Plataformas (Coolify, etc): emitem certificado automaticamente. Configure Full (strict) e funciona.

Configuração recomendada para projetos novos: use Cloudflare Origin Certificate. Simples, válido por 15 anos, sem dor de renovação. Vamos cobrir detalhes operacionais nos Caps 4 e 11.

Always Use HTTPS

Em SSL/TLS → Edge Certificates, ative Always Use HTTPS. Isso força redirect de qualquer requisição HTTP para HTTPS no edge da Cloudflare. Sem isso, alguém que acesse http://meudominio.com.br bate em HTTP — você pode até estar com Full strict, mas o link inicial fica fora do túnel.

HSTS — recomendado depois de validação

HSTS (HTTP Strict Transport Security) é header que diz ao navegador "nunca mais aceite HTTP desse domínio, sempre HTTPS, por X meses". Cloudflare oferece configuração simples em SSL/TLS → Edge Certificates → HSTS.

Cuidado: uma vez ativado com max-age grande (ex: 1 ano), você fica preso. Se algum dia tiver problema de HTTPS e quiser servir HTTP temporariamente, navegadores não vão deixar. Ative só depois de meses de operação estável. Para projetos novos, deixe HSTS desligado por algum tempo.

2.6 Page Rules e Rulesets — automação de borda

Cloudflare permite criar regras que executam no edge: redirects, mudanças de cache, headers, bloqueios. Há duas APIs: Page Rules (mais antiga, sendo descontinuada) e Rulesets (nova, mais poderosa).

No plano gratuito, você tem 3 Page Rules. Use bem.

Casos úteis

# Regra 1: Redirect apex para www (ou vice-versa)
# Match: meudominio.com.br/*
# Action: Forwarding URL → 301 → https://www.meudominio.com.br/$1

# Regra 2: Cache agressivo para assets estáticos
# Match: *meudominio.com.br/static/*
# Action: Cache Level → Cache Everything
#         Edge Cache TTL → 1 month

# Regra 3: Bypass cache em endpoints dinâmicos
# Match: *meudominio.com.br/api/*
# Action: Cache Level → Bypass

Rulesets (Configuration Rules, Cache Rules, Origin Rules) substituem Page Rules e são mais flexíveis. No plano gratuito você ganha algumas delas; vale entrar em Rules → Overview e ver o que está disponível.

2.7 Cache estratégico — onde Cloudflare é absurdamente boa

Cache é onde Cloudflare entrega valor desproporcional. Por default, ela já cacheia muitas extensões de arquivo: .css, .js, .jpg, .png, fontes. Mas tem comportamentos importantes a entender.

O que cacheia por default

Cloudflare tem uma lista de extensões "estáticas" que ela cacheia automaticamente, respeitando headers do servidor (Cache-Control, Expires). HTML não é cacheado por default — porque normalmente é dinâmico.

Como ver se está cacheando

Toda resposta passada pela Cloudflare tem header cf-cache-status:

• HIT — serviu do cache. Ótimo.
• MISS — primeira vez, pegou do servidor, salvou no cache.
• EXPIRED — tinha em cache, mas expirou. Vai buscar de novo.
• BYPASS — não cacheou (por configuração ou headers).
• DYNAMIC — Cloudflare considerou dinâmico, não cacheia.

$ curl -I https://meudominio.com.br/static/main.css
HTTP/2 200
content-type: text/css
cf-cache-status: HIT          # servido do cache do edge
age: 8472
cache-control: public, max-age=2592000

Cache Everything — quando vale

Para sites com conteúdo predominantemente público e estático (blog, marketing site, documentação), você pode usar Page Rule com Cache Level: Cache Everything + TTL longo. Toda página fica em cache.

Para apps com usuários autenticados, NÃO use. Cache vai servir conteúdo de um usuário para outro. Catastrófico.

Purge — invalidação manual

Quando você atualiza um arquivo e quer derrubar o cache: vá em Caching → Configuration → Purge Cache. Pode purgar tudo (use com cuidado) ou URLs específicas. API também existe — útil pra integrar no seu CI/CD.

2.8 Segurança gratuita — o que você ganha de graça

No plano gratuito, Cloudflare já entrega:

• DDoS protection ilimitado: ataques de centenas de Gbps absorvidos sem custo extra. Promessa pública da Cloudflare desde 2017.
• WAF managed rules: conjunto curado de regras contra ataques comuns (SQL injection óbvia, XSS, etc). Não substitui WAF pago do plano Pro, mas pega muito.
• Bot Fight Mode: bloqueia bots conhecidos. Em Security → Bots.
• Rate limiting básico: 1 regra grátis, com lógica simples (X requests por Y minutos por IP).
• Browser Integrity Check: verifica que o cliente parece um navegador real.
• Challenge passage: CAPTCHA/Turnstile para visitantes suspeitos.

Security Level — ajuste fino

Em Security → Settings → Security Level:

• Off: não usar.
• Essentially Off: só bloqueia tráfego óbvio malicioso. Para APIs com tráfego de servidores legítimos (webhooks, integrações), considere.
• Low/Medium: padrão razoável.
• High: mais agressivo, pode bloquear usuários legítimos.
• I'm Under Attack: mostra interstitial JavaScript challenge a todos os visitantes. Use apenas durante ataque ativo.

Turnstile — alternativa ao reCAPTCHA

Cloudflare Turnstile é alternativa ao reCAPTCHA do Google. Gratuita, privacy-friendly, funciona melhor para usuário (geralmente passa sem clique). Em Turnstile, gere site key e secret key. Implementa em formulários (signup, login) como faria com reCAPTCHA.

2.9 Quando o plano gratuito basta

Honestamente: para 90% dos projetos individuais e startups iniciais, o plano gratuito basta. O que muda no Pro ($20/mês), Business ($200/mês), Enterprise (custom):

Quando vale o Pro:

• Site com tráfego razoável e você quer image optimization (Polish + Mirage reduzem drasticamente o peso de imagens, sem você fazer nada).
• Você foi atacado por bots/scrapers e o Bot Fight Mode gratuito não está dando conta.
• Você quer WAF mais robusto (OWASP CRS).

Para start, comece no gratuito. Mude quando dor concreta justificar.

2.10 Firewall: aceitar só Cloudflare

Você ativou proxy laranja. Cloudflare protege. Mas seu servidor ainda está exposto em IP público — se alguém descobrir o IP real, conecta direto, bypassa Cloudflare inteira.

A defesa: configure firewall do servidor para aceitar HTTP/HTTPS apenas dos ranges de IP da Cloudflare. Conexões diretas (sem passar pela Cloudflare) são bloqueadas.

# Cloudflare publica os ranges atualizados em:
# https://www.cloudflare.com/ips-v4
# https://www.cloudflare.com/ips-v6

# Script para configurar ufw aceitando só Cloudflare:

#!/bin/bash
ufw default deny incoming

# SSH primeiro (cuidado pra não se trancar fora)
ufw allow 22/tcp

# HTTP/HTTPS apenas dos IPs da Cloudflare
for ip in $(curl -s https://www.cloudflare.com/ips-v4); do
    ufw allow from $ip to any port 80,443 proto tcp
done

for ip in $(curl -s https://www.cloudflare.com/ips-v6); do
    ufw allow from $ip to any port 80,443 proto tcp
done

ufw enable
ufw status numbered

Vamos cobrir firewall em profundidade no Cap 8. Por agora, registre: ativar Cloudflare proxy não é suficiente sem fechar o servidor para o resto do mundo.

2.11 Estudo de caso — configuração inicial completa

Tipo  Nome    Valor              Proxy
A     @       5.6.7.8            Laranja
A     www     5.6.7.8            Laranja
A     ssh     5.6.7.8            Cinza   # SSH precisa IP real

# Salvar:
sudo nano /etc/ssl/certs/cloudflare-origin.pem
# colar certificate
sudo nano /etc/ssl/private/cloudflare-origin.key
# colar private key
sudo chmod 600 /etc/ssl/private/cloudflare-origin.key

# Configurar Nginx para HTTPS:
sudo nano /etc/nginx/sites-enabled/meuapp

# Dentro:
server {
    listen 443 ssl http2;
    server_name meuapp.com.br www.meuapp.com.br;
    
    ssl_certificate /etc/ssl/certs/cloudflare-origin.pem;
    ssl_certificate_key /etc/ssl/private/cloudflare-origin.key;
    
    location / {
        proxy_pass http://localhost:8000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

sudo nginx -t && sudo systemctl reload nginx

2.12 Erros comuns

2.13 Exercícios

# Page Rule 1 — Assets imutáveis (com hash no nome)
# Match: *meusite.com.br/_astro/*
# Setting: Cache Level → Cache Everything
# Setting: Edge Cache TTL → 1 year (max disponível)
# Setting: Browser Cache TTL → 1 year
# Justificativa: hash no nome significa que mudança de arquivo
# gera nome novo. Cache eterno é seguro.

# Page Rule 2 — Bypass cache em endpoints dinâmicos
# Match: *meusite.com.br/api/*
# Setting: Cache Level → Bypass
# Justificativa: sempre dinâmico, cache só atrapalha.

# Page Rule 3 — Cache de páginas HTML
# Match: meusite.com.br/*
# Setting: Cache Level → Cache Everything
# Setting: Edge Cache TTL → 1 hour
# Setting: Browser Cache TTL → 5 minutes
# Justificativa: páginas mudam raramente; 1h no edge é OK.
# Browser TTL menor permite que mudanças apareçam em ~5min.
# Quando publicar post novo: purge manual.

# OBS: para o sitemap.xml, não precisa regra própria —
# a Regra 3 vai cobrir. Quando publicar, faz purge.

# Resultado: ~95% das requests servidas direto do edge,
# servidor de origem raramente tocado.

Email do
domínio sem
dor.

Email é o protocolo mais subestimado da internet. Parece simples — "manda mensagem, chega" — e na verdade tem três camadas de autenticação, sistemas de reputação opacos, e mil formas silenciosas de quebrar. Quem não trata com cuidado, ou não consegue enviar email, ou consegue mas ninguém recebe.

Você vai precisar enviar email — confirmação de cadastro, reset de senha, notificações, faturas. E vai precisar receber email no seu domínio — contato@meusite.com.br, suporte@meusite.com.br. Esse capítulo cobre os dois lados sem você precisar virar especialista em SMTP. Vou ser direto sobre o que vale e o que é dor desnecessária.

3.1 A história — de UUCP a DMARC

3.2 Por que email é difícil

Três fatos que explicam quase toda dor:

1. SMTP foi projetado sem autenticação. SPF, DKIM, DMARC são camadas adicionadas depois. Configurar mal qualquer uma quebra entregabilidade silenciosamente — você manda, parece que enviou, e o destinatário nunca recebe.
2. Reputação de IP/domínio é opaca. Gmail, Outlook, Yahoo decidem internamente se seu email vai pra inbox, spam ou se some. Não há recurso, suporte ou explicação. Você precisa de IPs "limpos" e domínio com histórico bom.
3. Recebimento e envio são dois sistemas separados. Receber emails em contato@meusite.com.br é um problema; enviar de noreply@meusite.com.br é outro. Frequentemente usa serviços diferentes.

3.3 MX records — para onde vai o email recebido

Quando alguém envia email para voce@meusite.com.br, o servidor SMTP do remetente faz consulta DNS:

$ dig MX meusite.com.br +short
10 mail.meusite.com.br.
20 mail2.meusite.com.br.

Os números (10, 20) são prioridades. Menor número = maior prioridade. O remetente tenta o de prioridade 10 primeiro; se falhar, tenta o 20. Permite redundância.

Os valores apontam para nomes — o remetente vai resolver esses nomes em IPs e fazer SMTP. Importante: MX records apontam para nomes, não para IPs diretamente.

Tipos de configuração comum

Quando MX é vazio

Se você não pretende receber email no domínio (só envia), pode configurar MX null:

# Null MX (RFC 7505): diz explicitamente "não aceito email aqui"
MX  0  .

# Servidores remetentes que respeitam RFC entendem que devem rejeitar
# o email imediatamente, sem retry. Reduz spam para você.

3.4 SPF — autorizando remetentes

SPF (Sender Policy Framework) é um registro TXT no DNS que lista quais servidores podem enviar email em nome do seu domínio. Quando um servidor de destino recebe email "de" algo@meusite.com.br, ele consulta o SPF e verifica se o servidor que está enviando está autorizado.

# Exemplo de SPF — registro TXT no apex do domínio:

meusite.com.br.  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

# Decomposição:
# v=spf1                          → versão 1 (única que existe na prática)
# include:_spf.google.com         → autoriza servidores listados pelo Google
# include:sendgrid.net            → autoriza servidores do SendGrid
# ~all                            → tudo o mais: softfail (suspeito mas aceita)

Mecanismos comuns

Erros comuns em SPF

SPF típico para projetos pequenos

# Recebe no Google Workspace, envia transacional pelo Resend:
"v=spf1 include:_spf.google.com include:_spf.resend.com ~all"

# Recebe no Migadu, envia transacional pelo SES da AWS:
"v=spf1 include:_spf.migadu.com include:amazonses.com ~all"

# Não envia email do domínio (só recebe):
"v=spf1 -all"

3.5 DKIM — assinatura criptográfica

DKIM adiciona assinatura digital a cada email enviado. O servidor de envio assina o conteúdo com uma chave privada; o servidor de recebimento busca a chave pública no DNS e valida.

# 1. Você configura serviço (Resend, SendGrid, Google, etc).
# 2. Ele te dá um TXT record para adicionar no seu DNS:

selector1._domainkey.meusite.com.br.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA..."

# 3. Quando o serviço envia email "de" meusite.com.br, adiciona header:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
                d=meusite.com.br; s=selector1;
                h=from:to:subject:date;
                bh=...; b=...

# 4. Servidor de recebimento faz:
   - lê "d=meusite.com.br" e "s=selector1"
   - consulta DNS: dig TXT selector1._domainkey.meusite.com.br
   - obtém a chave pública
   - valida assinatura

# Se válido: email confirmadamente vem de servidor autorizado.
# Se inválido: marcado como suspeito ou rejeitado.

Pontos importantes

• Selectors permitem múltiplas chaves. Cada serviço usa um selector próprio (selector1, google, k1, etc). Você pode ter vários simultaneamente.
• Você não escreve o DKIM manualmente. Os serviços geram o registro completo; você só copia/cola no DNS.
• Rotação de chaves é boa prática. Serviços maduros rotacionam DKIM periodicamente; o painel mostra a chave atualizada quando isso acontece.
• DKIM valida conteúdo, não remetente. Garante que o email não foi modificado em trânsito e veio do servidor autorizado.

3.6 DMARC — política e relatórios

DMARC junta SPF e DKIM e define o que fazer quando algum deles falha. É o registro mais importante hoje (e o mais frequentemente esquecido).

# DMARC vai no subdomínio _dmarc:

_dmarc.meusite.com.br.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@meusite.com.br; pct=100; adkim=s; aspf=s"

# Decomposição:
# v=DMARC1                          → versão
# p=quarantine                      → política: o que fazer com falhas
# rua=mailto:dmarc@meusite.com.br   → onde mandar relatórios agregados (diários)
# pct=100                           → aplica a 100% dos emails
# adkim=s                           → DKIM em modo strict
# aspf=s                            → SPF em modo strict

Política (p=)

• p=none: não faz nada com falhas, mas reporta. Use no início para monitorar sem bloquear.
• p=quarantine: manda falhas para spam. Recomendado quando você tem confiança nos seus SPF/DKIM.
• p=reject: rejeita falhas no servidor. Maior nível, recomendado quando tudo estiver maduro.

Fluxo recomendado de adoção

1. Semana 1-4: p=none com rua= apontando para email seu. Monitora relatórios. Ajusta SPF e DKIM até zero falhas.
2. Semana 5-8: p=quarantine; pct=10. Manda 10% das falhas para spam. Observe se quebra algo legítimo.
3. Semana 9-12: aumenta gradualmente pct para 50, depois 100.
4. Semana 13+: muda para p=reject com pct=100. Maturidade total.

Lendo relatórios DMARC

Os relatórios são XML, enviados diariamente. Lê na mão é doloroso. Serviços que processam pra você:

• Postmark DMARC Monitoring (gratuito): pega seu rua, processa, manda relatório semanal legível por email.
• dmarcian: dashboard mais completo, grátis para projetos pequenos.
• EasyDMARC: alternativa com tier gratuito.

Para projeto solo/pequeno: comece com Postmark DMARC Monitoring. Simples, eficaz, grátis.

3.7 Email transacional — enviando da aplicação

Quando sua aplicação envia email (confirmação de cadastro, reset de senha, notificações, faturas), você usa um serviço de email transacional. Esses serviços já têm IPs com boa reputação, gerenciam SPF/DKIM, escalam, e expõem API simples.

Opções honestas em 2026

Recomendação prática

• Começando agora: Resend. Free tier generoso, API moderna, documentação excelente, setup em 15 minutos.
• Volume alto, custo crítico: AWS SES. Mais barato em escala, mas exige mais trabalho de setup e monitoring.
• Premium para entregabilidade: Postmark. Caro relativo, mas a entregabilidade é referência da indústria.

Setup típico (Resend como exemplo)

1. Criar conta em resend.com.
2. Adicionar seu domínio. Resend gera 3-4 registros DNS: 1 SPF (TXT no apex), 1-2 DKIM (TXT em selector), 1 MX para bounce handling (opcional mas recomendado).
3. Adicionar registros no Cloudflare DNS.
4. Verificar — Resend confere se DNS está propagado, atualiza status.
5. Gerar API key.
6. Enviar email via API.

import resend
import os

resend.api_key = os.environ["RESEND_API_KEY"]

def enviar_confirmacao(email_destino: str, link_confirmacao: str):
    response = resend.Emails.send({
        "from": "noreply@meusite.com.br",
        "to": email_destino,
        "subject": "Confirme seu cadastro",
        "html": f"""
            <h1>Bem-vindo!</h1>
            <p>Clique para confirmar: <a href="{link_confirmacao}">Confirmar</a></p>
        """,
    })
    return response["id"]  # id do envio, útil pra rastrear

3.8 Email pessoal — caixa contato@meusite.com.br

Diferente do transacional, "email pessoal" no domínio é onde você recebe emails (e responde). Quem visita seu site e usa contato@ precisa de uma caixa real.

Opções comparadas

Recomendações por caso

• Só preciso de contato@ que cai no meu Gmail pessoal: Cloudflare Email Routing. Grátis. 5 minutos de setup. Cap 3.9.
• Quero caixa própria, sem pagar muito: Zoho Mail (free 5 usuários) ou Migadu Mini ($19/ano).
• Sou solo dev/freelancer profissional: Fastmail ou Migadu Standard. Pagar pouco vale demais.
• Tenho time, quero docs e drive integrados: Google Workspace ou Microsoft 365.

3.9 Cloudflare Email Routing — encaminhamento grátis

Lançado pela Cloudflare em 2021, gratuito, simples e suficiente para muito caso: configura contato@meusite.com.br para encaminhar para seunome@gmail.com. Não tem caixa própria — emails chegam no seu Gmail/Outlook pessoal.

Setup

1. No painel Cloudflare do domínio, ir em Email → Email Routing.
2. Ativar. Cloudflare adiciona automaticamente os MX records necessários.
3. Adicionar endereços: contato@meusite.com.br → seuemail@gmail.com.
4. Verificar o destino (Cloudflare envia email de confirmação).
5. Configurar catch-all (opcional): qualquer *@meusite.com.br não definido vai pra um endereço fallback.

Limitações

• Não envia. Você recebe via Cloudflare, mas para responder com contato@meusite.com.br precisa de outro caminho (configurar Gmail para enviar como ou usar serviço de email transacional).
• Limite de tamanho: emails acima de 25MB são rejeitados.
• Sem armazenamento próprio: se seu Gmail tiver problema, perdeu o email (não fica cópia na Cloudflare).

Configurar resposta com mesmo endereço

No Gmail: Configurações → Contas e Importação → Enviar email como → Adicionar outro endereço de email. Use SMTP de um serviço transacional (Resend, SES, SendGrid). Daí você responde no Gmail e o destinatário vê contato@meusite.com.br como remetente.

3.10 Debug de entregabilidade

"Mandei email mas não chegou" é um dos pesadelos clássicos. Ferramentas que ajudam:

mail-tester.com

Acessa o site, copia um endereço único que ele gera (algo tipo test-abc123@mail-tester.com), manda email pra esse endereço. Em segundos, te dá score de 0-10 com análise detalhada: SPF, DKIM, DMARC, conteúdo, blacklists. Excelente primeira ferramenta.

mxtoolbox.com

Bom pra verificar registros publicados. Em particular: SuperTool permite consultar MX, SPF, DKIM, DMARC, blacklists de uma vez.

Google Postmaster Tools

Se você envia muito para Gmail, vale ativar. Mostra estatísticas de entregabilidade, reputação do IP, taxa de spam reportada pelos usuários. Diagnóstico premium e grátis.

Análise de headers

Email recebido tem dezenas de headers que contam a história de como chegou. No Gmail: abra email → menu três pontos → "Mostrar original". Headers importantes:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@meusite.com.br header.s=resend
       spf=pass (google.com: domain of bounces@resend.dev) smtp.mailfrom=bounces@resend.dev
       dmarc=pass (p=QUARANTINE sp=NONE) header.from=meusite.com.br

Received-SPF: pass
Return-Path: <bounces@resend.dev>
From: "Eu" <noreply@meusite.com.br>
DKIM-Signature: v=1; a=rsa-sha256; ...

# O que olhar:
# - dkim=pass / dkim=fail   → assinatura DKIM verificada?
# - spf=pass / spf=fail     → SPF passou?
# - dmarc=pass / dmarc=fail → DMARC passou?
# - Authentication-Results  → resumo do que Gmail validou

Listas de bloqueio (RBLs)

Se seu IP de envio caiu em blacklist (Spamhaus, SpamCop, Barracuda), emails serão rejeitados por muitos destinos. mxtoolbox.com/blacklists.aspx verifica em ~100 listas de uma vez. Se você usa serviço transacional (Resend, SES), o IP é deles — preocupação não é sua, em geral.

3.11 Estudo de caso — configuração completa de domínio novo

Tipo  Nome                     Valor                                      Proxy
# Cloudflare Email Routing — recebimento
MX    @                        isaac.mx.cloudflare.net  (priority 36)     —
MX    @                        amir.mx.cloudflare.net   (priority 50)     —
MX    @                        linda.mx.cloudflare.net  (priority 90)     —

# SPF — autoriza tanto Cloudflare Email (recebimento via SRS) quanto Resend (envio)
# Importante: combine TUDO num único TXT no apex
TXT   @                        v=spf1 include:_spf.mx.cloudflare.net include:_spf.resend.com ~all

# DKIM do Resend
TXT   resend._domainkey        p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCB...

# DMARC — começa em modo monitoramento
TXT   _dmarc                   v=DMARC1; p=none; rua=mailto:dmarc-reports@meuapp.com.br

# Bounce handler do Resend
MX    send                     feedback-smtp.us-east-1.amazonses.com (priority 10)
TXT   send                     v=spf1 include:amazonses.com ~all

$ curl -X POST 'https://api.resend.com/emails' \
       -H 'Authorization: Bearer re_SUA_API_KEY' \
       -H 'Content-Type: application/json' \
       -d '{
         "from": "noreply@meuapp.com.br",
         "to": "test-abc123@mail-tester.com",
         "subject": "Teste",
         "text": "Hello"
       }'

# Acessa mail-tester.com e vê o score.
# Objetivo: 10/10 com SPF pass, DKIM pass, DMARC pass.

_dmarc  TXT  v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@meuapp.com.br

# Em mais 2 semanas → pct=50, depois pct=100.
# Por fim → p=reject.

3.12 Erros comuns

3.13 Exercícios

TLS, HTTPS,
certificados.

HTTPS deixou de ser opcional há tempo — em 2026 é tabela. Mas quem só sabe "instalei Let's Encrypt" não está pronto pra quando algo dá errado: certificado não renovou, navegador mostra erro estranho, ACME falhou no domingo. Entender o protocolo evita madrugadas debugando o óbvio.

Esse capítulo cobre o que importa operacionalmente: como TLS funciona o suficiente pra debugar, como funciona o sistema de certificados, como Let's Encrypt automatiza tudo, e por que renovação automática quebra silenciosamente — o erro mais comum em produção. Vou ser pragmático: não vou ensinar criptografia de ponta-a-ponta, vou ensinar a operar.

4.1 A história — de SSL 2.0 a TLS 1.3

4.2 Como TLS funciona — o suficiente pra debugar

TLS resolve três problemas simultaneamente: identidade (o servidor é quem diz ser), confidencialidade (terceiros não conseguem ler) e integridade (terceiros não conseguem modificar).

O handshake em alto nível

# TLS 1.3 (versão atual recomendada) — 1 round-trip:

Cliente                                      Servidor
   │                                             │
   │ ClientHello                                 │
   │  - "falo TLS 1.3"                          │
   │  - cipher suites que aceito                 │
   │  - chave pública efêmera (Diffie-Hellman)   │
   │  - server_name = "meuapp.com.br" (SNI)    │
   │ ─────────────────────────────────────────→  │
   │                                             │
   │                       ServerHello           │
   │            - escolho TLS 1.3                │
   │            - escolho cipher X               │
   │            - chave pública dele             │
   │            - certificado                    │
   │            - assinatura provando que ele é  │
   │              dono da chave do certificado   │
   │ ←─────────────────────────────────────────  │
   │                                             │
   │ Cliente:                                    │
   │   1. Valida certificado (cadeia até root CA)│
   │   2. Deriva chaves de sessão (DH ephemeral) │
   │   3. Começa a falar HTTPS criptografado     │
   │ ─────────────────────────────────────────→  │
   │                                             │
   │      [HTTP request/response criptografado]  │
   │ ←──────────────────────────────────────────→│

O que cada parte faz

• Identidade: o certificado contém a chave pública do servidor + nome de domínio + assinatura de uma CA confiável. O navegador confia em ~150 CAs (a lista vem com o navegador/SO).
• Confidencialidade: Diffie-Hellman efêmero gera uma chave compartilhada que nem o cliente nem o servidor armazenam. Mesmo se a chave privada do servidor vazar depois, o tráfego antigo não pode ser descriptografado. Isso é chamado Perfect Forward Secrecy.
• Integridade: cada mensagem é autenticada (MAC). Modificação em trânsito quebra a verificação.

SNI — Server Name Indication

Um IP pode hospedar centenas de sites. No ClientHello, o cliente envia SNI — o nome do site que ele quer acessar (meuapp.com.br). O servidor usa isso pra escolher o certificado certo. Sem SNI (TLS antigo), seria impossível ter múltiplos certs num único IP.

Implicação operacional: configurações como curl --resolve e proxies precisam mandar SNI correto. Erro de SNI causa "certificado errado retornado".

4.3 TLS 1.2 vs 1.3 — o que mudou

O que ter em produção

• TLS 1.3: obrigatório, padrão.
• TLS 1.2: ative como fallback para clientes muito antigos (Android antigo, IE11). Caddy/Nginx modernos fazem isso por padrão.
• TLS 1.0, 1.1: desligue. Vulneráveis (BEAST, POODLE) e sem uso real. Padrão PCI-DSS e a maioria das auditorias bloqueia.
• SSL 2.0, 3.0: nunca, em hipótese alguma.

4.4 O certificado — o que tem dentro

Certificado é arquivo no formato X.509. Contém:

• Subject: a quem se refere (CN = Common Name, geralmente nome do domínio).
• Subject Alternative Names (SAN): lista de domínios cobertos (meuapp.com.br, www.meuapp.com.br, etc).
• Issuer: qual CA emitiu (Let's Encrypt, etc).
• Validity: datas Not Before e Not After — período de validade.
• Public Key: a chave pública do servidor.
• Signature: assinatura digital da CA, provando que ela atestou o domínio.
• Extensions: Key Usage, Extended Key Usage, CRL Distribution Points, etc.

Inspecionando certificado

# Ver certificado de um site:
$ openssl s_client -connect meuapp.com.br:443 -servername meuapp.com.br </dev/null \
    | openssl x509 -noout -text

# Saída resumida:
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 04:a1:...
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: C=US, O=Let's Encrypt, CN=E5
        Validity
            Not Before: Mar  8 14:23:11 2026 GMT
            Not After : Jun  6 14:23:10 2026 GMT
        Subject: CN=meuapp.com.br
        Subject Public Key Info: ...
        X509v3 extensions:
            X509v3 Subject Alternative Name:
                DNS:meuapp.com.br, DNS:www.meuapp.com.br

# Versão curta — só validade:
$ echo | openssl s_client -connect meuapp.com.br:443 -servername meuapp.com.br 2>/dev/null \
    | openssl x509 -noout -dates
notBefore=Mar  8 14:23:11 2026 GMT
notAfter=Jun  6 14:23:10 2026 GMT

Cadeia de confiança

Seu certificado é assinado pela Let's Encrypt. Mas o navegador não confia diretamente nela — confia em uma root CA (raíz). A Let's Encrypt é, na verdade, uma intermediate CA assinada por uma root.

# Cadeia típica de um certificado Let's Encrypt em 2026:

ISRG Root X1 (root) ← confiada pelo navegador
    │
    ↓ assina
Let's Encrypt R3/R10/E5 (intermediate)
    │
    ↓ assina
meuapp.com.br (seu certificado)

# O servidor envia: SEU CERT + INTERMEDIATE.
# Navegador valida intermediate contra root que ele já confia.

Configuração comum: o servidor envia o seu cert mais a intermediate (a "chain" ou "fullchain"). Servir apenas o seu cert sem a intermediate é erro comum: muitos navegadores fazem AIA fetching (buscam intermediate por conta), mas alguns clientes (curl strict, libs HTTP de linguagens) falham com "certificate chain incomplete".

4.5 Let's Encrypt e ACME — como funciona

Antes do Let's Encrypt, obter certificado envolvia: gerar CSR, mandar para CA, esperar 1-3 dias, receber email, instalar manualmente. Renovação era manual. Esquecimento causava expiração e site fora.

ACME (Automatic Certificate Management Environment, RFC 8555) é o protocolo que automatiza tudo. Cliente (certbot, Caddy, etc) conversa com a CA via API HTTP. Provisionamento e renovação viram script.

Como funciona o ACME challenge

A CA precisa confirmar que você controla o domínio. Para isso, ela emite um challenge: você prova controle de uma das duas formas (em 2026, com algumas variações):

• HTTP-01: CA pede para você servir arquivo específico em http://seudominio.com/.well-known/acme-challenge/TOKEN. Mais comum. Funciona se você tem servidor HTTP rodando.
• DNS-01: CA pede para você criar registro TXT específico em _acme-challenge.seudominio.com. Mais flexível — funciona mesmo sem servidor HTTP exposto, e é a única forma de obter certificado wildcard.
• TLS-ALPN-01: challenge via TLS na porta 443. Útil em casos específicos. Raramente usado manualmente.

Fluxo HTTP-01 passo a passo

# Cliente ACME (certbot, etc) inicia:

1. Cliente: "quero certificado para meuapp.com.br"
   → CA (Let's Encrypt)

2. CA: "prove que você controla. Coloque o token TOKEN
       no caminho /.well-known/acme-challenge/TOKEN do site."
   → Cliente

3. Cliente: cria arquivo TOKEN no path certo, com conteúdo específico.
   → Servidor web (Nginx, Caddy, etc) serve esse arquivo.

4. Cliente: "feito, valida"
   → CA

5. CA: faz HTTP GET para http://meuapp.com.br/.well-known/acme-challenge/TOKEN
   Encontra arquivo? Conteúdo bate? OK.

6. CA: emite certificado.
   → Cliente

7. Cliente: salva cert + chave privada local. Recarrega servidor web.

# Tempo total típico: 10-30 segundos.
# Validade do certificado: 90 dias (Let's Encrypt).
# Renovação automática: 30 dias antes de vencer.

Por que validade curta

Let's Encrypt emite certificados por 90 dias (e, desde 2025, está testando certificados de 6 dias). Por quê tão curto?

• Limita janela de comprometimento: chave roubada vira inútil em poucas semanas.
• Força automação: ninguém renova manualmente a cada 90 dias. Automação obrigatória.
• Revogação na prática não funciona: CRL (Certificate Revocation List) e OCSP têm problemas reais. Certificado curto é alternativa mais eficaz.

A indústria está convergindo para certificados ainda mais curtos. CABForum aprovou em 2025 baseline para certificados de até 47 dias. Em 2-3 anos, certificados longos serão exceção.

4.6 Tipos de certificado — DV, OV, EV, wildcard

Por nível de validação

Por escopo

• Single domain: só meuapp.com.br.
• Multi-domain (SAN): vários domínios listados explicitamente — meuapp.com.br, www.meuapp.com.br, app.meuapp.com.br. Padrão moderno.
• Wildcard: *.meuapp.com.br — cobre qualquer subdomínio com um nível. NÃO cobre a.b.meuapp.com.br nem o apex.

Wildcard sim ou não?

Wildcard parece sempre vantajoso, mas tem trade-off:

• Vantagem: um certificado serve todos os subdomínios. Não precisa renovar/configurar pra cada novo subdomínio.
• Desvantagem 1: chave privada única que comprometida expõe todos os subdomínios. Single-domain certs podem ser comprometidos um a um.
• Desvantagem 2: Let's Encrypt wildcard exige DNS-01 challenge — sua automação precisa permissão para criar/deletar registros DNS. Mais setup.

Recomendação: use cert individual por subdomínio quando você tem poucos. Use wildcard quando tem dezenas (multi-tenant, por exemplo). Ferramentas modernas (Caddy) tornam ambos triviais.

4.7 Caddy — automatização absurda

Caddy (criado por Matt Holt em 2015) é servidor web que faz HTTPS automaticamente. Você fala "quero servir meuapp.com.br"; ele:

1. Obtém certificado Let's Encrypt automaticamente
2. Configura TLS 1.3
3. Renova antes de expirar
4. Recarrega sem dor

Sem configuração de SSL. Sem certbot. Sem cron. Apenas funciona.

# Caddyfile — configuração completa de Caddy
# para um app FastAPI rodando em localhost:8000

meuapp.com.br {
    reverse_proxy localhost:8000
}

# Isso é tudo. Caddy:
# - Obtém cert Let's Encrypt automaticamente
# - Redireciona HTTP para HTTPS automaticamente
# - Configura TLS 1.3 com defaults sãos
# - Renova cert antes de expirar (30 dias)
# - Reinicia transparente

# Múltiplos sites:
meuapp.com.br, www.meuapp.com.br {
    reverse_proxy localhost:8000
}

api.meuapp.com.br {
    reverse_proxy localhost:3000
}

# Wildcard com Cloudflare DNS provider:
*.meuapp.com.br {
    tls {
        dns cloudflare {env.CLOUDFLARE_API_TOKEN}
    }
    reverse_proxy localhost:8000
}

Quando usar Caddy

• Você está começando. Default sensato, zero config para 99% dos casos.
• Projeto solo. Sem time, sem tempo para configurar Nginx.
• Stack Docker. Caddy num container já resolve todo o frontend HTTPS.

Quando não

• Você já tem Nginx complexo funcionando. Não migre por modismo.
• Performance extrema (não que Caddy seja lento, mas Nginx ainda tem vantagem em casos de altíssima carga).
• Configurações muito específicas (load balancing avançado, sticky sessions complexas).

Vamos cobrir reverse proxies em detalhe no Cap 11. Por enquanto, registre: Caddy é a opção mais simples e moderna para HTTPS automático.

4.8 Certbot — manual quando precisa

certbot (da EFF) é a ferramenta original de ACME. Funciona com qualquer servidor (Nginx, Apache, etc). Mais boilerplate que Caddy, mas é o padrão histórico.

# Instalação (Ubuntu):
$ sudo apt install certbot python3-certbot-nginx

# Obter certificado para domínio rodando Nginx:
$ sudo certbot --nginx -d meuapp.com.br -d www.meuapp.com.br

# Certbot:
# - faz HTTP-01 challenge
# - obtém cert
# - modifica config Nginx adicionando HTTPS
# - configura redirect HTTP→HTTPS
# - testa config
# - reinicia Nginx
# - configura cron pra renovar automaticamente

# Verificar renovação está funcionando (dry run):
$ sudo certbot renew --dry-run

# Forçar renovação (raro, só pra teste):
$ sudo certbot renew --force-renewal

# Listar certificados existentes:
$ sudo certbot certificates

# Obter wildcard (precisa DNS-01 com plugin do provedor):
$ sudo apt install python3-certbot-dns-cloudflare
$ sudo certbot certonly --dns-cloudflare \
    --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
    -d '*.meuapp.com.br' -d meuapp.com.br

Onde certbot salva:

• /etc/letsencrypt/live/meuapp.com.br/fullchain.pem — cert + intermediate
• /etc/letsencrypt/live/meuapp.com.br/privkey.pem — chave privada
• /etc/letsencrypt/renewal/meuapp.com.br.conf — config de renovação

4.9 Renovação que falha silenciosamente — o erro #1

Configurou renovação automática. Funciona por meses. Então — sem você notar — para de funcionar. Cert expira. Site fora do ar com erro de cert.

Causas comuns:

Causa 1: Mudança de configuração que quebra HTTP-01

Renovação usa HTTP-01 challenge — Let's Encrypt acessa http://meuapp.com.br/.well-known/acme-challenge/.... Se você:

• Adicionou redirect HTTP→HTTPS antes da rota /.well-known/
• Adicionou WAF/auth na frente que bloqueia a Let's Encrypt
• Restringiu firewall removendo porta 80
• Mudou Cloudflare para "I'm Under Attack Mode" que challenge bots

Renovação falha. Próximas tentativas no cron também. Cert expira.

Causa 2: Disco cheio

Certbot grava em /var/log/letsencrypt/. Disco cheio → certbot falha em escrever log → renovação não roda.

Causa 3: Cron não está rodando

Por algum motivo (manutenção, upgrade do SO, container reiniciado com state perdido), o cron de renovação não existe mais. Ou existe mas o serviço cron está parado.

Causa 4: Rate limit

Let's Encrypt tem limites: 50 certs por domínio raiz por semana, 5 erros por hora. Se você renovou 50× testando algo, fica bloqueado temporariamente.

Como evitar tudo isso

Script simples de monitor

#!/bin/bash
# check_certs.sh — alerta se cert vai expirar em < 14 dias
# Rodar via cron diariamente.

DOMAINS=("meuapp.com.br" "api.meuapp.com.br" "blog.meuapp.com.br")
ALERT_DAYS=14
NOTIFY_URL="https://ntfy.sh/meu-canal-pessoal"  # ou Slack webhook, etc

for domain in "${DOMAINS[@]}"; do
    expiry=$(echo | openssl s_client -servername "$domain" -connect "$domain:443" 2>/dev/null \
             | openssl x509 -noout -enddate \
             | cut -d= -f2)
    expiry_epoch=$(date -d "$expiry" +%s)
    now_epoch=$(date +%s)
    days_left=$(( (expiry_epoch - now_epoch) / 86400 ))
    
    if [ "$days_left" -lt "$ALERT_DAYS" ]; then
        curl -d "⚠️ Cert de $domain expira em $days_left dias" "$NOTIFY_URL"
    fi
done

4.10 mTLS — autenticação mútua, brevemente

No TLS normal, só o servidor prova identidade. Em mTLS (mutual TLS), o cliente também apresenta certificado, e o servidor valida.

Casos de uso:

• Comunicação entre microsserviços internos — cada serviço tem cert, valida o outro.
• API B2B com clientes específicos — você emite cert para cada cliente, só quem tem o cert válido pode acessar.
• VPN-like sem precisar de VPN.

mTLS é setup pesado. Para projetos solo/pequenos quase nunca vale. Cloudflare Access (a partir do plano gratuito limitado) oferece autenticação SSO sem precisar gerenciar certs cliente. Menciono pra você conhecer o termo; setup detalhado fica fora do escopo desse capítulo.

4.11 Estudo de caso — incidente de cert expirado

$ echo | openssl s_client -connect meuapp.com.br:443 -servername meuapp.com.br 2>/dev/null \
    | openssl x509 -noout -dates
notBefore=Dec  8 14:23:11 2025 GMT
notAfter=Mar  8 14:23:10 2026 GMT
# Cert expirou há 2 dias. Confirmado.

$ sudo certbot certificates
# Lista cert expirado.

$ sudo journalctl -u snap.certbot.renew --since "1 month ago"
# Logs do timer de renovação.

# OU em logs do certbot direto:
$ sudo tail -100 /var/log/letsencrypt/letsencrypt.log
# Procurar mensagens de erro nas últimas semanas.

# Causa comum encontrada:
# "Detail: Fetching http://meuapp.com.br/.well-known/acme-challenge/XYZ:
#  Connection refused"

$ sudo ufw status
Status: active
To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere
443/tcp                    ALLOW       Anywhere

# Achei. Há 1 mês alguém endureceu o firewall pra aceitar só 443.
# Esqueceu que renovação usa HTTP-01 na porta 80.

# Reabrir porta 80 temporariamente
$ sudo ufw allow 80/tcp

# Forçar renovação agora
$ sudo certbot renew --force-renewal
# Aguardar 30-60s

# Recarregar Nginx (certbot tenta fazer automaticamente)
$ sudo systemctl reload nginx

# Verificar
$ echo | openssl s_client -connect meuapp.com.br:443 -servername meuapp.com.br 2>/dev/null \
    | openssl x509 -noout -dates
# notAfter agora 90 dias no futuro. OK.

# Instalar plugin DNS
$ sudo apt install python3-certbot-dns-cloudflare

# Criar credentials
$ sudo nano /etc/letsencrypt/cloudflare.ini
# Conteúdo:
dns_cloudflare_api_token = SEU_TOKEN_AQUI
$ sudo chmod 600 /etc/letsencrypt/cloudflare.ini

# Reemitir cert via DNS-01
$ sudo certbot certonly --dns-cloudflare \
    --dns-cloudflare-credentials /etc/letsencrypt/cloudflare.ini \
    -d meuapp.com.br -d www.meuapp.com.br \
    --force-renewal

# Agora pode fechar porta 80 com segurança
$ sudo ufw delete allow 80/tcp

4.12 Erros comuns

4.13 Exercícios

$ openssl s_client -connect github.com:443 -servername github.com </dev/null 2>/dev/null

# Pontos relevantes na saída:
# - Server certificate
#     subject=CN=github.com
#     issuer=C=US, O=DigiCert Inc, CN=DigiCert Global G2 ...
# - X509v3 Subject Alternative Name:
#     DNS:github.com, DNS:www.github.com
# - Protocol  : TLSv1.3
# - Cipher    : TLS_AES_128_GCM_SHA256
# - SSL-Session: ...
# - Verify return code: 0 (ok)

# Observações típicas:
# - github.com: usa DigiCert, TLS 1.3, cipher GCM moderno
# - bb.com.br: pode usar TLS 1.2 ou 1.3
# - gov.br: tipicamente DigiCert ou similar pago, TLS 1.2/1.3

# Versão curta da consulta:
$ echo | openssl s_client -connect github.com:443 -servername github.com 2>/dev/null \
    | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

# Site principal — apex + www
meuapp.com.br, www.meuapp.com.br {
    reverse_proxy localhost:8000
}

# API com headers explícitos
api.meuapp.com.br {
    reverse_proxy localhost:9000 {
        header_up X-Real-IP {remote_host}
        header_up X-Forwarded-Proto {scheme}
    }
}

# Admin com basic auth
# Gerar hash: caddy hash-password
admin.meuapp.com.br {
    basic_auth {
        admin $2a$14$Zkx19XLiW6VYouLHR5NmfOFU0z2GTNmpkT/5qqR7hx4IjWJPDhjvG
    }
    reverse_proxy localhost:7000
}

# Static com cache longo
static.meuapp.com.br {
    root * /var/www/static
    file_server
    header Cache-Control "public, max-age=31536000, immutable"
}

# Caddy faz HTTPS automático em TODOS os domínios acima.
# Redirect HTTP→HTTPS automático.
# Renovação a cada 60 dias (margem de 30 dias).

"""
check_certs.py — monitora validade de certs TLS.
Rodar via cron diariamente:
    0 9 * * * /usr/bin/python3 /opt/scripts/check_certs.py
"""

import ssl
import socket
import json
import sys
from datetime import datetime, timezone
from pathlib import Path
import urllib.request
import logging

logging.basicConfig(level=logging.INFO, format="%(message)s")
log = logging.getLogger()

DOMAINS_FILE = Path("/opt/scripts/domains.txt")
ALERT_DAYS = 14
NTFY_URL = "https://ntfy.sh/seu-canal-privado"
TIMEOUT = 10

def get_cert_expiry(domain: str) -> datetime:
    with socket.create_connection((domain, 443), timeout=TIMEOUT) as sock:
        ctx = ssl.create_default_context()
        with ctx.wrap_socket(sock, server_hostname=domain) as ssock:
            cert = ssock.getpeercert()
            expiry_str = cert["notAfter"]
            # Formato: 'Jun  6 14:23:10 2026 GMT'
            expiry = datetime.strptime(expiry_str, "%b %d %H:%M:%S %Y %Z")
            return expiry.replace(tzinfo=timezone.utc)

def notify(message: str):
    try:
        req = urllib.request.Request(NTFY_URL, data=message.encode(), method="POST")
        urllib.request.urlopen(req, timeout=5)
    except Exception as e:
        log.error(json.dumps({"event": "notify_failed", "error": str(e)}))

def check_domain(domain: str) -> dict:
    try:
        expiry = get_cert_expiry(domain)
        days_left = (expiry - datetime.now(timezone.utc)).days
        result = {
            "event": "cert_check",
            "domain": domain,
            "expires_at": expiry.isoformat(),
            "days_left": days_left,
            "status": "ok" if days_left >= ALERT_DAYS else "warning",
        }
        log.info(json.dumps(result))

        if days_left < ALERT_DAYS:
            notify(f"⚠️ Cert de {domain} expira em {days_left} dias ({expiry.date()})")
        return result

    except Exception as e:
        result = {
            "event": "cert_check_error",
            "domain": domain,
            "error": str(e),
            "status": "error",
        }
        log.error(json.dumps(result))
        notify(f"❌ Falha ao verificar cert de {domain}: {e}")
        return result

def main():
    if not DOMAINS_FILE.exists():
        log.error(f"Domains file não encontrado: {DOMAINS_FILE}")
        sys.exit(1)

    domains = [d.strip() for d in DOMAINS_FILE.read_text().splitlines() if d.strip() and not d.startswith("#")]
    results = [check_domain(d) for d in domains]
    
    # Status final para exit code (útil em CI/health checks)
    has_errors = any(r["status"] != "ok" for r in results)
    sys.exit(1 if has_errors else 0)

if __name__ == "__main__":
    main()

meuapp.com.br
www.meuapp.com.br
api.meuapp.com.br
blog.meuapp.com.br
# Comentários começam com #
# admin.meuapp.com.br (desativado)

Escolhendo
provedor
de VPS.

Provedor errado custa de 3 a 10 vezes mais do que precisaria, com performance pior. Provedor certo custa pouco, performa bem, e quando você precisa de mais, deixa você crescer sem trauma. Não é decisão definitiva — você pode migrar — mas começar bem economiza meses de trabalho.

Esse capítulo é opinado. Vou comparar os principais provedores com critérios honestos, ignorando o marketing. Os preços e specs são de 2026 (verifique site oficial no dia da decisão — VPS é mercado que muda). O objetivo: você sair daqui sabendo o que escolher e por quê, sem ler 15 reviews superficiais.

5.1 A história — de servidor dedicado a serverless

5.2 O que é VPS, exatamente

VPS = Virtual Private Server. Você aluga uma máquina virtual num servidor físico compartilhado com outros clientes (mas isolada por hypervisor). Recebe acesso root via SSH e pode fazer o que quiser dentro dela.

O que você ganha

• Root completo: instala o que quiser, configura como quiser.
• IP público: normalmente 1 IPv4 dedicado + faixa de IPv6.
• Banda incluída: tipicamente 1-20 TB/mês (varia muito).
• Imagem de SO: instalação rápida de Ubuntu, Debian, etc.
• Console (KVM): acesso ao console mesmo se SSH quebrar.
• Snapshots e backups: normalmente opcionais com custo extra.

O que você não ganha

• Gerenciamento. Você é responsável por updates, segurança, backups (se não pagar pelo serviço), monitoring. Provedor cuida do hardware e da rede, ponto.
• SLA forte. A maioria oferece 99.9% (~8h de downtime/ano permitidos). Cloud pública oferece 99.99%.
• Serviços gerenciados. Sem banco gerenciado, sem fila gerenciada, sem load balancer (alguns oferecem, com cost extra).
• Localização brasileira: a maioria não tem datacenter no Brasil, ou cobra muito mais quando tem.

5.3 Critérios honestos para escolher

Em ordem de importância para 90% dos casos:

1. Preço por recurso real. €4 com 4GB RAM é melhor que $5 com 1GB. Não compare "VPS por preço base" — compare RAM e CPU obtidos.
2. Performance medida, não anunciada. "vCPU" varia muito entre provedores. Mesma sigla, performance 3× diferente. Veja benchmarks reais (vpsbenchmarks.com, joedevops.com).
3. Localização do datacenter. Latência mata. Se usuário está no Brasil, datacenter no Brasil ou costa leste dos EUA é tolerável; Europa adiciona 200ms. Vai sentir no chat, jogos, API responsiva.
4. Banda incluída. Surpresa comum: provedor barato cobra $0.10/GB acima de 1TB. Hetzner inclui 20TB; AWS cobra $0.09/GB de saída desde o primeiro byte (com plano grátis pequeno).
5. Painel de gerenciamento. API decente, criar/destruir/snapshot fácil. Reflete maturidade do provedor.
6. Suporte. Maioria dos baratos: ticket que demora 24h. Hetzner é referência ruim aqui. Quando você está fora do ar às 3h da manhã, isso vira problema real.
7. Reputação do IP. Provedores baratos têm IPs queimados por outros clientes (spam, scanning). Você herda. Pra alguns casos importa muito.
8. Conformidade com leis (LGPD/GDPR). Para dados sensíveis, datacenter em jurisdição compatível.

5.4 Os provedores — comparação honesta

5.5 Localização e latência BR

Para apps com usuários brasileiros, latência da conexão entre o usuário e o servidor é frequentemente o fator mais perceptível de performance. Latências típicas de São Paulo (verifique a sua com ping):

Como mitigar latência alta

• Cloudflare na frente. Conexão usuário→Cloudflare é rápida (POP de SP); Cloudflare→origin via backbone otimizado. Latência percebida cai muito, especialmente para assets cacheados.
• Edge functions / Workers. Lógica simples roda no Cloudflare, próximo do usuário. Origem só consultada quando necessário.
• Página renderizada server-side com cache agressivo. HTML cacheado no edge serve usuário em ~50ms mesmo com origin no exterior.

Para muitos apps (especialmente os web tradicionais), latência de origin não importa tanto quanto se imagina, se tiver Cloudflare bem configurado na frente. Para apps real-time (chat, jogos, colaborativo), origin próximo é essencial.

5.6 Pegadinhas de "free tier"

Free tier é marketing. Sempre tem custos escondidos. Os maiores:

AWS Free Tier

• 12 meses de t2.micro (1 vCPU, 1GB) — só primeiro ano.
• Depois, vira ~$8.50/mês.
• Egress: 100GB/mês free; acima, $0.09/GB. Fácil estourar.
• Snapshot, IP elástico não usado, load balancer: cobranças extras.
• Surpresa de billing é REAL — pessoas pegando contas de $1000 por engano.

Oracle Cloud Always Free

• De fato muito generoso: 4 ARM vCPUs, 24GB RAM "para sempre".
• Mas: Oracle reivindica direito de desligar instances "ociosas". Definição de ocioso é deles.
• Bloqueio de conta sem aviso é problema reportado por muitos.
• Para tinkering pessoal, vale. Para produção séria, não.

Google Cloud Always Free

• e2-micro (0.25 vCPU, 1GB) — em uma região US, exceto Virginia.
• 1GB egress/mês — fácil estourar.
• OK para hobby. Inviável para produção.

Conclusão pragmática: free tier é bom para aprender e experimentar. Para projetos reais, escolha provedor com preço fixo previsível ($5-7/mês). Surpresa de billing destrói muito mais que economia inicial.

5.7 Quando sair de VPS para cloud (AWS/GCP)

VPS é o caminho certo para 95% dos projetos solo/pequenos. Sair pra AWS/GCP só faz sentido quando você bate em problemas específicos:

• Precisa de serviços gerenciados específicos: RDS (banco gerenciado), SQS (fila), Cognito (auth), etc. Cara de montar, fácil de consumir.
• Compliance forte: ISO 27001, SOC 2, HIPAA. Cloud pública tem certificações; VPS pequeno geralmente não.
• Multi-região com failover automático. Possível em VPS, mas trabalhoso.
• Escala que VPS não dá conta. Centenas de instances, autoscaling sofisticado.
• GPU para AI/ML. Cloud pública é viável; VPS raramente tem.
• Integração com ecossistema cloud: S3, SES, Bedrock — usar o resto da AWS junto faz sentido.

Antes de migrar pra cloud, considere abordagens híbridas:

• VPS + serviços cloud gerenciados. Sua aplicação no Hetzner, banco gerenciado no Neon, S3 da AWS, SES pra email. Melhor dos dois mundos.
• VPS + plataforma serverless para específicos. Cloud Run/Lambda para jobs específicos, VPS para o core.

5.8 Dimensionamento inicial

"Qual VPS comprar para começar?" — pergunta clássica. Resposta: menor que você acha, e cresça quando precisar.

Para projeto pessoal/MVP

• 2 vCPU, 4GB RAM, 40GB SSD. Hetzner CX22 ou similar.
• Custa €4-8/mês. Cabe Postgres + Redis + 1-2 apps Python + Caddy.
• Suporta tranquilamente 100 usuários ativos simultâneos em apps web bem feitos.

Para startup early-stage

• 4 vCPU, 8GB RAM, 80GB SSD. Hetzner CX32 ou similar.
• Custa €7-14/mês.
• Considera separar: 1 VPS para app + Caddy, 1 VPS para Postgres. Total ~€15/mês. Mais resiliente.

Quando tudo cresce

• Saia de "uma VPS faz tudo" antes de doer demais.
• Padrão saudável: app stateless em uma VPS (ou várias) + banco em VPS separada + storage no S3/R2.
• Vertical antes de horizontal: sair de CX22 para CX32 é trivial e dobra recursos. Adicionar segunda VPS exige load balancer.

5.9 Estudo de caso — decisão para projeto novo

5.10 Erros comuns

5.11 Exercícios

# Latência:
$ ping -c 10 google.com           # referência local
$ ping -c 10 hetzner.com          # DE
$ ping -c 10 aws.amazon.com       # US

# Para testar latência específica a datacenters,
# use looking glass dos provedores:
# - hetzner: https://hel1-speed.hetzner.com (Helsinki)
# - hetzner: https://nbg1-speed.hetzner.com (Nuremberg)
# - hetzner: https://ash-speed.hetzner.com (Ashburn US)
# - vultr: https://lg-sjo.vultr.com, lg-sao.vultr.com, etc

Provisionamento
inicial da VPS.

Provedor entregou o servidor: IP público, senha de root, acesso por SSH. Daqui até "servidor utilizável" tem 30-60 minutos de trabalho que ninguém deveria pular. Quem pula, paga em dor depois — fuso horário errado em logs, root exposto na internet, swap inexistente em momento crítico.

Esse capítulo é a receita do setup inicial mínimo, em ordem. Cada passo justificado, cada comando explicado. Não vou ensinar Linux do zero — assumo que você sabe ler um terminal. Vou cobrir exatamente o que importa: o que distingue um servidor que vai aguentar produção de um que vai virar manchete em fórum de incidentes.

6.1 A história — de scripts artesanais a cloud-init

6.2 O primeiro login

Provedor te deu: IP público (ex: 5.6.7.8), usuário root, senha temporária. Ou (Hetzner, AWS, alguns outros): só IP + chave SSH que você forneceu na criação.

# Conectar pela primeira vez (senha):
$ ssh root@5.6.7.8
The authenticity of host '5.6.7.8 (5.6.7.8)' can't be established.
ED25519 key fingerprint is SHA256:abc123...
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
root@5.6.7.8's password:

# Daí, prompt:
root@vps-nome:~#

Sobre a fingerprint da primeira conexão

Aquele aviso "authenticity can't be established" é importante. Você está aceitando a chave do servidor sem confirmação. Em teoria, alguém poderia estar fazendo MITM. Na prática, em rede normal, raro. Provedores sérios mostram a fingerprint esperada no painel — vale conferir uma vez. Após aceitar, fica em ~/.ssh/known_hosts; conexões futuras só prosseguem se a fingerprint bate.

Atualizar tudo primeiro

# Sempre primeiro passo num servidor novo:
# apt update     → busca lista de pacotes atualizados
# apt upgrade    → instala atualizações disponíveis (sem mudar versão major)
# apt dist-upgrade → idem mas pode promover ou remover pacotes (use com critério)

# apt update
# apt upgrade -y

# Em Ubuntu/Debian. Outras distros: dnf (Fedora/RHEL), zypper (openSUSE), etc.
# Pode reiniciar o kernel:
# [ -f /var/run/reboot-required ] && reboot

Em Ubuntu da Hetzner ou DigitalOcean, frequentemente já vem bem atualizado, mas faça o ritual mesmo. Em casos raros aparece kernel novo — reinicia.

6.3 Criar usuário não-root com sudo

Rodar como root é a configuração padrão dos provedores. É terrível: qualquer comando ruim destrói o sistema. Toda operação que vier de fora (script malicioso, vulnerabilidade na app) tem privilégio total.

Crie um usuário "humano" com sudo:

# Como root:
# adduser admin
# Vai pedir senha (escolha forte), depois algumas perguntas opcionais — pula com Enter.

# usermod -aG sudo admin
# Agora 'admin' pode executar com sudo.

# Verificar:
# su - admin
# sudo whoami
# Pedirá a senha. Deve retornar 'root'.

Copiar chave SSH para o novo usuário

Se você ainda não fez login com chave (só senha), agora é hora. Da sua máquina local:

# Se você ainda não tem chave SSH local:
$ ssh-keygen -t ed25519 -C "seu-email@dominio.com"
# Aceite o caminho padrão (~/.ssh/id_ed25519). Senha opcional mas recomendada.

# Copiar chave pública para o servidor (no usuário admin):
$ ssh-copy-id admin@5.6.7.8
# Vai pedir senha do admin. Após isso, pode entrar sem senha.

# Testar:
$ ssh admin@5.6.7.8
# Sem prompt de senha = sucesso.

A partir desse momento, você não precisa mais do usuário root direto. Não desligue ainda — vamos hardenizar SSH no próximo capítulo. Mas use admin com sudo para o resto desse setup.

6.4 Locale e timezone

Servidor com locale errado faz Python imprimir UnicodeDecodeError em horário aleatório. Servidor com timezone errado faz logs aparecerem 3-9h depois do "horário real" — debug vira inferno.

Verificar configuração atual

$ locale
LANG=C.UTF-8
LANGUAGE=
LC_ALL=

$ timedatectl
               Local time: Wed 2026-05-21 14:23:11 UTC
           Universal time: Wed 2026-05-21 14:23:11 UTC
                 RTC time: Wed 2026-05-21 14:23:11
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active

Configurar locale para UTF-8

# Gerar locales (caso precise pt_BR):
# locale-gen en_US.UTF-8 pt_BR.UTF-8

# Definir locale padrão para inglês UTF-8 (recomendado em servidores):
# update-locale LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8

# Por que inglês? Erros e logs em inglês são pesquisáveis. 
# Português dá tradução ruim de stack traces e mensagens de sistema.

Configurar timezone

Convenção sólida: servidor em UTC, aplicação converte para timezone do usuário. Logs em UTC são comparáveis globalmente; conversão na hora de mostrar pro usuário.

# Manter UTC (recomendado):
# timedatectl set-timezone UTC

# Se você prefere horário local (não recomendado para servidor de produção,
# mas pode fazer sentido para servidor pessoal):
# timedatectl set-timezone America/Sao_Paulo

# Listar timezones disponíveis:
# timedatectl list-timezones | grep -i sao
# America/Sao_Paulo

Se você escolher UTC, lembre que ferramentas como journalctl mostrarão horários em UTC. journalctl --since "1 hour ago" ainda funciona porque é relativo. Para visualizar em horário local, use TZ=America/Sao_Paulo journalctl ... ou configure seu cliente local.

6.5 Hostname — identificar o servidor

Hostname é o nome que aparece no prompt e nos logs. Default é algo genérico (ubuntu-2gb-hil1); útil mudar para algo que faça sentido pra você.

# Mudar hostname permanente:
# hostnamectl set-hostname meuapp-prod-01

# Adicionar mapeamento local (recomendado):
# nano /etc/hosts
# Adicionar linha:
127.0.1.1   meuapp-prod-01

# Convenção saudável: nome-ambiente-numero
# - meuapp-prod-01
# - meuapp-staging-01
# - meuapp-db-01
# 
# Permite logs e dashboards identificarem origem facilmente.

6.6 Swap — quando vale e quanto

Swap é espaço em disco que o kernel usa quando RAM acaba. VPS modernas (especialmente Hetzner, Vultr) vêm sem swap. Pra projetos pequenos, isso pode ser problema: aplicação consome todo RAM em momento de pico, Linux mata processos arbitrariamente (OOM killer), serviço cai.

Habilitar swap não é solução para problema de memória — mas é colchão para picos curtos. Compromisso útil em servidores pequenos.

Quando habilitar

• VPS com 1-4GB RAM: sim. Swap de 1-2GB.
• VPS com 8GB+: opcional. Só se tiver workload com picos de memória.
• Banco de dados em produção séria: evitar — swap mata performance de SGBD. Compre RAM suficiente.
• Container runtime (Docker, k8s) em produção: debate. Recomendação moderna é desabilitar.

Como configurar

# Criar arquivo de swap de 2GB:
# fallocate -l 2G /swapfile
# chmod 600 /swapfile
# mkswap /swapfile
# swapon /swapfile

# Tornar persistente entre reboots:
# echo '/swapfile none swap sw 0 0' >> /etc/fstab

# Ajustar 'swappiness' (0-100, default 60):
# Menor = usa menos swap, prefere RAM.
# Para servidor: 10 é comum.
# echo 'vm.swappiness=10' >> /etc/sysctl.conf
# sysctl -p

# Verificar:
$ free -h
              total        used        free      shared  buff/cache   available
Mem:          3.8Gi       240Mi       3.0Gi        0.0Ki       540Mi       3.4Gi
Swap:         2.0Gi          0B       2.0Gi

6.7 Updates automáticos de segurança

unattended-upgrades é pacote do Debian/Ubuntu que aplica patches de segurança automaticamente, durante a noite. Configurado, você dorme sabendo que CVEs sendo divulgadas hoje estarão patcheadas amanhã.

Vamos cobrir em detalhe no Cap 9 (Updates e supply chain). Por enquanto, basta ativar com configuração default:

# Instalar (geralmente já vem em Ubuntu):
# apt install -y unattended-upgrades apt-listchanges

# Ativar interativamente (responda Yes):
# dpkg-reconfigure -plow unattended-upgrades

# Verificar:
# systemctl status unattended-upgrades

# Configuração avançada vai no Cap 9.

6.8 Pacotes essenciais

O servidor "limpo" do provedor tem o mínimo. Ferramentas que economizam horas depois:

# apt install -y \
    curl wget \                    # downloads
    git \                          # version control
    vim nano \                     # editores (escolha um)
    htop \                         # monitoring de CPU/RAM interativo
    iotop \                        # monitoring de I/O
    ncdu \                         # 'du' visual — qual diretório está cheio
    tmux \                         # multiplexer (sessões persistentes)
    jq \                           # processamento de JSON na linha de comando
    rsync \                        # sync de arquivos
    net-tools \                    # netstat e amigos
    dnsutils \                     # dig, nslookup, host
    fail2ban \                     # proteção contra brute-force (Cap 7)
    ufw \                          # firewall simples (Cap 8)
    logrotate                      # rotação de logs (Cap 10)

Boa prática: documentar essa lista num script de provisionamento. Reinstalar em servidor novo vira ./provision.sh — 30 segundos em vez de 30 minutos.

6.9 Monitoring rudimentar — onde estou usando?

Antes de configurar dashboards e observabilidade séria (Cap 10), saiba os comandos básicos para inspecionar saúde do servidor:

# RAM e swap em tempo real:
$ free -h

# Uso de CPU/RAM por processo (interativo):
$ htop
# Pressione 'F6' pra ordenar por colunas; 'q' pra sair.

# Espaço em disco:
$ df -h
# Coluna 'Use%' > 80% começa a preocupar; > 95% é incêndio.

# Onde está cheio dentro de um diretório (interativo):
$ sudo ncdu /var/log

# Top processos por CPU/memória:
$ ps aux --sort=-%mem | head
$ ps aux --sort=-%cpu | head

# Carga média (load average):
$ uptime
 14:35:22 up 12 days,  3:14,  1 user,  load average: 0.15, 0.12, 0.10
# Load entre 0 e número de CPUs = OK.
# > número de CPUs = sistema sobrecarregado.

# Conexões de rede ativas:
$ ss -tunlp
# t=TCP, u=UDP, n=numeric, l=listening, p=process

# Quem está logado:
$ w

Esses comandos não substituem observabilidade séria, mas são primeira linha de diagnóstico. Quando alarme dispara, você ssh, roda htop e df, e em 30 segundos sabe se é CPU, RAM, ou disco.

6.10 Automação — cloud-init e Ansible em 60 segundos

Esse capítulo cobriu setup manual. Para fazer o mesmo de forma reproduzível, duas opções principais:

cloud-init — no boot

Maioria dos provedores (Hetzner, AWS, DO, Vultr) aceita um YAML de cloud-init na criação da VPS. Ela boota já configurada.

#cloud-config
timezone: UTC
hostname: meuapp-prod-01

users:
  - name: admin
    sudo: "ALL=(ALL) NOPASSWD:ALL"
    shell: /bin/bash
    ssh_authorized_keys:
      - ssh-ed25519 AAAAC3...sua-chave-publica

package_update: true
package_upgrade: true
packages:
  - curl
  - git
  - htop
  - vim
  - fail2ban
  - ufw
  - unattended-upgrades

runcmd:
  - ufw default deny incoming
  - ufw allow 22/tcp
  - ufw --force enable
  - sed -i 's/^PermitRootLogin yes/PermitRootLogin no/' /etc/ssh/sshd_config
  - systemctl restart ssh
  - fallocate -l 2G /swapfile
  - chmod 600 /swapfile
  - mkswap /swapfile
  - swapon /swapfile
  - echo '/swapfile none swap sw 0 0' >> /etc/fstab

Crie VPS via API/painel com esse YAML. Em 1-2 minutos, servidor está pronto sem você logar nele.

Ansible — após boot

Para configurações complexas, evolutivas, multi-servidor, Ansible. Playbook YAML descreve estado desejado; rodar é idempotente.

- hosts: meuapp_prod
  become: true
  tasks:
    - name: Atualizar todos os pacotes
      apt:
        upgrade: dist
        update_cache: true

    - name: Instalar essenciais
      apt:
        name:
          - curl
          - git
          - htop
          - vim
          - fail2ban
        state: present

    - name: Configurar timezone
      timezone:
        name: UTC

    - name: Habilitar swap
      command: "swapon /swapfile"
      when: ansible_swaptotal_mb < 100

# Roda com: ansible-playbook -i inventory setup.yml
# Idempotente — só faz mudanças quando necessário.

Para projeto solo, cloud-init basta. Para gerenciar múltiplos servidores ao longo do tempo, Ansible vence. Para infra grande, Terraform + Ansible.

6.11 Estudo de caso — provisionamento real em 45 minutos

# Hetzner já recebeu sua chave SSH na criação, então:
$ ssh root@5.6.7.8
The authenticity of host... yes

# Já dentro:
root@cx22-test:~# uname -a
Linux cx22-test 6.8.0-31-generic ...

# apt update && apt upgrade -y
# Aguarda. Hetzner Ubuntu já vem decente; updates típicos: 20-60 pacotes.

# [ -f /var/run/reboot-required ] && reboot
# Se kernel atualizou, reboota. Espera 30s, ssh de novo.

# adduser admin
# Senha forte. Confirma. Enter no resto.

# usermod -aG sudo admin

# Copiar chave SSH para admin:
# mkdir -p /home/admin/.ssh
# cp ~/.ssh/authorized_keys /home/admin/.ssh/
# chown -R admin:admin /home/admin/.ssh
# chmod 700 /home/admin/.ssh
# chmod 600 /home/admin/.ssh/authorized_keys

# Em outra janela, validar:
$ ssh admin@5.6.7.8
# Sem prompt de senha. Sucesso.

admin@cx22-test:~$ sudo whoami
[sudo] password for admin: ...
root
# Funciona.

$ sudo timedatectl set-timezone UTC
$ sudo hostnamectl set-hostname meuapp-prod-01
$ sudo nano /etc/hosts
# Editar a linha 127.0.1.1 para o novo nome.

# Confirmar:
$ timedatectl
# Time zone: Etc/UTC
$ hostname
meuapp-prod-01

$ sudo fallocate -l 2G /swapfile
$ sudo chmod 600 /swapfile
$ sudo mkswap /swapfile
$ sudo swapon /swapfile
$ echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
$ echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.conf
$ sudo sysctl -p

# Confirmar:
$ free -h
# Swap: 2.0Gi

$ sudo apt install -y curl git vim htop iotop ncdu tmux jq \
    rsync net-tools dnsutils ufw fail2ban logrotate \
    unattended-upgrades apt-listchanges

$ sudo dpkg-reconfigure -plow unattended-upgrades
# Diálogo: "Automatically download and install stable updates?" Yes

$ uname -a; uptime; free -h; df -h
# Verifica tudo numa hora.

$ systemctl status fail2ban unattended-upgrades
# Ambos active (running)

$ id
uid=1000(admin) gid=1000(admin) groups=1000(admin),27(sudo)
# admin no grupo sudo. OK.

6.12 Erros comuns

6.13 Exercícios

# Provisionamento inicial — VPS Ubuntu

[ ] SSH como root pela primeira vez
    ssh root@<ip>

[ ] Atualizar pacotes
    apt update && apt upgrade -y
    [ -f /var/run/reboot-required ] && reboot

[ ] Criar usuário admin
    adduser admin
    usermod -aG sudo admin

[ ] Copiar chave SSH para admin
    mkdir -p /home/admin/.ssh
    cp ~/.ssh/authorized_keys /home/admin/.ssh/
    chown -R admin:admin /home/admin/.ssh
    chmod 700 /home/admin/.ssh
    chmod 600 /home/admin/.ssh/authorized_keys

[ ] Validar login admin em janela paralela
    ssh admin@<ip>
    sudo whoami  # deve retornar root

[ ] Configurar timezone
    sudo timedatectl set-timezone UTC

[ ] Configurar hostname
    sudo hostnamectl set-hostname meuapp-prod-01
    sudo sed -i 's/^127.0.1.1.*/127.0.1.1 meuapp-prod-01/' /etc/hosts

[ ] Habilitar swap (VPS com ≤4GB)
    sudo fallocate -l 2G /swapfile
    sudo chmod 600 /swapfile
    sudo mkswap /swapfile
    sudo swapon /swapfile
    echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
    echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.conf
    sudo sysctl -p

[ ] Instalar pacotes essenciais
    sudo apt install -y curl git vim htop iotop ncdu tmux jq \
        rsync net-tools dnsutils ufw fail2ban logrotate \
        unattended-upgrades

[ ] Ativar unattended-upgrades
    sudo dpkg-reconfigure -plow unattended-upgrades

[ ] Validar
    systemctl status fail2ban unattended-upgrades
    id  # admin no grupo sudo

[ ] Documentar
    Notas: IP, hostname, propósito, data, chave SSH usada

[ ] Snapshot inicial
    Painel do provedor: criar snapshot 'baseline'

#cloud-config

hostname: meuapp-prod-01
timezone: UTC
preserve_hostname: false

users:
  - name: admin
    sudo: "ALL=(ALL) NOPASSWD:ALL"
    groups: sudo
    shell: /bin/bash
    ssh_authorized_keys:
      - ssh-ed25519 AAAAC3NzaC1lZDI1NTE5...SUA_CHAVE_PUBLICA admin@laptop

package_update: true
package_upgrade: true
package_reboot_if_required: true

packages:
  - curl
  - git
  - vim
  - htop
  - iotop
  - ncdu
  - tmux
  - jq
  - rsync
  - net-tools
  - dnsutils
  - ufw
  - fail2ban
  - logrotate
  - unattended-upgrades
  - apt-listchanges

write_files:
  - path: /etc/sysctl.d/99-swappiness.conf
    content: "vm.swappiness=10"

runcmd:
  # Swap 2GB
  - fallocate -l 2G /swapfile
  - chmod 600 /swapfile
  - mkswap /swapfile
  - swapon /swapfile
  - echo '/swapfile none swap sw 0 0' >> /etc/fstab
  - sysctl -p /etc/sysctl.d/99-swappiness.conf
  
  # Habilitar unattended-upgrades automaticamente
  - echo 'unattended-upgrades unattended-upgrades/enable_auto_updates boolean true' | debconf-set-selections
  - dpkg-reconfigure -fnoninteractive unattended-upgrades
  
  # Firewall básico (só SSH; Cap 8 ajusta)
  - ufw default deny incoming
  - ufw default allow outgoing
  - ufw allow 22/tcp
  - ufw --force enable

final_message: "Servidor pronto. SSH em admin@$ip"

$ uptime
 14:35:22 up 3 days, load average: 3.50, 2.80, 1.90
# Em VPS de 2 cores: 3.50 = sobrecarga real. Tendência crescente (vs 1.90 há 15min).

$ free -h
              total        used        free      shared  buff/cache   available
Mem:          1.9Gi       1.7Gi        90Mi        5.0Mi       120Mi        70Mi
Swap:         2.0Gi       1.5Gi       500Mi
# RAM lotada. Swap ativo agressivamente (1.5GB usado). SWAPPING — explica lentidão.

$ ps aux --sort=-%mem | head -5
USER       PID %CPU %MEM    VSZ   RSS COMMAND
postgres  1234  15.2 35.4 ...        postgres: idle
python    5678   8.5 28.2 ...        gunicorn worker
python    5679   8.1 27.8 ...        gunicorn worker
# Postgres + 2 workers Python = ~90% da RAM.
# Provavelmente subiram número de workers ou queries pesadas no banco.

$ sudo iotop
# Vê processos que estão fazendo muito I/O. Em swap thrashing, kswapd aparece alto.

$ df -h
/dev/sda1        40G   38G  2.0G  95% /
# 95% cheio! Causa secundária de problemas (Postgres pode ter dificuldade de gravar).

$ sudo ncdu /var/log
# Vê onde está cheio: /var/log/postgresql/postgresql-14-main.log com 8GB. Logrotate não configurado direito.

Hardening
de SSH.

SSH é a única porta de entrada do seu servidor. Bem configurada, é praticamente intransponível. Mal configurada, é o caminho mais provável de comprometimento. A diferença é meia hora de trabalho e uns 5 ajustes de configuração — feitos uma vez, esquecidos para sempre.

Esse capítulo cobre o que importa: como SSH realmente autentica (modelo de chaves), como gerar chaves direito em 2026, quais ajustes no servidor valem (e quais são teatro), fail2ban configurado de verdade, e o que fazer quando você se tranca fora (porque vai acontecer). Vou ignorar mitos populares e focar em prática.

7.1 A história — de telnet a SSH 2

7.2 Como SSH autentica — o suficiente pra debugar

SSH tem múltiplos modos de autenticação. Os dois que importam:

Password (não use em produção)

Usuário digita senha; servidor compara com /etc/shadow. Vulnerável a:

• Brute force online: milhões de tentativas com senhas comuns. Bots fazem isso 24/7 em qualquer IP público.
• Phishing/keylogger: senha digitada vaza.
• Reuso: mesma senha em vários serviços; um vaza, todos comprometidos.

Chave pública (use sempre)

Você tem um par de chaves: privada (fica na sua máquina, nunca sai dela) e pública (colocada no servidor, em ~/.ssh/authorized_keys).

# Fluxo de autenticação por chave:

1. Cliente: "oi, sou o user admin no servidor X.
              tenho essas chaves públicas pra oferecer."
   → Servidor

2. Servidor verifica se alguma das chaves oferecidas
   está em /home/admin/.ssh/authorized_keys

3. Servidor: "prove que você TEM a chave privada da chave X.
              eis um desafio aleatório, assine ele."
   → Cliente

4. Cliente: assina o desafio com chave privada local
   (chave privada nunca sai do cliente)
   → Servidor

5. Servidor verifica assinatura usando a chave pública.
   Válida? Login autorizado.

# Vantagem chave: o servidor nunca recebe sua chave privada.
# Mesmo se atacante intercepta tudo, não consegue forjar autenticação.

7.3 Tipos de chave — escolha que importa

ed25519 vence em tudo: mais rápida, mais segura (na curva 25519, sem números mágicos suspeitos), chaves curtas e legíveis. Único motivo pra ainda usar RSA é compatibilidade com sistemas pré-2014 — raro.

7.4 Gerar chaves direito

# Gerar chave ed25519:
$ ssh-keygen -t ed25519 -C "voce@laptop"
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/voce/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:

# Arquivos gerados:
# ~/.ssh/id_ed25519       → chave privada (NUNCA compartilhe)
# ~/.ssh/id_ed25519.pub   → chave pública (esta vai pro servidor)

Sobre a passphrase

Quando gera a chave, pedem passphrase. Polêmica entre comodidade e segurança:

• Sem passphrase: SSH instantâneo. Mas se alguém pega seu laptop ou rouba o arquivo, vira você no servidor sem fricção.
• Com passphrase + ssh-agent: digita passphrase uma vez por sessão; agente guarda em memória. Próximos SSH não pedem nada. Recomendação saudável.

ssh-agent vem com sistema operacional. macOS: ssh-add --apple-use-keychain guarda no Keychain. Linux com gnome-keyring: automático. Windows com OpenSSH: ssh-add com agent rodando.

Múltiplas chaves para múltiplos contextos

Boa prática: chave separada por contexto (trabalho, pessoal, servidores específicos).

$ ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_pessoal -C "voce@pessoal"
$ ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_trabalho -C "voce@trabalho"
$ ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_servidores -C "voce@servidores"

# Configuração de qual usar em qual host vai em ~/.ssh/config (próxima seção).

Compartilhar chave pública

A pública é segura para compartilhar — esse é o ponto. Coloque em:

• ~/.ssh/authorized_keys dos servidores que você acessa.
• GitHub/GitLab (Settings → SSH Keys) — usado para git push via SSH.
• Painel da Hetzner/DO/etc — para incluir automaticamente em novas VPSs.

Sua chave pública vai começar com ssh-ed25519 e ter ~80 caracteres. Pode publicar no GitHub público, no Twitter — não há risco. Privada é a única que precisa segredo absoluto.

7.5 sshd_config — o que mexer

O arquivo principal de configuração do servidor SSH é /etc/ssh/sshd_config. Para Ubuntu/Debian modernos, prefira criar arquivo em /etc/ssh/sshd_config.d/ que sobrescreve defaults — é mais limpo e sobrevive a upgrades.

# Hardening recomendado em 2026
# Aplica-se em adição às configs default do Debian/Ubuntu

# --- Desabilitar root login ---
PermitRootLogin no

# --- Desabilitar autenticação por senha ---
PasswordAuthentication no
ChallengeResponseAuthentication no
KbdInteractiveAuthentication no

# --- Forçar apenas chaves ---
PubkeyAuthentication yes
AuthenticationMethods publickey

# --- Limitar usuários que podem entrar via SSH (opcional, recomendado) ---
AllowUsers admin

# --- Timeouts agressivos contra conexões ociosas ---
ClientAliveInterval 300
ClientAliveCountMax 2
# Se cliente não responder em 300s × 2, conexão é fechada.

# --- Reduzir tentativas antes de desconectar ---
MaxAuthTries 3
LoginGraceTime 30

# --- Desabilitar features que raramente são úteis ---
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no
# Atenção: TcpForwarding às vezes é útil (port forwarding).
# Se você usa SSH tunnels, deixe 'yes'.

# --- Banner opcional ---
Banner /etc/issue.net
# Conteúdo do arquivo deve avisar que acesso é restrito (efeito legal em algumas jurisdições).

Aplicar mudanças

# Testar config antes de reiniciar (CRÍTICO):
$ sudo sshd -t
# Sem output = OK. Se houver erro de sintaxe, mostra.

# Reiniciar serviço:
$ sudo systemctl restart ssh

# IMPORTANTE: mantenha sua sessão atual aberta!
# Abra outra janela e teste novo login antes de fechar a atual.
$ ssh admin@5.6.7.8
# Funcionou? OK, agora pode fechar a primeira sessão.

Sobre AuthenticationMethods publickey

Linha AuthenticationMethods publickey força que SÓ chave seja aceita. Combinada com PasswordAuthentication no, deixa o servidor impermeável a brute force de senha — bot pode tentar 1 milhão de vezes, sempre vai falhar sem chave válida.

Você pode exigir múltiplos fatores: AuthenticationMethods publickey,password obriga as duas. Para servidores muito críticos, isso é melhor — mas adiciona fricção. Padrão 2026 para projetos solo: só chave basta, se bem cuidada.

7.6 Seu ~/.ssh/config — comodidade que importa

Sem ~/.ssh/config, você digita ssh -i ~/.ssh/id_ed25519_servidores -p 22 admin@5.6.7.8 toda vez. Com config, vira ssh meuapp.

# Defaults para todos os hosts
Host *
    AddKeysToAgent yes
    IdentitiesOnly yes
    ServerAliveInterval 60
    ServerAliveCountMax 5

# Servidor de produção
Host meuapp
    HostName 5.6.7.8
    User admin
    Port 22
    IdentityFile ~/.ssh/id_ed25519_servidores

# Staging
Host meuapp-staging
    HostName 1.2.3.4
    User admin
    IdentityFile ~/.ssh/id_ed25519_servidores

# GitHub via SSH
Host github.com
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_pessoal

# Bastion / jump host (pra acessar máquinas internas via uma exposta)
Host db-interno
    HostName 10.0.1.5
    User admin
    ProxyJump meuapp
    IdentityFile ~/.ssh/id_ed25519_servidores

Agora você usa

$ ssh meuapp                  # entra direto
$ ssh meuapp-staging          # outro servidor
$ scp arquivo.tar.gz meuapp:/tmp/   # scp funciona com aliases
$ rsync -av ./local/ meuapp:/var/www/    # rsync também
$ ssh db-interno              # conecta via meuapp como bastion

7.7 fail2ban — atacando bots em escala

Mesmo com password authentication desligado, bots vão bater na sua porta SSH milhares de vezes por dia. Logs ficam barulhentos, há um pequeno custo de CPU. fail2ban resolve: monitora logs, detecta padrões de ataque, e bloqueia IPs via firewall.

Configuração base

fail2ban vem com configurações em /etc/fail2ban/jail.conf. Não edite esse — crie /etc/fail2ban/jail.local com overrides.

[DEFAULT]
# Quanto tempo banir (segundos)
bantime = 3600

# Janela para contar tentativas
findtime = 600

# Quantas tentativas antes do ban
maxretry = 5

# IPs que nunca devem ser banidos (seu IP de casa, escritório):
ignoreip = 127.0.0.0/8 ::1 SEU.IP.DE.CASA

# Backend para detectar mudanças nos logs
backend = systemd

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = %(sshd_log)s
maxretry = 3
bantime = 86400     # SSH banido por 24h (mais rigor que default)

Aplicar e verificar

$ sudo systemctl restart fail2ban

# Ver status:
$ sudo fail2ban-client status
Status
|- Number of jail: 1
`- Jail list: sshd

# Detalhes do jail sshd:
$ sudo fail2ban-client status sshd
Status for the jail: sshd
|- Filter
|  |- Currently failed:     3
|  |- Total failed:         847
|  `- File list:            /var/log/auth.log
`- Actions
   |- Currently banned: 12
   |- Total banned:     156
   `- Banned IP list: 1.2.3.4 ...

# Desbanir um IP manualmente (caso seja você):
$ sudo fail2ban-client unban 5.6.7.8

# Ver logs do fail2ban:
$ sudo journalctl -u fail2ban -f

É realmente necessário?

Resposta honesta: com password auth desligada, fail2ban é mais sobre reduzir ruído nos logs do que segurança real. Brute force de chave SSH é matematicamente inviável. Mas:

• Logs com 50 mil tentativas de SSH/dia ficam imprestáveis para análise.
• fail2ban reduz isso a quase nada.
• Configuração é trivial, custo é mínimo.

Use. Não é "linha defensiva crítica" mas é higiene.

7.8 Mudar porta SSH — vale a pena?

Conselho popular: "mude a porta SSH de 22 para 2222 ou outra coisa, vai reduzir ataques". Verdade pela metade.

O que muda

• Bots automatizados que escaneiam só porta 22 deixam de bater. Logs ficam mais limpos.
• Ataques direcionados (alguém pesquisando seu IP) descobrem a nova porta em segundos via nmap. Não muda nada.

Quando vale

• Você está irritado com logs barulhentos de SSH (alternativa: fail2ban resolve).
• Por convenção da sua organização.

Quando NÃO vale

• Você acha que adiciona segurança real. Não adiciona.
• Você não documenta a porta nova. Esquece daqui a 3 meses, fica trancado fora.
• Sua porta nova entra em conflito com algum serviço (ex: 2222 é porta padrão de DirectAdmin).

Se mudar, faça direito

# Em sshd_config.d/99-hardening.conf, adicionar:
Port 22
Port 2347

# SSH escutará em ambas as portas durante transição.
# Validar:
$ sudo sshd -t
$ sudo systemctl restart ssh

# Abrir firewall pra nova porta:
$ sudo ufw allow 2347/tcp

# Testar (em outra janela):
$ ssh -p 2347 admin@5.6.7.8
# Funcionou? Edita ~/.ssh/config pro Port 2347.

# Depois de 24h+ confiantes, remover linha "Port 22" e fechar firewall:
$ sudo ufw delete allow 22/tcp

7.9 SSH com várias pessoas

Servidor de time tem múltiplas pessoas com acesso SSH. Modelo errado: criar usuário deploy com senha que todo mundo compartilha. Catastrófico — quando alguém sai, você troca a senha, todo mundo tem que atualizar; logs não distinguem quem fez o quê.

Modelo certo: 1 usuário por pessoa

# Para cada pessoa do time:
$ sudo adduser maria
$ sudo usermod -aG sudo maria
$ sudo mkdir -p /home/maria/.ssh
$ echo "ssh-ed25519 AAAAC3... maria@laptop" | sudo tee /home/maria/.ssh/authorized_keys
$ sudo chown -R maria:maria /home/maria/.ssh
$ sudo chmod 700 /home/maria/.ssh
$ sudo chmod 600 /home/maria/.ssh/authorized_keys

# Quando alguém sai:
$ sudo userdel -r maria
# Remove conta + home directory.

# Logs mostram cada pessoa explicitamente:
$ sudo journalctl _SYSTEMD_UNIT=ssh.service -p info
... sshd[1234]: Accepted publickey for maria from 200.150.x.x port ...

Para time maior — gestão centralizada

Quando passa de 5-10 pessoas, fica chato. Opções:

• Ansible/Terraform: playbook gerencia usuários e chaves. Pessoa nova → adiciona no playbook → aplica em todos os servidores.
• SSH CA (certificate authority): assinatura central de chaves. Cada pessoa tem chave assinada por CA da empresa; CA assinada confiada nos servidores. Revogação central.
• Bastion / jump host com SSO: Teleport, Boundary (HashiCorp), Tailscale SSH. Pessoa loga via SSO; sistema injeta credenciais.
• Cloudflare Access: mais simples — pessoa acessa via browser, SSO da Google/etc, e túnel SSH transparente.

Para projetos solo/pequenos (1-5 devs), modelo "1 usuário por pessoa, chave SSH, gerenciado manualmente" basta. Faz a transição quando dor justificar.

7.10 Quando você se tranca fora

Vai acontecer pelo menos uma vez. Configuração errada, chave perdida, firewall fechado demais. O que fazer:

Console via provedor (a salvação)

Todo provedor decente oferece console KVM no painel — acesso direto ao servidor, como se você estivesse fisicamente com teclado conectado. Bypassa SSH inteiro.

• Hetzner: "Open console" no painel → janela com terminal.
• DigitalOcean: "Access" → "Launch Droplet Console".
• AWS Lightsail: "Connect using SSH" → console no browser.
• Vultr: "View console" no painel.

Console precisa de senha de usuário (que normalmente você não definiu se entrou só por chave!). Boa prática preventiva: defina senha forte para admin ANTES de hardenizar SSH. Senha só será usada via console, em emergência.

# Definir senha do admin (preventivo):
$ sudo passwd admin
New password: ...
Retype: ...

# Guarda essa senha no seu gerenciador de senhas.
# Vai usar apenas via console em emergência.

Rescue mode

Se nem console funciona (cenário raro: kernel quebrou no boot), rescue mode: provedor reinicia VPS num sistema de "resgate" — pequeno Linux que monta seu disco como volume. Você corrige arquivo problemático manualmente.

• Hetzner: tem opção "Rescue" no painel — boota num Debian de resgate, com chave SSH que você fornece.
• DigitalOcean: "Recovery Boot" → boota em rescue ISO.
• AWS: detacha o volume, anexa em outra instance, corrige, reanexa.

Documente o processo do seu provedor antes de precisar. Saber onde clicar quando o site está fora é diferença entre 10 minutos e 2 horas.

7.11 Estudo de caso — hardening completo em uma sessão

$ sudo passwd admin
# Senha forte (gerador de senhas do seu gerenciador). Guarda no gerenciador.
# Será usada apenas via console KVM em emergência.

$ sudo nano /etc/ssh/sshd_config.d/99-hardening.conf

# Conteúdo:
PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
AllowUsers admin
ClientAliveInterval 300
ClientAliveCountMax 2
MaxAuthTries 3
LoginGraceTime 30
X11Forwarding no

$ sudo sshd -t
# Sem output = OK. Se aparecer erro, NÃO reinicie SSH ainda.

$ sudo systemctl restart ssh

$ ssh admin@5.6.7.8
# Entrou? Excelente. Pode fechar a sessão original.
# Não entrou? Use a sessão original para reverter:
#   sudo rm /etc/ssh/sshd_config.d/99-hardening.conf
#   sudo systemctl restart ssh

$ sudo nano /etc/fail2ban/jail.local

# Conteúdo:
[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 5
ignoreip = 127.0.0.0/8 ::1

[sshd]
enabled = true
maxretry = 3
bantime = 86400

$ sudo systemctl restart fail2ban
$ sudo fail2ban-client status sshd

$ nano ~/.ssh/config

# Adicionar:
Host meuapp
    HostName 5.6.7.8
    User admin
    IdentityFile ~/.ssh/id_ed25519

# Testar:
$ ssh meuapp
# Funcionou — agora você usa 'ssh meuapp' em vez do IP.

# Tentativa de login como root deve falhar:
$ ssh root@5.6.7.8
Permission denied (publickey).

# Tentativa com senha (de outra máquina sem chave) deve falhar:
$ ssh admin@5.6.7.8
Permission denied (publickey).
# Não pede senha — só aceita chave.

# fail2ban funcionando:
$ sudo fail2ban-client status sshd
# Active.

# Logs limpos:
$ sudo journalctl -u ssh --since today | grep -i fail
# Em algumas horas, vai começar a aparecer tentativas falhas vindas
# de bots — confirma que fail2ban está vendo (e banindo).

7.12 Erros comuns

7.13 Exercícios

# Gerar chave
$ ssh-keygen -t ed25519 -C "voce@laptop-pessoal" -f ~/.ssh/id_ed25519
# Quando pedir passphrase, use senha forte (gerador). Guarda no gerenciador.

# Verificar ssh-agent
$ ssh-add -l
# Se "The agent has no identities", adicionar:
$ ssh-add ~/.ssh/id_ed25519
# Pede a passphrase uma vez; depois fica em memória.

# Em macOS, para guardar no Keychain:
$ ssh-add --apple-use-keychain ~/.ssh/id_ed25519

# Criar config
$ nano ~/.ssh/config
# Exemplo:
Host *
    AddKeysToAgent yes
    IdentitiesOnly yes
    ServerAliveInterval 60

Host meuapp
    HostName 5.6.7.8
    User admin
    IdentityFile ~/.ssh/id_ed25519

Host github.com
    User git
    IdentityFile ~/.ssh/id_ed25519

# Permissões importam:
$ chmod 600 ~/.ssh/config

# Testar:
$ ssh meuapp

Firewall:
ufw, iptables,
security groups.

Servidor exposto na internet sem firewall é casa com a porta da frente aberta. Configurar firewall direito é meia hora de trabalho — pra esconder serviços que não precisam estar públicos, limitar acesso aos que precisam, e bloquear o IP real mesmo com Cloudflare na frente. Defesa em camadas começa aqui.

Esse capítulo cobre ufw (a ferramenta que você vai usar 95% do tempo), iptables o suficiente pra debug, security groups da nuvem (camada paralela em AWS/GCP), e a integração com Cloudflare que esconde seu IP do mundo. Vou ser pragmático: vai sair daqui com o servidor fechado.

8.1 A história — packet filtering em Linux

8.2 Conceitos — o que firewall faz

Firewall examina cada pacote de rede que entra/sai e decide aceitar ou rejeitar baseado em regras. Em essência, três coisas:

• Direção: tráfego entrando (INPUT) ou saindo (OUTPUT) ou passando por (FORWARD).
• Origem/destino: IP/range de IPs.
• Porta/protocolo: TCP 22 (SSH), TCP 443 (HTTPS), UDP 53 (DNS), etc.

Política default

Ponto mais importante de toda a configuração: política default. Define o que acontece quando nenhuma regra explícita bate. Duas filosofias:

• Default allow: aceita tudo que não está explicitamente bloqueado. Insano para servidor exposto — esquece de uma porta e fica vulnerável.
• Default deny: bloqueia tudo que não está explicitamente permitido. É a única forma sã. Configuração explícita, sem surpresas.

Estado da conexão

Firewall moderno é stateful: lembra das conexões em andamento. Você diz "permite SSH entrar" — automaticamente as respostas saindo são permitidas (mesma conexão, fluxo bidirecional). Sem stateful, teríamos que configurar regras para cada direção. Com stateful, configuramos só "novas conexões".

8.3 Defense in depth — camadas de defesa

Pra servidor moderno em cloud, há tipicamente 3 camadas de firewall agindo:

Internet
   ↓
┌─────────────────────────────────────────┐
│ Camada 1: WAF / DDoS protection         │ ← Cloudflare, AWS Shield
│  (filtragem em aplicação, ataques L7)  │
└────────────────┬────────────────────────┘
                 ↓
┌─────────────────────────────────────────┐
│ Camada 2: Cloud firewall (security      │ ← AWS Security Groups,
│  group) — filtragem por porta/IP        │   Hetzner Cloud Firewall,
│                                         │   gerenciado pelo provedor
└────────────────┬────────────────────────┘
                 ↓
┌─────────────────────────────────────────┐
│ Camada 3: Firewall do SO (ufw/iptables) │ ← Configurado dentro da VPS
│  — última linha antes da aplicação      │
└────────────────┬────────────────────────┘
                 ↓
            Aplicação

Cada camada filtra independentemente. Configuração em uma não substitui a outra. Recomendação: todas as três configuradas para servidores expostos. Para projetos solo:

• Cloudflare (Camada 1): sempre, é grátis.
• Cloud firewall (Camada 2): depende do provedor. Hetzner Cloud Firewall é grátis. AWS Security Groups são obrigatórios.
• ufw no servidor (Camada 3): sempre.

Por que múltiplas camadas?

• Bug em uma camada: outra ainda protege.
• Configuração esquecida: errou ufw, security group salva.
• Modelo de ameaça diferente: Cloudflare bloqueia L7 (HTTP malicioso), security group bloqueia L3-L4 (IP/porta), ufw também L3-L4 mas dentro do servidor.

8.4 ufw na prática

ufw (Uncomplicated Firewall) é wrapper amigável sobre iptables/nftables. Sintaxe legível, comandos coerentes. Para 95% dos casos, é tudo que você precisa.

Instalação e estado inicial

# Já instalado em Ubuntu/Debian. Caso não:
$ sudo apt install ufw

# Status:
$ sudo ufw status
Status: inactive

# Configurar defaults ANTES de habilitar:
$ sudo ufw default deny incoming
$ sudo ufw default allow outgoing

Permitir o que você precisa

# ANTES de habilitar, abra SSH — senão você se tranca fora:
$ sudo ufw allow 22/tcp comment 'SSH'

# Liberar HTTP/HTTPS (vamos ajustar depois pra só Cloudflare):
$ sudo ufw allow 80/tcp comment 'HTTP'
$ sudo ufw allow 443/tcp comment 'HTTPS'

# Habilitar:
$ sudo ufw enable
Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
Firewall is active and enabled on system startup

# Status:
$ sudo ufw status numbered
Status: active

     To                         Action      From
     --                         ------      ----
[ 1] 22/tcp                     ALLOW IN    Anywhere                   # SSH
[ 2] 80/tcp                     ALLOW IN    Anywhere                   # HTTP
[ 3] 443/tcp                    ALLOW IN    Anywhere                   # HTTPS
[ 4] 22/tcp (v6)                ALLOW IN    Anywhere (v6)
[ 5] 80/tcp (v6)                ALLOW IN    Anywhere (v6)
[ 6] 443/tcp (v6)               ALLOW IN    Anywhere (v6)

Note que ufw cria regras para IPv4 e IPv6 automaticamente — bom.

Comandos do dia a dia

# Permitir só de um IP específico (útil pra SSH restrito):
$ sudo ufw allow from 200.150.1.2 to any port 22 proto tcp

# Permitir de um range:
$ sudo ufw allow from 200.150.0.0/24 to any port 22 proto tcp

# Bloquear IP específico (lista negra):
$ sudo ufw deny from 198.51.100.100

# Deletar regra pelo número:
$ sudo ufw status numbered
$ sudo ufw delete 3      # deleta regra #3

# Deletar regra pela descrição:
$ sudo ufw delete allow 80/tcp

# Resetar tudo (cuidado!):
$ sudo ufw reset

# Desabilitar (mantém regras, só não aplica):
$ sudo ufw disable

# Modo verboso — vê detalhes (chains, contadores):
$ sudo ufw status verbose

# Ver logs de tráfego bloqueado:
$ sudo tail -f /var/log/ufw.log

# Habilitar logging (default é off):
$ sudo ufw logging on
# Níveis: off, low, medium, high, full. 'low' geralmente é o suficiente.

Application profiles

ufw vem com perfis pré-configurados para serviços comuns:

$ sudo ufw app list
Available applications:
  Nginx Full
  Nginx HTTP
  Nginx HTTPS
  OpenSSH
  ...

# Permitir usando o profile:
$ sudo ufw allow 'Nginx Full'
# Equivale a: ufw allow 80/tcp + ufw allow 443/tcp

Útil pra clareza nas regras ('Nginx Full' em vez de "80/tcp e 443/tcp"), mas funciona igual.

8.5 Aceitar HTTP/HTTPS só de IPs Cloudflare

Você ativou Cloudflare proxy (Cap 2). O mundo vê IPs da Cloudflare; seu IP real está escondido — desde que ninguém descubra. Como atacante pode descobrir? Vazamento em email, header HTTP indiscreto, histórico de DNS, scanning de range do provedor.

Defesa final: aceitar HTTP/HTTPS no servidor APENAS dos ranges de IP da Cloudflare. Conexões diretas, mesmo se descobrirem o IP, são rejeitadas pelo firewall.

Os ranges da Cloudflare

Cloudflare publica os ranges atualizados em URLs públicas:

• https://www.cloudflare.com/ips-v4 — IPv4
• https://www.cloudflare.com/ips-v6 — IPv6

Atualizados periodicamente (semestralmente, em média). Você precisa atualizar seu firewall quando mudar.

Script de configuração

#!/bin/bash
# cloudflare_ufw.sh
# Configura ufw para aceitar HTTP/HTTPS apenas de IPs Cloudflare.
# Rodar como root.

set -e

# 1. Remover regras genéricas de HTTP/HTTPS, se existirem:
ufw delete allow 80/tcp 2>/dev/null || true
ufw delete allow 443/tcp 2>/dev/null || true

# 2. Buscar ranges atuais
echo "Baixando ranges IPv4 da Cloudflare..."
IPV4_RANGES=$(curl -fsSL https://www.cloudflare.com/ips-v4)
echo "Baixando ranges IPv6 da Cloudflare..."
IPV6_RANGES=$(curl -fsSL https://www.cloudflare.com/ips-v6)

# 3. Adicionar regra por range:
for ip in $IPV4_RANGES; do
    ufw allow from "$ip" to any port 80,443 proto tcp comment "Cloudflare"
done

for ip in $IPV6_RANGES; do
    ufw allow from "$ip" to any port 80,443 proto tcp comment "Cloudflare"
done

# 4. Recarregar
ufw reload
echo "Pronto. ufw status:"
ufw status numbered

Mantendo atualizado

Cloudflare muda ranges raramente, mas muda. Opções:

• Cron mensal: roda o script automaticamente. Simples.
• Webhook do Cloudflare: notificação quando ranges mudam (raro de necessitar para projetos pequenos).
• Conferir manualmente trimestralmente. Funciona pra projetos solo.

# Em /etc/cron.d/cloudflare-ufw, rodar todo dia 1 do mês às 4h:
0 4 1 * * root /opt/scripts/cloudflare_ufw.sh >> /var/log/cloudflare-ufw.log 2>&1

8.6 iptables — quando ufw não basta

ufw cobre 95% dos casos, mas há configurações onde você precisa baixar para iptables (que é o que ufw usa por baixo). Casos:

• Regras com lógica de matching complexa (string match, geolocation, rate limiting fino).
• NAT/port forwarding.
• Debug profundo de regras existentes.

Comandos essenciais

# Listar regras (com numeração):
$ sudo iptables -L -v -n --line-numbers

# Listar regras NAT:
$ sudo iptables -t nat -L -v -n

# Adicionar regra (exemplo: bloquear IP):
$ sudo iptables -I INPUT -s 198.51.100.0/24 -j DROP

# Deletar regra:
$ sudo iptables -D INPUT 3     # deleta regra 3 da chain INPUT

# Salvar regras (para persistir reboot):
$ sudo apt install iptables-persistent
$ sudo netfilter-persistent save

Quando aparecer nftables

Em sistemas modernos, comandos iptables podem estar usando nftables por baixo (transparente). Para usar diretamente:

# Listar tudo:
$ sudo nft list ruleset

# Adicionar regra:
$ sudo nft add rule inet filter input ip saddr 198.51.100.100 drop

Para projetos solo, raramente vai precisar. Mas conhecer o nome ajuda quando aparece em docs e fóruns.

8.7 Security groups da nuvem

Em AWS, GCP, Azure, e provedores modernos como Hetzner Cloud, há firewall gerenciado pela plataforma — aplicado antes do tráfego chegar à VPS.

AWS Security Groups

• Stateful (já lembra de conexões).
• Default deny em inbound.
• Default allow em outbound (você muda se quiser).
• Configurado por instance, pode ser compartilhado entre várias.
• Suporta referência a outros security groups (ex: "permitir tráfego de qualquer instance no SG-app").

Hetzner Cloud Firewall

• Gratuito (até certo limite, generoso).
• Configurado no painel ou via API/Terraform.
• Aplicado a um ou mais servidores.
• Mesma lógica (default deny inbound + regras explícitas).

resource "hcloud_firewall" "prod" {
  name = "prod-firewall"

  rule {
    direction = "in"
    protocol = "tcp"
    port = "22"
    source_ips = ["200.150.1.2/32"]   # só meu IP
  }

  rule {
    direction = "in"
    protocol = "tcp"
    port = "443"
    source_ips = ["173.245.48.0/20", ...]  # ranges Cloudflare
  }
}

Dúvida comum: "preciso de ufw se já tenho security group?"

Sim, vale ter ambos. Razões:

• Configurações divergem ao longo do tempo (ufw foi pra um lado, SG pra outro — bom ter ambos checando).
• Bug ou misconfiguração em uma camada → outra protege.
• ufw vê IP real do cliente (após tráfego entrar na VPS); SG funciona em nível de rede da nuvem. Capabilities diferentes.

Trade-off: dois lugares pra atualizar quando muda regra. Aceitável.

8.8 IPv6 também precisa

VPS moderna vem com IPv4 + IPv6 público. ufw configurado cria regras para ambos automaticamente. Mas há armadilhas:

• Bind no IPv6 esquecido: serviço pode escutar em :: (todos IPv6) mas você só fechou 0.0.0.0 (IPv4) no firewall. Vulnerável via IPv6.
• Cloudflare em IPv6: tem ranges separados, configure ambos.
• Logs frequentemente em IPv4 só: aplicação pode estar logando IP do cliente em formato IPv4, ignorando IPv6.

Verificar serviços expostos

$ sudo ss -tlnp
# Vê tudo escutando, tanto v4 quanto v6.
# Coluna "Local Address:Port":
#   0.0.0.0:80      → escuta em IPv4 todas as interfaces
#   *:80            → escuta em IPv4 + IPv6 todas
#   [::]:80         → escuta em IPv6 todas
#   127.0.0.1:5432  → escuta só localhost (Postgres bem configurado)

# Se vê serviço em 0.0.0.0 ou *, considere se deveria estar exposto.

Idealmente, serviços de aplicação (banco, cache) bind em 127.0.0.1 ou IP privado da rede interna — não no IP público. Defense in depth no nível da aplicação.

8.9 Filtrar saída? — pragmatismo

ufw padrão libera todo o tráfego de saída. Você poderia restringir — "servidor só pode acessar internet via porta 443" — limitando dano de comprometimento. Trade-offs:

Vantagens de filtrar saída

• Servidor comprometido tem dificuldade pra exfiltrar dados ou baixar payloads.
• Detecta atividade anômala mais facilmente (algo tentando conectar em IP estranho aparece nos logs).
• Reduz superfície de ataque para escalation.

Desvantagens

• Configuração trabalhosa: cada serviço precisa de regra (apt, DNS, NTP, monitoring agents...).
• Quebra coisas em momentos aleatórios — atualizou app que agora chama API nova, esquece de liberar.
• Para servidor multi-uso (dev + prod), inviável manter.

Recomendação pragmática

• Projeto solo / equipe pequena: deixa saída livre. Foco em INPUT. Trabalho de filtrar OUTPUT não compensa.
• Compliance forte / dados muito sensíveis: sim, filtrar OUTPUT. Use ferramentas como CrowdSec ou seu próprio iptables com lista de IPs permitidos.
• Container: orquestrador (k8s) tem suas próprias network policies — diferente abordagem.

8.10 Estudo de caso — fechando servidor com app web

$ sudo ss -tlnp
Netid State  Local Address:Port  Process
tcp   LISTEN 0.0.0.0:22           sshd
tcp   LISTEN 0.0.0.0:80           caddy
tcp   LISTEN 0.0.0.0:443          caddy
tcp   LISTEN 127.0.0.1:8000        gunicorn   # app, OK só local
tcp   LISTEN 0.0.0.0:5432         postgres   # PROBLEMA: Postgres exposto!

$ sudo nano /etc/postgresql/16/main/postgresql.conf
# Procurar/mudar:
listen_addresses = 'localhost'

$ sudo systemctl restart postgresql

$ sudo ss -tlnp | grep 5432
tcp LISTEN 127.0.0.1:5432 postgres   # Agora só local. Bom.

$ sudo ufw default deny incoming
$ sudo ufw default allow outgoing

$ sudo ufw allow 22/tcp comment 'SSH'
$ sudo ufw allow 80/tcp comment 'HTTP - liberado pra ACME challenge'
$ sudo ufw allow 443/tcp comment 'HTTPS'

$ sudo ufw enable

# Já que vamos restringir, podemos rodar script:
$ sudo nano /opt/scripts/cloudflare_ufw.sh
# Cola conteúdo da seção anterior.

$ sudo chmod +x /opt/scripts/cloudflare_ufw.sh
$ sudo /opt/scripts/cloudflare_ufw.sh

# Confirma:
$ sudo ufw status numbered | grep Cloudflare | head
[ 3] 80,443/tcp                ALLOW IN    173.245.48.0/20   # Cloudflare
[ 4] 80,443/tcp                ALLOW IN    103.21.244.0/22   # Cloudflare
...

$ sudo nano /etc/cron.d/cloudflare-ufw
0 4 1 * * root /opt/scripts/cloudflare_ufw.sh >> /var/log/cloudflare-ufw.log 2>&1

# Tentar conectar direto no IP da VPS (não pelo DNS que vai pra Cloudflare):
$ curl -v http://5.6.7.8/
# Esperado: timeout. Firewall bloqueia.

$ curl -v https://5.6.7.8/ -k
# Esperado: timeout. 

# Via Cloudflare:
$ curl https://meuapp.com.br/
# Funciona. Tráfego válido passa.

# Postgres está exposto?
$ nc -zv 5.6.7.8 5432
nc: connect to 5.6.7.8 port 5432 (tcp) failed: Connection timed out
# Bom. Banco protegido.

8.11 Erros comuns

8.12 Exercícios

$ sudo ss -tlnp
Netid State  Local Address:Port    Process
tcp   LISTEN 0.0.0.0:22             sshd       # SSH — exposto, OK
tcp   LISTEN 0.0.0.0:80             caddy      # HTTP — exposto, OK
tcp   LISTEN 0.0.0.0:443            caddy      # HTTPS — exposto, OK
tcp   LISTEN 127.0.0.1:5432          postgres   # OK — só localhost
tcp   LISTEN 127.0.0.1:6379          redis      # OK — só localhost
tcp   LISTEN 0.0.0.0:8000           gunicorn   # PROBLEMA: app exposta direto
                                              # Deveria estar em 127.0.0.1
                                              # com Caddy na frente

# Reset (cuidado: se tiver SSH ativo, NÃO faça reset sem janela paralela)
$ sudo ufw default deny incoming
$ sudo ufw default allow outgoing

# SSH só do IP de casa
$ sudo ufw allow from 200.150.1.2 to any port 22 proto tcp comment 'SSH'

# HTTP/HTTPS pra todos (Cloudflare cuida no Cap 2)
$ sudo ufw allow 80/tcp comment 'HTTP'
$ sudo ufw allow 443/tcp comment 'HTTPS'

# Postgres só pra IP interno específico
$ sudo ufw allow from 10.0.0.5 to any port 5432 proto tcp comment 'Postgres interno'

# Habilitar
$ sudo ufw enable
$ sudo ufw status numbered

# Resultado:
# To              Action      From
# 22/tcp          ALLOW IN    200.150.1.2  (SSH)
# 80/tcp          ALLOW IN    Anywhere     (HTTP)
# 443/tcp         ALLOW IN    Anywhere     (HTTPS)
# 5432/tcp        ALLOW IN    10.0.0.5     (Postgres interno)
# (Tudo mais: bloqueado por default deny)

#!/bin/bash
## cloudflare_ufw.sh — configurar ufw para HTTP/HTTPS Cloudflare-only,
## com trapdoor pro IP do admin (você).
##
## USO DA TRAPDOOR:
## - Acesso normal: navegue pelo domínio (passa pela Cloudflare)
## - Emergência (Cloudflare fora): acesse direto via IP da VPS
##   curl https://5.6.7.8/ -H "Host: meuapp.com.br" -k
## - Funciona porque firewall libera HTTP/HTTPS do MEU_IP_FIXO
##
## Para isso funcionar, ADMIN_IP precisa ser estático e atualizado neste script.

set -e

ADMIN_IP="200.150.1.2"     # Atualize se mudar

# Limpar regras antigas relacionadas:
ufw status numbered | grep -E "Cloudflare|Admin trapdoor" | awk -F"[][]" '{print $2}' | sort -rn | while read num; do
    echo "y" | ufw delete "$num"
done

# Adicionar regras Cloudflare:
echo "Configurando ranges Cloudflare..."
for ip in $(curl -fsSL https://www.cloudflare.com/ips-v4); do
    ufw allow from "$ip" to any port 80,443 proto tcp comment "Cloudflare"
done
for ip in $(curl -fsSL https://www.cloudflare.com/ips-v6); do
    ufw allow from "$ip" to any port 80,443 proto tcp comment "Cloudflare"
done

# Trapdoor — meu acesso direto:
echo "Adicionando trapdoor para $ADMIN_IP..."
ufw allow from "$ADMIN_IP" to any port 80,443 proto tcp comment "Admin trapdoor"

ufw reload
ufw status numbered
echo "OK. Trapdoor ativo para $ADMIN_IP."

# Cloudflare está fora. Acessar direto via IP:
$ curl -k -H "Host: meuapp.com.br" https://5.6.7.8/

# Ou, modificando /etc/hosts temporariamente:
$ echo "5.6.7.8 meuapp.com.br" | sudo tee -a /etc/hosts
$ curl https://meuapp.com.br/   # resolve pra IP direto agora
# Lembre de remover essa linha quando Cloudflare voltar.

$ sudo ufw status verbose
# 1. ufw está ativo? "Status: active"
# 2. Default incoming é deny? "Default: deny (incoming)"
# 3. Logging está habilitado? "Logging: on (low)"
# 4. Há comentários nas regras? (qualidade de manutenção)

$ sudo ss -tlnp
# 5. Algum serviço em 0.0.0.0 que não deveria? (banco, app)
# 6. Postgres/Redis/Mongo em localhost?
# 7. Aplicação atrás de reverse proxy (em 127.0.0.1, não exposto)?

$ sudo ss -ulnp
# 8. UDP exposto? DNS recursivo aberto? NTP exposto? (vetores de amplificação DDoS)

# 9. Regras ufw cobrem v6? (status mostra "(v6)" nas regras)
# 10. Algum serviço em [::]: que não tem regra equivalente?
$ sudo ss -tlnp | grep "::"

$ sudo ufw status | grep Cloudflare | wc -l
# 11. Há regras restringindo HTTP/HTTPS aos ranges Cloudflare?

$ cat /etc/cron.d/cloudflare-ufw 2>/dev/null || echo "sem cron"
# 12. Há cron pra atualizar os ranges?

$ ls /opt/scripts/cloudflare_ufw.sh 2>/dev/null
# 13. Script de atualização presente e atualizado?

Updates,
patches e
supply chain.

O servidor que você esqueceu de atualizar é o servidor que vai ser invadido. Não por um gênio do mal com exploit zero-day — por um script automatizado varrendo a internet atrás de uma CVE pública de oito meses atrás que você nunca aplicou. Patching é a defesa mais barata e mais negligenciada que existe.

Este capítulo é sobre manter o software do servidor atualizado sem quebrar produção no meio da madrugada. Vamos cobrir o que é uma CVE e como priorizar, configurar unattended-upgrades direito (não só ligar — configurar), lidar com reboots e patches de kernel, e estender o pensamento para a supply chain: as dependências da sua aplicação, que hoje são um vetor de ataque tão real quanto o SSH aberto. O objetivo é simples: patches de segurança aplicados automaticamente, com janela de quebra controlada e visibilidade do que aconteceu.

9.1 A história — de "rodar apt-get" a supply chain

9.2 Conceitos — CVE, CVSS e a janela de exposição

Antes de automatizar, vale entender o vocabulário, porque ele aparece em todo aviso de segurança que você vai ler.

CVE — o identificador

Uma CVE é um número único para uma vulnerabilidade específica, no formato CVE-ANO-NÚMERO — por exemplo CVE-2024-3094. Não diz nada sobre gravidade por si só; é só um nome estável para que todo mundo (fornecedor, pesquisador, scanner, você) esteja falando da mesma falha.

CVSS — a severidade

O CVSS (Common Vulnerability Scoring System) dá uma nota de 0.0 a 10.0. A faixa importa mais que o número exato:

A janela de exposição

O conceito que organiza tudo é a janela de exposição: o tempo entre o patch ficar disponível e você aplicá-lo. Durante essa janela, a falha é pública (logo, conhecida pelos atacantes) e o seu servidor segue vulnerável. O objetivo de todo o capítulo é encolher essa janela ao máximo — idealmente para "horas" no caso de segurança, sem precisar de você acordado.

Patch publicado          Você aplica
      │                       │
      ▼                       ▼
──────┼───────────────────────┼──────────►  tempo
      │◄─── janela de ────────►│
      │      exposição         │
      │                        │
   atacantes já sabem      você protegido
   da falha (é pública)

Objetivo: encolher essa janela.
Segurança → automatizada (horas).
Demais → ciclo controlado (dias).

9.3 O modelo mental de patching

Nem todo update é igual. Tratar todos da mesma forma leva ou à paralisia (com medo de quebrar) ou à imprudência (atualiza tudo às cegas). O modelo sadio separa em três baldes:

A regra de ouro: automatize segurança, controle o resto. Patches de segurança quase nunca quebram nada (o mantenedor faz backport mínimo da correção para a versão estável). Updates funcionais e upgrades maiores, sim. É por isso que a configuração padrão do unattended-upgrades só pega segurança — e é assim que deve ficar na maioria dos servidores.

9.4 unattended-upgrades na prática

Esse é o coração do capítulo. O pacote já vem no Ubuntu, mas vale instalar e — principalmente — configurar. Ligar sem configurar deixa pontas soltas (não reinicia serviços, não avisa de nada, não limpa kernels antigos).

Instalação e habilitação

$ sudo apt update
$ sudo apt install unattended-upgrades apt-listchanges

# Habilitar via diálogo interativo (cria 20auto-upgrades):
$ sudo dpkg-reconfigure --priority=low unattended-upgrades

# Conferir se está ativo:
$ systemctl status unattended-upgrades
$ cat /etc/apt/apt.conf.d/20auto-upgrades
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

A configuração que importa

O arquivo 50unattended-upgrades é onde mora a decisão. Por padrão ele só aplica segurança — bom. Mas há quatro linhas que você quase sempre quer ajustar:

// Quais origens atualizar — manter SÓ security é o conservador:
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
    "${distro_id}ESMApps:${distro_codename}-apps-security";
    "${distro_id}ESM:${distro_codename}-infra-security";
};

// 1. Remover dependências órfãs após o upgrade:
Unattended-Upgrade::Remove-Unused-Dependencies "true";

// 2. Limpar kernels antigos (senão /boot enche e quebra):
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";

// 3. Reiniciar serviços afetados sem perguntar
//    (libssl atualizada → reinicia quem usa, sem reboot):
Unattended-Upgrade::Automatic-Reboot "false";
$nrconf{restart} = "a";   // via /etc/needrestart/needrestart.conf

// 4. Avisar por email se algo der errado:
Unattended-Upgrade::Mail "voce@exemplo.com";
Unattended-Upgrade::MailReport "on-change";

Testar sem aplicar

Antes de confiar, faça um dry-run. Ele mostra exatamente o que seria atualizado sem mexer em nada:

# Simular — não aplica, só lista:
$ sudo unattended-upgrade --dry-run --debug

# Rodar de verdade, agora, manualmente:
$ sudo unattended-upgrade -v

# Ver o que já foi feito automaticamente:
$ cat /var/log/unattended-upgrades/unattended-upgrades.log
$ zcat /var/log/unattended-upgrades/unattended-upgrades.log.*.gz

9.5 Reboot e patches de kernel

Um problema fica de fora do needrestart: o próprio kernel. Patch de kernel só passa a valer depois de um reboot — não há como reiniciar "o kernel" sem reiniciar a máquina. E aqui mora uma tensão real: rebootar derruba a aplicação (downtime), mas não rebootar deixa o servidor rodando um kernel vulnerável indefinidamente.

Saber quando um reboot é necessário

# Se este arquivo existe, há reboot pendente:
$ ls /var/run/reboot-required
$ cat /var/run/reboot-required.pkgs   # quais pacotes pediram

# Kernel rodando vs kernel instalado:
$ uname -r                            # o que está em execução
$ ls /boot/vmlinuz-*                  # o que está instalado

Três estratégias para o reboot

• Reboot automático em janela definida. Para servidores que toleram downtime curto, deixe o unattended-upgrades reiniciar de madrugada. Automatic-Reboot "true" e Automatic-Reboot-Time "04:00". Simples, mas derruba a app — só serve se o downtime de 1 minuto às 4h é aceitável.
• Reboot manual coordenado. O monitor te avisa que há reboot pendente; você reinicia num horário escolhido, idealmente com a app drenada. Mais controle, exige disciplina.
• Livepatch — kernel sem reboot. O Canonical Livepatch aplica correções críticas de kernel em memória, sem reiniciar. Gratuito para até 5 máquinas com uma conta Ubuntu Pro pessoal. Reduz a urgência do reboot a quase zero para CVEs de kernel.

$ sudo pro attach <SEU-TOKEN>       # token em ubuntu.com/pro
$ sudo pro enable livepatch
$ canonical-livepatch status
# kernel: 6.8.0-x
# fully-patched: true
# → CVEs de kernel corrigidas em memória, sem reboot

9.6 Supply chain — a ameaça que importou de fora

Até aqui falamos do sistema operacional. Mas a maior superfície de ataque moderna não é o apt — é tudo que sua aplicação importa: pacotes npm, módulos pip, gems, crates, imagens Docker base. Cada dependência é código de um estranho que você roda com os privilégios da sua aplicação. Uma única lib comprometida na sua árvore de dependências é um comprometimento da sua aplicação.

Os vetores reais

• Typosquatting. Pacote malicioso com nome parecido com um popular (python-requests vs requests, colour vs color). Você erra a digitação, instala o do atacante.
• Conta de mantenedor comprometida. Atacante rouba credenciais de quem mantém um pacote legítimo e publica uma versão envenenada. Foi como o event-stream (2018), baixado milhões de vezes, ganhou um roubador de carteiras de Bitcoin.
• Backdoor de longo prazo. O caso xz (2024): um colaborador construiu confiança por dois anos antes de inserir o backdoor. Difícil de detectar porque a fonte parecia limpa — o payload estava em arquivos de teste binários.
• Imagem base Docker envenenada. Você puxa FROM alguma-imagem:latest sem fixar digest. O mantenedor da imagem (ou quem comprometeu a conta dele) injeta algo.

Defesas concretas

# 1. Lockfiles SEMPRE versionados e instalados a partir deles:
$ npm ci          # usa package-lock.json, não package.json
$ pip install -r requirements.txt   # com versões fixas + hashes
$ uv sync --frozen                  # respeita uv.lock

# 2. Auditar vulnerabilidades conhecidas na árvore:
$ npm audit
$ pip-audit                          # pip install pip-audit

# 3. Fixar imagens Docker por digest, não por tag mutável:
# RUIM:  FROM node:20
# BOM:   FROM node:20@sha256:abc123...   (imutável)

# 4. Escanear a imagem antes de subir:
$ trivy image meuapp:latest          # CVEs nas camadas

Dependabot / Renovate — automatizar a vigilância

Manualmente acompanhar CVEs de todas as suas dependências é inviável. Ferramentas como Dependabot (GitHub, grátis) e Renovate abrem pull requests automáticos quando uma dependência tem update — marcando quais são correções de segurança. Você revisa, o CI testa, e você faz merge. A vigilância vira parte do fluxo em vez de uma tarefa que ninguém faz.

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    # Agrupar updates menores num PR só, pra não inundar:
    groups:
      minor-patch:
        update-types: ["minor", "patch"]
  - package-ecosystem: "docker"
    directory: "/"
    schedule:
      interval: "weekly"

9.7 Dependências da aplicação no servidor

Há um ponto que escapa de muita gente: o servidor roda runtimes (Node, Python, PostgreSQL) que também recebem CVEs, e nem sempre vêm pelo apt. Se você instalou Node via NodeSource, Python via deadsnakes, ou roda tudo em contêiner, o unattended-upgrades do sistema pode não estar cobrindo esses.

• Runtimes via PPA / repositório externo: confira se o Allowed-Origins inclui o repositório, ou atualize-os manualmente no seu ciclo.
• Tudo em contêiner: o patching se desloca para o build da imagem. Rebuildar a imagem com base atualizada e redeployar é o "apt upgrade" do mundo Docker. Imagem que nunca é reconstruída acumula CVEs silenciosamente.
• Banco gerenciado vs auto-hospedado: se você roda Postgres na própria VPS, o patching dele é seu problema. Banco gerenciado (Cap 19) transfere isso ao provedor — um dos principais argumentos a favor.

9.8 O que monitorar

Automação sem monitoramento é só um jeito mais silencioso de falhar — o mesmo princípio do Cap 4 sobre renovação de TLS. Você precisa de visibilidade de que o patching está, de fato, acontecendo. O mínimo viável:

# Quantos pacotes de segurança pendentes?
$ apt list --upgradable 2>/dev/null | grep -c security

# unattended-upgrades rodou nas últimas 24h?
$ grep "$(date +%Y-%m-%d)" \
    /var/log/unattended-upgrades/unattended-upgrades.log

# Reboot pendente?
$ [ -f /var/run/reboot-required ] && echo "REBOOT NECESSÁRIO" \
    || echo "ok"

# /boot tem espaço?
$ df -h /boot

9.9 Estudo de caso — endurecer o patching de uma VPS

$ apt list --upgradable 2>/dev/null | grep security
$ df -h /boot
$ uname -r ; ls /boot/vmlinuz-*
$ ls /var/run/reboot-required 2>/dev/null
# Entender o estado: o que está pendente, há reboot acumulado?

# Em janela de baixo tráfego, snapshot antes (provedor) por segurança:
$ sudo apt update
$ sudo unattended-upgrade -v   # aplica só o repo de security
# needrestart deve reiniciar os serviços afetados

$ sudo apt autoremove --purge
$ df -h /boot          # conferir que baixou de 78%

$ sudo apt install unattended-upgrades needrestart
# Editar 50unattended-upgrades: Remove-Unused-Kernel,
# Mail on-change, needrestart automático (seção 9.4)
$ sudo nano /etc/apt/apt.conf.d/50unattended-upgrades
$ sudo nano /etc/needrestart/needrestart.conf  # $nrconf{restart}='a'

# Reboot automático às 4h (downtime tolerável neste caso):
# Automatic-Reboot "true"; Automatic-Reboot-Time "04:00";
$ sudo unattended-upgrade --dry-run --debug   # validar

# No repositório da aplicação:
$ npm audit            # ou pip-audit
# Habilitar Dependabot (.github/dependabot.yml)
# Fixar imagem base Docker por digest

9.10 Erros comuns

9.11 Exercícios

$ sudo apt update
$ apt list --upgradable 2>/dev/null | grep -c security
# → nº de pacotes de segurança pendentes

$ systemctl is-enabled unattended-upgrades
$ cat /etc/apt/apt.conf.d/20auto-upgrades
# Unattended-Upgrade "1" = ativo

$ [ -f /var/run/reboot-required ] && echo PENDENTE || echo ok
$ df -h /boot

$ sudo apt install unattended-upgrades needrestart apt-listchanges
$ sudo dpkg-reconfigure --priority=low unattended-upgrades

# /etc/apt/apt.conf.d/50unattended-upgrades
Unattended-Upgrade::Remove-Unused-Kernel-Packages "true";
Unattended-Upgrade::Remove-Unused-Dependencies "true";
Unattended-Upgrade::Mail "voce@exemplo.com";
Unattended-Upgrade::MailReport "on-change";
# Allowed-Origins: manter SÓ as linhas -security

# /etc/needrestart/needrestart.conf
$nrconf{restart} = 'a';   # automático, sem prompt

# Validar:
$ sudo unattended-upgrade --dry-run --debug

# 1. Auditar:
$ npm audit                  # Node
$ pip install pip-audit && pip-audit   # Python

# 2. Lockfile versionado?
$ git ls-files | grep -E "package-lock.json|uv.lock|poetry.lock"
# Se vazio: o lockfile NÃO está no git. Corrija.

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule: { interval: "weekly" }
    groups:
      minor-patch:
        update-types: ["minor", "patch"]

Logs e o
início da
observabilidade.

Todo servidor gera logs. A diferença entre quem opera bem e quem opera no escuro não é ter logs — é conseguir responder perguntas com eles. "Por que o site caiu às 3h14?" tem resposta em segundos para quem sabe onde olhar, e é um mistério de horas para quem só sabe que "tem um log em algum lugar".

Este capítulo fecha a Parte II ensinando a enxergar dentro do servidor. Vamos cobrir onde os logs realmente moram em um Linux moderno, dominar o journald (a peça central que quase ninguém aprende direito), configurar rotação para não encher o disco, entender níveis e structured logging, e — o mais importante — passar de "eu tenho logs" para "eu consigo responder perguntas". No fim, um panorama honesto de quando vale centralizar logs num serviço externo e quando é cedo demais para isso. É a fundação de observabilidade sobre a qual a Parte III vai construir Sentry, uptime e métricas.

10.1 A história — de arquivos de texto a journald

10.2 Conceitos — os três pilares

Observabilidade costuma ser descrita por três tipos de sinal. Vale conhecer os três para saber onde os logs se encaixam — e onde param.

Para um servidor único rodando uma aplicação, logs respondem 80% das perguntas operacionais: o que quebrou, quando, com qual erro, precedido de quê. Métricas entram quando você quer tendências ("a memória vem subin­do há uma semana?"). Traces só fazem sentido com múltiplos serviços. Comece pelos logs, domine-os, e adicione o resto quando a dor justificar — não antes.

10.3 Onde os logs realmente moram

Em um Ubuntu/Debian moderno, há essencialmente dois mundos coexistindo. Saber qual olhar economiza muito tempo.

10.4 journald na prática

O journalctl é a ferramenta que você vai viver dentro. Vale memorizar um punhado de invocações — elas cobrem quase tudo.

As consultas que você vai usar todo dia

# Seguir tudo ao vivo (o "tail -f" do journal):
$ journalctl -f

# Logs de UM serviço, ao vivo:
$ journalctl -u nginx -f
$ journalctl -u meuapp.service -f

# Desde o último boot (perde ruído de boots antigos):
$ journalctl -b

# Janela de tempo — investigando "caiu às 3h14":
$ journalctl --since "03:00" --until "03:30"
$ journalctl --since "2026-06-15 02:00" --since "1 hour ago"

# Só erros e acima (prioridade):
$ journalctl -p err -b

# Kernel (OOM killer, disco, rede):
$ journalctl -k -b

# Mais recentes primeiro, sem paginador:
$ journalctl -u meuapp -n 100 --no-pager -r

Garantir que o journal persiste

# O journal está persistente ou volátil?
$ journalctl --header | grep -i "File path"
# /run/log/...  → volátil (some no reboot)
# /var/log/journal/... → persistente (sobrevive)

# Tornar persistente:
$ sudo mkdir -p /var/log/journal
$ sudo systemd-tmpfiles --create --prefix /var/log/journal
$ sudo systemctl restart systemd-journald

# Verificar uso de disco do journal:
$ journalctl --disk-usage

Fazer sua aplicação logar no journal

A maneira mais limpa de a sua app aparecer no journalctl -u meuapp é rodá-la como um serviço systemd e deixar que ela escreva em stdout/stderr. O systemd captura essas saídas e as roteia para o journal automaticamente — sem você gerenciar arquivo de log nenhum.

[Unit]
Description=Minha aplicação
After=network.target

[Service]
User=appuser
WorkingDirectory=/opt/meuapp
ExecStart=/opt/meuapp/.venv/bin/gunicorn app:app -b 127.0.0.1:8000
Restart=on-failure

# Saída vai pro journal; identificador facilita o filtro:
StandardOutput=journal
StandardError=journal
SyslogIdentifier=meuapp

[Install]
WantedBy=multi-user.target

10.5 Rotação e retenção — não deixar o disco encher

Log que cresce sem limite é uma bomba-relógio: o disco enche, a aplicação que tenta escrever falha, o banco para de aceitar gravação, e o servidor vira um tijolo. Há dois sistemas de rotação rodando em paralelo, um para cada mundo de logs.

journald — limites embutidos

[Journal]
Storage=persistent

# Teto de espaço total do journal:
SystemMaxUse=1G

# Apagar entradas mais antigas que isto:
MaxRetentionSec=30day

# Deixar pelo menos isto livre no disco:
SystemKeepFree=2G

# Reduzir o journal a 500MB agora:
$ sudo journalctl --vacuum-size=500M

# Apagar tudo mais antigo que 7 dias:
$ sudo journalctl --vacuum-time=7d

logrotate — para os logs em arquivo

Logs próprios (Nginx, Caddy, e qualquer coisa que escreva em /var/log/*.log) são geridos pelo logrotate, que roda diariamente via cron/timer. Ele renomeia, comprime e descarta logs antigos.

/var/log/meuapp/*.log {
    daily                 # rotacionar todo dia
    rotate 14             # manter 14 arquivos (≈14 dias)
    compress              # gzip dos antigos
    delaycompress         # não comprimir o mais recente
    missingok             # ok se o arquivo não existir
    notifempty            # não rotacionar arquivo vazio
    create 0640 appuser appuser
    sharedscripts
    postrotate            # avisar a app pra reabrir o arquivo
        systemctl reload meuapp.service > /dev/null 2>&1 || true
    endscript
}

$ sudo logrotate --debug /etc/logrotate.d/meuapp   # dry-run
$ sudo logrotate --force /etc/logrotate.d/meuapp   # forçar agora

10.6 Níveis de log e structured logging

Dois hábitos de aplicação melhoram drasticamente a utilidade dos logs — e ambos são decisões de quem escreve a app, não de quem opera o servidor.

Use níveis com disciplina

• DEBUG — detalhe para desenvolvimento. Desligado em produção (ou ligado só temporariamente).
• INFO — eventos normais dignos de registro: "usuário X logou", "job Y concluído".
• WARNING — algo estranho mas recuperável: "retry da API externa", "cache miss inesperado".
• ERROR — falhou uma operação, mas a app segue de pé: "pagamento recusado", "exceção tratada".
• CRITICAL — a app não consegue continuar: "sem conexão com o banco". É o que deve te acordar.

A regra prática: se tudo é ERROR, nada é ERROR. Logar com nível certo é o que permite journalctl -p err retornar exatamente os problemas reais, e não 10 mil linhas de ruído de INFO.

Logue estruturado, não frases

User joao falhou login
do IP 1.2.3.4 às 3h14

{"level":"warning",
 "event":"login_failed",
 "user":"joao",
 "ip":"1.2.3.4"}

10.7 De "tenho logs" a "respondo perguntas"

O salto de maturidade do capítulo é este: parar de "olhar logs" e começar a interrogá-los. Toda investigação operacional é uma pergunta. Veja como traduzir perguntas reais em comandos.

# Sintoma: "o site ficou lento/fora por volta das 3h"
# 1. O que a app reportou naquela janela?
$ journalctl -u meuapp --since "03:00" --until "03:30" -p warning

# 2. O kernel matou algo por falta de memória?
$ journalctl -k --since "03:00" | grep -i "oom\|killed process"

# 3. A app reiniciou? (systemd registra Started/Stopped)
$ journalctl -u meuapp --since "03:00" | grep -E "Started|Stopped|Failed"

# 4. O disco encheu naquele momento? (correlacionar)
$ journalctl --since "03:00" | grep -i "no space\|disk full"

# Conclusão típica: OOM killer derrubou gunicorn → systemd
# reiniciou → 90s de indisponibilidade. Causa raiz: memória.

10.8 Centralizar logs — quando (e quando não)

Em algum momento alguém vai sugerir mandar todos os logs para um serviço externo — Grafana Loki, a stack ELK, Datadog, Better Stack. É uma boa ideia… eventualmente. O ponto é não fazer cedo demais nem tarde demais.

Sinais de que vale centralizar

• Mais de um servidor. "Em qual das três máquinas aconteceu?" vira insustentável dando SSH em cada uma. Esse é o gatilho nº 1.
• Logs efêmeros. Contêineres ou instâncias que somem (autoscaling, deploys frequentes) levam os logs junto. Precisa de um lugar fora da máquina.
• Você precisa correlacionar app + proxy + banco numa visão só, com busca rápida em janelas grandes.
• Alertas baseados em log: "me avise se aparecerem 10 erros 500 em 1 minuto" — difícil com journalctl, natural numa plataforma.

10.9 Estudo de caso — diagnosticar uma queda noturna

# Journal sobreviveu à madrugada?
$ journalctl --header | grep -i "file path"   # /var/log/journal = bom

# Ver tudo na janela do incidente:
$ journalctl --since "03:05" --until "03:20" -p warning --no-pager

$ journalctl -u meuapp --since "03:05" | grep -E "Stopped|Started|Failed|killed"
# Achado: "Main process exited, code=killed, signal=KILL"
# seguido de "Started Minha aplicação" 8s depois.
# → algo MATOU o processo, e o systemd o reergueu.

$ journalctl -k --since "03:05" | grep -i "out of memory\|oom"
# Achado: "Out of memory: Killed process 1234 (gunicorn)"
# → o kernel matou o gunicorn por falta de memória. Causa raiz.

# Havia um job pesado às 3h? cron, backup, relatório?
$ journalctl --since "03:00" --until "03:15" | grep -iE "cron|backup|report"
# Achado: backup do Postgres roda às 03h10 e consome RAM.
# Pico de backup + carga da app estourou a memória da VPS.

10.10 Erros comuns

10.11 Exercícios

# Persistente ou volátil?
$ journalctl --header | grep -i "file path"
# Se aparecer /run/log → volátil. Corrigir:
$ sudo mkdir -p /var/log/journal
$ sudo systemd-tmpfiles --create --prefix /var/log/journal
$ sudo systemctl restart systemd-journald

# Espaço ocupado:
$ journalctl --disk-usage

# Erro mais recente:
$ journalctl -p err -n 1 --no-pager -r

[Unit]
Description=App de exemplo
After=network.target

[Service]
ExecStart=/usr/bin/bash -c 'while true; do echo "tick $(date)"; sleep 5; done'
StandardOutput=journal
StandardError=journal
SyslogIdentifier=exemplo
Restart=on-failure

[Install]
WantedBy=multi-user.target

$ sudo systemctl daemon-reload
$ sudo systemctl enable --now exemplo
$ journalctl -u exemplo -f          # deve ver os "tick"

# Limitar o journal em /etc/systemd/journald.conf:
[Journal]
Storage=persistent
SystemMaxUse=500M
$ sudo systemctl restart systemd-journald

# (a) erros da app na última hora
$ journalctl -u meuapp -p err --since "1 hour ago"

# (b) logins SSH falhos hoje
$ journalctl -u ssh --since today | grep -i "failed\|invalid"

# (c) OOM killer neste boot
$ journalctl -k -b | grep -i "out of memory\|killed process"

# (d) quantas vezes a app iniciou desde o boot
$ journalctl -u meuapp -b | grep -c "Started"

# (e) janela específica de ontem
$ journalctl --since "yesterday 02:00" --until "yesterday 02:05"

Reverse proxy:
Nginx, Caddy,
Traefik.

Sua aplicação escuta em 127.0.0.1:8000. O mundo espera em 443. Entre os dois mora o reverse proxy — a peça que recebe o tráfego da internet, encerra o TLS, e entrega para a aplicação certa. É a porta de entrada de quase tudo que você vai colocar no ar, e a primeira coisa a configurar quando a app sai do "roda na minha máquina".

Este capítulo abre a Parte III conectando o servidor (Parte II) à aplicação. Vamos entender por que praticamente nunca se expõe a aplicação direto na porta 443, comparar honestamente as três ferramentas dominantes — Caddy, Nginx e Traefik — e configurar cada uma para o caso real: HTTPS automático, proxy reverso para a app, e os headers sem os quais a aplicação enxerga o mundo errado. A recomendação será pragmática (Caddy para a maioria dos projetos solo), mas você vai sair sabendo operar Nginx, que ainda domina o que já existe lá fora.

11.1 A história — de servir arquivos a orquestrar tráfego

11.2 Por que não expor a aplicação direto

A pergunta honesta de quem está começando: minha app já consegue escutar na 443 e falar HTTPS — por que botar um proxy na frente? Porque o proxy resolve, num só lugar, uma lista de problemas que você não quer que cada aplicação resolva sozinha:

• Terminação TLS. Certificados, renovação, versões de protocolo, ciphers — tudo num lugar, não espalhado por cada serviço. A app fala HTTP simples internamente.
• Múltiplos serviços, uma porta. api.seudominio.com e app.seudominio.com na mesma máquina, na mesma 443, roteados por nome (virtual hosts). Sem proxy, eles brigariam pela porta.
• Servir estáticos com eficiência. Imagens, CSS, JS entregues pelo proxy (otimizado para isso) em vez de ocupar workers da aplicação.
• Buffer e proteção. O proxy absorve conexões lentas, requests malformados e picos, protegendo a aplicação. Encerra a conexão lenta sem prender um worker da app.
• Operação sem downtime. Recarregar config, trocar a versão da app por trás (blue-green), adicionar um segundo backend — tudo sem o cliente perceber.
• Cabeçalhos, compressão, rate limit, redirects. Política transversal aplicada antes de chegar na app.

11.3 Conceitos — forward vs reverse, upstream, virtual host

Forward proxy vs reverse proxy

Os dois "ficam no meio", mas em pontas opostas. Um forward proxy fica na frente dos clientes (uma VPN corporativa que filtra a saída dos funcionários). Um reverse proxy fica na frente dos servidores: o cliente acha que fala com um servidor só, mas por trás há um proxy distribuindo para uma ou mais aplicações. É deste segundo que o capítulo trata.

Cliente                Reverse proxy            Aplicações (upstream)
  │                         │                          │
  │  GET / HTTPS :443       │                          │
  ├────────────────────────►│  encerra TLS             │
  │                         │  roteia por hostname     │
  │                         │  GET / HTTP :8000        │
  │                         ├─────────────────────────►│ app principal
  │                         │                          │
  │                         │  (api.dominio → :9000)   │
  │                         ├─────────────────────────►│ API
  │  resposta HTTPS         │                          │
  │◄────────────────────────┤◄─────────────────────────┤
  │                         │                          │
internet (público)     127.0.0.1 só local       só localhost

Vocabulário que você vai ler em toda config

• Upstream / backend: a aplicação para onde o proxy encaminha. Ex.: 127.0.0.1:8000.
• Virtual host / server block: a regra que diz "para o hostname X, mande para o upstream Y". É o que permite vários sites numa máquina.
• Terminação TLS: o proxy descriptografa o HTTPS de fora e fala HTTP (ou HTTPS interno) com a app.
• proxy_pass / reverse_proxy: a diretiva concreta que faz o encaminhamento (Nginx usa a primeira, Caddy a segunda).
• Load balancing: distribuir entre vários upstreams (round-robin, least-conn). Relevante quando há mais de uma instância da app.

11.4 Nginx, Caddy ou Traefik — a escolha

Antes da prática, a decisão. Os três fazem o trabalho; o que muda é o atrito e o encaixe.

11.5 Caddy na prática

O argumento do Caddy se prova na primeira config. Aqui está um proxy reverso completo, com HTTPS automático, para uma aplicação rodando em 127.0.0.1:8000:

# É isto. Caddy obtém e renova o certificado sozinho.
meuapp.com.br {
    reverse_proxy 127.0.0.1:8000
}

Duas linhas úteis. O Caddy resolve o ACME (Cap 4) automaticamente: pede o certificado, valida, instala, renova antes de expirar, sem cron, sem certbot, sem você lembrar. Um exemplo mais realista, com estáticos, compressão, headers e múltiplos sites:

meuapp.com.br {
    encode gzip zstd                  # compressão automática

    # Servir estáticos direto do disco, app só pro resto:
    handle_path /static/* {
        root * /opt/meuapp/static
        file_server
    }

    reverse_proxy 127.0.0.1:8000

    # Headers de segurança básicos:
    header {
        Strict-Transport-Security "max-age=31536000"
        X-Content-Type-Options "nosniff"
        -Server                        # esconde o header Server
    }

    log {
        output file /var/log/caddy/meuapp.log
    }
}

# Segundo serviço, mesma máquina, outro hostname:
api.meuapp.com.br {
    reverse_proxy 127.0.0.1:9000
}

# Redirect do www pro apex:
www.meuapp.com.br {
    redir https://meuapp.com.br{uri} permanent
}

$ sudo apt install caddy            # repo oficial do Caddy

# Validar a sintaxe antes de aplicar:
$ caddy validate --config /etc/caddy/Caddyfile

# Recarregar sem downtime (graceful):
$ sudo systemctl reload caddy

# Ver o que está acontecendo:
$ journalctl -u caddy -f            # amarra no Cap 10

11.6 Nginx na prática

Você vai encontrar Nginx em todo lugar, então precisa saber lê-lo e operá-lo mesmo que escolha Caddy para o novo. A mesma tarefa — proxy reverso com HTTPS — exige mais peças, mas cada uma é explícita e ajustável.

# Redireciona HTTP → HTTPS:
server {
    listen 80;
    listen [::]:80;
    server_name meuapp.com.br;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name meuapp.com.br;

    # Certificado (gerado pelo certbot — Cap 4):
    ssl_certificate     /etc/letsencrypt/live/meuapp.com.br/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/meuapp.com.br/privkey.pem;

    # Estáticos direto do disco:
    location /static/ {
        alias /opt/meuapp/static/;
        expires 30d;
    }

    # Tudo o mais vai para a app:
    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host              $host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

# Habilitar o site (symlink para sites-enabled):
$ sudo ln -s /etc/nginx/sites-available/meuapp \
             /etc/nginx/sites-enabled/

# SEMPRE testar a config antes de recarregar:
$ sudo nginx -t
# nginx: configuration file ... test is successful

# Recarregar sem derrubar conexões:
$ sudo systemctl reload nginx

# HTTPS automático no Nginx? Use certbot:
$ sudo certbot --nginx -d meuapp.com.br   # Cap 4

11.7 Traefik, brevemente

O Traefik brilha num cenário específico: você roda tudo em Docker e quer que novos serviços apareçam no proxy sem editar config. Em vez de você declarar rotas, o Traefik observa o Docker e se configura sozinho a partir de labels nos contêineres.

services:
  meuapp:
    image: meuapp:latest
    labels:
      # O Traefik lê isto e cria a rota sozinho:
      - "traefik.enable=true"
      - "traefik.http.routers.app.rule=Host(`meuapp.com.br`)"
      - "traefik.http.routers.app.tls.certresolver=le"
      - "traefik.http.services.app.loadbalancer.server.port=8000"

Suba um novo contêiner com as labels certas e ele já está roteado e com HTTPS — sem tocar no proxy. Em ambiente estático (um servidor, dois ou três serviços fixos), essa dinâmica é complexidade desnecessária; Caddy é mais simples. Mas quando serviços nascem e morrem o tempo todo, o Traefik economiza um trabalho manual constante. É também o motor por trás de várias plataformas self-hosted que veremos no Cap 12.

11.8 Os headers que importam (e quebram tudo se faltam)

Quando há um proxy no meio, a aplicação para de ver o cliente diretamente — ela vê o proxy. Sem repassar certas informações, a app toma decisões erradas. Estes são os headers críticos:

11.9 Estudo de caso — pôr no ar app + API + estáticos

$ sudo ss -tlnp | grep -E ":8000|:9000"
# Devem aparecer em 127.0.0.1, NÃO em 0.0.0.0.
# Se estiverem em 0.0.0.0, corrija o bind da app (Cap 8).

meuapp.com.br {
    encode gzip zstd
    handle_path /static/* {
        root * /opt/meuapp/static
        file_server
    }
    reverse_proxy 127.0.0.1:8000
    log { output file /var/log/caddy/app.log }
}

api.meuapp.com.br {
    reverse_proxy 127.0.0.1:9000
    log { output file /var/log/caddy/api.log }
}

# 80/443 abertos só para os ranges Cloudflare (Cap 8):
$ sudo ufw status | grep -E "80|443"
# DNS dos dois hostnames com proxy laranja ON (Cap 2).
# Modo SSL/TLS: Full (strict) (Cap 4).

$ caddy validate --config /etc/caddy/Caddyfile
$ sudo systemctl reload caddy
$ journalctl -u caddy -f      # ver o ACME obter os certs

# Do seu lado, testar cada superfície:
$ curl -I https://meuapp.com.br
$ curl -I https://api.meuapp.com.br
$ curl -I https://meuapp.com.br/static/logo.png

11.10 Erros comuns

11.11 Exercícios

teste.meudominio.com.br {
    reverse_proxy 127.0.0.1:8000
}

$ caddy validate --config /etc/caddy/Caddyfile
$ sudo systemctl reload caddy
$ journalctl -u caddy -f          # ver o certificado ser emitido

$ curl -I https://teste.meudominio.com.br    # 200 + cadeado

# De OUTRA máquina, a porta 8000 deve estar inacessível:
$ curl --max-time 5 http://SEU-IP:8000    # deve dar timeout

loja.com.br {
    handle_path /static/* {
        root * /opt/loja/static
        file_server
    }
    reverse_proxy 127.0.0.1:8000
}
www.loja.com.br {
    redir https://loja.com.br{uri} permanent
}

# HTTP → HTTPS para os dois hostnames:
server {
    listen 80;
    server_name loja.com.br www.loja.com.br;
    return 301 https://loja.com.br$request_uri;
}

# Redirect do www (em HTTPS):
server {
    listen 443 ssl http2;
    server_name www.loja.com.br;
    ssl_certificate     /etc/letsencrypt/live/loja.com.br/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/loja.com.br/privkey.pem;
    return 301 https://loja.com.br$request_uri;
}

# Site principal:
server {
    listen 443 ssl http2;
    server_name loja.com.br;
    ssl_certificate     /etc/letsencrypt/live/loja.com.br/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/loja.com.br/privkey.pem;

    location /static/ {
        alias /opt/loja/static/;
        expires 30d;
    }
    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host              $host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Plataformas
self-hosted:
Coolify, Dokploy.

No capítulo anterior você configurou o proxy na mão. Funciona, e ensina muito. Mas quando os serviços começam a se multiplicar — app, API, banco, fila, três projetos de cliente — editar Caddyfile e escrever units systemd vira trabalho repetitivo. As plataformas self-hosted dão o "git push e tá no ar" do Heroku, rodando na sua própria VPS. O Heroku que é seu.

Este capítulo é sobre subir um nível de abstração sem perder o controle. Vamos entender o que Coolify e Dokploy resolvem (deploy via git, TLS automático, gestão de proxy e contêineres por uma interface), o trade-off honesto que essa conveniência cobra, e como escolher entre os dois. Você vai instalar uma plataforma e subir o primeiro app. Mas o ponto mais importante — e o que diferencia este livro de um tutorial — é entender o que roda por baixo: tudo que a plataforma faz, você já sabe fazer na mão (Caps 8, 11). Isso é o que te salva quando a abstração vaza.

12.1 A história — o fantasma do Heroku

12.2 O que essas plataformas resolvem

Tudo que uma plataforma self-hosted faz, você poderia montar à mão com as peças dos capítulos anteriores. O valor está em ter tudo integrado numa interface, sem cola manual entre as partes:

• Deploy via git. Conecta o repositório (GitHub/GitLab); cada push dispara build e deploy automático. Webhook → build da imagem → troca do contêiner sem downtime.
• TLS automático. A plataforma obtém e renova certificados Let's Encrypt sozinha (via Traefik, no caso de ambas). Todo o Cap 4 resolvido por baixo.
• Reverse proxy gerenciado. Você diz "este app responde por app.dominio.com" numa caixa de texto; a plataforma escreve a config do proxy. O Cap 11 virou um formulário.
• Serviços de um clique. Postgres, Redis, MySQL, ou apps prontos (Ghost, Plausible, Umami) sobem de um catálogo, já conectados.
• Variáveis de ambiente e secrets geridos pela interface, injetados nos contêineres.
• Rollback e logs acessíveis sem SSH — voltar à versão anterior é um botão; os logs do contêiner aparecem na tela.

12.3 O trade-off central — conveniência vs controle

Toda abstração cobra um preço. A plataforma esconde a complexidade, mas a complexidade não some — ela passa a ser problema da plataforma, que agora você também precisa entender e manter.

12.4 Coolify vs Dokploy — a escolha em 2026

As duas são open source, rodam num VPS, fazem deploy via git, TLS automático por Traefik e Docker por baixo. São mais parecidas do que diferentes — a escolha é fit-para-o-caso, não estilo de vida. Onde divergem:

A leitura prática: Coolify se você quer o ecossistema mais maduro, o maior catálogo de serviços de um clique e mais comunidade/tutoriais — ao custo de mais consumo de recurso. Dokploy se você quer algo leve, com UI limpa, e está confortável perto do Docker/Swarm — especialmente num VPS pequeno onde o overhead importa.

12.5 Instalar e subir o primeiro app

O fluxo é parecido nas duas. Usarei Coolify como exemplo por ser o mais comum, mas os conceitos transferem direto para o Dokploy. Pré-requisito honesto: faça os Caps 6–8 primeiro. A plataforma assume um servidor minimamente são; instalá-la num servidor cru e exposto é convidar problema.

# O instalador detecta o SO, instala Docker se faltar,
# baixa as imagens e configura o serviço. Leia o script antes:
$ curl -fsSL https://cdn.coollabs.io/coolify/install.sh -o install.sh
$ less install.sh                  # NUNCA rode curl|bash às cegas
$ sudo bash install.sh

# Ao fim, ele indica a URL do painel, tipicamente:
#   http://SEU-IP:8000
# Crie a conta admin IMEDIATAMENTE (antes que outro crie).

Subir uma aplicação, conceitualmente

Com o painel no ar, o fluxo para qualquer app é o mesmo, e mapeia exatamente nos capítulos anteriores:

1. Conectar o servidor (no Coolify, pode ser o próprio ou outro via SSH — Cap 7).
2. Conectar o git (GitHub App ou deploy key). A plataforma passa a receber webhooks de push.
3. Criar o recurso "Application": aponta o repo, a branch, e como buildar (Dockerfile próprio ou Nixpacks, que detecta a stack automaticamente).
4. Definir o domínio: você digita app.seudominio.com; a plataforma configura o Traefik e emite o TLS (Caps 4 e 11, num campo de texto).
5. Variáveis de ambiente: cola os secrets na interface; eles entram no contêiner.
6. Deploy: o primeiro é manual (um botão); os próximos disparam sozinhos a cada push.

# A plataforma criou contêineres — veja-os:
$ docker ps
# Deve aparecer o Traefik (proxy), o painel, e seu app.

# O DNS do app aponta pra Cloudflare → VPS? (Caps 1, 2)
# O firewall libera 80/443 só pra Cloudflare? (Cap 8)
# O TLS emitiu? (Cap 4)
$ curl -I https://app.seudominio.com

12.6 O que roda por baixo (e por que você precisa saber)

Aqui está o coração do capítulo. Uma plataforma self-hosted não é mágica — é uma orquestração das peças que você já conhece. Mapear o painel de volta para os fundamentos é o que te dá poder de debug:

12.7 Segurança do painel — uma responsabilidade nova

Instalar uma plataforma de deploy adiciona uma superfície de ataque poderosa: um painel que pode subir contêineres, ler secrets e executar comandos no servidor. Tratá-lo com o mesmo rigor do SSH (Cap 7) não é exagero.

• Nunca exponha o dashboard ao mundo. Restrinja por firewall ao seu IP (Cap 8), ou ponha atrás de VPN/Tailscale, ou no mínimo atrás de autenticação forte e um domínio com TLS. O painel aberto é acesso root indireto.
• Mantenha a plataforma atualizada. Estas plataformas têm CVEs como qualquer software — o Coolify teve 11 reportadas em janeiro de 2026 (injeção de comando, exposição de chave privada), todas corrigidas. O padrão reflete a complexidade da ferramenta. A lição não é "evite", é "mantenha atualizado religiosamente" (Cap 9).
• Senha forte + 2FA na conta admin. É a chave do reino.
• Isole, se possível. O Coolify recomenda rodar o painel num servidor e os recursos (apps) em outros, via SSH. Para projeto solo num VPS só, não é viável — mas saiba que misturar painel e produção na mesma máquina concentra risco.
• Backups da configuração da plataforma e dos volumes dos bancos (Cap 16). A plataforma facilita criar coisas; não te isenta de ter backup delas.

12.8 Quando NÃO usar uma plataforma

12.9 Estudo de caso — três projetos de cliente numa VPS

# O servidor já passou pelos Caps 6-8? Confirmar:
$ sudo ufw status                  # firewall ativo
$ sudo systemctl status fail2ban   # SSH protegido (Cap 7)

# Snapshot do provedor ANTES de instalar nada novo.

$ curl -fsSL https://cdn.coollabs.io/coolify/install.sh -o i.sh
$ less i.sh && sudo bash i.sh

# Criar admin na hora. Depois, fechar o painel ao mundo:
$ sudo ufw allow from SEU-IP-CASA to any port 8000 proto tcp
# (ou pôr atrás de domínio + 2FA). Habilitar 2FA no admin.

12.10 Erros comuns

12.11 Exercícios

# 1. Instalar (lendo o script antes):
$ curl -fsSL https://cdn.coollabs.io/coolify/install.sh -o i.sh
$ less i.sh && sudo bash i.sh

# 2. Fechar o painel ao mundo — só seu IP:
$ sudo ufw allow from SEU-IP to any port 8000 proto tcp
$ sudo ufw reload

# 3. No painel: criar admin, habilitar 2FA, conectar git,
#    criar app, definir domínio, deploy.

# 4. Conferir do lado do servidor:
$ docker ps                        # Traefik + painel + app
$ curl -I https://app-teste.seudominio.com   # 200 + TLS
$ sudo ss -tlnp                    # app NÃO deve estar exposta direto