Vai al contenuto
Avanet
Accedi

Attivare MFA per Sophos Firewall WebAdmin, VPN Portal e Remote Access

Sophos Firewall

Per la funzione OTP locale, aprire Authentication > Multi-factor authentication, selezionare prima Specific users and groups, attivare i servizi necessari e testare tutto con un gruppo pilota. All users deve essere utilizzato solo dopo aver completato i test con esito positivo.

MFA protegge WebAdmin, VPN Portal e l’accesso remoto dall’uso della sola password rubata. Non sostituisce però regole di accesso restrittive né un accesso di emergenza verificato. Questo articolo descrive quindi l’intero processo, dall’attivazione sicura alla scelta dell’app, al ripristino e al troubleshooting.

La procedura principale configura Sophos OTP locale. RADIUS ed Entra ID SSO vengono confrontati più avanti come alternative.

Attivare Sophos OTP in sicurezza

Le procedure seguenti distinguono le funzionalità MFA documentate di SFOS 22 e SFOS 23. In particolare, Share QR code e il periodo di validità del QR descritto non devono essere applicati a SFOS 22. Le limitazioni delle app si riferiscono alla procedura di registrazione Sophos documentata, non indistintamente a ogni versione attuale delle app. Prima del rollout vengono quindi verificati con il gruppo pilota la build SFOS installata, il sistema operativo mobile, la versione specifica dell’app e ogni servizio necessario.

Prima dell’attivazione

Prima della prima modifica, chiarire i seguenti punti:

  • Il firewall utilizza l’ora corretta in Administration > Time, preferibilmente tramite NTP.
  • Utenti e gruppi sono disponibili localmente o tramite AD, LDAP oppure un altro server di autenticazione.
  • Esistono un gruppo pilota e un secondo amministratore verificato.
  • Sono note la console e la procedura di ripristino per l’admin predefinito.
  • Sono disponibili un backup recente e una procedura documentata per il reset dei token.

Per Active Directory classico, Aggiungere Active Directory a Sophos Firewall spiega come configurare l’origine utenti.

In Administration > Device access si stabilisce da quali zone siano raggiungibili WebAdmin, User Portal, VPN Portal e gli altri servizi locali. Le Local service ACL exception rules limitano ulteriormente l’accesso alle reti di gestione, alle reti VPN o agli indirizzi sorgente noti. Proteggere l’accesso a Sophos Firewall: configurare correttamente Device Access illustra nel dettaglio la procedura di hardening.

SSH non rientra tra i servizi protetti da Sophos OTP. Deve essere limitato tramite Device Access e, dove possibile, utilizzare una chiave pubblica; la procedura è descritta in Connettersi a Sophos Firewall tramite SSH.

⚠️ MFA riduce il rischio associato alle password compromesse, ma non diminuisce la superficie di attacco di un servizio accessibile pubblicamente. WebAdmin, SSH e i portali non devono mai essere esposti più del necessario.

Prima dei test negativi, controllare anche Administration > Admin and user settings > Login security > Block login. Diversi tentativi errati intenzionali possono bloccare l’IP sorgente per WebAdmin, CLI, VPN Portal e User Portal, escludendo anche un amministratore di fallback dalla stessa rete. Deve quindi essere disponibile una seconda origine o l’accesso alla console.

Configurare MFA per un gruppo pilota

  1. Accedere a WebAdmin e aprire Authentication > Multi-factor authentication.
  2. In One-time password (OTP), selezionare prima Specific users and groups.
  3. Aprire Add users and groups, selezionare il gruppo pilota e applicare la selezione.
  4. Attivare Generate OTP token with next sign-in se si utilizza un’app di autenticazione. In SFOS 23, selezionare anche Share QR code: Email invia il codice QR all’indirizzo e-mail dell’utente al successivo accesso a VPN Portal o User Portal. Portals lo mostra in User Portal e VPN Portal dopo il successivo accesso a VPN Portal, User Portal o WebAdmin. Questa scelta non riguarda la procedura guidata dell’admin predefinito descritta più avanti.
  5. In Require MFA for, selezionare soltanto le interfacce di accesso realmente necessarie.
  6. In OTP hash algorithm, scegliere un algoritmo supportato dall’app prevista.
  7. Modificare le impostazioni facoltative OTP timestep settings solo se l’app supporta lo stesso intervallo; il valore predefinito è 30 secondi.
  8. Salvare con Apply.
Sophos Firewall Authentication > Multi-factor authentication con selezione degli utenti, servizi protetti e algoritmo hash OTP
In questa schermata si definiscono gli utenti MFA, i servizi protetti e l’algoritmo hash OTP. I valori visualizzati All users e SHA1 non sono raccomandazioni per il rollout.

Dopo Apply, completare subito la procedura con un utente pilota: in base al servizio selezionato, accedere prima a User Portal o VPN Portal usando solo la password, registrare il codice QR o la chiave Base32 nell’app di autenticazione e aprire poi una nuova sessione con <password><passcode>. Un codice intenzionalmente errato deve essere rifiutato e il tentativo deve comparire in Log viewer. Valutare All users solo dopo questo test positivo e negativo.

