Exchange Server 2007

Lutter contre le courrier indésirable et le phishing à l'aide de Sender ID

Craig Spiezle and Alexander Nikolayev

Vue d'ensemble:

• Notions fondamentales sur Sender ID
• Configurer Sender ID sur Exchange Server
• Avantages de l'authentification

De nombreuses technologies d'identification et de filtrage ont été développées suite à la menace grandissante du courrier indésirable. Leur efficacité repose sur le questionnement de chaque message électronique, concernant

l'expéditeur du message par exemple. Malheureusement, la réponse à la question fondamentale de l'identité de l'expéditeur n'est pas toujours facile à donner. Le courrier électronique est généralement envoyé sur Internet sans que l'expéditeur soit authentifié ou sans que les ordinateurs agissent au nom de l'expéditeur. En réalité, il est facile d'envoyer un message électronique tout en prétendant être quelqu'un d'autre et il n'existe aucune méthode automatisée pour détecter ces messages usurpés.

Le SMPT (Simple Mail Transfer Protocol), utilisé pour envoyer et recevoir des courriers électroniques, n'a pas été conçu pour vérifier l'identité de l'expéditeur d'un message électronique. Cette faille technologique rend possible l'insertion de n'importe quel nom et n'importe quelle adresse au titre d'expéditeur. Par conséquent, des mesures de filtrage de contenu ou anti-spam ne peuvent se baser uniquement sur les informations d'en-tête pour garantir que les messages proviennent vraiment de l'expéditeur déclaré.

L'authentification du courrier électronique répond de manière spécifique à cette faille. Grâce à l'authentification, les systèmes d'envoi et de réception de courrier électronique attestent que les messages proviennent des domaines d'où ils déclarent venir. Les organisations peuvent ainsi filtrer le courrier électronique indésirable facilement et de manière efficace, mais peuvent également s'assurer que le courrier électronique légitime arrive aux destinataires prévus.

Il existe aujourd'hui deux méthodes, libres de droits, permettant l'authentification du courrier électronique : SIDF (Sender ID Framework) et DKIM (DomainKeys Identified Mail). SIDF est une solution basée sur IP (Internet Protocol) créée à partir de la fusion de SPF (Sender Policy Framework) et de l'ID de l'appelant Microsoft pour le courrier électronique. En avril 2006, IETF (Internet Engineering Task Force) a publié les spécifications RFC 4405-4408 de Sender ID. Une coalition des parties prenantes de l'industrie et des entreprises, y compris Microsoft, recommande le déploiement de SIDF basé sur des facteurs tels que sa valeur technique et commerciale, sa stabilité, sa maturité, sa facilité de déploiement, son impact réduit sur les performances sortantes ou entrantes ainsi que son interopérabilité avec l'écosystème du courrier électronique pour les fournisseurs de services Internet et les environnements d'entreprise.

DKIM est la fusion de Yahoo! Spécifications des IIM (Identified Internet Mail) de DomainKeys et de Cisco Systems Inc. En janvier 2006, IETF a approuvé la création d'un groupe de travail DKIM et la spécification est actuellement revue par IETF.

Comme il n'existe aucune solution parfaite pour lutter contre le courrier indésirable, SIDF constitue une initiative industrielle d'importance non négligeable pour lutter contre les domaines usurpés. Par conséquent, il s'agit d'un élément clé pour réduire les attaques de courrier indésirable et de phishing et pour augmenter la confiance en général et la fiabilité des opérations en ligne. Partout dans le monde, le SIDF est de plus en plus adopté par les organisations. De nos jours, plus de 5,5 millions d'entreprises et de détenteurs de domaines ont publié des enregistrements SPF et plus de 600 millions d'utilisateurs sont protégés par SIDF. À ce jour, plus d'un tiers du volume du courrier électronique journalier mondial est désormais authentifié et compatible avec SIDF.

