Communications

Serveurs de transport Edge Exchange chez Microsoft 2ème partie

Kay Unkroth

Vue d'ensemble:

• Utilisation des journaux et des suivis de transport Edge
• Configuration anti-courrier indésirable avec des scripts
• Tests de scénarios de courrier indésirable typiques

Télécharger le code de cet article: Edge2007_11.exe (161KB)

Face au déluge de courrier indésirable et d'autres contenus malveillants circulant sur Internet, comment garantissez-vous une messagerie fiable et sûre aux utilisateurs de votre organisation ? L'une des méthodes, que j'ai commencé à décrire le mois dernier dans la première partie de cette série d'articles, consiste à déployer

des serveurs de transport Edge Exchange Server 2007 et Forefront Security for Exchange Server dans un réseau de périmètre entre Internet et votre environnement de production.

Dans cette deuxième et dernière partie de ma série de deux articles, j'expliquerai comment analyser les agents de transport Edge en action en utilisant les fonctionnalités de journalisation et de suivi d'agent standard d'Exchange Server 2007. J'utiliserai également une méthode personnalisée pour transférer tous les objets d'événements du pipeline de transport vers des fichiers XML. J'illustrerai ensuite la façon d'appliquer des paramètres anti-courrier indésirable à un laboratoire de test de transport Edge selon la configuration que Microsoft utilise dans son propre environnement de production d'entreprise. Pour terminer, je conclurai avec quelques scénarios de test réalistes intéressants pour voir comment les agents de transport Edge réagissent face aux diverses situations de courrier indésirable.

Pour plus d'informations sur l'installation du laboratoire de test de transport Edge et l'architecture de transport Edge générale, consultez le premier article de cette série dans le numéro d'octobre 2007 de TECHNET Magazine, disponible sur technetmagazine.com/issues/2007/10/Edge.

J'ai recours à des scripts et des fichiers de commandes de façon intensive pour automatiser les tâches de configuration les plus importantes. Vous pourrez trouver ces scripts dans le téléchargement de code qui accompagne cet article (sur technetmagazine.com/code07.aspx). Par ailleurs, pour des informations générales plus détaillées sur la configuration des agents de transport Edge de Microsoft IT, je recommande la lecture du livre blanc technique « Protection du transport Edge et de la messagerie Microsoft® Exchange Server 2007 » rédigé pour Microsoft IT Showcase. Vous pouvez télécharger ce livre blanc IT Showcase à l'adresse microsoft.com/technet/itshowcase/content/edgetransport.mspx.

Journalisation et suivi

Exchange Server 2007 inclut plusieurs fonctionnalités de suivi et de journalisation, notamment la journalisation de protocole, la journalisation d'agent et le suivi de pipeline, qui facilitent le diagnostic et le dépannage des problèmes liées aux agents de transport. Bien que je ne procède pas exactement au dépannage des agents de transport dans cet article, la journalisation et le suivi des informations sont utiles pour l'examen de la façon dont fonctionnent les agents de transport Edge.

Si vous souhaitez effectuer le suivi des informations concernant les activités d'envoi et de réception SMTP, vous devez activer la journalisation de protocole pour les connecteurs d'envoi et de réception. Dans l'environnement de test que j'ai configuré dans la première partie de cette série d'articles (voir la figure 1), j'ai activé la journalisation de protocole à l'aide du paramètre suivant sur les applets de commande New-SendConnector et New-ReceiveConnector :

Figure 1** Environnement de test **

–ProtocolLoggingLevel: Verbose

Vous trouverez les fichiers journaux SMTP par défaut dans les sous-dossiers de %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog.

La journalisation de protocole est utile si vous voulez analyser les conversations SMTP, mais les agents anti-courrier indésirable n'interfèrent pas toujours avec la session SMTP. Par exemple, l'agent de filtrage de contenu peut n'estampiller que les messages entrants avec une valeur de seuil de probabilité de courrier indésirable (SCL). Tant que la valeur SCL se situe en-deçà d'un seuil spécifié (par défaut 7), l'agent de filtrage de contenu ne provoque pas le rejet du message par le processus de transport Edge. La conversation SMTP n'est par conséquent pas affectée.

