Sophos Firewall WAF: Pubblicare in sicurezza un server web

Con Web Server Protection o Web Application Firewall (WAF), è possibile pubblicare applicazioni web interne o basate su cloud tramite Sophos Firewall. Il firewall funziona come un Reverse Proxy: i client si connettono all’indirizzo pubblico del firewall, che verifica il traffico HTTP o HTTPS e inoltra la richiesta al server web protetto.

Una regola WAF non sostituisce automaticamente lo sviluppo sicuro delle applicazioni, il patching, l’autenticazione forte o il rafforzamento del server. Tuttavia, rispetto a un semplice inoltro di porta, riduce notevolmente la superficie di attacco, poiché il traffico HTTP(S) può essere esaminato, limitato e registrato in modo più mirato.

Tuttavia, WAF non è automaticamente la risposta giusta per ogni pubblicazione. È fondamentale verificare se l’applicazione funziona correttamente su HTTP o HTTPS, se il firewall deve valutare i nomi host e i percorsi e se il livello aggiuntivo di Reverse Proxy si adatta all’applicazione.

Quando è sensato usare WAF invece di DNAT

Per servizi TCP o UDP semplici, si continua a utilizzare NAT e regole del firewall. Per le applicazioni web, WAF è spesso la scelta migliore.

Se si desidera rendere rapidamente accessibile un server web interno tramite inoltro di porta, consultare la guida Pubblicare server tramite DNAT su Sophos Firewall. Per applicazioni web pubbliche, è consigliabile esaminare prima WAF.

⚠️ WebDAV non è supportato da Sophos WAF. Pertanto, applicazioni come Nextcloud non dovrebbero essere pubblicate ciecamente tramite WAF, ma pianificate tramite regole firewall e NAT appropriate o un’altra architettura di pubblicazione.

Decisione: WAF, DNAT o accesso privato

La domanda più importante non è quanto velocemente si può costruire una pubblicazione, ma se può essere gestita, testata e ritirata in sicurezza in seguito. Questa classificazione aiuta prima dell’implementazione tecnica:

Per applicazioni private, una regola WAF accessibile a livello mondiale è spesso troppa superficie di attacco. Se devono accedere solo poche persone, reti di origine fisse, VPN, ZTNA o un’altra architettura di accesso privato sono spesso più pulite di una pubblicazione web pubblica.

Prerequisiti

Prima della prima regola WAF, è necessario chiarire questi punti:

• Nome DNS pubblico, ad esempio portal.example.com
• Indirizzo IP pubblico o alias sull’interfaccia WAN
• Certificato per il nome host pubblicato
• Indirizzo IP interno o FQDN del server web
• Porta di destinazione interna del server web
• Decisione se reindirizzare HTTP su HTTPS
• Reti di origine, paesi o gruppi di utenti consentiti
• Profilo di protezione appropriato e policy IPS opzionale
• Logging attivato per analisi successive
• Accesso di test esterno al di fuori della propria LAN

Il nome DNS pubblico deve puntare all’indirizzo utilizzato nella regola WAF come Hosted address. In caso di HTTPS, il certificato deve corrispondere al nome host pubblicato.

Pianificare la pubblicazione WAF prima della configurazione

Una regola WAF non dovrebbe essere pianificata solo nella maschera. Prima deve essere chiaro se Sophos Firewall deve solo pubblicare o se deve anche gestire autenticazione, profili di protezione, regole nazionali e logging.

Queste domande sono importanti prima di una pubblicazione produttiva:

Per i certificati, è necessario chiarire presto se importare un certificato esistente, se il firewall deve creare e rinnovare un certificato Let’s Encrypt o se è necessario un certificato generato esternamente. Per i certificati wildcard, c’è una guida separata: Creare un certificato wildcard Let’s Encrypt.

Struttura di base di una regola WAF

Una pubblicazione WAF è composta da diversi elementi:

Sophos crea regole WAF nell’area delle regole del firewall. L’azione si chiama Protect with web server protection.

Creare una regola WAF

Il percorso del menu è:

Rules and policies > Firewall rules

Procedura:

