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.

Per il contesto generale di hardening, consultare l’hub Sophos Firewall Hardening: best practice per una configurazione sicura.

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.

Decisione prima della pubblicazione

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.

• DNAT è adatto a servizi non HTTP, semplici inoltri di porta e protocolli speciali. Il firewall traduce e consente quindi principalmente il traffico.
• WAF / Web Server Protection è adatto ad applicazioni HTTP e HTTPS quando sono rilevanti hostname, certificato, percorsi, profili di protezione, autenticazione o regole per paese.
• Reverse Proxy o ZTNA è adatto a piattaforme web complesse, integrazione identità e applicazioni private, quando l’accesso deve essere fortemente controllato o non pubblico.

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:

• Sito web pubblico o semplice applicazione HTTPS: WAF è spesso il punto di partenza adatto. DNS, certificato, hostname, profilo di protezione, logging e raggiungibilità del backend devono essere testati.
• Portale clienti, portale partner o interfaccia amministrativa: WAF con limitazione delle fonti e MFA opzionale può essere sensato. Prima va chiarito se WAF-MFA, regole per paese o reti sorgente fisse sono possibili.
• Servizio TCP o UDP puro: DNAT è di solito più adatto. Regola firewall, regola NAT, server di destinazione, percorso di ritorno e logging devono essere controllati insieme.
• Applicazione web con WebDAV o protocollo speciale: non usare automaticamente WAF. Testare funzioni supportate, comportamento client e pubblicazione alternativa.
• Applicazione solo per utenti interni: verificare VPN, ZTNA o WAF fortemente limitato. La raggiungibilità pubblica va messa in discussione criticamente.

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.

Pianificazione e prerequisiti

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.

Il firewall necessita inoltre di un oggetto web server in Web server > Web servers. Qui si descrive il server di destinazione interno o esterno con host, protocollo e porta. L’host è un oggetto IP o FQDN. Per i backend sono possibili HTTP o HTTPS; le porte standard sono 80 e 443. Se il web server backend fornisce risposte lunghe o richiede keep-alive, Keep alive e Timeout devono essere verificati consapevolmente invece di essere accettati casualmente.

Il Timeout del backend può variare da 1 a 65,535 secondi; il valore predefinito è 300 secondi. Alla scadenza, WAF invia 502 al client. Disable backend connection pooling forza una nuova connessione al backend per ogni richiesta e può ridurre le prestazioni. Questa opzione va usata solo per un troubleshooting mirato e poi riportata allo stato precedente documentato.

Inoltre, i limiti della Web Server Protection dovrebbero essere considerati presto. Sophos indica, tra l’altro, un limite di 60 regole WAF per firewall. Questo basta per molti ambienti, ma con molti portali clienti, tenant, sistemi di test o hostname separati può diventare rilevante prima del previsto. In quel caso non bisognerebbe creare ciecamente altre regole singole, ma verificare concetto dei nomi, percorsi, web server virtuali e modalità alternative di pubblicazione.

SFOS 22 non supporta le regole WAF tramite IPv6. Un’applicazione non deve quindi essere pianificata come pubblicazione IPv6 con questa funzione; la panoramica Supporto IPv6 e limiti in Sophos Firewall con SFOS 22 distingue WAF dalle funzioni IPv6 supportate per regole e protezione. Anche i template Exchange non sono un lasciapassare per ambienti Exchange moderni: Sophos documenta che le regole WAF attualmente non supportano versioni Exchange successive al 2013.

I template preconfigurati provengono da un panorama applicativo Microsoft meno recente: Exchange Autodiscover, Outlook Anywhere ed Exchange General si fermano al limite di Exchange 2013; le altre guide Sophos citano Microsoft Lync, Remote Desktop Gateway o RD Web 2008/R2 e SharePoint 2010/2013. Non rappresentano quindi una base attuale per Microsoft 365, versioni moderne di Exchange, Teams o implementazioni RDS odierne. Prima di usare un template, confrontare i percorsi, i metodi di autenticazione e le policy di protezione realmente necessari con l’architettura Microsoft attuale; per un’applicazione moderna, in caso di dubbio lasciare Preconfigured template su None.

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:

• È davvero un’applicazione HTTP o HTTPS? Per altri protocolli, DNAT è spesso più adatto.
• L’applicazione deve essere pubblicamente accessibile? Portali amministrativi privati spesso si adattano meglio a VPN, ZTNA o reti sorgente limitate.
• Quale hostname e quale certificato vengono usati? DNS, SNI, certificato e domini WAF devono combaciare.
• Quante pubblicazioni sono pianificate? Il limite di regole WAF e la futura gestibilità influenzano il design.
• Il firewall deve autenticare gli utenti? Per i portali, WAF-MFA può essere utile.
• Quali profili di protezione sono attivi? Eccezioni troppo ampie indeboliscono WAF, profili troppo rigidi possono rompere le applicazioni.
• Come viene registrato e testato? Log Viewer, reverseproxy.log e log backend devono essere noti prima del go-live.

Per i certificati, è necessario chiarire presto se importare un certificato esistente con chiave privata e catena CA, 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.

Configurare la regola WAF

Struttura di base di una regola WAF

Una pubblicazione WAF è composta da diversi elementi:

• Hosted address: indirizzo IP pubblico o alias su cui i client raggiungono l’applicazione.
• Listening port: porta pubblica, di solito 80 o 443.
• Domains: hostname che devono corrispondere alla regola WAF.
• HTTPS certificate: certificato per l’hostname pubblicato.
• Web server: oggetto web server creato in precedenza con host, protocollo, porta e impostazioni di connessione.
• Allowed client networks: reti sorgente che possono accedere.
• Blocked client networks / countries: fonti o paesi che vengono bloccati.
• Protection policy: protezione WAF contro attacchi web tipici.
• Authentication: autenticazione opzionale a monte tramite il firewall.

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

Importante: una regola WAF non è una normale regola firewall con NAT dietro. Crea una pubblicazione Reverse Proxy. Per questo Hosted address, Listening port, Domains, certificato, Protected server e Allowed client networks devono combaciare. Se uno di questi campi non è corretto, l’errore appare spesso come problema di certificato, DNS o backend.

Creare una regola WAF

Il percorso del menu è:

Rules and policies > Firewall

Procedura:

La seguente procedura numerata con Protected servers si applica solo a SFOS 22 e rimane invariata per questa versione. Le regole WAF supportano solo IPv4. L’azione esterna della regola Protect with web server protection non va confusa con l’azione specifica per percorso Action > Protect in Traffic routing su SFOS 23; per SFOS 23 si applica la guida separata riportata subito dopo questa procedura.

1. Selezionare IPv4.
2. Aprire Add firewall rule.
3. Selezionare New firewall rule.
4. Assegnare un nome descrittivo alla regola.
5. Impostare consapevolmente Rule position, soprattutto se esistono già regole WAF più generiche o vecchie pubblicazioni.
6. In Action, scegliere l’opzione Protect with web server protection.
7. Se non è necessario un modello speciale, lasciare Preconfigured template su None.
8. In Hosted server details, definire l’indirizzo pubblico, la porta di ascolto, HTTPS, certificato e domini.
9. In Protected servers, selezionare l’oggetto web server adatto o crearlo prima in Web server > Web servers.
10. Impostare consapevolmente Allowed client networks. Per siti web pubblici può essere necessario Any IPv4; per portali è meglio una restrizione.
11. Se necessario, impostare Blocked client networks o Blocked countries.
12. Verificare consapevolmente Protection, Intrusion prevention e Traffic shaping nelle policy avanzate.
13. Salvare la regola e testare esternamente.

SFOS 23: pubblicare percorsi in Traffic routing

