Configurer et tester les notifications e-mail Sophos Firewall

Pour que les notifications par e-mail fonctionnent, Sophos Firewall nécessite deux configurations distinctes : le transport des e-mails est configuré sous Administration > Notification settings. Les événements réellement signalés par e-mail sont définis sous System services > Notification list.

Le rapport de quarantaine destiné aux utilisateurs utilise également ce transport, mais son calendrier, son lien vers le portail et son affectation sont des réglages distincts.

Les textes visibles d’authentification, SMTP, d’administration et de SMS sous Administration > Messages constituent une troisième couche indépendante. Configurer l’avertissement de connexion et les messages sur Sophos Firewall explique leur contenu et leurs tests ; la modification d’un message ne configure ni le transport SMTP ni la sélection des événements.

La procédure rapide :

Configurer le serveur de messagerie, le port, l’authentification, le chiffrement, l’expéditeur et le destinataire sous Administration > Notification settings.
Envoyer un e-mail de test et confirmer sa livraison dans la boîte de destination ou le suivi du serveur de messagerie.
Activer le commutateur global Email notifications sous System services > Notification list.
Ne sélectionner que les événements auxquels un destinataire responsable peut réagir.
En plus de l’e-mail de test, déclencher de manière contrôlée un événement réel sélectionné et vérifier sa livraison.

Un e-mail de test réussi prouve seulement que le chemin SMTP fonctionne en principe. Il ne prouve pas que le commutateur global de messagerie et les bons événements sont activés. À l’inverse, une ligne d’événement sélectionnée n’envoie aucun message tant que le transport des e-mails ne fonctionne pas. Cette distinction explique également pourquoi un serveur SMTP configuré ne satisfait pas encore, sur le plan opérationnel, le point Notification Emails du Sophos Firewall Health Check.

Modifier l’adresse du destinataire via la Device Console

Si WebAdmin n’est pas disponible ou si l’adresse du destinataire doit être corrigée via un accès contrôlé à la console, utiliser 2. System Configuration > 3. Set Email ID for system notification. Cette option modifie uniquement l’adresse e-mail de l’administrateur pour les alertes système. Elle ne configure ni le serveur de messagerie, l’expéditeur, l’authentification et TLS, ni le commutateur global et les événements de la Notification list.

Documenter d’abord l’ancienne adresse. Confirmer ensuite la modification avec y, saisir la nouvelle adresse et vérifier que l’adresse affichée par SFOS ne contient aucune faute. Appuyer sur Enter pour revenir au menu. Un e-mail de test et un événement réel contrôlé doivent ensuite parvenir au nouveau destinataire ; la confirmation de la console ne prouve pas à elle seule la livraison.

Préparer l’envoi d’e-mails

Avant la configuration, le serveur de messagerie, le port et la méthode d’authentification doivent être confirmés avec l’administrateur de messagerie responsable. Lorsqu’un FQDN comme smtp.example.net est utilisé, le pare-feu doit pouvoir le résoudre et atteindre le serveur par le chemin de routage prévu. Une connexion Internet générale n’est nécessaire que si le serveur de messagerie ou le fournisseur OAuth choisi se trouve sur Internet. Un relais SMTP interne peut également fonctionner sans accès direct du pare-feu à Internet.

Un exemple réaliste :

Serveur de messagerie : smtp.example.net
Port : 587
Authentication : Basic
Connection security : STARTTLS
Expéditeur : fw-zrh-01@example.net
Destinataire : firewall-alerts@example.net
Management interface IP address : interface de management interne du pare-feu

Toutes les valeurs contenant example.net doivent être remplacées par le domaine de l’organisation et les adresses autorisées par l’administrateur de messagerie. Une adresse de distribution est généralement préférable à une boîte personnelle : les responsabilités peuvent changer sans qu’il soit nécessaire de reconfigurer chaque pare-feu.

