Mitigação DDoS e Hardening de VPS Linux: Camada 4 e 7

A mitigação de ataques DDoS (Distributed Denial of Service) é uma das responsabilidades mais críticas para administradores de sistemas e desenvolvedores que operam infraestrutura na nuvem. Embora provedores de cloud ofereçam proteção na borda da rede, a segurança efetiva depende do hardening VPS no nível do sistema operacional. Um servidor mal configurado pode ser consumido rapidamente, não apenas por saturar a banda, mas por esgotar recursos locais como CPU, memória e conexões de sockets.

Este tutorial apresenta uma estratégia em camadas para proteger seu ambiente Linux contra ataques de camada 4 (Transporte) e camada 7 (Aplicação). Abordaremos desde a configuração rigorosa do firewall até a implementação de ferramentas modernas de detecção de intrusão, garantindo que sua infraestrutura permaneça estável sob pressão.

1. Fundamentos: Restrição de Acesso com UFW

O primeiro passo na mitigação DDoS é reduzir a superfície de ataque. Se uma porta não precisa ser acessível publicamente, ela deve estar fechada. O UFW (Uncomplicated Firewall) é a ferramenta padrão para gerenciar regras no Ubuntu e Debian, oferecendo uma sintaxe simples e eficaz.

Antes de configurar, verifique o status atual do firewall. Em seguida, defina as políticas padrão para bloquear tráfego não autorizado. Isso cria uma "lista negra" implícita para todo tráfego que não for explicitamente permitido.

sudo ufw status
sudo ufw default deny incoming
sudo ufw default allow outgoing

Agora, permita apenas os serviços essenciais. Para servidores web, é crucial permitir a entrada nas portas 80 (HTTP) e 443 (HTTPS). No entanto, o gerenciamento remoto deve ser restrito à porta SSH (geralmente 22), mas com uma ressalva importante: limite o acesso por IP se possível.

sudo ufw allow ssh
sudo ufw allow 'Nginx Full'
sudo ufw enable

Para servidores que exigem acesso SSH de múltiplas origens, utilize a regra de limitação (limit) para prevenir ataques de força bruta simples na porta 22. Isso permite apenas três conexões por minuto de um único endereço IP.

sudo ufw allow ssh limit

2. Blindagem do SSH com Chaves Criptográficas

O serviço SSH é o alvo mais comum para bots que escaneam a internet em busca de credenciais fracas. A autenticação por senha é vulnerável e consome recursos do servidor durante tentativas repetidas. A solução definitiva é desativar a autenticação por senha e utilizar SSH keys.

Gere um par de chaves na sua máquina local se ainda não o fez:

ssh-keygen -t ed25519 -C "[email protected]"

Transfira a chave pública para o servidor:

ssh-copy-id usuario@seu_servidor

Teste a conexão. Se conseguir acessar sem senha, edite o arquivo de configuração do SSH para desativar logins por senha e root.

Sudo nano /etc/ssh/sshd_config

Altere as seguintes diretrizes:

• PasswordAuthentication no: Impede login com senha.
• PermitRootLogin prohibit-password: Permite root apenas com chave (ou no para bloquear totalmente o root remoto).
• PubkeyAuthentication yes: Garante que a autenticação por chave esteja ativa.

Reinicie o serviço para aplicar as mudanças:

sudo systemctl restart sshd

3. Detecção e Bloqueio Automático com Fail2ban

O Fail2ban é um daemon que monitora arquivos de log do sistema (como /var/log/auth.log) e bloqueia IPs que exibem comportamentos maliciosos, como múltiplas tentativas de login falhas. Ele atua dinamicamente atualizando as regras do firewall.

Instale o pacote:

sudo apt install fail2ban

Copie o arquivo de configuração padrão para criar uma cópia editável, evitando que atualizações sobrescrevam suas configurações personalizadas:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Edite jail.local para ajustar os tempos de banimento e o tempo limite de falhas. Por exemplo, banir um IP por 1 hora após 5 tentativas falhas:

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 3600

Para proteção contra ataques na camada de aplicação, como tentativas de login no WordPress ou acessos repetidos a endpoints vulneráveis, crie jails personalizadas. O Fail2ban pode ser integrado ao UFW para bloquear efetivamente o tráfego indesejado.

sudo systemctl enable fail2ban
sudo systemctl start fail2ban

4. Inteligência Coletiva com CrowdSec

Enquanto o Fail2ban é local, o CrowdSec utiliza uma abordagem de inteligência coletiva. Quando um servidor é atacado, a informação é enviada para a nuvem do CrowdSec e imediatamente compartilhada com outros clientes na rede. Isso significa que se um atacante for banido em um servidor no Brasil, ele será automaticamente bloqueado no seu servidor se estiver na lista global.

Instale o agente seguindo as instruções oficiais da documentação do projeto. Após a instalação, ative os "scenarios" (cenários) relevantes para seu tipo de servidor.

sudo apt install crowdsec
sudo cscli scenarios install cs/nginx
sudo systemctl enable --now crowdsec

O CrowdSec funciona em conjunto com o firewall do sistema. Certifique-se de que a integração está ativa para que os IPs maliciosos detectados sejam bloqueados no nível do kernel.

sudo cscli metrics

Verifique o status dos bans e a saúde da inteligência coletiva. O CrowdSec oferece painéis web gratuitos para visualizar as ameaças em tempo real, fornecendo uma camada extra de visibilidade sobre tentativas de invasão.

