Communications

Serveurs de transport Edge Exchange chez Microsoft

Kay Unkroth

Vue d'ensemble:

• Rôle de serveur de transport Edge Exchange
• Configuration d'un laboratoire de test
• Agents et événements de transport
• Agents vu de l'intérieur

Télécharger le code de cet article: ExchangeEdge2007_10.exe (354KB)

Durant une journée ouvrée normale, Microsoft reçoit environ 13 millions de tentatives de soumission de message depuis Internet et bloque plus de 10,5 millions de ces messages, à caractère non légitime. Dans les situations

critiques, telles que les attaques de courrier indésirable ou les attaques de virus sur Internet, le volume peut augmenter jusqu'à plus de 90 millions. Ceci s'applique bien sûr exclusivement à Microsoft, mais les escroqueries, le hameçonnage, les virus véhiculés par courrier électronique, les attaques DHA (Directory Harvest Attack), les attaques par déni de service distribué (DDoS) et autres soucis similaires ne sont pas spécifiques à Microsoft. Face à de tels problèmes, comment assurer la remise de tous les messages légitimes aux utilisateurs tout en maintenant le flot de contenu malveillant et illégitime à l'écart de l'environnement de messagerie ?

L'une des méthodes permettant d'y parvenir consiste à mettre en place une protection de messagerie fiable en déployant 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. Cette approche place une équipe organisée de plus de 10 agents de transport Edge sur votre périmètre pour vous aider à protéger les systèmes de production et les utilisateurs. L'avantage que constitue le blocage du contenu indésirable au point le plus extérieur possible est évident. Dans l'idéal, ceci doit se produire avant que le contenu soit remis à vos serveurs, compte tenu de la charge que votre environnement de messagerie pourrait autrement avoir à supporter dans une situation critique. Pourtant, la protection de la messagerie est loin de se limiter au blocage des messages.

Cet article est la première partie d'une série de 2 articles au cours desquels nous discuterons de l'architecture et des fonctionnalités essentielles des agents anti-courrier indésirable et antivirus disponibles dans Exchange Server 2007 et Forefront Security for Exchange Server. Pour que les explications demeurent réalistes et pratiques, je vous montrerai d'abord dans ce premier article comment mettre en place un laboratoire de test qui reflète la conception de protection de la messagerie utilisée par Microsoft dans son propre environnement de production d'entreprise. Je couvrirai ensuite plus en détail l'architecture de transport Edge d'Exchange Server 2007.

Au cours de cet article, j'aurai souvent recours à des scripts et des fichiers de commandes pour automatiser les tâches de configuration les plus importantes. Ces fichiers incluent des commentaires qui expliquent les étapes individuelles entreprises. Vous trouverez ces scripts dans le téléchargement disponible sur le site Web de TechNet Magazine à l'adresse technetmagazine.com/code07.aspx.

Topologie de transport Edge

La figure 1 illustre la conception de transport Edge implémentée par l'équipe Microsoft IT dans l'environnement de production d'entreprise. Avant de vous faire découvrir l'architecture de transport Edge, je souhaiterais mettre l'accent sur certaines fonctionnalités de conception très intéressantes. Si les détails de mise en œuvre complets vous intéressent, consultez le livre blanc IT Showcase auquel il est fait référence dans l'encadré Ressources Exchange.

Figure 1** Topologie de transport Edge chez Microsoft **(Cliquer sur l'image pour l'agrandir)

En analysant la figure 1, vous remarquerez que la topologie de transport Edge de Microsoft est entièrement redondante. Il n'existe aucun point de défaillance, à quelque endroit que ce soit. Pour l'équilibrage de la charge, Microsoft IT utilise un tourniquet (round robin) DNS en externe et des connecteurs de messagerie avec plusieurs têtes de pont en interne. Il est également à noter que tous les serveurs de transport (transport Hub et transport Edge) exécutent Forefront Security for Exchange Server pour l'analyse antivirus. Ceci permet à Microsoft IT d'analyser tous les messages entrants, sortants et internes dès qu'ils atteignent un serveur de transport de la topologie de routage de message.

Une autre caractéristique de conception importante de la sécurité est que les serveurs de transport Edge ne font pas partie de l'environnement Active Directory® d'entreprise. Il n'est en fait pas nécessaire de déployer les serveurs de transport Edge dans une forêt Active Directory. Cependant, pour conserver une infrastructure de gestion cohérente, appliquer un ensemble commun de stratégies et prendre en charge l'authentification unique, Microsoft IT déploie tous les serveurs de transport Edge dans une forêt extranet, séparée de l'environnement de production.