La Management interface IP address ne détermine pas l’interface par laquelle la connexion SMTP quitte le pare-feu. L’adresse IP sélectionnée est incluse dans la notification et aide à identifier le pare-feu émetteur. Avec plusieurs sites, il faut donc choisir une adresse IP de management durablement compréhensible ; avec un seul pare-feu, None peut également suffire.

Configurer le serveur de messagerie

Choisir Built-in ou External email server

Sophos Firewall peut utiliser le Built-in email server ou un External email server. L’envoi intégré est pratique pour un démarrage simple. Dans les environnements de production, un relais dédié ou un serveur de messagerie cloud est souvent plus facile à suivre, car l’authentification, le suivi des e-mails, les autorisations d’expéditeur et les erreurs de livraison sont visibles à un emplacement central.

Nous recommandons donc l’External email server lorsqu’un service SMTP fiable est déjà exploité.

Pour le Built-in email server, cette courte procédure suffit :

Activer le Built-in email server sous Administration > Notification settings.
Saisir l’expéditeur, le destinataire et, en option, la Management interface IP address.
Enregistrer et envoyer l’e-mail de test.

Le Built-in email server ne dispose pas d’un suivi de relais distinct permettant à l’administrateur de retracer l’acceptation et le transfert. La livraison réelle doit donc être vérifiée avec une attention particulière. Si elle échoue de manière répétée ou si le domaine destinataire et les exigences de sécurité imposent un chemin SMTP contrôlé, un External email server est plus facile à exploiter.

Configurer un External email server

Ouvrir Administration > Notification settings.
Sélectionner External email server.
Saisir l’adresse IPv4 ou le FQDN du serveur de messagerie ainsi que le port spécifié.
Sous Authentication, sélectionner None, Basic ou OAuth 2.0 en fonction du serveur.
Sous Connection security, sélectionner le chiffrement de transport exigé par le serveur de messagerie.
Saisir l’expéditeur, le destinataire et, en option, la Management interface IP address.
Enregistrer et exécuter la fonction d’e-mail de test.

Le port par défaut de SFOS est 25, mais il ne s’agit pas d’une recommandation pour tous les environnements. Le listener du relais de l’organisation est déterminant. Les choix courants sont 25 pour un relais interne autorisé par l’IP source, 587 pour une soumission authentifiée avec STARTTLS ou 465 pour une connexion SSL/TLS directe. Le port, l’authentification et le mode de chiffrement doivent correspondre ensemble au serveur de messagerie.

None n’a pas la même signification dans les deux champs de sélection : sous Authentication, il désactive l’authentification auprès du serveur de messagerie. Cela peut être correct pour un relais interne qui autorise exclusivement l’IP source du pare-feu. Sous Connection security, None signifie en revanche une transmission SMTP non chiffrée. Ce réglage ne convient pas aux chemins Internet et ne doit être utilisé en interne que si le modèle de sécurité l’autorise explicitement.

Avec Basic, le pare-feu utilise un nom d’utilisateur et un mot de passe. Selon Sophos, le nom d’utilisateur est sensible à la casse. Le relais doit prendre en charge la méthode d’authentification utilisée ; une erreur relative à l’Authentication method indique notamment une différence concernant LOGIN ou PLAIN.

STARTTLS est souvent mal compris : le pare-feu suit les capacités du serveur de messagerie. Si le serveur propose STARTTLS, la connexion est chiffrée ; s’il ne le propose pas, le message peut être transmis sans chiffrement. Lorsqu’il faut imposer le chiffrement, utiliser SSL/TLS avec le port et le listener de serveur correspondants.

⚠️ L’option Allow invalid certificate sous Email > General settings ne doit pas être activée comme solution de contournement rapide. Un certificat expiré, non approuvé ou ne correspondant pas au nom du serveur doit être corrigé sur le serveur de messagerie ou dans la chaîne de confiance.

Si le pare-feu utilise Mail Protection en MTA Mode, le certificat employé pour l’envoi des e-mails dépend également de la configuration sous Email > General settings. Une modification ne doit donc pas être effectuée isolément, sans tenir compte du flux de messagerie de production.

