Cisco Secure Email : Gateway, AsyncOS et SMA

Cisco Secure Email Gateway, abrégé SEG et historiquement nommé Email Security Appliance ou ESA, est une passerelle de messagerie SMTP. Elle termine les sessions SMTP entrantes, décide de l’acceptation, traite les messages dans une file d’attente de travail interne et ouvre une nouvelle session SMTP pour la livraison. La limite de responsabilité technique ne se situe donc pas au niveau du handshake TCP ou TLS réussi, mais à la réponse SMTP positive après le contenu du message : à partir de cet instant, la passerelle doit livrer le message ou générer une erreur conforme à la norme (Cisco: Email Pipeline, RFC 5321).

Le deuxième rôle classique est le Cisco Secure Email and Web Manager, SMA. Il ne se trouve normalement pas dans le chemin de messagerie de production comme MTA régulier. Il prend en charge les données centralisées de tracking et de reporting ainsi que, selon la conception, les quarantaines de spam, de politiques, de virus et d’épidémies de plusieurs passerelles. Une panne du SMA peut donc laisser la livraison intacte sur les nœuds SEG tout en interrompant la recherche, la quarantaine des utilisateurs finaux ou le traitement des messages retenus (Cisco: SMA Message Tracking, Cisco: Centralized Quarantines).

Les deux rôles s’exécutent sur AsyncOS, une plateforme logicielle maintenue par Cisco en tant qu’unité d’appliance. Les administrateurs ne gèrent pas les paquets sous-jacents comme sur un serveur Linux généraliste ; l’interface technique fiable se compose de la configuration AsyncOS, de la CLI, de l’interface Web, de l’API REST, des abonnements aux journaux, des MIB, des canaux de mise à jour et des intégrations documentées. Les aperçus open source de Cisco attestent de nombreux composants intégrés, mais pas d’une nomenclature publiquement maintenable du pipeline de messagerie propriétaire. Les bibliothèques individuelles ne doivent donc pas être assimilées à l’architecture globale (Cisco: Open Source Used in AsyncOS, Cisco: AsyncOS API).

L’explication accompagne un message à travers Cisco Secure Email : du listener, via HAT, RAT et la file d’attente de travail, jusqu’à la livraison. Viennent ensuite SMA, le fonctionnement en cluster, les dépendances, le diagnostic et la récupération.

Rôles des produits et limites de confiance

Une conception on-premises typique place au moins deux nœuds SEG dans la DMZ et un SMA dans un réseau de gestion interne. Les DNS MX ou un service en amont répartissent les connexions entrantes vers les passerelles ; en sortie, les connecteurs de smarthost du système de messagerie déterminent le chemin via la passerelle. Plusieurs nœuds SEG ne sont hautement disponibles que si DNS, load balancer ou MTA émetteur peuvent utiliser des cibles alternatives. Le cluster de configuration AsyncOS seul n’assure pas ce routage du trafic (Cisco: Centralized Management Using Clusters, RFC 5321, Address Resolution).

Cisco documente des appliances virtuelles, des déploiements dans le cloud public et un Secure Email Cloud Gateway exploité. Ces variantes partagent des termes de produit, mais déplacent les responsabilités : pour l’appliance virtuelle, le client est responsable de l’hyperviseur, du réseau, de la capacité et de la restauration ; pour le Cloud Gateway, Cisco fournit l’infrastructure de passerelle. Secure Email Threat Defense est quant à lui une plateforme cloud native d’analyse et de protection qui peut être intégrée par passerelle, journalisation ou API Microsoft. Ce n’est ni un synonyme de la file d’attente de travail locale ni un terme de remplacement pour le SMA (Cisco: Secure Email Data Sheet, Cisco: Email Threat Defense Data Sheet).

Réception : listener, HAT et RAT

Un listener lie SMTP à une interface IP et constitue la première limite de politique. Les listeners publics acceptent généralement le trafic Internet pour les domaines locaux ; les listeners privés reçoivent les messages sortants depuis des réseaux contrôlés. Ces rôles relèvent de la configuration et ne constituent pas une propriété de confiance intrinsèque du port. Un listener privé avec une autorisation de relais trop large est un open relay, même s’il porte un nom interne.

La Host Access Table, HAT, attribue les hôtes qui se connectent à des Sender Groups. Leurs Mail Flow Policies déterminent notamment si une connexion est acceptée, rejetée, limitée ou traitée sans certaines analyses. La Recipient Access Table, RAT, définit les domaines de destinataires locaux pour les messages entrants. En option, LDAP vérifie des destinataires précis durant la session SMTP ou ultérieurement dans la file d’attente de travail ; SMTP Call-Ahead peut également interroger le serveur en aval. Cisco distingue ainsi quatre identités qui ne doivent pas être confondues lors d’un incident : IP source, expéditeur d’enveloppe, destinataire d’enveloppe et identités des en-têtes (Cisco: Email Pipeline, Incoming).

