Configuração de Firewall de Servidor: Protegendo o Servidor Contra DDoS e Bots

A configuração do firewall de servidor é o processo de deixar apenas as portas necessárias abertas e bloquear todo o acesso desnecessário; ele forma a primeira linha de defesa contra DDoS, força bruta e tráfego de bots maliciosos. Na prática, o objetivo é limitar o acesso SSH, abrir serviços web de forma controlada, aplicar limitação de taxa a solicitações suspeitas, monitorar logs e, sempre que possível, filtrar o tráfego antes que ele chegue ao servidor usando proteções de camada superior, como CDN/WAF.

Assim que você expõe um servidor web à internet, em questão de minutos pode ser alvo de varreduras de porta, tentativas de acesso SSH, bots de vulnerabilidade e agentes de usuário falsos. Especialmente em estruturas que executam WordPress, e-commerce, painéis de controle, APIs ou servidores de jogos, um firewall não é apenas uma escolha técnica, mas uma necessidade para garantir a continuidade. Neste guia, vamos estabelecer uma arquitetura de firewall passo a passo aplicável em servidores Linux; abordaremos juntos UFW, firewalld, nftables, Fail2ban, firewall de aplicação web e a abordagem de mitigação de DDoS.

Comecemos com um fato importante: um firewall local não pode, por si só, interromper ataques DDoS de grande volume. Quando um ataque de 20 Gbps, 80 Gbps ou mais atinge um data center ou a infraestrutura de rede, os pacotes podem preencher a largura de banda antes de chegar ao conjunto de regras do seu sistema operacional. Portanto, a abordagem correta é a segurança em camadas: proteção DDoS em nível de provedor, CDN/WAF, firewall do sistema operacional, limitação de taxa de aplicação e análise regular de logs devem trabalhar juntos. Para uma escolha de infraestrutura adequada, você pode se conectar à página de Soluções de servidor VPS e VDS Hostragons e, para opções de hospedagem web seguras, consulte a página de Pacotes de hosting web Hostragons.

Para Que Serve o Firewall de Servidor?

Um firewall de servidor é uma camada de segurança que filtra o tráfego da rede com base em IP de origem, IP de destino, porta, protocolo, estado da conexão e, em alguns casos, características dos pacotes. Com um exemplo simples: as portas 80 e 443 devem estar abertas para seu site, mas a porta 3306, que é a porta do banco de dados, não deve estar acessível na internet. Em vez de permitir que qualquer um tente a porta 22 para SSH, é mais seguro limitar o acesso apenas ao seu endereço IP do escritório.

O objetivo principal de um firewall não é eliminar magicamente todos os ataques. O verdadeiro objetivo é reduzir a superfície de ataque. Quanto menor a superfície de ataque, menos opções o invasor terá para tentar. Por exemplo, em um novo servidor Linux, SSH, painel web, serviço de e-mail, banco de dados, agente de monitoramento e serviços de teste podem estar todos abertos ao mesmo tempo. Cada um deles representa um risco separado. Um firewall bem configurado opera sob o princípio de "negar por padrão, permitir o que é necessário".

Entendendo DDoS e Tráfego de Bots

Por que os Ataques DDoS são Diferentes?

DDoS, ou ataque de negação de serviço distribuído, visa tornar o serviço alvo inacessível por meio de um tráfego intenso proveniente de muitas fontes. O ataque pode preencher a largura de banda, consumir os recursos da CPU e RAM do servidor, ou acionar operações dispendiosas na camada de aplicação. Por exemplo, um pequeno servidor de aplicação que recebe 50.000 solicitações HTTP por segundo pode não conseguir responder, mesmo que a conexão da rede não esteja saturada, devido ao PHP-FPM, Node.js ou ao pool de conexões do banco de dados.

Bots São Sempre Maléficos?