Gmail et Microsoft 365 avec OAuth 2.0

Pour Gmail et Microsoft 365, l’aide actuelle de SFOS 22 exige OAuth 2.0. Le Provider, le Client ID, le Client secret et le Refresh token sont renseignés dans Notification settings. Bien que l’aide générale de Sophos décrive le Client secret comme facultatif pour Microsoft 365, la procédure Microsoft 365 documentée par Sophos en crée et en utilise explicitement un. Il est donc configuré dans cette procédure.

Pour Gmail, un projet et la Gmail API doivent être configurés dans Google Cloud, puis un client OAuth et un Refresh Token doivent être générés. La procédure suivante correspond au guide Sophos actuel Configure OAuth 2.0 on Gmail.

Configurer Gmail OAuth 2.0 étape par étape

Se connecter à Google Cloud Console avec le compte Google prévu, créer un nouveau projet et le sélectionner.
Ouvrir APIs & Services > Library, rechercher Gmail API et activer l’API.
Sous APIs & Services > Credentials, cliquer sur Create credentials > OAuth client ID.
Si l’écran de consentement est d’abord demandé, ouvrir Configure the OAuth consent screen > Get started. Renseigner le nom de l’application et l’adresse e-mail, sélectionner User type: External, ajouter l’adresse de contact du développeur et créer la configuration.
Sélectionner Create OAuth client, définir Application type: Web application et attribuer un nom explicite.
Sous Authorized redirect URIs, ajouter exactement https://developers.google.com/oauthplayground.
Créer le client OAuth et consigner immédiatement le Client ID et le Client secret de manière sécurisée.
Sous Audience > Add users, ajouter le compte Google qui enverra ensuite les notifications.
Ouvrir Google OAuth 2.0 Playground. À l’aide de l’icône d’engrenage, activer Use your own OAuth credentials, puis saisir le Client ID et le Client secret.
Sous Step 1 Select & authorize APIs, développer Gmail API v1, sélectionner le scope https://mail.google.com et lancer Authorize APIs. Utiliser le compte d’envoi prévu.
Sous Step 2 Exchange authorization code for tokens, échanger le code contre les tokens et copier le Refresh token de manière sécurisée.
Sur le pare-feu, configurer l’External email server sous Administration > Notification settings avec Authentication: OAuth 2.0 et Provider: Gmail. Saisir le Client ID, le Client secret et le Refresh token, enregistrer et envoyer un e-mail de test.

Google ne considère pas un projet OAuth avec User type External et Publishing status Testing comme une configuration de production durable : lors de l’utilisation du scope Gmail, le Refresh Token expire après sept jours selon Google OAuth 2.0. Le scope Gmail https://mail.google.com utilisé par Sophos permet, outre l’envoi, de lire, créer et supprimer définitivement des e-mails. L’application OAuth, les identifiants et, de préférence, un compte d’envoi dédié doivent donc être protégés et exploités comme un mot de passe de serveur de messagerie.

Pour Microsoft 365, l’application nécessite les autorisations déléguées SMTP.Send et offline_access ; Authenticated SMTP doit être activé pour le compte d’envoi. La procédure standard documentée utilise smtp.office365.com, le port 587 et STARTTLS. Si l’adresse d’expéditeur diffère de la boîte authentifiée, le compte a également besoin de Send As. Les étapes Entra actuelles sont disponibles sous Configure OAuth 2.0 on Microsoft 365.

Configurer Microsoft 365 OAuth 2.0 étape par étape

