Proteggere Sophos Firewall WAF con MFA

Con Sophos Firewall WAF MFA è possibile proteggere ulteriormente le applicazioni web pubblicate tramite la Web Application Firewall con l’autenticazione multifattoriale. Questo è particolarmente utile per portali interni, interfacce amministrative, aree clienti o accessi partner che devono essere raggiungibili tramite HTTPS, ma non dovrebbero essere protetti solo dall’applicazione stessa.

WAF-MFA non sostituisce un’applicazione sicura, una gestione delle patch o un modello di autorizzazione ben definito. È uno strato di protezione preliminare sul firewall. Il firewall verifica prima il login e il secondo fattore, prima di inoltrare l’accesso al server web protetto.

La versione è importante: il MFA integrato per WAF è una funzione di SFOS 22. Su versioni firmware precedenti, le pubblicazioni WAF devono essere pianificate con altre architetture, per esempio autenticazione esterna, reverse proxy dedicato, VPN o ZTNA.

Per la pubblicazione di base di un server web tramite WAF, si adatta prima la guida Sophos Firewall WAF: Pubblicare in modo sicuro un server web. Questo articolo si concentra sull’autenticazione preliminare e MFA.

Impiego e pianificazione

Quando è utile WAF-MFA

WAF-MFA è particolarmente efficace quando un’applicazione web deve essere raggiungibile da Internet, ma non è destinata a tutti i visitatori.

Casi d’uso tipici:

• portali interni con accesso esterno
• interfacce amministrative di applicazioni specialistiche
• portali partner o clienti con un numero limitato di utenti
• applicazioni web legacy senza MFA forte propria
• applicazioni in cui è desiderata una protezione di accesso aggiuntiva prima del backend

Per siti web pubblici, negozi o pagine informative, WAF-MFA di solito non è adatto, poiché ogni visitatore vedrebbe prima un login del firewall. Per applicazioni private complesse, ZTNA, SSE o un proxy inverso dedicato possono essere più adatti di WAF-MFA. Sophos WAF non supporta WebDAV; applicazioni come Nextcloud non sono quindi pubblicazioni WAF supportate. Pianificare un’altra architettura con regole firewall adeguate e una propria protezione degli accessi; pubblicare senza WAF non mantiene automaticamente la sua autenticazione o protezione applicativa.

WAF protegge a livello Layer 7 da minacce come la manipolazione di cookie, URL e moduli. Il server web, la Protection Policy e la Authentication Policy sono associati tramite la regola WAF; sono supportate al massimo 60 regole WAF. Il servizio WAF si gestisce in System services > Services. Riavviarlo interessa le applicazioni pubblicate e non è il primo intervento per un singolo errore di login.

Quando WAF-MFA non è sufficiente

WAF-MFA è uno strato di accesso preliminare. Tuttavia, questo strato non risponde a tutte le domande architetturali. Soprattutto per portali critici, bisogna decidere consapevolmente se l’applicazione debba essere raggiungibile pubblicamente.

• L’applicazione è destinata solo a pochi utenti interni: verificare VPN, ZTNA, reti sorgente fisse o una pubblicazione non pubblica.
• L’applicazione contiene dati particolarmente sensibili: verificare anche autorizzazioni backend, logging, audit trail e sessioni applicative.
• L’applicazione necessita di WebDAV: scegliere un’altra architettura; un progetto pilota non trasforma la mancanza di supporto WAF in una soluzione supportata. Per altri protocolli speciali, verificare separatamente la compatibilità prima del rollout.
• Partner esterni accedono raramente: documentare in modo particolarmente chiaro rollout dei token, processo di supporto e fallback.
• Il backend ha un proprio login e ruoli: considerare WAF-MFA solo come strato aggiuntivo, non come sostituto dei ruoli backend.

Se un portale rimane accessibile a livello mondiale, MFA non dovrebbe essere l’unica misura. Reti sorgente fisse, limitazioni geografiche, Threat Feeds, profili di protezione e patch appropriate del backend riducono ulteriormente il rischio.

Prerequisiti

Prima della configurazione, dovrebbero essere chiariti questi punti:

• L’applicazione web è già pianificata o pubblicata tramite una regola WAF.
• Il firewall esegue SFOS 22 o versione successiva.
• Gli utenti o i gruppi sono presenti sul firewall, ad esempio localmente, tramite AD, LDAP o RADIUS.
• Gli utenti possono configurare il loro token OTP.
• L’ora di sistema del firewall è corretta e NTP funziona.
• Per la regola WAF viene utilizzato HTTPS con un certificato appropriato.
• È chiaro se il server web backend necessita di autenticazione propria o se il firewall deve gestire completamente il login.
• Sono disponibili un utente di test e un accesso amministrativo di fallback.

⚠️ MFA per WAF dovrebbe essere testato prima con un gruppo pilota. Una combinazione errata di gruppo MFA, politica di autenticazione WAF e autenticazione backend può escludere utenti legittimi o far sembrare guasta un’applicazione.

Pianificare pilota, fallback e responsabilità

WAF-MFA agisce prima dell’applicazione vera e propria. Pertanto, il rollout non dovrebbe essere trattato come una normale regola del firewall, ma come una modifica al processo di login dell’applicazione. Gli utenti vedono prima il login di Sophos Firewall e solo successivamente, a seconda del backend, l’applicazione vera e propria.

Prima dell’attivazione, dovrebbero essere definiti questi punti:

• Quale gruppo di utenti testerà per primo?
• Chi può disattivare l’accesso se il login fallisce?
• Esiste un secondo accesso amministrativo che non dipende dalla stessa regola WAF, dallo stesso portale o dallo stesso utente di test?
• Quali parti dell’applicazione devono essere testate dopo un login riuscito?
• Chi controlla reverseproxy.log, Log Viewer e log backend in caso di errori?
• Come vengono informati gli utenti su token, scadenza della sessione e possibile secondo login backend?

