Indurimento delle web app a livello infrastrutturale: TLS sul reverse proxy, HSTS, ottimizzazione di HTTP/2 e regole WAF automatizzate

Errore: „Se l’applicazione è sicura, bastano le correzioni del codice — l’indurimento dell’infrastruttura è solo sovraccarico.“

È un’aspettativa diffusa, ma è una visione riduttiva. L’indurimento delle Web‑App basato sull’infrastruttura riduce in modo sistematico le superfici d’attacco laddove operano reti, policy dei cifrari, protocolli e gateway centrali. Il termine „indurimento delle Web‑App basato sull’infrastruttura“ descrive esattamente questo approccio centralizzato: strato proxy, policy TLS, HSTS, limiti HTTP/2 e regole WAF automatizzate vengono applicati come livelli di protezione gestibili operativamente. In casi eccezionali — ad esempio requisiti normativi che richiedono una vera crittografia end‑to‑end — la strategia può essere limitata. Questo contributo mette alla prova il mito, mostra le eccezioni e fornisce una procedura pratica e orientata all’operatività per amministratori e gestori.

Indurimento delle Web‑App basato sull’infrastruttura: perché l’approccio centralizzato spesso offre vantaggi maggiori

Un reverse‑proxy centrale riduce il carico amministrativo: certificati, baseline dei cifrari, header HSTS e regole WAF sono gestiti in un unico punto. OWASP raccomanda la TLS‑termination sul proxy come strategia praticabile per ridurre lo sprawl delle chiavi e per l’applicazione centralizzata delle policy TLS — questo riduce la probabilità che certificati scaduti o configurati in modo errato passino inosservati.^[Fonte]

Prerequisiti: quando la centralizzazione ha senso

Optate per la centralizzazione solo se sono soddisfatti i seguenti prerequisiti:

• Disponete di un inventario di tutti i domini/sottodomini e di una gestione automatica dei certificati (ACME/PKI).
• I backend si fidano del proxy (p. es. tramite segmento di rete o mTLS), oppure utilizzate connessioni Reencrypt verso il backend.
• Sono presenti monitoraggio e playbook per i rollback (handshakes, 4xx/5xx, rilevamenti WAF).

1. Terminazione TLS sul reverse proxy: varianti, vantaggi, rischi

Le decisioni di policy si possono assegnare a tre varianti: Offload (il proxy termina, backend non cifrato), Reencrypt (il proxy termina e apre un nuovo flusso TLS verso il backend), o mTLS (autenticazione reciproca con certificati). Le linee guida NIST indicano TLS 1.2+ come requisito minimo e raccomandano il supporto a TLS 1.3; oggi questo è lo standard per ambienti produttivi. La centralizzazione semplifica i rollout dei cifrari, ma sposta il confine di sicurezza sul layer del proxy — un proxy compromesso mette a rischio tutti i servizi a valle.^[Fonte]

Configurazione di base concreta per NGINX

# Beispiel: NGINX TLS-Grundset (Auszug)
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers on;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;

Perché? TLS 1.3 riduce i roundtrip e esclude costrutti di cifratura obsoleti. L’OCSP Stapling (ssl_stapling) solleva i client dal controllo dello stato del certificato. I guasti si verificano spesso a causa di client incompatibili — testate quindi in un canary‑pool.

Comandi di verifica prima del rollout

# Quick-TLS-Check: supported protocols und ciphers
openssl s_client -connect example.com:443 -alpn h2 -tls1_3

# OCSP Stapling prüfen
openssl s_client -connect example.com:443 -status

Checklist pratica per il rollout TLS

1. Inventario: rilevare domini, sottodomini, emittenti e date di scadenza.
2. Baseline: utilizzare Mozilla Intermediate come riferimento praticabile.
3. Staging: simulare un canary pool con client meno recenti.
4. Monitoraggio: osservare errori di handshake, distribuzioni Client‑TLS ed errori OCSP.
5. Fallback: configurare rollback automatico in caso di picco di errori di handshake.

2. Rollout HSTS: fasi, rischi del preload, passaggi di verifica

HSTS impedisce il fallback su HTTP e lo SSL‑stripping, ma è persistente: i browser memorizzano la policy e impongono HTTPS fino alla scadenza di max‑age. RFC 6797 documenta questo comportamento e avverte contro rollout imprudenti che possono bloccare gli utenti in caso di guasto del certificato.^[Fonte]

# HSTS-Schrittweiser Rollout (NGINX)
# Anfang: kurzer max-age für Test
add_header Strict-Transport-Security "max-age=86400; includeSubDomains" always;

