Configurare e testare le notifiche e-mail Sophos Firewall

Per ottenere notifiche e-mail funzionanti, Sophos Firewall richiede due configurazioni distinte: il trasporto e-mail viene impostato in Administration > Notification settings. Gli eventi effettivamente segnalati via e-mail vengono selezionati in System services > Notification list.

Anche il riepilogo di quarantena per gli utenti usa questo trasporto, ma pianificazione, link al portale e assegnazione utenti sono impostazioni separate.

I testi visibili Authentication, SMTP, Admin e SMS in Administration > Messages costituiscono un terzo livello separato. Configurare l’avviso di accesso e i messaggi su Sophos Firewall ne spiega contenuto e test; la modifica di un messaggio non configura né il trasporto SMTP né la selezione degli eventi.

La procedura rapida:

Configurare mail server, porta, autenticazione, cifratura, mittente e destinatario in Administration > Notification settings.
Inviare un’e-mail di prova e confermarne la consegna nella casella di destinazione o nel tracking del mail server.
Attivare l’interruttore globale Email notifications in System services > Notification list.
Selezionare solo gli eventi per i quali un destinatario responsabile può intervenire.
Oltre all’e-mail di prova, generare in modo controllato un evento reale selezionato e verificarne la consegna.

Un’e-mail di prova riuscita dimostra soltanto che il percorso SMTP funziona in linea di principio. Non dimostra ancora che l’interruttore globale per le e-mail e gli eventi corretti siano attivi. Viceversa, la selezione di una riga evento non invia alcun messaggio finché il trasporto e-mail non funziona. Questa distinzione spiega anche perché un server SMTP configurato da solo non soddisfa ancora operativamente il punto Notification Emails del Sophos Firewall Health Check.

Se WebAdmin non è disponibile o l’indirizzo del destinatario deve essere corretto tramite un accesso CLI controllato, aprire 2. System Configuration > 3. Set Email ID for system notification nel Main Menu della CLI. System Configuration è l’opzione 2 del Main Menu, non un sottomenu della Device Console (opzione 4). Se ci si trova già nell’opzione 4, tornare prima al Main Menu e scegliere l’opzione 2. Questa opzione modifica solo l’indirizzo e-mail dell’amministratore per gli avvisi di sistema. Non configura mail server, mittente, autenticazione e TLS né l’interruttore globale e gli eventi nella Notification list.

Documentare prima l’indirizzo precedente. Confermare quindi la modifica con y, inserire il nuovo indirizzo e controllare che quello mostrato da SFOS non contenga errori. Premere Enter per tornare al menu. Un’e-mail di prova e un evento reale controllato devono poi raggiungere il nuovo destinatario; la sola conferma della console non dimostra la consegna.

Preparare l’invio delle e-mail

Prima della configurazione, mail server, porta e metodo di autenticazione devono essere concordati con l’amministratore di posta responsabile. Se si utilizza un FQDN come smtp.example.net, il firewall deve poterlo risolvere e raggiungere il server attraverso il percorso di routing previsto. Una connessione Internet generale è necessaria solo se il mail server o il provider OAuth scelto si trova su Internet. Un relay SMTP interno può funzionare anche senza accesso diretto del firewall a Internet.

Prima di apportare modifiche, annotare l’opzione mail server selezionata, il server, la porta, Authentication, Connection security, mittente, destinatario, interfaccia di gestione ed eventi selezionati. Se la modifica riguarda i certificati, annotare anche la selezione attuale in Administration > Notification settings o Email > General settings, a seconda dei casi. Verificare che le credenziali e i token OAuth necessari siano disponibili in un password manager o secrets manager sicuro; non inserirli in screenshot non protetti. Queste informazioni consentono di ripristinare la configurazione precedente se il nuovo percorso e-mail non supera il test di consegna.

Un esempio realistico:

Mail server: smtp.example.net
Port: 587
Authentication: Basic
Connection security: STARTTLS
Sender: fw-zrh-01@example.net
Recipient: firewall-alerts@example.net
Management interface IP address: interfaccia di management interna del firewall

Tutti i valori che utilizzano example.net devono essere sostituiti con il dominio dell’organizzazione e gli indirizzi approvati dall’amministratore di posta. Un indirizzo di distribuzione è generalmente preferibile a una casella personale: le responsabilità possono cambiare senza dover riconfigurare ogni firewall.

La Management interface IP address non determina da quale interfaccia esce la connessione SMTP del firewall. L’indirizzo IP selezionato viene incluso nella notifica e aiuta a identificare il firewall mittente. In presenza di più sedi, scegliere quindi un IP di management comprensibile nel tempo; con un solo firewall può essere sufficiente anche None.

Le interfacce fisiche, bridge e LAG compaiono nel menu a discesa solo se hanno un indirizzo IP assegnato. Se manca un’interfaccia, questo requisito ne spiega l’assenza; non assegnare indirizzi IP né modificare interfacce o routing soltanto per aggiungere l’identificazione a un messaggio.

