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 l’hardening 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.

WAF non è però 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.

PHP2Shell – situazione al 24 ottobre 2026: Per CVE-2026-109618 e CVE-2026-109619, nell’advisory del 22 ottobre, versione 4 Sophos non indica una protezione specifica offerta dalla WAF di Sophos Firewall. Gli ambienti di esecuzione PHP vulnerabili sul backend devono essere aggiornati; la pubblicazione tramite WAF non sostituisce questo aggiornamento. Le firme IPS disponibili dal 22 ottobre servono a rilevare tentativi di attacco. Occorre verificare separatamente se una policy IPS adeguata ispeziona il percorso effettivo dei dati e quale azione esegue; per questi controlli è utile la guida IPS. L’assenza di un allarme non dimostra che il sistema sia correttamente aggiornato.

Decisione prima della pubblicazione

Prima di creare una regola WAF, occorre chiarire se WAF, DNAT, VPN o ZTNA è adatto all’applicazione. Questa decisione è più importante della schermata di configurazione del firewall, perché determina la superficie di attacco, la gestione operativa e il troubleshooting.

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 delle identità e applicazioni private, quando l’accesso deve essere fortemente controllato o non deve essere pubblico.

Se si desidera soltanto 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 alla cieca 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ò realizzare una pubblicazione, ma se in seguito sarà possibile gestirla, testarla e rimuoverla in sicurezza. 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 restrizioni sulle sorgenti 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 verificati insieme.
Applicazione web con WebDAV o protocollo speciale: non usare automaticamente WAF. Testare le funzioni supportate, il comportamento dei client e una modalità di pubblicazione alternativa.
Applicazione solo per utenti interni: valutare VPN, ZTNA o WAF con forti restrizioni. La raggiungibilità pubblica va messa in discussione criticamente.

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

Pianificazione e prerequisiti

Una pubblicazione WAF stabile richiede DNS, certificato, raggiungibilità del backend, logging e un piano di rollback. Questi aspetti dovrebbero essere definiti prima della configurazione.

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 sorgente, 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 host IP o FQDN. Per i backend sono possibili HTTP o HTTPS; le porte standard sono 80 e 443. Se il server web backend fornisce risposte lunghe o richiede keep-alive, Keep alive e Timeout devono essere verificati consapevolmente invece di essere accettati senza valutarli.

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 accesso e può ridurre le prestazioni. Questa opzione va quindi usata solo per circoscrivere un problema in modo mirato e poi riportata allo stato precedente documentato.

Inoltre, i limiti della Web Server Protection dovrebbero essere considerati fin dall’inizio. Sophos indica, tra l’altro, un limite di 60 regole WAF per firewall. Questo basta per molti ambienti, ma con numerosi portali clienti, tenant, sistemi di test o hostname separati può diventare rilevante prima del previsto. In quel caso non bisognerebbe creare alla cieca altre regole singole, ma verificare lo schema dei nomi, i percorsi, i server web virtuali e le 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 i profili di protezione realmente necessari con l’architettura Microsoft attuale; per un’applicazione moderna, in caso di dubbio lasciare Preconfigured template su None.

Creare un oggetto backend con un esempio chiaro

Il nome pubblico e il nome del backend svolgono funzioni diverse. Nell’esempio seguente, gli utenti aprono portal.example.com; il firewall raggiunge il server tramite backend.example.com. Entrambi i nomi sono segnaposto e devono essere sostituiti con i propri nomi DNS. Dal punto di vista del firewall, il nome del backend deve risolversi nell’indirizzo del server effettivo, non di nuovo nel proprio indirizzo WAF pubblico: altrimenti non si ottiene un percorso valido verso il backend.

In Hosts and services > FQDN host > Add, creare un oggetto denominato WAF_Backend_Portal con FQDN backend.example.com e salvarlo. In alternativa, usare un oggetto host IP per un server backend con indirizzo fisso. Secondo la documentazione del prodotto, gli host FQDN offrono una compatibilità più ampia con i server; la risoluzione DNS e il server di destinazione devono comunque essere verificati.
In Web server > Web servers > Add, creare un oggetto web server WAF_Portal_Server e selezionare l’oggetto backend in Host.
Impostare Type e Port in base al listener effettivo del backend: nell’esempio HTTPS, HTTPS e 443; per un backend HTTP, HTTP e, ad esempio, 80. La porta di ascolto esterna viene definita solo nella regola WAF e non deve necessariamente coincidere con la porta del backend. Per un backend HTTP, proteggere consapevolmente il segmento non crittografato; un frontend HTTPS da solo non crittografa questo segmento.
Attivare Keep alive solo se il server web supporta il riutilizzo delle connessioni. Valutare inizialmente Timeout con il valore predefinito di 300 secondi. Si intende il tempo di attesa dei dati da o verso il backend, non una durata massima complessiva fissa per ogni richiesta: finché i dati arrivano in tempo, una risposta può durare più a lungo. In caso di 502, verificare quindi i log del backend e le pause nel trasferimento dei dati, anziché aumentare subito il valore.
Nel normale funzionamento, non attivare Disable backend connection pooling come ottimizzazione delle prestazioni. Salvare l’oggetto, controllarne l’assegnazione alla regola WAF o al percorso Protect di SFOS 23 e verificare un accesso rappresentativo al backend.

Pianificare la pubblicazione WAF prima della configurazione

Una regola WAF non dovrebbe essere pianificata solo nella schermata di configurazione. Prima deve essere chiaro se Sophos Firewall deve solo pubblicare l’applicazione o se deve anche gestire autenticazione, profili di protezione, regole per paese e logging.

Queste domande sono importanti prima di una pubblicazione in produzione:

È 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 compromettere il funzionamento delle applicazioni.
Come vengono gestiti logging e test? Log Viewer, reverseproxy.log e log del 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

La regola WAF vera e propria è composta da indirizzo pubblico, hostname, certificato, server di destinazione, sorgenti consentite e profilo di protezione. Questi campi dovrebbero essere considerati nel loro insieme, non come opzioni isolate.

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: sorgenti 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:

Le nuove regole sono attivate per impostazione predefinita. Per una pubblicazione già predisposta ma non ancora autorizzata, verificare quindi esplicitamente lo stato della regola e lasciarla disattivata fino al go-live pianificato. Rule position offre Top o Bottom; Rule group assegna la regola a un gruppo esistente o creato tramite Create new. Automatic utilizza il primo gruppo corrispondente in base al tipo di regola e alle zone di origine e destinazione. Il raggruppamento è un ausilio alla gestione, non un sostituto della verifica degli accessi.

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.

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

SFOS 23: pubblicare percorsi in Traffic routing

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.
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 modello crea percorsi con Protect, ma richiede comunque l’assegnazione dei backend.
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.
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.
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.
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.