1. In Rules and policies > Firewall, creare o modificare una regola IPv4. Continuare a scegliere Protect with web server protection come Action esterna e configurare correttamente indirizzo pubblico, porta, certificato HTTPS e domini. Una nuova regola contiene per impostazione predefinita / con Block: senza un’ulteriore configurazione del routing, le richieste vengono respinte e l’applicazione non viene pubblicata.
2. In Traffic routing, usare Edit o Add new path per modificare o aggiungere il percorso specificamente previsto. In Action, scegliere esplicitamente Protect e assegnare gli oggetti backend necessari da Web server > Web servers. Un template crea percorsi con Protect, ma richiede comunque l’assegnazione dei backend.
3. Per ogni percorso protetto, assegnare la Authentication Policy prevista nel campo Authentication e impostare consapevolmente Allowed client networks, senza lasciarlo vuoto. Verificare in modo mirato Blocked client networks, Blocked countries e Block IP addresses of unknown country-origin; per gli indirizzi di origine di paesi sconosciuti, considerare anche il rischio di bloccare il proprio accesso.
4. Se devono essere pubblicati solo determinati percorsi, mantenere consapevolmente / con Block come route di fallback. Impostare / su Protect solo se si intende pubblicare l’intera applicazione; verificare esplicitamente backend, autenticazione, restrizioni di accesso e parti dell’applicazione rese così raggiungibili. I percorsi più lunghi e specifici vengono valutati per primi, indipendentemente dall’ordine nella tabella.
5. Distinguere le azioni: Block respinge le richieste per il percorso selezionato e non le inoltra al backend. Protect applica la policy di protezione della regola e le impostazioni di autenticazione e accesso configurate. Redirect invia al client un reindirizzamento alla destinazione configurata, invece di pubblicare un backend. Passthrough crea un tunnel verso il backend senza ispezione WAF e senza applicare la policy di protezione. Protection si applica solo ai percorsi con Protect.
6. Dopo il salvataggio, testare dall’esterno un percorso che deve essere consentito, un percorso bloccato intenzionalmente e un percorso senza una corrispondenza specifica. Se utilizzati, verificare separatamente anche Redirect e Passthrough. Correlare il risultato sul client, Log Viewer, reverseproxy.log e i log del backend in base alla stessa richiesta e allo stesso momento.

Regole esistenti dopo l’aggiornamento: secondo la documentazione Sophos, durante l’aggiornamento a SFOS 23 le regole WAF esistenti vengono automaticamente impostate su Protect; le route specifiche per percorso esistenti vengono mantenute. Questo comportamento è diverso sia dall’impostazione predefinita / con Block delle nuove regole, sia dalla precedente migrazione delle ModSecurity Protection Policies in SFOS 18. Dopo l’aggiornamento, verificare comunque per ogni percorso azione, backend, autenticazione, restrizioni di accesso e route effettiva ed eseguire un collaudo esterno; la migrazione automatica non sostituisce il collaudo.

Contesto del tutorial: il tutorial Sophos sulla protezione di un server web dagli attacchi continua a usare la procedura con Protected servers e indica IPv4 or IPv6, sebbene il riferimento delle regole WAF limiti WAF a IPv4. Il tutorial non è quindi una guida completa al routing di SFOS 23. Per la configurazione attuale si applicano IPv4 e le azioni esplicite per percorso descritte sopra.

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.

Se Allowed client networks resta vuoto, la regola WAF non funziona correttamente; il browser può ricevere un 400 Bad Request. Per un’applicazione pubblica Any IPv4 è possibile, ma non automaticamente corretto. Per portali admin, portali partner o strumenti interni si dovrebbero prima valutare reti sorgente fisse, limitazione per paese, WAF-MFA, VPN o ZTNA.

I conflitti di porta devono essere chiariti prima del salvataggio. WebAdmin e User Portal richiedono ciascuno una porta univoca. WAF e VPN Portal utilizzano entrambi TCP; se utilizzano la stessa porta, le relative Hosted address o gli indirizzi IP WAN devono quindi essere diversi. WAF può differenziarsi da SSL VPN tramite l’indirizzo IP WAN, la porta o il protocollo, poiché SSL VPN supporta TCP o UDP. Un FQDN o nome SNI diverso da solo non è sufficiente per separare questi listener. Se un altro servizio o una vecchia pubblicazione DNAT è già in ascolto su un IP pubblico, l’assegnazione deve essere verificata per indirizzo IP, porta e protocollo prima della messa in produzione.

Go-live e collaudo

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.