Enfin, vous pouvez voir clairement que tous les messages provenant d'Internet atteignent Microsoft via des serveurs de transport Edge situés en Amérique du Nord. Les serveurs de transport Edge basés à Dublin et à Singapour gèrent uniquement les messages sortants. La concentration de tout le trafic entrant sur les serveurs de transport Edge d'Amérique du Nord permet de centraliser la sécurité et les contrôles anti-courrier indésirable, tout en évitant le transfert de messages sortants depuis de grands centres de données régionaux sur la dorsale principale de messagerie interne.

Omesh Desai, ingénieur système de Microsoft IT, a conçu la topologie de transport Edge de Microsoft. Lorsque j'ai demandé à Omesh quelles étaient les caractéristiques de conception les plus importantes, sa réponse a été « Dans notre conception de transport Edge, nous tirons parti des fonctionnalités anti-courrier indésirable et antivirus natives d'Exchange pour la protection de la messagerie sur plusieurs couches de la dorsale principale de messagerie. La sécurité du périmètre de messagerie est la première priorité, mais un modèle d'administration et de gestion simple est également important pour nous. Les serveurs de transport Edge nous aident à accroître la sécurité grâce à des configurations de pare-feu plus strictes, tout en améliorant la précision du filtrage de courrier indésirable via des services de réputation d'IP, des mises à jour automatiques de filtre de contenu, l'agrégation de listes fiables et la validation de l'oblitération de courrier électronique. Toute communication interne de serveur à serveur est par défaut chiffrée et nous chiffrons également, si possible, la communication avec les destinations externes.

« Nos serveurs de transport Edge sont chacun équipés de processeurs 64 bits double cœur et de huit gigaoctets de mémoire. Avec six de ces serveurs, où la charge est équilibrée sur deux centres de données, nous disposons de capacités suffisantes pour prendre également en charge les pics de soumission de messages importants, qui surviennent par exemple pendant les attaques de virus sur Internet ».

Laboratoire de test du transport Edge

Configuration du laboratoire de test

Comme il est recommandé d'utiliser des noms de domaine inexistants et des adresses IP privées, j'utilise AdventureWorks.com et des adresses IP de plage 192.168.xxx.0 à 24. Il n'y a pas de systèmes redondants ou de groupes de pare-feu parce que je ne teste pas l'équilibrage de la charge ou la tolérance de panne. (En outre, il est évident que, pour des raisons de sécurité, nous ne discuterons pas ici des véritables systèmes de pare-feu que Microsoft IT utilise). De tels détails ne sont de toute façon pas importants pour cet environnement de test.

Mon environnement de test utilise Isa Server 2006 car il s'agit probablement de l'un des systèmes de pare-feu les plus couramment utilisés avec Exchange Server 2007. L'exécution d'Isa Server 2006 sur les pare-feu extérieur comme intérieur contribue à maintenir la complexité de l'environnement de test à un niveau modéré. Dans les environnements de production, je recommande toutefois l'utilisation de systèmes de pare-feu extérieur et intérieur différents pour accroître la sécurité. Je n'ai pas déployé de stratégies de sécurité d'IP (IPsec), ni préparé l'environnement pour l'utilisation du protocole TLS (Transport Layer Security) car ces sujets dépassent l'étendue de cet article.

Cependant, j'ai utilisé des machines virtuelles et un logiciel d'évaluation 32 bits, que vous pouvez télécharger à partir du site Web de Microsoft. Microsoft ne prend pas en charge la version 32 bits d'Exchange Server 2007 en production, mais cela ne constitue pas un problème dans un environnement de test.

Mon laboratoire de test s'appuie dans la mesure du possible sur les paramètres par défaut. Seuls la configuration IP, les pare-feu et les zones DNS nécessitent une attention particulière avant exécuter l'installation d'Exchange Server 2007 et d'abonner le serveur de transport Edge à l'environnement de production. Pour les détails concernant la configuration IP, consultez le fichier Test Lab—IP Configuration.xls que vous trouverez dans le téléchargement associé. Si vous utilisez les mêmes attributions d'adresses IP, vous pouvez configurer rapidement le pare-feu extérieur, nommé ISA01, en exécutant le script ISA01_Firewall_Policies.vbs directement sur l'ordinateur ISA01, et utiliser ISA02_Firewall_Policies.vbs pour le pare-feu intérieur (ISA02). Le téléchargement associé inclut également des fichiers de commandes permettant de configurer les serveurs DNS (INTERNET01_DNS_Config.bat, AD01_DNS_Config.bat et AD02_DNS_Config.bat). Comme ces fichiers de commandes utilisent l'outil de ligne de commande DNS (dnscmd.exe), les outils de support de Windows doivent être installés. Si ce n'est pas le cas, vous devrez créer les enregistrements DNS manuellement à l'aide de la console DNS.