Il percorso predefinito può essere modificato, clonato o eliminato. La clonazione non comporta l’autorizzazione della nuova configurazione: verificare nuovamente azione, backend, autenticazione e origini per la nuova associazione. Non rimuovere accidentalmente / quando costituisce la route di fallback impostata intenzionalmente per bloccare le richieste.

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. Le modifiche alle regole WAF in produzione dovrebbero quindi essere effettuate in una finestra di manutenzione o almeno con piena consapevolezza delle conseguenze.

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 amministrativi, portali partner o strumenti interni si dovrebbero prima valutare reti sorgente fisse, limitazioni 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 testata per indirizzo IP, porta e protocollo prima del go-live.

La porta predefinita del User Portal è 4443; i listener dei portali e i relativi limiti sono descritti nella panoramica dei portali.

SFOS 23: definire in modo preciso le risposte Block e Redirect

Un’azione di routing può raggruppare più voci in Paths quando tutte richiedono lo stesso trattamento. In Traffic routing > Add new path, selezionare i percorsi e l’azione, compilare i campi specifici dell’azione e salvare la voce relativa ai percorsi. Utilizzare voci separate in presenza di backend, regole di accesso o destinazioni di reindirizzamento differenti.

Per Block, Response code determina la risposta. Un esempio è /admin/ con Forbidden (403), mentre / rimane su Block come route di fallback. La selezione documentata comprende da 400 a 417, oltre a 422, 423, 424 e 426. Scegliere il codice in base al significato desiderato: 403 indica un accesso negato, 404 contenuti non trovati. La scelta del codice 401 non configura una Authentication Policy; il solo codice di stato non costituisce una protezione tramite autenticazione. Durante il collaudo, verificare lo stato configurato e l’assenza di una corrispondente richiesta al backend.

Per Redirect, oltre a Paths e Action, la configurazione comprende i campi Response code, Protocol, Host, Path e Port. Esempio: /old-portal/ con Temporary Redirection (307), Protocol HTTPS, un host FQDN per portal.example.com, Path /portal/ e Port 443. Sostituire nomi e percorsi con quelli della propria applicazione di destinazione. 307 indica un reindirizzamento temporaneo che mantiene il metodo della richiesta; è adatto a un progetto pilota controllato se la destinazione gestisce lo stesso metodo. Testare comunque separatamente browser e client API, in particolare le richieste POST. La destinazione /portal/ deve essere a sua volta raggiungibile e protetta, ad esempio tramite un percorso Protect appropriato; un semplice reindirizzamento non vi crea alcuna configurazione di backend o di accesso.

La selezione offre 300, 301, 302, 303, 304, 305, 307 e 308. Non tutti i codici disponibili rappresentano un normale reindirizzamento a una nuova pagina: 304 descrive la validazione della cache. 305 è deprecato per motivi di sicurezza e non è consigliato per applicazioni pubbliche. Utilizzare 301 o 308 solo quando si intende effettuare un passaggio permanente e considerare il comportamento di client e cache in caso di ripristino. Le porte predefinite della destinazione sono 80 per HTTP e 443 per HTTPS. Redirect non esegue alcuna ispezione WAF e non invia la richiesta a un backend di questa route; verificare quindi sul client lo stato e la destinazione del reindirizzamento e, successivamente, la protezione dell’applicazione di destinazione.

Adattare in modo mirato l’header Host, HTML e la compressione

Le Advanced settings di una regola WAF aiutano a risolvere problemi specifici del reverse proxy. Non sono opzioni da attivare tutte indiscriminatamente:

Pass host header inoltra al backend l’header Host richiesto dal client. Quando un server ospita più siti web, questo può consentire di selezionare l’host virtuale corretto. Configurare il vHost del backend in modo che corrisponda al nome pubblicato e verificare nel log di accesso che non risponda un altro sito web.
Rewrite HTML adatta i link nelle pagine restituite. Ad esempio, se un link assoluto punta a http://backend.example.com/, mentre l’applicazione viene pubblicata tramite il nome pubblico, può essere necessaria una riscrittura. In presenza di nomi host pubblici già corretti o di link esclusivamente relativi, normalmente non è necessaria. L’elaborazione riguarda i Content-Type text/* e *xml*; i download binari devono essere forniti con il Content-Type corretto, altrimenti rischiano di essere danneggiati. Successivamente, testare separatamente link pubblici, download e funzioni dell’applicazione.
Rewrite cookies riscrive i cookie nelle pagine restituite. In caso di problemi di sessione, esaminare i cookie effettivamente impostati, il login e il logout, senza confondere la riscrittura dei cookie con Cookie signing: la riscrittura e la protezione contro la manipolazione svolgono compiti diversi.
Disable compression support è un ausilio mirato per pagine visualizzate in modo errato o errori di Content-Encoding. Il firewall richiede quindi al backend dati non compressi e li restituisce senza compressione, indipendentemente dall’encoding richiesto. Documentare lo stato precedente, ripetere l’accesso alla stessa pagina e annullare l’impostazione se non risolve il problema.

Alcune porte sono riservate ai servizi di sistema anche quando il servizio corrispondente non viene utilizzato. Il solo fatto che un listener sia libero non rende una di queste porte disponibile per WAF; la panoramica Porte riservate di Sophos Firewall aiuta nella pianificazione. Traffic shaping assegna alla pubblicazione larghezza di banda e priorità in funzione del tempo. Si tratta di una decisione operativa, non di un’ulteriore protezione applicativa; con la policy attivata, verificare upload e download anche sotto un carico rappresentativo.

Go-live e collaudo

Dopo il salvataggio della regola, la pubblicazione non è ancora completa. Solo test esterni, log adeguati e un rollback chiaramente definito rendono la modifica pronta per la produzione.

Pianificare il go-live e il rollback

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

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, lo stesso IP pubblico o lo stesso nome host.
Disattivare le vecchie regole DNAT o documentare chiaramente perché non competono con la regola WAF.
Ridurre il TTL DNS prima del passaggio se il nome host pubblico viene trasferito da una vecchia pubblicazione a WAF.
Predisporre un accesso di test esterno, senza testare solo dalla LAN interna.
Definire i casi di test: pagina iniziale, login, upload, download, percorso API, WebSocket, logout e messaggio di errore.
Stabilire dove devono comparire i log: Log Viewer, reverseproxy.log, log di accesso del backend e log degli errori del backend.
Stabilire un criterio di rollback, ad esempio login non possibile, backend non raggiungibile, certificato errato, tasso di errori elevato o parti critiche dell’applicazione non funzionanti.

Durante il passaggio, dovrebbe essere attiva una sola 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 ricostruire. Prima del passaggio in produzione, deve essere chiaro quale regola elabora 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, gli errori del backend, i reindirizzamenti inaspettati, i problemi di sessione e le 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 avvisi sul 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 una motivazione.
Backend web server: verificare log di accesso, log degli errori, sessione applicativa e X-Forwarded-For. La richiesta dovrebbe raggiungere il vHost o il percorso corretto e la logica dell’IP client deve essere compresa.

