Configuração de firewall: UFW, iptables e políticas de segurança

Um alerta do servidor tirou a equipe da cama: o banco de dados de um ambiente de testes apresentava tráfego anormal de varredura. Ao entrar no servidor, veio a surpresa: o firewall estava desativado. Depois de ativá-lo, a lista de regras revelou várias configurações de teste desorganizadas, e a porta SSH nem sequer tinha limitação de taxa.

O episódio deixa um problema bastante concreto: ao configurar um firewall, muita gente apenas copia alguns comandos e encerra o assunto; outras pessoas nem sabem qual é a diferença entre UFW e iptables, muito menos como elaborar uma política de segurança de forma sistemática. É isso que vamos organizar aqui.

Como o firewall do Linux realmente funciona

Antes de falar em firewall, é preciso esclarecer um conceito que costuma causar confusão: Netfilter. Muita gente pensa que iptables é o próprio firewall, mas não é bem assim.

O Netfilter é a estrutura do kernel Linux responsável pelo processamento de pacotes de rede. Ele posiciona vários “ganchos” (hooks) em pontos importantes da pilha de protocolos do kernel. Cada pacote que passa por ali aciona esses ganchos, onde você pode aplicar lógicas de processamento como bloquear, modificar ou registrar o pacote.

iptables, UFW e nftables são apenas interfaces de configuração no espaço do usuário. As regras escritas com essas ferramentas acabam convertidas para um formato que o Netfilter entende e executa no kernel.

Uma analogia: o Netfilter é o sistema de válvulas instalado sob a tubulação; o iptables é um registro manual antigo; e o UFW é um painel de controle moderno com tela sensível ao toque. Todos abrem e fecham as válvulas, mas de maneiras bem diferentes.

A evolução das ferramentas no espaço do usuário

As ferramentas de firewall do Linux mudaram bastante nos últimos anos:

• iptables: ferramenta tradicional que existe desde aproximadamente o ano 2000. Opera diretamente sobre o Netfilter; a sintaxe é complexa, mas os recursos são amplos.
• nftables: substituto moderno do iptables, introduzido em 2014. Tem sintaxe mais uniforme e melhor desempenho; versões recentes do Ubuntu já o usam como backend padrão.
• UFW (Uncomplicated Firewall): ferramenta simplificada lançada pelo Ubuntu em 2008. Continua usando iptables/nftables por baixo, mas oferece comandos muito mais simples.
• firewalld: gerenciador dinâmico de firewall das distribuições da família Red Hat, capaz de alterar regras em tempo de execução sem interromper conexões.

Este artigo se concentra em UFW e iptables porque ambos ainda aparecem com frequência na administração de sistemas. O nftables é mais moderno, mas compartilha vários conceitos com o iptables; depois de entender o iptables, a transição fica bem mais fácil.

UFW: uma configuração de firewall menos dolorosa

Por que o UFW é tão popular

Quem já usou iptables conhece a tensão de escrever cada regra com todo cuidado, com receio de errar um parâmetro, bloquear a porta SSH e ficar sem acesso ao servidor.

A ideia central do UFW é priorizar a simplicidade. Um único comando libera uma porta, sem exigir que você memorize uma sintaxe como -A INPUT -p tcp --dport 22 -j ACCEPT.

Veja a diferença:

iptables:

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j ACCEPT

UFW:

ufw allow ssh

A diferença é evidente. O UFW cuida automaticamente de detalhes como protocolo, rastreamento de estado e IPv6; você só precisa dizer que deseja liberar o SSH.

Configuração básica: começando do zero

Ao receber um servidor novo, siga esta sequência para configurar o firewall:

Primeiro passo: definir as políticas padrão

A política padrão determina o que acontece quando nenhuma regra corresponde ao pacote. O princípio básico de segurança é negar todas as conexões de entrada e permitir todas as conexões de saída.

sudo ufw default deny incoming   # Nega todas as conexões de entrada
sudo ufw default allow outgoing   # Permite todas as conexões de saída