Dans Microsoft Entra admin center, créer une New registration sous Identity > Applications > App registrations.
Attribuer un nom explicite. Pour la procédure documentée par Sophos, sélectionner Accounts in any organizational directory (Any Microsoft Entra ID tenant - Multitenant) et saisir https://outlook.office365.com/ comme plateforme Web sous Redirect URI. Cette même URI doit ensuite être réutilisée à l’identique.
Enregistrer l’application et consigner l’Application (client) ID de manière sécurisée.
Sous API permissions > Add a permission > Microsoft Graph > Delegated permissions, ajouter SMTP.Send et offline_access. Exécuter ensuite Grant admin consent.
Pour le compte d’envoi, activer Authenticated SMTP sous Users > Active users > Mail > Email apps > Manage email apps.
Sous Certificates & secrets > Client secrets > New client secret, créer un secret avec une date d’expiration surveillée. Copier immédiatement et de manière sécurisée la Value affichée ; Entra ne l’affiche plus après le rechargement de la page.
Ouvrir l’URL suivante dans un navigateur. Remplacer YOUR_CLIENT_ID par l’Application ID ; la redirect_uri doit correspondre à celle de l’application enregistrée.

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=12345

Se connecter avec le compte d’envoi prévu et copier le code d’autorisation de courte durée depuis l’URL de redirection.
Envoyer le code au point de terminaison de token avec un client API au format application/x-www-form-urlencoded. Remplacer chaque paramètre fictif par les valeurs de cette application.

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

Enregistrer immédiatement et de manière sécurisée le Refresh token renvoyé. Le code d’autorisation, le Client secret, l’Access token et le Refresh token ne doivent pas figurer dans des tickets, des captures non protégées ou des logs.
Sur le pare-feu, configurer l’External email server sous Administration > Notification settings avec Authentication: OAuth 2.0 et Provider: Microsoft 365. Saisir smtp.office365.com, le port 587, STARTTLS, le Client ID, le Client secret et le Refresh token, enregistrer et envoyer un e-mail de test.

Sophos exige que le système exécutant le client API et le pare-feu utilisent le même fuseau horaire lors de la génération du token. Vérifier au préalable l’heure système et le fuseau horaire. Ne pas modifier spontanément le fuseau horaire du pare-feu en production ; Sophos exige ensuite un redémarrage, qui doit être planifié dans une fenêtre de maintenance.

Les Microsoft Security Defaults désactivent SMTP AUTH. Cette protection ne doit pas être désactivée globalement pour tout le tenant uniquement afin qu’un pare-feu puisse envoyer des messages. Si l’autorisation ciblée du compte d’envoi ne correspond pas au modèle de sécurité, un relais interne ou externe prévu à cet effet constitue l’approche la plus propre.

⚠️ La Known Issues list actuelle de Sophos contient toujours NC-166854 : OAuth Microsoft 365 pour les notifications ne fonctionne pas sur les builds répertoriés 22.0.0.274, 22.0.0.323, 21.0.2.349 et 21.5.1.261. Aucune version corrigée n’y est indiquée. Il faut donc vérifier le build SFOS exact et exiger la réussite de l’e-mail de test. Des champs Client ID, secret et token enregistrés ne prouvent pas que la fonction marche.

Si un build répertorié est concerné, utiliser un relais SMTP pris en charge ou un autre chemin de messagerie vérifié jusqu’à ce qu’une version de firmware corrigée soit confirmée de manière fiable. Des exceptions TLS non sécurisées ou une Basic Authentication non vérifiée ne constituent pas un bon remplacement pour une chaîne d’alerte fonctionnelle.

Sélectionner les événements dans la Notification list

Après un test de messagerie réussi, ouvrir System services > Notification list. Activer d’abord Email notifications, puis sélectionner les cases de la colonne Email pour les événements requis et enregistrer avec Save.

Tous les pare-feu n’ont pas besoin de la même sélection. Une base utile dépend des risques et des fonctions réellement utilisées :