Per le applicazioni in produzione, è 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 una fonte consentita e, se possibile, da una fonte intenzionalmente 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 venga selezionata un’altra pubblicazione, che manchi il logging o che l’accesso non avvenga tramite il percorso previsto.

Protezione e accesso sicuri

Per le applicazioni web pubbliche, WAF è solo un livello di protezione. Certificati, restrizioni sulle fonti, Threat Feeds, profili di protezione e logging del backend devono essere pianificati insieme.

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 in 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. *. è consentito solo all’inizio, ad esempio *.example.com; una regola può contenere più domini wildcard.
Gli underscore nell’etichetta più a sinistra del dominio non costituiscono un nome DNS corretto e andrebbero evitati per i domini WAF.
Il backend può utilizzare un nome interno diverso se l’header 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 sulla stessa porta, con HTTPS il firewall decide in base a SNI e nome host quale regola WAF è appropriata.

I Domains nella regola WAF dovrebbero quindi corrispondere esattamente a DNS e certificato. I wildcard possono essere utili, ma non dovrebbero sostituire un progetto di pubblicazione ben definito. 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 gestito la richiesta. È 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.

Il nome dell’oggetto certificato può contenere solo caratteri alfanumerici del set di caratteri US-ASCII; non va confuso con il nome DNS presente nel certificato. Dopo la selezione, controllare i Domains inseriti automaticamente e, se necessario, modificarli, aggiungerli o eliminarli. HTTPS rende il listener raggiungibile tramite HTTPS, non anche tramite HTTP. Redirect HTTP reindirizza separatamente gli accessi dalla porta 80 alla porta 443; occorre quindi pianificare anche questi listener e gli eventuali conflitti di porta.

Con un nome di sottodominio non corrispondente, non è detto che venga visualizzata una pagina grafica di blocco. La documentazione mostra, ad esempio, 403 per un accesso a un altro sottodominio. Verificare quindi lo stato HTTP e reverseproxy.log, non solo l’aspetto della pagina nel browser.

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 autonomamente la connessione al backend. Per l’applicazione e i log del server web, quindi, può essere visibile in primo luogo l’indirizzo del firewall.

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

Log delle applicazioni e analisi di sicurezza
Limiti di frequenza o protezione del login a livello applicativo
Analisi degli errori con riferimento all’utente o all’IP di origine
Correlazione SIEM o di monitoraggio
Analisi forense dopo un incidente

È importante il confine di fiducia: un backend dovrebbe trattare tali header 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 gli header provenienti 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 geografica sconosciuta solo se è stato valutato il rischio di bloccare il proprio accesso.
Per i portali, utilizzare anche WAF-MFA o autenticazione a monte.
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 assumono maggiore rilevanza anche per il traffico in entrata e inoltrato, come quello delle 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 ulteriori fonti malevole conosciute o renderle visibili. Tuttavia, ciò non sostituisce la gestione delle patch, un’autenticazione ben configurata e l’hardening delle applicazioni.

In pratica, 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 durante l’esercizio?
Esiste un processo per i falsi positivi, l’inserimento negli elenchi di elementi consentiti e le autorizzazioni di emergenza?
È chiaro chi reagisce ai rilevamenti e se questi vengono solo registrati o se il traffico viene bloccato 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 di produzione, chi gestisce il sistema deve sapere dove visualizzare il rilevamento e come decidere correttamente: attacco reale, falso allarme o applicazione pubblicata in modo errato.

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 il controllo delle versioni TLS e la protezione contro attacchi 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 in base agli accessi simultanei delle applicazioni interessate e, dopo una modifica, verificare login, logout e cambio di sessione.

In Slow HTTP protection, Soft limit è il tempo 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 alla rete più ristretta possibile. 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 un test esterno 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, verificare tutte le pubblicazioni WAF e controllare reverseproxy.log; se il servizio non si avvia, annullare le ultime modifiche ai valori personalizzati e tornare ai valori precedenti documentati invece di provare altre varianti in produzione.

Per le Protection Policies è importante la modalità operativa. Reject blocca e genera eventi visibili in Log Viewer per le regole WAF. Monitor registra soltanto, ma questi messaggi WAF non compaiono necessariamente in Log Viewer; in quel caso bisogna controllare reverseproxy.log. Monitor può essere utile in una fase pilota, ma per la protezione in produzione 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, le corrispondenze 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 indiscriminatamente un’intera categoria o un livello superiore non sostituisce un’analisi accurata.

Static URL hardening distingue maiuscole e minuscole, non accetta wildcard 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; occorre quindi correggere 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 verificati con l’applicazione reale.

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

Le eccezioni dovrebbero essere impostate in modo restrittivo. 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. È preferibile 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.

Creare una Protection Policy e comprenderne l’efficacia

In Web server > Protection policies > Add, assegnare un nome descrittivo, ad esempio WAF_Portal_Protection, configurare le funzioni di protezione necessarie e selezionare Save. Selezionare poi la policy nel campo Protection della regola WAF; in SFOS 23 si applica solo ai percorsi con Protect. Una policy standard esistente, ad esempio per Exchange Autodiscover, dovrebbe essere utilizzata solo per il caso d’uso corrispondente.

Per una fase pilota della propria applicazione, scegliere innanzitutto consapevolmente tra Monitor e Reject. Monitor non blocca e non mostra i relativi messaggi WAF nel Log Viewer; per consultarli è necessario reverseproxy.log. La maggiore visibilità di Reject non deve essere confusa con una compatibilità applicativa già verificata. Pass Outlook anywhere consente ai client Outlook esterni di aggirare la protezione del server web per l’accesso a Exchange. L’opzione non è una soluzione generale di compatibilità per i portali moderni e va lasciata disattivata in assenza di un caso d’uso legacy motivato.

Cookie signing aggiunge a un cookie impostato dal server un secondo cookie contenente un hash ricavato da nome, valore e un segreto noto solo al firewall. Se il client non restituisce la coppia corrispondente, il cookie viene scartato. Questo protegge dalle manipolazioni, ma non sostituisce né sessioni applicative sicure né la corretta configurazione dei cookie sul backend. Dopo l’attivazione, testare login, carrello o altri flussi che dipendono dai cookie.

Con Static URL hardening, il firewall firma i link statici e determina dalla risposta del server quali link successivi siano consentiti. Entry URLs definisce gli URL di ingresso che possono essere raggiunti senza una firma di hardening; per un sito web semplice, / può essere il punto di ingresso. Questo elenco non è un elenco generale di routing. Rispettare maiuscole e minuscole e non inserire wildcard. Le applicazioni con URL generate da JavaScript o deep link legittimi richiedono una verifica separata. Form hardening firma la struttura originale del form e respinge i form manipolati. Restano determinanti il limite di 8,000 byte e un Content-Type HTML/XML corretto.