Une documentation de listener complète contient au minimum, pour chaque direction, l’IP et le port de liaison, les réseaux sources autorisés, les noms EHLO attendus, le mode TLS, l’exigence de certificat client, l’ordre HAT, les domaines RAT, la vérification des destinataires, la taille maximale des messages, les limites de débit et le profil de bounce. L’ordre est particulièrement critique : un rejet HAT précoce ne génère pas d’enregistrement Message-ID comme un message accepté ultérieurement ; le helpdesk ne peut donc pas le trouver avec la même recherche.

Après l’acceptation SMTP commence le traitement effectif du contenu et des politiques. Son ordre est important, car un résultat précoce peut influencer les contrôles ultérieurs, les groupes de destinataires ou les chemins de livraison.

File d’attente de travail : ordre, splintering et politiques

Après son acceptation, le message entre dans la Work Queue. Cisco y documente le routage et le masquage, les Message Filters, les Safe-/Blocklists, l’anti-spam, l’antivirus, Graymail, la réputation et l’analyse des fichiers, les Content Filters, les Outbreak Filters et les quarantaines. L’ordre fait partie du modèle de sécurité. Une modification de politique ne s’applique généralement pas rétroactivement aux messages déjà stockés ; l’activation ultérieure d’un scanner ne corrige donc pas automatiquement un contournement antérieur (Cisco: Email Pipeline, Work Queue).

Les Message Filters fonctionnent avant la Mail Policy liée au destinataire et peuvent modifier, archiver, mettre en quarantaine, rejeter ou supprimer des messages selon l’enveloppe, les en-têtes, le contenu, les pièces jointes ou les données de connexion. AsyncOS peut ensuite splinter un message avec plusieurs destinataires : des Message IDs distincts et, par conséquent, différents états finaux sont créés pour les différentes politiques de destinataires. Une valeur Inject ou ICID unique d’origine peut ainsi se ramifier vers plusieurs MID et résultats de livraison. Le tracking doit afficher cet arbre, pas uniquement rechercher par objet.

Les Mail Policies contrôlent les analyses et filtres de contenu liés au destinataire ou à l’expéditeur. Selon Cisco, DLP est limité au traitement sortant. Les licences, l’état de mise à jour des moteurs et la connectivité cloud déterminent en outre quels contrôles sont réellement effectués. Pour chaque politique, un test fiable requiert un cas positif inoffensif, un cas négatif ciblé et l’état final attendu : livraison, modification, quarantaine, suppression ou bounce.

Livraison : SMTP Routes, Destination Controls et file d’attente

Dans la phase de livraison, AsyncOS sélectionne la route, l’interface source et la destination. Les SMTP Routes remplacent la résolution MX normale pour les domaines configurés ; les Destination Controls limitent les connexions parallèles et les destinataires par destination. Les Virtual Gateways peuvent fournir différentes adresses IP source, noms d’hôte et files de livraison. Ces paramètres influencent la réputation, SPF, l’allowlisting des pairs et l’emplacement où un message attend (Cisco: Email Pipeline, Delivery, RFC 7208).

Le TLS sortant est hop-by-hop. AsyncOS peut utiliser STARTTLS avec les pairs ; le succès protège ce tronçon de transport, mais ne dit rien des hops précédents ou suivants. Pour les politiques forcées, les modèles de destination, la vérification du certificat, le lien avec le nom et le comportement en cas d’erreur doivent être documentés. Le TLS opportuniste peut revenir au clair en cas d’échec du handshake ; une politique obligatoire doit au contraire mettre le message en file d’attente ou échouer (Cisco: Verify and Troubleshoot TLS Certificates, RFC 3207).

L’âge de la file d’attente est plus important que sa longueur seule. Un volume élevé peut être sain lorsque le débit est important ; quelques messages très anciens indiquent un blocage persistant de destination, DNS, TLS ou politique. Pour chaque route, l’image de l’incident doit inclure le message le plus ancien, le motif de nouvelle tentative, le prochain essai, la réponse de destination et le pair responsable.

Dès que l’ESA a transmis ou mis un message en quarantaine, une partie de la visibilité administrateur se déplace vers le SMA. Celui-ci ne remplace toutefois pas les données locales de file d’attente et de système de l’ESA.

SMA : tracking, reporting et quarantaines