• Client esterno: verificare risoluzione DNS, certificato, stato HTTP, login e percorsi importanti. L’applicazione dovrebbe aprirsi tramite l’hostname pubblico senza avviso certificato.
• Sophos Firewall: verificare Log Viewer, regola WAF, reverseproxy.log e firme bloccate. La regola WAF corretta dovrebbe elaborare l’accesso e i log dovrebbero mostrare richieste consentite o bloccate con motivazione.
• Backend web server: verificare access log, error log, sessione applicativa e X-Forwarded-For. La richiesta dovrebbe raggiungere vHost o percorso corretto, e la logica dell’IP client deve essere compresa.

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.

Protezione e accesso sicuri

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.
• Il certificato HTTPS selezionato può compilare automaticamente l’elenco dei domini nella regola WAF o sovrascrivere voci dominio esistenti.
• Con più nomi host sullo stesso IP, il firewall utilizza SNI.
• I certificati wildcard sono possibili, ma devono essere documentati accuratamente.
• I domini wildcard vengono usati solo dopo le regole di dominio più specifiche.
• Gli underscore nel label sinistro del dominio non sono un nome DNS pulito e andrebbero evitati per i domini WAF.
• 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.

I Domains nella regola WAF dovrebbero quindi combaciare esattamente con DNS e certificato. I wildcard possono essere utili, ma non dovrebbero sostituire un concetto di pubblicazione pulito. Se più applicazioni usano hostname simili, serve una documentazione chiara di regole e certificati, altrimenti diventa difficile capire in seguito quale regola WAF abbia effettivamente matchato. È utile un test con un sottodominio volutamente non corrispondente: così si vede se risponde la regola specifica, una regola wildcard o nessun web server virtuale corrispondente.

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

In Web server > General settings si trovano ulteriori impostazioni globali per Web Server Protection, tra cui controllo delle versioni TLS e protezione contro schemi HTTP DoS lenti. Queste impostazioni non valgono solo per una singola regola. Le modifiche devono quindi essere pianificate consapevolmente e coordinate con le pubblicazioni WAF esistenti.

SFOS 23: personalizzare in modo mirato il profilo worker

In Web server > General settings > Worker customization, il firewall calcola i valori predefiniti in base alle risorse CPU e RAM disponibili; questi valori sono adatti alla maggior parte delle installazioni. Valori più elevati possono influire negativamente sulle prestazioni WAF e sulle risorse di sistema. Attivare quindi Use custom worker profile solo dopo aver verificato la necessità e valutato gli effetti. Prima della modifica, documentare i valori precedenti e lo stato calcolato o personalizzato, creare un backup della configurazione e pianificare una finestra di manutenzione e il rollback esattamente a quello stato precedente. Questa personalizzazione non modifica Maximum sessions.

• Start servers: numero di processi worker avviati all’avvio del server web.
• Server limit: numero massimo di processi worker eseguibili contemporaneamente.
• Minimum spare threads: numero minimo di thread inattivi mantenuti disponibili per nuove richieste.
• Maximum spare threads: numero massimo di thread inattivi prima che quelli in eccesso vengano rimossi.
• Threads per child: numero massimo di thread worker per processo worker.
• Asynchronous request worker factor: controlla lo scaling dei processi worker per connessioni e richieste asincrone.

Per l’autenticazione Reverse Proxy basata su form, il campo globale Maximum sessions limita le sessioni utente simultanee di tutte le regole WAF che usano questo metodo di autenticazione. Il valore predefinito è 25,000 e l’intervallo consentito va da 100 a 100,000. Raggiunto il limite, il firewall chiude le sessioni vecchie o scadute per accettarne di nuove. Non è quindi una capacità per singola regola: dimensionarla sulle connessioni simultanee delle applicazioni interessate e, dopo una modifica, verificare login, logout e cambio di sessione.

In Slow HTTP protection, Soft limit è il timeout inizialmente concesso per ricevere l’header della richiesta. Hard limit imposta il limite massimo assoluto. Extension rate stabilisce quanti byte aggiuntivi ricevuti estendono di un secondo il soft limit. Questi tre valori devono essere testati insieme e con client realmente lenti; un solo valore troppo permissivo può indebolire inutilmente la protezione.

