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.

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.

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. Sophos décrit les étapes actuelles sous Configure OAuth 2.0 on Gmail.

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.

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.

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