Un errore di pianificazione comune è la confusione tra autenticazione del firewall e autenticazione backend. WAF può verificare gli utenti prima del backend. Tuttavia, ciò non significa automaticamente che l’applicazione stessa non abbia più bisogno di un proprio login, verifica dei ruoli o gestione delle sessioni. Soprattutto per portali amministrativi e dati dei clienti, l’autorizzazione backend dovrebbe essere mantenuta consapevolmente.

Se il servizio pubblicato è destinato solo a poche persone, oltre a MFA, si dovrebbero limitare le origini di accesso. Per la pubblicazione di base e la limitazione delle fonti, si adatta Sophos Firewall WAF: Pubblicare in modo sicuro un server web. Se sono pianificati diritti utente o MFA per accesso remoto in generale, aiuta Abilitare MFA per Sophos Firewall WebAdmin, VPN Portal e Accesso Remoto.

Un rollback dovrebbe essere preparato prima dell’attivazione. Praticamente significa: documentare il vecchio metodo di accesso funzionante, nominare la regola WAF e la politica di autenticazione, designare la persona responsabile e scegliere un momento in cui è possibile il feedback degli utenti e la verifica dei log. Se l’applicazione è critica per il business, WAF-MFA dovrebbe essere attivato prima per un dominio di test, un gruppo pilota o una finestra di manutenzione.

Configurazione

Componenti della configurazione

Per WAF-MFA devono essere allineate diverse impostazioni:

• Impostazione MFA: definisce quali utenti utilizzano MFA e se Web application firewall è protetto.
• WAF Authentication Policy: definisce modalità di login, utenti/gruppi, template e comportamento di sessione.
• WAF rule: collega il server web pubblicato alla Authentication Policy.
• Backend authentication forwarding: definisce se il firewall inoltra le credenziali di accesso al server web.
• Rollout dei token: garantisce che gli utenti possano effettivamente generare il loro codice OTP.

La differenza principale: MFA non viene attivato solo globalmente. La regola WAF interessata deve anche utilizzare una politica di autenticazione appropriata.

Attivare MFA per WAF

Il percorso del menu è:

Authentication > Multi-factor authentication

Procedura:

1. Sotto One-time password (OTP) selezionare All users o Specific users and groups.
2. In Specific users and groups aggiungere gli utenti o i gruppi interessati.
3. Attivare Generate OTP token with next sign-in se gli utenti devono configurare il loro token al prossimo login.
4. Sotto Require MFA for attivare l’opzione Web application firewall.
5. Impostare consapevolmente OTP hash algorithm e, se necessario, OTP timestep settings. I valori predefiniti sono 30 secondi per Default token timestep, 2 per Maximum verification code offset e 10 per Maximum initial verification code offset.
6. Salvare la configurazione.

Quando Generate OTP token with next sign-in è attivo, User portal viene selezionato automaticamente. Gli utenti accedono prima al VPN portal o allo User portal e scansionano lì il codice QR. L’amministratore predefinito può invece usare la console WebAdmin quando MFA è obbligatoria per il suo accesso WebAdmin. Questa fase di onboarding deve funzionare prima del primo accesso WAF. La pianificazione generale di MFA è descritta in Abilitare MFA per Sophos Firewall WebAdmin, VPN Portal e Accesso Remoto.

I due valori di offset non sono la soluzione normale per un orologio errato. Con un timestep di 30 secondi, un Maximum verification code offset pari a 2, ad esempio, accetta un codice non ancora usato dei 60 secondi precedenti. Una finestra più ampia rende il login più tollerante, ma estende anche la validità dei codici precedenti. Correggere prima NTP e l’ora dello smartphone e modificare l’offset solo per un motivo documentato.

Preparare il rollout dei token e la comunicazione agli utenti

WAF-MFA spesso fallisce in operatività non a causa della regola WAF stessa, ma del rollout dei token. Gli utenti devono sapere dove appare il codice QR, quale app utilizzare, quanto dura una sessione e se dopo il login al firewall segue un secondo login all’applicazione.

Prima dell’attivazione della regola WAF produttiva, si dovrebbe stabilire:

• Creazione del token: dove l’utente configura il token OTP?
• Accesso al portale: User Portal o un altro percorso previsto per il codice QR sono raggiungibili per gli utenti interessati?
• App Authenticator: quale app è autorizzata e testata con l’algoritmo scelto?
• Fallback: chi può reimpostare un token perso o difettoso?
• Codici di emergenza: è chiaro se e come possono essere emessi passcode monouso aggiuntivi nei casi di supporto?
• Caso di supporto: di quali informazioni ha bisogno l’helpdesk in caso di problemi di login?
• Comunicazione: quale sequenza di login vedono gli utenti dal go-live?

Se si utilizza Generate OTP token with next sign-in, il primo login dovrebbe essere testato in modo controllato. È importante verificare se gli utenti vedono il codice QR nel portale previsto e se possono accedere con successo all’applicazione WAF con password più OTP. I portali stessi sono descritti in Sophos Firewall Portali: WebAdmin, User Portal e VPN Portal.

Per molti servizi del firewall, il codice OTP viene elaborato come combinazione di password e passcode. La comunicazione agli utenti e il runbook dell’helpdesk devono quindi indicare chiaramente quale schermata vedono davvero gli utenti e se password e OTP devono essere inseriti separatamente o combinati. Con WAF-MFA e login basato su Form, questo punto è particolarmente importante perché un secondo login backend viene rapidamente interpretato come “MFA non funzionante”.

Sophos Authenticator non dovrebbe più essere pianificata come nuova app standard, perché l’app è End of Life dal 2022. In pratica vanno testate Intercept X for Mobile, Google Authenticator, Microsoft Authenticator, Duo Mobile, Okta Verify o un’app approvata internamente. Conta non solo il nome dell’app, ma se supporta correttamente l’algoritmo scelto, il timestep e il codice QR del firewall.

Durante il rollout conta anche il sistema operativo mobile. La scansione del codice QR nell’app Okta non funziona per questi token su iOS né su Android. Su iOS la stessa limitazione riguarda anche Google Authenticator, Duo e Microsoft Authenticator. In questi casi l’utente deve inserire manualmente il Base32 secret. Includere questo passaggio nella guida utente; una configurazione corretta del firewall può altrimenti sembrare guasta se il runbook prevede soltanto la scansione QR.