1. Selezionare IPv4.
2. Aprire Add firewall rule.
3. Selezionare New firewall rule.
4. Assegnare un nome descrittivo alla regola.
5. In Action, scegliere l’opzione Protect with web server protection.
6. Se non è necessario un modello speciale, lasciare Preconfigured template su None.
7. In Hosted server details, definire l’indirizzo pubblico, la porta di ascolto, HTTPS, certificato e domini.
8. In Protected servers, selezionare o creare un nuovo server web interno.
9. Impostare consapevolmente Allowed client networks. Per siti web pubblici può essere necessario Any IPv4, per portali è meglio una restrizione.
10. Se necessario, impostare Blocked client networks o Blocked countries.
11. Verificare profilo di protezione, IPS e opzioni avanzate.
12. Salvare la regola e testare esternamente.

Quando la regola viene salvata, Sophos riavvia le regole di Web Server Protection. Le connessioni live esistenti tramite queste regole possono essere interrotte. Pertanto, le modifiche alle regole WAF produttive dovrebbero essere effettuate in una finestra di manutenzione o almeno consapevolmente.

Pianificare il go-live e il rollback

Una pubblicazione WAF non dovrebbe essere considerata completata solo con il salvataggio della regola. È fondamentale verificare se DNS, certificato, Hosted address, backend, profilo di protezione e logging funzionano insieme. Soprattutto con inoltri di porta esistenti, il passaggio dovrebbe essere trattato come una piccola pubblicazione.

Prima del go-live, verificare:

• Documentare la configurazione attuale del firewall o almeno le impostazioni di regola e certificato interessate.
• Identificare le regole DNAT o firewall precedenti che riguardano la stessa porta, IP pubblico o nome host.
• Disattivare le vecchie regole DNAT o documentare chiaramente perché non competono con la regola WAF.
• Ridurre il TTL DNS prima di una modifica se il nome host pubblico passa da una vecchia pubblicazione a WAF.
• Fornire accesso di test esterno, non testare solo dalla LAN interna.
• Definire casi di test: pagina iniziale, login, upload, download, percorso API, WebSocket, logout e messaggio di errore.
• Stabilire punti di log attesi: Log Viewer, reverseproxy.log, log di accesso del backend e log di errore del backend.
• Stabilire un criterio di rollback, ad esempio login non possibile, backend non raggiungibile, certificato errato, alto tasso di errore o parti critiche dell’applicazione difettose.

Durante il passaggio, dovrebbe essere attiva solo una pubblicazione alla volta. Se una vecchia regola DNAT e una nuova regola WAF utilizzano lo stesso IP pubblico e la stessa porta, il comportamento è difficile da comprendere. Prima di passare alla produzione, dovrebbe essere chiaro quale regola gestisce effettivamente il traffico.

Un rollback semplice consiste spesso nel disattivare la nuova regola WAF e riattivare la pubblicazione precedente. Se è stato modificato anche il DNS, bisogna considerare il TTL DNS. In caso di problemi con certificati o nomi host, un rollback tramite DNS da solo è spesso troppo lento; in tali casi, la vecchia regola sulla stessa Hosted address dovrebbe essere riattivabile o dovrebbe essere disponibile un accesso alternativo.

Dopo il go-live, i primi accessi dovrebbero essere monitorati attivamente. Sono importanti non solo i codici di stato HTTP di successo, ma anche i blocchi WAF, errori del backend, reindirizzamenti inaspettati, problemi di sessione e informazioni mancanti sull’IP del client nei log del backend.

Test di accettazione dopo il go-live

Un test WAF è completo solo quando la stessa richiesta è tracciabile da tre punti di vista: client, firewall e backend. Ciò consente di identificare più rapidamente se un problema riguarda DNS, certificato, corrispondenza WAF, profilo di protezione o applicazione.

Per applicazioni produttive, è necessario testare almeno questi casi:

• Accesso tramite il nome host corretto e tramite un dominio non corrispondente.
• Login con utente valido e non valido, se l’applicazione o WAF autentica.
• Funzione di upload, download, API o WebSocket, se l’applicazione utilizza tali funzioni.
• Accesso da fonte consentita e, se possibile, da una fonte consapevolmente non consentita.
• Comportamento di una richiesta di test WAF nota e innocua, in modo che il logging e il percorso di blocco siano visibili.

Se l’applicazione sembra funzionare dopo il go-live, ma non sono visibili log corrispondenti, il test non è ancora concluso. In tal caso, potrebbe essere che un’altra pubblicazione corrisponda, che manchi il logging o che l’accesso non avvenga tramite il percorso previsto.