Per Slow HTTP protection, limitare le eccezioni al minimo necessario, cioè a un singolo indirizzo IP o a una rete ristretta. Sophos supporta in questo punto oggetti host IP e di rete, ma non intervalli IP né elenchi di host. Anche la Minimum TLS version è globale; prima di renderla più restrittiva, testare i client meno recenti e tutte le applicazioni pubblicate mediante una connessione esterna reale.

Come impostazioni TLS globali, SFOS offre tra le altre TLS v1.2 (wide compatibility), TLS v1.2 (strict) e TLS v1.3. Modificare Custom protocol configuration e Custom cipher configuration solo con valori OpenSSL documentati e testati; le cipher suite TLS 1.3 sono gestite separatamente. Valori non validi possono impedire l’avvio del servizio Apache gestito da SFOS e quindi di Web Server Protection. Il piano di modifica deve includere i valori precedenti, un backup della configurazione, una finestra di manutenzione e un accesso amministrativo alternativo. Successivamente, testare tutte le pubblicazioni WAF e controllare reverseproxy.log; se il servizio non si avvia, ripristinare gli ultimi valori personalizzati invece di provare altre varianti in produzione.

Per le Protection Policies è importante il modo operativo. Reject blocca e genera eventi visibili in Log Viewer per le regole WAF. Monitor registra soltanto, ma questi messaggi WAF non compaiono necessariamente nel Log Viewer; in quel caso bisogna controllare reverseproxy.log. Monitor può essere utile in un pilota, ma per la protezione produttiva deve essere chiaro se gli attacchi vengono solo osservati o realmente respinti.

Il Common threat filter utilizza quattro Filtering Strengths. Level 1 è il più permissivo e non viene registrato; da Level 2 in poi, i match compaiono in /log/reverseproxy.log, mentre aumenta anche il rischio di falsi positivi. Le singole regole si escludono in Skip filter rules solo tramite la Rule ID verificata nel log. Disattivare ampiamente un’intera categoria o un livello superiore non sostituisce questa analisi.

Static URL hardening distingue maiuscole e minuscole, non accetta wildcards e non aiuta con URL generate dinamicamente da JavaScript. Form hardening confronta la struttura del form e supporta moduli fino a 8,000 byte. Se contenuti binari vengono serviti erroneamente come HTML o XML, entrambe le funzioni possono danneggiarli; si corregge prima il Content-Type del backend invece di disattivare ampiamente la protezione.

Per la scansione antivirus, il limite di dimensione si applica al volume totale caricato in una richiesta, non a ogni singolo file. Il Request size limit aggiuntivo per il body HTTP va da 1 a 1,024 MB e ha un valore predefinito di 10 MB. HTTP Strict Transport Security aggiunge l’header HSTS solo se la regola WAF utilizza Redirect HTTP; MIME-type sniffing protection imposta X-Content-Type-Options: nosniff. Upload, download e header devono quindi essere testati con l’applicazione reale.

IPS in una regola WAF va valutato separatamente. Sophos applica IPS per WAF solo quando la comunicazione tra firewall e web server avviene via HTTP. Se il backend è collegato via HTTPS, non bisogna aspettarsi automaticamente che una policy IPS selezionata abbia lo stesso effetto.

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.

Rivalidare le Protection Policies migrate

Da SFOS 18, Web Server Protection utilizza OWASP ModSecurity Core Rule Set 3.0. Durante la migrazione delle Protection Policies precedenti, le vecchie categorie sono state unite, i Rule IDs sono stati rimappati e sono state introdotte le Filtering Strengths. Se una delle categorie unite era attiva, la nuova categoria comune può quindi risultare attiva anche se un’altra parte era precedentemente disattivata.

Dopo un aggiornamento di questo tipo non basta confrontare il nome della policy. Le categorie attive, le eccezioni e le Filtering Strengths devono essere confrontate con la documentazione precedente. Seguono test positivi e negativi controllati con traffico applicativo reale e la verifica di Log Viewer e reverseproxy.log. La policy migrata è validata solo quando le richieste legittime continuano a funzionare e vengono rilevati gli attacchi di test previsti.

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.