Per l’helpdesk e l’operatività dovrebbe essere documentato almeno:

• nome host pubblicato dell’applicazione WAF
• gruppo di utenti interessato
• politica di autenticazione utilizzata
• algoritmo OTP utilizzato
• app Authenticator consentita
• procedura per il reset del token
• messaggio previsto in caso di password errata o OTP errato
• punti di log per la prima verifica: Log Viewer e reverseproxy.log

Soprattutto con partner esterni o portali utilizzati raramente, il primo login non dovrebbe avvenire solo in caso di emergenza produttiva. Un breve pilota con utenti normali spesso rivela problemi che gli amministratori non vedono nei propri test: app Authenticator diversa, accesso al portale mancante, secondo login backend non chiaro o timeout delle sessioni troppo brevi per l’applicazione.

Creare una politica di autenticazione WAF

Il percorso del menu è:

Web server > Authentication policies

Per WAF-MFA, impostare la modalità client su Form. L’autenticazione basata su form crea cookie di sessione e consente un logout dedicato; il firewall gestisce il login tramite il modulo e le sessioni.

Procedura:

1. Aprire Add.
2. Assegnare un nome significativo, ad esempio WAF_MFA_Portal_Users.
3. In Mode selezionare l’opzione Form.
4. Selezionare un Authentication template appropriato.
5. Selezionare gli utenti o i gruppi che avranno accesso a questa pubblicazione WAF.
6. Scegliere consapevolmente la modalità di Authentication forwarding.
7. Impostare Session timeout e Session lifetime in base all’applicazione.
8. Salvare.

La documentazione dell’API XML di SFOS 23 descrive il parametro facoltativo RedirectToRequestedURL esclusivamente per la modalità client Form, con i valori Enable e Disable. Con Enable, l’utente viene reindirizzato all’URL richiesto originariamente dopo l’autenticazione riuscita. La documentazione non indica un valore predefinito per questo parametro; il suo nome nell’API non è un’etichetta di campo della GUI confermata. Il reindirizzamento non sostituisce né l’autenticazione né la verifica delle autorizzazioni.

Scegliere correttamente l’inoltro dell’autenticazione

La modalità di Authentication forwarding decide cosa succede tra il firewall e il backend.

• None: nessuna autenticazione del backend da parte del firewall; l’autenticazione a monte resta attiva. Per rimuovere un header Basic inviato dal client è rilevante anche Remove basic header.
• Basic: il firewall trasmette nome utente e password al backend tramite HTTP Basic Authentication.

Se l’applicazione non necessita di autenticazione propria o se il login preliminare del firewall è sufficiente, None è spesso più pulito. Se il backend stesso si aspetta HTTP Basic Authentication, la modalità di inoltro deve adattarsi all’applicazione.

Con None si dovrebbe inoltre verificare se è necessario impostare Remove basic header. Questo impedisce che un header Basic Authentication inviato dal client venga inoltrato inutilmente al server web. È particolarmente importante quando vecchi client, dati salvati nel browser o pubblicazioni precedenti generano ancora header Basic.

⚠️ Basic Authentication dovrebbe essere utilizzata solo con HTTPS. Inoltre, deve essere chiaro se il backend deve effettivamente elaborare le credenziali di accesso trasmesse dal firewall.

La modalità client Basic non crea cookie di sessione e non offre un logout dedicato. Per WAF-MFA Sophos richiede quindi la modalità client Form. Indipendentemente da questo, l’Authentication forwarding mode deve essere adatto al backend.

Nella modalità client Basic, Basic prompt è soltanto il testo della finestra del browser. Nella modalità di inoltro Basic, Username affix aggiunge il prefisso o suffisso configurato quando viene inserito solo un nome utente. Verificare separatamente i nomi di login completi per evitare di duplicare dominio o suffisso nel backend. HTTP Basic segue RFC 7617; la codifica non cifra le credenziali.

Utilizzare la politica di autenticazione nella regola WAF

La regola WAF viene modificata sotto Rules and policies > Firewall rules. L’azione è Protect with web server protection. La seguente checklist e l’associazione tramite Protected servers si riferiscono a SFOS 22; per SFOS 23 sono inoltre necessari i controlli espliciti per ogni percorso in Traffic routing descritti di seguito.

Il salvataggio di una regola WAF riavvia tutte le regole di protezione dei server web. Le connessioni attive che utilizzano queste regole vengono interrotte e devono essere ristabilite. Concordare la modifica con i responsabili di tutte le applicazioni interessate in una finestra adeguata, conservare le impostazioni precedenti e verificare poi raggiungibilità, accesso con OTP e accesso al backend. Questo effetto e la procedura di ripristino non sono stati testati qui su un’appliance.

Nella regola WAF interessata, questi punti devono essere allineati:

• Indirizzo Hosted address e porta di ascolto corretti.
• Dominio corretto e certificato HTTPS appropriato.
• Server web protetto corretto.
• Politica di Authentication desiderata selezionata.
• Il gruppo di utenti nella politica di autenticazione corrisponde al gruppo MFA.
• Le restrizioni di accesso tramite Allowed client networks, paesi o Threat Feeds sono impostate consapevolmente.

Per portali pubblici o fortemente esposti, MFA non dovrebbe essere l’unica misura di protezione. La limitazione di paesi e fonti è descritta in Sophos Firewall: Bloccare paesi e IP malevoli. Per le liste di blocco dinamiche si adatta Sophos Firewall Threat Feeds.

SFOS 23: assegnare MFA a ogni percorso del portale

La sola azione esterna della regola Protect with web server protection non è sufficiente. Per ogni percorso del portale da proteggere, su ogni nome host pubblicato e in ogni regola WAF associata, la configurazione del percorso deve essere corretta; i passaggi MFA e i limiti delle sessioni già descritti rimangono invariati.