Configurare il mail server

Scegliere Built-in o External email server

Sophos Firewall può utilizzare il Built-in email server o un External email server. L’invio integrato è pratico per un avvio semplice. Negli ambienti di produzione, un relay dedicato o un mail server cloud è spesso più facile da tracciare, perché autenticazione, tracking delle e-mail, autorizzazioni del mittente ed errori di consegna sono visibili in un punto centrale.

Consigliamo pertanto l’External email server quando è già disponibile un servizio SMTP gestito in modo affidabile.

Per il Built-in email server è sufficiente questa breve procedura:

Attivare il Built-in email server in Administration > Notification settings.
Inserire mittente, destinatario e, facoltativamente, Management interface IP address.
Salvare e inviare l’e-mail di prova.

Il Built-in email server non dispone di un tracking separato del relay con cui l’amministratore possa seguire accettazione e inoltro. Occorre quindi controllare con particolare attenzione la consegna effettiva. Se fallisce ripetutamente o se il dominio destinatario e i requisiti di sicurezza richiedono un percorso SMTP controllato, un External email server è la variante più gestibile.

Configurare un External email server

Aprire Administration > Notification settings.
Selezionare External email server.
Inserire l’indirizzo IPv4 o il FQDN del mail server e la porta indicata.
In Authentication, selezionare None, Basic o OAuth 2.0 in base al server.
In Connection security, impostare la cifratura del trasporto richiesta dal mail server.
Inserire mittente, destinatario e, facoltativamente, Management interface IP address.
Salvare ed eseguire la funzione di e-mail di prova.

La porta predefinita in SFOS è 25, ma non è una raccomandazione per ogni ambiente. È determinante il listener del relay dell’organizzazione. Le scelte tipiche sono 25 per un relay interno autorizzato in base all’IP sorgente, 587 per l’invio autenticato con STARTTLS o 465 per SSL/TLS diretto. Porta, autenticazione e modalità di cifratura devono corrispondere al mail server come combinazione.

None non ha lo stesso significato nei due campi di selezione: in Authentication disattiva l’accesso autenticato al mail server. Può essere corretto per un relay interno che autorizza esclusivamente l’IP sorgente del firewall. In Connection security, invece, None indica una trasmissione SMTP non cifrata. Questa impostazione non è adatta ai percorsi Internet e deve essere utilizzata anche internamente solo se il modello di sicurezza lo consente esplicitamente.

Con Basic, il firewall utilizza nome utente e password. Il nome utente distingue maiuscole e minuscole. Il relay deve supportare il metodo di autenticazione utilizzato; un errore relativo all’Authentication method indica in particolare una differenza tra LOGIN o PLAIN.

STARTTLS viene facilmente frainteso: il firewall segue le funzionalità del mail server. Se il server offre STARTTLS, la connessione viene cifrata; se non lo offre, il messaggio può essere trasmesso senza cifratura. Se la cifratura deve essere obbligatoria, utilizzare SSL/TLS con la porta e il listener del server corrispondenti.

⚠️ Allow invalid certificate in Email > General settings non deve essere attivato come soluzione rapida. Un certificato scaduto, non attendibile o non corrispondente al nome del server deve essere corretto sul mail server o nella catena di attendibilità.

Il certificato utilizzato da SFOS dipende anche dalla modalità e-mail. Con STARTTLS in MTA Mode, il firewall usa il certificato configurato in Email > General settings. In Legacy Mode, per STARTTLS è possibile selezionare un certificato direttamente in Administration > Notification settings; se non viene selezionato, SFOS usa anche in questo caso il certificato in Email > General settings. Con SSL/TLS usa il certificato in Email > General settings. Non modificare quindi un certificato isolatamente senza considerare il flusso di posta in produzione.

Gmail e Microsoft 365 con OAuth 2.0

Per Gmail e Microsoft 365, in SFOS 22 e 23 selezionare OAuth 2.0. In Notification settings vengono inseriti Provider, Client ID, Client secret e Refresh token. Il campo Client secret è facoltativo per Microsoft 365; la procedura Microsoft 365 descritta qui crea e utilizza però espressamente un secret. Per questa procedura viene quindi configurato.

Per Gmail occorre configurare un progetto e la Gmail API in Google Cloud, quindi generare un client OAuth e un Refresh Token. La procedura seguente descrive questi passaggi. Google e Microsoft modificano i propri portali e requisiti indipendentemente da SFOS; prima di una configurazione in produzione, verificare quindi i requisiti aggiornati dei provider e le autorizzazioni dell’account di invio previsto.

Configurare Gmail OAuth 2.0 passo dopo passo

