Saltar para o conteúdo 
Firewall iptables e UFW controlam quais conexões um servidor web aceita e quais eu bloqueio - isso determina a superfície de ataque e as falhas. Neste artigo prático, mostro regras claras, predefinições seguras e comandos testados para SSH, HTTP(S), bases de dados, registo, IPv6 e Docker - diretamente aplicáveis em anfitriões produtivos.
Pontos centrais
Os seguintes pontos-chave dão-me uma orientação rápida antes de começar a configuração.
- Restritivo Início: Predefinição de recusa de entrada, aberto especificamente
- SSH Permitir primeiro: não arriscar o acesso
- UFW como interface: sintaxe simples, iptables em segundo plano
- Registo ativar: Verificar regras, reconhecer ataques
- Persistência garantir: Manter regras sobre reinícios
Noções básicas: iptables e UFW em resumo
Confio em iptablesquando preciso de um controlo fino sobre pacotes, cadeias e correspondências. Eu 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 netfilter do Linux sem me perder nos detalhes. Para servidores web, isso significa: eu construo 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.
Ambas as ferramentas se complementam e eu decido qual delas se adequa à situação. O UFW ganha com uma legibilidade limpa, especialmente no Ubuntu e no Debian [3]. O iptables dá-me opções alargadas, por exemplo para NAT, interfaces específicas e correspondências 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, pode encontrar uma introdução clara aqui: Firewall como escudo protetor.
Iniciar configuração: Definir políticas predefinidas de forma segura
Começo por Predefinição-Policies: Bloquear a entrada, permitir a saída. É assim que eu evito que novos serviços sejam acessados de forma não intencional. Eu sempre permito o loopback para que os processos internos funcionem de forma estável. Aceito as ligações existentes para evitar cancelamentos. Esta sequência minimiza os erros ao ativar a firewall [2][5].
Utilizo o UFW para definir a base com apenas alguns comandos. Depois, verifico o estado em pormenor para detetar imediatamente os erros de digitação. Para hosts particularmente sensíveis, também restrinjo as portas de saída. Isto reduz o risco de fugas de dados se um serviço tiver sido comprometido. Eu uso os seguintes comandos com frequência:
# UFW: Regras predefinidas
sudo ufw default deny incoming (negar entrada)
sudo ufw default allow outgoing
# Política de saída alternativa mais rigorosa
sudo ufw default deny outgoing
sudo ufw permite saída 53
sudo ufw allow out 80
sudo ufw permitir saída 443
# Verificar estado
sudo ufw status verbose
Filtragem com estado: Estados e sequência
Um fluxo de parcelas limpas é igual a A Conntrack declara. Aceito primeiro as ligações estabelecidas, descarto os pacotes inválidos mais cedo e deixo o loopback aberto. Isso reduz a carga e evita efeitos colaterais devido a quedas tardias. Para o 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 pacotes inválidos mais cedo
iptables -A INPUT -m conntrack --ctstate INVALID -j DROP
Com o UFW, ESTABLISHED/RELATED já são tidos em conta internamente. Também presto atenção ao facto de preferir DROP (silencioso) ou REJEITAR (ativo, failover mais rápido). Para redes internas prefiro REJECT, na rede pública normalmente DROP.
Regras essenciais para servidores Web: SSH, HTTP e HTTPS
Eu troco SSH primeiro, caso contrário, bloqueio-me facilmente. De seguida, permito HTTP e HTTPS para que o servidor Web esteja acessível. Só defino as portas de que realmente preciso. Mais tarde, opcionalmente, adiciono a limitação de taxa ou o Fail2ban para restringir as tentativas brutais de login. Verifico todas as alterações imediatamente com os comandos status ou list.
Eu mantenho os comandos para isso simples. O UFW oferece aliases de fala para portas web, o que aumenta a legibilidade. Com o iptables, posso definir portas e protocolos precisos. Eu salvo as regras do iptables depois para que elas sobrevivam à reinicialização. Aqui estão os passos mínimos:
# 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
Para além da libertação, atenuo os ataques com Limitação da taxa ou listas brancas. O UFW fornece uma proteção simples:
# Limitação da taxa SSH (UFW)
sudo ufw limit 22/tcp comentário "Limite de taxa SSH"
Eu defino limites mais finos com o iptables. Isto impede a adivinhação maciça de palavras-passe sem excluir administradores legítimos:
# SSH: Limitar 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, só permito SSH a partir 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 excepções e verifico-as regularmente.
Proteger as bases de dados e restringir as fontes de IP
Nunca abro portas de bases de dados globalmente, mas apenas local ou para endereços IP de origem definidos. Isso impede que os scanners encontrem portas MySQL, PostgreSQL ou MongoDB abertas. Para aplicações locais, 127.0.0.1 é suficiente como alvo; eu controlo o acesso externo do administrador estritamente através do IP. Eu documento as alterações brevemente, por exemplo, no wiki do servidor. Isto poupa-me tempo durante as auditorias.
Utilizo frequentemente os seguintes exemplos em projectos. Verifico previamente a correção de cada IP permitido. O UFW permite uma notação "de-para" limpa, o iptables implementa a mesma lógica tecnicamente. Eu uso regras de permissão adicionais para janelas de manutenção temporárias e as excluo depois. Isso mantém a interface pequena:
# Apenas 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 simples do registo, interfaces e IPv6
Eu troco Registo para verificar regras e reconhecer tráfego conspícuo. O nível "on" no UFW é suficiente para a maioria dos hosts, apenas utilizo níveis mais elevados seletivamente. Analiso os registos com journalctl, fail2ban ou ferramentas SIEM. Isto permite-me reconhecer padrões de scans ou tentativas de força bruta. Em caso de anomalias, ajusto as regras de imediato [2].
Costumo associar as regras a um determinado Interfacecomo eth0 em redes públicas. Isto evita que as redes internas sejam afectadas 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 dual-stack.
ICMP e ICMPv6: Acessibilidade sem lacunas
Deixo necessário ICMP-para que a descoberta do MTU do caminho, os tempos limite e o diagnóstico funcionem. O ICMP não é um inimigo, mas sim o núcleo do protocolo IP. Limito apenas os ecos excessivos.
# IPv4: Limitar o eco, permitir tipos ICMP importantes
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). Permito os tipos de núcleo e limito os pedidos 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
Utilizar corretamente a restrição de saída e o NAT/masquerading
Limito o tráfego de saída quando Perfil de risco e conformidade. Permito o DNS e o HTTPS e bloqueio tudo o resto, exceto os alvos definidos. Isto reduz os dados exfiltrados se um serviço for desviado. Crio excepções definidas para aplicações que requerem actualizações ou APIs. Documento estas excepções de forma clara e verifico-as regularmente.
Para configurações de roteamento, eu 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 conetividade e as latências. Para sistemas de produção, planeio uma janela de manutenção e faço uma cópia de segurança da configuração. Isto permite-me manter os caminhos da rede rastreáveis [7].
Pormenores 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 correio eletrónico, adiciono 25/tcp e 587/tcp. Não resolvo excepções baseadas no domínio ao nível do pacote, mas através de proxies ou da lógica da aplicação.
# UFW: serviços típicos do sistema
sudo ufw allow out 123/udp # NTP
sudo ufw allow out 25/tcp # SMTP - apenas se for um servidor de correio eletrónico
sudo ufw allow out 587/tcp # Submissão - apenas se necessário
# iptables: específico Permitir
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 o seu próprio iptables-regras que podem influenciar a minha política. Portanto, eu verifico as cadeias NAT e FORWARD após cada composição ou início de daemon. Eu deliberadamente libero portas expostas e evito "-p 0.0.0.0:PORT". Em vez disso, eu as vinculo ao IP de gerenciamento ou ao proxy reverso. Isso mantém o vetor de ataque menor e mais visível [1].
Mantenho as firewalls do anfitrião activas apesar do Docker. Também controlo os grupos de segurança ao nível da infraestrutura, se disponível. Em caso de conflitos entre o UFW e o Docker, utilizo soluções alternativas documentadas ou defino regras no DOCKER-USER. É importante ter responsabilidades claras: o anfitrião bloqueia sempre, os contentores só abrem explicitamente. Essa ordem evita liberações inconscientes.
# DOCKER-USER: aplicar a política de anfitrião 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
Definições finas do UFW: Sequência, perfis e tráfego encaminhado
Quando a precisão é importante, utilizo "inserir", "numerado" e perfis de aplicações. É assim que mantenho a sequência de regras limpa e utilizo definições de serviço testadas.
# Sequência de controlo
sudo ufw insert 1 deny in from 198.51.100.0/24
# Vista numerada e eliminação direcionada
sudo ufw status numbered
sudo ufw delete 3
# Perfis de aplicações (por exemplo, Nginx Full)
sudo ufw app list
sudo ufw info da aplicação "Nginx Full"
sudo ufw allow "Nginx Full"
# Bloquear tráfego encaminhado por predefinição (reencaminhamento)
sudo ufw default deny routed
Armazeno excepções mais complexas em antes.regras respectivamente após.regras. Aí posso colocar o ajuste fino do ICMP ou o NAT com precisão sem perder a legibilidade das regras padrão.
Regras persistentes: Guardar e restaurar
As regras da UFW são persistente e sobrevivem automaticamente a 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. Eu uso iptables-save/restore ou netfilter-persistent para isso. Sem esses passos, eu perco as alterações após uma reinicialização [5].
Testo a persistência de forma sistemática: programo um reinício e verifico o estado. Se os contadores e as cadeias estiverem corretos, a configuração é sólida. Se faltarem regras, corrijo o caminho de carregamento no contexto do init ou do systemd. Esta rotina evita surpresas durante a manutenção. A documentação e o backup dos ficheiros 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 afinação do kernel
Quando a carga é elevada, reduzo o número de controlos e utilizo Limites de taxas. Para listas de blocos grandes, trabalho com o ipset para reduzir os tempos de consulta. Também utilizo 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
Mantenho o tamanho do Mesa de comando num relance. Se houver muitas ligações simultâneas, aumento o nf_conntrack_max, mas testo previamente os efeitos.
Gestão, testes e prevenção de erros
Vou-me embora SSH antes de ativar "negar entrada". De seguida, testo numa segunda sessão se o acesso se mantém estável. Verifico cada nova regra com "ufw status verbose" ou "iptables -L -v". Isto permite-me reconhecer os contadores de acertos e ver se os pacotes estão a aterrar na cadeia esperada. Faço cópias de segurança dos ficheiros da firewall antes de fazer grandes alterações.
Para uma segurança abrangente, combino a firewall com passos de reforço do sistema. Estas incluem definições SSH seguras, gestão de patches e serviços mínimos. Gosto de utilizar um guia prático como lista de controlo: Fortalecimento do servidor para Linux. Repito estas verificações regularmente e cumpro as janelas de manutenção fixadas. Desta forma, os meus servidores mantêm-se fiáveis e em forma.
Testes avançados e observação
Verifico o impacto externo com Varreduras de portas de uma rede externa e verificar internamente os sockets abertos. No início, monitorizo os registos de perto para reconhecer conclusões falsas logo no início.
Tomadas abertas #
ss -lntup
# Visão geral do iptables compacto
sudo iptables -S
sudo iptables -L -v -n
# UFW: estado e registos detalhados
sudo ufw status verbose
journalctl -k | grep -i ufw
# Verificação externa (de outro host/rede)
nmap -Pn -p 22,80,443
Para as alterações de alto risco, estou a planear uma Nível de recurso em. Trabalho no Screen/Tmux e, se necessário, defino uma reposição controlada por tempo se me bloquear. Após um teste bem sucedido, cancelo novamente a ação de recurso.
# Exemplo: desativação automática como âncora de emergência (usar com cuidado)
echo "ufw disable" | at now + 2 minutes
# Apagar novamente após um teste bem sucedido: atrm
Comparação de fornecedores de alojamento: Foco na integração da firewall
Para o alojamento, confio em Segurança perto da plataforma. As políticas personalizadas, a rápida implementação de regras e a boa monitorização compensam. Nas comparações actuais, o webhoster.de impressiona pelas opções de firewall perfeitamente integradas e pelo suporte rápido. Aqueles que preferem configurações de painel beneficiam de instruções claras para Firewall do Plesk. O quadro seguinte categoriza os principais critérios.
| Fornecedor | Integração de firewall | Desempenho | Suporte | Colocação |
|---|---|---|---|---|
| webhoster.de | configuração individual. | Muito elevado | topo | 1 |
| Fornecedor B | Padrão | elevado | bom | 2 |
| Fornecedor C | Padrão | bom | Satisfatório | 3 |
Exemplos práticos: Do teste à regra de produção
Eu inicio cada conjunto de regras no Ecrã ou numa segunda sessão SSH. Desta forma, ainda me posso salvar no caso de um erro de funcionamento. Só quando um anfitrião de teste está a funcionar corretamente é que aplico regras na produção. As regras do caminho de retorno e um plano de reversão dão-me segurança adicional. No final, documento as alterações de forma concisa no registo de alterações.
Utilizo blocos de construção recorrentes para servidores Web: permitir SSH, libertar HTTP/S, ligar portas internas localmente, iniciar sessão, limitar ICMP, bloquear protocolos supérfluos. Em seguida, cuido das regras de espelhamento IPv6 para que não haja lacunas. Verifico sempre as cadeias Docker separadamente porque definem os seus próprios caminhos. Por fim, valido o acesso através de verificações e monitorização externas. Isto mantém a interface limpa e rastreável [1][2].
Resumo para administradores
Com uma clara Regras e alguns comandos, eu protejo servidores web de forma fiá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 via whitelist, logging ativo, observar IPv6, verificar cadeias docker. O armazenamento persistente e os testes regulares evitam surpresas desagradáveis. Esta rotina mantém os serviços acessíveis e reduz significativamente os riscos.
Quer utilize diretamente o UFW ou o iptables, uma política clara e económica é crucial. Eu documento brevemente, verifico regularmente e mantenho as excepções a um nível mínimo. A restrição de saída impede as ligações desnecessárias e limita os danos em caso de compromisso. Com um olhar prático sobre os registos, reconheço as anomalias mais rapidamente e reajo de forma adequada. Isto mantém o servidor Web resiliente e a superfície de ataque reduzida.