Le SMA collecte des données de tracking et de reporting de plusieurs nœuds SEG. Le Message Tracking peut afficher des états finaux tels que Delivered, Dropped, Bounced, Quarantined, Queued, Processing et Splintered. Il s’agit cependant d’un index dérivé : si des données d’export manquent, qu’un service est retardé ou que le message est hors rétention, un résultat vide ne prouve pas que le message n’a jamais été traité. La preuve primaire reste les Mail Logs correspondants et la chaîne MID sur le SEG (Cisco: Tracking Messages).

La quarantaine antispam et les quarantaines de politiques, virus et épidémies sont des services distincts avec des utilisateurs, chemins de libération et rétentions différents. Les quarantaines centralisées stockent les messages sur le SMA derrière le pare-feu et peuvent être incluses dans sa sauvegarde standard. À 75, 85 et 95 % d’occupation, AsyncOS génère des alertes de seuil documentées. Lorsqu’un service de quarantaine centralisé devient inaccessible, l’exploitation doit disposer d’une décision testée à l’avance : mettre temporairement en file d’attente, modifier le traitement local ou désactiver de manière contrôlée la politique associée (Cisco: Centralized Quarantines, Cisco: Centralizing Services).

Un cluster de configuration n’est pas de la HA de messagerie

AsyncOS peut relier plusieurs passerelles dans un cluster de configuration peer-to-peer. Les paramètres peuvent être maintenus au niveau du cluster, du groupe ou de la machine ; il n’existe pas de nœud de cluster primaire. Les membres doivent utiliser une version AsyncOS compatible et communiquent par SSH ou Cluster Communication Service. Le cluster réplique la configuration, pas les sessions SMTP actives, le contenu des files d’attente, les quarantaines locales ou la progression des livraisons (Cisco: Centralized Management Using Clusters).

Il existe donc trois mécanismes distincts :

• Répartition du trafic : plusieurs cibles MX, load balancers ou basculement de smarthost ;
• Cohérence de configuration : cluster AsyncOS avec des overrides clairs au niveau cluster, groupe et machine ;
• Disponibilité des données : état de file d’attente par SEG ainsi que données de tracking et de quarantaine sur le SMA.

La perte d’un nœud après une acceptation SMTP positive peut affecter des messages présents uniquement dans sa file d’attente locale. L’expéditeur ne doit pas simplement les renvoyer tant que l’état de livraison initial n’est pas clair ; des doublons seraient sinon créés. Un test de récupération doit donc non seulement charger la configuration, mais aussi suivre des messages de test acceptés lors d’une panne contrôlée de nœud.

Pile technologique et surfaces d’administration

AsyncOS est une plateforme d’appliance fermée. Cisco publie des avis open source pour les composants fournis, mais aucun plan complet du code source ou des langages des services propriétaires. Des affirmations telles que « écrit en Python » ou « basé sur FreeBSD » ne constituent pas des informations d’exploitation fiables sans preuve du fabricant spécifique à la version. Pour les administrateurs, la pile vérifiable suivante est plus pertinente (Cisco: Open Source Used in AsyncOS) :

Les modifications CLI suivent un modèle transactionnel : les commandes modifient d’abord une configuration en cours, commit l’active, clearchanges l’annule. Un runbook doit indiquer le dialogue complet et le mode de configuration ; de simples fragments de copier-coller sont dangereux en raison des différences entre versions et clusters. L’API REST fournit un accès authentifié de manière sûre aux rapports, compteurs, données de tracking et de quarantaine ; son interface Swagger locale documente l’étendue réellement installée de l’API (Cisco: AsyncOS API, Cisco: SEG Support Documentation).

Dépendances réseau, identité et temps

Une fois le pipeline de messagerie établi, ses connexions externes peuvent être vérifiées. Chaque ligne indique quel système initie une connexion, à quoi elle sert et comment une erreur se manifeste.

Les numéros de port seuls ne prouvent aucune fonction active. Les attributions proviennent du IANA Service Name and Port Registry; Cisco documente CCS et sa configurabilité dans le chapitre consacré aux clusters. Les pare-feu doivent inclure la source, la destination, le sens, le protocole, les exigences TLS ou d’authentification et l’objectif métier.

LDAP peut alimenter l’acceptation des destinataires, le routage, l’appartenance aux groupes et l’authentification administrateur. Ces requêtes ont des schémas, timeouts et conséquences d’erreur différents. Si Recipient Acceptance échoue, le système peut, selon la configuration, générer un bounce différé ou supprimer le message ; une erreur d’authentification de la GUI ne prouve donc pas un défaut de vérification SMTP des destinataires. Les comptes de service, Base DN, filtres, comportement de referral, chaîne de certificats et ordre de basculement doivent être documentés par requête (Cisco: Email Pipeline, LDAP Recipient Acceptance, RFC 4511).