Le opzioni utente significano:

  • No OTP: MFA è disattivata.
  • All users: MFA si applica a tutti gli utenti; utilizzare questa opzione solo dopo il test pilota.
  • Specific users and groups: MFA si applica esclusivamente agli account o ai gruppi selezionati.

Per gli utenti autenticati esternamente, la rimozione da un gruppo MFA non ha effetto immediato al primo login successivo. Sophos richiede ancora un accesso con MFA; l’OTP non è più necessario soltanto negli accessi seguenti. Una modifica del gruppo va quindi verificata con una nuova sessione e almeno due login controllati.

Quando Generate OTP token with next sign-in è attivo, gli utenti registrano un’app software al login successivo. User Portal viene selezionato automaticamente come servizio MFA. Se l’opzione è disattivata, i token hardware o gestiti manualmente vengono assegnati in Issued tokens.

Con Email, verificare prima del pilota che sia configurato l’indirizzo corretto dell’utente e che la consegna funzioni. Il codice QR contiene il segreto del token: proteggere l’accesso alla casella di posta e non includere il codice QR o la chiave Base32 in ticket o screenshot non protetti. In caso di mancata consegna, verificare prima l’indirizzo e l’invio delle e-mail, senza provocare un blocco dell’accesso tramite ripetuti tentativi di accesso falliti. Per un pilota senza consegna tramite e-mail, Portals è l’alternativa documentata; l’accesso al portale deve essere possibile dalla rete prevista.

Selezionare consapevolmente i servizi

In SFOS 22 sono disponibili i seguenti servizi sotto Require MFA for:

  • User portal
  • Web admin console
  • VPN portal
  • SSL VPN remote access
  • IPsec remote access
  • Web application firewall

MFA per User Portal si applica anche a Captive Portal e Client Authentication Agents. Gli utenti di accesso remoto devono prima registrare il token tramite VPN Portal o User Portal.

Per WAF, la sola selezione del servizio non è sufficiente. Da SFOS 22 sono necessari Webserver Protection, una Authentication Policy basata su moduli e la relativa assegnazione alla regola WAF. La procedura completa è descritta in Proteggere Sophos Firewall WAF con MFA.

Scegliere il modello MFA adatto

Sophos OTP locale

Sophos OTP gestisce i token direttamente sul firewall e non richiede un’ulteriore infrastruttura RADIUS o di Identity Provider. È particolarmente adatto per utenti locali normali, piccoli ambienti e per applicare rapidamente l’hardening a WebAdmin o all’accesso remoto.

Il compromesso per la semplicità di implementazione è un token separato dai processi Microsoft 365 esistenti. Utenti e help desk devono conoscere la registrazione dell’app, l’inserimento di password più OTP e la procedura per il cambio di dispositivo.

RADIUS o Entra ID SSO

Una piattaforma MFA esistente può integrarsi meglio nella gestione centralizzata delle identità tramite RADIUS o SSO. Richiede tuttavia test specifici per ogni servizio:

  • VPN Portal non supporta RADIUS con MFA challenge.
  • Sophos Connect non supporta una challenge OTP. Il client invia insieme password e OTP nel formato passwordotp, ma supporta MFA tramite chiamata e notifica push.
  • User Portal e WebAdmin supportano inoltre MFA basata su challenge.
  • Con Entra ID SSO, MFA viene eseguita presso l’Identity Provider; la MFA locale di Sophos OTP non può essere aggiunta allo stesso login SSO.
  • Entra SSO con Sophos Connect richiede almeno la versione 2.4 del client su Windows. WebAdmin SSO non è disponibile sul dispositivo ausiliario HA.

Per il Remote Access è disponibile la guida dedicata Configurare Microsoft Entra ID SSO per Sophos Connect e VPN Portal. Se invece Entra deve controllare il login WebAdmin e i ruoli amministratore, Entra ID SSO per WebAdmin di Sophos Firewall descrive Role mapping, privilegi minimi, login pilota e accesso locale di emergenza.

Sophos Connect o SSL VPN: quale soluzione scegliere? aiuta a scegliere il modello di accesso remoto; prima del rollout è inoltre opportuno controllare la versione del client Sophos Connect.

Indipendentemente dal modello, iniziare con un gruppo pilota. Aggiungere altri utenti solo dopo aver verificato WebAdmin, i portali, i client VPN reali, i gruppi, i timeout, il logging e il fallback.

Configurare token e app di autenticazione

Registrare e gestire i token

Quando Generate OTP token with next sign-in è attivo, l’utente accede a VPN Portal o User Portal e registra il codice QR in un’app compatibile. In SFOS 22 il QR viene visualizzato; gli amministratori possono registrare il token anche in WebAdmin se MFA viene applicata a tale servizio. In SFOS 23 la distribuzione segue Share QR code: con Email, usare il QR ricevuto via e-mail; con Portals, quello visualizzato nei portali. Un accesso WebAdmin può attivare la visualizzazione nei portali con Portals, ma non l’invio via e-mail. La registrazione riguarda solo gli utenti e i gruppi per i quali è configurata MFA.

