Configurare l’avviso di accesso e i messaggi su Sophos Firewall

Sophos Firewall può mostrare agli amministratori un Login disclaimer prima dell’accesso. In Administration > Messages è inoltre possibile personalizzare i testi per autenticazione, eventi SMTP e credenziali di accesso via SMS. Tutti questi messaggi sono limitati a 256 caratteri.

La mia valutazione è volutamente chiara: il Login disclaimer non offre praticamente alcun vantaggio per la sicurezza tecnica del firewall. Non impedisce i tentativi di accesso automatizzati né l’uso di credenziali rubate, non verifica l’identità e non limita i permessi. Nel normale utilizzo aggiunge soprattutto un clic a ogni accesso, che viene generalmente confermato in modo automatico.

SFOS 22 contrassegna tuttavia un avviso disattivato come Noncompliant in Firewall health check. Il controllo Login disclaimer should be enabled appartiene allo standard CIS e ha gravità Medium. Attivandolo, il punto diventa verde o Compliant, ma questo conferma soltanto che l’avviso è attivo. L’accesso non diventa più sicuro. In assenza di un requisito legale, contrattuale o interno di conformità, la funzione non dovrebbe essere attivata solo per migliorare il punteggio. Health Check consente di usare Override status per queste decisioni consapevoli; Interpretare correttamente Sophos Firewall Health Check spiega come contrassegnarle e documentarle.

L’avviso è quindi una funzione informativa e di conformità, non un controllo tecnico degli accessi. Non sostituisce Device Access, Local Service ACL, account amministratore personali, profili, password robuste, MFA o log di audit. Un testo con rilevanza legale deve essere concordato con l’ufficio legale o di conformità competente e non copiato da un modello qualsiasi.

Configurare l’avviso in sette passaggi

1. Definire scopo, destinatari, lingua, contatto e un massimo di 256 caratteri.
2. Mantenere aperto un secondo accesso amministrativo o di ripristino già testato.
3. In Administration > Admin settings > Login disclaimer settings, attivare Enable login disclaimer e salvare con Apply.
4. Aprire il link Modify oppure modificare e salvare l’avviso in Administration > Messages > Administration.
5. Aprire l’anteprima in Login disclaimer settings e verificare testo, interruzioni di riga e completezza.
6. Eseguire un accesso amministrativo reale in una finestra privata del browser, leggere l’avviso e confermarlo con I accept.
7. Verificare separatamente rifiuto, credenziali errate, profili consentiti, Audit Trail e, in HA, un nuovo accesso dopo un failover pianificato.

⚠️ L’avviso non deve contenere password, indirizzi IP interni, codici di ripristino, segreti di supporto o dettagli di sistema non necessari. Una casella di controllo o I accept non rende automaticamente il testo legalmente vincolante. L’attivazione non deve inoltre mettere a rischio l’unica sessione amministrativa testata: prima della modifica devono rimanere disponibili un secondo account amministratore e il percorso di ripristino.

Quali messaggi può personalizzare SFOS 22

In Administration > Messages, SFOS raggruppa i modelli in base all’evento:

• Authentication: conferma di accesso e disconnessione, accesso non riuscito e interruzione.
• SMTP: messaggi relativi alle e-mail bloccate e ricevute.
• Administration: avviso per l’accesso amministrativo.
• SMS customization: testo SMS con gli attributi dinamici {username}, {password} e {expirydate}.

Con Edit si modifica un testo, con Apply lo si salva e con Reset si ripristina il messaggio predefinito di Sophos. Reset non annulla una singola parola, ma elimina la versione personalizzata di quel testo. Prima delle modifiche, il testo precedente viene quindi salvato nella documentazione del change.

Questi modelli sono separati dai canali di trasporto. Administration > Messages modifica il contenuto, ma non configura il server SMTP, Notification List o il gateway SMS. Configurare le e-mail di notifica su Sophos Firewall spiega il trasporto e-mail; gli utenti guest e il gateway SMS restano nel flusso Creare utenti guest in sicurezza su Sophos Firewall.

Pianificare il testo dell’avviso

Un buon avviso di accesso è breve, inequivocabile e non contiene segreti tecnici. Può includere questi punti:

• Accesso consentito solo agli amministratori autorizzati.
• L’utilizzo e le modifiche possono essere registrati.
• Proseguire significa aver letto l’avviso.
• Contatto per tentativi di accesso accidentali o non autorizzati.
• Riferimento a una policy interna mantenuta, se il link è raggiungibile dalla rete di gestione.