Certificati e nomi host

Per HTTPS, la regola WAF deve utilizzare un certificato che corrisponda al nome host pubblico. Il certificato viene importato o creato sotto Certificates > Certificates e successivamente selezionato nella regola WAF.

Punti importanti:

• Il nome DNS deve corrispondere al certificato.
• Con più nomi host sullo stesso IP, il firewall utilizza SNI.
• I certificati wildcard sono possibili, ma devono essere documentati accuratamente.
• Il backend può utilizzare un nome interno diverso se l’intestazione Host e l’applicazione possono gestirlo.
• In caso di problemi con i link assoluti, Rewrite HTML può diventare rilevante.

Se più server web virtuali funzionano sullo stesso IP e porta, il firewall decide in base a SNI e nome host quale regola WAF è appropriata.

Pianificare IP del client e log del backend

Nelle pubblicazioni WAF, il server web interno spesso non vede l’IP reale del client come indirizzo di origine diretto. Sophos Firewall funziona come Reverse Proxy e stabilisce la connessione al backend autonomamente. Per l’applicazione e i log del server web, quindi, può essere visibile prima l’indirizzo del firewall.

Se l’applicazione o il backend necessita dell’IP originale del client, è necessario verificare presto se X-Forwarded-For o un’intestazione comparabile viene valutata. Questo è importante per:

• Log delle applicazioni e valutazione della sicurezza
• Limiti di velocità o protezione del login a livello applicativo
• Analisi degli errori con riferimento all’utente o all’IP di origine
• Correlazione SIEM o monitoraggio
• Valutazione forense dopo un incidente

È importante il limite di fiducia: un backend dovrebbe trattare tali intestazioni come affidabili solo se la richiesta proviene effettivamente da Sophos Firewall o da un Reverse Proxy definito. I client pubblici non devono poter impostare direttamente X-Forwarded-For come prova di sicurezza. In pratica, il server web dovrebbe quindi fidarsi solo dell’IP del firewall e ignorare o sovrascrivere intestazioni da altre fonti.

Per il troubleshooting, ciò significa che Log Viewer, reverseproxy.log e log del backend devono coprire lo stesso momento del test. Se nel backend è visibile solo l’IP del firewall, non è automaticamente un errore WAF, ma spesso un comportamento normale del Reverse Proxy.

Limitare l’accesso del client

Non tutte le applicazioni web devono essere accessibili a livello mondiale. Già nella regola WAF è possibile limitare l’accesso.

Limitazioni sensate:

• Consentire solo indirizzi IP di origine noti o reti partner.
• Bloccare paesi non necessari.
• Bloccare indirizzi IP di origine di paesi sconosciuti solo se è stato valutato il rischio di un proprio blocco.
• Per i portali, utilizzare anche WAF-MFA o autenticazione preposta.
• Bloccare fonti malevole conosciute tramite Threat Feeds.

Per il blocco di paesi e IP malevoli, consultare Sophos Firewall: Bloccare paesi e IP malevoli. Per le liste di minacce dinamiche, è rilevante Sophos Firewall Threat Feeds.

Pianificare Threat Feeds e Active Threat Response

Per le applicazioni web accessibili pubblicamente, non si dovrebbe considerare solo la regola WAF stessa. Dalla versione SFOS 22, i Threat Feeds sono rilevanti anche per il traffico in entrata e inoltrato come le pubblicazioni WAF e DNAT. Il firewall può confrontare tali rilevamenti con MDR Threat Feeds, NDR Essentials e Third-Party Threat Feeds.

Per gli amministratori, ciò significa che WAF è il livello di pubblicazione, mentre Threat Feeds e Active Threat Response possono bloccare o rendere visibili fonti malevole conosciute. Tuttavia, ciò non sostituisce la gestione delle patch, un’autenticazione pulita e il rafforzamento delle applicazioni.

Praticamente, si dovrebbe verificare:

• Active Threat Response è configurato in modo sensato nell’ambiente?
• Vengono utilizzati e controllati regolarmente Threat Feeds rilevanti?
• Gli eventi WAF, i log di Active Threat Response e i log del backend sono visibili in produzione?
• Esiste un processo per i falsi positivi, la whitelist e le autorizzazioni di emergenza?
• È chiaro chi reagisce ai rilevamenti e se vengono solo registrati o bloccati attivamente?