Per la registrazione iniziale in SFOS 23 con Generate OTP token with next sign-in su ON, agli utenti MFA selezionati si applica questa regola: il QR generato scade se non viene usato per accedere entro 24 ore dalla generazione. Per generarne uno nuovo, l’utente accede a VPN Portal o User Portal con la sola password; il nuovo QR viene distribuito secondo Email o Portals. Registrarlo poi nell’app e verificare un nuovo accesso con <password><passcode>. Questa durata del QR è distinta dalla finestra di 300 secondi del primo codice. Il flusso non si applica a un token emesso con stato OFF né alla riemissione manuale di un seed; non viene presunto per SFOS 22 né per ogni flusso della procedura guidata dell’admin predefinito.

In Authentication > Multi-factor authentication > Issued tokens è possibile controllare, disattivare temporaneamente, eliminare o aggiungere manualmente i token emessi. È inoltre possibile generare codici monouso aggiuntivi e controllare o sincronizzare lo scostamento temporale di un token.

Impostare lo stato del token su OFF impedisce all’utente di accedere; non autorizza l’accesso con la sola password. Non equivale all’eliminazione seguita da una nuova registrazione né all’esclusione di MFA per un solo accesso tramite CLI Main Menu > 2. System Configuration.

In caso di smarrimento dello smartphone o cambio di app, verificare prima l’identità dell’utente. Immediatamente prima dell’eliminazione, controllare in Authentication > Multi-factor authentication che Generate OTP token with next sign-in sia su ON; in SFOS 23, impostare anche Share QR code su Email o Portals. Se la modalità manuale OFF è intenzionale, preparare invece la riemissione manuale con un nuovo seed; il flusso QR automatico seguente non si applica. Solo dopo eliminare il vecchio token in Issued tokens. L’utente accede una volta a VPN Portal o User Portal con la sola password e registra il nuovo QR: SFOS 22 lo visualizza, mentre SFOS 23 lo invia via e-mail o lo mostra nel portale secondo la scelta. Verificare poi un nuovo accesso con <password><passcode>. Un vecchio token non deve continuare a esistere in parallelo senza controllo.

Per questo flusso di cambio app o sostituzione in SFOS 23, il QR generato scade se non viene usato per accedere entro 24 ore dalla generazione. Accedere nuovamente con la sola password genera un nuovo QR, distribuito ancora tramite Email o Portals. Le 24 ore riguardano il QR, non la finestra di 300 secondi del primo codice spiegata più avanti. Questa durata del QR non viene presunta per SFOS 22 né per ogni flusso della procedura guidata dell’admin predefinito.

L’elenco può contenere anche token preparati manualmente senza assegnazione a un utente; a questi è possibile assegnare un utente in seguito. Sono inoltre presenti i token assegnati manualmente e quelli di utenti e amministratori che hanno registrato il codice QR. Una voce nell’elenco non dimostra quindi da sola un accesso MFA riuscito: prima della consegna, verificare l’assegnazione all’utente, lo stato del token e l’accesso effettivo.

Dopo l’eliminazione, il codice di accesso del vecchio token non è più valido e non deve essere aggiunto durante l’accesso di registrazione con la sola password. Un’eliminazione non può essere annullata inserendo nuovamente il vecchio codice; il metodo di ripristino sicuro è una riemissione controllata. Prima dell’eliminazione, verificare quindi l’accesso al portale, la consegna o la consegna manuale del seed e la soluzione di fallback. In presenza di più utenti, procedere per fasi e convalidare ogni nuova registrazione prima di migrare il gruppo successivo.

Provisionare manualmente un token hardware o software

Anche in modalità manuale, configurare prima Specific users and groups con il gruppo pilota e i servizi necessari in Require MFA for, scegliere l’algoritmo compatibile e il timestep e salvare con Apply. Quindi, nella finestra di dialogo Add token (for hardware tokens), selezionare OTP hash algorithm per il token da creare prima di compilare Secret, l’utente e, se necessario, Use custom timestep, e salvare con Save. La sola selezione di un valore predefinito globale non sostituisce né l’assegnazione del token né il successivo accesso pilota.

Se il firewall non deve generare un codice QR, lasciare disattivato Generate OTP token with next sign-in. I token già registrati continuano a funzionare; per i nuovi utenti, il seed viene inserito manualmente in Authentication > Multi-factor authentication > Issued tokens > Add token (for hardware tokens). Il nome del pulsante è più limitato della funzione, perché la stessa finestra consente anche di provisionare manualmente un token software.

Selezionare prima OTP hash algorithm e il timestep richiesto dal token specifico o dall’app di autenticazione. Per Secret valgono queste regole:

  • Per un token hardware, inserire la chiave individuale fornita dal produttore.
  • Per un token software, usare un seed esadecimale univoco e sufficientemente casuale. Se l’app richiede Base32, convertire localmente il seed con uno strumento offline controllato.
  • Un seed di produzione non deve essere inserito in un sito pubblico di conversione né incluso in un ticket, un’e-mail non cifrata o un comando shell conservato nella cronologia. Chi conosce il seed può generare codici OTP validi.