Não. Googlebot, Bingbot e alguns bots de monitoramento são úteis. No entanto, bots maliciosos realizam varredura de painéis administrativos, pesquisa de diretórios abertos, spam de formulários, cópia de conteúdo, exploração de XML-RPC, criação de registros falsos e tentativas de login. Portanto, o objetivo da gestão de bots não é bloquear todos os bots, mas diferenciar com base no comportamento. Alta taxa de erro, muitas solicitações em um curto espaço de tempo, cabeçalhos que não se comportam como um navegador real e padrões de URL suspeitos são sinais importantes.

Lista de Verificação Antes de Começar a Configuração

Ao escrever uma regra de firewall em um servidor ao vivo, o maior risco é se trancar fora do servidor. Portanto, é necessário fazer uma breve preparação antes de fazer alterações. A lista de verificação abaixo é uma abordagem segura comumente usada em ambientes de produção.

• Não feche a sessão SSH ativa; teste com um segundo terminal.
• Assegure-se de que seu provedor de servidor oferece acesso ao console, VNC ou recuperação.
• Liste as portas abertas existentes: examine a saída de ss -tulpn ou netstat -tulpn.
• Anote quais portas estão sendo usadas pelos serviços web, e-mail, DNS, banco de dados, painel e monitoramento.
• Se estiver usando IPv6, planeje também as regras de firewall para IPv6.
• Primeiro aplique regras de permissão (allow), em seguida regras de bloqueio (deny).
• Assegure-se de que o conjunto de regras seja persistente; ele não deve ser perdido após a reinicialização do servidor.

Por exemplo, em um servidor típico que apenas hospeda um site, as portas que geralmente precisam estar abertas são 80, 443 e uma porta SSH limitada. Se o servidor de e-mail não estiver em execução, não há necessidade de abrir portas como 25, 465, 587 ou 993. Se o banco de dados for utilizado apenas internamente, as portas 3306 ou 5432 devem permanecer fechadas para o mundo exterior.

Qual Ferramenta de Firewall Você Deve Escolher?

No mundo Linux, existem várias ferramentas, e a maioria gerencia a mesma infraestrutura de filtragem de núcleo com diferentes facilidades de uso. Para iniciantes, o UFW é simples e rápido. Em sistemas corporativos ou baseados em Red Hat, o firewalld é comum. Para cenários mais avançados, o nftables oferece uma estrutura moderna e flexível. A tabela abaixo facilita a escolha.

Passo a Passo para a Configuração do Firewall de Servidor

1. Identifique Portas e Serviços Abertos

O primeiro passo é ver o que está aberto. O comando ss -tulpn em um servidor Linux mostra quais serviços estão ouvindo em quais portas. Por exemplo, se o nginx está ouvindo em 0.0.0.0:80 e 0.0.0.0:443, isso significa que o tráfego web está sendo aceito de todas as interfaces. Se o MariaDB está ouvindo em 0.0.0.0:3306, isso geralmente é arriscado; na maioria dos sites, o banco de dados deve funcionar em 127.0.0.1.

A regra prática aqui é: nenhum serviço que não precisa ser acessado pela internet deve ouvir em 0.0.0.0. É mais saudável corrigir a configuração do serviço primeiro e depois bloquear com o firewall. Porque mesmo que o firewall esteja desativado, o serviço não deve estar exposto ao mundo exterior.

2. Defina a Política Padrão como Fechada

Em conjuntos de regras seguros, o tráfego de entrada padrão é rejeitado, enquanto o tráfego de saída é liberado conforme necessário. Essa abordagem evita que serviços recém-instalados sejam inadvertidamente expostos à internet. Em um servidor Ubuntu usando UFW, a lógica é a seguinte: primeiro permite-se o SSH, depois abrem-se as portas 80 e 443, em seguida, a política de entrada padrão é definida como deny e o firewall é ativado.

Fluxo de exemplo: permita o acesso SSH ao seu endereço IP de administrador, abra o tráfego HTTP e HTTPS, feche portas desnecessárias e, por fim, ative o firewall. Uma das falhas mais comuns é abrir o firewall sem permitir o acesso SSH primeiro, especialmente em servidores remotos.