Pour analyser les actions exécutées par les agents anti-courrier indésirable (filtrage des connexions, filtrage de contenu, application de règles de transport Edge, filtrage des destinataires, filtrage des expéditeurs et identification d'expéditeur) sur les messages qui transitent par le pipeline de transport, vous devez vérifier les journaux d'agent au lieu des journaux de protocole. La journalisation d'agent est habituellement activée avec le paramètre AgentLogEnabled du fichier EdgeTransport.exe.config. Par défaut, les journaux d'agent sont situés dans le dossier %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\AgentLog. Vous pouvez ouvrir les journaux dans le Bloc-Notes, mais l'applet de commande Get-AgentLog affiche les informations de journaux d'agents de façon plus intuitive dans Exchange Management Shell.

Le suivi de pipeline est une autre fonctionnalité utile. Elle vous permet de capturer des instantanés des messages d'un expéditeur particulier lorsque que les messages transitent par le pipeline de transport. Le concept est relativement simple : le processus Transport Edge crée un instantané de chaque message avant et après avoir invoqué les agents de réception et de routage SMTP inscrits pour les événements OnEndofData, OnSubmittedMessage et OnRoutedMessage En comparant les instantanés de messages, vous pouvez voir comment chaque agent modifie chaque message. Il est bien sûr impératif que vous activiez cette précieuse fonctionnalité dans l'environnement de test.

L'utilisation suivante de l'applet de commande Set-TransportServer active le suivi de pipeline pour un utilisateur de test. Le paramètre PipelineTracingEnable défini sur $true active le suivi de pipeline, comme vous pouviez vous y attendre. L'adresse de messagerie de l'utilisateur de test est définie dans le paramètre PipelineTracingSenderAddress :

Set-TransportServer –Identity EDGE01 
–PipelineTracingEnabled $true 
-PipelineTracingSenderAddress Contoso.User@contoso.com

Lorsque le suivi de pipeline est activé, vous pouvez trouver les fichiers d'instantané de message correspondant à chaque message de l'expéditeur spécifié (dans ce cas, il s'agit de Contoso.User@contoso.com) dans le dossier %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\PipelineTracing\MessageSnapshots. Il s'agit du dossier par défaut. Pour chaque message, les fichiers d'instantanés sont situés dans un sous-répertoire dont le nom est défini par le GUID attribué au message. Notez que vous pouvez trouver le message d'origine dans un fichier portant le nom Original.eml et les copies du message dans les fichiers .eml qui commencent par SmtpReceive ou Routing, en fonction des événements rencontrés et des agents installés. Pour analyser le traitement des agents anti-courrier indésirable inscrits pour les événements de réception SMTP OnEndofData et OnEndOfHeaders, consultez les fichiers SmtpReceive*.eml. Pour analyser le traitement de l'agent antivirus et des autres agents inscrits pour les événements OnSubmittedMessage et OnRoutedMessage, utilisez plutôt les fichiers Routing*.eml.

Vidange de pipeline personnalisée

Les fonctionnalités de journalisation et de suivi d'agent standard d'Exchange Server 2007 répondent à tous les besoins de dépannage, malgré le fait que les fonctionnalités standard ne couvrent pas tous les événements de transport. Par exemple, le suivi de pipeline ne peut pas capturer les informations concernant OnConnectEvent, OnEhloCommand, OnMailCommand, OnRcptCommand, OnDataCommand et les événements de transport similaires parce que l'hôte expéditeur n'a pas encore transféré de messages pouvant être écrits dans le dossier %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\PipelineTracing. Si vous voulez capturer des informations détaillées sur ces événements, vous devez mettre en place un agent personnalisé qui vidange les données d'événement dans des fichiers du système de fichiers.

Comme je l'ai brièvement décrit dans mon article précédent, il n'est pas compliqué de créer des agents personnalisés. Je n'ai donc pas pu m'empêcher de créer un agent de réception et un agent de routage SMTP pour vidanger tous les objets d'événements du pipeline de transport dans des fichiers XML. Vous trouverez un projet Microsoft Visual Studio® 2005 correspondant, PipelineXMLDump, dans le téléchargement disponible pour cet article. Les deux fichiers importants sont DumpAgents.Cs, qui implémente les fabriques d'agent et les agents, et XMLDump.CS, qui implémente une classe d'assistance pour l'écriture des champs des objets source d'événement et argument d'événement dans les fichiers XML. Si vous compilez le code source et copiez le fichier PipelineXMLDump.dll résultant dans un dossier nommé C:\PipelineXMLDump sur le serveur de test de transport Edge, vous pouvez inscrire et activer les agents personnalisés en utilisant les scripts RegisterPipelineXMLDump.ps1 et EnableDumpAgents.ps1. Les scripts sont inclus dans le dossier de projet PipelineXMLDump du téléchargement. Bien sûr, mes agents personnalisés ont un but explicatif uniquement, n'ont pas été suffisamment testés et ne doivent jamais être installés sur un serveur de production. Vous utilisez ces agents à vos risques et périls.

DumpAgents.cs vous montre comment implémenter tous les gestionnaires d'événements de réception et de routage SMTP pris en charge par le pipeline de transport. Ceci peut constituer un bon point de départ si vous voulez implémenter vos propres agents personnalisés. Mes agents de vidange écrivent des fichiers XML dans les sous-dossiers de %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\PipelineXMLDump qui correspondent à l'identificateur de la session SMTP (agent de réception SMTP) ou à l'identificateur de message (agent de routage). La figure 2 illustre un exemple d'informations d'argument d'événement transmises à l'agent de réception SMTP dans le gestionnaire OnConnectEvent. Cet exemple révèle le point de terminaison IP local (l'adresse IP et le port) qui a accepté une demande de connexion entrante.

Figure 2** Informations d'argument vidangées pendant l'événement OnConnect **(Cliquer sur l'image pour l'agrandir)

Préparation des séries de tests

Assez de théorie sur la journalisation, le suivi et la vidange. Préparons-nous à exécuter quelques séries de tests qui montreront les agents anti-courrier indésirable en action. Vous trouverez ci-après un bref récapitulatif reflétant aussi fidèlement que possible la configuration de Microsoft IT dans votre environnement de test. Comme mentionné précédemment, des informations générales sont disponibles dans le livre blanc technique « Protection du transport Edge et de la messagerie Microsoft Exchange Server 2007 ».

Commencez par désactiver les agents de réécriture d'adresses pour les messages entrants, de filtrage de pièce jointe et de réécriture d'adresses pour les messages sortants en exécutant le script EDGE01_disable_agents.ps1 du téléchargement d'accompagnement. La réécriture d'adresses n'est pas nécessaire car les destinataires utilisent les mêmes adresses de messagerie en interne et en externe. Je n'utilise pas l'agent de filtrage de pièce jointe car des fonctionnalités de filtrage de pièce jointe plus évoluées sont disponibles dans Forefront Security.

L'environnement de test n'est pas connecté à Internet. Ceci complique les tests de l'agent de filtrage des connexions. Pour remédier à ce problème, vous pouvez créer une liste rouge d'IP sur l'hôte Internet en exécutant le fichier INTERNET01_create_IP_block_list.bat. Vérifiez que les outils de support de Windows® sont installés, car ceux-ci incluent l'outil de ligne de commande DNS (dnscmd.exe). Si ce n'est pas le cas, vous devrez passer du temps à créer manuellement les enregistrements de DNS à l'aide de la console DNS.

Vous pouvez maintenant configurer l'agent de filtrage des connexions en exécutant le script EDGE01_add_block_list_provider.ps1. Ce script ajoute un fournisseur de liste rouge d'IP pour ip-bl.consolidatedmessenger.com. Il s'agit de la liste rouge d'IP de Consolidated Messenger, créée auparavant dans l'environnement de test en exécutant le fichier INTERNET01_create_IP_block_list.bat sur l'hôte Internet, comme mentionné précédemment. Microsoft IT utilise également la liste rouge et la liste verte d'IP locales, mais ces fonctionnalités ne nécessitent pas une configuration manuelle. Il est important de noter que Microsoft IT n'utilise pas de fournisseurs de liste verte d'IP.

Maintenant, configurez l'agent de filtrage des destinataires en exécutant le script EDGE01_recipient_filter.ps1 pour bloquer les messages aux destinataires inexistants ainsi que les messages aux boîtes aux lettres et aux listes de distribution globales qui sont réservées à l'utilisation interne ou sortante uniquement.

L'agent de filtrage des expéditeurs nécessite également une mise à jour de la configuration. Microsoft IT utilise le filtrage des expéditeurs comme contre-mesure aux attaques par inondation de courrier électronique provenant d'adresses d'expéditeurs spécifiques, et pour bloquer certains serveurs de listes et des sources similaires qui ne sont pas considérées comme pertinentes pour les activités professionnelles. Microsoft IT utilise en outre le filtrage des expéditeurs pour bloquer les messages avec des informations d'expéditeur non valides ou manquantes. Appliquons cette configuration à l'environnement de test en exécutant le script EDGE01_sender_filter.ps1 sur le serveur de transport Edge.

Vous devez également configurer les enregistrements SPF (Sender Policy Framework) dans le DNS pour refléter la configuration de Microsoft IT. Pour créer un enregistrement SPF qui atteste de l'autorité de votre serveur de transport Edge pour les messages de votre domaine, adventure-works.com, vous pouvez utiliser l'Assistant d'enregistrements SPF de Microsoft Sender ID Framework à l'adresse microsoft.com/mscorp/safety/content/technologies/senderid/wizard. Essayez en indiquant un nom de domaine Internet existant. Dans l'environnement de test, vous pouvez exécuter le fichier INTERNET01_create_SPF_record.bat sur l'hôte Internet.

Et voilà. Aucun autre paramètre ne nécessite d'être configuré car la plupart des agents sont fournis avec des paramètres par défaut acceptables. Pour effectuer une vérification rapide des paramètres par défaut les plus importants pour les agents d'application de règles de transport Edge, d'identification d'expéditeur, d'analyse de protocole et de filtrage de contenu, exécutez le script EDGE01_check_defaults.ps1 sur le serveur de transport Edge.

Agents de transport Edge en action

Mettons maintenant les agents de transport Edge à l'œuvre dans quelques scénarios de messagerie réalistes. Pour envoyer des messages de test au serveur de transport Edge, j'utilise les services SMTP et POP3 inclus dans Windows Server 2003, et Outlook® Express comme client de messagerie, en utilisant la plupart du temps les paramètres par défaut. Assurez-vous toutefois que la journalisation est activée.

Mais, pour commencer, un avertissement : ne suivez aucune des étapes et n'exécutez aucun des scripts décrits dans cette section si votre environnement de test possède des connexions à un système de production ou à Internet. Vous effectuez les tests à vos risques et périls.

Le premier agent que je vais tester est l'agent de filtrage des connexions. Il mérite d'être testé en premier car il est l'agent le plus sollicité sur un serveur de transport Edge. Chez Microsoft, l'agent de filtrage des connexions bloque à peu près 88 % de tous les messages envoyés depuis Internet. Sur 13 millions d'envois tentés chaque jour ouvrable ordinaire, seuls à peu près 1,5 million proviennent d'expéditeurs légitimes.

Envoyons donc un message électronique en tant que Fabrikam.User@Fabrikam.com à Administrator@adventure-works.com. Si les choses fonctionnent correctement, l'administrateur ne doit pas recevoir le message. Au lieu de cela, Fabrikam.User doit recevoir une notification d'état de remise (DSN) déclarant que la remise au destinataire a échoué. Fabrikam.user vérifie que l'adresse de messagerie est correcte, renvoie le même message et Fabrikam.User reçoit à nouveau une DSN. Ensuite, Fabrikam.User appelle le support technique et fait état du problème. Il n'est pas le premier. En fait, personne chez Fabrikam ne peut communiquer avec Adventure Works. Il s'est passé quelque chose. Le problème est urgent. Pour tenter de le résoudre rapidement, vous vérifiez les journaux SMTP du dossier %systemroot%\system32\Logfiles\SMTPSVC1 sur INTERNET01 et, comme indiqué par le texte en rouge de la figure 3, la voilà !

Figure 3 Les journaux SMTP montrent le problème

... 220 mail.adventure-works.com Microsoft ESMTP MAIL Service ready at Thu, 
31 May 2007 12:21:33 -0700,
... EHLO, -, INTERNET01,
... 250-mail.adventure-works.com Hello [192.168.1.100],
... MAIL, -, FROM:<Fabrikam.User@fabrikam.com> SIZE=840,
... 250 2.1.0 Sender OK,
... RCPT, -, TO:<Administrator@adventure-works.com>,
... 550 5.7.1 E-mail rejected because your IP address is listed by 
ip-bl.consolidatedmessenger.com. Please visit 
http://www.consolidatedmessenger.com/ip-bl for more information. 
If you still need assistance, contact cmipbl@adventure-works.com.,
... RSET, -, -,
... 250 2.0.0 Resetting,
... QUIT, -, -,
... 221 2.0.0 Service closing transmission channel,

La réponse d'erreur 550 vous indique que Consolidated Messenger a placé l'adresse IP de l'hôte Internet sur une liste rouge d'IP. Soit. Vous contactez Consolidated Messenger pour être supprimé de cette liste. Il se trouve qu'il est plus facile de figurer sur la liste rouge de Consolidated Messenger que d'en être supprimé. La résolution de ce problème nécessitera plusieurs jours, voire plusieurs semaines.

Vous avez besoin d'aide plus rapidement, et vous contactez donc Adventure Works à l'adresse de messagerie cmipbl@adventure-works.com. Vous envoyez un message électronique en tant que Fabrikam.Admin@Fabrikam.com, en décrivant la situation et en demandant le déblocage de l'adresse IP de votre hôte Internet (dans ce cas 192.168.1.100). Après avoir vérifié votre identité, Adventure Works débloque l'adresse en utilisant la commande suivante pour accorder une exception temporaire qui expire automatiquement après 30 jours :

Add-IPAllowListEntry -IPAddress 192.168.1.100 
-ExpirationTime (get-date).AddDays(30)

Trente jours devraient vous donner suffisamment de temps pour résoudre le problème auprès de Consolidated Messenger, si bien qu'Adventure Works ne doit pas passer du temps à maintenir l'exception manuellement. En accordant des exceptions à expiration automatique, Adventure Works maintient la charge administrative associée à la maintenance des listes vertes d'IP à un minimum.

Expéditeurs fiables

Maintenant, testons la détection d'expéditeurs fiables du filtrage de contenu, une nouvelle fonctionnalité très intéressante qui augmente la précision du filtrage de courrier indésirable. EdgeSync propage les informations d'expéditeurs fiables aux serveurs de transport Edge sous une forme chiffrée et hachée à partir de l'environnement interne. L'agent de filtrage de contenu utilise ces informations pendant le processus de filtrage pour prendre des décisions pertinentes. Il vous suffit d'entrer les informations d'expéditeur fiable (c'est-à-dire, la liste des expéditeurs fiables, la liste des destinataires fiables, la liste rouge d'expéditeurs et les contacts externes) dans Active Directory® en utilisant l'applet de commande Update-SafeList et en répliquant ensuite les informations sur le serveur de transport Edge à l'aide de l'applet de commande Start-EdgeSynchronization. Microsoft IT exécute l'applet de commande Update-SafeList suivant un calendrier établi, en dehors des heures de pointe. Dans notre environnement de test, il suffit d'exécuter manuellement un script correspondant (HUB-MBX-01_update_safelist.ps1).

Pour commencer, nettoyez l'environnement de test en exécutant le script EDGE01_clean_up.ps1 sur le serveur de transport Edge pour supprimer l'entrée de liste verte d'IP précédemment créée. Ceci est nécessaire car l'agent de filtrage de contenu n'a aucun effet sur les messages des sources qui figurent sur cette liste. Ensuite, supprimez l'entrée de liste rouge d'IP pour 100.1.168.192.ip-bl.consolidatedmessenger.com dans la liste rouge de Consolidated Messenger en exécutant le fichier INTERNET01_clean_up.bat sur l'hôte Internet. Á défaut, l'hôte Internet simulé ne pourra pas envoyer de messages, comme démontré précédemment.

Enfin, envoyez un message que l'agent de filtrage de contenu considèrera certainement comme étant du courrier indésirable. C'est difficile car l'agent de filtrage de contenu utilisera le seuil de rejet de SCL par défaut pour remettre la plupart des messages aux utilisateurs afin de réduire le nombre de faux positifs. Pourtant, après quelques essais, j'ai trouvé une version de message qui élève le contrôle d'accès SCL jusqu'au niveau de rejet. Pour envoyer le message en tant que Contoso.User@Contoso.com, exécutez le script INTERNET01_contoso_msg.vbs sur l'hôte Internet.

Mon script utilise une connexion SMTP anonyme pour soumettre le message au service SMTP sur INTERNET01. Pour qu'il fonctionne, vous devez configurer le service SMTP de sorte qu'il relaie les messages des utilisateurs anonymes. Dans le Gestionnaire IIS, ouvrez les propriétés du serveur virtuel SMTP par défaut. Sur l'onglet Accès, cliquez sur le bouton Relais et sélectionnez ensuite Tout sauf la liste ci-dessous. Je couvrirai dans un instant les implications de cette configuration.

Lorsque vous exécutez le script pour envoyer ce message, Contoso.User doit recevoir un DSN indiquant que cette remise a échoué avec : Code de diagnostic : smtp;550 5.7.1 Message rejeté en raison de restrictions de contenu. Vous pouvez également voir cette réponse dans le journal SMTP de l'hôte Internet et, si vous exécutez la commande Get-AgentLog | Select-Object -Last 1 sur le serveur de transport Edge pour afficher la dernière entrée du journal de l'agent, vous devriez pouvoir voir que le message a été rejeté car son contrôle d'accès SCL était 7, comme illustré à la figure 4.

Figure 4** Le message a été bloqué en raison de restrictions de contenu **(Cliquer sur l'image pour l'agrandir)

Contoso.User n'est cependant pas un expéditeur de courrier indésirable. Il est malheureux que son message n'ait pas pu aboutir dans ce cas-ci, mais Contoso.User peut habituellement communiquer avec les destinataires d'Adventure Works. Contoso.User informe donc l'administrateur dans un autre message électronique que son message d'origine a été bloqué par erreur. L'administrateur connaît Contoso.User et, pour s'assurer que les filtres de courrier indésirable ne bloquent plus ses messages à l'avenir, l'administrateur ajoute Contoso.User à la liste des expéditeurs fiables. Pour effectuer cette opération dans Office Outlook 2007, cliquez avec le bouton droit sur un message reçu de Contoso.User, pointez sur Courrier indésirable et cliquez sur Ajouter l'expéditeur à la liste des expéditeurs approuvés.

À intervalles réguliers, l'applet de commande Update-SafeList s'exécute pour actualiser les informations de liste d'utilisateurs fiables dans Active Directory et après la synchronisation Edge suivante, Contoso.User pourra communiquer avec l'administrateur sans générer de faux positifs. Pour simuler cette procédure, exécutez le script HUB-MBX-01_update_safelist.ps1.

Exécutez maintenant le script INTERNET01_contoso_msg.vbs pour renvoyer le message Contoso.User. Vérifiez ensuite le journal de l'agent sur le serveur de transport Edge en utilisant la commande Get-AgentLog | Select-Object -Last 1 et vous pourrez voir sous ReasonData que le filtre de contenu a maintenant été contourné. Contoso.User. ne génère plus de faux positifs !

Attaque de courrier indésirable

Pour conclure les séries de tests, allons plus loin. Comme vous l'avez sans aucun doute remarqué, durant le test précédent, j'ai configuré l'hôte Internet en tant que relais ouvert, ce qui ouvre la porte aux expéditeurs de courrier indésirable. Voyons donc maintenant ce qui se passe si Spam.Sender@cohovineyards.com remarque cette configuration vulnérable et exploite l'hôte pour envoyer des milliers de messages indésirables à Adventure Works. Le script INTERNET01_spam_msg.vbs n'envoie qu'un seul message indésirable, mais vous pouvez modifier le script et modifier la valeur de max_loop pour en produire davantage.

Pour simuler une attaque de courrier indésirable, j'ai envoyé 1 000 messages à mon hôte compromis devant être relayés au serveur de transport Edge. Le service SMTP limite le nombre de messages par connexion sortante à 20 et il a donc fallu un certain temps pour relayer un nombre de messages indésirables suffisant pour que l'agent d'analyse de protocole réagisse.

L'agent d'analyse de protocole aide l'agent de filtrage des connexions en assurant automatiquement la gestion des entrées de liste rouge d'IP en fonction de l'analyse de protocole SMTP et des mises à jour de réputation d'IP de Microsoft Update. En l'occurrence, l'analyse de protocole SMTP a détecté les messages électroniques indésirables. L'agent d'analyse de protocole prend note de la note SCL de chaque message pour calculer une valeur SCL moyenne qu'il utilise pour déterminer un niveau de réputation d'expéditeur (SRL). Comme une multitude de messages illégitimes sont arrivés pendant ma campagne de courrier indésirable simulée, le SRL de l'hôte Internet a augmenté jusqu'à dépasser le seuil de blocage SRL. Par conséquent, l'hôte s'est retrouvé pendant 24 heures sur la liste rouge d'IP. Plus de courrier indésirable de cet hôte ! Ceci s'est produit automatiquement. Aucune intervention de l'administrateur n'a été nécessaire.

La figure 5 illustre l'entrée de liste rouge d'IP résultante et les modifications correspondantes dans la gestion des messages. Avant le blocage de l'hôte, le serveur de transport Edge rejetait chaque message indésirable pendant l'événement OnEndOfData car l'agent de filtrage de contenu agissait pour chaque message en fonction du seuil SCL (pour référence, voir la figure 4). Le message était soumis, bien qu'en vain. Après le blocage de mon hôte, la connexion a été rejetée pendant l'événement OnMailCommand par l'agent de filtrage des connexions. Les messages ne sont plus soumis. Ceci permet d'économiser la bande passante du réseau et les ressources de traitement pour déconnecter les expéditeurs de courrier indésirable avant la soumission de messages.

Figure 5** Arrêt d'un hôte Internet nuisible **(Cliquer sur l'image pour l'agrandir)

Autres tests

Il existe bien sûr de nombreux autres scénarios et fonctionnalités d'agent pouvant être testés. Par exemple, vous pouvez tester le filtrage des expéditeurs en envoyant des messages en tant que Blocked.User@Contoso.com ou Blocked.User@Fabrikam.com. Vous pouvez tester le filtrage des destinataires en envoyant des messages à Blocked.User@adventure-works.com. Vous pouvez également utiliser Telnet pour simuler des attaques DHA (directory harvesting) avec différents intervalles de délai de connexions entrantes. Microsoft IT utilise l'intervalle par défaut de cinq secondes pour les réponses SMTP 5yz sur le connecteur de réception exposé à Internet, ce qui constitue une durée suffisante pour que Microsoft IT rende les attaques DHA peu commodes pour les expéditeurs de courrier indésirable. Mais vous pouvez appliquer des valeurs différentes avec l'applet de commande Set-ReceiveConnector, comme démontré dans le script EDGE01_tarpitting.ps1.

Vous pouvez également aller plus loin en examinant les fichiers d'instantanés créés par le suivi de pipeline pour les messages de Contoso.User@Contoso.com. Examinez les tampons antivirus, X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0, utilisé par Forefront Security pour marquer les messages comme vérifiés. Lorsque Forefront Security, situé sur le serveur de transport Hub, trouve ce tampon avec des informations de version récente, il ne doit pas vérifier le message une deuxième fois. Si vous essayez de tromper Forefront Security en insérant des tampons d'antivirus falsifiés dans vos messages de test, vous pouvez voir le pare-feu d'en-tête en action. Il supprime ces tampons juste après l'événement OnDataCommand, longtemps avant que l'événement OnSubmittedMessage soit déclenché pour invoquer l'agent de routage FSE.

Pendant que vous examinez les en-têtes de messages dans les fichiers d'instantanés, vous voudrez peut-être créer un enregistrement de test SPF pour Contoso.com qui identifie une mauvaise adresse IP comme un expéditeur légitime. L'une des façons d'y parvenir consiste à exécuter le fichier INTERNET01_wrong_SPF_record.bat sur l'hôte Internet. Vous devez ensuite envoyer un message de test en tant que Contoso.User@Contoso.com et examiner X-MS-Exchange-Organization-SenderIdResult et l'en-tête Received-SPF :

X-MS-Exchange-Organization-SenderIdResult: SoftFail
Received-SPF: SoftFail (EDGE01.extranet.adventure-works.com: domain of transitioning
Contoso.User@Contoso.com discourages use of 192.168.1.100 as permitted sender)

Conclusion

Comme vous l'avez vu dans cet article et dans mon article précédent, les serveurs de transport Exchange sont fournis avec un jeu d'agents de transport complet pour l'implémentation de fonctionnalités anti-courrier indésirable de pointe fiables, notamment le filtrage des connexions, l'analyse de protocole et le filtrage de contenu. L'architecture de transport est extensible et prend en charge l'implémentation d'autres agents pour la prise en charge de fonctionnalités supplémentaires. L'agent de routage FSE est un bon exemple d'agent supplémentaire intégrant Forefront Security for Exchange Server dans l'architecture de transport.

Associé à des fonctionnalités supplémentaires, telles que le délai de connexion, le pare-feu d'en-tête, la sécurité de couche de transport et l'authentification, les serveurs de transport Edge fournissent les moyens nécessaires pour atteindre un niveau très élevé de protection de messagerie à plusieurs niveaux, sans point de défaillance unique. En déployant des serveurs de transport Edge et Forefront Security dans un réseau de périmètre, strictement séparé de votre organisation Exchange Server interne, vous pouvez maintenir le flux des contenus illégitimes et malveillants à l'écart de votre environnement de messagerie tout en remettant les messages légitimes à vos utilisateurs avec un faible taux de faux positifs.

Kay Unkroth est un entrepreneur qui a travaillé comme ingénieur de support technique, développeur système, consultant, formateur et auteur spécialiste des technologies de serveur Microsoft pendant plus de 15 années. Kay est également cofondateur et président de Biblioso Corporation, une entreprise spécialisée dans la documentation gérée et les services de localisation.

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.