Se il singolo token differisce dal Default token timestep globale, attivare Use custom timestep solo per quel token e inserire l’intervallo effettivamente supportato. Senza questa opzione si applica il valore globale; verificare la compatibilità dell’app e dell’hardware prima di salvare.

Selezionare quindi l’utente esatto previsto e salvare con Save. Il token hardware o il seed Base32 viene consegnato una sola volta tramite un canale protetto. Successivamente si provano un codice corretto e uno volutamente errato e, se necessario, si sincronizza lo scostamento temporale in Issued tokens. Se il seed potrebbe essere stato esposto, il token non deve essere riutilizzato: va eliminato e ne va emesso uno nuovo con un nuovo seed.

Automazione tramite API: separare impostazioni e stato del token

Nell’automazione tramite API, OTPSettings e OTPTokens hanno due funzioni diverse: le impostazioni definiscono l’ambito di applicazione di MFA, i servizi e i valori globali; il record del token si riferisce a un singolo token emesso. Una modifica delle impostazioni non sostituisce né l’assegnazione all’utente né la registrazione né l’accesso pilota.

In OTPSettings si utilizzano i valori documentati 0 e 1 per le opzioni, non le etichette della GUI o Enable/Disable:

  • otp disattiva o attiva OTP. allUsers=0 limita l’ambito di applicazione agli utenti o ai gruppi selezionati esplicitamente; non attiva di per sé OTP. Per il pilota, mantenere una selezione ristretta anziché impostare allUsers=1. L’esempio mostra la selezione in otpUsers/user, ma la tabella dei parametri non definisce una codifica degli ID utente per questo campo. Non costruire identità a partire da nomi o ID presunti.
  • tokenAutoCreation controlla la generazione automatica dei token, non lo stato di un token già emesso. otpUserPortal, otpVPNPortal, otpSSLVPN, otpWebAdmin e otpIPsec corrispondono a User Portal, VPN Portal, SSL VPN Remote Access, WebAdmin e IPsec Remote Access. Selezionare solo i servizi necessari; durante la verifica, tenere comunque conto della selezione automatica di User Portal prevista dalla procedura nella GUI.
  • Solo SFOS 23 documenta il campo facoltativo qrCodeVia, con i valori esatti email o portal. Le etichette della GUI Email e Portals non sono valori letterali dell’API. Non è documentato un valore predefinito dell’API; questo campo non è presente nella documentazione di riferimento di SFOS 22.

Trattare separatamente i valori temporali: OTPSettings/defaultTimeStep è l’intervallo globale dei token, OTPSettings/maxTimeStepsInterval è la finestra di verifica per gli utilizzi successivi e OTPSettings/maxInitialTimeStepDiff è la finestra al primo utilizzo. OTPTokens/timeStep è invece l’intervallo del singolo token. L’API indica, rispettivamente, 10–300 secondi, 0–10 intervalli temporali, 0–600 intervalli temporali e 10–300 secondi come limiti di validazione. Non si tratta né di raccomandazioni operative né di valori predefiniti dell’API; le colonne dei valori predefiniti sono vuote. I valori predefiniti della GUI descritti sopra e la compatibilità delle app restano aspetti distinti.

Per il token, active, autoCreated e lastLogin riguardano rispettivamente lo stato, l’origine e l’ultimo accesso riuscito, non la selezione globale di MFA. Non compilare lastLogin o autoCreated come campi obbligatori di un’automazione. Anche l’esempio del token non costituisce uno schema di importazione validato: utilizza OTPTokens/user, mentre la tabella indica userid. Nella guida MFA, Sophos richiede un <tokenid/> vuoto per l’importazione tramite API; anche l’esempio del token lo mostra, ma la tabella dell’API indica una lunghezza minima di 1 carattere. Non risolvere questa contraddizione con ID inventati o con uno schema di scrittura presunto universalmente valido.

XML-Delete non è un’importazione di token. La documentazione di riferimento Delete OTP Token per SFOS 22 e SFOS 23 identifica un token esistente tramite tokenid; è documentata una singola stringa di 1–32 caratteri. Prima dell’eliminazione, leggere il record del token salvato da una vista aggiornata e attendibile e verificarne l’identificativo e l’assegnazione all’esatto utente previsto. Né user né userid né il <tokenid/> vuoto della guida all’importazione sostituiscono questo identificativo per l’eliminazione. L’indicazione Mandatory: No nella tabella non autorizza a omettere l’identificativo, inventarlo o ricavarlo da un nome utente. Se l’identità o lo schema appropriato per la versione non sono chiari, non procedere all’eliminazione, ma chiarire prima l’assegnazione o lo schema.