1. In Traffic routing, modificare o aggiungere ogni percorso protetto del portale e impostare Action > Protect. Assegnare gli oggetti backend previsti da Web server > Web servers.
2. Nel campo Authentication, selezionare la Authentication Policy prevista. Questa deve utilizzare la modalità client Form e includere il gruppo di utenti previsto; l’associazione del gruppo deve corrispondere alla configurazione MFA. Verificare per ogni percorso Allowed client networks e le altre restrizioni delle fonti e degli accessi, inclusi i blocchi di reti e paesi scelti consapevolmente.
3. Se sono consentiti solo determinati percorsi del portale, mantenere / con Block come route di fallback. Se si intende usare Protect per / per pubblicare l’intera applicazione, assegnare anche lì la stessa autenticazione prevista e restrizioni di accesso appropriate. Verificare esplicitamente che percorsi e nomi host alternativi abbiano una protezione equivalente o siano bloccati intenzionalmente.
4. Mantenere i test esistenti per login riuscito con password e OTP, funzionamento del backend, logout, scadenza della sessione e nuovo login. I tentativi con OTP errato e con utenti al di fuori del gruppo consentito devono fallire; percorsi o nomi host alternativi non devono offrire un accesso non protetto. Correlare il risultato sul client con i log WAF, di autenticazione e del backend.

Limite della documentazione su Passthrough: la panoramica delle regole descrive l’autenticazione come funzione di Protect; allo stesso tempo, la tabella delle impostazioni per l’azione di routing Passthrough offre un campo Authentication. Questa incongruenza non dimostra né l’applicazione né l’aggiramento di MFA con Passthrough. Basare quindi la MFA WAF richiesta su percorsi Protect configurati esplicitamente, non su un comportamento di Passthrough non confermato. Concordare separatamente gli eventuali tunnel WebSocket necessari con i responsabili del routing WAF e dell’autenticazione.

Basic with passthrough indica una modalità di autenticazione per l’inoltro delle credenziali; Passthrough in Traffic routing è invece un’azione di routing per la gestione del traffico. La somiglianza del nome non implica alcuna proprietà MFA. Per la pubblicazione di base, i responsabili devono verificare la configurazione dei percorsi di SFOS 23 insieme all’assegnazione di MFA: il tutorial Sophos sulla protezione dagli attacchi, rimasto invariato, non è una guida completa al routing di SFOS 23 e le regole WAF supportano solo IPv4.

Personalizzare in sicurezza un’Authentication Template

Un modulo personalizzato si crea in Web server > Authentication templates > Add. L’HTML deve mantenere il form con action="<?login_path?>" e method="POST", oltre ai campi httpd_username e httpd_password. Per MFA deve essere presente anche otp_field. Se questi elementi vengono rimossi o rinominati, il login può non funzionare anche quando la pagina appare corretta.

Per immagini, stili e script, SFOS mette a disposizione, tra gli altri, i segnaposto <?assets_path?>, <?admin_contact?>, <?company_logo?> e <?company_text?>. Gli asset caricabili sono limitati a .jpg, .jpeg, .png, .ico, .css e .js. Il template deve essere testato prima con un utente pilota; credenziali di produzione, tracker esterni e JavaScript non verificato non devono essere inseriti nella pagina di login.

Dopo Add, inserire un nome, selezionare il file HTML e i suoi asset, scegliere Upload e poi Save. Selezionare il template salvato nella policy di autenticazione Form. Questo modulo minimo mantiene i nomi tecnici richiesti; è un esempio documentale, non un template testato su un’appliance:

<form action="<?login_path?>" method="POST">
  <label>Username <input name="httpd_username" type="text"></label>
  <label>Password <input name="httpd_password" type="password"></label>
  <?otp_field?><label>OTP <input name="otp_field" type="password"></label><?otp_field?>
  <button type="submit">Login</button>
</form>

Contraddizioni nella documentazione dei template: un breve esempio della password usa type="text", mentre la definizione del campo e l’esempio completo mostrano type="password". Mantenere quindi mascherata la password. Una nota indica inoltre soltanto <?login_path?> come variabile sostituita, ma la tabella opzionale descrive sostituzioni anche per <?assets_path?> e <?admin_contact?>. Questo non verifica il comportamento di ogni firmware. Prima del rollout, controllare modulo renderizzato, percorsi degli asset, inserimento OTP e login con un gruppo pilota; non sostituire un template funzionante senza validazione.

<?assets_path?> indica il percorso dei file allegati caricati, per esempio in <link rel="stylesheet" href="<?assets_path?>/stylesheet.css">. Immagini e CSS possono così restare fuori dal modulo. La descrizione del campo collega <?admin_contact?> a Administration > Notification settings > Email settings > Send notifications to email address; verificare se l’indirizzo può essere mostrato pubblicamente. Sostituire <?company_logo?> con il percorso del proprio logo e <?company_text?> con il testo visibile previsto, senza presumere sostituzioni automatiche. Se restano segnaposto visibili o il login fallisce, tornare al template funzionante salvato e analizzare la causa con il supporto anziché disattivare MFA.

Pianificare sessioni e timeout

Con l’autenticazione WAF basata su form, il firewall lavora con le sessioni. Nella politica di autenticazione si definisce:

• Session timeout: dopo quale inattività gli utenti devono autenticarsi nuovamente
• Session lifetime: quanto tempo rimane valida una sessione al massimo

Inoltre, sotto Web server > General settings c’è il numero massimo di sessioni simultanee per l’autenticazione del reverse proxy basata su form. Il valore predefinito è 25,000, l’intervallo supportato è 100 a 100,000.

Maximum sessions è condiviso fra tutte le regole WAF con autenticazione Form. Raggiunto il limite, il firewall chiude sessioni vecchie o scadute per consentirne di nuove. Richieste ripetute di login possono quindi dipendere dalla capacità globale, non solo dal timeout di una singola policy.

Sessioni brevi aumentano la sicurezza, ma possono disturbare gli utenti. Sessioni molto lunghe sono più comode, ma aumentano il rischio che un accesso al browser rubato o condiviso rimanga utilizzabile più a lungo. Per i portali amministrativi, si dovrebbe iniziare in modo conservativo e osservare il comportamento in operatività.