Prima di generare il Refresh Token, verificare l’account di invio previsto, il client OAuth, la Redirect URI e lo scope Gmail con ampie autorizzazioni descritto sotto. Per la procedura seguente con User type: External, deve essere stata approvata anche la messa in produzione dell’app OAuth. Publish App non sostituisce né la verifica richiesta dal provider né l’approvazione dell’amministratore Google Workspace o della sicurezza responsabile. Se la pubblicazione non è consentita dai requisiti attuali di Google o dalle policy interne, non aggirare queste protezioni: utilizzare invece un relay SMTP approvato per un percorso di allarme duraturo.

Accedere a Google Cloud Console con l’account Google previsto, creare un nuovo progetto e selezionarlo.
Aprire APIs & Services > Library, cercare Gmail API e abilitare l’API.
In APIs & Services > Credentials, fare clic su Create credentials > OAuth client ID.
Se viene prima richiesta la schermata di consenso, aprire Configure the OAuth consent screen > Get started. Inserire il nome dell’app e l’indirizzo e-mail, selezionare User type: External, aggiungere l’indirizzo di contatto dello sviluppatore e creare la configurazione.
Selezionare Create OAuth client, impostare Application type: Web application e assegnare un nome univoco.
In Authorized redirect URIs, aggiungere esattamente https://developers.google.com/oauthplayground.
Creare il client OAuth e registrare subito in modo sicuro il Client ID e il Client secret.
In Audience, verificare l’account di invio previsto e lo stato attuale della pubblicazione. Finché l’app è in Testing, aggiungere l’account come utente di test in Add users. Questo elenco di utenti di test non costituisce una restrizione di accesso per un’app esterna dopo la pubblicazione.
Dopo aver ottenuto l’approvazione necessaria, eseguire Publish App e verificare che Publishing status sia passato da Testing a In production. Un’app esterna è quindi, in linea di principio, disponibile per l’autorizzazione anche da parte di account Google non presenti nell’elenco degli utenti di test; restano da rispettare le policy applicabili agli account e all’organizzazione. Generare il Refresh Token solo dopo questo passaggio. In questa procedura Gmail, un token generato prima della pubblicazione scade dopo sette giorni; per un funzionamento continuativo, generare quindi un nuovo Refresh Token dopo la pubblicazione invece di continuare a utilizzare quello precedente.
Aprire Google OAuth 2.0 Playground. Usare l’icona a forma di ingranaggio per attivare Use your own OAuth credentials, quindi inserire il Client ID e il Client secret.
In Step 1 Select & authorize APIs, espandere Gmail API v1, selezionare lo scope https://mail.google.com e avviare Authorize APIs. Utilizzare l’account di invio previsto e, prima di concedere il consenso, confrontare l’app visualizzata e le sue autorizzazioni con la configurazione approvata. In caso di differenze, interrompere e verificare la configurazione.
In Step 2 Exchange authorization code for tokens, scambiare il codice con i token e copiare in modo sicuro il Refresh token. Client secret, Authorization Code, Access token e Refresh token non devono comparire in ticket, screenshot non protetti o log.
Sul firewall, in Administration > Notification settings, configurare l’External email server con Authentication: OAuth 2.0 e Provider: Gmail. Inserire Client ID, Client secret e Refresh token, salvare e inviare un’e-mail di prova. Confermare la consegna effettiva nella casella di destinazione o nel tracking del mail server; i soli campi OAuth salvati non dimostrano che il percorso e-mail funzioni.

Google non considera un progetto OAuth con User type External e Publishing status Testing come una configurazione di produzione permanente: utilizzando lo scope Gmail, il Refresh Token scade dopo sette giorni secondo Google OAuth 2.0. Lo scope Gmail https://mail.google.com utilizzato qui consente, oltre all’invio, di leggere, creare ed eliminare definitivamente le e-mail. L’app OAuth, le credenziali e, preferibilmente, un account di invio dedicato devono quindi essere protetti e gestiti come una password del mail server.

Per Microsoft 365, l’app richiede le autorizzazioni delegate SMTP.Send e offline_access; per l’account di invio deve essere attivato Authenticated SMTP. La procedura standard documentata utilizza smtp.office365.com, la porta 587 e STARTTLS. Se l’indirizzo del mittente differisce dalla casella autenticata, l’account richiede inoltre Send As. La procedura Entra completa è riportata subito sotto.

Configurare Microsoft 365 OAuth 2.0 passo dopo passo