Prima di XML-Delete, mantenere disponibili il fallback verificato, l’accesso di gestione e l’accesso alla console; la verifica dell’utente e la preparazione della riemissione automatica o manuale descritte sopra restano valide senza modifiche. Restano inoltre valide le limitazioni per l’admin predefinito. Dopo la chiamata, leggere nuovamente l’elenco dei token e verificare che sia stato rimosso esattamente il vecchio token previsto e che gli altri token siano rimasti invariati. Procedere quindi con la riemissione preparata e verificare un accesso MFA riuscito in una nuova sessione; mantenere disponibile il fallback fino al completamento del collaudo. Una risposta da sola non sostituisce né questo controllo dell’elenco dei token né il test MFA.

La documentazione di riferimento per Delete riporta 200 con il simbolo di messaggio non risolto OTPTokenDeleted e 500 con OTPTokenNotThere. Si tratta di indicazioni della documentazione, non di messaggi confermati in fase di esecuzione né di garanzie relative a uno stato HTTP, alla ripetibilità o alla sicurezza di un nuovo tentativo automatico. Da queste indicazioni non si ricava né una richiesta XML eseguibile né una struttura contenitore della richiesta.

L’importazione tramite API non equivale alla finestra di dialogo manuale Add token. Prima di un’importazione in produzione, verificare il backup e l’accesso consentito all’API, chiarire quale schema sia appropriato per la versione e non memorizzare seed in log delle richieste non protetti. Successivamente, controllare le impostazioni salvate, la selezione ristretta degli utenti, l’assegnazione dei servizi e lo stato dei token, oltre a verificare l’accesso pilota descritto. Una chiamata API riuscita non costituisce da sola un collaudo MFA.

Fornire codici monouso aggiuntivi in modo controllato

Se l’accesso all’app o al token hardware manca solo temporaneamente, modificare l’utente interessato in Authentication > Multi-factor authentication > Issued tokens. In Additional codes, il pulsante più genera codici aggiuntivi; Save li associa al token. Il firewall rimuove automaticamente ogni codice dall’elenco dopo che è stato utilizzato.

Verificare l’identità dell’utente prima di fornire i codici. Consegnarli una sola volta tramite un canale protetto esclusivamente a tale utente e non inserirli tutti insieme in un ticket o in un’e-mail non protetta. I codici aggiuntivi non sostituiscono la riemissione di un token definitivamente smarrito o potenzialmente copiato: eliminare il vecchio token e registrarne uno nuovo con un nuovo seed.

App e algoritmo hash devono essere compatibili

SFOS 22 supporta SHA1, SHA256 e SHA512. Sophos raccomanda SHA256 o SHA512, ma l’algoritmo scelto deve essere supportato dall’app:

  • Sophos Intercept X for Mobile e Google Authenticator supportano SHA256 e SHA512.
  • Microsoft Authenticator non supporta questi due algoritmi in questo flusso Sophos. La scansione del codice QR può comunque riuscire, ma il login successivo non va a buon fine.
  • Duo Mobile e Okta Verify rientrano tra le app indicate da Sophos; la loro compatibilità con il codice QR e l’algoritmo deve corrispondere al sistema operativo e alla configurazione utilizzati.
  • App TOTP diverse vengono approvate solo dopo un vero test pilota.

Sophos Intercept X for Mobile supporta un timestep personalizzato per i token. La maggior parte delle altre app di autenticazione supporta soltanto il valore predefinito di 30 secondi, quindi il valore globale non viene modificato esclusivamente per una singola app.

Su iOS, la scansione del codice QR Sophos non funziona con Google Authenticator, Duo Mobile e Microsoft Authenticator. L’account deve essere creato manualmente usando la chiave Base32 visualizzata. Okta Verify richiede la registrazione manuale tramite Base32 sia su iOS sia su Android. Questo però non risolve la mancata compatibilità di Microsoft Authenticator con SHA256/SHA512.

La precedente app Sophos Authenticator è End of Life dal 31 luglio 2022 e non deve più essere prevista per nuovi rollout.

Dopo un upgrade da una versione precedente a SFOS 22, occorre prevedere la presenza di token SHA1, perché le versioni SFOS precedenti generavano i token MFA con SHA1. La selezione di un algoritmo globale più robusto non converte questi token esistenti.

Per migrare da SHA1 a un algoritmo più robusto:

  1. Testare l’app pilota con SHA256 o SHA512.
  2. Attivare Generate OTP token with next sign-in. In SFOS 23, scegliere anche Email o Portals in Share QR code prima di Apply.
  3. Selezionare il nuovo algoritmo in Authentication > Multi-factor authentication.
  4. Salvare con Apply.
  5. Eliminare i vecchi token SHA1 in Issued tokens. Per eliminare il token dell’admin predefinito, accedere come tale utente; un altro amministratore non può eliminarlo. Tenere pronti in anticipo l’accesso di fallback verificato e l’accesso alla console.
  6. Fare accedere gli utenti normali a VPN Portal o User Portal con la sola password e registrare nuovamente il QR o la chiave Base32 in un’app compatibile con SHA256/SHA512. In SFOS 23 la distribuzione del QR segue Email o Portals. Per l’admin predefinito, la nuova registrazione dopo l’eliminazione inizia invece con un accesso WebAdmin con la sola password, non tramite User Portal o VPN Portal; seguire il flusso di registrazione visualizzato lì. Questa è la migrazione SHA, non Use an existing token nella procedura guidata di riattivazione. Non presumere un ulteriore selettore Share QR code nella procedura guidata per questa eccezione.
  7. Eseguire test di accesso controllati con un passcode corretto e uno errato.