3. Limite o Acesso SSH

SSH é um dos serviços mais visados pelos invasores. Um servidor com a porta padrão 22 aberta pode ver centenas ou milhares de tentativas de senha por dia. A abordagem mais segura é restringir o acesso SSH a determinados endereços IP. Se você estiver usando um IP fixo, permita apenas o acesso do seu escritório ou do endereço IP da VPN. Se não houver um IP fixo, pelo menos use autenticação baseada em chave e desative a entrada por senha.

• Desative o login SSH direto como root.
• Use chave SSH em vez de senha.
• Limite usuários com AllowUsers ou AllowGroups.
• Use Fail2ban para bloquear automaticamente tentativas falhas.
• Se você estiver usando um painel, restrinja também a porta do painel por IP.

Mudar a porta por si só não garante segurança, mas pode reduzir o ruído de bots automáticos. No entanto, a verdadeira proteção vem da limitação de IP, autenticação forte e monitoramento de logs.

4. Abra as Portas Web de Forma Controlada

Para a maioria dos servidores que publicam sites, as portas 80 e 443 são necessárias. Contudo, hoje em dia, a porta 443 (HTTPS) deve ser a principal porta de tráfego, enquanto a 80 deve ser utilizada apenas para redirecionamento para HTTPS. Sites sem certificado SSL afetam negativamente tanto a confiança do usuário quanto o desempenho em SEO. Neste ponto, o link Certificados SSL Hostragons é uma oportunidade natural de link interno para direcionar o leitor à configuração segura do HTTPS.

Ao abrir portas web, preste atenção ao comportamento do IP real. Se você estiver usando CDN ou um proxy reverso, é mais seguro permitir o tráfego nas portas 80 e 443 apenas a partir dos intervalos de IP da CDN, em vez de abri-los para a internet inteira. Assim, mesmo que o invasor conheça o endereço IP real do servidor, não poderá acessar diretamente o serviço web.

5. Feche o Banco de Dados e Serviços Internos para a Internet

Serviços como MySQL, MariaDB, PostgreSQL, Redis, Elasticsearch, MongoDB e similares geram um risco sério se expostos à internet. A falta de autenticação no Redis, acesso não autorizado a índices no Elasticsearch ou portas de gerenciamento abertas no MongoDB levaram a vazamentos de dados significativos no passado. Esses serviços devem, se possível, ouvir apenas em localhost ou em uma rede privada.

Por exemplo, para um site WordPress que opera no mesmo servidor, é suficiente que o banco de dados funcione em 127.0.0.1. Se você estiver usando um servidor de aplicativo e um servidor de banco de dados separados, permita apenas o endereço IP privado do servidor de aplicativo. Deixar o acesso 3306 ou 5432 aberto para a internet é um erro conhecido que bots exploram continuamente.

6. Use Fail2ban para Bloquear Tentativas de Força Bruta

O Fail2ban monitora arquivos de log para detectar tentativas de login falhadas repetidas e bloqueia temporariamente o endereço IP correspondente. Jails podem ser definidas para SSH, nginx, Apache, Postfix, Dovecot, login do WordPress e alguns serviços de painel. Por exemplo, bloquear um endereço IP que faz 5 tentativas de SSH falhadas em 10 minutos por 1 hora é um começo simples, mas eficaz.

Ao usar regras excessivamente agressivas na configuração do Fail2ban, tenha cuidado. Um padrão de log incorreto pode bloquear usuários legítimos. Portanto, no início, mantenha o valor de bantime razoável, monitore os logs e, em seguida, implemente um endurecimento gradual.

7. Adicione Limitação de Taxa e Limites de Conexão