In Microsoft Entra admin center, creare una New registration in Identity > Applications > App registrations.
Assegnare un nome univoco. Per questa procedura, selezionare Accounts in any organizational directory (Any Microsoft Entra ID tenant - Multitenant). In Redirect URI, selezionare la piattaforma Web e inserire https://outlook.office365.com/ come URI. In alternativa è previsto http://localhost/. La URI registrata deve essere riutilizzata esattamente nella richiesta di autorizzazione e nello scambio del token; se si utilizza localhost, sostituire il valore di redirect_uri con http://localhost/ in entrambi gli esempi seguenti.
Registrare l’app e conservare in modo sicuro l’Application (client) ID.
In API permissions > Add a permission, configurare l’autorizzazione SMTP delegata per la risorsa Outlook/Exchange e concedere il consenso necessario. Microsoft documenta a questo scopo lo scope https://outlook.office.com/SMTP.Send; richiedere inoltre offline_access per il Refresh Token. È necessaria l’autorizzazione SMTP, non un’autorizzazione Graph come Mail.Send. Prima di creare il token, verificare la risorsa selezionata e le autorizzazioni visualizzate seguendo la guida Microsoft per SMTP con OAuth. Se manca l’autorizzazione corretta, non procedere con una che sembra simile.
Nel Microsoft 365 admin center, per l’account di invio, controllare Authenticated SMTP in Users > Active users > Mail > Email apps > Manage email apps e, se le policy di sicurezza lo consentono, attivarlo e salvare. Questa impostazione della casella di posta è distinta dalla registrazione dell’app nell’Entra admin center.
In Certificates & secrets > Client secrets > New client secret, creare un secret con una data di scadenza monitorata. Copiare subito e in modo sicuro il Value visualizzato; Entra non lo mostra più dopo il ricaricamento della pagina.
Aprire il seguente URL in un browser. Sostituire YOUR_CLIENT_ID con l’Application ID e YOUR_RANDOM_STATE con un valore casuale generato esclusivamente per questa operazione; il redirect_uri deve corrispondere alla registrazione dell’app. Codificare correttamente i valori dei parametri nell’URL. Il valore State deve essere restituito invariato nella risposta; un valore di esempio fisso non protegge l’operazione. La guida Microsoft al flusso Authorization Code spiega la verifica di State e l’uso di PKCE per i client compatibili.

https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=YOUR_CLIENT_ID&response_type=code&redirect_uri=https://outlook.office365.com/&response_mode=query&scope=https://outlook.office365.com/.default+offline_access&state=YOUR_RANDOM_STATE

Accedere con l’account di invio previsto, confrontare il valore State restituito con quello conservato e, solo se coincidono, acquisire il codice di autorizzazione di breve durata dall’URL di reindirizzamento. In caso di mancata corrispondenza, interrompere e ricominciare la procedura.
Inviare il codice con un client API come application/x-www-form-urlencoded all’endpoint del token. Sostituire ogni segnaposto con i valori di questa app. Il blocco seguente mostra i campi su più righe per facilitarne la lettura; nel client API, inserirli come singoli campi del modulo affinché spazi e caratteri speciali nel codice, nel secret e nella Redirect URI siano codificati correttamente. Non è un comando shell da copiare ed eseguire senza modifiche.

POST https://login.microsoftonline.com/common/oauth2/v2.0/token

client_id=YOUR_CLIENT_ID
&scope=https://outlook.office365.com/.default offline_access
&code=YOUR_AUTHORIZATION_CODE
&redirect_uri=https://outlook.office365.com/
&grant_type=authorization_code
&client_secret=YOUR_CLIENT_SECRET

Salvare immediatamente e in modo sicuro il Refresh token restituito. Il codice di autorizzazione, il Client secret, l’Access token e il Refresh token non devono essere inseriti in ticket, screenshot non protetti o log.
Sul firewall, configurare l’External email server in Administration > Notification settings con Authentication: OAuth 2.0 e Provider: Microsoft 365. Inserire smtp.office365.com, la porta 587, STARTTLS, Client ID, Client secret e Refresh token, salvare e inviare un’e-mail di prova.

Per questa procedura di generazione del token, il sistema che esegue il client API e il firewall devono utilizzare lo stesso fuso orario. Controllare prima l’ora di sistema e il fuso orario. Non modificare spontaneamente il fuso orario del firewall in produzione; il riavvio necessario dopo la modifica deve essere pianificato in una finestra di manutenzione.

I Microsoft Security Defaults disattivano SMTP AUTH. Questa protezione non deve essere disattivata globalmente per l’intero tenant solo per consentire a un firewall di inviare messaggi. Se l’abilitazione mirata per l’account di invio non è compatibile con il modello di sicurezza, la soluzione più pulita è un relay interno o esterno appositamente previsto.

⚠️ Il problema noto NC-166854 riguarda OAuth Microsoft 365 per le notifiche sui build SFOS 22.0.0.274, 22.0.0.323, 21.0.2.349 e 21.5.1.261. Questo non permette di concludere né che tutti gli altri build funzionino né che nel frattempo non sia disponibile una correzione. Prima della messa in servizio, verificare il build SFOS esatto e lo stato del problema e delle correzioni applicabile a quel build, e richiedere un’e-mail di prova riuscita. I campi Client ID, secret e token salvati non dimostrano il funzionamento.