Un testo neutro di documentazione può essere formulato così:

Accesso consentito solo agli amministratori autorizzati. Accessi e modifiche possono essere registrati. Proseguendo si conferma questo avviso. Contatto: noc@example.com

.example è un dominio riservato alla documentazione. Contatto, formulazione ed eventuale riferimento alla policy devono essere adattati alla propria organizzazione. Il testo deve rimanere sotto i 256 caratteri e non va descritto come modello legale universale.

È opportuno evitare:

• policy lunghe che nessuno può leggere in modo affidabile nella piccola finestra di accesso;
• affermazioni come «completamente sicuro», «monitorato senza lacune» o «automaticamente vincolante»;
• versioni firmware specifiche, nomi host interni o schemi di rete;
• dati personali di un singolo dipendente quando è possibile usare un contatto funzionale;
• testi contraddittori in più lingue senza un responsabile definito.

Attivare l’avviso di accesso

L’interruttore e il testo si trovano in due aree. Questa separazione è importante:

1. Aprire Administration > Admin settings.
2. Passare a Login disclaimer settings.
3. Selezionare Enable login disclaimer.
4. Fare clic su Apply.
5. Usare il link per modificare il testo oppure passare a Administration > Messages.

Dopo aver inserito le credenziali, gli amministratori devono fare clic su I accept. La documentazione Sophos attuale indica l’avviso prima dell’accesso a WebAdmin, User Portal e CLI. Da ciò non deriva alcuna autorizzazione di rete: raggiungibilità e autenticazione continuano a essere gestite separatamente.

I livelli di protezione restano separati:

• Amministratori locali e profili di accesso al dispositivo definiscono identità e permessi.
• Device Access e Local Service ACL limitano le reti da cui WebAdmin o SSH sono raggiungibili.
• MFA, protezione delle password e Login Restrictions restano attivi senza modifiche.
• L’avviso aggiunge soltanto una notifica visibile a questi controlli.

Gestire il testo in Messages

Il contenuto effettivo viene modificato in Administration > Messages:

1. Espandere l’area Administration.
2. Selezionare Edit.
3. Inserire il testo concordato con un massimo di 256 caratteri.
4. Selezionare Apply.
5. Tornare a Administration > Admin settings > Login disclaimer settings.
6. Aprire il link Preview.

L’anteprima conferma presentazione e contenuto, ma non l’intero accesso. Solo una nuova sessione privata del browser mostra se l’avviso appare dopo le credenziali e se I accept è obbligatorio. Una sessione amministrativa già esistente non è un test affidabile.

Se il testo è inutilizzabile, Reset ripristina il messaggio predefinito di Sophos. Per un rollback controllato, la versione personalizzata precedente deve comunque essere documentata, perché Reset non ritorna a quella versione specifica del cliente.

Modificare in sicurezza i messaggi Authentication e SMTP

I messaggi di autenticazione e SMTP hanno un effetto diretto sugli utenti o sui flussi di posta. Le modifiche devono quindi essere verificate sia dal punto di vista editoriale sia funzionale.

In caso di errore di autenticazione, il testo non dovrebbe rivelare informazioni non necessarie sull’esistenza di un nome utente, su una password errata o sulla mancanza di MFA. Un messaggio di errore generico riduce gli indizi per un attaccante. Accesso positivo, password errata, disconnessione e interruzione forzata vengono provati con account di test.

I testi dei messaggi SMTP non modificano né il routing della posta né la causa di un blocco. Dopo una modifica, vengono testati un messaggio consentito controllato e uno bloccato. I log della posta e Message History restano l’evidenza tecnica; il solo testo visibile non dimostra che l’elaborazione SMTP sia corretta.

Allineare il modello SMS al provider

Per SMS customization, SFOS consente questi segnaposto:

• {username}
• {password}
• {expirydate}

I segnaposto devono rimanere scritti esattamente così. Il provider SMS può richiedere un modello approvato in anticipo. Se formulazione, ordine o testo aggiuntivo differiscono, il server SMS può rifiutare il messaggio. Occorre quindi procurarsi prima il modello vincolante del provider e poi adattare il messaggio SFOS.

L’anteprima dell’avviso di accesso non testa gli SMS. Anche Test connection sul gateway SMS conferma solo il percorso di test previsto in quel punto. La verifica completa richiede un Guest User controllato, un SMS effettivamente ricevuto, valori corretti nei segnaposto e un accesso riuscito.