Com isso, nenhuma solicitação externa entra a menos que você a autorize explicitamente. Muita gente escolhe allow por padrão para evitar trabalho; o resultado é um servidor parecido com uma casa de portas abertas.

Segundo passo: liberar as portas necessárias

Há uma armadilha aqui: libere o SSH antes de ativar o firewall. Caso contrário, sua conexão remota será encerrada imediatamente.

sudo ufw allow ssh        # Libera o SSH (porta 22)
sudo ufw allow 80/tcp     # HTTP
sudo ufw allow 443/tcp    # HTTPS

Se você usa outro serviço, como SSH em uma porta personalizada — 2222, por exemplo —, execute:

sudo ufw allow 2222/tcp

Terceiro passo: ativar o firewall

sudo ufw enable

O sistema exibirá o aviso “This may disrupt existing ssh connections”. Não se assuste: se você executou allow ssh antes, a conexão continuará funcionando. Digite y para confirmar.

Quarto passo: conferir o status

sudo ufw status verbose

A saída será parecida com esta:

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), deny (routed)

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    Anywhere
80/tcp                     ALLOW IN    Anywhere
443/tcp                    ALLOW IN    Anywhere

Quando aparecer Status: active, o firewall já estará em vigor.

Técnicas avançadas para reforçar a segurança

Perfis de aplicativos (App Profiles)

O UFW oferece um recurso especialmente útil: App Profiles. Vários serviços comuns, como Nginx, Apache e OpenSSH, já incluem perfis predefinidos.

Liste os perfis disponíveis:

Alibaba Cloud - Escolha dos desenvolvedores, 15% de desconto exclusivo em Lighthouse

Ganhar 15% off →Anúncio

sudo ufw app list

A saída pode incluir:

Available applications:
  Apache
  Apache Full
  Apache Secure
  Nginx Full
  Nginx HTTP
  Nginx HTTPS
  OpenSSH

Use diretamente o nome do aplicativo para liberar as portas:

sudo ufw allow 'Nginx Full'

Esse comando libera HTTP (80) e HTTPS (443) ao mesmo tempo, dispensando duas regras manuais.

Limitação de taxa contra força bruta

A porta SSH é um alvo recorrente de ataques de força bruta. O UFW oferece limitação de taxa integrada:

sudo ufw limit ssh

Essa regra bloqueia temporariamente um IP que tentar se conectar mais de seis vezes em 30 segundos. É muito mais seguro do que usar apenas allow ssh.

Restringir o acesso a um IP específico

Em alguns casos, apenas um IP deve acessar determinado serviço. O painel de administração do banco de dados, por exemplo, pode ficar restrito à rede da empresa:

# Permite que somente 192.168.1.100 acesse o MySQL
sudo ufw allow from 192.168.1.100 to any port 3306

# Bloqueia um IP mal-intencionado
sudo ufw deny from 203.0.113.100

Registro em log

Os logs do firewall são essenciais para investigar problemas:

sudo ufw logging on
sudo ufw logging medium   # Níveis de log: low/medium/high

Os registros ficam em /var/log/ufw.log e têm um formato parecido com este:

Mar 15 10:23:45 server kernel: [UFW BLOCK] IN=eth0 OUT= MAC=... SRC=203.0.113.100 DST=... PROTO=TCP SPT=54321 DPT=22

Ao encontrar [UFW BLOCK], você sabe que o firewall bloqueou aquela solicitação.

Limitações do UFW

O UFW é fácil de usar, mas tem limites:

• NAT e encaminhamento de portas: o suporte é limitado; configurações complexas ainda exigem iptables
• Cadeias de regras complexas: não permite cadeias personalizadas nem condições aninhadas
• Filtragem por conteúdo: não consegue, por exemplo, filtrar um payload malicioso em uma solicitação HTTP

Se a sua necessidade ultrapassa esses limites, é hora de usar iptables.

iptables: controle preciso das regras

Entendendo a arquitetura do iptables

O iptables é mais complexo que o UFW, mas sua lógica interna é bem definida. O ponto principal é entender a estrutura em três níveis: tabelas, cadeias e regras.