Il semplice esempio documentato di protezione dagli attacchi utilizza Reject, Static URL hardening con ingresso /, Form hardening, Antivirus, Block clients with bad reputation e Common threat filter. In tale esempio, Cookie signing, Pass Outlook anywhere e Skip remote lookups for clients with bad reputation sono disattivati. Si tratta di un profilo di test per quel flusso specifico, non di una raccomandazione universale né di una prova che i valori predefiniti siano adatti a qualsiasi applicazione. Per un portale moderno, valutare ciascuna di queste opzioni sulla base del traffico applicativo reale. Anche Basic with passthrough, citato nell’esempio, non è una raccomandazione MFA; la modalità client, l’inoltro delle credenziali e i template sono spiegati nell’articolo sull’autenticazione WAF e MFA collegato.

Configurare consapevolmente antivirus e reputazione

In Antivirus, Mode determina se utilizzare uno o due motori di scansione; per la scansione singola, selezionare il motore. Direction specifica upload, download o entrambe le direzioni. Block unscannable content blocca, ad esempio, file crittografati o danneggiati che non possono essere analizzati. Questo rende più rigorosa l’applicazione dei controlli, ma può riguardare anche documenti crittografati legittimi; definire quindi in anticipo i flussi aziendali consentiti e il percorso di assistenza.

Limit scan size limita il volume da analizzare; 0 o un campo vuoto significa che non è previsto un limite di dimensione per la scansione. Esempio: con un limite di scansione di 50 MB e file di 45, 5 e 10 MB in un unico upload, l’ultimo file non viene analizzato. Un upload riuscito non dimostra quindi che ogni file incluso sia stato controllato. Questo limite di scansione va distinto dal Request size limit per l’intero body HTTP: un limite del body più elevato non rende automaticamente analizzabile una maggiore quantità di contenuti. Scegliere i limiti in base agli upload effettivamente necessari, alle risorse e ai requisiti di sicurezza, e verificare gli upload con più file e i contenuti non analizzabili in un ambiente di test autorizzato.

Block clients with bad reputation utilizza informazioni RBL e GeoIP: Sophos SXL per le RBL e MaxMind per GeoIP. Sono documentati anche blocchi per le classificazioni A1 (proxy anonimi o servizi VPN) e A2 (ISP satellitari). Questo può riguardare accessi legittimi dei partner. Skip remote lookups for clients with bad reputation può migliorare le prestazioni, ma modifica la valutazione basata sulle interrogazioni remote; non attivarlo senza una valutazione consapevole e non equipararlo a una allowlist delle fonti.

Valutare il Common threat filter per categoria e livello di protezione

Le categorie rispondono a esigenze diverse e vanno scelte consapevolmente per l’applicazione:

Application attacks: rileva, tra l’altro, accessi non consentiti ai percorsi e tentativi tipici di esecuzione di comandi, anche dopo una possibile intrusione.
SQL injection attacks: verifica gli argomenti delle richieste alla ricerca di comandi SQL incorporati e caratteri di escape.
XSS attacks: verifica gli input alla ricerca di tag script e codice incorporati.
Protocol enforcement: verifica la conformità al protocollo, header tipici come Host e User-Agent, limiti degli argomenti e utilizzo consentito di HTTP. Anche un client legittimo con un comportamento insolito può quindi essere segnalato.
Scanner detection: rileva schemi tipici di bot, crawler e scansioni; gli accessi desiderati dei motori di ricerca o dei sistemi di monitoraggio devono comunque essere testati.
Data leakage: impedisce che informazioni sensibili arrivino al client, ad esempio tramite messaggi di errore del server. Se Application attacks o SQL injection attacks sono attivi, occorre verificare anche questa categoria, perché gli ambiti di rilevamento si sovrappongono.

Filter strength è impostato per default su Level 1 e genera il minor numero di falsi positivi. Level 2 aggiunge, ad esempio, espressioni regolari per SQL/XSS injection e ulteriori parole chiave relative alla code injection; Level 3 aggiunge regole, elenchi di parole chiave e limiti per i caratteri speciali; Level 4 limita ancora di più i caratteri speciali e richiede test particolarmente approfonditi sui falsi positivi prima del go-live. Restano validi i limiti di logging descritti in precedenza: Level 1 non viene registrato, mentre Level 2 e superiori compaiono in /log/reverseproxy.log. Non considerare un livello superiore validato come sicuro solo perché la pagina iniziale si apre.

Verificare HSTS e protezione MIME prima dell’attivazione

Con HTTP Strict Transport Security e Redirect HTTP attivato, il firewall aggiunge questo header:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

31536000 corrisponde a un anno. L’effetto non riguarda soltanto il punto di ingresso testato: includeSubDomains include i sottodomini e i browser possono memorizzare questa direttiva. Prima dell’attivazione, HTTPS, certificati e tutti i sottodomini interessati devono funzionare in modo stabile nel tempo; deselezionare successivamente la casella non annulla immediatamente le direttive già memorizzate dai browser. La sola presenza di preload nell’header non dimostra l’inclusione in una lista di preload del browser. MIME-type sniffing protection aggiunge X-Content-Type-Options: nosniff; correggere quindi i tipi MIME errati sul backend, invece di rimuovere indiscriminatamente l’header. Verificare entrambi gli header dal client esterno.

Creare eccezioni limitate allo stretto necessario