Le DNS et une heure correcte sont des dépendances système. La résolution MX et d’hôtes contrôle la livraison et l’accessibilité du cluster ; PTR et réputation influencent la classification. NTP rend les heures des journaux, Received et tracking corrélables. Cisco exige, pour les clusters, des noms d’hôte résolubles ou des adresses IP utilisées de manière cohérente et décrit l’heure système ainsi que NTP comme faisant partie de la configuration de base (Cisco: Setup and Installation).

En cas d’incident, le même chemin est suivi à l’envers : état de livraison, décision de la file d’attente de travail, politique de réception, listener et dépendances réseau.

Supervision et triage des incidents

La question centrale est : La passerelle a-t-elle accepté le message, l’a-t-elle traité et à quel hop l’a-t-elle remis ? À cette fin, les identifiants de connexion, de message et de livraison des Mail Logs sont chaînés. Le Message Tracking sur le SMA accélère la recherche, mais ne remplace pas les journaux bruts. Les signaux techniques utiles sont :

• taux d’acceptation, réponses 4xx/5xx et connexions rejetées par listener et Sender Group ;
• files d’attente de travail et de livraison, âge du message le plus ancien ainsi que réponses de destination récurrentes ;
• durée de traitement et de splintering, erreurs des moteurs d’analyse et ancienneté des mises à jour ;
• occupation des quarantaines locales et centralisées, événements de libération et de suppression ;
• valeur Resource Conservation, CPU, mémoire, occupation disque et alertes critiques ;
• disponibilité et latence de DNS, LDAP, SMA, services de mise à jour et cloud ;
• cohérence du cluster et Machine Overrides involontaires ;
• expiration et utilisation de chaque certificat TLS ainsi que modifications du truststore.

En Resource Conservation Mode, AsyncOS limite progressivement l’acceptation afin que la livraison puisse résorber le retard ; en cas de pénurie extrême de ressources, aucun nouveau message n’est accepté. Le symptôme est donc souvent une baisse du débit entrant alors que la cause réelle est une route de destination lente ou une ressource saturée. Cisco fournit l’état et les alertes dans la GUI/CLI ; SNMPv3 et ASYNCOS-MAIL-MIB permettent une supervision externe (Cisco: Resource Conservation, Cisco: SNMP Monitoring).

Sauvegarde, récupération et mise à niveau

Un fichier de configuration XML exporté est nécessaire, mais ne constitue pas une sauvegarde système complète. Cisco documente saveconfig, mailconfig et loadconfig; les phrases de passe masquées ne peuvent pas être rechargées. Les certificats et clés, l’état du cluster, les Feature Keys, les files d’attente locales, les quarantaines locales, les données SMA ainsi que les dépendances externes nécessitent leurs propres preuves (Cisco: System Administration, Cisco: Automated Configuration Backup).

Les mises à niveau sont des migrations d’appliance. Au préalable, il faut vérifier le chemin cible, les états intermédiaires compatibles, les exigences d’hyperviseur ou de cloud, les modifications de fonctionnalités, l’ordre de cluster, l’espace libre, l’indisponibilité et la limite de rollback. Les catégories de version GD et MD de Cisco ne constituent pas une recommandation automatique pour chaque environnement ; les Security Advisories, la matrice de support et l’étendue de politiques propre à l’environnement testée sont déterminantes. La page de support et les explications de cycle de vie doivent faire partie du processus de patch, et non figurer comme numéro de version statique dans l’article (Cisco: SEG Release Notes, Cisco: Software Lifecycle Support Statement).

Outils de diagnostic

La recherche d’erreur suit le chemin du message de l’extérieur vers l’intérieur. Les noms et l’accessibilité sont vérifiés d’abord, puis l’acceptation SMTP, les événements du pipeline, la file d’attente et, le cas échéant, l’évaluation SMA.

DNS, MX et résolution de destination

Resolve-DnsName -Type MX example.ch
Resolve-DnsName seg1.example.ch -Type A,AAAA
Resolve-DnsName 192.0.2.25 -Type PTR

dig +short MX example.ch
dig +short A seg1.example.ch
dig +short AAAA seg1.example.ch
dig +short -x 192.0.2.25

Resolve-DnsName et dig affichent la résolution MX, directe et inverse. La requête doit être répétée depuis la perspective des résolveurs internes et externes ; les SMTP Routes AsyncOS peuvent remplacer le résultat MX visible.

