Réseau - Web - GNU/Linux

2011 13 mai

Évitez l'utilisation illicite de vos noms de domaine avec SPF - Debian 5.0 Lenny

Rédigé par Marc GUILLAUME | Aucun commentaire

Utiliser le framework SPF pour éviter l'utilisation illicite de votre domaine.

Si vous êtes fatigué des faux mails semblant provenir de domaines très connus comme eBay ou Paypal voici un espoir. Et vous pouvez au moins protéger votre propre domaine de spammeurs envoyant des messages en votre nom. C'est le propos de SPF qui est le sigle de sender policy framework. Dans son principe de base le possesseur d'un domaine définit quelles adresses IP sont autorisées à envoyer des mails. Prenons un exemple. Si vous avez sous la main l'outil dig lancez la commande :

 $> dig +short workaround.org txt

et vous allez voir quelque chose comme

 "v=spf1 ip4:85.214.93.191 ip4:85.214.149.150 -all"

Cela signifie que si quelqu'un vous envoie un mail avec une adresse d'expéditeur du domaine @workaround.org alors vous devriez l'accepter seulement si il a été envoyé depuis une de ces deux adresses IP. Le "-all" à la fin indique qu'aucune autre adresse IP ne devrait être acceptée (FAIL). Une autre règle comme "~all" à la fin de la ligne indique un SOFTFAIL, c'est à dire que vous devriez au moins être plus soupçonneux et peut-être augmenter le score de spam. (Dans la pratique "~all" est largement utilisé mais c'est à peu près sans intérêt. Soit vous savez ce que vous faites et vous utilisez "-all" ou bien alors vous n'utilisez pas du tout SPF. Si vous voulez tester si SPF fonctionne alors vous pouvez utilise "?all".)

Ainsi si quelque'un vous envoit un mail depuis …@workaround.org from depuis une autre adresse IP alors vous pouvez le rejeter, c'est un spam.

Beaucoup d'entreprises ont déjà des enregistements SPF que vous pouvez utiliser pour réduire le nombre de spam que vous recevez. Donc les tâches à exécuter en tant qu'administrateur de serveur de courrier sont :

  • Mettre en place une entrée TXT dans votre zone DNS définissant quelle adresse IP est autorisée à envoyer des mails au nom de votre domaine
  • Vérifier les entrées des serveurs expéditeurs et rejeter les mails provenant d'adresses IP non autorisées.

Mise en place d'une entrée SPF

Bien entendu vous devez avoir totalement le contrôle de votre zone DNS pour ajouter un enregistrement TXT. Si vous ne le pouvez pas alors demandez à votre ISP et demandez-lui d'ajouter cette entrée TXT. L'enregistrement SPF doit être lisible par la machine. Je vous suggère d'aller sur le site web de OpenSPF et d'utiliser leur utilitaire pour créer une entrée SPF correcte. Ajoutez cette chaîne en enregistrement TXT pour votre domaine. Comme au dessus vous devriez afficher l'entrée SPF si vous lancez la commande dig sur votre domaine :

 $> dig +short mydomain.com txt

Vous devez être averti d'un inconvénient qui est également le plus gros problème de SPF : si vos utilisateurs utilisent l'option de transfert (forward) celui-ci pourra être rejeté. Dans tous les cas vous devez être certain que vos utilisateurs envoient toujours leurs mails par l'intermédiaire de votre serveur de mail.

Vérifiez les entrées SPF des autres serveurs de Mail

Par chance il existe un paquet Debian pour le logiciel tumgreyspf ce qui facilite la vérification des entrées SPF. Installez le :

$> aptitude install tumgreyspf

tumgreyspf est un démon de vérification écrit en Python qui réalise à la fois le greylisting et le contrôle SPF des mails entrants. Son utilisation est détaillée dans le fichier /usr/share/doc/tumgreyspf/README.Debian. Dans l'utilisation de base il suffit d'ajouter dans /etc/postfix/main.cf une ligne à vos règles smtpd_sender_restrictions (ou smtpd_recipient_restrictions si vous avez tout mis là) pour pouvoir l'utiliser. Par exemple :