Tabelas (Tables)

Cada tabela processa um tipo de tarefa:

• Tabela filter (padrão): filtra pacotes e decide se devem ser aceitos ou bloqueados
• Tabela nat: faz tradução de endereços (NAT) e reescreve endereços de origem ou destino
• Tabela mangle: modifica metadados do pacote, como TOS e TTL
• Tabela raw: configura exceções que ignoram o rastreamento de conexões

Na maioria dos cenários, apenas a tabela filter é necessária; por isso, ela será usada como padrão.

Cadeias (Chains)

Uma cadeia é um conjunto de regras executadas em sequência. A tabela filter tem cinco cadeias integradas:

• INPUT: pacotes de entrada cujo destino é a própria máquina
• OUTPUT: pacotes de saída cuja origem é a própria máquina
• FORWARD: pacotes encaminhados, quando a máquina atua apenas como intermediária
• PREROUTING: processamento antes do roteamento
• POSTROUTING: processamento depois do roteamento

As configurações cotidianas usam principalmente INPUT e OUTPUT. FORWARD é necessária quando a máquina funciona como roteador ou gateway.

Ordem de correspondência das regras

As regras são verificadas de cima para baixo. A primeira correspondência executa a ação, e as regras seguintes deixam de ser avaliadas.

Veja este exemplo:

iptables -A INPUT -s 192.168.1.100 -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -j DROP

Com essa ordem, 192.168.1.100 corresponde à primeira regra ACCEPT e é liberado imediatamente, sem chegar à segunda. Se você inverter as regras, o mesmo endereço será bloqueado pela primeira regra DROP e nunca alcançará a segunda.

Esse é o princípio central da configuração do iptables: coloque as regras mais específicas antes das regras mais gerais.

Anatomia da sintaxe básica

O formato básico de um comando iptables é:

iptables -t tabela -A cadeia condições_de_correspondência -j ação

Parâmetros comuns:

• -t: especifica a tabela; o padrão é filter e pode ser omitido
• -A: adiciona uma regra ao fim da cadeia (Append)
• -I: insere uma regra em uma posição específica (Insert)
• -D: exclui uma regra (Delete)
• -L: lista as regras (List)
• -F: limpa todas as regras (Flush)
• -P: define a política padrão (Policy)

Condições de correspondência

• -s: endereço IP de origem, como -s 192.168.1.100
• -d: endereço IP de destino
• -p: protocolo, como tcp, udp ou icmp
• --sport: porta de origem
• --dport: porta de destino
• -i: interface de entrada, como -i eth0
• -o: interface de saída
• -m state --state: verificação do estado da conexão

Ações (Target)

• ACCEPT: aceita o pacote
• DROP: descarta silenciosamente, sem retornar informação
• REJECT: rejeita e retorna uma mensagem de erro
• LOG: registra em log sem bloquear e continua verificando as regras seguintes
• RETURN: encerra a cadeia atual e retorna à cadeia anterior

Configuração prática de um firewall seguro para servidor

Veja um processo completo para um ambiente de produção:

Primeiro passo: limpar as regras existentes

Servidores novos podem conter regras padrão. Limpe-as antes de começar:

sudo iptables -F        # Limpa todas as regras
sudo iptables -X        # Exclui todas as cadeias personalizadas
sudo iptables -t nat -F
sudo iptables -t mangle -F

Segundo passo: definir as políticas padrão

Assim como no UFW, negue as conexões de entrada por padrão:

sudo iptables -P INPUT DROP
sudo iptables -P FORWARD DROP
sudo iptables -P OUTPUT ACCEPT

Terceiro passo: permitir conexões estabelecidas

Esta regra é especialmente importante: ela permite a passagem do tráfego de resposta e dos dados de conexões já estabelecidas.

sudo iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

O que isso significa? Quando você acessa um site, a solicitação enviada passa por OUTPUT, cuja política padrão é ACCEPT. A resposta do site entra por INPUT. Sem essa regra, o pacote de resposta seria descartado, e você não receberia dado algum.