TCP et SMTP-TLS

Test-NetConnection seg1.example.ch -Port 25 -InformationLevel Detailed
curl.exe --verbose --ssl-reqd smtp://seg1.example.ch:25

nc -vz seg1.example.ch 25
openssl s_client -starttls smtp -connect seg1.example.ch:25 \
  -servername seg1.example.ch -showcerts

Test-NetConnection et nc attestent uniquement le chemin TCP. curl et openssl s_client demandent STARTTLS et affichent le handshake ainsi que la chaîne de certificats ; seule la vérification attendue du nom et de la confiance atteste la politique TLS configurée.

Message de test SMTP autorisé

curl.exe --verbose --ssl-reqd --url smtp://seg1.example.ch:25 `
  --mail-from test-sender@example.ch `
  --mail-rcpt test-recipient@example.net `
  --upload-file .\seg-test.eml

swaks --server seg1.example.ch --port 25 --tls \
  --from test-sender@example.ch --to test-recipient@example.net \
  --data seg-test.eml

curl et swaks envoient un message de test contrôlé. L’expéditeur, le destinataire et la destination doivent être autorisés. Il faut consigner la réponse SMTP finale, l’ICID/MID, les MID splinter, la politique, l’état de quarantaine ou de livraison et l’arrivée effective.

Interface Web et API REST

Invoke-WebRequest -Method Head -Uri https://sma.example.ch/
Invoke-WebRequest -Method Head -Uri https://seg1.example.ch/swagger

curl --head --verbose https://sma.example.ch/
curl --head --verbose https://seg1.example.ch/swagger

Invoke-WebRequest et curl vérifient l’accessibilité HTTP et TLS. Un code d’état ne prouve ni la connexion, ni l’autorisation de rôle, ni l’importation de tracking ou le fonctionnement de la quarantaine. La page Swagger décrit uniquement l’API de l’instance interrogée ; les tests API de production utilisent un compte minimal en lecture seule et ne stockent aucun token dans l’historique du shell.

Chemin des paquets sur un point de mesure autorisé

pktmon filter remove
pktmon filter add SEG-SMTP -p 25
pktmon start --capture --pkt-size 0 --file-name seg.etl
pktmon stop
pktmon pcapng seg.etl -o seg.pcapng

tcpdump -ni any -s 0 -w seg.pcap 'tcp port 25 or tcp port 443'

pktmon et tcpdump ne voient que le trafic au point de mesure sélectionné. Un client administrateur n’observe pas automatiquement le chemin entre le load balancer, le SEG, le SMA et le MTA de destination. Les données de paquets peuvent contenir du contenu SMTP avant STARTTLS et des métadonnées personnelles ; elles doivent être protégées en conséquence.

Histoire technique

IronPort Systems a développé des passerelles de messagerie spécialisées et la gamme de produits AsyncOS. Cisco a annoncé l’acquisition de l’entreprise en janvier 2007 et a intégré ses technologies de sécurité e-mail et Web à son propre portefeuille de sécurité (Cisco: Agreement to Acquire IronPort). Les noms de produits ont ensuite évolué de Cisco IronPort Email Security Appliance à Cisco Email Security Appliance, puis à Cisco Secure Email Gateway ; des termes historiques tels que ESA, C-Series et M-Series restent visibles dans les runbooks, les messages de journal, les licences et les chemins de documentation.

L’idée architecturale est restée reconnaissable malgré ces renommages : une passerelle spécialisée avec le pipeline à trois étapes Receipt, Work Queue et Delivery, ainsi qu’un système de gestion séparé pour les données agrégées et les quarantaines. Des appliances virtuelles et de cloud public, Cloud Gateway, des API REST et des services d’analyse basés sur le cloud ont été ajoutés ultérieurement. Email Threat Defense étend le portefeuille avec des modèles API, journalisation et passerelle ; il ne modifie pas rétroactivement les limites d’état d’une installation ESA/SMA existante (Cisco: Secure Email Data Sheet, Cisco: Email Threat Defense).

Le nom d’une appliance installée ne suffit donc pas comme information de cycle de vie. Le modèle matériel, la plateforme virtuelle, la branche AsyncOS, les licences activées, les mises à jour de moteurs et de règles ainsi que les services cloud dépendants ont leurs propres cycles de vie. Les pages de support, de versions et de fin de vie de Cisco sont des sources opérationnelles dynamiques ; un article statique devrait y renvoyer, mais ne pas figer une prétendue version durablement actuelle (Cisco: SEG End-of-Life Notices, Cisco: SEG Support).