Analyser et tester POP3 et IMAP sur Sophos Firewall

Sophos Firewall peut analyser les e-mails lorsque les clients les relèvent via POP3, POP3S, IMAP et IMAPS. Cela s’applique aussi bien en mode MTA qu’en mode Legacy ; le chemin vers la stratégie POP-IMAP facultative diffère. Une stratégie seule ne suffit pas : seule une règle firewall correspondante dirige le trafic de messagerie vers le proxy et active les paramètres d’analyse et TLS configurés.

Le test de validation le plus important n’est donc pas un commutateur vert, mais une relève réelle depuis le client prévu vers le serveur de messagerie prévu. La Firewall Rule ID, le port, la chaîne de certificats, la version TLS négociée et warren.log doivent tous correspondre au chemin planifié.

⚠️ Sans Scan email content dans la règle firewall qui s’applique réellement, SFOS n’applique pas les paramètres ni les stratégies POP/IMAP. Une stratégie seule n’offre aucune protection.

Analyse POP/IMAP en huit étapes

1. Documenter le réseau client, le serveur de messagerie, les protocoles et les ports réellement utilisés.
2. Sélectionner une seule source pilote et tester sa relève de courrier actuelle.
3. Importer sous Certificates > Certificate authorities la CA qui a émis le certificat du serveur de messagerie si elle n’est pas encore approuvée.
4. Définir POP/S and IMAP/S settings et POP and IMAP TLS configuration sous Email > General settings.
5. Uniquement si nécessaire, créer une stratégie POP-IMAP scan pour les expéditeurs, destinataires ou caractéristiques des messages : sous Email > Policies and exceptions en mode MTA ou sous Email > Policies en mode Legacy.
6. Créer une règle firewall restreinte et journalisée pour le client pilote et le serveur de messagerie, puis activer les protocoles requis sous Scan email content.
7. Vérifier la relève, la connexion TLS, la Firewall Rule ID et warren.log avec un petit message de test.
8. N’ajouter d’autres clients qu’après les tests positif et négatif et documenter le retour arrière.

Ce que protège le proxy POP/IMAP

POP3 et IMAP servent à relever et gérer des messages dans une boîte aux lettres. Ils ne doivent pas être confondus avec SMTP, qui transporte les messages entre un expéditeur, un MTA et un serveur de messagerie. Le guide du mode MTA explique donc MX, le routage SMTP, le relais, le spool et la quarantaine SMTP ; ce guide se concentre sur la relève du courrier par un client.

SFOS distingue les ports non chiffrés ou mis à niveau avec STARTTLS des variantes qui utilisent TLS dès le début :

• POP3: TCP 110, avec passage facultatif à TLS via STARTTLS
• POP3S: TCP 995, TLS dès le début de la connexion
• IMAP: TCP 143, avec passage facultatif à TLS via STARTTLS
• IMAPS: TCP 993, TLS dès le début de la connexion

Dans une nouvelle conception, les clients de messagerie devraient utiliser des connexions chiffrées. Sélectionner un protocole dans SFOS ne modifie toutefois pas la configuration du client. Si le client utilise un autre port ou contourne la règle planifiée, ce trafic n’est pas automatiquement protégé par l’option standard sélectionnée.

L’analyse POP/IMAP nécessite une licence Email Protection valide. Elle ne remplace ni la protection du serveur de messagerie ni l’analyse lors de l’arrivée d’un message via SMTP. Avec les services de messagerie cloud en particulier, il faut d’abord confirmer que le fournisseur autorise encore la relève POP/IMAP classique et qu’un proxy transparent est compatible avec ses exigences TLS et d’authentification.

Définir l’exemple et le périmètre du test

Un pilote contrôlé évite qu’une mauvaise configuration de certificat ou de règle affecte simultanément tous les clients de messagerie. Cet exemple utilise des valeurs de documentation :

• client pilote 10.20.30.50 dans la zone LAN
• serveur de messagerie mail.example.net
• adresse de destination 192.0.2.25
• protocole utilisé IMAPS sur TCP 993
• règle firewall Pilot_POP_IMAP_Scan

Remplacer 10.20.30.50, mail.example.net et 192.0.2.25 par les valeurs réelles. L’adresse de destination appartient à la plage de documentation TEST-NET et ne doit pas être utilisée comme adresse de serveur en production. Le pilote devrait utiliser une boîte de test dédiée et non le seul compte d’un administrateur.

Avant le changement, relever un message et noter l’émetteur actuel du certificat. Conserver également la règle firewall existante, son compteur et la configuration du client. Cela permet ensuite de distinguer un problème de routage, TLS, analyse par proxy ou serveur de messagerie.