Le développement et l'adoption mondiale de SIDF seraient impossibles sans la contribution et le soutien de nombreuses organisations et entreprises, dont AOL, AOTA (Authentication and Online Trust Alliance), Bell Canada, ESPC (E-Mail Senders Provider Coalition), CipherTrust, Cisco Systems, IronPort Systems, MarkMonitor, Port25 Solutions Inc, Sendmail, Symantec, TRUSTe, VeriSign, entre autres.

Comprendre Sender ID

Certaines enquêtes industrielles indiquent que plus de 95 % des schémas de phishing proviennent de domaines usurpés et possèdent des adresses d'expéditeur de courrier électronique usurpées. C'est là que SIDF fait toute la différence pour ce qui est du traitement anti-spam. SIDF ne résoudra pas à lui seul ce problème de courrier indésirable, mais il contribue fortement à minimiser les conséquences des attaques de courrier indésirable et de phishing. SIDF n'empêche pas l'envoi des courriers électroniques indésirables. Il facilite cependant leur détection. Cet environnement permet aux expéditeurs de courrier électronique de protéger leur nom de domaine, leur réputation et leur marque. Il fournit une base solide pour prendre des décisions de filtrage basées sur la réputation et le comportement de l'expéditeur, en termes de courrier électronique.

Sender ID cherche à vérifier que chaque message électronique provient du domaine Internet duquel il déclare avoir été envoyé. Ceci se fait par la vérification de l'adresse du serveur qui envoie le courrier électronique par rapport à une liste enregistrée de serveurs autorisés par le propriétaire de domaine à envoyer des courriers électroniques. La vérification est exécutée par le fournisseur de services Internet ou par le serveur de courrier du destinataire avant que le message ne soit délivré à la boîte de réception de l'utilisateur.

Remarquez que le Sender ID ou tout autre mécanisme d'authentification ne remplacent pas les systèmes de filtrage du contenu. Ni SIDF ni DKIM ne vérifient le contenu réel du message. Au lieu de cela, l'authentification indique au système de courrier électronique d'entrée si le message peut être validé comme provenant de l'expéditeur revendiqué. Parce que la plupart des tentatives de spam et de phishing ne proviennent pas, en fait, du domaine affiché, cette approche permet d'identifier automatiquement ces messages et de les séparer du flux de courrier électronique entrant.

Au sein du SIDF, l'enregistrement SPF fournit un simple enregistrement de texte de tous les serveurs de messagerie de sortie associés à un domaine, en même temps que leurs adresses IP respectives. Une organisation publie l'enregistrement SPF sur son fichier de zone de serveur, qui est alors vérifié par les serveurs de messagerie du destinataire. Configurer un enregistrement SPF : c'est rapide, facile et gratuit. L'assistant d'enregistrement SPF de l'environnement Sender ID fournit un processus pas à pas pour examiner les serveurs de messagerie d'un domaine et créer des enregistrements personnalisés prêts pour la publication. (Les informations concernant la publication d'un enregistrement SPF sont disponibles sur microsoft.com/senderid. Vous pouvez accéder directement à l'assistant sur microsoft.com/senderid/wizard.)

Le serveur de courrier électronique SMPT de réception exécute le fichier de zone du domaine dans le DNS pour détecter la présence d'un enregistrement SPF. Une fois détectée, l'adresse IP du serveur expéditeur est vérifiée par rapport aux adresses IP répertoriées. S'il y a correspondance, l'authenticité du message est validée. En revanche, si l'enregistrement SPF sur le domaine de l'expéditeur ne correspond pas à l'adresse IP d'où provient le message, il échoue, est évalué négativement et risque d'être placé dans le dossier de courrier indésirable. La figure 1 présente ce processus.

Figure 1** Vérification des enregistrements SPF pour les messages entrants **(Cliquer sur l'image pour l'agrandir)

Une fois le message balisé, le SIDF permet au serveur de courrier destinataire d'analyser le message sur la base des comportements précédents, sur la réputation de l'expéditeur, le contenu et sur d'autres critères qui peuvent être définis s'il y a lieu. Cette possibilité assure une meilleure sécurité. Par exemple, les expéditeurs de courrier indésirable peuvent enregistrer des domaines d'aspect semblable et des enregistrements SPF publiés pour tromper l'utilisateur et le réseau de réception et les amener à penser que le courrier électronique émane d'un expéditeur légitime. Et même si le message électronique passe la barrière de la vérification de l'authentification, la réputation d'expéditeur de courrier indésirable de l'expéditeur est suffisante pour bloquer, rendre indésirable ou supprimer le message.