In Add new exception, definire Paths, Sources, Operation e i controlli specifici da saltare. I percorsi delle eccezioni distinguono maiuscole e minuscole e consentono wildcard, ad esempio /products/*/images/*. Questo li differenzia dalle Entry URLs della policy Static URL Hardening, che non ammettono wildcard. In Operation, è determinante la combinazione booleana: la corrispondenza con un percorso e una fonte insieme è più restrittiva rispetto alla corrispondenza con un percorso o una fonte. Prima di salvare, verificare l’intersezione desiderata, per evitare che una fonte partner venga involontariamente esclusa dalla protezione per tutti i percorsi.

Per Sources di un’eccezione sono documentati indirizzi IP, intervalli, elenchi e reti. Questo non va esteso ad altri campi: per Path-specific routing di SFOS 22 e per i campi Allowed client networks e Blocked client networks di Passthrough in SFOS 23 sono documentati solo i tipi di host IP e Network, non IP ranges o IP lists. Per ottenere una restrizione di accesso prevedibile, utilizzare in questi campi singoli oggetti IP o di rete.

Le opzioni di un’eccezione consentono di saltare, tra l’altro, Cookie signing, Static URL hardening, Form hardening, Antivirus, Block clients with bad reputation e determinate categorie del Common threat filter. Due opzioni richiedono ulteriore cautela:

Never change HTML during static URL hardening or form hardening impedisce la riscrittura della pagina HTML, ad esempio quando l’applicazione necessita di link non modificati. Questo non significa automaticamente che i link non firmati vengano accettati; a tale scopo può essere necessaria un’eccezione di hardening mirata.
Accept unhardened form data accetta dati dei form privi di firma di hardening. Una sola eccezione per Form hardening non lo fa. Questa autorizzazione aggiuntiva rimuove un ulteriore controllo ed è adatta solo a un flusso precisamente circoscritto e motivato.

Prima della modifica, conservare la richiesta legittima che produce l’errore, l’orario e la Rule ID verificata. Dopo la modifica, ripetere la stessa richiesta ed eseguire una controverifica con una fonte o un percorso non esclusi. L’eccezione è adeguatamente circoscritta solo quando il flusso necessario funziona e il resto della protezione rimane attivo; in caso di dubbio, escludere una singola Rule ID verificata in Skip filter rules, invece di un intero ambito di protezione.

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, gli ID delle regole 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.

Per la precedente migrazione a SFOS 18 sono importanti le seguenti corrispondenze: Protocol violations, Protocol anomalies, Request limits e HTTP policy sono confluiti in Protocol enforcement; Generic attacks e Tight security in Application attacks; Bad robots in Scanner detection; Outbound in Data leakage. Rigid filtering viene migrato a Level 1 e deve essere rivalutato consapevolmente. La categoria Trojans è stata rimossa; l’antivirus fornisce la protezione corrispondente. Le regole già escluse a cui è assegnata una nuova Rule ID rimangono escluse, mentre gli ID non rimappati, rimossi o confluiti in una nuova regola vengono eliminati dalla lista delle esclusioni. Non copiare quindi il vecchio elenco di eccezioni senza verificarlo, ma confrontarlo con la policy e i log attuali.

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 online.
/ 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 hot standby. Questo aiuta in semplici casi di alta disponibilità o distribuzione del carico, ma non sostituisce un progetto completo di bilanciamento del carico applicativo.

Senza un ulteriore vincolo di affinità, le richieste vengono distribuite tra i diversi server web selezionati. Sticky session cookie associa il browser a un server backend; se questo non è più disponibile, il cookie viene aggiornato e la sessione viene spostata su un altro server. Questo non garantisce il trasferimento dello stato applicativo: un carrello, ad esempio, può richiedere un archivio di sessione condiviso.

Hot-standby mode invia inizialmente tutte le richieste al primo server selezionato e utilizza gli altri come backup. Quando il server principale torna disponibile, le sessioni normalmente tornano su di esso; con Sticky session cookie attivato, la sessione esistente rimane sul backup. Collaudare quindi separatamente il server primario, l’ordine dei backup, il guasto, il ripristino e un’operazione di login o di utilizzo del carrello che mantenga effettivamente uno stato.

Il campo Authentication è elencato anche nella tabella SFOS 23 per Passthrough, mentre la panoramica delle funzionalità associa l’autenticazione a Protect. Questa discrepanza nella documentazione non va risolta con supposizioni. Se è richiesta WAF-MFA, basare la parte protetta su Protect e su una policy esplicita; le distinzioni e i test sono descritti in Autenticazione WAF con MFA.

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 tra sedi, 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.

La configurazione documentata 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 con indirizzo assegnato 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:

In Routing > Gateways > IPv4 gateway > Add, creare e salvare il gateway. Nell’esempio si chiama gw6, utilizza Gateway IP 10.12.13.2 e Interface xfrm1-10.12.13.1. In Monitoring condition, utilizzare un host dietro il gateway che risponda in modo affidabile; l’esempio documentato utilizza 10.12.13.2. Sostituire questi indirizzi privati e l’interfaccia con l’indirizzamento effettivo del tunnel e un host di monitoraggio adatto.
In Routing > SD-WAN routes, selezionare IPv4 e Add, assegnando ad esempio il nome SD-WAN_WAF_Portal. In Destination networks, rimuovere Any e selezionare l’interfaccia WAN pubblica o la Hosted address attraverso la quale il client raggiunge la regola WAF; nell’esempio, #Port1. Per questa route WAF documentata, non si tratta semplicemente dell’IP privato del backend.
In Services, rimuovere Any e selezionare il Listening Port esterno della regola WAF, nell’esempio TCP 8080. Se è diverso dalla porta interna del backend, qui va utilizzata esplicitamente la porta esterna. La porta non standard deve essere considerata anche nella richiesta di test esterna.
In Link selection settings, selezionare Primary and Backup gateways e impostare in Primary gateway il gateway XFRM gw6 creato in precedenza. Salvare la route. 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.

La procedura SD-WAN rimanda a una guida per VPN route-based con Traffic Selectors; il riferimento delle regole WAF esclude però esplicitamente i Traffic Selectors basati su subnet. Per questo caso d’uso WAF, pianificare quindi una connessione Any-to-Any e non interpretare il titolo della guida richiamata come un’autorizzazione a utilizzare configurazioni con selettori di subnet.

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é la corrispondenza SD-WAN né la raggiungibilità del backend.

Operatività e troubleshooting

Durante l’operatività è importante che la pubblicazione rimanga tracciabile: quale regola gestisce il traffico, quali log sono rilevanti, quali eccezioni esistono e come procedere in caso di problemi.

Errori tipici

Il 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 oppure la corrispondenza SNI non è corretta.
È stata scelta la Hosted address sbagliata: il firewall seleziona un’altra regola oppure non intercetta alcun traffico WAF.
Allowed client networks vuoto: la regola non funziona come previsto.
Limite delle regole WAF non considerato: ulteriori pubblicazioni non possono più essere configurate correttamente.
Versione Exchange successiva al 2013 pianificata con un template WAF: il template non rientra nel limite di supporto WAF.
Conflitto di porta con User Portal, VPN Portal o un altro servizio: l’applicazione non è raggiungibile oppure risponde un servizio del firewall.
Il backend non è raggiungibile internamente: i client esterni ricevono errori anche se DNS e certificato sono corretti.
Timeout del backend impostato male: le risposte lunghe terminano con errori anche se l’applicazione è sostanzialmente raggiungibile.
Backend raggiunto tramite VPN o SD-WAN senza una route adatta: la regola WAF corrisponde, 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 oppure 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 della regola senza finestra di manutenzione: le connessioni esistenti possono interrompersi al riavvio delle regole WAF.
La vecchia regola DNAT e la nuova regola WAF competono: non è chiaro quale pubblicazione gestisca il traffico.

Risoluzione dei problemi

Se una pubblicazione WAF non funziona, verificare sistematicamente:

Il nome DNS pubblico punta all’IP pubblico corretto?
È selezionata la Hosted address corretta nella regola WAF?
La porta di ascolto è libera e non occupata da WebAdmin, User Portal, VPN Portal o un’altra pubblicazione?
Il certificato corrisponde al nome host richiesto?
Il server web interno è raggiungibile dal firewall?
Allowed client networks, Blocked client networks e Blocked countries sono impostati correttamente?
Il Protected Server è raggiungibile tramite una route, una SD-WAN Route o una connessione VPN effettivamente corretta dal punto di vista del firewall?
Esiste una regola WAF più generale che corrisponde prima?
L’accesso viene visualizzato nel Log Viewer come consentito, bloccato o scartato?
Ci sono indicazioni in /log/reverseproxy.log?
La Protection Policy è impostata su Monitor o Reject?
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 specifica versione SFOS interessata o corretta né un workaround supportato.

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

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

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 circoscritte, giustificate e temporanee.
La modifica è stata testata esternamente.
La data di scadenza o il termine di revisione è documentato.

Inquadrare gli oggetti WAF tramite la XML API

Per le automazioni, pubblicazione, backend e policy di protezione sono collegati, ma restano oggetti distinti. FirewallRule con PolicyType HTTPBased contiene HTTPBasedPolicy; RealServers descrive il web server backend e ProtocolSecurity la policy di protezione. La regola WAF fa riferimento a questi oggetti, non ne sostituisce la configurazione. Accesso, verifica TLS, segreti, operazioni di scrittura esplicite e interpretazione dello stato XML sono illustrati in Limitare in modo sicuro l’accesso alla XML API.

Le corrispondenze seguenti spiegano i riferimenti SFOS 22/23, ma non sono modelli di richiesta eseguibili. Prima di ogni scrittura, confrontare la API help della build installata con l’oggetto esistente, predisporre un backup e una procedura di ripristino e verificare prima una query di lettura innocua. Se la sintassi, l’unità o la corrispondenza delle azioni non sono chiare, non scrivere, ma richiedere un chiarimento al supporto. Questo vale soprattutto dopo un cambio di versione.

Non confondere la pubblicazione con i percorsi di accesso

Name identifica la FirewallRule; il riferimento consente al massimo 60 caratteri, senza virgole e in UTF-8. Position è obbligatorio e indica Bottom, Top, After o Before; per le ultime due varianti occorre anche la regola di riferimento identificata per nome. Per Status, la tabella indica il valore predefinito ON e i valori di scrittura Disable ed Enable: ometterlo non è un modo sicuro per predisporre una pubblicazione disattivata. Secondo la tabella, LogTraffic è impostato per default su Disable; verificare esplicitamente il logging. IPFamily offre anche IPv6 nel contratto comune di FirewallRule, ma HTTPBasedPolicy è espressamente limitato a IPv4. Le regole di rete e utente sono trattate in Regole firewall, non devono essere riprese come payload WAF.

Nella sezione WAF, HostedAddress, ListenPort, HTTPS, HTTPSCertificate e Domains/Domain corrispondono al listener pubblico. La tabella elenca HostedAddress, ListenPort, HTTPS e Domains come campi obbligatori. ListenPort è un intero da 1 a 65535; i valori documentati sono 80 con HTTPS disattivato e 443 con HTTPS attivato. Non è la porta del backend. RedirectHTTP è il reindirizzamento HTTP separato. Dopo ogni modifica, verificare insieme il nome pubblico, il certificato e il listener.

Le associazioni dei percorsi si trovano sotto HTTPBasedPolicy/AccessPaths/AccessPath. Al suo interno, backend fa riferimento agli oggetti web server; allowed_networks, denied_networks, blocked_countries e block_unknown_country descrivono l’accesso dei client. stickysession_status e hot_standby riguardano l’affinità di sessione e la selezione del backend. Una Authentication Policy referenziata viene inquadrata nell’articolo sull’autenticazione WAF; un campo presente, da solo, non applica MFA a ogni azione.

Differenza tra versioni: La tabella di SFOS 22 descrive path come una singola stringa e backend come un array obbligatorio. In SFOS 23, path è un array con più valori, mentre backend è indicato come facoltativo. Secondo la tabella, i valori dei percorsi sono limitati a 63 caratteri e non possono contenere virgole. Facoltativo non significa, in questo caso, che abbia senso pubblicare un percorso Protect o Passthrough senza un backend assegnato: l’interfaccia attuale richiede la selezione del backend per queste azioni, mentre Block e Redirect non pubblicano alcun backend.

SFOS 23 aggiunge action in minuscolo, con i valori consentiti 0, 1, 2, 3, oltre a response_code, redirect_protocol, redirect_host, redirect_port e redirect_path. Il riferimento non associa i quattro numeri alle azioni dell’interfaccia. Non costruire una corrispondenza basandosi sull’ordine o su supposizioni; la corrispondenza confermata per la build installata è un prerequisito per ogni modifica automatizzata. Action con l’iniziale maiuscola e i valori Accept, Drop, Reject compare nell’esempio sotto UserPolicy o NetworkPolicy, non nel blocco WAF. Non sostituisce né l’azione WAF esterna dell’interfaccia né AccessPath/action. Per redirect_protocol, la tabella riporta letteralmente http e https, per redirect_port l’intervallo da 1 a 65535 e per redirect_path un massimo di 8192 caratteri. response_code vi è descritto soltanto come intero; per la configurazione concreta resta determinante la selezione nell’interfaccia illustrata sopra.

Nemmeno l’esempio costituisce una prova dello schema: mescola path e Path, contiene riferimenti vuoti e segnaposto e non mostra completamente HTTPSCertificate e LogTraffic nel blocco WAF. SFOS 22 mostra ancora websocket_passthrough; SFOS 23 utilizza il modello delle azioni. Confermare quindi grafia, annidamento, campi necessari e logging nel contratto specifico della build, senza completare meccanicamente l’esempio. ProtocolSecurity nel blocco WAF fa riferimento alla policy di protezione. Le opzioni avanzate PassHostHeader, RewriteHTML, RewriteCookies e CompressionSupport riguardano gli adattamenti del reverse proxy illustrati sopra; non uniformare valori contraddittori dell’esempio e della tabella creando enum propri.

L’esempio mostra inoltre SourceNetworks/Network e ExceptionNetworks/Network, mentre il suo commento cita in alternativa Authentication, AllowFrom, BlockFrom o AccessPaths. Non dedurne equivalenza tra alias, combinazioni consentite o regole di precedenza. Per gli oggetti esistenti che rappresentano l’accesso in questo modo, chiarire struttura ed effetto nella build installata; se restano dubbi, non effettuare scritture automatizzate.

Per le eccezioni è previsto un blocco separato Exceptions/Exception. Al suo interno, path, source e op collegano le condizioni; per op, la tabella riporta letteralmente and, or, AND, OR. skipcookie, skipurl, skipform, skipav e skipbadclients saltano i rispettivi controlli. Invece, skiphtmlrewrite impedisce la modifica dei contenuti corrispondenti e skipform_missingtoken consente dati dei moduli privi della firma di hardening, in aggiunta all’eccezione per i moduli. La riga corrispondente della tabella scambia descrizione e valore predefinito; non dedurne un default affidabile. Restano decisive le conseguenze di sicurezza di entrambe le opzioni descritte sopra. skip_threats_filter_categories utilizza token diversi da quelli della policy di protezione, ad esempio application_attacks e data_leakages. Non scambiare questi token delle eccezioni con i nomi visualizzati della policy. Anche il testo descrittivo obsoleto sulle categorie precedenti non autorizza l’uso dei vecchi token. Dopo una modifica, verificare separatamente il percorso consentito, il percorso bloccato, la route di fallback e una richiesta non coperta da eccezioni.

La tabella descrive path per le route Site-Path; l’esempio di eccezione mostra invece più elementi path all’interno di una Exception, senza un contratto tabellare specifico e univoco. Non applicare quindi alle eccezioni la cardinalità e i limiti dei percorsi di routing. Prima di apportare modifiche automatizzate alle eccezioni, confermare la struttura, il numero di elementi e i valori consentiti nella build installata; se il contratto non è chiaro, non eseguire scritture.

Verificare in modo sicuro il contratto del backend e il timeout

Per RealServers, Name, Host, Port e TimeOut sono documentati come campi obbligatori. Name consente al massimo 60 caratteri UTF-8 senza virgole. Host è il riferimento a un oggetto host IP o FQDN, non un nome WAF pubblico liberamente intercambiabile. Port va da 1 a 65535, con default API 80; Type riporta letteralmente Plaintext (HTTP) o Encrypted (HTTPS). Per un backend HTTPS, confrontare quindi esplicitamente il listener e la porta effettivi, anziché adottare il valore predefinito della porta API.

L’API descrive TimeOut con default 300, intervallo da 1 a 65535 e la nota che si applica soltanto con Keep alive attivato. La GUI, invece, descrive Timeout come il tempo di attesa dei dati verso o dal backend e indica un HTTP-502 alla scadenza. Si tratta di una descrizione diversa, non di una prova di comportamento identico con keep-alive disattivato. Per le configurazioni tramite interfaccia, utilizzare il test delle pause nel trasferimento dei dati descritto sopra; prima di un’automazione, chiarire la dipendenza e il valore memorizzato nella build installata. Non dedurne un aumento globale del timeout.

Per KeepAlive, l’esempio mostra Enable/Disable, ma la tabella riporta soltanto 0 ed Enable, oltre al default ON. Non correggere tacitamente questa discrepanza presumendo un valore Disable. DisableReuse riporta Disable ed Enable e corrisponde a Disable backend connection pooling. Salvare lo stato precedente, rileggere l’oggetto modificato e solo successivamente verificare un trasferimento di dati rappresentativo e i log del backend. Una risposta API da sola non dimostra né la raggiungibilità del backend né l’adeguatezza delle impostazioni di connessione.

Policy di protezione e opzioni dipendenti

Secondo la tabella, ProtocolSecurity richiede Name, Mode e RequestSizeLimit. Per Name valgono al massimo 60 caratteri UTF-8 senza virgole; Mode riporta Monitor e Reject. Le opzioni CookieSigning, StaticUrlHardening e FormHardening corrispondono alla protezione di cookie, URL e moduli descritta sopra. Secondo la tabella, PassOutlookAnywhere è impostato per default su OFF: l’API descrive l’accesso a Exchange solo brevemente, mentre la GUI menziona espressamente il bypass di Web Server Protection. In assenza di un caso d’uso legacy giustificato, lasciarlo quindi disattivato e non trattarlo come una normale opzione di compatibilità. Con StaticUrlHardening attivato, il riferimento descrive EntryURLType con Manual, SitemapFile, SitemapURL; per il caso manuale, l’esempio mostra EntryURLList/EntryURL, con più Entry URL di un massimo di 255 caratteri ciascuno. Non dedurne che la GUI offra tutte le varianti API in modo identico.

La tabella API indica per CookieSigning, StaticUrlHardening, FormHardening, AntiVirus, BlockClientsWithBadReputation e ThreatsFilter un Default di OFF e per ParanoiaLevel un Default di 1. Una policy nuova o referenziata non dimostra quindi, di per sé, che i controlli di protezione siano attivati. Quando si crea una policy, impostare esplicitamente le opzioni desiderate e rileggerne i valori. In fase di modifica, in assenza di un contratto di aggiornamento confermato, non presumere né che i campi omessi vengano mantenuti né che vengano ripristinati ai valori di Default.

Con AntiVirus attivato, diventano rilevanti AVMode (Avira, Sophos, DualScan), Direction (Uploads, Downloads, UploadsAndDownloads), BlockUnscannableContent e LimitScanSize. L’intero Megabytes dipende inoltre dall’attivazione di LimitScanSize. Questo limite resta separato da quello del body. SkipRemoteLookups dipende da BlockClientsWithBadReputation; non dedurre l’effetto del controllo della reputazione dalla sola descrizione sintetica dell’API.

ThreatsFilter attiva il Common threat filter. Ne fanno parte ThreatFilters/Filter, ParanoiaLevel da 1 a 4 e SkipFilterRules/FilterRules come elenco di Rule ID interi. I token di filtro consentiti sono letteralmente Application attacks, SQL injection attacks, XSS attacks, Protocol enforcement, Scanner detection, Data leakages. L’ultimo token differisce dal nome nella GUI Data leakage. Escludere in modo mirato soltanto i falsi positivi documentati e poi verificare nuovamente la protezione restante; livello, categoria ed eccezione sono decisioni distinte.

RequestSizeLimit resta un conflitto tra fonti: La tabella API indica il campo come obbligatorio, il default 10, la descrizione «Megabytes» e un intervallo di interi da 1 a 1073741824. La GUI attuale documenta invece da 1 a 1024 MB, con default 10 MB. Nell’esempio API, RequestSizeLimit manca del tutto. Non dedurne né una conversione byte/MB, né un limite operativo più ampio, né la certezza che il campo sia facoltativo. Per la GUI, utilizzare l’intervallo in MB documentato; utilizzare un valore di scrittura API soltanto dopo aver confermato unità, intervallo e comportamento del campo obbligatorio nella build installata. Lo stesso vale per la denominazione della tabella HSTS Enforcement, assente nell’esempio: non inventare un tag XML a partire dal nome. XContentTypeOptions descrive la protezione MIME; controllare dall’esterno l’associazione della policy memorizzata e gli header effettivi.

Distinguere le risposte XML in base all’operazione

I numeri seguenti sono stati degli oggetti XML, non codici di stato HTTP. Message.* indica qui un nome simbolico non risolto presente nel riferimento, non un messaggio di errore tradotto né una prova di una causa precisa. Verificare insieme risposta, operazione e stato dell’oggetto memorizzato; in caso di errori, avvisi o possibili modifiche parziali, non ripetere mai alla cieca una scrittura. La guida centrale alla sicurezza dell’API illustra la procedura sicura di verifica ed escalation.

Per le risposte di FirewallRule rilevanti per il WAF, sono particolarmente importanti le seguenti differenze:

Add firewall rule: 200 → Message.FWRuleAddSuccess, 500 → Message.FWRuleAddFail, 502 → Message.FWRuleRecordExists. Edit firewall rule: 200 → Message.FWRuleEditSuccess, 202 → Message.FirewallRuleUpdateWithRename, 500 → Message.FWRuleEditFail, 502 → Message.FWRuleUpdateRecordExist. Con 202, rileggere anche il nome dell’oggetto e i riferimenti, non limitarsi a riutilizzare il vecchio nome.
Add firewall rule 541 → Message.VHIPRangeConflict. Edit firewall rule 541 ha invece Message.FWRuleFailMaxUser; lo stesso codice non deve portare alla stessa diagnosi.
Add firewall rule 543 ed Edit firewall rule 544 → Message.CannotSetupRedirectionFromHTTP. Add firewall rule 544 ed Edit firewall rule 543 → Message.CannotUseDefaultPort. La corrispondenza è invertita tra Add ed Edit: verificare listener, porta e reindirizzamento, senza classificare soltanto in base al numero.
Per Add firewall rule ed Edit firewall rule: 542 → Message.CannotUseTypeHTTP, 545 → Message.PortAlreadyExists, 546 → Message.CannotConfigureDomainWithAddrTypePort, 550 → Message.PortUsedInUserPortal, 553 → Message.CannotConfigureDomainWithHTTPSRedirection. Confrontare la configurazione esistente di listener e domini; non modificare le aperture delle porte sulla base di supposizioni.
Per entrambe le operazioni: 547 → Message.warn_update_business_policy; 548 e 549 utilizzano entrambi Message.MaxIPv4ForAppServerAllowed. La doppia associazione del simbolo non dimostra l’esistenza di limiti diversi inventati. Verificare l’avviso e lo stato WAF effettivamente memorizzato.
Add firewall rule 554 → Message.CannotUseFQDNWildCardAsProtectedServer; Edit firewall rule 554 → Message.CannotUpdateFQDNWildCardAsProtectedServer. Non confondere i domini pubblici wildcard con un host backend adatto. Edit firewall rule 552 → Message.CannotImportDiffPolicytypeWithSameName: verificare nome e tipo di policy, senza sovrascrivere un oggetto diverso.
Per Add, Edit e Delete firewall rule: 596 → Message.CMLOCALOperationrestriction. Per Delete sono inoltre previsti 200 → Message.FWDelSuccess e 500 → Message.FWRuleDeleteFail. Chiarire la competenza amministrativa e i riferimenti prima di un nuovo tentativo. La pagina Delete indica Name come facoltativo e utilizza un testo descrittivo non pertinente su Before/After; questo non costituisce un modello sicuro per l’eliminazione. Confermare il destinatario esatto e il contratto Remove specifico della build; altrimenti non eliminare.

Anche backend e policy di protezione hanno serie di risposte proprie: Add Web Server 200/500/502 corrispondono a Message.RealServerAddSuccess/Message.RealServerAddFail/Message.RealServerRecodExist; Update Web Server 200/500 a Message.RealServerUpdateSuccess/Message.RealServerUpdateFail. Add Protection Policy 200/500/502 corrispondono a Message.ProtocolSecurityAddSuccess/Message.ProtocolSecurityAddFail/Message.ProtocolSecurityRecodExist; Edit Protection Policy 200/500 a Message.ProtocolSecurityUpdateSuccess/Message.ProtocolSecurityUpdateFail. Le grafie RecodExist sono mantenute letteralmente: i nomi simbolici non sono stati corretti. In caso di collisioni tra nomi, leggere prima l’oggetto esistente; eliminare e ricreare non è una procedura standard sicura di ripetizione del tentativo.

Per l’oggetto globale WAFSlowHTTP, RequestHeaderTimeoutEnabled, RequestHeaderTimeoutSoftLimit, RequestHeaderTimeoutHardLimit e RequestHeaderTimeoutExtensionRate corrispondono all’opzione di attivazione e ai tre limiti illustrati sopra. Tutti e quattro sono documentati come campi obbligatori; l’opzione riporta Disable ed Enable, gli altri valori sono interi senza un intervallo specificato. NetworkExceptions/Host è un elenco facoltativo di riferimenti a host. I valori di esempio 10, 30, 5000 non sono default comprovati. SlowHTTP Protection riporta 200 con Operation Successful. e 500 con Operation Fail.. Le modifiche restano globali: verificare i valori memorizzati e le eccezioni strettamente circoscritte e collaudare tutte le pubblicazioni interessate con client legittimi lenti.

Domande frequenti

WAF sostituisce il patching del server web?

No. WAF può rilevare o bloccare attacchi, ma non può compensare permanentemente un’applicazione insicura. Sistema operativo, server web, framework, plugin e codice applicativo devono essere comunque mantenuti.

È necessario anche DNAT?

Normalmente no per la stessa pubblicazione web. La regola WAF gestisce la pubblicazione tramite l’Hosted address e inoltra al server web protetto. DNAT rimane rilevante per altri protocolli o applicazioni web non supportate.

Perché il server web non vede l'IP reale del client?

Il firewall funziona come Reverse Proxy. Pertanto, il server web vede spesso il firewall come indirizzo di origine. L’IP originale del client si trova nell’header X-Forwarded-For, a condizione che l’applicazione o il server web interpreti questo header.

È possibile pubblicare più siti web tramite lo stesso IP pubblico?

Sì, con HTTPS il firewall utilizza SNI e il nome host per scegliere la regola WAF appropriata o il server web virtuale corrispondente. DNS, certificato e domini nella regola WAF devono corrispondere correttamente.

Si dovrebbe usare WAF per Nextcloud?

Non senza un’attenta valutazione. WebDAV è documentato come caso non supportato per WAF. Poiché Nextcloud utilizza intensamente WebDAV, una pubblicazione tramite WAF in molti ambienti non è adatta.

I Threat Feeds proteggono anche le regole WAF?

Con SFOS 22, i Threat Feeds possono essere rilevanti anche per il traffico in entrata e inoltrato, come quello delle pubblicazioni WAF e DNAT. Perché ne derivi una protezione effettiva, i feed, il logging, gli allarmi, le responsabilità e il processo di gestione dei falsi positivi devono però essere gestiti correttamente.