Firewalls e controle de tráfego em servidores: regras, estados e listas de acesso

O que um firewall faz (e o que ele não faz)

Firewall é um mecanismo de controle de tráfego: ele decide se um pacote (ou fluxo) pode passar com base em regras. Em servidores, ele é usado para reduzir a superfície de ataque e limitar comunicações ao mínimo necessário.

• Firewall não é antivírus: ele não inspeciona arquivos para detectar malware.
• Firewall não corrige aplicações: se você expõe um serviço vulnerável, o firewall pode até limitar quem acessa, mas não elimina a vulnerabilidade.
• Firewall não substitui autenticação: abrir SSH apenas para um IP ajuda, mas ainda é preciso chave, MFA, hardening etc.

Onde o firewall pode existir: host vs perímetro

Na prática, você costuma ter camadas:

• Host firewall: roda no próprio servidor (ex.: nftables/iptables, firewalld, ufw). É a última linha de defesa e é ótimo para regras por serviço e por interface.
• Firewall de perímetro: fica na borda da rede (appliance, roteador, cloud security group). Controla o que entra/sai do ambiente e pode aplicar políticas por sub-rede/VLAN.

Uma boa regra mental: perímetro filtra o macro (o que pode chegar na rede/segmento) e host filtra o micro (o que pode chegar naquele servidor).

Entendendo allow/deny, política padrão e ordem das regras

Allow/Deny e a política padrão (default policy)

Regras de firewall normalmente seguem o modelo:

• allow (permitir): deixa passar tráfego que combina com os critérios.
• deny/drop (negar): bloqueia o tráfego. Pode ser drop (silencioso) ou reject (responde com erro).

Além das regras, existe a política padrão para o que não casar com nenhuma regra. Em servidores, o padrão mais seguro é:

Continue em nosso aplicativo e ...

• Ouça o áudio com a tela desligada
• Ganhe Certificado após a conclusão
• + de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

• Entrada (inbound): negar por padrão e permitir apenas o necessário.
• Saída (outbound): permitir por padrão (com exceções quando você precisa controlar exfiltração ou compliance).

Ordem das regras: o primeiro match vence

Em muitos firewalls, as regras são avaliadas de cima para baixo. A primeira regra que casar com o pacote decide o destino (permitir/bloquear). Isso cria dois cuidados comuns:

• Regras genéricas no topo podem anular regras específicas abaixo (ex.: um deny amplo antes de um allow específico).
• Exceções geralmente devem vir antes da regra geral (ex.: permitir rede interna antes de negar o resto).

Exemplo conceitual (ordem importa):

1) deny  tcp any -> server:22        (bloqueia SSH de todo mundo)  ❌ se vier antes do allow abaixo, não adianta ter allow depois
2) allow tcp 203.0.113.10 -> server:22 (permitir seu IP)

Ordem correta:

1) allow tcp 203.0.113.10 -> server:22
2) deny  tcp any -> server:22

Stateful vs stateless: por que isso muda suas regras

Stateless (sem estado)

Um firewall stateless avalia cada pacote isoladamente. Isso significa que, para uma conexão TCP, você pode precisar permitir explicitamente tráfego de retorno (dependendo da implementação e do sentido das regras).

Problema comum em stateless: você libera entrada para um serviço, mas esquece que a resposta pode usar portas efêmeras no cliente, e a regra fica mais complexa.

Stateful (com estado)

Um firewall stateful acompanha o estado das conexões (ex.: NEW/ESTABLISHED/RELATED). Assim, você normalmente escreve regras como:

• Permitir conexões NEW para portas de serviço (ex.: 80/443/22).
• Permitir automaticamente tráfego ESTABLISHED e RELATED (respostas e fluxos associados).

Isso simplifica e reduz erros. Em Linux, é comum ver regras baseadas em conntrack (rastreamento de conexão).

Entrada vs saída: pense em quem inicia a conexão

Tráfego de entrada (inbound)

É o tráfego que chega ao servidor vindo de fora (Internet, rede interna, outra VLAN). Ex.: clientes acessando seu site, administradores acessando SSH.

Boa prática: inbound deny por padrão e abrir apenas o que for necessário.

Tráfego de saída (outbound)

É o tráfego iniciado pelo servidor para fora. Ex.: servidor baixando atualizações, consultando DNS, enviando logs, conectando em um banco remoto.

Mesmo quando outbound está liberado, você deve saber que:

• Bloqueios de outbound podem quebrar atualizações, resolução DNS, NTP e integrações.
• Restringir outbound é uma defesa forte contra exfiltração e movimentação lateral, mas exige inventário de dependências.