smtpd_sender_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    [ ... ]
    check_policy_service unix:private/tumgreyspf
    [ ... ]
    permit

Et pour définir le programme qui doit être appelé lors de l'utilisation de ce service de règles vous devez ajouter deux lignes dans votre /etc/postfix/master.cf :

tumgreyspf unix  -      n       n       -       -       spawn
   user=tumgreyspf argv=/usr/bin/tumgreyspf

Rechargez votre Postfix et obtenez :

        $> postfix reload

Le cas : SPF okay

Regardez votre fichier de log /var/log/mail.log. Chaque mail entrant devrait rajouter une ligne supplémentaire venant de tumgreyspf. SI la vérification SPF est positive alors vous devriez voir :

tumgreyspf[24672]: sender SPF authorized: QUEUE_ID=""; identity=mailfrom;
client-ip=26.21.244.31; helo=squedge2.squ.edu.om;
envelope-from=…@squ.edu.om;
receiver=…@workaround.org;

Ceci signifie que l'expéditeur …@squ.edu.om a été accepté après vérification de l'entrée SPF.

Le cas SPF fail

Si la vérification SPF échoue vous verrez quelque chose de ce genre :

tumgreyspf[24672]: SPF fail - not authorized: QUEUE_ID=""; identity=mailfrom;
client-ip=41.234.18.141; helo=gmx.de;
envelope-from=…gmx.de;
receiver=…christoph-haas.de;

Le mail a été rejeté. Un spam de moins dans le monde. :)

Le cas SPF softfail

Le troisième cas se produit lorsque l'entrée SPF ne force pas à FAIL (-all) mais juste à SOFTFAIL (~all). Dans vote fichier de log vous verrez :

tumgreyspf[20408]: domain owner discourages use of this host: QUEUE_ID="";
identity=mailfrom; client-ip=220.245.2.67; helo=220-245-2-67.static.tpgi.com.au;
envelope-from=…@rollouts.com; receiver=…@workaround.org

Malheureusement le SOFTFAIL ne rejette pas réellement le mail. Mais l'expéditeur croit toujours que cette adresse IP ne deverait pas envoyer de mail pour ce domaine. Heureusement tumgreyspf ajoute cette information dans un en-tête Received-SPF dans le mail. Comme ceci :

Received-SPF: Softfail (domain owner discourages use of this host) identity=mailfrom;
client-ip=61.146.93.243; helo=mail.163gd.com;
envelope-from=…@cantv.net; receiver=…@christoph-haas.de;

Cela vous offre une chance de marquer un tel email comme spam dans votre client de mail en filtrant les mails ayant un en-tête Received-SPF: Softfail.

(malheureusement tumgreyspf n'a pas d'option de configuration qui permettrait de traiter SOFTFAIL comme FAIL).

Le cas pas d'information SPF

Si le domaine distant est stupide et ignorant et n'a pas d'entrée SPF alors vous lirez dans votre fichier de log :

Received-SPF: Neutral (access neither permitted nor denied) identity=mailfrom;
client-ip=80.65.65.222; helo=mail.unze.ba;
envelope-from=…@gmail.com; receiver=…@christoph-haas.de;

Écrire un commentaire

Quelle est la deuxième lettre du mot xuuxj ?

Fil RSS des commentaires de cet article

À propos

Yakati.info - Réseau - Web - GNU/Linux © 2017

Généré par PluXml en 0.029s  - Administration

Mes coordonnées

Marc Guillaume
contact[at]yakati.info
79150 ÉTUSSON

Crédits

Pour la gestion du contenu

Généré par PluXml, le Blog ou Cms sans base de données

Pour le contenu

Licence Creative Commons
Ce(tte) œuvre est mise à disposition selon les termes de la Licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les Mêmes Conditions 4.0 International.

Pour le thème

Thème SOLID de blacktie.co adapté pour PluXml