Se un build elencato è interessato, utilizzare un relay SMTP supportato o un altro percorso e-mail verificato finché non viene confermata in modo affidabile una versione firmware corretta. Eccezioni TLS non sicure o Basic Authentication non verificata non sono validi sostituti di un percorso di allarme funzionante.

Selezionare gli eventi nella Notification list

Dopo un test e-mail riuscito, aprire System services > Notification list. Attivare innanzitutto Email notifications, quindi selezionare le caselle nella colonna Email per gli eventi richiesti e salvare con Save.

E-mail e SNMP sono canali di uscita distinti. Per le trap, configurare anche l’agente SNMP e le community o gli utenti appropriati in Administration > SNMP. Attivare quindi nella Notification list l’interruttore globale SNMP traps e le caselle degli eventi disponibili per SNMP, e salvare. La selezione delle e-mail non attiva le trap; per ciascun evento è possibile scegliere e-mail, SNMP o entrambi i canali disponibili. L’articolo SNMP collegato in fondo spiega la configurazione e la verifica del manager SNMP.

Non tutti i firewall necessitano della stessa selezione. Una base utile dipende dai rischi e dalle funzioni effettivamente utilizzate:

Admin: accessi non riusciti e numero eccessivo di tentativi di accesso non riusciti.
HA: porte o interfacce monitorate disconnesse quando si utilizza un cluster HA.
Disk/Memory: avvisi di spazio affinché un’area di reporting o di sistema piena non venga notata solo durante una finestra di manutenzione. Soglie e conseguenze sono spiegate in Controllare spazio e report in Sophos Firewall.
Firmware: nuovo firmware pronto per l’installazione, firmware installato correttamente e installazioni non riuscite in linea con il processo di aggiornamento dell’organizzazione.
Solo SFOS 23 – Firmware > Security updates: In System services > Notification list, abilitare la colonna Email per Security updates. Restano necessari l’interruttore globale Email notifications e un percorso SMTP funzionante. Le notifiche SNMP non sono disponibili per gli aggiornamenti di sicurezza tramite hotfix; questa limitazione non riguarda indistintamente tutti gli hotfix o tutti gli eventi del firmware. La consegna immediata non è garantita e l’assenza di email non dimostra né successo né fallimento. Verificare gli aggiornamenti applicati con la procedura di verifica degli hotfix di SFOS 23.
System: aggiornamenti non riusciti del database WebCat, delle firme IPS e delle definizioni antivirus, avvio o riavvio del sistema, elevato utilizzo della CPU e Gateway status.
IPS: sono selezionabili i livelli Critical, Major, Moderate, Minor e Warning. L’alert richiede che il firewall registri l’evento IPS e scarti il pacchetto. Per iniziare, sono adatti gli eventi critici con un processo di triage definito.
Active threat response: gli eventi Log e Drop per MDR, NDR Essentials, Sophos X-Ops e i threat feed di terze parti vengono selezionati separatamente. I tipi di corrispondenza e le limitazioni sono descritti nella sezione successiva.
RED: connessione interrotta, aggiornamento firmware non riuscito, dispositivo deautorizzato automaticamente o nuovo Unlock Code. AP: Access Point offline o aggiornamento firmware non riuscito. Selezionare solo le notifiche dei dispositivi effettivamente utilizzati e definire un destinatario responsabile.
VPN: tunnel IPsec up, down e failover/failback, nonché connessioni SSL VPN stabilite o interrotte. Le condizioni di attivazione IPsec illustrate sotto sono più restrittive di questo elenco generale; la selezione non garantisce una notifica per ogni cambio di stato manuale del tunnel.
Virus: selezionare gli alert per HTTP, FTP, SMTP, POP3 e IMAP4 in base alle funzioni di protezione effettivamente utilizzate. La casella non sostituisce né la relativa scansione né il rilevamento degli eventi.
Web - Instant alerts: categorie Web selezionate consapevolmente. Queste notifiche vengono inviate in batch a intervalli fissi di cinque minuti, non modificabili, e richiedono un’attivazione separata della categoria, come descritto in Categorie Web e Instant Alerts.

Attivare indiscriminatamente tutti gli eventi provoca rapidamente alert fatigue. In particolare, le notifiche VPN possono essere ripetute approssimativamente ogni 60 secondi finché la causa non viene risolta; con più reti locali e remote può inoltre essere generata una notifica per ogni coppia di subnet. È preferibile una selezione ridotta con una risposta chiara: chi riceve l’alert, quanto è urgente e qual è il primo controllo?

Alcune Default Notifications vengono inviate automaticamente dal firewall e non possono essere deselezionate: cambiamenti di ruolo HA da Standalone, Primary o Auxiliary, stato faulty dei dispositivi HA, host virtuali up/down e riavvio o arresto tramite WebAdmin. Anche per queste notifiche il percorso e-mail configurato deve essere raggiungibile. Una categoria di eventi non deselezionabile non garantisce che un messaggio raggiunga una casella di posta non raggiungibile.

