19
Août 05

Lutte antispam et antispoofing d’email

19 août 2005 | Non classé

Le spam n’est désormais plus un phénomêne émergeant : c’est une réalité à  laquelle il faut faire face tous les jours dans le domaine du courrier électronique sur Internet.

Les protocoles liés au mail n’ont pas été conçus avec le souci de la sécurisation (comme la plupart des protocoles à  l’origine d’Internet d’ailleurs). Spécifiquement, le protocole SMTP (pour Simple Mail Transfer Protocol, RFC 821) n’intêgre aucune notion d’authentification de l’émetteur ou de canal de communication sécurisé.

Ceci est à  l’origine d’une partie des problêmes de spam rencontrés actuellement : les spammeurs peuvent se forger une identité (une adresse mail) pour émettre des messages semblant provenir de bill gates ou d’un utilisateur de hotmail, yahoo ou caramail. Par la suite, la victime (le destinataire) aura l’impression que l’émetteur du message de spam est légitime, puisqu’il connaît sinon l’émetteur, du moins le domaine de l’adresse mail utilisée.

L’une des techniques les plus courantes des spammeurs consiste à  utiliser un relais de messagerie mal configuré pour envoyer un grand nombre de « pourriels » (terme consacré pour la françisation de spam). Les technologies présentées ici n’empécheront certainement pas l’utilisation de tels relais. Néanmoins, ils permettraient (dans un monde idéal) de compliquer la vie des spammeurs en les empéchant d’utiliser des domaines arbitraires comme source de leurs messages.

Actuellement, la standardisation de ces technologie est en cours et aucune d’entre elle ne s’est affirmée comme la seule et l’unique devant étre utilisée sur Internet. Aucune n’a notamment atteint le stade de standard reconnu, et elles seront par ailleurs probablement complémentaires.

Sender Policy Framework

