A maioria dos planos de hospedagem promete proteção contra DDoS. Isso geralmente significa filtrar grandes inundações de pacotes inúteis (camadas 3 e 4) antes que cheguem ao seu servidor. Não impede mil navegadores "de verdade" carregando ao mesmo tempo a sua página mais lenta. Esses ataques na camada de aplicação (camada 7) parecem visitantes comuns, e você mesmo precisa lidar com eles. Veja o que é proteção contra DDoS para o contexto.
Conheça a diferença
- Inundações volumétricas: enchem o canal da rede. O host ou o provedor upstream filtra essas.
- Ataques de protocolo: esgotam as tabelas de conexão. Em geral tratados pela rede.
- Ataques de camada 7: requisições HTTP de aparência válida que consomem CPU, banco de dados ou workers. Esses chegam à sua aplicação.
Passo 1: limite a taxa no Nginx
Limite a velocidade com que um único endereço pode fazer requisições. Defina uma zona no bloco http e aplique-a ao seu site.
limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=connip:10m;
server {
location / {
limit_req zone=perip burst=20 nodelay;
limit_conn connip 20;
}
location = /login {
limit_req zone=perip burst=3 nodelay;
}
}
Use um limite muito mais rígido em logins e buscas, já que são operações caras.
Passo 2: use cache sempre que puder
Uma página em cache quase não custa nada para servir. Ative o cache FastCGI ou de proxy para o tráfego anônimo, mesmo por 30 a 60 segundos. Isso transforma uma inundação de requisições idênticas em um punhado de requisições reais.
fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=site:50m inactive=10m;
fastcgi_cache site;
fastcgi_cache_valid 200 60s;
fastcgi_cache_use_stale updating error timeout;
Passo 3: defina timeouts sensatos
Ataques de conexão lenta mantêm workers abertos. Reduza os limites.
client_body_timeout 10s;
client_header_timeout 10s;
send_timeout 15s;
keepalive_timeout 15s;
client_max_body_size 5m;
Passo 4: bana reincidentes com o fail2ban
Bana os endereços que acionam o limitador de taxa. O Nginx registra as requisições rejeitadas no log de erros, e um filtro pode identificá-las.
[nginx-limit-req]
enabled = true
filter = nginx-limit-req
logpath = /var/log/nginx/error.log
maxretry = 10
findtime = 60
bantime = 1h
Passo 5: coloque um proxy na frente quando a situação ficar séria
Um proxy reverso ou CDN com desafios contra bots pode absorver ataques que um único VPS não consegue. Lembre-se de proteger a origem como descrito em manter o IP de origem em segredo, ou os atacantes vão contorná-lo.
Esteja preparado antes que aconteça
- Conheça as suas páginas mais lentas e corrija-as ou coloque-as em cache.
- Mantenha o monitoramento para perceber um pico rapidamente.
- Tenha um plano: limites mais rígidos, uma página de manutenção, um servidor maior.
O básico no guia de UFW e fail2ban complementa este.