ESTABLISHED indica uma conexão já estabelecida; RELATED representa uma conexão relacionada, como uma conexão de dados FTP.

Quarto passo: liberar as portas necessárias

# SSH
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# HTTP
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT

# HTTPS
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT

Quinto passo: restringir ICMP (opcional)

ICMP é o protocolo usado pelo ping. Algumas políticas de segurança bloqueiam ping:

# Permite ping
sudo iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT

# Ou bloqueia ping
sudo iptables -A INPUT -p icmp -j DROP

Sexto passo: registrar em log

Adicione uma regra LOG antes do DROP para facilitar a investigação:

sudo iptables -A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 4

--limit 5/min evita uma avalanche de logs, limitando o registro a cinco entradas por minuto.

Sétimo passo: o DROP final

A política padrão já é DROP, mas uma regra explícita deixa a configuração mais clara:

sudo iptables -A INPUT -j DROP

Oitavo passo: salvar as regras

As regras do iptables não são persistentes por padrão e desaparecem após uma reinicialização. No Ubuntu/Debian, você pode usar iptables-persistent:

Railway - Plataforma de deploy moderna, sem ops complexas, no ar em minutos

Começar agora →Anúncio

sudo apt install iptables-persistent
sudo netfilter-persistent save

Outra opção é salvar manualmente:

sudo iptables-save > /etc/iptables/rules.v4
sudo ip6tables-save > /etc/iptables/rules.v6  # Regras IPv6

Consultar o estado das regras

sudo iptables -L -n -v --line-numbers

• -n: usa números sem resolver nomes de domínio, o que é mais rápido
• -v: modo detalhado, com contagem de pacotes
• --line-numbers: mostra o número de cada regra

Exemplo de saída:

Chain INPUT (policy DROP 0 packets, 0 bytes)
num  pkts bytes target     prot opt in     out     source               destination
1      42  2848 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state ESTABLISHED,RELATED
2       0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:22
3       0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80
4       0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:443
5       0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0            limit: avg 5/min burst 5 LOG flags 0 level 4 prefix "iptables denied: "
6       0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0

UFW ou iptables: qual escolher

Depois de tudo isso, a dúvida pode continuar: devo usar UFW ou iptables?

Diferença central: facilidade de uso ou flexibilidade

A verdade sobre o desempenho

Muita gente acredita que o iptables tem melhor desempenho, mas o mecanismo subjacente é exatamente o mesmo: o Netfilter faz o trabalho no kernel. A única diferença vem da quantidade de regras; quanto mais regras, mais lenta a correspondência. Para servidores pequenos e médios, esse impacto é pouco relevante.

Recomendações de escolha

Cenários em que o UFW é recomendado:

• VPS, servidor em nuvem ou servidor dedicado
• Implantação de serviços web e APIs
• Ausência de requisitos de rede complexos, como NAT ou encaminhamento de portas
• Quem não é administrador de sistemas especializado e não quer aprender a sintaxe do iptables
• Configuração de segurança rápida, como na resposta emergencial a um ataque

Cenários em que o iptables é recomendado:

• Gateway, roteador ou servidor VPN
• Necessidade de NAT, encaminhamento de portas ou balanceamento de carga
• Cadeias de regras complexas e condições em várias camadas
• Implantação em grande escala, com dezenas de servidores gerenciados por scripts
• Filtragem avançada por conteúdo, taxa ou horário
• Equipe de operações com profissionais responsáveis pela configuração da rede

É possível misturar os dois?

Não é recomendável. UFW e iptables manipulam o mesmo conjunto de regras do Netfilter, portanto combiná-los pode provocar conflitos.

Por exemplo, você pode liberar a porta SSH com iptables e depois bloqueá-la com deny no UFW. A última regra aplicada entra em vigor, e você fica sem acesso.

Se for realmente necessário misturar os dois, observe a ordem: as regras do UFW ficam entre before.rules e after.rules, e regras adicionadas diretamente pelo iptables podem ser sobrescritas pelas regras padrão do UFW.

Princípios centrais para projetar uma política de firewall