Options de déploiement de Sender ID

L'authentification du courrier sortant via SIDF ne nécessite pas d'évolution de l'infrastructure ou de mise à jour logicielle et n'est pas spécifique au logiciel client ou serveur. Cependant, les organisations qui désirent incorporer l'authentification à l'arrivée des messages pour protéger leur entreprise et leurs employés, devront mettre à jour leurs systèmes d'entrée et leurs MTA (Message Transfer Agent) et déployer un logiciel ou un système qui prend en charge SIDF. La majorité des principaux MTA commerciaux et Open Source et des fournisseurs anti-spam, dont Microsoft® Exchange Server et Exchange Hosted Filtering, propose des solutions intégrées.

Microsoft a intégré SIDF à tous ses produits de messagerie, y compris à Microsoft Exchange Server 2003 Service Pack 2 (SP2), Exchange Server 2007, Microsoft Exchange Hosted Filtering (filtrage Microsoft Exchange), Microsoft Windows Live™ Mail, MSN® Hotmail®, Outlook® Express ainsi qu'à la messagerie Outlook Office et aux clients de collaboration.

Et pourtant, même Microsoft reçoit des courriers indésirables. Environ 15 millions de messages arrivent chaque jour chez Microsoft et lors des dernières attaques de courrier indésirable, nous avons constaté que ce volume pouvait doubler à quadrupler. Dans un tel environnement, le moyen le plus efficace pour se protéger du courrier indésirable consiste à être vigilant et à implémenter les technologies disponibles.

Microsoft utilise une solution anti-spam Exchange Server interne basée sur le filtre Sender ID dans Exchange Server 2003 et sur l'agent Sender ID dans Exchange Server 2007. Dans ces deux versions d'Exchange Server, l'état du Sender ID est basé sur l'évaluation de l'enregistrement du Sender ID situé sur les serveurs DNS correspondants. Le domaine réel est déterminé par l'examen des en-têtes du message RFC 2822 dans l'ordre de priorité suivant :

1. Resent-Sender
2. Resent-From
3. Sender
4. From

Le domaine de l'expéditeur (ou l'entité responsable de l'injection d'un message dans le flux de messagerie et qui est la plus récente car les systèmes de messagerie peuvent transférer des courriers électroniques de manière légitime, au nom d'autres serveurs de messagerie) est déterminé par la localisation de la première définition des en-têtes qui viennent d'être mentionnés dans l'ordre défini. Si aucun de ces en-têtes n'est trouvé, SIDF utilisera la valeur MAIL FROM de SMTP RFC 2821.

Configurer Sender ID

Dans Exchange Server 2007, l'agent Sender ID peut être activé sur les serveurs sur lesquels est installé le rôle de transport Edge. Si l'agent Sender ID est activé, il filtrera les messages passant par les connecteurs de réception - tout le trafic entrant non authentifié (provenant de sources externes) sera soumis à un traitement par le Sender ID. Dans Exchange Server 2003, l'état du Sender ID persiste d'un serveur à l'autre dans le blob EXCH50. Dans Exchange Server 2007, il a également été ajouté aux métadonnées du message. Au niveau de leur destination finale, tous deux sont convertis en une propriété MAPI pour une consommation client future.

La configuration de filtrage du Sender ID dans Exchange Server 2003, disponible dans les propriétés de remise des messages, consiste uniquement à spécifier comment Exchange Server gère l'échec de la validation.

Pour activer Sender ID dans Exchange Server 2007, il suffit d'ouvrir Exchange Management Console pour un serveur sur lequel est configuré le rôle de transport Edge, de sélectionner l'onglet Anti-spam, puis le Sender ID et dans le volet Actions, de cliquer sur Activer ou Désactiver pour agir sur l'agent Sender ID comme illustré dans la figure 2. De plus, vous pouvez utiliser Exchange Management Shell pour activer ou désactiver Sender ID comme illustré dans la figure 3.

