Sicurezza Essenziale di Nginx: Best Practice e FAQ per la Risoluzione dei Problemi

La sicurezza essenziale di Nginx non è un singolo parametro o un'intestazione magica. È una raccolta di impostazioni predefinite attente: HTTPS, accesso ai file rigoroso, comportamento proxy sicuro, esposizione limitata e log che ti aiutano a individuare i problemi prima che crescano.

Questa FAQ copre le domande che i team di solito si pongono dopo aver messo online Nginx e aver realizzato che la configurazione predefinita è solo un punto di partenza.

Quali Sono le Prime Impostazioni di Sicurezza di Nginx da Revisionare?

Inizia con le basi che riducono l'esposizione accidentale. Queste impostazioni ti proteggono da errori comuni, non da attacchi avanzati.

Prima di tutto, disabilita i token di versione:

server_tokens off;

Questo impedisce a Nginx di pubblicizzare la sua versione nelle pagine di errore e nelle intestazioni. Non rende il server invisibile, ma rimuove dettagli non necessari.

In secondo luogo, assicurati che la root del documento sia corretta. Un errore comune è puntare root a una directory di progetto invece che alla directory di build pubblica. Questo può esporre file sorgente, esempi di ambiente o risorse private.

Per un sito statico, preferisci qualcosa come:

root /var/www/example.com/public;

non:

root /var/www/example.com;

Terzo, blocca i file nascosti a meno che la tua applicazione non ne abbia realmente bisogno:

location ~ /\.(?!well-known) {
    deny all;
}

Questo permette i percorsi .well-known utilizzati per la convalida dei certificati, negando al contempo file come .env, .git e .htpasswd.

Infine, rivedi i limiti di upload. Se il tuo sito non accetta upload di grandi dimensioni, mantieni client_max_body_size modesto. Questo riduce il raggio d'azione di richieste grandi accidentali.

Come Dovrebbe Gestire Nginx l'HTTPS?

HTTPS dovrebbe essere il percorso normale per siti web pubblici e API. Reindirizza il semplice HTTP a HTTPS, utilizza certificati validi ed evita impostazioni di protocollo obsolete.

Un semplice blocco server di reindirizzamento è simile a questo:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

Il blocco server HTTPS dovrebbe fare riferimento ai tuoi file di certificato e includere impostazioni TLS moderne. Molti team utilizzano Certbot o un bilanciatore di carico gestito per gestire i certificati. Il punto importante è mantenere il rinnovo automatizzato e monitorato.

Le intestazioni di sicurezza possono anche aiutare i browser a prendere decisioni più sicure:

add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Fai attenzione con Content Security Policy. È potente, ma una politica rigorosa può rompere script, font, analytics o contenuti incorporati se la applichi senza test. Inizia in modalità solo report quando possibile.

Per una guida pratica su HTTPS, vedi proteggere Nginx con HTTPS.

Come Proteggo Nginx come Proxy Inverso?

Quando Nginx instrada il traffico verso un'app, devi preservare le giuste informazioni sulla richiesta senza fidarti ciecamente dell'input del client.

Le intestazioni proxy comuni sono simili a queste:

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

Queste intestazioni aiutano l'applicazione upstream a comprendere la richiesta originale. Sono utili per logging, reindirizzamenti, limitazione della velocità e controlli di sicurezza.

Se Nginx si trova dietro un altro proxy fidato o bilanciatore di carico, configura la gestione degli IP reali con attenzione. Fidati solo degli indirizzi proxy conosciuti:

set_real_ip_from 10.0.0.0/8;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

Non fidarti di X-Forwarded-For proveniente da Internet aperto. Un client può falsificare quell'intestazione. Fidati solo quando la richiesta proviene dal tuo bilanciatore di carico, CDN o proxy interno.

Dovresti anche nascondere i dettagli di implementazione upstream. Se la tua app restituisce intestazioni specifiche del framework di cui non hai bisogno, rimuovile a livello di proxy o applicazione.

Dovrei Usare la Limitazione della Velocità?

La limitazione della velocità è utile per pagine di login, endpoint di ricerca, API costose e qualsiasi percorso che gli aggressori possano abusare a basso costo. Non sostituisce la sicurezza dell'applicazione, ma può rallentare i tentativi di forza bruta e il traffico rumoroso.

Esempio:

limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

server {
    location /login {
        limit_req zone=login burst=10 nodelay;
        proxy_pass http://app_backend;
    }
}

Questo crea una zona di memoria condivisa basata sull'IP del client e limita le richieste al percorso di login. I valori esatti dipendono dai tuoi utenti. Una dashboard aziendale può di solito tollerare limiti più severi rispetto a un'app consumer pubblica su reti mobili.

Testa attentamente i limiti di velocità. Se il tuo sito è dietro un proxy e non hai configurato la gestione degli IP reali del client, ogni utente potrebbe apparire provenire dallo stesso indirizzo. Questo può bloccare il traffico legittimo.

Perché Vedo Ancora Richieste Sospette?

I server Nginx pubblici ricevono costantemente rumore di fondo: scansioni per vecchi pannelli di amministrazione, file PHP, percorsi WordPress e file di ambiente esposti. Vedere queste richieste nei log non significa sempre che sei stato compromesso.

Ciò che conta è come risponde il tuo server. Una richiesta per /wp-admin su un sito non WordPress dovrebbe restituire 404 o 403. Una richiesta per /.env non dovrebbe mai restituire segreti. Una richiesta con un percorso strano non dovrebbe essere inoltrata a un servizio di amministrazione interno.

Controlla i tuoi log di accesso per:

• Risposte 401 o 403 ripetute
• Molte richieste da un singolo IP
• Corpi di richiesta grandi
• Sondaggi per file nascosti
• User agent insoliti
• Picchi di risposte 499, 502 o 504

Per una risoluzione dei problemi più ampia, vedi errori comuni di Nginx.

Quando Chiedere Aiuto per la Sicurezza

Coinvolgi un ingegnere della sicurezza o un consulente DevOps esperto quando Nginx protegge dati dei clienti, autenticazione, flussi di pagamento, API private o strumenti di amministrazione interni. Dovresti anche chiedere aiuto dopo qualsiasi sospetta violazione, esposizione imprevista di file o traffico di attacco ripetuto che influisce sulla disponibilità.

La revisione professionale vale la pena quando la configurazione si estende su più livelli, come CDN, bilanciatore di carico, Nginx, service mesh e framework applicativo. Un file Nginx sicuro può ancora essere indebolito da un confine di fiducia errato altrove.

Proteggi Nginx rimuovendo esposizioni non necessarie, forzando HTTPS, gestendo attentamente le intestazioni proxy e monitorando i log. Non hai bisogno di una configurazione enorme per essere più sicuro. Hai bisogno di impostazioni predefinite chiare, modifiche testate e l'abitudine di controllare cosa serve effettivamente il tuo server.