SPF est destiné à  limiter l’utilisation abusive d’adresses e-mail émettrices. Définie actuellement dans un draft (http://spf.pobox.com/draft-ietf-marid-protocol-00.txt) elle a pour vocation de permettre à  un relais de messagerie recevant un courriel de vérifier auprês du domaine concerné si l’émetteur (au sens IP du terme) est bien un émetteur légitime.

Pour comprendre plus précisément le fonctionnement de ce solution, imaginons qu’une entreprise possédant le domaine business.com souhaite déployer cette technologie. Il est important de préciser :

  • Qu’elle agira au niveau de ses serveurs DNS.
  • Que l’adoption de cette norme lui permettra de fournir des informations aux destinataires des courriels émis par ses employés. Ces informations concerneront les serveurs de messagerie autorisés à  envoyer des messages utilisant comme émetteur des adresses en business.com.

Elle ne se protégera donc pas elle-méme contre les spams, mais contribuera à  protéger les autres utilisateurs. C’est d’ailleurs le cas pour l’ensemble des technologies décrites dans cet article : mis en place par les grands acteurs d’Internet (et notamment les ISPs et les fournisseurs d’adresses de messagerie gratuites), elles permettent de renforcer la lutte globale contre le spam et le spoofing d’adresses mail, mais ne protêgent pas spécifiquement les utilisateurs de ceux qui les déploient.

L’utilisation de SPF consiste alors à  modifier le serveur DNS de la zone business.com en lui ajoutant un champ de type TXT. Les champs de type TXT sont destinés à  fournir des informations textes sur les informations de la zone ou la zone elle-méme.

Dans le cas de SPF, on va ajouter un champ TXT concernant l’ensemble de la zone, de la forme suivante :

 

business.com. IN TXT « v=spf1 mx -all » 

Cette entrée précise que la zone business.com fournit des informations conforme au standard SPF1 (v=spf1). Elle précise de plus que seuls les mx de la zone business.com sont autorisés à  envoyer des e-mails provenant de cette zone (mx). La chaîne -all permet de préciser que le comportement par défaut est de refuser un message provenant d’un serveur de messagerie non listé précédemment.

Ainsi, dans cet exemple, lorsque le serveur de messagerie du domaine client.com recevra un message provenant de l’utilisateur emetteur@business.com, envoyé par le serveur disposant de l’adresse IP 1.2.3.4 et à  destination de dest@client.com, il procêdera aux vérifications suivantes :

  1. Récupération de l’adresse IP de l’émetteur : 1.2.3.4
  2. Récupération du domaine de l’émetteur : business.com
  3. Interrogation du champ TXT au format SPF1 du domaine business.com auprês de son serveur DNS :

    business.com. IN TXT « v=spf1 mx -all » 

  4. Interrogation de ce méme serveur DNS pour vérifier la liste des serveurs MX de la zone

    business.com IN MX 5 1.2.3.4
    business.com IN MX 10 5.8.6.1 

Dans le cas o๠l’adresse IP de l’émetteur fait partie des émetteurs autorisés (ce qui est le cas ici), le message est accepté. Dans le cas contraire, la politique de sécurité est appliqué. Le message peut par exemple étre marqué comme du spam (pour permettre à  l’utilisateur de le trier) ou étre supprimé purement et simplement.

Le champ SPF peut aussi étre construit de maniêre plus complexe, en précisant par exemple la liste explicite des adresses IP autorisées (à  l’aide de l’option a:), ou encore en renvoyant vers le champ SPF associé à  une autre zone. Ainsi, si la société possédant le domaine business.com possêde aussi le domaine business.fr, elle pourra préciser le champ suivant pour cette derniêre zone :

business.fr. IN TXT « v=spf1 include:business.com -all »

De cette maniêre, elle n’aura à  maintenir qu’une seule liste des émetteurs autorisés, celle associés à  son domaine principal

Une des limites de cette technologie est qu’elle se contente d’analyser l’instruction MAIL FROM du protocole SMTP (l’enveloppe du message) et non son entéte From:. Or les spammeurs contournent déjà  cette limitation en utilisant au niveau SMTP une adresse email différent de celle précisée dans l’entéte, qui est celle affichée par le logiciel de messagerie des utilisateurs.

Pour une description plus précise de cette technologie, on pourra se référer à  la proposition de HOWTO rédigé par la société Zytrax.

Domainkeys

Yahoo a, de son cà´té, développé une solution pour lutter contre le spam en empéchant les spammeurs d’envoyer des messages en utilisant des adresses émettrices arbitraires. Elle est expliquée dans un draft . Yahoo possêde sur cette technologie un certain nombre de brevets, mais n’en a restreint l’usage d’aucune façon (à  ma connaissance, car je ne suis pas juriste), contrairement à  la solution de Microsoft exposée plus bas.

L’idée de cette solution est de permettre la signature par le relais émetteur des messages et la vérification de cette signature par les destinataires.

Ainsi, si on reprend l’exemple cité ci-dessus, les administrateurs de business.com commmencent par créer une paire de clé publique/clé privée destinées à  signer les messages émis par le relais sortant. A chaque fois qu’un email sera envoyé, le relais ajoutera un entéte appelé DomainKey-Signature qui contiendra la signature du message avec sa clé privée. Cet entéte est rajouté avant le reste du message (y compris son entéte) et n’est pas utilisé pour calculer la signature :

 

  • DomainKey-Signature: a=rsa-sha1 s=blah; d=business.com; 
  • c=simple; q=dns;
  • b=dzdVyO…iYzR;

On précise alors l’algorithme utilisé (rsa-sha1), des informations nécessaires pour retrouver la clé publique associée (blah, voir plus bas), le nom de domaine associé à  la signature (business.com), l’algorithme utilisé pour « canoniser » le message (simple) et la méthode pour récupérer la clé publique (dns).

Dans la plupart des cas, la signature est calculée à  partir de la ligne suivant l’entéte DomainKey-Signature. Néanmoins, il est possible de préciser dans ce champ quels sont les entétes à  intégrer dans la signature (à  l’aide de l’option h=)

Par la suite, les relais de messagerie intermédiaires ajoutent des informations dans l’entéte du message, mais ils le font au début, avant le champ DomainKey-Signature. La signature n’est donc pas modifiée.

Lors de la réception du message par le relais de messagerie du domaine du destinataire, celui-ci récupêre le champ DomainKey-Signature et s’appréte à  effectuer un ensemble d’action de vérification de signature :

  1. Analyse de l’entéte DomainKey-Signature pour récupérer le nom de domaine concerné et construire la requéte DNS permettant de récupérer la clé publique associée.
  2. Requéte auprês du serveur DNS du domaine émetteur. Dans l’exemple pris ici, l’enregistrement TXT de l’entrée blah._domainkey.business.com sera utilisé. _domainkey est réservé dans ce but, et blah est précisé dans l’entéte (voir la description du champ DomainKey-Signature ci-dessus). Ceci permet à  l’administrateur du domaine de l’organiser comme il l’entend.
  3. Récupération et analyse de ce champ. On précise notamment l’algorithme à  l’aide du champ k= et la clé publique, encodé en Base64, à  l’aide du champ p=
  4. blah._domainkey IN TXT « k=rsa; p=MHww … IDAQAB »

  5. Muni de cette information, le serveur de messagerie destinataire peut appliquer sa politique de sécurité, par exemple en marquant ce message comme du spam ou en le supprimant purement et simplement.

Contrairement à  SPF, Domain Keys analyse le champ From: de l’entéte et ne se content donc pas de travailler au niveau SMTP.

Le défaut de cette technique est qu’elle introduit un traitement supplémentaire au niveau du relais de messagerie émetteur, qui risque d’étre consommateur en ressource CPU.

Sender ID : extension Microsoft de SPF

Sender ID est la solution issue de la fusion de la proposition de Microsoft et de SPF v1. Elle est définie sur la page Sender ID FrameWork. En septembre 2004, l’IETF a refusé de normaliser officiellement cette proposition, et AOL a annoncé que pour sa part elle ne la soutiendrait pas. On peut donc penser que, par rapport aux deux solutions présentée ci-dessus, Sender ID est en perte de vitesse et risque de ne pas parvenir à  s’imposer.

Sender ID est un complément à  SPF. De la méme maniêre, il repose sur des enregistrements DNS précisant les relais de messagerie autorisés à  envoyer des messages provenant d’un domaine particulier.

Ces entrées commencent par la chaîne spf2, indiquant par là  la filiation avec la norme SPF :

 

spf2.0/pra mx a:81.91.65.187 -all 

Sender ID complête SPF en précisant que le champ From: de l’entéte devrait étre vérifié en plus de l’adresse de l’enveloppe SMTP.

Elle introduit aussi la notion de PRA (Purported Responsible Address) permettant de déterminer l’adresse mail responsable de l’envoi du message. Dans le cas de mailing-lists par exemple, ce n’est pas forcément l’adresse précisée dans le champ From:. Sender ID définit alors un algorithme capable de retrouver l’adresse responsable.

Elle propose de plus l’ajout de la commande SUBMITTER au protocole SMTP afin de résoudre les problêmes posés par cette technologie concernant la forwarding des messages.

En effet, supposons que l’utilisateur emetteur@test.com envoie un message à  forward@tempo.com, et que ce compte de messagerie soit configuré pour transmettre (forwarder) tous les messages à  destination de dest@final.com. Si l’émetteur du message utilise Sender ID (ou SPF d’ailleurs), il pourra l’envoyer à  tempo.com, qui sera chargé de simplement le transmettre à  final.com. Le problême est que l’adresse mail source du message sera emetteur@test.com, mais que le message proviendra de l’adresse IP du relais de messagerie de tempo.com. Ce dernier ne sera pas indiqué dans la liste des relais de messagerie autorisés pour le domaine test.com, ce qui est normal puisqu’il n’est pas lié à  ce domaine. Le relais de messagerie de final.com considérera alors ce message comme du spam ! Pour résoudre le problême, Microsoft a proposé avec Sender ID d’ajouter un commande SUBMITTER au protocole SMTP, passé avec la commande MAIL FROM:. Ainsi, dans notre exemple, on aurait :

 

MAIL FROM: emetteur@test.com SUBMITTER=forward@tempo.com 

Ainsi le relais recevant le message est informé que le message a transité par le domaine tempo.com et peut aller faire ses vérifications auprês de lui.

A noter que la solution SPF version 1 ne dispose pas d’une telle solution de contournement, et que son promotteur, pobox propose tout simplement que le relais de messagerie de tempo.com ré-écrive l’adresse email de l’émetteur (au niveau SMTP, puisque SPF v1 ne travaille qu’à  ce niveau). Cette solution est appelé SRS (pour Sender Rewriting Scheme) et consiste alors à  réécrire l’adresse email de l’émetteur en emetteur=test.com@tempo.com. Ainsi le serveur destinataire ira chercher les informations de SPF auprês du serveur DNS de la zone tempo.com, tout en étant capable de retrouver l’émetteur initial du domaine (en supprimant le @tempo.com et en remplaçant le = par un @). Néanmoins, ceci requiert de modifier l’ensemble des relais de messagerie, y compris ceux ne supportant pas SPF et SRS, afin qu’ils puissent au moins retrouver l’émetteur original du message.

Alternatives

Les trois solutions présentées ci-dessus ne sont pas les seules. Plusieurs autres, non soutenues par des groupes tels que Yahoo ou Microsoft, coexistent :

  • Client SMTP Validation précise que le client SMTP doit préciser dans le champ HELO son nom DNS, et que le relais de messagerie cible doit vérifier que l’adresse IP du client correspond à  l’adresse IP associée à  son nom DNS. Cette solution a l’avantage de la simplicité, et empéche les spammeurs de prétendre émettre des messages depuis smtp.yahoo.com par exemple
  • RMX est une alternative aux solutions SPF et Sender ID, fonctionnant lui-aussi au niveau des adresses mail SMTP. RMX précise lui aussi la liste des adresses IP autorisées à  émettre des messages pour un domaine donné, mais propose de diffuser cette information via les protocoles HTTP, HTTPS ou encore LDAP.

Limites et conclusion

En conclusion, il est important de retenir qu’aucune de ces solutions ne constitué la panacée :

  • Dans tous les cas, elles demandent une adoption large pour commencer à  étre utiles et efficaces dans la lutte contre le spam. Il est évident que ce point est difficilement évitable
  • En attendant cette phase de diffusion plus importante, à  nouveau quelle que soit la technologie, la « protection » n’est efficace que si à  la fois l’émetteur et le destinataire l’implémente. business.com peut três bien diffuser des entrées SPF, si personne ne les vérifie, cela sera inutile. De méme, configurer un relais de messagerie pour qu’il vérifie les informations Domain Keys alors qu’aucun n’émetteur n’en fournit s’avance pas à  grand chose.
  • Certaines solutions posent des problêmes importants d’implémentation, tel le problême concernant le forwarding pour SPF et Sender ID.
  • Ces solutions n’empéchent pas un spammeur de créer le domaine businesss.com (avec trois s à  la fin) et de l’utiliser pour émettre des mails en provenant de ce domaine.

Il est donc important de garder à  l’esprit que ces solutions permettent de compléter la lutte contre le spam, qu’elles sont souvent complémentaires et à  implémenter ensemble (par exemple SPF + DomainKeys), et qu’elles ne signifient pas qu’il faille abandonner les solutions utilisées jusqu’alors, telles que les listes RBL ou les logiciels de détection de spam tels que SpamAssassin, SpamBayes ou les produits proposés par les principaux éditeurs du marché.


  • pierson bernard

    bonjour voilà  le texte envoyé à  msn messenger pour récupérer une adresse email qu’en pensez vous ?
    quelles solutions envisagez vous ?
    deux adresses on disparu en me prenant mes mots de passes
    je ne peux les récupérer pas la voie normal
    merci ce me donner un conseil avisé merci

    Bonjour,

    Merci de vos réponses mais elles ne me satisfont pas du tout
    En effet je n’ai plus accês à  mon compte pibenaboy@hotmail.com ni depuis hier à  celui de cplbenou@yahoo.fr
    Quelqu’un c’est approprié mes mots de passe et je ne peux redéfinir un mot de passe car je n’ai plus la question secrête avec la réponse, ni l’adresse de messagerie de secours
    J’ai écris à  Microsoft Passport Network mais sans résultats ?
    Mes codes support sont les suivants :
    Le 11/02/2006 1009065784
    Le 12/02/2006 1009110666
    Le 13/02/2006 1009155366
    Le 14/02/2006 1009219889
    Le 14/02/2006 1009219953
    Le 17/02/2006 1009391110
    Le 17/02/2006 1009394129
    J’ai téléphoner ici en Belgique mais rien non plus on me renvoit sur le site ?
    Pouvez vous de votre cà´té récupérer le compte pibenaboy@hotmail.com car j’ai des dossiers important dedans et ce dans la messagerie ?
    Pouvez vous m’envoyer « une redéfinition de mon mot de passe » à  pibenaboy@tiscali.be ou pibenaboy@caramail.com
    Je vous donne carte blanche pour récupérer ce compte et me faire part de votre avis !
    Moi je sais plus rien faire concernant les options de redéfinition de mon mot de passe vu que je ne les ai plus ni questions ni réponses ni messagerie de secours
    Pierson Bernard
    57, rue de Burhaimont
    6880 Belgique
    Messagerie : pibenaboy@hotmail.com (celle qui est bloquée ?)
    Merci de me répondre sur pibenaboy@tiscali.be

  • Bonjour,
    cela semble fortement compromis dans la mesure ou vous n’avez plus acces a l’adresse de secours, certainement donnée lors de la creation des @ (?!). 🙁

    Votre seul recours est effectivement montrer pate blanche a un technicien/admin de hotmail, ce qui je presume, est difficile a faire.

    Desole de ne pouvoir plus vous aider.