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.

La procedura rapida:

1. Configurare mail server, porta, autenticazione, cifratura, mittente e destinatario in Administration > Notification settings.
2. Inviare un’e-mail di prova e confermarne la consegna nella casella di destinazione o nel tracking del mail server.
3. Attivare l’interruttore globale Email notifications in System services > Notification list.
4. Selezionare solo gli eventi per i quali un destinatario responsabile può intervenire.
5. 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.

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.

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.

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:

1. Attivare il Built-in email server in Administration > Notification settings.
2. Inserire mittente, destinatario e, facoltativamente, Management interface IP address.
3. 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

1. Aprire Administration > Notification settings.
2. Selezionare External email server.
3. Inserire l’indirizzo IPv4 o il FQDN del mail server e la porta indicata.
4. In Authentication, selezionare None, Basic o OAuth 2.0 in base al server.
5. In Connection security, impostare la cifratura del trasporto richiesta dal mail server.
6. Inserire mittente, destinatario e, facoltativamente, Management interface IP address.
7. 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. Secondo Sophos, 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à.

Se il firewall utilizza Mail Protection in MTA Mode, il certificato usato per l’invio e-mail dipende anche dalla configurazione in Email > General settings. Una modifica non deve quindi essere effettuata isolatamente senza considerare il flusso di posta di produzione.

Gmail e Microsoft 365 con OAuth 2.0

Per Gmail e Microsoft 365, la guida corrente di SFOS 22 richiede OAuth 2.0. In Notification settings vengono inseriti Provider, Client ID, Client secret e Refresh token. Sebbene la guida generale Sophos descriva il Client secret come facoltativo per Microsoft 365, la procedura Microsoft 365 documentata da Sophos ne crea e utilizza espressamente uno. 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. Sophos descrive i passaggi correnti in Configure OAuth 2.0 on Gmail.

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 da Sophos 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. I passaggi Entra correnti sono disponibili in Configure OAuth 2.0 on Microsoft 365.

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.

⚠️ L’attuale Known Issues list di Sophos contiene ancora NC-166854: OAuth Microsoft 365 per le notifiche non funziona sui build elencati 22.0.0.274, 22.0.0.323, 21.0.2.349 e 21.5.1.261. Non viene indicata una versione corretta. Occorre quindi controllare il build SFOS esatto 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.

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 e soprattutto installazioni non riuscite in linea con il processo di aggiornamento dell’organizzazione.
• System: aggiornamenti di firme o database non riusciti, avvio del sistema, elevato utilizzo della CPU e Gateway status.
• IPS e Active threat response: inizialmente eventi critici o bloccanti, se esiste un processo di triage.
• RED, AP e VPN: solo per dispositivi e connessioni importanti effettivamente utilizzati.
• Web - Instant alerts: categorie Web selezionate consapevolmente. Queste notifiche vengono inviate in batch di cinque minuti 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. Comprendono determinati cambiamenti di ruolo e stato HA, lo stato degli host virtuali e un riavvio o arresto tramite WebAdmin. Anche per queste notifiche il percorso e-mail configurato deve essere raggiungibile.

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

Inviare l’e-mail di prova in Administration > Notification settings. 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.

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;
• stato Up/Down di un tunnel VPN di test espressamente previsto a questo scopo;
• 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

L’e-mail di prova fallisce già

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:

1. Email notifications è attivo globalmente?
2. L’evento specifico è selezionato nella colonna Email?
3. L’evento atteso si è effettivamente verificato e appartiene alla categoria corretta?
4. È presente un ritardo o un raggruppamento noto, ad esempio per i Web Instant Alerts?
5. 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 e scartare l’evento. Una notifica VPN dipende dal tipo di tunnel e dallo stato Up/Down effettivo.

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

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

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.