Pour éviter toute interférence provenant d'environnements existants, mon laboratoire de test n'est pas connecté à Internet. Cette isolation est une bonne précaution. Elle provoque l'échec des téléchargements de mises à jour de signatures, de réputations d'IP et de mises à jour de filtres de contenu, mais ce n'est pas critique pour le test. Pour éviter les messages d'erreur, accédez à Mises à jour de l’analyseur dans la console de l'Administrateur de sécurité de Forefront Server, définissez ensuite la fréquence de mise à jour de tous les moteurs d'analyse sur une seule fois et spécifiez une date passée.

Pour explorer ces fonctionnalités en action, il est recommandé de mettre en place un environnement de test, le bon sens suggérant de ne jamais utiliser un système de production à des fins de test. Cet environnement nécessite au minimum un serveur exécutant Exchange Server 2007 pour les rôles de Boîte aux lettres, Accès au client et Transport Hub. Vous aurez besoin d'un second serveur Exchange pour le rôle de serveur de Transport Edge. Vous pourriez ignorer l'installation du serveur de transport Edge si vous déployez tous les agents de transport sur le serveur multirôle en exécutant le script Install-AntispamAgents.ps1 (vous le trouverez sur les serveurs de transport Hub dans le dossier %ProgramFiles%\Microsoft\Exchange Server\Scripts). Toutefois, cette approche ne ressemblerait que de très loin au déploiement de Microsoft IT. Pour un laboratoire de test réaliste, vous devrez inclure quelques serveurs supplémentaires. La figure 2 illustre l'environnement de test que j'ai utilisé pour préparer cet article. Une illustration plus détaillée est disponible dans le téléchargement associé. Pour plus d'informations sur la configuration du laboratoire, consultez l'encadré « Configuration du laboratoire de test ».

Figure 2** Environnement de test du transport Edge **(Cliquer sur l'image pour l'agrandir)

Pendant l'abonnement du serveur de transport Edge et la configuration des connecteurs associés, Microsoft IT supprime tous les connecteurs par défaut et crée ensuite quatre connecteurs d'envoi pour communiquer efficacement avec les différents types d'hôtes SMTP (Simple Mail Transfer Protocol) et de serveurs de transport Hub internes. Le premier connecteur d'envoi est un connecteur Internet général pour toutes les destinations qui ne correspondent pas à des définitions d'espace d'adressage spécifiques.

Le second connecteur d'envoi est un connecteur Internet avec des définitions d'espace d'adressage détaillées pour les destinations connues qui ne prennent pas en charge le protocole Extended SMTP (domaines HELO). En définissant le paramètre ForceHELO pour ce connecteur sur $true, Microsoft IT évite une séquence inutile de EHLO, « Failure Response 500, HELO » lors de l'établissement des connexions SMTP.

Le troisième connecteur d'envoi est un connecteur Internet avec des définitions d'espace d'adressage détaillées pour les partenaires et autres domaines distants prenant en charge TLS pour la communication sécurisée sur les connexions chiffrées (domaines TLS). Le paramètre RequireTLS de ce connecteur est défini sur $true.

Le quatrième connecteur d'envoi est un connecteur entrant pour le transfert des messages Internet reçus vers les serveurs de transport Hub de l'environnement d'entreprise. Ici encore, pour plus de détails concernant la configuration du serveur de transport Edge, consultez le livre blanc IT Showcase auquel il est fait référence dans l'encadré « Ressources Exchange » à la fin de cet article.

Pour appliquer au laboratoire de test une topologie de connecteur du style de celle de Microsoft IT, je me suis appuyé sur une procédure basée sur les scripts qu'Omesh a créés en interne pour Microsoft. Pour des raisons de sécurité, j'ai modifié et ai raccourci radicalement chaque commande, mais la topologie de connecteur résultante correspond toujours à celle de Microsoft IT. En voici les étapes :

1. Sur le serveur Exchange multirôle (HUB-MBX-01) et le serveur de transport Edge (EDGE01), supprimez les connecteurs par défaut.
2. Sur HUB-MBX-01, créez un nouveau connecteur de réception en exécutant le script HUB-MBX-01_recv_connector.ps1 que vous trouverez dans le téléchargement associé à cet article.
3. Sur EDGE01, créez deux nouveaux connecteurs de réception pour la connectivité de messagerie interne et externe en exécutant le script EDGE01_recv_connector.ps1.
4. Sur EDGE01, créez un fichier d'abonnement en exécutant cette commande :

    New-EdgeSubscription -FileName 
    "c:\subscriptionfile.xml" 