Figure 2** Contrôles de la console de gestion Exchange pour l'agent Sender ID dans Exchange Server 2007 **(Cliquer sur l'image pour l'agrandir)

Figure 3** Activer Sender ID en utilisant l'environnement de ligne de commande Exchange Management Shell **(Cliquer sur l'image pour l'agrandir)

La boîte de dialogue des propriétés du Sender ID ne reflète pas l'état (activé ou désactivé) de l'agent. L'onglet Action fournit des options très similaires à celles disponibles dans Exchange Server 2003 (voir Figure 4).

Figure 4** Propriétés Action de l'agent Sender ID dans Exchange Server 2007 **(Cliquer sur l'image pour l'agrandir)

En termes d'implémentation et de fonctionnalité du Sender ID, il n'existe pas de différence majeure entre Exchange Server 2003 et Exchange Server 2007. Le filtre Sender ID (dans Exchange Server 2003) et l'agent Sender ID (dans Exchange Server 2007) utilisent le même algorithme sous-jacent pour l'extraction et la vérification. L'éventail des actions possibles est également le même : Supprimer le message (suppression silencieuse), Rejeter le message (réponse de protocole SMPT niveau 500) et Marquer le message avec le résultat du Sender ID et continuez le traitement. La dernière option est l'action par défaut dans les deux versions d'Exchange Server.

Dans Exchange Server 2007, les codes d'état FAIL et TempError peuvent déclencher une action Rejeter le message (dans Exchange Server 2003, seul un code d'état FAIL peut déclencher cette action). L'agent Sender ID doit être configuré de manière explicite pour déclencher l'action Rejeter le message sur des messages comportant un code d'état TempError car, par défaut, ces messages seront acceptés dans le système, marqués avec le résultat du Sender ID puis traités.

L'option de configuration par cela n'est pas disponible dans l'interface utilisateur graphique, vous devez donc utiliser Exchange Management Shell pour configurer les actions de Sender ID pour le code d'erreur TempError. Par exemple, pour forcer l'agent Sender ID à rejeter les messages avec un code d'état TempError, exécutez la cmdlet de l'agent Sender ID suivante :

Set-SenderIDConfig -TempErrorAction Reject

L'éventail des résultats d'état et des actions possibles de Sender ID dans Exchange Server 2007 est semblable à celui du filtre Sender ID Exchange Server 2003 ; il est illustré dans la figure 5.

Figure 5 État et actions de Sender ID dans Exchange Server 2007