Se molti utenti o più portali WAF utilizzano lo stesso firewall, il limite globale delle sessioni non dovrebbe essere controllato solo quando compaiono errori. L’autenticazione WAF basata su Form è un parametro operativo condiviso del reverse proxy e rientra quindi nella pianificazione di capacità e monitoraggio.

Gestire in sicurezza le impostazioni globali WAF

Web server > General settings interessa tutti i server web protetti, non solo il portale MFA. Prima di modifiche, salvare i valori, identificare applicazioni interessate e compatibilità dei client, e pianificare finestra di manutenzione e ripristino. Queste indicazioni sono verificate documentalmente; effetti e rollback non sono stati testati su un’appliance.

Slow HTTP protection limita l’attesa di header di richiesta incompleti. In un DoS Slow HTTP, frammenti che arrivano lentamente occupano le connessioni fino a esaurire la capacità:

• Soft limit: tempo minimo per ricevere un header di richiesta.
• Hard limit: tempo massimo per riceverlo.
• Extension rate: quantità di dati in byte; ogni superamento estende il timeout soft di un secondo.
• Skipped networks/hosts: eccezioni mirate. Usare solo i tipi di host IP IP e Network, non IP ranges o IP lists. Eccezioni ampie escludono dalla protezione anche client indesiderati.

Dopo gli aggiustamenti, verificare client legittimi normali e lenti e le altre applicazioni WAF. Non adottare timeout arbitrari come soluzione generale per problemi di login.

TLS version settings determina le connessioni client consentite. I profili documentati differiscono anche nelle suite crittografiche:

• TLS v1 or later: esclude SSLv3; profilo legacy, non consigliato per nuovi portali.
• TLS v1.1 or later: esclude SSLv3 e TLSv1; non è uno standard moderno di rollout.
• TLS v1.2 (wide compatibility): solo TLSv1.2, incluse suite legacy non consigliate.
• TLS v1.2 (strict): solo TLSv1.2 con suite consigliate.
• TLS v1.3: solo suite TLSv1.3.

Verificare il supporto dei client prima di scegliere; per esempio IE 8 o precedente e Windows XP non possono connettersi con TLS 1.2. Non ottenere compatibilità legacy indebolendo indiscriminatamente la sicurezza. Testare prima un profilo rigoroso con i client realmente necessari e tutte le applicazioni pubblicate.

In Custom TLS, Protocols, Cipher suite e TLS v1.3 cipher suite only usano sintassi OpenSSL. Le suite TLSv1.3 vanno solo nel campo TLSv1.3 separato, non in Cipher suite. Protocolli o suite non validi possono impedire l’avvio di Apache e compromettere WAF. Non sperimentare Custom TLS in produzione senza configurazione validata; in caso di guasto, ripristinare i valori salvati e verificare stato del servizio e accesso HTTPS a tutti i portali interessati.

SFOS 23 – Worker customization: il firewall calcola la capacità WAF in base a CPU e RAM. I valori calcolati sono ottimizzati per l’hardware; normalmente non servono modifiche. Valori maggiori possono peggiorare prestazioni WAF e utilizzo delle risorse. Attivare Use custom worker profile solo dopo un’attenta valutazione di capacità e impatto, non come rimedio generico al login:

• Start servers: processi worker all’avvio del server web.
• Server limit: numero massimo di processi worker.
• Minimum spare threads: minimo di thread liberi mantenuti disponibili.
• Maximum spare threads: soglia di thread liberi oltre la quale si eliminano quelli in eccesso.
• Threads per child: massimo di thread per processo worker.
• Asynchronous request worker factor: controlla la scalabilità dei processi per connessioni e richieste asincrone.

Non copiare numeri universali da altri sistemi. Salvare i valori iniziali, osservare carico e risorse rappresentativi e ripetere i test di login, OTP, sessioni e accesso al backend dopo ogni modifica motivata. Se le prestazioni peggiorano, ripristinare la configurazione iniziale salvata; qui non si afferma che il ripristino sia stato eseguito con successo.

Automatizzare l’autenticazione WAF tramite XML API

Per l’automazione occorre coordinare tre oggetti distinti: FormTemplate fornisce il modulo di accesso, ReverseAuthentication definisce l’autenticazione del client e del backend e FirewallRule associa la policy alla pubblicazione o ai relativi percorsi. Prima di procedere, eseguire il backup del modello funzionante, della policy e di tutte le regole che li utilizzano. Accesso, operazioni di scrittura esplicite, valutazione delle risposte e tentativi ripetuti in sicurezza sono illustrati in Proteggere l’accesso alla XML API di Sophos Firewall. Le indicazioni seguenti descrivono i riferimenti SFOS-22/23, non una procedura di scrittura testata su un’appliance. Prima di apportare modifiche, verificare l’API help della build installata; non eseguire scritture se vi sono campi o associazioni di upload non chiariti.

Distinguere modalità client, backend e sessioni

Nell’oggetto ReverseAuthentication, Name, VirtualWebserverMode e RealWebserverMode sono descritti come campi obbligatori. Name consente al massimo 60 caratteri. VirtualWebserverMode seleziona Basic o Form per il client; il valore predefinito documentato Basic non è una raccomandazione per l’MFA. Per l’MFA del WAF, Form rimane necessario. BasicPrompt è il testo informativo opzionale per Basic, con un massimo di 255 caratteri. In modalità Form, FormTemplate fa riferimento al modello salvato. UserGroupList contiene voci UserGroup ripetibili per utenti o gruppi esistenti; questa selezione deve continuare a corrispondere al gruppo MFA. La parola Mode nelle note di applicabilità non costituisce un ulteriore tag XML documentato.

RealWebserverMode seleziona indipendentemente Basic o None per il backend; anche in questo caso la tabella indica Basic come valore predefinito. Con Basic, UsernameAffix riguarda l’accesso al backend. Prefix e Suffix sono testi opzionali, ciascuno con un massimo di 255 caratteri, previsti solo per la selezione di affisso corrispondente. Con None, è invece rilevante RemoveBasicHeader, con Enable o Disable. Il valore predefinito ON riportato in quel punto non è di per sé un valore di input ammesso; utilizzare valori espliciti solo dopo aver verificato la build. Restano necessari i controlli HTTPS, del backend e del nome utente già previsti.

