Best practice di sicurezza per Nginx: Proteggi il tuo server web

Il tuo server Nginx è spesso il primo servizio pubblico che utenti e attaccanti possono raggiungere. Queste best practice di sicurezza per Nginx si concentrano sui controlli che Nginx può effettivamente applicare: TLS, limiti delle richieste, intestazioni, regole di accesso, impostazioni predefinite più sicure e aggiornamenti regolari.

Nginx non può risolvere da solo il codice applicativo vulnerabile. Trattalo come un livello davanti alla tua app, database, sistema di autenticazione e firewall host.

Connessioni sicure con TLS

TLS crittografa il traffico tra il browser e il tuo server. Utilizza un certificato attendibile, reindirizza HTTP a HTTPS e disabilita le versioni di protocollo obsolete.

Ottieni un certificato

Let's Encrypt è comune per i siti web pubblici, ma qualsiasi autorità di certificazione attendibile può funzionare. Su molti server Linux, Certbot archivia i file in /etc/letsencrypt/live/tuo_dominio.com/.

Configura HTTPS

Modifica il blocco server per il tuo dominio. Il percorso è spesso /etc/nginx/sites-available/ su Debian/Ubuntu o /etc/nginx/conf.d/ su sistemi stile RHEL.

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    http2 on;

    server_name tuo_dominio.com www.tuo_dominio.com;

    ssl_certificate /etc/letsencrypt/live/tuo_dominio.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/tuo_dominio.com/privkey.pem;

    # Includi le tue impostazioni TLS condivise
    include /etc/nginx/snippets/ssl-params.conf;

    # ... altre configurazioni (root, blocchi location, ecc.)
}

server {
    listen 80;
    listen [::]:80;
    server_name tuo_dominio.com www.tuo_dominio.com;

    # Reindirizza HTTP a HTTPS
    return 301 https://$host$request_uri;
}

Utilizza parametri TLS conservativi

Puoi mantenere le impostazioni TLS condivise in un snippet come /etc/nginx/snippets/ssl-params.conf.

# /etc/nginx/snippets/ssl-params.conf

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;

# Abilita HSTS (HTTP Strict Transport Security)
# Aggiungi includeSubDomains se applicabile
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

# Abilita OCSP Stapling per controlli del certificato più veloci
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.8.8 8.8.4.4 valid=300s;
resolver_timeout 5s;

# Parametri Diffie-Hellman (generane uno forte se necessario)
# ssl_dhparam /etc/nginx/ssl/dhparams.pem;

ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_session_tickets off;

Aggiungi includeSubDomains o preload a HSTS solo dopo aver verificato che ogni sottodominio supporti HTTPS. Un rollout HSTS errato può bloccare gli utenti da sottodomini più vecchi.

Implementa il rate limiting

Il rate limiting aiuta a rallentare tentativi di forza bruta, scraping e inondazioni accidentali di richieste. Non è una soluzione DDoS completa, ma dà alla tua app più respiro.

Esempio base di rate limiting

limit_req_zone definisce lo stato condiviso, e limit_req applica il limite a una location.

http {
    limit_req_zone $binary_remote_addr zone=mylimit:10m rate=5r/s;

    server {
        # ...

        location /login {
            limit_req zone=mylimit burst=10 nodelay;
            # ... la tua configurazione del gestore di login
        }

        location / {
            limit_req zone=mylimit burst=20 nodelay;
            # ... la tua configurazione principale del sito
        }
    }
}

In questo esempio: $binary_remote_addr chiave il limite per indirizzo IP del client. burst=10 consente un breve scoppio sopra la velocità media, e nodelay rifiuta le richieste eccessive invece di ritardarle.

Fai attenzione dietro un load balancer o CDN. Se Nginx vede solo l'IP del proxy, il rate limiting tramite $binary_remote_addr può penalizzare tutti gli utenti come un unico client. Configura la gestione degli IP reali attendibili prima di fare affidamento sui limiti per client.

Riduci la superficie di attacco comune

Nginx può ridurre l'esposizione, ma la tua applicazione necessita comunque di validazione dell'input, codifica dell'output, SQL parametrizzato, controlli di autenticazione e patch delle dipendenze.

Aggiungi intestazioni di sicurezza

Le intestazioni di sicurezza possono ridurre il rischio lato browser:

add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;

Una Content Security Policy può aiutare con XSS, ma deve corrispondere a script, stili, immagini e servizi di terze parti della tua app. Inizia in modalità solo report prima di applicarla su un sito di produzione.

Blocca scanner ovvi con cautela

Blocchi di pattern semplici possono fermare scanner rumorosi, ma non sostituiscono un WAF. Mantienili ristretti per non bloccare utenti legittimi.

http {
    # Definisci una mappa per bloccare bot/scanner dannosi
    map $http_user_agent $bad_bot {
        default 0;
        "~*malicious_bot_pattern" 1;
        "~*another_suspicious_agent" 1;
    }

    server {
        # ...
        if ($bad_bot) {
            return 403;
        }
        # ...
    }
}

Limita i percorsi sensibili

Usa try_files, mantieni autoindex disattivato a meno che non ti servano elenchi di directory, e nega l'accesso a file nascosti che non dovrebbero mai essere serviti.

location / {
    root /var/www/html;
    index index.html index.htm;
    try_files $uri $uri/ =404;
    autoindex off; # Disabilita l'elenco delle directory
}

# Esempio di restrizione dell'accesso a file sensibili
location ~ /\.ht {
    deny all;
}

Nascondi la versione di Nginx

server_tokens off rimuove la versione di Nginx dalle pagine di errore generate e riduce i dettagli nell'intestazione di risposta Server.

http {
    server_tokens off;
    # ...
}

Limita i metodi HTTP dove appropriato

Se un endpoint accetta solo GET e POST, rifiuta altri metodi lì. Fallo per location per non rompere le richieste CORS preflight o gli endpoint API che usano legittimamente PUT, PATCH o DELETE.

location /api/ {
    # Consenti solo GET e POST
    if ($request_method !~ ^(GET|POST)$) {
        return 405;
    }
    # ...
}

Mantieni Nginx aggiornato

Le correzioni di sicurezza arrivano spesso tramite il repository di pacchetti della tua distribuzione Linux. Mantieni Nginx e i pacchetti correlati a OpenSSL patchati e testa i ricaricamenti dopo gli aggiornamenti.

Per Debian/Ubuntu:

sudo apt update
sudo apt upgrade nginx

Per CentOS/RHEL:

sudo dnf update nginx

Usa yum update nginx su versioni più vecchie di RHEL/CentOS che usano ancora yum.

Aggiungi protezione a livello di host

La sicurezza di Nginx dipende anche dall'host circostante:

• Consenti solo le porte necessarie in ufw, firewalld, gruppi di sicurezza cloud o ACL di rete.
• Monitora /var/log/nginx/access.log e /var/log/nginx/error.log per picchi, risposte 401/403 ripetute e percorsi sospetti.
• Usa Fail2ban o uno strumento simile quando i pattern dei log possono identificare client abusivi.
• Esegui sudo nginx -t prima di ogni ricaricamento in modo che una modifica di sicurezza non porti offline il sito.

Conclusione

Inizia con HTTPS, aggiornamenti, porte limitate, intestazioni sicure e limiti di velocità su percorsi sensibili come /login. Poi rivedi regolarmente i tuoi log. La maggior parte dei guadagni di sicurezza di Nginx deriva da una manutenzione costante e una configurazione chiara, non da un unico grande file di hardening copiato da un altro sito.