5. Proteção na Camada 4: Limitação de Conexões com Nginx

Ataques de camada 4 muitas vezes envolvem a exaustão de conexões TCP simultâneas. Se você utiliza um servidor web como Nginx, pode configurar limites para limitar o número de conexões por IP e a taxa de requisições.

No arquivo de configuração do Nginx (/etc/nginx/nginx.conf), adicione as seguintes diretivas dentro do bloco http:

limit_conn_zone $binary_remote_addr zone=addr:10m;
limit_req_zone $binary_remote_addr zone=req:10m rate=10r/s;

Estas linhas definem zonas de memória para rastrear endereços IP. limit_conn limita o número total de conexões simultâneas, enquanto limit_req limita a taxa de requisições.

No bloco server ou location específico:

limit_conn addr 10;
limit_req zone=req burst=20 nodelay;

Isso permite que um usuário faça até 10 requisições por segundo, com uma "burst" (explosão) temporária de 20, sem causar atrasos significativos. Acima disso, o Nginx retornará 503 Service Temporarily Unavailable, protegendo os recursos do backend.

6. Mitigação na Camada 7: Proteção contra Scraping e Bots

Na camada 7, os ataques visam aplicar carga pesada em scripts PHP, APIs ou bancos de dados. Ferramentas como ModSecurity (se usar Apache) ou módulos de segurança do Nginx são essenciais.

Para Nginx, considere a instalação do módulo naxsi ou o uso de regras personalizadas para bloquear padrões suspeitos nas URLs. Além disso, mantenha suas aplicações atualizadas e remova painéis de administração expostos publicamente.

Outra prática recomendada é implementar rate limiting específico para endpoints sensíveis, como login e recuperação de senha:

location /wp-login.php {
    limit_req zone=req burst=5 nodelay;
    # Redirecionar ou bloquear se exceder o limite
}

Use Cloudflare ou serviços similares como proxy reverso. Eles absorvem a maior parte do tráfego malicioso antes que ele chegue ao seu servidor, atuando como um filtro de camada 7 altamente eficiente.

7. Monitoramento e Auditoria com Auditd

Após a mitigação ativa, é crucial monitorar o sistema para detectar invasões em andamento ou tentativas de escalada de privilégios. O auditd (Linux Audit Daemon) registra eventos do kernel que podem indicar atividades suspeitas.

Instale e inicie o serviço:

sudo apt install auditd audispd-plugins
sudo systemctl enable --now auditd

Configure regras para monitorar arquivos sensíveis, como o arquivo de senhas e o SSH. Por exemplo, monitore alterações no /etc/ssh/sshd_config:

sudo auditctl -w /etc/ssh/sshd_config -p wa -k ssh_config_change

Para tornar as regras persistentes, edite o arquivo /etc/audit/rules.d/audit.rules.

Use a ferramenta aureport para gerar relatórios de auditoria. Isso ajuda no monitoramento invasão, permitindo que você identifique quem tentou alterar configurações críticas ou acessar arquivos restritos.

aureport --summary
aureport -x --start today

8. Hardening Geral do Sistema

Além das ferramentas específicas, práticas gerais de hardening são fundamentais para a resiliência do servidor.

• Atualizações Constantes: Mantenha o kernel e os pacotes atualizados para corrigir vulnerabilidades conhecidas. Use unattended-upgrades no Debian/Ubuntu.
• Desabilitar Serviços Inúteis: Remova ou desative serviços que não estão em uso, como FTP, Telnet e SNMP, a menos que sejam estritamente necessários.
• Sysctl Tuning: Ajuste parâmetros do kernel para resistência contra ataques SYN flood. Edite /etc/sysctl.conf:

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 2048
net.ipv4.tcp_synack_retries = 2

O parâmetro tcp_syncookies ativa cookies SYN, uma técnica que permite ao servidor lidar com conexões incompletas durante ataques de negação de serviço, sem precisar manter estado para cada tentativa.

9. Resposta a Incidentes e Plano de Contingência

Nenhuma defesa é infalível. Ter um plano de resposta a incidentes é parte integrante da mitigação DDoS. Se o servidor estiver sob ataque:

1. Identifique: Use top, htop e ss -s para identificar picos de uso de CPU, memória ou conexões.
2. Isole: Se possível, desconecte o servidor da rede pública ou redirecione o tráfego para um serviço de mitigação DDoS dedicado.
3. Analyze: Verifique os logs do Fail2ban, CrowdSec e Nginx para identificar padrões de ataque.
4. Recupere: Após a contenção, revise as configurações de segurança e aplique patches pendentes antes de retornar à produção.

A manutenção contínua é vital. Revisar logs semanalmente e testar a eficácia das regras do firewall ajuda a garantir que sua estratégia de mitigação DDoS esteja sempre alinhada com as novas ameaças do cenário de segurança cibernética.

Conclusão

A proteção contra DDoS e invasões não é um produto único, mas um processo contínuo de camadas. Ao combinar UFW para filtragem básica, Fail2ban e CrowdSec para detecção reativa, configurações otimizadas de servidor web para controle de tráfego e auditd para monitoramento forense, você cria um ambiente robusto e difícil de comprometer.

Lembre-se: o objetivo não é apenas resistir ao ataque, mas minimizar seu impacto. Um servidor bem hardened continua operando mesmo quando parte de sua infraestrutura está sob pressão, garantindo a disponibilidade para usuários legítimos. Implemente estas etapas gradualmente, testando cada mudança em um ambiente de homologação antes de aplicar à produção.