# Nach Tests: langfristig
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Regola: iniziate con un max‑age breve (ad es. 1 giorno) e verificate i report di errore. Il preload dovrebbe essere attivato solo dopo aver controllato completamente l’inventario delle sottodomini, il controllo DNS e l’automazione dei certificati — le voci di preload rimangono efficaci nelle liste dei browser a lungo termine.

3. Ottimizzazione HTTP/2: parametri, test e insidie tipiche

HTTP/2 introduce efficienza, ma anche nuovi limiti di risorse. RFC 9113 descrive parametri come SETTINGS_MAX_HEADER_LIST_SIZE come mezzo per controllare le dimensioni degli header; leve di configurazione esistono nei proxy più diffusi (NGINX, HAProxy). Valutate quali limiti necessitano i client API, le SPA o i gateway — limiti troppo restrittivi possono bloccare pattern di traffico legittimi.^[Fonte]

# NGINX HTTP/2-Tuning (Beispiel)
http2_max_field_size 8192;
http2_max_header_size 32768;
http2_max_concurrent_streams 128;

# Beispiel-Lasttest mit h2load
h2load -n 10000 -c 100 -m 10 https://example.com/

Insidie: le SPA con Authorization‑header lunghi o gateway API con header di tracing aggiuntivi possono attivare i limiti. Analizzate gli access log per le distribuzioni delle lunghezze degli header prima di impostare limiti rigidi.

# Header-Längen aus Access-Log extrahieren (Beispiel für nginx combined log)
awk '{print length($12)}' /var/log/nginx/access.log | sort -n | uniq -c | tail -n 20

4. Pipeline automatizzata di regole WAF: DetectionOnly, Replay, CI/CD

OWASP CRS è un set di regole collaudato per WAF compatibili con ModSecurity; in ambienti di produzione è importante un ciclo di vita automatizzato: DetectionOnly → Analisi → eccezioni mirate → Blocking. Iniziate con almeno 7–14 giorni in DetectionOnly, raccogliete i log e raggruppateli per URI, RuleID e User‑Agent. Successivamente create le eccezioni strettamente necessarie e testatele mediante replay su staging.^[Quelle]

Passaggi consigliati del ciclo di vita

1. Rilevare la baseline: gestire la WAF in DetectionOnly, raccogliere i log per 7–14 giorni.
2. Analisi dei log: raggruppare per URI, RuleID, User‑Agent, ResponseCode.
3. Definire eccezioni alle regole in modo minimale: limitare per URI + RuleID + User‑Agent.
4. Replay: reiniettare i traffici in staging e simulare il Blocking.
5. CI/CD: mantenere le regole come codice, testarle automaticamente e distribuirle.