Durante la migrazione possono coesistere token con algoritmi diversi. I token non eliminati continuano però a utilizzare il vecchio algoritmo.

Limitare il timestep e le finestre di tolleranza

In OTP timestep settings si configurano non solo l’intervallo per i nuovi codici, ma anche due finestre di verifica. I tre valori hanno effetti diversi:

  • Default token timestep definisce l’intervallo con cui l’app o il token hardware genera un nuovo codice. Il valore predefinito è 30 secondi. Una modifica si applica solo ai token generati successivamente e non cambia quelli esistenti.
  • Maximum verification code offset determina per quanti intervalli rimane valido un codice non ancora utilizzato. Con il valore predefinito 2 e un intervallo di 30 secondi vengono accettati anche i codici non utilizzati dei 60 secondi precedenti.
  • Maximum initial verification code offset si applica al primo codice dopo la scansione del codice QR. Con il valore predefinito 10 e un intervallo di 30 secondi, la finestra è di 300 secondi se il codice non è già stato utilizzato.

Queste finestre non sostituiscono una corretta sincronizzazione dell’ora. Controllare prima l’NTP del firewall e l’ora dell’endpoint, quindi mantenere ogni offset al valore più basso compatibile con le app e i token hardware utilizzati. Una finestra più ampia accetta più a lungo un codice intercettato e non ancora utilizzato. Dopo una modifica, testare un nuovo token pilota; non presumere che un token esistente utilizzi il timestep modificato.

Inserire correttamente password e OTP

Per i login nativi Sophos OTP, il formato ufficiale è <password><passcode>, senza spazi o separatori.

Esempio:

Password:   LaMiaPasswordSicura
Codice OTP: 123456
Inserimento: LaMiaPasswordSicura123456

Sophos Connect può visualizzare un terzo campo separato tramite otp: true. Il client aggiunge internamente il codice alla password. Questa visualizzazione non modifica il formato inviato al server di autenticazione.

Proteggere e ripristinare l’amministratore predefinito

Attivare MFA per l’admin predefinito

L’utente locale admin predefinito non viene attivato tramite il normale elenco utenti. La sua procedura guidata dedicata si trova in Administration > Device access, non in Issued tokens > Add token (for hardware tokens) per gli utenti normali.

Prima devono essere funzionanti un secondo amministratore, l’accesso di gestione e l’accesso alla console. Conservare in modo sicuro i codici monouso aggiuntivi, ad esempio in un password manager. L’admin predefinito rimane un account di emergenza e non viene utilizzato per l’amministrazione quotidiana.

Gli altri amministratori non possono attivare, disattivare, modificare o eliminare il token dell’admin predefinito. L’OTP hash algorithm globale selezionato si applica anche a questo token.

Prima di iniziare, verificare anche l’ora, la compatibilità dell’app o dell’hardware e Block login, come descritto sopra. I nuovi token hardware e software ereditano l’algoritmo da Authentication > Multi-factor authentication > OTP hash algorithm; non viene scelto separatamente nella procedura guidata dell’admin predefinito. Una scansione QR riuscita non dimostra la compatibilità dell’algoritmo. Restano valide le limitazioni relative alle app e a Base32 descritte sopra.

  1. Accedere a WebAdmin come admin predefinito e aprire Administration > Device access.
  2. Attivare MFA for default admin e fare clic su Apply.
  3. Selezionare il metodo di token appropriato nella procedura guidata e fare clic su Next. Completare quindi il ramo pertinente:
  • Configure a hardware token: Inserire la chiave individuale fornita dal produttore del dispositivo e l’intervallo corrispondente al token hardware. Fare clic su Next, quindi inserire la password dell’admin predefinito seguita immediatamente dal codice attuale del token hardware nel formato <password><passcode>, senza spazi o separatori. Fare clic su Validate e, dopo una validazione riuscita, concludere con Apply.
  • Generate a software token: Installare un’app di autenticazione compatibile sul dispositivo mobile e scansionare il codice QR visualizzato. Inserire la password dell’admin predefinito seguita immediatamente dal codice attuale dell’app nel formato <password><passcode>. Fare clic su Validate e, dopo una validazione riuscita, concludere con Apply.
  • Use an existing token: Se esiste già un token hardware o software per l’admin predefinito e si sta soltanto riattivando MFA, scegliere questo ramo e inserire la password seguita immediatamente dal codice attuale. Per configurare invece un nuovo token software, selezionare Generate a software token e registrare il codice QR nell’app. Questa scelta non è una migrazione dei token utente SHA1 esistenti.