A limitação de taxa em nível de sistema operacional pode ajudar contra tráfego DDoS e de bots. Por exemplo, se um número excessivo de novas conexões estiver vindo do mesmo endereço IP por segundo, um limite pode ser aplicado. No lado do servidor web, os módulos limit_req e limit_conn para nginx, ou mod_evasive para Apache, podem ser usados. No lado da aplicação, limites de taxa também devem ser aplicados em login, busca, carrinho, pagamento e endpoints de API.

Um exemplo concreto: em uma página de login, 10 tentativas por minuto para um único endereço IP pode ser razoável. Em um endpoint de busca, 2-5 solicitações por segundo podem ser suficientes. Se você estiver oferecendo uma API, limite de token baseado em usuário, limite de IP e análise de comportamento devem ser projetados juntos. Assim, um invasor não pode simplesmente alterar o IP para superar todos os limites.

Exemplo de Cenário de Configuração Segura com UFW

Em um servidor web baseado em Ubuntu ou Debian, um cenário simples de início seguro pode ser configurado da seguinte forma: primeiro, verifique os serviços existentes, permita o acesso SSH a partir do seu endereço IP de administrador, abra as portas 80 e 443, rejeite o tráfego de entrada por padrão e verifique o estado do UFW. Se o seu acesso SSH não puder ser limitado a um IP fixo, você pode temporariamente permitir o SSH de todos os IPs e, em seguida, mudar para uma solução de VPN ou IP fixo.

O conjunto de decisões de exemplo poderia ser o seguinte: 203.0.113.10 como o endereço IP do administrador. O SSH deve vir apenas desse IP. O tráfego web nas portas 80 e 443 deve permanecer aberto para todos. O banco de dados, Redis, painel e portas de teste devem estar fechados para o exterior. Essa configuração é um bom começo para muitos sites corporativos pequenos e de médio porte. Para garantir o direcionamento correto no lado do domínio e DNS, você pode se conectar à página de Consulta de domínio e registro Hostragons.

Zona de Lógica com firewalld

firewalld é amplamente utilizado em servidores baseados em AlmaLinux, Rocky Linux e RHEL. O firewalld trabalha com o conceito de zonas. A zona pública é para interfaces abertas à internet, a zona confiável é para redes privadas confiáveis, e a zona drop é usada para descartar silenciosamente o tráfego indesejado. O ponto mais importante é a diferença entre regras runtime e permanent. A regra runtime é aplicada imediatamente, mas pode ser perdida na reinicialização; a regra permanent é duradoura, mas pode exigir recarregamento.

Ao usar firewalld em ambientes corporativos, definições baseadas em serviços facilitam as coisas. Por exemplo, você pode abrir os serviços http e https na zona pública, enquanto garante que o serviço ssh seja acessível apenas a partir de certos endereços IP de origem. Se a rede de gerenciamento, a rede de backup e o tráfego de usuários estiverem em interfaces separadas, a estrutura de zonas melhora a segurança e a legibilidade.

CDN, WAF e Proteção DDoS em Nível de Provedor

Um firewall local decide após os pacotes chegarem ao servidor. Em ataques DDoS grandes, o objetivo é filtrar o tráfego antes que ele chegue ao servidor. Portanto, CDN, WAF e proteção DDoS em nível de provedor são críticos. O CDN fornece conteúdos estáticos em locais de borda, o WAF filtra solicitações maliciosas na camada de aplicação, e a proteção do provedor absorve ou limpa ataques volumosos em nível de rede.

No modelo ideal, seus registros DNS passam pelo CDN, o endereço IP real do servidor é ocultado e seu firewall de servidor aceita apenas 80 e 443 de intervalos de IP da CDN. As portas de gerenciamento devem ser acessíveis através de VPN ou IP fixo. Esse modelo reduz a probabilidade de ataques diretos ao IP e permite que você elimine o tráfego de bots antes que ele chegue à aplicação. Para conteúdos que abordam segurança e desempenho web, pode-se usar o link Guias de aceleração e segurança de site.

Medidas de Camada de Aplicação Contra Bots