Il firewall non valuta i percorsi in base all’ordine nella tabella, ma dà priorità ai percorsi più lunghi e quindi più specifici rispetto alla route di fallback. Questa corrispondenza deve essere testata in modo mirato. Solo per SFOS 22: per il percorso del sito web che lo richiede, è possibile attivare la casella WebSocket passthrough; il traffico WebSocket viene inoltrato senza protezione WAF, poiché i dati WebSocket non possono essere verificati come il normale traffico HTTP. Per SFOS 23: in Traffic routing, configurare esclusivamente il percorso WebSocket necessario con Action > Passthrough e il backend previsto. Questo tunnel opera senza ispezione WAF e senza policy di protezione; gli altri percorsi dell’applicazione rimangono su Protect. Non impostare mai l’intero portale su Passthrough come workaround. Testare separatamente l’upgrade della connessione, il trasferimento dei dati e la riconnessione. Da ciò non è possibile dedurre nulla sull’applicazione di MFA con Passthrough; se è richiesta l’autenticazione, chiarire le responsabilità con il responsabile dell’autenticazione.

Solo per SFOS 22: nella procedura con Protected servers, il percorso predefinito / inoltra le richieste senza una corrispondenza più specifica al server standard assegnato. Se questa route predefinita viene rimossa, il firewall respinge tali richieste con 404 Not Found. Per SFOS 23: le richieste senza una corrispondenza più specifica utilizzano l’azione di /; per le nuove regole, l’impostazione predefinita è Block. Mantenere consapevolmente questa route di fallback se devono essere pubblicati solo singoli percorsi. Protect per / è sensato solo quando si intende pubblicare l’intera applicazione e richiede una verifica delle parti aggiuntive rese raggiungibili. Per SFOS 23 non è garantito un codice di stato 404 fisso: la risposta di Block viene configurata tramite Response code.

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.

Raggiungere backend WAF remoti tramite SD-WAN

Se il web server protetto non si trova nella rete locale del firewall, routing e SD-WAN vanno verificati con particolare attenzione. Per backend tramite collegamenti di sede, MPLS o route-based IPsec può servire una SD-WAN Route adatta affinché il firewall raggiunga in modo affidabile il Protected Server e il percorso di ritorno sia corretto. Con route-based IPsec è inoltre importante: WAF tramite route-based IPsec con Traffic Selectors per subnet non è supportato da Sophos; le connessioni Any-to-Any sono l’alternativa documentata.

Il progetto documentato da Sophos parte da una regola WAF funzionante e da un tunnel route-based raggiungibile. In Routing > Gateways si crea un oggetto gateway per il percorso remoto con l’indirizzo IP del peer, l’interfaccia XFRM indirizzata e un host di monitoraggio affidabile dietro il peer. Solo allora si crea in Routing > SD-WAN routes la route mirata per il traffico proxy WAF:

1. Destination networks corrisponde all’interfaccia WAN pubblica o alla Hosted address attraverso la quale il client raggiunge la regola WAF.
2. Services contiene il Listening Port esterno della regola WAF. Se è diverso dalla porta interna del backend, qui va utilizzata esplicitamente la porta esterna.
3. In Primary gateway si seleziona il gateway XFRM creato in precedenza.
4. Se più pubblicazioni utilizzano lo stesso gateway, la stessa SD-WAN Route può contenere più indirizzi WAN pubblici e Listening Ports. Per gateway diversi sono necessarie route separate.

Il collaudo separa quindi i livelli: il test esterno deve corrispondere alla regola WAF prevista; nel Log Viewer si correlano regola WAF, errori del reverse proxy e orario; sul firewall devono essere attivi interfaccia XFRM, monitor del gateway e SD-WAN Route; infine il server backend deve ricevere la richiesta e rispondere attraverso il percorso previsto. Un tunnel verde da solo non dimostra né il match SD-WAN né la raggiungibilità del backend.

Operatività e troubleshooting

Errori tipici