Listas de acesso (ACLs): a mesma ideia em outros lugares

ACL (Access Control List) é um termo amplo para regras de permitir/negar aplicadas em:

• Firewalls (host/perímetro).
• Roteadores e switches L3 (ACLs por interface, filtrando tráfego entre redes).
• Security Groups/NACLs em nuvem (conceitos similares, com diferenças de estado e direção conforme o provedor).

A habilidade transferível aqui é: descrever o tráfego (origem, destino, protocolo, porta, direção, interface) e aplicar o mínimo necessário.

Passo a passo: construindo uma política mínima para um servidor web com SSH

Objetivo: um servidor que hospeda um site (HTTP/HTTPS) e permite administração via SSH, com exposição mínima.

Passo 1: inventariar serviços e quem precisa acessar

• HTTP (80) e HTTPS (443): acessível por qualquer cliente (Internet).
• SSH (22): acessível apenas por IPs de administração (ex.: seu escritório/VPN/bastion).
• Outros serviços: não expor (bloquear por padrão).

Passo 2: definir políticas padrão

• Inbound: DROP (nega tudo que não estiver explicitamente permitido).
• Outbound: ACCEPT (inicialmente), e depois endurecer se necessário.

Passo 3: permitir tráfego de retorno (stateful)

Em firewalls stateful, crie uma regra geral para permitir conexões estabelecidas/relacionadas:

allow state ESTABLISHED,RELATED (inbound)

Isso evita quebrar respostas de conexões iniciadas pelo servidor e o retorno de conexões permitidas.

Passo 4: abrir HTTP/HTTPS para todos

allow tcp any -> server:80
allow tcp any -> server:443

Passo 5: abrir SSH apenas para origens confiáveis

Exemplo: permitir SSH apenas do IP público do seu escritório (203.0.113.10) e de uma VPN (198.51.100.0/24):

allow tcp 203.0.113.10 -> server:22
allow tcp 198.51.100.0/24 -> server:22

Em seguida, garanta que o restante está bloqueado pela política padrão (ou por uma regra explícita):

deny tcp any -> server:22

Passo 6: validar com testes simples

• De um IP permitido: testar SSH.
• De um IP não permitido: confirmar que SSH falha.
• De qualquer lugar: confirmar que 80/443 respondem.

Ferramentas comuns de teste (do lado do cliente):

curl -I http://SEU_IP_OU_DOMINIO
curl -I https://SEU_IP_OU_DOMINIO
ssh -v usuario@SEU_IP

Passo a passo: banco de dados acessível apenas na rede interna

Cenário: um servidor de banco (ex.: PostgreSQL 5432 ou MySQL 3306) que não deve ser acessível pela Internet, apenas por servidores de aplicação na rede interna.

Passo 1: definir quem pode acessar

Escolha a menor origem possível:

• Preferível: IPs dos servidores de aplicação (lista curta).
• Aceitável: sub-rede interna (ex.: 10.0.10.0/24).

Passo 2: negar por padrão e permitir apenas a porta do banco para a origem interna

Exemplo para PostgreSQL:

allow tcp 10.0.10.0/24 -> dbserver:5432
deny  tcp any -> dbserver:5432

Exemplo para MySQL:

allow tcp 10.0.10.0/24 -> dbserver:3306
deny  tcp any -> dbserver:3306

Passo 3: cuidado com acesso administrativo

Se você administra o banco via SSH, mantenha o padrão: SSH restrito (por IP/VPN/bastion). Evite abrir a porta do banco para sua máquina diretamente pela Internet.

Passo 4: validar de dentro e de fora

• De um servidor na rede interna: testar conexão na porta do banco.
• De fora (Internet): confirmar que a porta não responde.

Testes comuns:

nc -vz DB_IP 5432
nc -vz DB_IP 3306

IPv6: regras separadas e armadilhas comuns

Em muitos ambientes, IPv4 e IPv6 são filtrados por pilhas e regras separadas. Um erro frequente é:

• Você bloqueia bem no IPv4, mas esquece de aplicar regras equivalentes no IPv6, e o serviço fica exposto via IPv6.

Checklist prático para não esquecer IPv6

• Verifique se o servidor tem IPv6 global configurado (endereço público).
• Crie regras equivalentes para IPv6 (HTTP/HTTPS aberto, SSH restrito, banco apenas interno).
• Se você não usa IPv6, decida conscientemente: desabilitar (quando permitido pela política) ou filtrar com deny por padrão.