Préparer TLS et les limites d’analyse

CA et validation du certificat

Sous Certificates > Certificate authorities, ajouter la CA qui a émis le certificat du serveur de messagerie si le firewall ne lui fait pas déjà confiance. Les fichiers de CA privées doivent provenir uniquement de la PKI de l’organisation ou d’une autre source vérifiée. Importer des certificats sur Sophos Firewall explique l’importation générale et le contrôle de la chaîne.

Sous Email > General settings > POP and IMAP TLS configuration, sélectionner ensuite dans TLS certificate la CA ayant émis le certificat du serveur de messagerie, préalablement vérifiée et importée. Laisser Allow invalid certificate désactivé. Désactiver la validation ne répare pas un serveur distant invalide, expiré ou non approuvé.

Cocher Disable legacy TLS protocols pour désactiver les protocoles antérieurs à TLS 1.1, conformément à l’aide SFOS. Cette option ne prouve pas qu’une session donnée utilise TLS 1.2 ou TLS 1.3. Si la norme de sécurité exige au minimum TLS 1.2, vérifier la version négociée sur le chemin réel du client. Si la combinaison déployée ne peut pas respecter cette exigence, arrêter le déploiement et évaluer une autre architecture de protection.

Comme le firewall traite le trafic de messagerie chiffré pour l’analyser, un avertissement de certificat peut apparaître sur le client. Un nouvel avertissement ne doit pas être ignoré. Vérifier le nom présenté, l’émetteur, la chaîne et la confiance du client, puis corriger la cause avant un déploiement étendu.

Taille des messages et en-têtes de destinataire

Sous POP/S and IMAP/S settings, Don’t scan emails greater than définit la taille maximale des messages à analyser. Pour POP/IMAP, 0 ne signifie pas illimité ; selon l’aide SFOS, cette valeur fixe la limite à 10,240 KB. Les messages plus volumineux ne sont pas analysés. La limite doit correspondre aux pièces jointes habituelles, aux performances disponibles et au risque résiduel accepté.

Les Recipient headers aident SFOS à identifier les destinataires pour les stratégies POP/IMAP. Par défaut, le firewall utilise Delivered-To, Received et X-RCPT-TO. N’ajouter un autre en-tête que si le véritable serveur de messagerie le définit de manière fiable. Un en-tête inventé ou supprimé en aval produit sinon des correspondances de stratégie difficiles à comprendre.

Créer une stratégie POP-IMAP facultative

Avec un abonnement Email Protection actif, SFOS applique automatiquement la stratégie par défaut default-pop-av au trafic POP3/S et IMAP/S. Elle supprime les pièces jointes infectées par un virus et remplace le corps du message par une notification. Cette stratégie de base automatique doit être prise en compte lors des tests et du diagnostic avant d’attribuer le comportement à une stratégie personnalisée.

Une stratégie POP-IMAP ajoute des critères et des avertissements destinés aux utilisateurs. En mode MTA, le chemin est Email > Policies and exceptions > Add policy > POP-IMAP scan ; en mode Legacy, il est Email > Policies > Add policy > POP-IMAP scan. Définir d’abord un nom ainsi que les groupes d’expéditeurs et de destinataires. La stratégie peut ensuite réagir, entre autres, à une classification de spam, à une IP ou un réseau source, à la taille du message ou à un en-tête.

Pour les expéditeurs et destinataires, choisir des groupes d’adresses e-mail ou de domaines et une correspondance exacte ou par mot-clé. Des adresses de test individuelles avec correspondance exacte permettent un périmètre pilote précis ; des groupes de domaines ou des mots-clés peuvent élargir le périmètre prévu. Vérifier la portée réelle avec des messages correspondants et non correspondants, sans supposer de règles supplémentaires concernant les caractères génériques ou la casse.

• Inbound email is: choisir spam, probable spam, virus outbreak ou probable virus outbreak comme classification.
• Source IP/network address: indiquer l’adresse IP ou réseau de l’expéditeur.
• Message size: définir une limite supérieure ou inférieure de taille du message. Ce critère de stratégie ne remplace pas la limite globale Don’t scan emails greater than.
• Message header: choisir l’en-tête ; pour Other, saisir ses détails. Choisir ensuite une correspondance exacte ou par mot-clé et indiquer la valeur du mot-clé à comparer.