Un SMS con {password} contiene credenziali. Destinatari, periodo di validità, protezione del dispositivo e cancellazione devono quindi essere gestiti come le password. Il testo non deve contenere ulteriori dettagli interni e screenshot o ticket devono essere creati senza credenziali reali.

Verificare la modifica

La verifica separa presentazione, accesso e consegna:

1. Anteprima: avviso completo, leggibile e inferiore a 256 caratteri.
2. Accesso amministrativo positivo: l’avviso appare dopo le credenziali e I accept consente l’accesso previsto.
3. Test negativo: le credenziali errate restano rifiutate; l’avviso non aggira l’autenticazione.
4. Profili: un amministratore di sola lettura non ottiene permessi aggiuntivi accettando.
5. Device Access: le reti sorgente non consentite continuano a non raggiungere WebAdmin.
6. CLI: verificare separatamente l’accesso CLI usato nell’ambiente senza ampliare SSH per il test.
7. E-mail e SMS: eseguire per ciascuno un vero test di consegna controllato; anteprima e testo del messaggio da soli non sono sufficienti.
8. Audit: verificare modifica, amministratore e orario in Audit Trail; confrontare separatamente il testo atteso con Preview e la documentazione del change. Analizzare i log di audit della configurazione su Sophos Firewall ne spiega l’interpretazione.
9. HA: dopo un failover pianificato, provare un nuovo accesso al nodo attivo; non promettere la continuità delle sessioni WebAdmin o CLI esistenti.

Delimitare gli errori in base al sintomo

L’avviso non appare

Verificare che Enable login disclaimer sia attivo e salvato con Apply in Admin settings. Usare quindi una nuova sessione privata del browser. Una sessione precedente o la sola modifica del testo in Messages non dimostra che l’interruttore sia attivo.

Il testo è errato o troncato

Verificare numero di caratteri, interruzioni di riga e caratteri speciali. Ridurre il testo a un massimo di 256 caratteri e controllarlo nuovamente nell’anteprima. Se non è possibile correggere in sicurezza la versione personalizzata, usare Reset e reinserire il testo concordato dalla documentazione del change.

L’accesso non riesce dopo la modifica

Non presumere che la causa sia l’avviso. Verificare separatamente credenziali, MFA, Administrator authentication methods, Login Restrictions, Block login, Device Access e certificato. Usare la sessione di ripristino aperta per disattivare temporaneamente l’avviso se è l’unico modo per delimitare la causa in sicurezza. Non ampliare una ACL o un metodo di autenticazione.

L’SMS non viene consegnato

Verificare modello del provider, segnaposto esatti, gateway SMS, formato del numero mobile e risposta del provider. Se il provider richiede un modello registrato, il testo non deve essere modificato a tentativi. Verificare l’intero flusso del Guest User e non soltanto Test connection.

Health Check richiede un avviso di accesso

Sophos Firewall Health Check valuta la funzione come raccomandazione di conformità. L’avviso non offre un vantaggio tecnico di sicurezza come MFA o una ACL restrittiva. La decisione dipende dai propri requisiti legali, di audit e dei clienti; Interpretare correttamente Sophos Firewall Health Check spiega questo limite.

Rollback

1. Tenere disponibile il testo personalizzato precedente dalla documentazione del change.
2. In caso di semplice errore di testo, reinserire la versione precedente in Administration > Messages oppure usare consapevolmente Reset.
3. In caso di problema di accesso, disattivare Enable login disclaimer con la sessione di ripristino aperta e selezionare Apply.
4. Ripristinare singolarmente i modelli Authentication, SMTP o SMS allo stato precedente documentato; non modificare contemporaneamente tutte le aree dei messaggi.
5. Verificare nuovamente un nuovo accesso privato, i profili, Device Access e, se necessario, la consegna di e-mail e SMS.
6. Documentare modifica e rollback in Audit Trail e nel change.

Checklist

• Scopo, responsabile, lingua e massimo di 256 caratteri definiti.
• Testo verificato dall’ufficio legale o di conformità, se necessario.
• Secondo accesso amministrativo e percorso di ripristino testati.
• Avviso attivato in Admin settings e salvato con Apply.
• Messaggio gestito in Administration > Messages.
• Anteprima e nuovo accesso privato testati.
• I accept non estende né il profilo né Device Access.
• Testi Authentication, SMTP e SMS verificati ciascuno con un evento reale.
• Modello SMS e segnaposto corrispondono ai requisiti del provider.
• Audit Trail, test HA e rollback documentati.

FAQ