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.

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.

Le regole WAF sono inoltre orientate a pubblicazioni IPv4. Se un’applicazione deve essere necessariamente pubblicata tramite IPv6, il design va verificato separatamente. 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.

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, 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 rules

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. Attivare Log firewall traffic se la regola deve essere tracciabile in Log Viewer e nei report.
9. In Hosted server details, definire l’indirizzo pubblico, la porta di ascolto, HTTPS, certificato e domini.
10. In Protected servers, selezionare l’oggetto web server adatto o crearlo prima in Web server > Web servers.
11. Impostare consapevolmente Allowed client networks. Per siti web pubblici può essere necessario Any IPv4; per portali è meglio una restrizione.
12. Se necessario, impostare Blocked client networks o Blocked countries.
13. Verificare profilo di protezione, IPS e opzioni avanzate.
14. 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.

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. A seconda della Hosted address, WAF può usare la stessa porta di SSL VPN, ma non la stessa porta dello User Portal. Se WebAdmin, VPN Portal, User Portal o una vecchia pubblicazione DNAT sono già in ascolto su un IP pubblico, l’assegnazione deve essere univoca. Altrimenti l’errore sembrerà poi un problema WAF anche se risponde un’altra funzione.

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.

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.

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.

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. Sophos dà priorità ai percorsi più lunghi e quindi più specifici. I percorsi specifici devono quindi 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.

Il percorso predefinito / dovrebbe rimanere impostato consapevolmente. Se viene rimosso, i percorsi non corrispondenti non vengono inoltrati a un server standard, ma rifiutati con 404 Not Found. Può essere voluto, ma in caso di errore sembra rapidamente un problema backend.

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.

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; connessioni Any-to-Any sono la via documentata.

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.
• 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.

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