# ModSecurity initial: DetectionOnly
SecRuleEngine DetectionOnly
Include /etc/modsecurity/crs/crs-setup.conf
Include /etc/modsecurity/crs/rules/*.conf

# Beispiel-Regelausnahme (modsecurity)
SecRule REQUEST_HEADERS:User-Agent "^MyMobileApp/" "id:1000001,phase:1,pass,nolog,ctl:ruleRemoveById=942430"

# CI Job: WAF-Regel-Deploy (Auszug)
jobs:
  deploy-waf-rules:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run static checks
        run: waf-lint ./rules
      - name: Deploy to staging
        run: scp -r ./rules user@staging:/etc/modsecurity/rules && ssh user@staging 'systemctl reload nginx'

5. Ciclo di vita dei certificati e OCSP‑Stapling

Automatizzate il rinnovo dei certificati (ACME/Certbot o PKI interna) e collegate i renew‑hook ai reload del proxy. OCSP Stapling riduce la latenza, ma richiede monitoraggio: un Staple mancante può influire sui client. Testate regolarmente le risposte Staple.

# Certbot Renew Hook Beispiel
certbot renew --deploy-hook "systemctl reload nginx"

6. Monitoring, Alerts und Playbooks

Definite KPI e strumentate le metriche del proxy, i WAF‑hits e le statistiche dei TLS‑handshake. Esempi di alert:

1. TLS Handshake Error Rate > 0,5% in 15 minuti → Pager.
2. Aumento significativo di 4xx/5xx dopo modifica HSTS → isolare il Canary.
3. Aumento della False‑Positive Rate della WAF → avviare una revisione delle regole.

# Prometheus Alert: TLS Handshake Error Rate (Auszug)
- alert: TLSHandshakeErrorsHigh
  expr: increase(tls_handshake_errors_total[15m]) / increase(tls_connections_total[15m]) > 0.005
  for: 5m
  labels:
    severity: page
  annotations:
    summary: "Hohe TLS Handshake Error Rate"
    description: "Prüfen: Zertifikatslaufzeiten, OCSP Stapling, Cipher Policy"

Incident‑Playbook (breve): 1) raccogliere i log (proxy, WAF, backend), 2) rimuovere il pool Canary, 3) rollback della configurazione tramite infra‑repo, 4) notificare gli stakeholder, 5) post‑mortem.

7. Hardware: HSM, TLS‑NICs und Betriebsfallen

Acceleratori hardware (TLS‑NICs, HSMs) migliorano il throughput, ma comportano oneri operativi: patch firmware, cambi driver e procedure di key‑recovery. Includete backup delle chiavi, procedure di recovery offsite e test di rotazione nelle vostre routine. Testate gli upgrade firmware degli HSM in cluster isolati e validate le prestazioni di SSL‑offload sotto carico di produzione.

8. Strategie di ripristino e Runbook di rollback

Un rollback correttamente definito previene escalation di guasti. Automatizzate snapshot della configurazione del proxy, tenete pronti proxy di riserva e documentate smoke test che vengano eseguiti automaticamente dopo il rollback (TLS Handshake, header HSTS, casi di test WAF).

1. Trigger: soglia definita (p. es. picco di errori TLS Handshake).
2. Isolare: rimuovere il traffico Canary, reindirizzare il traffico al proxy alternativo.
3. Rollback: ripristinare il repository dell’infrastruttura e innescare il reload della configurazione.
4. Validare: eseguire smoke test.
5. Post‑mortem: documentare l’analisi delle cause e il RACI.

# Einfaches Rollback-Skript: Symlink wechseln und nginx reload
#!/bin/bash
set -e
# Annahme: /etc/nginx/sites-enabled/current -> /etc/nginx/sites-available/config-v2
ln -nsf /etc/nginx/sites-available/config-v1 /etc/nginx/sites-enabled/current
systemctl reload nginx
# Smoke tests
curl -I --http2 https://example.com/ | head -n 5

9. Troubleshooting: Sequenza di verifica concreta in caso di guasti

Se dopo un rollout si manifestano errori TLS, seguite questo ordine: 1) verificare la catena del certificato (validità, SNI, OCSP‑Staple), 2) matrice Cipher/Protocol (analizzare la distribuzione dei client), 3) limiti HTTP/2 (errori sugli header), 4) blocchi WAF (RuleID hits), 5) latenze di rete verso i backend (timeout). Questa sequenza ordina le cause per probabilità d’incidenza in ambienti centralizzati.

# Minimal-Checklist: Logs sammeln
journalctl -u nginx -n 200 | sed -n '1,200p'
grep "ModSecurity: Warning" /var/log/nginx/modsec_audit.log | tail -n 50
openssl s_client -connect example.com:443 -alpn h2 -tls1_3 -servername example.com

Nota pragmatica: i hit WAF possono rivelare modifiche legittime alle API; trattate i nuovi hit inizialmente come possibili regressioni e non immediatamente come attacchi.

Insidie comuni e come evitarle

• Affrettare il preload senza un audit delle sottodomini — evitare il preload finché inventario e controllo DNS non sono completi.
• Limiti HTTP/2 troppo bassi che disturbano client legittimi — eseguire preventivamente analisi degli header e test di carico.
• Firmware HSM/NIC non aggiornati dopo il rollout — predisporre un piano firmware e cluster di test.
• Eccezioni WAF senza data di scadenza e responsabile — documentare le eccezioni con data di scadenza e owner.

Piano di change concreto (sequenza breve)

1. Inventario: raccogliere domini, sottodomini, client e client legacy.
2. Baseline‑Scan: analizzare TLS, i valori predefiniti di HTTP/2 e i log WAF.
3. Staging: configurazione + replay di log reali.
4. Canary: 10–20% del traffico con monitoraggio ravvicinato.
5. Attivazione graduale: TLS Policy → HTTP/2 Limits → HSTS (short→long) → WAF Blocking.
6. Monitoraggio & revisione SLA; finestra di osservazione di 24–72h per fase.
7. Documentare e testare il Rollback‑Runbook e le esercitazioni di ripristino.

L’attuazione pratica richiede disciplina: regole come codice, Canary‑deploys, test automatizzati e un percorso di rollback documentato non sono piacevoli extra, sono protezione operativa. Iniziate con l’inventario e un piccolo Canary‑proxy; estendete passo per passo e misurate gli effetti in modo continuativo.

Per questo argomento sono importanti anche la terminazione TLS e il reverse proxy. L’articolo contestualizza questi aspetti in modo comprensibile e mostra cosa conta nella pratica quotidiana.