• Nome DNS pubblico punta all’IP sbagliato: la regola WAF non viene mai raggiunta.
• Il certificato non corrisponde all’hostname: i browser mostrano errori di certificato o il matching SNI non combacia.
• Hosted address sbagliata scelta: il firewall matcha un’altra regola o nessun traffico WAF.
• Allowed client networks vuoto: la regola non funziona come previsto.
• Limite regole WAF non considerato: ulteriori pubblicazioni non possono più essere rappresentate in modo pulito.
• Versione Exchange successiva al 2013 pianificata con template WAF: il template non rientra nel limite WAF supportato.
• Conflitto di porta con User Portal, VPN Portal o altro servizio: l’applicazione non è raggiungibile o risponde un servizio del firewall.
• Backend non raggiungibile internamente: i client esterni ricevono errori anche se DNS e certificato sono corretti.
• Timeout backend impostato male: risposte lunghe terminano con errori anche se l’applicazione è fondamentalmente raggiungibile.
• Backend su VPN o SD-WAN senza rotta adatta: la regola WAF matcha, ma il Protected Server non viene raggiunto in modo affidabile.
• Route-based IPsec con Traffic Selectors verso il backend: WAF su questo percorso non è supportato.
• Eccezione WAF troppo ampia: l’efficacia della protezione diminuisce inutilmente.
• Applicazione WebDAV pubblicata tramite WAF: l’applicazione non funziona in modo affidabile o non è supportata.
• Il percorso URL contiene %2F: WAF risponde con 404 Not Found, anche se la risorsa è raggiungibile direttamente sul backend. %2F è la forma codificata in URL di una barra / e deve essere distinta da un normale errore 404 del backend.
• Modifica regola senza finestra di manutenzione: le connessioni esistenti possono interrompersi al riavvio delle regole WAF.
• Vecchia regola DNAT e nuova regola WAF competono: non è chiaro quale pubblicazione gestisce il traffico.

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. Il Protected Server si trova dietro una route, SD-WAN Route o connessione VPN che dal punto di vista del firewall combacia davvero?
8. Esiste una regola WAF più generale che corrisponde prima?
9. L’accesso viene visualizzato nel Log Viewer come consentito, bloccato o scartato?
10. Ci sono indicazioni in /log/reverseproxy.log?
11. La Protection Policy è impostata su Monitor o Reject?
12. Il timeout dell’oggetto web server è adatto all’applicazione?

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.

WAF risponde con 404 quando il percorso contiene %2F

Un problema specifico riguarda gli URL che contengono una barra codificata. Una richiesta come https://portal.example.com/api/files/project%2Freport.pdf può restituire 404 Not Found tramite Sophos WAF, anche se la risorsa esiste quando viene richiamata direttamente sul backend. Sophos tiene traccia di questo comportamento con il riferimento NC-159041 e attualmente non indica né una versione SFOS interessata o corretta né un workaround supportato.

Per circoscrivere la causa, occorre confrontare la stessa richiesta tramite WAF e direttamente sul backend. Sono importanti l’URL esatto e l’orario del test:

1. Verificare se il percorso contiene effettivamente %2F. Una normale barra / o l’assenza del percorso predefinito rappresentano un problema diverso.
2. Confrontare l’orario nel Log Viewer, in /log/reverseproxy.log e nel log di accesso del server web.
3. Se sul backend non compare alcuna voce corrispondente, probabilmente la richiesta è stata respinta prima del server web. Un test diretto sul backend consente inoltre di confermare che la risorsa esiste.

Un’eccezione WAF ampia non risolve in modo mirato questo problema e ridurrebbe inutilmente la protezione. Non si deve neppure modificare la configurazione Apache gestita da SFOS: la gestione restrittiva delle barre codificate aiuta a impedire l’elusione dei controlli basati sul percorso o sull’accesso.

La soluzione più pulita è fare in modo che l’applicazione o il produttore generi URL senza barre codificate. Se non è possibile, occorre valutare consapevolmente un’altra modalità di pubblicazione, come DNAT, un reverse proxy adatto o l’accesso privato, rispetto alla perdita della protezione WAF. Per applicazioni non modificabili, Sophos Support dovrebbe verificare la build SFOS specifica e il caso d’uso. Le forme project%2Freport.pdf e project/report.pdf sono solo un modello diagnostico e non sono automaticamente equivalenti dal punto di vista funzionale.

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