Copiez le fichier d'abonnement résultant dans le dossier racine du serveur de transport Hub (c:\subscriptionfile.xml).

5. Sur HUB-MBX-01, assurez-vous que le chemin vers le fichier d'abonnement est c:\subscriptionfile.xml et exécutez ensuite le script HUB-MBX-01_complete_subscription.ps1. Ce script importe le fichier d'abonnement pour la synchronisation Edge sans création automatique de connecteur d'envoi, crée les connecteurs d'envoi pour la connectivité Internet et interne, et copie la configuration résultante sur le serveur de transport Edge à l'aide de la synchronisation Edge.

6. Vérifiez la configuration en envoyant à Administrator@adventureworks.com des messages de test en tant que Contoso.User@contoso.com et Fabrikam.User@fabrikam.com depuis l'hôte Internet, et en répondant aux messages reçus pour vous assurer que le transfert de messages entrants et sortants fonctionne.

Je vous suggère d'ouvrir les fichiers de script individuels dans le Bloc-notes et d'analyser les applets de commande et les paramètres que ces scripts utilisent pour effectuer la configuration. Des informations détaillées sur ces applets de commande et ces paramètres sont disponibles en ligne dans la documentation produit d'Exchange Server 2007.

Architecture de transport Edge

Abordons maintenant les agents de transport Edge, qui attendent que quelqu'un leur envoie un HELO ou EHLO depuis que j'ai installé le rôle de serveur de transport Edge. Si vous exécutez la cmdlet Get-TransportAgent sur le serveur de transport Edge, vous devriez voir les 11 entrées répertoriées à la figure 3. Tous les agents sont activés par défaut pour fournir la protection de messagerie avec des paramètres appropriés.

Figure 3 Agents de transport

L'applet de commande Get-TransportAgent et la figure 3 répertorient les agents dans l'ordre de leur priorité, même s'il ne s'agit pas de l'ordre dans lequel les agents effectuent leur travail. L'ordre de travail dépend principalement de la séquence des événements de réception et de routage SMTP pour lesquels les agents sont inscrits. Pour voir la correspondance entre agents et événements, observez le diagramme présenté à la figure 4, qui illustre la façon dont les agents de transport s'intègrent dans l'architecture de transport Edge.

Figure 4** Agents de transport dans l'architecture de transport Edge **(Cliquer sur l'image pour l'agrandir)

Les événements de transport surviennent à diverses étapes du traitement de message pour invoquer du code supplémentaire pour le filtrage du courrier indésirable, l'analyse antivirus et d'autres tâches. Dans cette conception extensible à couplage souple, le processus de transport Edge (EdgeTransport.exe) joue le rôle de source d'événement. Les gestionnaires d'événements, en d'autres termes les agents de transport, sont des objets gérés délégués basés sur Microsoft® .NET Framework 2.0, inscrits auprès de la source d'événement pour la réception de notifications de rappel.

La figure 5 illustre les inscriptions d'événement pour tous les agents installés sur un serveur de transport Edge avec Forefront Security. Ces inscriptions sont peut-être un peu difficiles à déchiffrer en raison du grand nombre d'inscriptions d'agent, mais ne désespérez pas. Si vous exécutez la commande Get-TransportPipeline | Format-List sur un serveur de transport Edge, vous pouvez analyser plus commodément les inscriptions pour chaque événement de transport individuel. Assurez-vous seulement que le service Transport Microsoft Exchange (MSExchangeTransport.exe) s'exécute et que vous avez envoyé au moins un message via le serveur de transport Edge depuis le dernier redémarrage du service. Comme le révèle le résultat, plusieurs agents peuvent s'inscrire pour le même type d'événement et chaque agent peut s'inscrire pour plusieurs événements. Les inscriptions d'événement dépendent seulement des exigences de traitement de l'agent correspondant.

Figure 5** Inscriptions d'événement pour les agents de transport **(Cliquer sur l'image pour l'agrandir)

L'un des événements les plus importants est l'événement de routage OnSubmittedMessage, déclenché lorsqu'un message atteint la file d'attente de soumission. Tous les messages doivent passer par cette file d'attente, qu'ils entrent par le SMTP, le système de fichiers ou tout autre mécanisme. Le catégoriseur est un composant fondamental de l'architecture de transport d'Exchange Server, responsable de la résolution des destinataires, de la bifurcation et du routage des messages et de la génération de notification d'état de remise (DSN). L'événement OnSubmittedMessage est donc un choix d'inscription parfait pour les agents qui doivent traiter tous les messages reçus. L'Agent de routage FSE est un composant de Forefront Security inscrit pour l'événement OnSubmittedMessage afin de transmettre tous les messages reçus aux moteurs d'analyse antivirus. Comme l'agent de routage FSE est inscrit pour l'événement OnSubmittedMessage, aucun message ne peut contourner la solution d'antivirus.

