Pular para o conteúdo 
Firewall iptables e UFW controlam quais conexões um servidor da Web aceita e quais eu bloqueio - isso determina a superfície de ataque e as falhas. Neste artigo prático, mostro regras claras, padrões seguros e comandos testados para SSH, HTTP(S), bancos de dados, registro em log, IPv6 e Docker - diretamente aplicáveis em hosts produtivos.
Pontos centrais
Os seguintes pontos-chave me dão uma orientação rápida antes de iniciar a configuração.
- Restritivo Início: Negar padrão para entrada, abrir especificamente
- SSH Permitir primeiro: não arriscar o acesso
- UFW como interface: sintaxe simples, iptables em segundo plano
- Registro em log ativar: Verificar regras, reconhecer ataques
- Persistência garantir: Manter regras sobre reinicializações
Noções básicas: iptables e UFW em resumo
Eu confio em iptablesquando preciso de controle refinado sobre pacotes, cadeias e correspondências. Uso o UFW quando quero aplicar rapidamente regras confiáveis que acabam internamente como regras do iptables [1]. Isso me permite combinar comandos simples com o poder do filtro de rede do Linux sem me perder nos detalhes. Para servidores Web, isso significa: eu crio um filtro claro na frente do Apache, Nginx ou Node para que apenas o tráfego desejado chegue [2]. Essa separação reduz as superfícies de ataque e permite que os ataques falhem com mais frequência.
As duas ferramentas se complementam e eu decido qual delas se adequa à situação. O UFW se destaca pela facilidade de leitura, especialmente no Ubuntu e no Debian [3]. O iptables me oferece opções ampliadas, por exemplo, para NAT, interfaces específicas e combinações complexas. Importante: Eu documento minhas regras de forma concisa para que a manutenção seja fácil mais tarde. Se quiser saber mais sobre o conceito de segurança, você pode encontrar uma introdução clara aqui: Firewall como escudo protetor.
Iniciar configuração: definir políticas padrão com segurança
Eu começo com Padrão-Políticas: bloquear a entrada, permitir a saída. É assim que evito que novos serviços sejam acessados de forma não intencional. Sempre permito o loopback para que os processos internos funcionem de forma estável. Aceito as conexões existentes para evitar cancelamentos. Essa sequência minimiza os erros ao ativar o firewall [2][5].
Eu uso o UFW para definir a base com apenas alguns comandos. Em seguida, verifico o status detalhadamente para perceber imediatamente os erros de digitação. Para hosts particularmente sensíveis, também restrinjo as portas de saída. Isso reduz o risco de vazamento de dados se um serviço tiver sido comprometido. Uso os seguintes comandos com frequência:
# UFW: Regras padrão
sudo ufw default deny incoming (negar entrada)
sudo ufw default allow outgoing
# Política de saída alternativa mais rígida
sudo ufw default deny outgoing (negar saída)
sudo ufw permite saída 53
sudo ufw permite saída 80
sudo ufw permite saída 443
# Verificar status
sudo ufw status verbose
Filtragem com estado: estados e sequência
Um fluxo de parcelas limpas se mantém e diminui com Declarações do Conntrack. Aceito conexões estabelecidas primeiro, descarto pacotes inválidos antecipadamente e deixo o loopback aberto. Isso reduz a carga e evita efeitos colaterais devido a quedas tardias. No iptables, defino deliberadamente a ordem:
# iptables: base sólida
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
# Sempre permitir loopback
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
# Permitir conexões existentes/associadas
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# Eliminar antecipadamente pacotes inválidos
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
Com o UFW, ESTABLISHED/RELATED já são levados em consideração internamente. Também presto atenção ao fato de eu preferir DROP (silencioso) ou REJEITAR (ativo, failover mais rápido). Para redes internas, prefiro REJECT; na rede pública, geralmente DROP.
Regras essenciais para servidores da Web: SSH, HTTP e HTTPS
Eu ligo SSH primeiro, caso contrário, eu me bloquearia facilmente. Em seguida, permito HTTP e HTTPS para que o servidor da Web fique acessível. Defino apenas as portas de que realmente preciso. Posteriormente, opcionalmente, adiciono limitação de taxa ou Fail2ban para restringir tentativas brutais de login. Verifico todas as alterações imediatamente com os comandos status ou list.
Eu mantenho os comandos simples para isso. O UFW oferece aliases de fala para portas da Web, o que aumenta a legibilidade. Com o iptables, posso definir portas e protocolos precisos. Depois, salvo as regras do iptables para que elas sobrevivam à reinicialização. Aqui estão as etapas mínimas:
# SSH
sudo ufw allow 22
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# HTTP/HTTPS
sudo ufw allow http
sudo ufw allow https
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j ACCEPT
SSH seguro: Restringir e abrir seletivamente
Além da liberação, atenuo os ataques com Limitação de taxa ou listas de permissões. O UFW oferece proteção simples:
# Limitação da taxa de SSH (UFW)
sudo ufw limit 22/tcp comentário "Limite de taxa SSH"
Eu defino limites mais finos com o iptables. Isso evita a adivinhação maciça de senhas sem excluir administradores legítimos:
# SSH: Limite de tentativas de conexão por fonte
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -m recent --name SSH --set
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW -m recent --name SSH --update --seconds 60 --hitcount 10 -j DROP
Sempre que possível, eu só permito SSH de Endereços IP de administrador e trabalhar com chaves SSH. A alteração de portas não substitui a segurança, mas pode reduzir o ruído. Eu documento as exceções e as verifico regularmente.
Proteja os bancos de dados e restrinja as fontes de IP
Eu nunca abro portas de banco de dados globalmente, mas apenas local ou para endereços IP de origem definidos. Isso impede que os scanners encontrem portas abertas do MySQL, PostgreSQL ou MongoDB. Para aplicativos locais, 127.0.0.1 é suficiente como alvo; eu controlo o acesso externo do administrador estritamente via IP. Eu documento as alterações brevemente, por exemplo, no wiki do servidor. Isso me poupa tempo durante as auditorias.
Costumo usar os exemplos a seguir em projetos. Verifico a exatidão de cada IP permitido com antecedência. O UFW permite uma notação "de-para" limpa; o iptables implementa a mesma lógica tecnicamente. Uso regras de permissão adicionais para janelas de manutenção temporárias e as excluo depois. Isso mantém a interface pequena:
# Somente local: MySQL
sudo ufw allow de 127.0.0.1 para qualquer porta 3306
iptables -A INPUT -p tcp -s 127.0.0.1 --dport 3306 -j ACCEPT
# Permitir um único IP
sudo ufw allow from 203.0.113.10
iptables -A INPUT -s 203.0.113.10 -j ACCEPT
# Permitir porta para IP específico
sudo ufw allow de 10.1.2.3 para qualquer porta 4444
iptables -A INPUT -p tcp -s 10.1.2.3 --dport 4444 -j ACCEPT
# Bloquear atacantes conhecidos
sudo ufw deny from 192.0.2.24
iptables -A INPUT -s 192.0.2.24 -j DROP
Tratamento limpo de registro, interfaces e IPv6
Eu ligo Registro em log para verificar as regras e reconhecer o tráfego visível. O nível "on" no UFW é suficiente para a maioria dos hosts; eu só uso níveis mais altos seletivamente. Analiso os registros com ferramentas journalctl, fail2ban ou SIEM. Isso me permite reconhecer padrões de varreduras ou tentativas de força bruta. Em caso de anomalias, ajusto as regras imediatamente [2].
Costumo vincular as regras a um Interfacecomo eth0 em redes públicas. Isso evita que as redes internas sejam afetadas desnecessariamente. O UFW pode "permitir a entrada na eth0 para qualquer porta 80", o iptables usa -i para interfaces de entrada. Para IPv6, eu verifico a ativação em /etc/default/ufw para "IPV6=yes" e uso ip6tables para regras nativas [2]. Essa separação evita falhas com hosts de pilha dupla.
ICMP e ICMPv6: acessibilidade sem lacunas
Deixo necessário ICMP-para que a descoberta do MTU do caminho, os tempos limite e os diagnósticos funcionem. O ICMP não é um inimigo, mas o núcleo do protocolo IP. Eu apenas limito o excesso de ecos.
# IPv4: Limitar o eco, permitir tipos importantes de ICMP
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 5/second --limit-burst 20 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT
iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
# UFW: Permitir ICMP em geral (é possível fazer um ajuste fino nas regras before.rules)
sudo ufw allow in proto icmp
Em IPv6 O ICMPv6 é absolutamente necessário (Neighbour Discovery, Router Advertisement). Eu permito os tipos principais e limito as solicitações de eco:
# IPv6 (ip6tables)
ip6tables -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type router-advertisement -j ACCEPT
ip6tables -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type neighbour-solicitation -j ACCEPT
ip6tables -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type neighbour-advertisement -j ACCEPT
ip6tables -A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type echo-request -m limit --limit 5/second --limit-burst 20 -j ACCEPT
Uso correto da restrição de saída e do NAT/mascaramento
Limito o tráfego de saída quando Perfil de risco e conformidade. Eu permito DNS e HTTPS e bloqueio todo o resto, exceto os alvos definidos. Isso reduz os dados exfiltrados se um serviço for sequestrado. Crio exceções definidas para aplicativos que exigem atualizações ou APIs. Eu documento essas exceções com clareza e as verifico regularmente.
Para configurações de roteamento, uso NAT/Masquerading via UFW-Before-Rules ou raw com iptables. Presto atenção à ordem das cadeias para que os pacotes sejam reescritos corretamente. Após as alterações, testo a conectividade e as latências. Para sistemas de produção, planejo uma janela de manutenção e faço backup da configuração. Isso me permite manter os caminhos da rede rastreáveis [7].
Detalhes de saída: serviços e protocolos do sistema
Com uma política de saída rigorosa, permito especificamente DNS (53/udp), HTTPS (443/tcp) e, se necessário NTP (Para servidores de e-mail, adiciono 25/tcp e 587/tcp. Não resolvo exceções baseadas em domínio no nível do pacote, mas por meio de proxies ou da lógica do aplicativo.
# UFW: serviços típicos do sistema
sudo ufw allow out 123/udp # NTP
sudo ufw allow out 25/tcp # SMTP - somente se for um servidor de correio eletrônico
sudo ufw allow out 587/tcp # Submission - somente se necessário
# iptables: Permissão específica
iptables -A OUTPUT -p udp --dport 123 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 25 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 587 -j ACCEPT
Docker e firewalls: evitando armadilhas
O Docker define seu próprio iptables-regras que podem influenciar minha política. Portanto, verifico as cadeias NAT e FORWARD após cada composição ou inicialização de daemon. Eu deliberadamente libero portas expostas e evito "-p 0.0.0.0:PORT". Em vez disso, eu as vinculei ao IP de gerenciamento ou ao proxy reverso. Isso mantém o vetor de ataque menor e mais visível [1].
Mantenho os firewalls do host ativos apesar do Docker. Também controlo os grupos de segurança no nível da infraestrutura, se disponível. No caso de conflitos entre o UFW e o Docker, uso soluções alternativas documentadas ou defino regras no DOCKER-USER. É importante ter responsabilidades claras: o host sempre bloqueia, os contêineres só abrem explicitamente. Essa ordem evita liberações inconscientes.
# DOCKER-USER: aplicar a política de host global antes das regras do Docker
iptables -N DOCKER-USER 2>/dev/null || true
iptables -I DOCKER-USER -s 192.0.2.24 -j DROP
iptables -A DOCKER-USER -j RETURN
Configurações finas do UFW: Sequência, perfis e tráfego roteado
Quando a precisão é importante, eu uso "inserir", "numerado" e perfis de aplicativos. É assim que mantenho a sequência de regras limpa e uso definições de serviço testadas.
# Sequência de controle
sudo ufw insert 1 deny in from 198.51.100.0/24
# Visualização numerada e exclusão direcionada
sudo ufw status numbered
sudo ufw delete 3
# Perfis de aplicativos (por exemplo, Nginx Full)
sudo ufw app list
sudo ufw app info "Nginx Full" (Nginx Completo)
sudo ufw allow "Nginx Full"
# Bloquear o tráfego roteado por padrão (encaminhamento)
sudo ufw default deny routed
Armazeno exceções mais complexas em before.rules respectivamente após.regras. Lá, posso colocar o ajuste fino do ICMP ou o NAT com precisão sem perder a legibilidade das regras padrão.
Regras persistentes: Salvar e restaurar
As regras do UFW são persistente e sobrevivem automaticamente às reinicializações. Isso simplifica muito a administração em hosts Debian/Ubuntu. Com o iptables, eu salvo as regras após as alterações e as restauro na inicialização. Para isso, uso o iptables-save/restore ou o netfilter-persistent. Sem essas etapas, eu perderia as alterações após uma reinicialização [5].
Eu testo a persistência sistematicamente: programo uma reinicialização e verifico o status. Se os contadores e as cadeias estiverem corretos, a configuração é sólida. Se as regras estiverem faltando, corrijo o caminho de carga no contexto do init ou do systemd. Essa rotina evita surpresas durante a manutenção. A documentação e o backup dos arquivos de regras completam o procedimento.
# Debian/Ubuntu: Persistência para iptables
sudo apt-get install -y iptables-persistent
sudo netfilter-persistent salvar
# Backup manual
sudo iptables-save | sudo tee /etc/iptables/rules.v4
sudo ip6tables-save | sudo tee /etc/iptables/rules.v6
Restauração do # (se necessário)
sudo iptables-restore < /etc/iptables/rules.v4
sudo ip6tables-restore < /etc/iptables/rules.v6
Desempenho e proteção: limites, conjuntos e ajuste do kernel
Quando a carga é alta, reduzo o número de controles e uso controles direcionados Limites de taxas. Para listas de blocos grandes, trabalho com o ipset para reduzir o tempo de consulta. Também uso mecanismos de proteção baseados no sistema:
# Conter inundação SYN (kernel)
sudo sysctl -w net.ipv4.tcp_syncookies=1
# Limitar a taxa de conexão HTTP por IP de origem (exemplo)
iptables -A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW
-m hashlimit --hashlimit-name http_rate --hashlimit-above 50/second
--hashlimit-burst 100 --hashlimit-mode srcip -j DROP
Eu mantenho o tamanho do Mesa de controle em uma olhada rápida. Se houver muitas conexões simultâneas, eu aumento o nf_conntrack_max, mas testo os efeitos com antecedência.
Gerenciamento, testes e prevenção de erros
Eu saio SSH antes de ativar a opção "negar entrada". Em seguida, testo em uma segunda sessão se o acesso permanece estável. Verifico cada nova regra com "ufw status verbose" ou "iptables -L -v". Isso me permite reconhecer os contadores de acertos e ver se os pacotes estão chegando na cadeia esperada. Faço backup dos arquivos do firewall antes de fazer qualquer alteração importante.
Para uma segurança abrangente, combino o firewall com etapas de fortalecimento do sistema. Isso inclui configurações seguras de SSH, gerenciamento de patches e serviços mínimos. Gosto de usar um guia prático como lista de verificação: Fortalecimento do servidor para Linux. Repito essas verificações regularmente e mantenho as janelas de manutenção fixas. Isso mantém meus servidores em forma confiável.
Testes avançados e observação
Eu verifico o impacto externo com Varreduras de portas de uma rede externa e verificar internamente os soquetes abertos. Eu monitoro os registros de perto no início para reconhecer conclusões falsas logo no início.
Soquetes abertos #
ss -lntup
# Visão geral do iptables compacto
sudo iptables -S
sudo iptables -L -v -n
UFW do #: status e registros detalhados
sudo ufw status verbose
journalctl -k | grep -i ufw
# Verificação externa (de outro host/rede)
nmap -Pn -p 22,80,443
Para mudanças de alto risco, estou planejando um Nível de fallback em. Trabalho no Screen/Tmux e, se necessário, defino uma reinicialização controlada por tempo se eu me bloquear. Após um teste bem-sucedido, cancelo novamente a ação de fallback.
# Exemplo: desativação automática como âncora de emergência (use com cuidado)
echo "ufw disable" | at now + 2 minutes
# Exclua novamente após um teste bem-sucedido: atrm
Comparação de provedores de hospedagem: Foco na integração do firewall
Para hospedagem, confio em Segurança próximo à plataforma. As políticas personalizadas, as implementações rápidas de regras e o bom monitoramento compensam. Nas comparações atuais, o webhoster.de impressiona com opções de firewall bem integradas e suporte rápido. Aqueles que preferem configurações de painel se beneficiam de instruções claras para Firewall do Plesk. A tabela a seguir categoriza os principais critérios.
| Fornecedor | Integração de firewall | Desempenho | Suporte | Colocação |
|---|---|---|---|---|
| webhoster.de | configurado individualmente. | Muito alto | superior | 1 |
| Provedor B | Padrão | alta | bom | 2 |
| Provedor C | Padrão | bom | Satisfatório | 3 |
Exemplos práticos: Do teste à regra de produção
Eu inicio cada conjunto de regras no Tela ou em uma segunda sessão SSH. Dessa forma, ainda posso me salvar no caso de um erro operacional. Somente quando um host de teste está funcionando corretamente é que aplico as regras na produção. As regras de caminho de retorno e um plano de reversão me dão segurança adicional. No final, eu documento as alterações de forma concisa no registro de alterações.
Eu uso blocos de construção recorrentes para servidores da Web: permitir SSH, liberar HTTP/S, vincular portas internas localmente, fazer logon, limitar ICMP, bloquear protocolos supérfluos. Em seguida, cuido das regras de espelhamento de IPv6 para que não haja lacunas. Sempre verifico as cadeias do Docker separadamente porque elas definem seus próprios caminhos. Por fim, valido o acesso por meio de verificações e monitoramento externos. Isso mantém a interface limpa e rastreável [1][2].
Resumo para administradores
Com clareza Regras e alguns comandos, eu protejo servidores da Web de forma confiável. Negar padrão de entrada, SSH primeiro, liberar HTTP/S - isso forma a base estável. Portas de banco de dados apenas localmente ou por meio de lista branca, registro ativo, observar IPv6, verificar cadeias do docker. O armazenamento persistente e os testes regulares evitam surpresas desagradáveis. Essa rotina mantém os serviços acessíveis e reduz significativamente os riscos.
Independentemente de eu usar o UFW ou o iptables diretamente, é fundamental ter uma política clara e econômica. Eu documento brevemente, verifico regularmente e mantenho as exceções em um nível mínimo. A restrição de saída impede conexões desnecessárias e limita os danos em caso de comprometimento. Com a prática de observar os registros, reconheço as anomalias mais rapidamente e reajo de forma adequada. Isso mantém o servidor Web resiliente e a superfície de ataque reduzida.