Non trasferire le contraddizioni in un payload: per UsernameAffix, l’esempio XML mostra None/Prefix/Suffix/PrefixAndSuffix, mentre la tabella elenca Basic, Prefix, Suffix, PrefixandSuffix e, al contempo, il valore predefinito None. Non dedurre né la grafia né ulteriori valori selezionabili. Analogamente, l’esempio mostra SessionTimeout e SessionLifetime come interruttori, i rispettivi campi Limit come interi e i campi Scope come Hours/Minutes/Days. La tabella conferma per SessionTimeoutLimit l’intervallo da 1 a 9999, ma inverte intero e interruttore per SessionLifetime e SessionLifetimeLimit; indicazioni come ON e 8 Hours non sono coerenti con i tipi di dati. Queste incongruenze non attestano valori predefiniti affidabili né una configurazione di sessione eseguibile. Confermare nella build installata il limite di inattività e la durata massima desiderati, rileggere lo stato salvato ed eseguire i test già previsti per sessione, logout e nuovo login. L’aggiunta di SFOS-23 RedirectToRequestedURL e il relativo test separato di reindirizzamento rimangono indipendenti da ciò.

Associare il modello e i file di supporto

Il riferimento FormTemplate mostra FormTemplate come oggetto con Name, Description, Template e Assets, con voci Asset ripetibili al loro interno. Name e Template sono campi obbligatori: il nome consente al massimo 60 caratteri, mentre Template è una stringa con un massimo di 255 caratteri per la selezione e l’upload del modello HTML. Description è opzionale. Le stringhe opzionali Asset consentono ciascuna un massimo di 255 caratteri e più valori per le immagini, i fogli di stile o i file JavaScript utilizzati.

L’esempio lascia vuoti Template e Asset. Non definisce quindi né i nomi delle parti multipart né i percorsi dei file, una codifica Base64 o contenuto HTML trasferibile direttamente. Non applicare ai FormTemplates un’associazione di upload dei certificati. In assenza di un contratto di upload confermato, utilizzare la sequenza GUI esistente Upload > Save, quindi selezionare il modello salvato tramite FormTemplate nella policy Form. Restano validi i campi del modulo richiesti e i tipi di file asset consentiti indicati nella sezione precedente. Verificare il modulo renderizzato, gli asset e il login OTP con un utente di test; il solo salvataggio riuscito dell’oggetto non dimostra che il modulo funzioni.

Associare l’Authentication Policy alla regola

Per FirewallRule, questa associazione riguarda il ramo WAF HTTPBasedPolicy, non NetworkPolicy o UserPolicy. La tabella dei parametri descrive Authentication come stringa scalare opzionale per un’Authentication Policy. Nell’esempio dei percorsi, l’associazione corrispondente è indicata come AccessPaths > AccessPath > auth_profile. Il commento dell’esempio distingue da AccessPaths la variante a livello di regola con Authentication e controlli sulle sorgenti; non attesta combinazioni arbitrarie o ereditarietà automatica. Non mescolare senza verifica le sintassi a livello di regola e di percorso e non presumere che una policy presente sul firewall protegga già ogni percorso.

In SFOS 23, la tabella descrive path come array obbligatorio di stringhe con più valori, un massimo di 63 caratteri, senza virgole e con supporto UTF-8; SFOS 22 indica qui uno scalare. L’esempio utilizza sia path sia Path. backend è opzionale nella tabella SFOS-23; ciò non garantisce che un portale protetto funzioni senza backend. Il nuovo action a livello di percorso mostra letteralmente 0/1/2/3, senza una corrispondenza attendibile con le azioni della GUI. Non dedurre una corrispondenza numerica e non equiparare questi valori al campo di rete Action. Routing, backend e profilo di protezione sono illustrati in WAF: pubblicare un server web in sicurezza.

Per modificare l’autenticazione, leggere prima i nomi host e i percorsi effettivi della regola di destinazione, associare la policy Form desiderata a ciascun percorso protetto e quindi confrontare lo stato salvato con quello previsto. Verificare tutti i percorsi, i nomi host e le regole alternativi, nonché un OTP errato e utenti esterni al gruppo. Restano invariati i controlli Protect già descritti, il limite della documentazione relativo al passthrough e la finestra di modifica per le regole WAF.

Valutare le risposte degli oggetti prima di un nuovo tentativo

Le corrispondenze seguenti sono valori di stato XML e simboli Message.* letterali e non risolti del riferimento, non codici di stato HTTP né testi di messaggi di runtime verificati. Per l’associazione alla FirewallRule sono particolarmente importanti le differenze tra Add ed Edit:

• 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 effettivo e tutte le associazioni.
• Corrispondenze differenti: Add 541 / Message.VHIPRangeConflict, Edit 541 / Message.FWRuleFailMaxUser; Add 543 / Message.CannotSetupRedirectionFromHTTP, Edit 543 / Message.CannotUseDefaultPort; Add 544 / Message.CannotUseDefaultPort, Edit 544 / Message.CannotSetupRedirectionFromHTTP. Lo stesso codice, da solo, non è sufficiente per l’interpretazione.
• Ulteriori righe distintive: Edit 552 / Message.CannotImportDiffPolicytypeWithSameName; Add 554 / Message.CannotUseFQDNWildCardAsProtectedServer, Edit 554 / Message.CannotUpdateFQDNWildCardAsProtectedServer.
• Delete firewall rule: 200 / Message.FWDelSuccess, 500 / Message.FWRuleDeleteFail, 596 / Message.CMLOCALOperationrestriction. 596 compare anche per Add ed Edit; chiarire lo stato effettivo delle autorizzazioni e della gestione, senza aggirarlo con ripetizioni alla cieca o eliminazioni. Eliminare una regola non è un modo per rimediare a un’associazione di autenticazione mancante.