Les actions documentées sont Accept et Prefix subject. Prefix subject distribue le message et ajoute un avertissement à son objet. La stratégie n’est donc pas une règle générale de quarantaine ou de blocage. Si None est choisi comme critère, l’action s’applique à tous les messages entre les expéditeurs et destinataires indiqués. Examiner consciemment cette portée avant d’enregistrer.

Un exemple pilote inoffensif utilise les groupes d’adresses de test de l’organisation avec une correspondance exacte et le critère Message header : Other, détails Subject, correspondance exacte, valeur du mot-clé Test email. Configurer Prefix subject avec le préfixe librement choisi Pilot, puis enregistrer la stratégie. Pour le message correspondant, l’objet attendu passe de Test email à Pilot: Test email. Un second message entre les mêmes adresses de test avec l’objet Control email ne correspond pas au critère d’en-tête et ne doit pas recevoir ce préfixe. Adapter les adresses et le préfixe au pilote ; tester deux nouveaux messages sur le même chemin de relève prévu. Les autres stratégies actives ne doivent pas fausser la comparaison.

Pour modifier une stratégie POP-IMAP scan existante, ouvrir Email > Policies and exceptions en mode MTA ou Email > Policies en mode Legacy. Sélectionner Edit pour la stratégie concernée, modifier les paramètres nécessaires et enregistrer la stratégie. Vérifier ensuite à nouveau la relève du courrier et l’effet de la stratégie sur le chemin prévu du client.

La stratégie supplémentaire peut être omise pour le premier test technique du proxy. Cela permet de voir clairement si la chaîne de base composée de TLS, de la règle firewall et de l’analyse fonctionne déjà. Ajouter une stratégie uniquement lorsqu’une logique d’expéditeur, de destinataire ou d’en-tête est réellement nécessaire.

Hiérarchie XML et limites de l’automatisation

Pour l’automatisation, l’objet de stratégie se nomme POPIMAPScanningPolicy. Les précisions suivantes décrivent la structure documentée pour SFOS 22/23, et non une requête POST testée ou prête à être envoyée. Sécuriser l’accès à l’API XML explique comment sécuriser l’accès et interpréter les réponses XML. Les options d’analyse de la règle firewall qui s’applique réellement restent nécessaires, même pour une stratégie gérée via l’API.

L’exemple documenté distingue trois niveaux :

• POPIMAPScanningPolicy/Name désigne la stratégie à gérer. POPIMAPScanningPolicy/After/Name désigne en revanche l’autre stratégie après laquelle elle est placée dans l’exemple. Ne pas confondre le nom de la stratégie cible et la référence utilisée pour son positionnement. L’exemple atteste cette structure de placement, mais ne démontre ni un ordre général d’évaluation ni le comportement en cas de référence absente ou d’omission de After.
• POPIMAPScanningPolicy/EmailAddress contient SenderEmail, SenderAction, RecipientEmail et RecipientAction. Les valeurs d’adresse et les opérateurs de correspondance appartiennent donc au nœud parent commun EmailAddress, et non directement à l’objet de stratégie. La description des paramètres présente les deux valeurs d’adresse comme des chaînes individuelles ; la sélection de groupes dans l’interface n’implique pas de nœud de liste XML supplémentaire.
• Dans l’exemple, FilterCriteria, Action, To et MatchIs se trouvent directement sous POPIMAPScanningPolicy, en dehors de EmailAddress et de After. Ici, To contient le préfixe de l’objet pour l’action de préfixe, et non une adresse de destinataire. Selon le critère, MatchIs décrit la classification des e-mails entrants ou la valeur d’en-tête à comparer.

Le tableau des paramètres indique que Name, SenderEmail, SenderAction, RecipientEmail, RecipientAction, FilterCriteria et Action sont obligatoires. Il indique pour Name un maximum de 255 caractères, pour To un maximum de 300 et pour MatchIs un maximum de 750 caractères. Ces limites décrivent les champs, et non la portée admissible de la stratégie ; par exemple, la valeur d’adresse Any présentée dans l’exemple n’est pas un choix approprié pour un pilote restreint.

Les autres paramètres propres aux critères sont Address pour l’IP ou le réseau source (tableau de chaînes, plusieurs valeurs), MessageSizeOperator avec MessageSize (entier), ainsi que MessageHeaderString (maximum de 765 caractères) avec MessageHeaderOperator pour les comparaisons d’en-têtes. Le tableau des paramètres mentionne ces champs, mais l’exemple présenté pour les e-mails entrants ne les contient pas. Il ne constitue donc pas un modèle XML complet pour les filtres d’IP source, de taille ou d’en-tête ; il ne permet pas de déduire les nœuds parents manquants, les unités de taille ou les dépendances entre champs obligatoires.