Active threat response: distinguere corrispondenza e canale

Per ciascuno dei seguenti tipi di corrispondenza sono disponibili un Log event e un Drop event:

Destination match for all traffic: l’indirizzo di destinazione corrisponde a una voce del threat feed.
Remote source match for inbound traffic: l’indirizzo sorgente remoto del traffico in ingresso corrisponde a una voce del threat feed.
Local source match for outbound traffic: l’indirizzo sorgente locale del traffico in uscita corrisponde a una voce del threat feed.

Un alert Log da solo non dimostra un blocco. Viceversa, un evento Drop dipende dalla corrispondenza effettiva e dalla relativa configurazione di Active threat response; la casella e-mail non genera né una corrispondenza né una nuova regola di protezione.

La guida Sophos alle notifiche indica come non supportata la corrispondenza delle sorgenti locali e remote per Sophos X-Ops. Questa indicazione è tuttavia in conflitto con la matrice del traffico SVG, come spiegato nell’articolo NDR/ATR, soprattutto per la corrispondenza della sorgente locale. L’opzione e-mail non dimostra quindi né un determinato effetto di corrispondenza X-Ops né la risoluzione del conflitto; chiarire separatamente i casi controversi prima di considerarli un requisito di protezione. Gli alert Remote source match non vengono inoltrati al servizio centrale Sophos, ma i relativi log sono visibili in Central Firewall Reporting (CFR). Il nome del servizio centrale varia tra le versioni (Sophos Central o Sophos Fusion); ciò non implica un’estensione dell’inoltro degli alert. Per questi eventi, verificare quindi il percorso locale e-mail/log senza affidarsi esclusivamente alla visualizzazione centrale degli alert.

Comprendere le condizioni di attivazione e le ripetizioni

Una casella attivata non significa che ogni breve cambiamento di stato generi un’e-mail. In SFOS 22.0 e 23.0, i seguenti eventi hanno queste condizioni:

Admin: Sign-in failed comprende credenziali errate o una OTP (password monouso) errata. Too many failed sign-in attempts si attiva quando viene raggiunto il numero di tentativi non riusciti configurato in Administration > Admin and user settings > Login security. Questa soglia spiega l’alert; non è un’istruzione per provocare il blocco di un account.
High CPU usage: La prima voce del log di notifica viene generata solo quando l’utilizzo della CPU raggiunge il 95% e rimane continuativamente al 95% o superiore per almeno 25 minuti. Ulteriori voci vengono generate ogni 25 minuti finché l’utilizzo non scende sotto il 95%. Un breve picco senza e-mail di evento non dimostra quindi un errore SMTP.
Gateway status: La selezione dell’evento è attivata per impostazione predefinita. Per l’invio deve comunque essere attivo il distinto interruttore globale Email notifications.

Per gli eventi disco, l’utilizzo deve rimanere continuativamente alla rispettiva soglia o al di sopra per almeno 50 secondi. Log e notifiche vengono poi ripetuti con la seguente frequenza predefinita finché l’utilizzo non scende sotto la soglia:

Area	Soglia di notifica	Ripetizione
Spazio di configurazione	≥80%	ogni 50 secondi
Spazio delle firme	≥90%	ogni 50 secondi
`/var`	≥80%	ogni 12 ore

Per /var, la soglia inferiore genera già log; le notifiche iniziano solo alla soglia superiore dell’80%. Se l’utilizzo supera la soglia superiore e poi scende sotto quella inferiore, il ripristino viene registrato, ma non viene inviata alcuna notifica di ripristino. Questo comportamento è distinto dagli avvisi e dall’arresto dei report descritti nell’articolo sullo spazio collegato sopra; qui, l’assenza di un’e-mail di ripristino non è un errore di consegna.

Per IPsec, l’ambito documentato è più ristretto di un qualsiasi cambiamento Up/Down di VPN: le notifiche riguardano solo tunnel host-to-host e site-to-site con le condizioni di disconnessione descritte:

Dead peer detection (DPD).
Mancato ristabilimento della connessione dopo DPD.
La IPsec Security Association (SA) è scaduta e deve essere ristabilita.
Questo elenco comprende anche il ritorno del tunnel dopo una perdita di connettività senza intervento dell’amministratore.

Se nelle impostazioni della connessione IPsec è configurata una descrizione, la notifica la include. Questo non garantisce notifiche per ogni disconnessione manuale né per tunnel di accesso remoto o SSL VPN.

I tempi CPU descrivono la generazione dei log di notifica e gli intervalli disco la ripetizione documentata, non un orario di arrivo garantito nella casella. Se manca un’e-mail, confrontare prima la condizione dell’evento, l’orario del log e il tracking del mail server. Non provocare saturazione di CPU o disco, blocchi di accesso, interruzioni HA o guasti VPN in produzione soltanto per testare un alert.