Anche i due oggetti preliminari hanno risposte proprie:

• Add Authentication Policy: 200 / Message.ReverseAuthAddSuccess, 500 / Message.ReverseAuthAddFail, 502 / Message.ReverseAuthRecodExist.
• Edit Authentication Policy: 200 / Message.ReverseAuthUpdateSuccess, 500 / Message.ReverseAuthUpdateFail.
• Add FormTemplate: 200 / Message.FormTemplateAddSuccess, 500 / Message.FormTemplateAddFail.
• Edit FormTemplate: 200 / Message.FormTemplateUpdateSuccess, 500 / Message.FormTemplateUpdateFail, 502 / Message.FormTemplateRecodExist. La grafia Recod in questi simboli viene mantenuta letteralmente; non dedurne uno stato aggiuntivo per un’altra operazione.

Registrare congiuntamente operazione, codice, risposta effettiva e stato salvato del modello, della policy e della regola di destinazione. In caso di errori, avvisi o risposte poco chiare, verificare prima che cosa sia stato effettivamente applicato; non aggirare il problema con un secondo nome, un gruppo più ampio o un percorso non protetto. Se la sintassi o l’associazione dell’upload non sono chiarite, fermarsi e coinvolgere il supporto fornendo dati depurati. Solo dopo aver confermato il salvataggio, eseguire i test positivi e negativi già previsti per MFA, backend, sessione, logout, reindirizzamento e percorsi alternativi. La verifica documentale non sostituisce il collaudo sul proprio firewall.

Algoritmo OTP e app Authenticator

SFOS 22 supporta, oltre a SHA1, anche SHA256 e SHA512 per i token OTP. Questo è sensato dal punto di vista della sicurezza, ma funziona solo se l’app Authenticator utilizzata supporta l’algoritmo scelto.

Punti importanti:

• SHA256 o SHA512 sono più sicuri di SHA1.
• Non tutte le app Authenticator supportano questi algoritmi in questo contesto.
• Microsoft Authenticator può scansionare il codice QR con SHA256 o SHA512, ma il login può fallire successivamente.
• Se l’algoritmo viene modificato, i vecchi token devono essere eliminati e scansionati nuovamente.
• Le modifiche al timestep del token valgono solo per i token generati di nuovo e devono corrispondere all’app utilizzata.

Per i rollout produttivi, si dovrebbe testare l’app desiderata e l’algoritmo con un piccolo gruppo pilota. Solo successivamente gli utenti esistenti dovrebbero essere migrati ampiamente.

Se un utente perde l’app o l’algoritmo viene modificato, spesso non basta ripetere la comunicazione agli utenti. In Authentication > Multi-factor authentication > Issued tokens è possibile reimpostare token o generare codici monouso aggiuntivi. Questo processo dovrebbe essere regolato internamente perché ha un forte impatto sulla sicurezza.

Validazione e operatività

Piano di test dopo la configurazione

Dopo la configurazione, non si dovrebbe solo verificare se appare la pagina di login. È importante testare l’intero percorso di accesso.

1. Utilizzare un browser esterno o una rete di test esterna.
2. Aprire l’URL WAF con un utente del gruppo consentito.
3. Testare il login con password corretta e OTP.
4. Testare il login con OTP errato.
5. Testare utenti al di fuori del gruppo consentito.
6. Verificare la scadenza della sessione dopo inattività.
7. Verificare la funzione backend dell’applicazione.
8. Controllare Log Viewer e reverseproxy.log per anomalie.
9. Verificare logout, nuovo login e scadenza della sessione con lo stesso browser.
10. Testare un secondo hostname o un percorso alternativo se l’applicazione utilizza più regole WAF.

Per verificare anche il ritorno all’URL richiesto in SFOS 23, aprire un URL effettivamente protetto con un percorso diverso da /, senza una sessione WAF valida. Dopo un login riuscito con password e OTP, con RedirectToRequestedURL impostato su Enable, verificare che venga raggiunto esattamente l’URL richiesto originariamente e che l’accesso al backend rispetti le autorizzazioni previste. Un reindirizzamento riuscito da solo non dimostra MFA né l’autorizzazione all’accesso; tutti i test precedenti di rifiuto, backend, sessione, logout, nuovo login e percorsi alternativi rimangono necessari.

Per i file di log aiuta Sophos Firewall Troubleshooting: Servizi e Log. Gli eventi WAF sono tipicamente collegati al Reverse Proxy e appaiono anche nel Log Viewer.

Per l’accettazione, ogni caso di test dovrebbe essere associato a un risultato visibile:

• Utente: appare il login del firewall, viene richiesto l’OTP, poi si apre l’applicazione prevista.
• Sophos Firewall: Log Viewer e reverseproxy.log mostrano autenticazione WAF consentita o rifiutata.
• Fonte di autenticazione: AD, LDAP, RADIUS o fonte utente locale mostra il login riuscito o fallito previsto.
• Backend: l’applicazione raggiunge lo stato utente o guest corretto e non mostra una seconda pagina di errore inattesa.

Se il browser sembra funzionare, ma non sono visibili i log corrispondenti, la validazione è incompleta. Occorre quindi verificare se viene applicata la regola WAF corretta, se la politica di autenticazione è effettivamente attiva e se i log arrivano nel punto previsto.

Go-live e operatività dopo l’attivazione

Dopo un test riuscito, WAF-MFA non dovrebbe essere semplicemente attivato ampiamente e poi dimenticato. Le prime ore dopo il go-live sono importanti, poiché gli utenti reali portano browser diversi, app Authenticator diverse, password salvate, vecchi segnalibri e altri stati di sessione rispetto a un test amministrativo.

Per il go-live è utile un piccolo piano operativo:

• Gruppo di rollout: prima gruppo pilota, poi altri gruppi di utenti.
• Finestra di supporto: tenere disponibili helpdesk o amministratori responsabili durante i primi login.
• Monitoraggio: osservare Log Viewer, reverseproxy.log e fonte di autenticazione.
• Reset del token: procedura chiara per token OTP persi o configurati erroneamente.
• Comportamento della sessione: verificare Session timeout e Session lifetime in base all’uso reale.
• Percorso di fallback: tenere documentati WAF rule, Authentication Policy e passaggi di modifica.