Admin : échecs de connexion et trop grand nombre de tentatives de connexion échouées.
HA : ports ou interfaces surveillés déconnectés lorsqu’un cluster HA est exploité.
Disk/Memory : avertissements de stockage afin qu’une zone de reporting ou du système pleine ne soit pas découverte seulement pendant une fenêtre de maintenance. Les seuils et conséquences sont expliqués dans Vérifier le stockage et les rapports de Sophos Firewall.
Firmware : nouveau firmware et surtout échecs d’installation en fonction du processus de mise à jour de l’organisation.
System : échec des mises à jour de signatures ou de bases de données, démarrage du système, utilisation élevée du processeur et Gateway status.
IPS et Active threat response : commencer par les événements critiques ou bloquants lorsqu’un processus de triage existe.
RED, AP et VPN : uniquement pour les appareils et les connexions importantes réellement utilisés.
Web - Instant alerts : catégories Web sélectionnées de manière réfléchie. Ces notifications sont envoyées par lots de cinq minutes et nécessitent une activation séparée de la catégorie, comme décrit dans Catégories Web et Instant Alerts.

Activer tous les événements sans discernement conduit rapidement à la fatigue d’alerte. Les notifications VPN, en particulier, peuvent être répétées environ toutes les 60 secondes jusqu’à la résolution de la cause ; avec plusieurs réseaux locaux et distants, une notification peut également être générée par paire de sous-réseaux. Une petite sélection avec une réponse claire est préférable : qui reçoit l’alerte, quelle est son urgence et quelle est la première vérification ?

Certaines Default Notifications sont envoyées automatiquement par le pare-feu et ne peuvent pas être désélectionnées. Elles comprennent certaines modifications de rôle et d’état HA, l’état des hôtes virtuels ainsi qu’un redémarrage ou un arrêt via WebAdmin. Le chemin de messagerie configuré doit également être joignable pour ces notifications.

Vérifier l’e-mail de test et un événement réel

La vérification se déroule en deux étapes.

1. Confirmer la livraison SMTP avec un e-mail de test

Envoyer l’e-mail de test sous Administration > Notification settings. Le message de réussite du pare-feu ne suffit pas : la boîte de destination, le filtre antispam ou le suivi du serveur de messagerie doit montrer que le message a réellement été accepté et livré.

Les points suivants sont contrôlés :

L’expéditeur et le destinataire sont corrects.
Le pare-feu attendu est identifiable par l’objet, le contenu ou l’IP de management.
Le message n’arrive pas durablement dans le spam ou la quarantaine.
La liste de distribution accepte les messages de l’expéditeur configuré.

2. Tester toute la chaîne d’événements

Déclencher ensuite de manière contrôlée un événement sélectionné. Exemples appropriés :

un seul échec de connexion avec un compte de test, après vérification des verrouillages et des seuils de connexion ;
le passage Up/Down d’un tunnel VPN de test expressément prévu à cet effet ;
Gateway status pendant un test de WAN Failover planifié.

Redémarrer ou déconnecter une passerelle de production, un port HA ou le pare-feu lui-même uniquement pour tester un e-mail serait disproportionné. Un scénario de maintenance ou de basculement déjà planifié constitue un meilleur test.

La chaîne complète n’est confirmée que lorsque l’événement parvient au bon destinataire dans le délai prévu : détection de l’événement, sélection de l’événement, commutateur global de messagerie, transport SMTP et livraison.

Délimiter les erreurs systématiquement

L’e-mail de test échoue déjà

L’API SFOS 22 distingue plusieurs catégories d’erreurs :

Failed to connect ou SMTP server failed to respond : vérifier la résolution du FQDN, la route, le port, le pare-feu en amont et le listener du serveur de messagerie.
Password mismatch : vérifier le nom d’utilisateur, la casse, le mot de passe et un éventuel verrouillage du compte.
Authentication method mismatch : vérifier que le relais et SFOS prennent tous deux en charge LOGIN ou PLAIN pour Basic Authentication.
STARTTLS not supported : le port et Connection security ne correspondent pas au listener du serveur.
Mail server refused to communicate : vérifier l’autorisation de relais, l’adresse d’expéditeur, l’IP source autorisée et les journaux du serveur de messagerie.
Couldn’t generate the OAuth 2.0 access token : vérifier le Provider, le Client ID, le secret, le Refresh Token, les autorisations et l’heure système.