Soprattutto per portali clienti, interfacce amministrative o accessi partner, questa verifica dovrebbe avvenire prima del go-live. Se un feed blocca successivamente il traffico produttivo, l’operazione deve sapere dove vedere il rilevamento e come decidere correttamente: attacco reale, falso allarme o applicazione pubblicata erroneamente.

Profili di protezione ed eccezioni

Una regola WAF non dovrebbe solo pubblicare, ma anche proteggere. A tal fine, si utilizzano Protection Policies, IPS Policies opzionali ed eccezioni.

Aree di protezione tipiche:

• Manipolazione dei cookie
• Hardening degli URL
• Hardening dei form
• Cross-Site Scripting
• Attacchi alle applicazioni
• Controllo antivirus
• Client con cattiva reputazione

Le eccezioni dovrebbero essere impostate in modo ristretto. Se un’applicazione non funziona a causa di un singolo percorso o di una fonte specifica, non si dovrebbe disattivare l’intero profilo di protezione. È meglio un’eccezione mirata con percorso, fonte e chiara motivazione.

⚠️ Ogni eccezione riduce l’efficacia della protezione. Percorso, fonte, motivo, data e termine di revisione dovrebbero essere documentati, in modo che le soluzioni temporanee non diventino permanenti.

Routing specifico per percorso, WebSocket e Load Balancing

WAF può inoltrare le richieste a server backend diversi a seconda del percorso. Questo è utile quando un’applicazione ha più componenti o un singolo nome host deve essere distribuito su più servizi interni.

Esempi:

• /api/ va a un server API.
• /shop/ va a un sistema di negozio.
• / va al server web standard.

Bisogna considerare che il firewall non valuta i percorsi semplicemente in base all’ordine delle righe della tabella. I percorsi specifici devono essere pianificati e testati accuratamente. Se è necessario WebSocket, può essere attivato WebSocket passthrough. Il traffico WebSocket viene quindi passato senza la stessa verifica WAF, poiché il protocollo non può essere verificato allo stesso modo del traffico HTTP normale.

Con più server backend, sono possibili sessioni sticky o standby caldo. Questo aiuta in semplici casi di alta disponibilità o distribuzione del carico, ma non sostituisce un concetto completo di bilanciamento del carico applicativo.

Errori tipici

Risoluzione dei problemi

Se una pubblicazione WAF non funziona, si dovrebbe verificare sistematicamente:

1. Il nome DNS pubblico punta all’IP pubblico corretto?
2. È selezionata la Hosted address corretta nella regola WAF?
3. La porta di ascolto è libera e non occupata da WebAdmin, User Portal, VPN Portal o un’altra pubblicazione?
4. Il certificato corrisponde al nome host chiamato?
5. Il server web interno è raggiungibile dal firewall?
6. Allowed client networks, Blocked client networks e Blocked countries sono impostati correttamente?
7. Esiste una regola WAF più generale che corrisponde prima?
8. L’accesso viene visualizzato nel Log Viewer come consentito, bloccato o scartato?
9. Ci sono indicazioni in /log/reverseproxy.log?

Per la prima analisi, il Log Viewer è utile. Per un troubleshooting più approfondito, aiutano i log di Web Server Protection sul firewall. Una panoramica dei file di log e dei servizi è disponibile in Sophos Firewall Troubleshooting: Servizi e Log.

Checklist per regole WAF produttive

• Il nome della regola descrive applicazione, nome host e ambiente.
• La persona responsabile o il proprietario del sistema è documentato.
• DNS, certificato e Hosted address sono verificati.
• La raggiungibilità del backend è stata testata dal firewall.
• La pubblicazione precedente e il rollback sono documentati.
• Le vecchie regole DNAT o firewall non competono con la regola WAF.
• I test di go-live esterni sono definiti.
• L’accesso è limitato alle fonti o ai paesi necessari.
• Threat Feeds e Active Threat Response sono stati valutati per applicazioni pubbliche.
• Il logging è attivo.
• Il profilo di protezione non è disattivato inutilmente.
• Le eccezioni sono strette, giustificate e temporanee.
• La modifica è stata testata esternamente.
• La data di scadenza o il termine di revisione è documentato.

Domande frequenti