Bloquear bots não se resume apenas a uma lista de IPs banidos. Bots modernos podem usar proxies, redes móveis, IPs de data centers e agentes de usuário variáveis. Portanto, uma abordagem baseada em comportamento é necessária. Muitas tentativas de login em um curto período de tempo a partir do mesmo IP, raspagem contínua gerando 404, e padrões de clique diferentes do usuário normal, assim como cabeçalhos suspeitos devem ser analisados.

• Use limitação de taxa em formulários de login e registro.
• Desative ou limite o acesso XML-RPC desnecessário.
• Proteja o painel de administração com URL diferente, limitação de IP e autenticação multifatorial.
• Filtre padrões de user-agent e referer suspeitos em nível de WAF.
• Utilize CAPTCHA ou mecanismos invisíveis de verificação bot de forma equilibrada em formulários.
• Adicione controles de chave, assinatura, cota e timestamp para endpoints de API.

Na gestão de bots, é importante não comprometer a experiência do usuário. CAPTCHA excessivo, bloqueios agressivos ou listas de bloqueio de países incorretas podem prejudicar seus clientes reais. Portanto, medir, testar e endurecer gradualmente é o método mais saudável.

Monitoramento de Logs e Regras de Alarme

É um erro comum pensar que a configuração está concluída. O firewall é um sistema vivo e deve ser monitorado regularmente. Tentativas de SSH em auth.log ou secure, alta concentração de solicitações anormais nos logs de acesso do nginx, aumento de 404 e 500 nos logs de erro, e monitoramento de métricas do sistema como uso de CPU e número de conexões devem ser realizados. Um simples alarme pode economizar minutos quando um ataque começa.

Os valores de limite de exemplo para começar podem ser: mais de 100 solicitações 404 do mesmo IP em 5 minutos, mais de 20 tentativas na página de login em 1 minuto, uso de CPU acima de 90% por 10 minutos, e o número de conexões triplicando o normal. Esses limites variam de site para site; o importante é conhecer seu perfil de tráfego normal.

Erros Comuns e Como Evitá-los

• Ativar o firewall sem permitir acesso SSH: Pode resultar na perda de acesso ao servidor remoto. Sempre teste com uma segunda sessão.
• Esquecer do IPv6: Os serviços podem ficar abertos pelo IPv6 enquanto o IPv4 está fechado.
• Deixar o banco de dados exposto à internet: Portas como 3306, 5432, 6379 e 9200 são constantemente escaneadas por bots.
• Usar CDN e deixar o IP real exposto: Um invasor pode contornar a CDN e atacar diretamente o servidor.
• Alterar regras sem documentá-las: Em caso de emergência, fica difícil entender a função de cada regra.
• Não ter um plano de acesso de backup: Se não houver acesso ao console devido a uma regra incorreta, o tempo de inatividade se estende.

Exemplo de Política de Firewall Prática

Uma política resumida que pode ser aplicada a um pequeno site corporativo pode ser: o tráfego de entrada é fechado por padrão; 443 está aberto para todos os visitantes; 80 está aberto apenas para redirecionamento HTTPS; o SSH é acessível apenas através de VPN ou do IP fixo do administrador; o banco de dados está em localhost ou em uma rede privada; se estiver usando CDN, as portas 80 e 443 devem ser permitidas apenas para intervalos de IP da CDN; Fail2ban monitora tentativas de login SSH e web; logs diários são enviados para uma ferramenta de monitoramento central.

Para um site de e-commerce de médio porte, além disso, os IPs de callback de pagamento são permitidos na lista, o painel de administração é colocado atrás de uma VPN, limites de usuário são aplicados à API, regras de SQL injection e XSS são ativadas no WAF, e um plano de filtragem temporário baseado em país ou ASN é elaborado. É importante que este plano esteja por escrito; implementar um procedimento predefinido em vez de tomar decisões sob pressão durante um ataque reduz o tempo de inatividade.