Il primo Apply avvia la configurazione; i nuovi token hardware e software richiedono comunque Validate e l’Apply finale. Se la validazione fallisce, controllare prima password più codice, ora, intervallo e algoritmo, anziché ripetere tentativi casuali. Tenere aperta la sessione esistente durante la verifica e, dopo aver completato la configurazione, testare una nuova sessione WebAdmin separata come admin predefinito con la password più un nuovo codice. Considerare conclusa la configurazione solo dopo un login riuscito e la conservazione sicura dei codici monouso; il secondo amministratore non sostituisce la gestione del token dell’admin predefinito né la procedura di ripristino tramite console descritta di seguito.

Ripristino tramite CLI Main Menu > 2. System Configuration

Le opzioni di ripristino si trovano in CLI Main Menu > 2. System Configuration, non in 4. Device Console. Se ci si trova già in Device Console, tornare prima al Main Menu e selezionare 2 per System Configuration.

Le opzioni di menu 6 e 7 compaiono solo se MFA for default admin è già stato configurato in Administration > Device access. Se non compaiono, non si deve presumere un errore della console; verificare prima questa impostazione e che l’account sia realmente l’utente predefinito admin. Le opzioni non si applicano ad altri account amministratore.

Se il token è solo temporaneamente indisponibile, in CLI Main Menu > 2. System Configuration è possibile autorizzare senza MFA esclusivamente il successivo accesso a WebAdmin dell’admin predefinito:

  1. Nel CLI Main Menu, inserire 2 per System Configuration.
  2. Inserire 6 per Skip multi-factor authentication for next Admin user login.
  3. Accedere una volta a WebAdmin utilizzando soltanto la password dell’admin predefinito e controllare il token. Continuare a tenere pronti l’accesso di fallback verificato e l’accesso alla console.
  4. Aprire quindi una nuova sessione WebAdmin separata come admin predefinito con la password più il passcode attuale nel formato <password><passcode>. Il ripristino è concluso solo dopo un accesso MFA riuscito; documentare il risultato e mantenere disponibile il fallback fino a quel momento.

Se il token rimane inutilizzabile, seguire la procedura di reset e nuova registrazione riportata di seguito, quindi verificare nuovamente un accesso MFA in una nuova sessione. L’esclusione di MFA vale solo per l’accesso successivo; né No OTP per tutti né un’apertura più ampia dell’accesso WAN sostituiscono questa verifica.

In caso di dispositivo smarrito o token definitivamente inutilizzabile, reimpostare MFA:

  1. Nel CLI Main Menu, inserire 2 per System Configuration.
  2. Inserire 7 per Reset multi-factor authentication for Admin user.
  3. Confermare con y.
  4. Accedere una volta a WebAdmin utilizzando soltanto la password di amministratore.
  5. Seguire le istruzioni per registrare nuovamente MFA, quindi testare di nuovo il login con MFA.

Queste due opzioni modificano soltanto lo stato MFA. Se non si conosce nemmeno la password dell’amministratore predefinito, l’articolo separato sul ripristino della password spiega la procedura seriale documentata per le appliance fisiche e i limiti in caso di perdita sia della password sia di MFA.

Testare, controllare i log ed eseguire il rollout

Testare ogni servizio separatamente

Un login WebAdmin riuscito non dimostra che i portali e i client VPN funzionino allo stesso modo. Prima di un rollout esteso, verificare:

  • WebAdmin: Accedere con l’amministratore pilota usando un OTP corretto e uno intenzionalmente errato.
  • Default admin: Verificare il percorso Device Access separato e la procedura di ripristino documentata.
  • User Portal e VPN Portal: Testare la registrazione tramite QR o Base32 e il login con <password><passcode>.
  • SSL VPN e IPsec Remote Access: Testare client reali e lo stesso gruppo di utenti utilizzato in produzione.
  • Sophos Connect: Se necessario, testare il terzo campo OTP, i profili client aggiornati e il comportamento di chiamata/push.
  • RADIUS o Entra SSO: Verificare timeout, log dell’IdP e il comportamento challenge effettivamente supportato.
  • Device Access: Testare l’accesso da una rete sorgente consentita e da una non consentita.

Eseguire soltanto un numero controllato di tentativi errati dopo aver verificato Block login. Il risultato atteso non è solamente un login riuscito: un codice errato deve essere rifiutato, il tentativo deve essere registrato e il servizio deve essere raggiungibile esclusivamente dalle reti previste.

Leggere correttamente i log di autenticazione

In Log viewer, controllare i login riusciti e falliti insieme a servizio, utente, origine, ora e motivo documentato. A seconda dell’evento, SFOS può fornire solo un messaggio generico come credenziali errate. Senza ulteriori evidenze, non dedurre che la causa sia stata esclusivamente la password, l’OTP o un codice scaduto.

Con MFA esterna, i log RADIUS, NPS o IdP fanno parte della stessa verifica. Troubleshooting di Sophos Firewall: servizi e log aiuta a individuare i file di log locali e i servizi. Per conservazione e correlazione più prolungate, consultare Inviare il Syslog di Sophos Firewall a un SIEM.