DNS et STARTTLS peuvent être précontrôlés sans modifier le serveur de messagerie depuis un système d’administration situé sur un chemin réseau comparable :

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

Remplacer smtp.example.net et 587 par le serveur et le port de l’organisation. nslookup confirme uniquement la résolution de noms du système d’administration. openssl s_client montre la joignabilité SMTP, la négociation TLS et la chaîne de certificats, mais ne vérifie ni la route du point de vue du pare-feu, ni son authentification, ni la livraison ultérieure.

Dans Log Viewer et, pour une analyse plus approfondie, dans cschelper.log, l’heure du test peut être corrélée avec l’e-mail généré par le système. L’accès aux journaux de service et la distinction avec l’Advanced Shell sont expliqués dans Services et journaux Sophos Firewall. Les journaux MTA tels que smtpd_main.log appartiennent principalement à Mail Protection et ne constituent pas systématiquement le journal des notifications.

L’e-mail de test arrive, mais les e-mails d’événements manquent

Le transport fonctionne alors, et la recherche commence sous System services > Notification list :

Email notifications est-il activé globalement ?
L’événement concerné est-il sélectionné dans la colonne Email ?
L’événement attendu s’est-il réellement produit et appartient-il à la bonne catégorie ?
Existe-t-il un délai ou un regroupement connu, par exemple pour les Web Instant Alerts ?
Le filtre antispam, la quarantaine ou le suivi du serveur de messagerie montre-t-il une acceptation ou un refus ?

Pour un événement spécialisé, il faut également vérifier sa condition fonctionnelle. Une alerte IPS, par exemple, n’est pas créée par la seule activation d’une case à cocher : une règle IPS correspondante doit d’abord journaliser et rejeter l’événement. Une notification VPN dépend du type de tunnel et de l’état Up/Down réel.

OAuth Microsoft 365 s’enregistre, mais n’envoie rien

Comparer d’abord la version et le build SFOS avec NC-166854. Vérifier ensuite le Client ID, le Client secret, le Refresh token, SMTP.Send, offline_access, Authenticated SMTP pour le compte d’envoi et l’heure système correcte.

Si l’e-mail de test continue d’échouer sur un build qui n’est pas répertorié comme affecté, il ne s’agit pas automatiquement du même problème. Le message exact, le build SFOS et les journaux de connexion du fournisseur doivent alors être inclus dans l’analyse approfondie ou dans un ticket de support.

Exploiter les notifications

Utiliser comme destinataire une liste de distribution fonctionnelle avec un responsable identifié.
Tester de nouveau l’e-mail de test et un événement réel après toute modification du serveur de messagerie, du DNS, du routage, du certificat, des identifiants, de l’application OAuth ou du firmware.
Tester toute la chaîne d’alerte au moins une fois par trimestre si aucun monitoring central ne la surveille en continu.
Documenter l’expiration et la rotation des mots de passe, Client Secrets et tokens.
Adapter régulièrement la sélection des événements aux nouvelles fonctions et aux services désactivés.
Définir une première vérification et un chemin d’escalade pour chaque alerte importante.

La checklist quotidienne d’administration de Sophos Firewall regroupe les signaux d’état, de sécurité et d’administration qui doivent également être contrôlés activement en exploitation.

L’e-mail est un bon canal d’alerte direct, mais ne remplace pas la conservation centralisée ni la corrélation des journaux. Pour un historique plus long et l’analyse de sécurité, voir Envoyer les journaux Syslog de Sophos Firewall à un SIEM. Pour la surveillance d’état classique et les traps, SNMP Hardware Monitoring constitue le complément approprié.

Pour envoyer des analyses PDF chaque jour ou chaque semaine, on n’utilise pas la Notification list, mais une planification de rapports distincte. Planifier les rapports Sophos Firewall et les envoyer par e-mail explique la sélection, les bookmarks, le test du transport et le contrôle du contenu.