⚠️ Dans la description des paramètres, certaines valeurs admissibles ne sont indiquées que sous forme de symboles non résolus, tels que $POPIMAP{SENDER_MATCHTYPE_CONTAINS}, $POPIMAP{RULETYPE_INBOUND_EMAIL} et $POPIMAP{POP_IMAP_ACTION_PREFIX_SUBJECT}. Ces symboles ne sont pas des valeurs littérales confirmées pour un POST. L’exemple présente certes Contains, InboundEmailIs et Prefix Subject, mais ne fournit pas de correspondance complète pour toutes les constantes. Pour MessageHeaderOperator, la colonne des valeurs par défaut indique même GreaterThan, alors que la description prévoit Contains/Equals. Ne pas résoudre cette contradiction en devinant un opérateur, et ne pas envoyer des libellés de l’interface ou des noms de symboles comme valeurs d’API sans les avoir vérifiés.

Tant que les valeurs concrètes et la structure de filtre requise pour le build déployé ne sont pas clarifiées, la configuration via l’interface décrite ci-dessus reste la méthode sûre et documentée. Avant une modification via l’API ultérieurement autorisée, sauvegarder les noms, l’ordre, le périmètre des adresses, le critère et l’action ; après la modification, relire l’état enregistré ou le vérifier dans l’interface, puis relever à nouveau la paire de messages de test correspondant et non correspondant. La référence répertorie les valeurs de statut XML 200, 500 et 502 pour Add et Edit, mais ne fournit aucun message explicatif. Un succès HTTP ne confirme donc à lui seul ni la stratégie enregistrée ni son effet. Aucun appel d’écriture n’a été exécuté sur une appliance dans le cadre de cette description.

Créer la règle firewall pour la relève du courrier

Créer la règle sous Rules and policies > Firewall rules. En mode MTA, il est aussi possible de compléter la règle firewall MTA créée automatiquement ; une règle dédiée et restreinte est toutefois plus facile à évaluer pour un pilote clairement délimité. En mode Legacy, créer une nouvelle règle firewall. Elle ne devrait contenir que le réseau client ou l’hôte pilote prévu, la destination du serveur de messagerie et les ports de messagerie réellement requis. Une règle générale de LAN vers WAN dotée de nombreuses fonctions de sécurité est difficile à évaluer lors de la validation.

Les valeurs suivantes conviennent à l’exemple Pilot_POP_IMAP_Scan :

• Source zones: LAN
• Source networks and devices: hôte 10.20.30.50
• Destination zones: zone du chemin vers le serveur de messagerie, généralement WAN pour un serveur externe
• Destination networks: objet hôte pour 192.0.2.25 ou pour le vrai serveur de messagerie
• Services: IMAPS
• Log firewall traffic: activé

Sous Scan email content, activer Scan IMAPS. Si l’environnement utilise réellement d’autres protocoles, sélectionner également Scan IMAP, Scan POP3 ou Scan POP3S. Add ports ajoute les services correspondants ; ils doivent ensuite apparaître sous Services dans la règle.

Placer la règle au-dessus d’une règle plus générale qui correspond déjà au même client et au même serveur de messagerie. Après l’enregistrement, la Firewall Rule ID réelle dans Log Viewer est déterminante, et non la position attendue dans la liste. Configurer les règles Sophos Firewall en toute sécurité explique la construction, l’ordre et la validation par Rule ID.

Tester le chemin complet

Déposer d’abord un petit message inoffensif dans la boîte de test privée. Le client pilote le relève au moyen du FQDN et du port prévus. Dans Log Viewer, l’IP source, l’IP de destination, le service, l’action et la Firewall Rule ID doivent correspondre à la nouvelle règle. L’augmentation du compteur d’une autre règle constitue une condition d’arrêt.

Pour contrôler le certificat et TLS, il est par exemple possible d’exécuter ces connexions en lecture seule depuis un client du même réseau :

openssl s_client -connect mail.example.net:993 -servername mail.example.net
openssl s_client -connect mail.example.net:995 -servername mail.example.net
openssl s_client -starttls imap -connect mail.example.net:143 -servername mail.example.net
openssl s_client -starttls pop3 -connect mail.example.net:110 -servername mail.example.net

Tester uniquement les protocoles réellement proposés par le serveur de messagerie. Remplacer mail.example.net par le vrai FQDN. La sortie confirme le certificat, la chaîne et les paramètres TLS, mais pas une connexion réussie ni l’analyse du contenu. Mettre fin à la connexion interactive avec Ctrl+C après le contrôle.