Exchange (s'il est configuré pour ça) supprimera seulement les messages qui ont échoué à la vérification du Sender ID. Aucun autre résultat ne déclenchera une suppression de message. Les messages entrants affichant une attribution d'état Neutre, Aucun, SoftFail, TempError ou PermError seront marqués de manière appropriée et transmis pour une vérification anti-spam approfondie. Dans certains cas, lorsque le message est vraiment mal fait et que l'adresse IP FROM fait défaut, l'état Sender ID ne peut être marqué sur le message. Dans une telle situation, le message n'est ni ignoré ni rejeté. Au lieu de cela, il sera transmis pour un traitement approfondi sans que l'état Sender ID soit défini et un événement approprié sera journalisé pour renforcer la vigilance.

Dans Exchange Server 2007, il est facile de définir les domaines d'expédition et les destinataires d'Exchange Server qui doivent être exclus de la vérification Sender ID. Là aussi, cette option de configuration n'est disponible que via l'environnement de ligne de commande Exchange Management Shell. Par exemple, pour exclure le domaine contoso.com du filtrage Sender ID, exécutez la commande suivante :

Set-SenderIDConfig -BypassedSenderDomains contoso.com

De la même façon, pour exclure les messages envoyés à des destinataires d'Exchange Server spécifiés à partir du filtrage Sender ID, exécutez la commande suivante :

Set-SenderIDConfig -BypassedRecipients user@contoso.com

Dans Exchange Server 2007, les valeurs de configuration du Sender ID définies via les cmdlets de l'environnement de ligne de commande Exchange Management Shell mais non disponibles dans l'interface utilisateur graphique, peuvent être facilement obtenues en exécutant la commande Get-SenderIDConfig dans l'environnement de ligne de commande Exchange Management Shell comme illustré dans la figure 6.

Figure 6** Cmdlets de configuration Sender ID **(Cliquer sur l'image pour l'agrandir)

L'environnement de ligne de commande Exchange Management Shell peut être utilisé pour effectuer une vérification manuelle rapide de l'adresse IP et du nom de domaine correspondant. Pour vérifier l'état Sender ID, exécutez la commande suivante :

Test-SenderID -IPAddress <IPAddress>-PurportedResponsibleDomain <SMTPDomain>

Si le domaine n'existe pas, vous verrez un résultat similaire à celui de la figure 7.

Figure 7** Vérifier l'état Sender ID d'une adresse **(Cliquer sur l'image pour l'agrandir)

Avantages de Sender ID

Outre l'intérêt évident de l'authentification des messages électroniques et de la réduction de la quantité de courrier indésirable reçue par les utilisateurs, SIDF en tant que protocole présente d'autres avantages. Lors de son développement, Microsoft s'est concentré sur plusieurs objectifs clés, dont la performance, le coût, le déploiement, l'évolutivité et l'interopérabilité.

SIDF authentifie d'abord un expéditeur de message électronique et permet l'évaluation de la réputation de l'expéditeur. Par conséquent, il peut potentiellement réduire de manière significative les messages de courrier indésirable et les messages usurpés et améliorer la remise du courrier électronique légitime provenant d'expéditeurs connus et de confiance. La création d'un enregistrement SPF est gratuite, toute organisation qui désire donc être compatible avec SIDF peut faire ça facilement. Les organisations qui désirent être compatibles avec les paramètres d'un nouveau standard doivent pouvoir le faire. Avec SIDF, la compatibilité est aussi facile que la publication d'un enregistrement SPF.

SIDF a été développé pour fonctionner sur les logiciels existants partout où c'est possible. Il peut être utilisé avec un large éventail d'architectures de courrier électronique et de logiciels client et serveur. Pour être efficace, tout service d'authentification doit pouvoir satisfaire les besoins des fournisseurs de services Internet les plus importants aussi facilement que ceux du plus petit serveur de courrier électronique personnel. SIDF peut prendre en charge de un à plusieurs milliers de serveurs de courrier électronique, plus ceux qui externalisent leurs serveurs de courrier électronique vers une autre organisation.

Les 18 et 19 avril 2007, Microsoft et un consortium d'entreprises de plus de 30 organisations et partenaires vont accueillir le Sommet Authentification et Identification en ligne & à Boston, Massachussets. Ce programme de deux jours passera en revue des études de cas et proposera une étude technique du Sender ID, en détaillant la valeur commerciale de l'authentification du courrier électronique. Pour plus d'informations, consultez le site www.aotalliance.org/summit2007. Pour plus d'informations concernant les outils et les ressources, visitez les sites www.microsoft.com/senderid et microsoft.com/exchange.

Craig Spiezle est responsable de la stratégie technologique et de la planification pour Windows Live Safety chez Microsoft. En tant que chef de produit de l'authentification du courrier électronique, Craig a été un élément moteur dans l'avènement de Sender ID dans ce secteur. Depuis ses débuts chez Microsoft en 1992, Craig a occupé plusieurs postes de direction, y compris dans le secteur du marketing international, des stratégies de support technique, des OEM et du développement des marchés émergents.

Alexander Nikolayev est responsable de programme chez Microsoft, en charge des protocoles côté serveur, de Transport Core et des composants anti-spam pour Exchange Server et Windows Server. Il possède un MBA (Master of Business Administration) obtenu à l'université de Mary, Washington. Lisez les commentaires d'Alexander sur le blog de l'équipe Exchange sur blogs.technet.com/exchange.

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