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 concetto di autorizzazione pulito. È 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.

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.

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. Se è necessario WebDAV, bisogna essere particolarmente cauti: Sophos WAF non supporta correttamente WebDAV, il che può essere rilevante per applicazioni come Nextcloud.

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.

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 backend pulite riducono ulteriormente il rischio.

Prerequisiti

Prima della configurazione, dovrebbero essere chiariti questi punti:

• L’applicazione web è già pianificata o pubblicata tramite una regola WAF.
• 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 “rotto” 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 dovrebbe limitare le fonti. 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.

Componenti della configurazione

Per WAF-MFA devono essere allineate diverse impostazioni:

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. Salvare la configurazione.

Se gli utenti devono configurare il loro token autonomamente, devono avere accesso a un portale in cui viene visualizzato il codice QR. In molti ambienti, per questo è rilevante il User Portal o il VPN Portal. La pianificazione generale di MFA è descritta in Abilitare MFA per Sophos Firewall WebAdmin, VPN Portal e Accesso Remoto.

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:

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 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, la modalità client dovrebbe essere impostata su Form. Con l’autenticazione basata su form, il firewall può gestire il login tramite un 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.

Scegliere correttamente l’inoltro dell’autenticazione

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

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.

⚠️ 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.

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.

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.

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.

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

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

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.

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.

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:

Se solo il browser sembra funzionare correttamente, ma non sono visibili log appropriati, l’accettazione è incompleta. Si dovrebbe quindi verificare se la regola WAF corretta corrisponde, se la politica di autenticazione è effettivamente attiva e se i log finiscono nel luogo 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:

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.

Errori tipici

Risoluzione dei problemi

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 riscanalizzati. Inoltre, l’app Authenticator deve supportare il nuovo algoritmo.

Password e OTP vengono trasmessi al backend

Con WAF-MFA, si dovrebbe verificare se la versione del firewall è aggiornata. Nelle Note di rilascio di SFOS-22.0 è documentato un errore WAF risolto, in cui il codice OTP non veniva rimosso dalla password prima che i dati fossero trasmessi al backend.

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