Pourquoi tous les agents ne s'inscrivent-ils pas simplement pour l'événement OnSubmittedMessage et considèrent que le travail est terminé ? Parce que vous souhaitez bloquer les messages indésirables au point le plus extérieur possible, avant que votre serveur confirme une livraison réussie. Dans le cas contraire, vos serveurs pourraient avoir à traiter 90 millions de messages indésirables pendant une attaque de courrier indésirable ou de virus, en ayant probablement à générer 90 millions de rapports de non-remise (NDR), qui à leur tour pourraient poser une menace sérieuse pour les passants innocents. Les attaques de courrier indésirable et de virus utilisent presque toujours des informations de créateur falsifiées. L'envoi de millions de rapports de non-remise aux destinataires qui n'ont pas créé les messages d'origine est non seulement un gaspillage de vos ressources et des ressources des organisations cibles, mais également une opportunité pour les utilisateurs malveillants de lancer des attaques par inondation de courrier électronique et par déni de service distribué. Il est important d'arrêter les expéditeurs malveillants dans leur lancée, pour votre propre protection et la protection des autres.

Pour bloquer un message efficacement, un agent de transport doit interrompre la conversation SMTP avec l'hôte distant avant que votre serveur confirme la réception des données avec un code d'état 250 OK. Conformément au principe SMTP stocker et transférer, votre serveur peut rejeter en toute sécurité toutes les données reçues sans générer de rapport de non-remise si la remise des messages n'a pas été confirmée. Les agents de réception SMTP peuvent accomplir ceci. Ils interagissent avec la session SMTP parce que le pipeline de transport invoque ces agents en fonction des événements de réception SMTP lorsque l'hôte à distance se connecte au serveur, établit une session SMTP, transmet des verbes SMTP, soumet des messages et met fin à la connexion. (Les événements de réception SMTP liés à chaque étape sont répertoriés à la figure 6.) En raison de la capacité de rejeter des messages avant la remise et de déconnecter des hôtes SMTP distants, tous les agents anti-courrier indésirable Exchange Server 2007 sont implémentés en tant qu'agents de réception SMTP.

Figure 6 Événements de session SMTP

Il est important de reconnaître la différence entre agents de routage et agents de réception SMTP en ce qui concerne leur contexte de traitement. Les agents de routage ont un accès complet aux propriétés de message, les agents de réception SMTP sont plus sensibles au contexte parce que ces agents interagissent avec la session SMTP. Par exemple, il n'est pas possible pour un filtre de courrier indésirable d'agir en fonction des propriétés du message avant que l'hôte à distance ait en fait transféré le message. Il est par conséquent important d'inscrire l'agent pour l'événement de réception SMTP correct. Consultez l'encadré « Développement d'agent de transport » pour un aperçu plus complet.

Ressources Exchange

• Transport Edge et protection de la messagerie Microsoft Exchange Server 2007 (Livre blanc technique Microsoft IT Showcase)
• Centre de scripts Windows PowerShell
• TechCenter Exchange Server 2007
• Blog de l'équipe Microsoft Exchange « You Had Me From EHLO »

Restez connecté

Faisons une pause avant de plonger encore plus en détail dans l'architecture de transport et les scénarios de test. J'ai couvert pas mal de terrain, d'un déploiement de serveurs de transport Edge du style de celui de Microsoft IT aux événements intérieurs déclenchés dans le pipeline de transport pendant le traitement des messages. Dans le prochain article de cette série en deux parties, je continuerai en analysant le comportement des agents de transport Edge dans quelques scénarios de test intéressants.

Entre-temps, je vous recommande de télécharger la version d'essai de 90 jours de Microsoft Visual Studio 2005 Professional Edition (go.microsoft.com/fwlink/?LinkId=98043) et de suivre les explications de Steve pour la compilation et l'installation d'agents d'exemple dans votre environnement de test. Même si vous n'êtes pas développeur, l'exécution de ces tâches est très simple. Je ne serais pas surpris de voir un nombre croissant d'applications professionnelles s'appuyant sur des agents personnalisés, en raison de la facilité avec laquelle ces composants peuvent être développés dans Exchange Server 2007 avec Visual Studio 2005.

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.