Exemplo conceitual de paridade de regras

Se no IPv4 você tem:

allow tcp any -> server:443
allow tcp 203.0.113.10 -> server:22
deny  inbound default

No IPv6 você precisa do equivalente (com os IPs/prefixos IPv6 corretos):

allow tcp any -> server:443 (IPv6)
allow tcp 2001:db8:abcd::10 -> server:22 (IPv6)
deny  inbound default (IPv6)

Observação importante: em IPv6, ICMPv6 é mais crítico para o funcionamento da rede do que ICMP no IPv4. Bloquear ICMPv6 indiscriminadamente pode causar problemas de conectividade e MTU (PMTUD).

Drop vs Reject: como isso aparece para quem testa

Quando um firewall bloqueia, ele pode:

• DROP (silencioso): o cliente não recebe resposta. Para quem testa, parece timeout.
• REJECT (ativo): o firewall responde com erro (ex.: TCP RST ou ICMP unreachable). Para quem testa, parece falha imediata.

ICMP bloqueado: impacto real no diagnóstico (e na rede)

ICMP é usado para mensagens de erro e diagnóstico. Bloquear ICMP “por segurança” sem critério costuma piorar operação e troubleshooting.

O que você percebe quando ICMP está bloqueado

• Ping falha, mas o serviço pode estar funcionando (HTTP/SSH podem responder mesmo sem ping).
• Traceroute pode ficar incompleto ou enganoso (depende do método e do que é bloqueado).
• Problemas de MTU podem aparecer como conexões que travam ou downloads que não completam, especialmente se mensagens de “fragmentation needed” / “packet too big” forem bloqueadas (mais sensível em IPv6).

Boa prática: permitir ICMP de forma controlada

Em vez de bloquear tudo, permita tipos necessários (principalmente em IPv6) e, se preciso, restrinja por origem (rede interna/monitoramento) e por rate limit. A implementação exata varia, mas o objetivo é:

• Manter diagnóstico e mensagens de erro funcionando.
• Evitar abuso com limitação de taxa.

Como ler sintomas e isolar onde está o bloqueio

1) Diferenciar “serviço fora” de “firewall bloqueando”

Se você tem acesso ao servidor, verifique primeiro se o serviço está escutando localmente. Se localmente funciona e remotamente não, o problema tende a ser firewall/ACL/rota.

Testes locais (no servidor):

ss -lntp   # portas TCP em escuta e processo
ss -lnup   # portas UDP em escuta

Teste local de aplicação:

curl -I http://127.0.0.1
curl -I http://SEU_IP_LOCAL

2) Identificar se é “fechado” ou “filtrado”

• Fechado: geralmente resposta imediata (refused). Indica serviço não escutando ou reject.
• Filtrado: timeout. Indica drop por firewall/ACL ou problema de caminho.

Exemplos:

nc -vz IP 443   # refused vs timeout ajuda a diferenciar
ssh -v user@IP  # verbose mostra em que etapa trava

3) Checar divergências IPv4/IPv6

Ao diagnosticar, force a pilha:

curl -4 -I https://DOMINIO
curl -6 -I https://DOMINIO

Se um funciona e outro não, procure:

• Regras de firewall aplicadas apenas em uma pilha.
• Publicação/DNS apontando para IPv6 que você não pretendia expor.

4) Confirmar se o bloqueio está no host ou no perímetro

Estratégia prática:

• Se você controla o perímetro e o host: compare regras dos dois lados.
• Se o host está liberado, mas continua bloqueado: suspeite de ACL/firewall upstream.
• Se o perímetro está liberado, mas continua bloqueado: suspeite do host firewall.

Uma evidência forte é observar contadores/logs de regras (quando habilitados). Em Linux, é comum habilitar log temporário para uma porta específica durante o troubleshooting (com cuidado para não gerar excesso de logs).

Padrões de regras recomendados (modelos mentais)

Modelo A: servidor web público

• Inbound default: deny/drop
• Allow: 80/tcp e 443/tcp de qualquer origem
• Allow: 22/tcp apenas de IPs de administração
• Allow: established/related
• IPv6: repetir o mesmo desenho

Modelo B: servidor de banco interno

• Inbound default: deny/drop
• Allow: porta do banco apenas da sub-rede/hosts de aplicação
• Allow: SSH apenas de rede de administração
• Negar explicitamente a porta do banco para qualquer outra origem (para deixar a intenção clara)
• IPv6: aplicar o mesmo (ou bloquear totalmente se não houver uso)