Verificare l’e-mail di prova e un evento reale

La verifica si compone di due fasi.

1. Confermare la consegna SMTP con un’e-mail di prova

Controllare innanzitutto la configurazione e-mail salvata in Administration > Notification settings ed eseguire la funzione di e-mail di prova disponibile nel build SFOS utilizzato. Il percorso per il test dei report è Reports > Show report settings > Report scheduling: selezionare un report, aprire Send test mail, inserire l’indirizzo del destinatario di prova e fare clic su Send. Questo test dei report verifica il trasporto e-mail, non la selezione degli eventi; il suo destinatario non coincide automaticamente con quello salvato per gli avvisi di sistema. Il messaggio di successo del firewall non è sufficiente: nella casella di destinazione, nel filtro antispam o nel tracking del mail server deve risultare che il messaggio è stato effettivamente accettato e consegnato. Il contenuto e la pianificazione dei report vengono verificati separatamente, come descritto nell’articolo sui report collegato in fondo.

Verificare quanto segue:

Mittente e destinatario sono corretti.
Il firewall atteso è identificabile tramite oggetto, contenuto o IP di management.
Il messaggio non finisce permanentemente nello spam o in quarantena.
La lista di distribuzione accetta i messaggi dal mittente configurato.

2. Testare l’intera catena degli eventi

Generare quindi in modo controllato un evento selezionato. Esempi adatti:

un singolo accesso non riuscito con un account di test, dopo aver verificato blocchi e soglie di login;
un evento VPN documentato su un tunnel di test espressamente previsto a questo scopo, solo se il tipo di tunnel e la condizione di attivazione corrispondono alla notifica selezionata; un semplice cambio di stato Up/Down manuale di un tunnel IPsec non è un test affidabile degli alert;
Gateway status durante un test WAN failover pianificato.

Riavviare o disconnettere un gateway di produzione, una porta HA o il firewall stesso esclusivamente per un test e-mail sarebbe sproporzionato. Uno scenario di manutenzione o failover già pianificato è il test migliore.

L’intera catena è confermata solo quando l’evento raggiunge il destinatario corretto entro il tempo previsto: rilevamento dell’evento, selezione dell’evento, interruttore e-mail globale, trasporto SMTP e consegna.

Individuare gli errori in modo sistematico

Non riesce nemmeno l’invio dell’e-mail di prova

L’API SFOS 22 distingue diverse classi di errore:

Failed to connect o SMTP server failed to respond: controllare risoluzione FQDN, route, porta, firewall a monte e listener del mail server.
Password mismatch: controllare nome utente, maiuscole/minuscole, password ed eventuale blocco dell’account.
Authentication method mismatch: verificare se relay e SFOS supportano entrambi LOGIN o PLAIN per Basic Authentication.
STARTTLS not supported: porta e Connection security non corrispondono al listener del server.
Mail server refused to communicate: controllare autorizzazione relay, indirizzo mittente, IP sorgente consentito e log del mail server.
Couldn’t generate the OAuth 2.0 access token: controllare Provider, Client ID, secret, Refresh Token, autorizzazioni e ora di sistema.

DNS e STARTTLS possono essere controllati in anticipo senza modificare il mail server da un sistema di amministrazione che utilizza un percorso di rete comparabile:

nslookup smtp.example.net
openssl s_client -starttls smtp -connect smtp.example.net:587 -servername smtp.example.net

Sostituire smtp.example.net e 587 con il server e la porta dell’organizzazione. nslookup conferma solo la risoluzione dei nomi dal sistema di amministrazione. openssl s_client mostra raggiungibilità SMTP, handshake TLS e catena di certificati, ma non verifica né la route dal punto di vista del firewall, né la sua autenticazione, né la successiva consegna.

In Log Viewer e, per un’analisi più approfondita, in cschelper.log, l’orario del test può essere correlato con l’e-mail generata dal sistema. L’accesso ai Service Logs e la distinzione dall’Advanced Shell sono spiegati in Servizi e log di Sophos Firewall. I log MTA come smtpd_main.log appartengono principalmente a Mail Protection e non sono in generale il log delle notifiche.

L’e-mail di prova arriva, ma mancano le e-mail degli eventi

In questo caso il trasporto funziona e la ricerca inizia in System services > Notification list:

Email notifications è attivo globalmente?
L’evento specifico è selezionato nella colonna Email?
L’evento atteso si è effettivamente verificato e appartiene alla categoria corretta?
È presente un ritardo o un raggruppamento noto, ad esempio per i Web Instant Alerts?
Filtro antispam, quarantena o tracking del mail server mostrano un’accettazione o un rifiuto?