Per applicazioni critiche per il business, non si dovrebbe programmare il go-live in un momento in cui nessuno può verificare correttamente i problemi di login. È meglio una finestra controllata con utenti di test di diversi gruppi, poi una breve revisione dei log e solo successivamente l’espansione ad altri utenti.

Dopo alcuni giorni, la configurazione dovrebbe essere nuovamente verificata:

• Ci sono utenti che aggirano MFA perché accedono tramite un’altra regola WAF o un altro URL?
• L’accesso è ancora consentito solo per i gruppi pianificati?
• La durata della sessione e il timeout di inattività si adattano all’applicazione?
• I login rifiutati e i problemi con i token vengono effettivamente rilevati in operatività?
• Ci sono casi di supporto che indicano una comunicazione utente poco chiara o un’app Authenticator errata?
• Sono state rimosse vecchie regole di test, domini di test o eccezioni temporanee?

Questo follow-up è particolarmente importante se più nomi host, percorsi o regole WAF puntano alla stessa applicazione. Altrimenti, può succedere che un percorso sia protetto correttamente con MFA, ma un secondo percorso rimanga accessibile senza autenticazione preliminare.

Risoluzione dei problemi

Altri errori frequenti

• Authentication Policy non usa Form: il comportamento MFA non corrisponde alla configurazione WAF prevista.
• Sophos Authenticator pianificata come nuova app standard: L’app è EOL e non dovrebbe più essere usata come base per un nuovo rollout.
• Fallback access dipende dalla stessa WAF rule: gli amministratori non possono annullare correttamente la modifica in caso di errore.
• Rollout del token non testato: gli utenti falliscono al primo login anche se la WAF rule è tecnicamente corretta.
• Un secondo URL o una seconda WAF rule rimane attiva senza MFA: gli utenti aggirano involontariamente MFA preliminare.
• Eccezioni temporanee del pilota non rimosse: la protezione produttiva è incoerente e difficile da auditare.

MFA non viene richiesto

Verificare prima se Web application firewall è attivato sotto Require MFA for. Poi controllare se la regola WAF utilizza effettivamente una politica di autenticazione e se questa politica contiene gli utenti o i gruppi previsti.

Il login funziona, ma l’applicazione non si apre

In tal caso, il problema si trova spesso dopo il login del firewall. Verificare raggiungibilità del backend, certificato, intestazione host, percorso, politica di protezione e inoltro dell’autenticazione. Se il backend si aspetta autenticazione propria, la modalità di inoltro deve adattarsi.

L’utente non può accedere dopo il cambio di algoritmo

Se si è passati da SHA1 a SHA256 o SHA512, i token esistenti devono essere eliminati e scansionati nuovamente. Inoltre, l’app Authenticator deve supportare il nuovo algoritmo.

Il backend richiede di nuovo il login dopo MFA riuscita

In SFOS 22.0 GA Respin Build 411 può verificarsi NC-177509: la WAF-MFA basata su form riesce, ma il backend richiede poi un ulteriore login che non può essere bypassato. Il codice OTP non viene separato dalla password prima che il firewall inoltri le credenziali al backend. Il problema è risolto a partire da SFOS 22.0 MR1 Build 490.

La correzione del codice OTP non rimosso ha anche il riferimento NC-177201. Gli ID non sono intercambiabili: NC-177509 associa le build interessate e corrette, mentre NC-177201 identifica il testo specifico del fix. In un ticket di supporto indicare sintomo, build ed entrambi i riferimenti.

Verificare:

• La WAF Authentication Policy usa Form.
• Authentication forwarding mode è attivo ed è adatto all’applicazione backend.
• La WAF rule interessata usa esattamente questa Authentication Policy.
• L’errore avviene dopo una MFA riuscita, non già durante il login al firewall.
• reverseproxy.log, Log Viewer e il log degli accessi del backend coprono lo stesso momento di test.
• È stata verificata la versione SFOS in uso.

Su un sistema GA interessato, salvare reverseproxy.log, Log Viewer e il log del backend e pianificare l’aggiornamento a MR1 Build 490 o successivo. Se non è possibile aggiornare tempestivamente, non apportare modifiche non verificate al flusso di autenticazione; usare i dati salvati per aprire un ticket al supporto Sophos. Non ridurre genericamente la protezione MFA e non cambiare Authentication Forwarding alla cieca: None è adatto solo se il backend non richiede credenziali inoltrate. Per i portali di produzione, il piano deve includere utenti di test, rollback e comunicazione agli utenti.

Troppe o vecchie sessioni

Verificare timeout della sessione, durata della sessione e impostazioni globali delle sessioni WAF. In ambienti produttivi dovrebbe essere chiaro se sono desiderate sessioni lunghe o se gli utenti devono autenticarsi nuovamente rapidamente dopo inattività.

Checklist

• La regola WAF è documentata e testata esternamente.
• Il certificato HTTPS corrisponde al nome host pubblicato.
• MFA si applica al gruppo di utenti corretto.
• Require MFA for > Web application firewall è attivato.
• La politica di autenticazione WAF utilizza Form.
• L’inoltro dell’autenticazione si adatta all’applicazione backend.
• Rollout del token, accesso al portale e procedura dell’helpdesk sono preparati.
• Timeout della sessione e durata della sessione sono impostati consapevolmente.
• App OTP e algoritmo hash sono stati testati.
• L’accesso amministrativo di fallback è disponibile.
• Rollback e persona responsabile sono documentati.
• Fonte di autenticazione e login backend sono stati verificati separatamente.
• Log Viewer e reverseproxy.log sono stati controllati dopo il test.
• Finestra di supporto per il go-live e procedura di reset del token sono stabiliti.
• Nomi host alternativi, percorsi e regole WAF sono stati controllati per l’aggiramento di MFA.
• Le eccezioni temporanee del pilota sono state rimosse dopo il rollout.

Domande frequenti