Dominar a ferramenta é apenas o primeiro passo. O mais importante é elaborar uma política de segurança coerente. Regras adicionadas sem planejamento costumam deixar várias brechas.

Princípio 1: negação por padrão (Default Deny)

Essa é a base de uma configuração segura.

Ideia central: negue tudo que não tiver sido permitido explicitamente.

O caminho inverso é permitir tudo por padrão e bloquear uma a uma as portas consideradas perigosas. Essa abordagem tem dois problemas:

1. Você não sabe quais portas representam risco; um invasor pode verificar todas as 65.535 portas
2. Basta esquecer uma porta para deixar uma vulnerabilidade

A configuração correta é:

# UFW
sudo ufw default deny incoming
sudo ufw default allow outgoing

# iptables
sudo iptables -P INPUT DROP
sudo iptables -P OUTPUT ACCEPT

Depois, libere somente as portas indispensáveis ao serviço. Para cada porta, pergunte: para que ela serve? É possível restringir o IP de origem?

Princípio 2: privilégio mínimo

Cada regra deve ter uma única função, com o menor escopo possível.

Liberação de portas:

• ❌ ufw allow 3306 (qualquer pessoa na internet pode se conectar ao MySQL)
• ✅ ufw allow from 192.168.1.100 to any port 3306 (somente um IP específico)

Acesso aos serviços:

• ❌ Liberar todas as portas dos serviços internos
• ✅ Liberar apenas os serviços voltados à internet, como Web e API; acessar os internos pela rede privada ou VPN

Administração por SSH:

• ❌ ufw allow ssh (qualquer pessoa pode tentar entrar)
• ✅ ufw allow from IP_DA_EMPRESA to any port 22 + ufw limit ssh

Princípio 3: defesa em camadas (Defense-in-Depth)

O firewall não resolve tudo; ele é apenas a primeira linha de defesa. Uma arquitetura de segurança completa deve ter várias camadas:

1. Firewall de rede (UFW/iptables): bloqueia tráfego mal-intencionado
2. Firewall de aplicação (WAF): filtra injeção de SQL, XSS e outros ataques na camada HTTP
3. Proteção do host (SELinux/AppArmor): restringe as permissões dos processos
4. Detecção de intrusão (IDS/IPS): monitora comportamentos anormais em tempo real
5. Auditoria periódica: análise de logs e varredura de vulnerabilidades

Por exemplo, depois que o firewall libera a porta HTTP 80, o WAF verifica payloads maliciosos nas solicitações HTTP, enquanto o SELinux limita o acesso do servidor web aos arquivos. Mesmo depois de atravessar essas três camadas, o invasor ainda encontra as proteções da aplicação, como validação de entrada e verificação de permissões.

Princípio 4: segmentação de rede (Network Segmentation)

Uma rede grande não pode ser tratada como um único bloco; é preciso dividi-la em zonas.

Um modelo típico de segmentação inclui:

• DMZ (Demilitarized Zone): serviços expostos à internet, como servidores web e de e-mail
• Zona interna: bancos de dados, serviços internos e rede de escritório
• Zona de administração: operações, monitoramento e logs

A segmentação traz três benefícios:

1. Isolamento de falhas: se a DMZ for comprometida, o invasor ainda precisa atravessar outra barreira para chegar à rede interna
2. Limitação da propagação: um worm pode se espalhar dentro de uma zona, mas o firewall o bloqueia na passagem entre zonas
3. Permissões mais precisas: usuários de zonas diferentes recebem acessos distintos

Ao configurar a segmentação com iptables, a cadeia FORWARD é essencial:

# Da DMZ para a rede interna: permite apenas acesso ao banco de dados
iptables -A FORWARD -s dmz_network -d internal_network -p tcp --dport 3306 -j ACCEPT
iptables -A FORWARD -s dmz_network -d internal_network -j DROP

Princípio 5: auditoria e atualização periódicas

A configuração do firewall não é algo que se faz uma única vez.

Revisão das regras:

• Todo mês: há alguma regra vencida, como uma porta de teste que deveria ter sido removida?
• A cada trimestre: depois das mudanças no negócio, as portas liberadas ainda fazem sentido?
• Todo ano: elimine regras redundantes e otimize o desempenho

Análise de logs:

• Toda semana: quais IPs foram bloqueados e por quê?
• Alertas de tráfego anormal: defina limites e envie notificações quando forem ultrapassados
• Investigação de ataques: use os logs para localizar a origem e reforçar as proteções correspondentes

Resposta às mudanças:

• Serviço novo: avalie o risco de segurança antes de liberar a porta
• Incidente de ataque: ajuste regras, bloqueie IPs mal-intencionados e adicione limitação de taxa
• Mudança no serviço: remova regras desnecessárias e reduza a superfície exposta

Configuração em produção: como evitar armadilhas

Uma sequência segura para configurar

Primeiro passo: validar no ambiente de testes

Nunca experimente uma regra nova diretamente no servidor de produção. Configure-a primeiro em uma VM de testes ou em um ambiente de desenvolvimento; só leve a mudança para produção depois de verificar que tudo funciona.

Segundo passo: preservar uma rota de acesso por SSH

Antes de configurar, verifique se a porta SSH já está liberada. Se você usa uma porta personalizada, lembre-se de executar:

# UFW
ufw allow 2222/tcp  # Porta SSH personalizada

# iptables
iptables -A INPUT -p tcp --dport 2222 -j ACCEPT

Terceiro passo: liberar as portas gradualmente

Não libere todas as portas de uma só vez. Comece pela essencial, o SSH, confirme que ainda consegue entrar, depois libere as portas web e, por fim, os outros serviços.

Quarto passo: registrar as alterações de configuração

Registre cada mudança nas regras do firewall:

• Horário da alteração
• Conteúdo alterado
• Motivo da mudança
• Resultado da verificação

Você pode gerenciar os arquivos de configuração das regras com Git ou manter esses dados em um documento.

Vultr - Servidor cloud NVMe de alto desempenho, 32 locais globais, deploy Docker com um clique

Ver preços →Anúncio

Erros comuns e soluções

Erro 1: bloqueio do SSH

Sintoma: depois de ativar o firewall, a conexão SSH cai e você não consegue mais entrar no servidor.

Causa: a porta SSH não foi liberada antes, ou a ordem das regras está errada, com DROP antes de ACCEPT.

Como prevenir:

1. Confira a porta SSH atual antes de configurar
2. Execute ufw allow ssh antes de ufw enable
3. No iptables, garanta que a regra SSH esteja antes do DROP

Solução de emergência:

• VPS: entre pelo Console do provedor, que não depende de SSH
• Servidor em nuvem: use o “Recovery Mode” ou “Rescue System” oferecido pelo provedor
• Servidor físico: faça login localmente

Erro 2: ordem incorreta das regras

Sintoma: existe uma regra ACCEPT para a porta, mas ainda assim não é possível se conectar.

Causa: uma regra DROP anterior corresponde primeiro ao pacote.

Como investigar:

iptables -L -n -v --line-numbers

Confira os números das regras e verifique se ACCEPT aparece antes de DROP.

Como corrigir:

# Exclui a regra da posição incorreta
iptables -D INPUT 3

# Insere na posição correta
iptables -I INPUT 2 -p tcp --dport 80 -j ACCEPT

Erro 3: configuração não persistente

Sintoma: todas as regras do firewall desaparecem após uma reinicialização.

Causa: por padrão, as regras do iptables ficam apenas na memória e são apagadas ao reiniciar.

Como corrigir:

# Ubuntu/Debian
sudo apt install iptables-persistent
sudo netfilter-persistent save

# CentOS/RHEL
sudo service iptables save

O UFW já é persistente por padrão e não exige nenhuma ação adicional.

Erro 4: IPv6 ignorado

Sintoma: o IPv4 funciona normalmente, mas não há acesso por IPv6.

Causa: o iptables foi configurado apenas para IPv4; o IPv6 exige ip6tables.

Como corrigir:

# Regras IPv6, semelhantes às do IPv4
sudo ip6tables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo ip6tables -A INPUT -p tcp --dport 80 -j ACCEPT

# Salva as regras
sudo ip6tables-save > /etc/iptables/rules.v6

O UFW processa IPv6 automaticamente e não precisa de configuração separada.

Técnicas de diagnóstico

Quando a configuração do firewall apresentar problemas, siga esta sequência:

1. Verifique o status do firewall

# UFW
sudo ufw status verbose

# iptables
sudo iptables -L -n -v

Confirme que o firewall está ativo e que as regras estão corretas.

2. Teste a conectividade das portas

# Teste a partir de outra máquina
telnet server_ip 22
nc -zv server_ip 80

# Teste local
sudo netstat -tulnp | grep :22

3. Consulte os logs do firewall

# UFW
tail -f /var/log/ufw.log

# iptables
tail -f /var/log/kern.log | grep "iptables"

Verifique se há registros de solicitações bloqueadas.

4. Desative temporariamente para investigar

# UFW
sudo ufw disable

# iptables
sudo iptables -F

Teste a conectividade depois de desativar o firewall para confirmar se a causa é o firewall ou o próprio serviço.

Atenção: com o firewall desativado, o servidor fica completamente exposto. Restaure a proteção assim que terminar a investigação.

Conclusão: monte sua arquitetura de segurança de firewall

Depois de percorrer os conceitos e os comandos, estes são os pontos centrais.

Escolha da ferramenta

• Cenários simples: o UFW é suficiente, pode ser configurado em poucos minutos e reduz o trabalho operacional
• Cenários complexos: o iptables é mais flexível e serve para gateways, NAT e filtragem avançada
• Não misture as ferramentas: escolha uma para centralizar o gerenciamento e evitar conflitos entre regras

Princípios de configuração

• Negação por padrão: negue toda entrada e libere apenas as portas necessárias
• Privilégio mínimo: mantenha o escopo de cada regra o menor possível e restrinja os IPs de origem
• Defesa em camadas: o firewall é apenas a primeira camada; combine-o com WAF e SELinux
• Segmentação de rede: isole DMZ, rede interna e área de administração
• Auditoria periódica: revise todo mês, avalie a cada trimestre e reestruture uma vez por ano

Pontos práticos

• Libere o SSH primeiro: garanta que a porta SSH esteja acessível antes de configurar o firewall
• Observe a ordem das regras: no iptables, vá das regras específicas para as gerais
• Salve de forma persistente: as regras do iptables precisam ser salvas para carregar após a reinicialização
• Configure o IPv6: o iptables exige ip6tables separadamente; o UFW processa IPv6 automaticamente
• Valide no ambiente de testes: teste a configuração antes de aplicá-la em produção
• Mantenha logs: ative os logs do firewall e analise regularmente o tráfego anormal

Próximos assuntos para estudar

Para se aprofundar em firewall e segurança de servidores, explore:

• nftables: substituto moderno do iptables, com sintaxe mais uniforme e melhor desempenho
• firewalld: gerenciamento dinâmico de firewall com alterações em tempo de execução
• Configuração de WAF: Nginx ModSecurity e Cloudflare WAF
• Detecção de intrusão: Fail2ban, que bloqueia automaticamente ataques de força bruta, e OSSEC
• SELinux/AppArmor: controle de permissões no host

A configuração do firewall é a base da segurança de um servidor. Ao dominar UFW e iptables e entender os princípios de elaboração de políticas de segurança, seu servidor deixa de ser uma casa de portas abertas. E a chance de um alerta tirar você da cama às três da manhã também diminui.

Referências

• UFW Essentials: Common Firewall Rules and Commands - DigitalOcean
• UFW vs iptables: Simple Firewall Rules That Actually Work - WeHaveServers
• Diferenças entre ufw, nftables e iptables - Baeldung on Linux
• Princípios de projeto de firewall em segurança de redes - Fortinet
• Firewall no Linux: configuração, ferramentas e práticas recomendadas - TuxCare
• Wiki de ajuda da comunidade Ubuntu - UFW