Per un singolo evento specialistico occorre verificarne anche la condizione funzionale. Un alert IPS, ad esempio, non viene generato semplicemente attivando una casella: una regola IPS corrispondente deve prima registrare l’evento e scartare il pacchetto. Una notifica VPN dipende dal tipo di tunnel e dallo stato Up/Down effettivo.

Gmail OAuth smette di funzionare dopo una modifica della password

Nella procedura di notifica Gmail descritta qui, con lo scope https://mail.google.com, il Refresh Token diventa non valido quando viene modificata la password dell’account Gmail utilizzato per l’invio. Il firewall non può più ottenere un nuovo Access Token con quel token. Questo non vale per tutti i token OAuth di Google né per Microsoft 365.

Verificare se è stata modificata la password di questo specifico account di invio. Confrontare client OAuth, account, autorizzazioni approvate e Publishing status: In production con la configurazione documentata. Anche un token generato prima di Publish App non costituisce una base duratura dopo sette giorni; verificare separatamente le due cause.
Con l’accesso attuale all’account e le credenziali del proprio client OAuth, ripetere l’autorizzazione Gmail e lo scambio dei token seguendo la procedura Playground descritta sopra. Verificare l’app e le autorizzazioni richieste prima di concedere il consenso e salvare il nuovo Refresh Token in modo sicuro.
In Administration > Notification settings, con Provider: Gmail, sostituire il Refresh token non valido con quello nuovo e salvare. Client ID e Client secret devono corrispondere al client OAuth utilizzato; non modificare senza motivo le impostazioni SMTP, TLS, di mittente, destinatario o eventi.
Inviare un’e-mail di prova e confermarne la consegna effettiva nella casella di destinazione o nel tracking del mail server. Verificare poi un evento selezionato attivato in modo controllato, come descritto nella sezione sull’intera catena degli eventi.

Inserire nuovamente il vecchio token non lo rende valido. Non reimpostare la password dell’account soltanto per ripristinare il percorso e-mail precedente. Se l’invio continua a non riuscire dopo la nuova autorizzazione, annotare il messaggio di errore esatto, il build SFOS e la configurazione del provider, senza secret o token, per proseguire l’analisi. Fino alla conferma del ripristino, utilizzare un percorso di allarme alternativo approvato o il relay SMTP documentato.

OAuth Microsoft 365 salva, ma non invia

Confrontare innanzitutto versione e build SFOS con NC-166854. Verificare quindi Client ID, Client secret, Refresh token, SMTP.Send, offline_access, Authenticated SMTP per l’account di invio e l’ora di sistema corretta.

Se l’e-mail di prova continua a non riuscire su un build non elencato come interessato, non si tratta automaticamente dello stesso errore. Il messaggio esatto, il build SFOS e i log di accesso del provider devono quindi essere inclusi nell’ulteriore analisi o in un ticket di supporto.

Gestire le notifiche

Se la consegna non riesce dopo una modifica, ripristinare innanzitutto la configurazione e-mail annotata: opzione mail server, server, porta, Authentication, Connection security, mittente, destinatario e interfaccia di gestione, oltre alla selezione del certificato precedente se è stata modificata. Lasciare invariata la selezione degli eventi se non faceva parte della modifica. Dopo il salvataggio, verificare nuovamente il percorso di allarme precedente con un’e-mail di prova e un evento selezionato attivato in modo controllato. Il ripristino è completo solo quando entrambi i messaggi sono effettivamente arrivati.

Utilizzare come destinatario una lista di distribuzione funzionale con un responsabile.
Testare nuovamente l’e-mail di prova e un evento reale dopo modifiche a mail server, DNS, routing, certificato, credenziali, app OAuth o firmware.
Testare l’intero percorso di allarme almeno ogni trimestre se nessun monitoring centrale lo controlla continuamente.
Documentare scadenza e rotazione di password, Client Secrets e token.
Adeguare regolarmente la selezione degli eventi alle nuove funzioni e ai servizi disattivati.
Definire un primo controllo e un percorso di escalation per ogni alert importante.

La checklist quotidiana di amministrazione di Sophos Firewall raccoglie i segnali di stato, sicurezza e amministrazione che devono essere controllati attivamente durante il funzionamento.

L’e-mail è un buon canale di allarme diretto, ma non sostituisce la conservazione centralizzata o la correlazione dei log. Per uno storico più lungo e l’analisi di sicurezza è indicato Inviare Syslog di Sophos Firewall a un SIEM. Per il classico monitoraggio dello stato e le trap, SNMP Hardware Monitoring è il complemento appropriato.

Per inviare analisi PDF ogni giorno o ogni settimana non si usa la Notification list, ma una pianificazione separata dei report. Pianificare i report Sophos Firewall e inviarli via e-mail spiega selezione, bookmark, test del trasporto e controllo dei contenuti.

Modificare l’indirizzo del destinatario tramite CLI Main Menu > 2. System Configuration