Prima del rollout esteso

Se il pilota fallisce, il rollout viene interrotto. Tramite il secondo amministratore testato, la normale selezione del pilota in Specific users and groups può essere ripristinata allo stato iniziale documentato; ciò non riguarda la procedura guidata separata dell’amministratore predefinito e non ripristina i token eliminati. Per i gruppi esterni, resta necessario tenere conto dell’accesso MFA aggiuntivo spiegato sopra. Non utilizzare né No OTP per tutti né un’ampia apertura dell’accesso WAN come metodo di riparazione generalizzato. Dopo una correzione, testare nuovamente i servizi interessati in nuove sessioni.

  • Gruppo pilota testato con successo con tutti i servizi necessari.
  • Secondo amministratore, codici monouso e ripristino tramite CLI Main Menu > 2. System Configuration documentati.
  • Utenti informati sulla registrazione dell’app e sull’inserimento di password più OTP.
  • Procedura di reset dei token definita per smartphone smarriti o nuovi.
  • Device Access, blocchi del login e conservazione centralizzata dei log verificati.
  • Responsabilità, timeout e fallback definiti per MFA esterna.

Troubleshooting

Token, codice QR e inserimento

Il codice OTP non viene accettato

Per prima cosa confrontare l’ora del firewall e dello smartphone, l’app utilizzata, l’algoritmo hash e l’intervallo. In Issued tokens è possibile controllare e sincronizzare lo scostamento temporale. Dopo una migrazione dell’algoritmo, il vecchio token deve essere stato eliminato e registrato nuovamente.

Per sincronizzare, aprire Authentication > Multi-factor authentication > Issued tokens, selezionare Synchronize token time offset per il token interessato, inserire il codice attuale generato dall’app o dal token hardware e fare clic su Check. Lo scostamento temporale viene sincronizzato con il firewall, correggendo la deriva dell’ora. Testare quindi un nuovo accesso in modo controllato; mantenere disponibile il fallback e controllare Block login prima di ulteriori tentativi falliti.

La modifica del server NTP deve essere pianificata separatamente, poiché il firewall riconnette i tunnel IPsec esistenti.

Il codice QR non appare o non può essere scansionato

L’utente deve appartenere al gruppo MFA selezionato e accedere a VPN Portal o User Portal. In SFOS 22 gli amministratori possono registrarsi anche in WebAdmin se MFA è attiva in tale servizio. In SFOS 23, controllare prima Share QR code: con Email, controllare la posta in arrivo dopo l’accesso al portale anziché aspettarsi un QR nel portale; con Portals, il QR viene visualizzato nei portali, anche dopo un accesso WebAdmin che attiva la visualizzazione. Il portale e l’origine devono inoltre essere consentiti in Administration > Device access. Per la registrazione iniziale o la sostituzione dell’app in SFOS 23 con la generazione di token attiva, controllare anche la durata di 24 ore spiegata sopra: se il QR non è stato usato per accedere in tale periodo, accedere a VPN Portal o User Portal con la sola password e registrare il nuovo QR distribuito secondo Email o Portals.

Su iOS o con Okta Verify, utilizzare la chiave Base32 invece di scansionare il codice QR quando si applicano le limitazioni indicate.

Il login segnala una password errata

Per un login Sophos OTP nativo, la password deve essere seguita immediatamente dal passcode. Senza un campo OTP separato, la sola password è incompleta.

Accesso, gruppi e Remote Access

Il portale non è raggiungibile

Controllare prima la zona, l’origine e il servizio necessario in Administration > Device access. Una Local Service ACL Exception Rule restrittiva è più sicura di un’autorizzazione WAN generale.

MFA non si applica a Remote Access

Le configurazioni MFA e Remote Access devono utilizzare lo stesso gruppo di utenti effettivamente importato. Quindi reimportare o distribuire il profilo client e testare la connessione con il client reale. Prima della prima connessione VPN, il token deve essere registrato tramite VPN Portal o User Portal.

MFA si applica solo a una parte degli utenti

Non confrontare soltanto i nomi dei gruppi visibili, ma verificare i gruppi effettivamente associati tramite AD, LDAP, RADIUS o Entra ID. Dopo la rimozione di un utente AD da un gruppo MFA, può essere ancora necessario un ultimo login con MFA; solo i login successivi non richiedono più un OTP.

Lockout e MFA esterna

L’amministratore è escluso

Per l’admin predefinito, utilizzare le opzioni 6 o 7 descritte sopra in CLI Main Menu > 2. System Configuration. Per un altro amministratore, utilizzare il secondo amministratore predisposto da un’origine consentita, quindi verificare gruppi, token e stato del blocco login.

RADIUS o Entra MFA non funzionano in modo affidabile

Controllare i timeout RADIUS, i log dell’IdP, i gruppi e il comportamento challenge del servizio specifico. Un test riuscito del server di autenticazione non dimostra che un login in produzione tramite VPN Portal, Sophos Connect o WebAdmin funzioni. Testare separatamente ciascuno di questi percorsi.