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. Créer une stratégie POP-IMAP 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
- Documenter le réseau client, le serveur de messagerie, les protocoles et les ports réellement utilisés.
- Sélectionner une seule source pilote et tester sa relève de courrier actuelle.
- Importer sous Certificates > Certificate authorities la CA qui a émis le certificat du serveur de messagerie si elle n’est pas encore approuvée.
- Définir POP/S and IMAP/S settings et POP and IMAP TLS configuration sous Email > General settings.
- Uniquement si nécessaire, créer sous Email > Policies and exceptions une stratégie POP-IMAP scan pour les expéditeurs, destinataires ou caractéristiques des messages.
- 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.
- Vérifier la relève, la connexion TLS, la Firewall Rule ID et
warren.logavec un petit message de test. - 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.50dans la zoneLAN - serveur de messagerie
mail.example.net - adresse de destination
192.0.2.25 - protocole utilisé
IMAPSsur TCP993 - 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.
Sélectionner ensuite le TLS certificate prévu sous Email > General settings > POP and IMAP TLS configuration. Laisser Allow invalid certificate désactivé. Désactiver la validation ne répare pas un serveur distant invalide, expiré ou non approuvé.
Selon l’aide SFOS, Disable legacy TLS protocols désactive les protocoles antérieurs à TLS 1.1. 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. Sous Email > Policies and exceptions > Add a 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.
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.
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.
Créer la règle firewall pour la relève du courrier
Créer la règle sous Rules and policies > Firewall rules. 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
WANpour un serveur externe - Destination networks: objet hôte pour
192.0.2.25ou 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.
Un test de validation fiable comprend également un cas négatif. Un hôte pilote non autorisé ou un port non sélectionné ne doit pas recevoir accidentellement la même protection par l’intermédiaire d’une autre règle d’analyse trop large. Si un serveur de test spécialement préparé avec une chaîne de certificats non valide est disponible, il doit échouer tant que Allow invalid certificate est désactivé ; 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
Une stratégie POP-IMAP scan suffit-elle pour activer l'analyse ?
La valeur 0 pour la taille d'analyse signifie-t-elle illimité ?
0 est défini dans l’aide SFOS 22 comme une limite de 10,240 KB. Les messages plus volumineux ne sont pas analysés.Une connexion OpenSSL réussie prouve-t-elle l'analyse complète ?
warren.log.