Répéter ensuite la relève avec le véritable client de messagerie. Utiliser warren.log pour l’analyse du proxy ; Log Viewer et Packet Capture montrent en outre la correspondance de la règle et le chemin réseau. Noter ensemble l’horodatage, l’IP du client, l’IP du serveur, le port et l’objet du test. Services et journaux Sophos Firewall classe le fichier journal et explique un accès sûr.

La relève, la Firewall Rule ID, les paramètres TLS et la corrélation avec warren.log démontrent ensemble le chemin de relève et TLS prévu, pas l’efficacité de l’antivirus. Si une stratégie personnalisée Prefix subject est configurée, tester également la paire de messages décrite ci-dessus : Pilot: Test email pour le message correspondant et aucun préfixe Pilot pour Control email. Documenter les objets réellement distribués ; même un préfixe correct démontre uniquement l’action de la stratégie, pas l’efficacité de l’antivirus. En cas d’écart, contrôler les groupes, le type de correspondance, les en-têtes et les autres stratégies actives, puis retester les deux messages.

Le test du chemin comprend aussi un cas négatif. Pour un hôte pilote non autorisé ou un port non sélectionné, définir au préalable le traitement attendu par les règles, puis contrôler la Rule ID réelle et les options d’analyse. Corriger une seconde règle d’analyse involontairement trop large ; une protection alternative délibérément prévue n’est pas un défaut. Le test n’exige ni une absence globale de protection ni un blocage systématique. Si un serveur de test spécialement préparé avec une chaîne de certificats non valide est disponible, la tentative de connexion ou de relève doit échouer en raison de la validation de cette chaîne tant que Allow invalid certificate est désactivé sur le firewall ; ne pas provoquer de défaut de certificat sur le serveur de production pour ce test.

Délimiter les erreurs par symptôme

La relève fonctionne, mais le proxy n’analyse pas

Contrôler d’abord la Firewall Rule ID. Si une règle supérieure ou plus générale s’applique, corriger l’ordre, la source, la destination et le service. Si la règle prévue s’applique, l’option correspondante Scan IMAP/IMAPS/POP3/POP3S et le port doivent être actifs sous Services. Une stratégie POP-IMAP seule n’active pas le proxy.

Le client de messagerie signale une erreur de certificat après l’activation

Relever le FQDN présenté, l’émetteur, la validité et la chaîne complète. Contrôler ensuite la CA sélectionnée sous POP and IMAP TLS configuration et la confiance du client. Ne pas activer Allow invalid certificate comme solution permanente. Si le certificat présenté par le proxy ou le serveur reste incertain, revenir sur le pilote avant d’affecter d’autres clients.

STARTTLS fonctionne, mais pas POP3S ou IMAPS

Contrôler séparément les ports et les modes de connexion. POP3 sur 110 et IMAP sur 143 ne passent à une session chiffrée qu’avec STARTTLS ; POP3S sur 995 et IMAPS sur 993 démarrent avec TLS. Le client de messagerie, l’écouteur du serveur, le service du firewall et l’option d’analyse activée doivent utiliser la même variante.

Un message volumineux est distribué, mais pas analysé

Comparer Don’t scan emails greater than à la taille réelle du message. Même 0 limite l’analyse POP/IMAP à 10,240 KB. Ne pas augmenter aveuglément la limite pour un seul test sans évaluer l’effet sur les performances et le risque accepté.

Le préfixe de l’objet est absent

Contrôler les groupes d’expéditeurs et de destinataires, le type de correspondance, le critère et les Recipient headers. Le message peut avoir été analysé techniquement même si la stratégie facultative ne s’est pas appliquée. Évaluer séparément le fonctionnement du proxy et l’action de la stratégie.

Exploitation et retour arrière

Après un pilote réussi, ajouter progressivement les autres clients. Surveiller les compteurs de règle, warren.log, les erreurs TLS et les retours du support pendant le déploiement. Les modifications du certificat du serveur de messagerie, du FQDN, du port ou du profil client doivent ensuite suivre le même processus de changement, car elles modifient le chemin validé.

Pour revenir en arrière, retirer d’abord le pilote de la règle restreinte ou désactiver l’option d’analyse correspondante. Vérifier ensuite que la relève initiale fonctionne à nouveau et que l’ancienne règle attendue s’applique. Ne supprimer une CA importée ou un paramètre POP/IMAP global que si aucun autre service ne l’utilise. Ne pas supprimer des messages, des journaux ou des certificats comme étape standard de retour arrière.

FAQ