Testando: As Regras Estão Realmente Funcionando?

Após a configuração do firewall, testes devem ser realizados. Realize uma varredura de portas abertas de uma rede diferente, verifique se o acesso SSH funciona apenas a partir do IP permitido, verifique se o site é acessível via HTTPS, e assegure-se de que a porta do banco de dados está fechada externamente. Se estiver usando CDN, valide que uma solicitação HTTP direta para o IP real do servidor seja bloqueada.

Durante o processo de teste, evite varreduras agressivas que possam danificar sistemas de produção. O objetivo é garantir uma validação segura. Além disso, após cada alteração, exporte ou anote o conjunto de regras. Isso facilita o retorno à configuração saudável anterior em caso de problemas.

Plano de Manutenção e Atualização

A segurança do servidor não é uma configuração única, mas sim um processo contínuo de manutenção. Quando um novo serviço é adicionado, a necessidade de portas deve ser reavaliada, permissões devem ser removidas quando um serviço antigo é removido, atualizações de segurança devem ser aplicadas pontualmente e logs devem ser verificados periodicamente. Realizar uma auditoria de portas abertas pelo menos uma vez por mês e revisar o conjunto de regras do firewall a cada três meses é um bom começo prático.

Além disso, um plano de backup é parte integrante da estratégia de segurança. Um ataque DDoS pode interromper o acesso, mas ransomware ou acesso não autorizado pode causar perda de dados. Hospedagem segura, SSL, gerenciamento de domínio e backup devem ser considerados em conjunto. Nesse contexto, os links Dicas para escolher hosting seguro e como fazer a instalação do certificado SSL são conexões naturais de continuidade.

Conclusão

A configuração do firewall do servidor não torna o servidor completamente invisível contra DDoS e bots; mas reduz significativamente a superfície de ataque, diminui o risco de acesso não autorizado e permite que você responda a eventos de forma mais controlada. O resultado mais eficaz é alcançado através da implementação conjunta de proteção DDoS em nível de provedor, CDN/WAF, política rigorosa de portas, restrição de SSH, Fail2ban, limitação de taxa e monitoramento regular de logs.

Se você está lançando um novo projeto, planejar a política do firewall desde o início é mais fácil do que corrigir depois. Ao avaliar servidores, hospedagem, domínio e infraestrutura SSL na Hostragons, você pode considerar suas necessidades de segurança para criar um ambiente web mais robusto. Se precisar, comece com uma pequena lista de verificação: feche portas abertas, limite o SSH, torne o HTTPS obrigatório e monitore os logs.

Perguntas Frequentes

O firewall do servidor bloqueia totalmente ataques DDoS?

Não. Um firewall local pode reduzir pequenos ataques e alguns ataques em nível de protocolo, mas para grandes ataques DDoS, é necessário usar proteção DDoS em nível de provedor, CDN e WAF.

Quais portas devem estar abertas em um servidor web?

Em um servidor web típico, as portas 80 e 443 permanecem abertas. A porta SSH deve ser permitida apenas para endereços IP de administradores. As portas de banco de dados e serviços internos devem ser mantidas fechadas para a internet.

Devo usar UFW ou firewalld?

Para Ubuntu e Debian, o UFW oferece um início mais fácil. Em sistemas baseados em AlmaLinux, Rocky Linux e RHEL, o firewalld é comum. Para cenários avançados e específicos, o nftables pode ser preferido.

Posso parar o tráfego de bots apenas bloqueando IPs?

Geralmente não. Bots modernos usam diferentes IPs e proxies. Além do bloqueio de IP, devem ser utilizadas limitação de taxa, regras de WAF, análise de comportamento, CAPTCHA e cotas baseadas em aplicação.

Qual é o maior risco ao configurar um firewall?

O maior risco é perder o acesso SSH devido a uma regra incorreta. Portanto, o acesso SSH deve ser definido primeiro, testado com uma segunda sessão e deve estar disponível acesso ao console do provedor.