Nginx Security Headers WAF e Protezione DDoS — Blocca Attacchi Senza Hardware Costoso

Attenzione: l'uso di if in location può essere problematico. In Nginx, if è spesso sconsigliato per logiche complesse, ma per semplici blocchi è accettabile. Alternativa: usare location ~ con regex sul request URI.

Per bloccare lo scanning di percorsi sensibili:

location ~* \.(env|git|svn|htaccess|bak|old)$ {
    deny all;
    return 403;
}

location ~* /(wp-admin|admin|phpmyadmin)/* {
    # Se non hai bisogno di queste aree, blocca
    deny all;
    return 403;
}

Esempio reale: abbiamo un cliente che aveva il file .env accessibile pubblicamente. Con questa regola abbiamo bloccato l'accesso in 5 minuti.

Limitare metodi HTTP non necessari

Blocca PUT, DELETE, TRACE, CONNECT se non li usi:

if ($request_method !~ ^(GET|HEAD|POST)$) {
    return 405;
}

Come limitare le richieste per mitigare attacchi DDoS su Nginx?

Il rate limiting di Nginx (modulo ngx_http_limit_req_module) è la tua arma più semplice contro DDoS di livello applicativo e brute force. Permette di limitare il numero di richieste al secondo per IP o sessione.

Configurare il rate limiting

Nel blocco http, definisci una zona di memoria:

# Zona per limitare le richieste (10 MB = circa 160.000 IP) 
limit_req_zone $binary_remote_addr zone=ddos:10m rate=30r/s;

# Server block
server {
    ...
    location / {
        limit_req zone=ddos burst=50 nodelay;
        ...
    }
}

• rate=30r/s: massimo 30 richieste al secondo per IP.
• burst=50: consente un picco di 50 richieste extra se arriva un breve scoppio.
• nodelay: non ritarda le richieste burst, le processa subito (aumenta il rischio di overflow).

Se un IP supera i limiti, Nginx risponde con 503 Service Unavailable. Puoi personalizzare la risposta:

limit_req_status 429; # Too Many Requests

Consiglio: per login e API (es. WooCommerce checkout) usa zone separate con rate più bassi (5-10 r/s).

Limitare connessioni simultanee

Il modulo limit_conn limita il numero di connessioni simultanee per IP:

limit_conn_zone $binary_remote_addr zone=conn:10m;
server {
    location / {
        limit_conn conn 10;
    }
}

Utile per mitigare attacchi slowloris (che tengono aperte molte connessioni lentamente).

Proteggere il traffico UDP/HTTP2 con limiti più stringenti

Se usi HTTP/2, i client possono multiplexare molte richieste su una singola connessione. Nginx ha parametri specifici:

http2_max_concurrent_streams 128;   # default 128
http2_recv_timeout 5s;

Per HTTP/1.1, abbassa i timeout di keepalive:

keepalive_timeout 15;
keepalive_requests 100;

Come testare e monitorare le configurazioni di sicurezza?

Non basta configurare: devi verificare che gli header siano effettivamente inviati e che il rate limiting funzioni. Ecco come fare.

Test con curl e strumenti online

• curl -I per vedere gli header.
• securityheaders.com (Scott Helme) — analisi degli header di sicurezza.
• Observatory di Mozilla — test completo di sicurezza web.

Simula un attacco DDoS con ab (Apache Bench) o wrk:

ab -n 1000 -c 100 https://iltuosito.it/

Se il rate limiting è attivo, dovresti vedere risposte 429/503 dopo le prime richieste.

Monitoraggio con i log di Nginx

Abilita il log delle richieste limitate:

log_format blocked '$remote_addr - $remote_user [$time_local] '
                  '"$request" $status $body_bytes_sent '
                  '"$http_referer" "$http_user_agent"';
server {
    access_log /var/log/nginx/access.log;
    # Log separato per richieste limitate
    access_log /var/log/nginx/limited.log blocked if=$limit_req_status;
}

Analizza i log con grep per trovare pattern sospetti: grep ' 503 ' /var/log/nginx/access.log.

Domande frequenti sulla sicurezza Nginx

Devo usare ModSecurity o va bene solo Nginx nativo?

Nginx nativo con header, rate limiting e blocchi URI è sufficiente per la maggior parte delle PMI. Se hai esigenze di compliance (PCI-DSS) o gestisci dati sensibili, ModSecurity con le OWASP CRS è consigliato. Noi lo abbiamo integrato per clienti nel settore sanitario e finanziario.

Cosa fare se una regola WAF blocca il traffico legittimo?

Usa log dettagliati. In ModSecurity, abilita SecRuleEngine DetectionOnly per testare senza bloccare. Per Nginx nativo, sposta il blocco in una location specifica o usa geo per whitelistare IP fidati.

Cosa fare adesso

1. Aggiungi gli header di sicurezza a nginx.conf ricarica con nginx -s reload.
2. Configura rate limiting per le route critiche (login, API, checkout).
3. Blocca i percorsi sensibili (.env, admin, backup).
4. Testa con curl e securityheaders.com.
5. Monitora i log per identificare attacchi in corso.

Se vuoi una configurazione personalizzata per il tuo progetto, contattaci. Noi lo facciamo ogni giorno. Ricorda: un server Nginx senza protezione è come un negozio con la porta aperta.

Per approfondire la configurazione di Nginx in produzione, consulta la nostra guida pillar su Nginx e Web Server Configuration.