Forums d'entraide informatique - Astuces - Conseils

Lutter contre le Spam
Le Spam ou Shoulder of Pork and hAM est une référence à une marque de corned-beef. Ce terme désigne habituellement messages publicitaires non sollicités, en d'autres termes
de la publicité sauvage par email. Le rapport avec la marque de corned-beef est la manière dont les deux sont fabriqués, c'est-à-dire en "balançant des morceaux de viande dans les pales d'un ventilateur”, bref, d'arroser tout le monde.
Le Spam est le véritable fléau d'Internet depuis que la plupart des utilisateurs peuvent y accéder très facilement. Cette méthode promotionnelle vante d'habitude des réductions hallucinantes sur tout et n'importe quoi, des techniques (payantes) pour gagner de l'argent facilement, sans oublier les incontournables sites pornos possédant les plus belles filles, etc. Le simple fait de laisser son adresse email traîner sur un serveur peu scrupuleux peut vous amener à recevoir jusqu'à des centaines de messages de publicité par jour. Il faut savoir en effet que le fait de noyer des milliers de personnes sous un déluge de publicité est une activité peut coûteuse pour le spammeur. Il lui suffit généralement d'une bonne connectivité et d'un serveur SMTP. Le nombre de messages envoyés n'influant quasiment pas sur le coût, le but du spammeur est d'atteindre le maximum de personnes.
Une fois l'adresse d'un destinataire enregistrée dans une base, il devient quasiment impossible de se débarrasser du spam. Les spammeurs ont en effet une fâcheuse tendance à échanger leurs fichiers avec leurs comparses. Ajoutez à cela qu'il existe tout un système de validation et de grade pour "noter" les adresses. Si vous êtes responsable d'un serveur SMTP où vous ne contrôlez pas le comportement des utilisateurs de votre serveur, il est fort probable que tout cela n'aille qu'en s'aggravant. Les spammeurs sont malins et n'hésitent pas à jouer la carte de la personnalisation ou de la ruse la plus complexe. Il est fort probable qu'une personne ne connaissant pas ce domaine soit tentée de répondre à un message promettant de stopper la publicité le cas échant. Nous avons également vu passer des messages qui semblaient extraits d'une conversation privée parlant de rendez-vous et faisant grand usage de "comme je te connais bien", "suite à ton mail", et autres "comme je te le disais dans mon dernier message". Dans la plupart des cas, les utilisateurs sont tentés de répondre. demandant de quoi il s'agit
ou encore suivant les directives, permettant, soi- disant, de ne plus être spammés. Or, c'est exactement l'erreur à ne pas commettre, puisqu'ils valident ainsi leur adresse, confirmant qu'une personne lit effectivement les messages qui y sont destinés.
Ce genre de problème n'étant pas très agréable en tant qu'utilisateur, il l'est encore moins en tant qu'administrateur. Dans ce cas, vous cumulez les désagréments courants tout en devant donner des explications aux utilisateurs, sans compter les problèmes de saturation du serveur SMTP et les journaux d'activité regorgeant d'informations tristement inutiles.
L'élimination du spam est avant tout une affaire de comportement de la part des utilisateurs. Laisser traîner son adresse réelle sur un site Web, remplir des formulaires d'inscription en ligne. utiliser les services du type -envoyer cet article à un ami", sont autant de choses à éviter. Cependant, une fois que le mal est fait, il faut se débarrasser du problème dans la mesure du possible. On ne peut en effet changer d'adresse email chaque mois sans perdre le contact avec bon nombre de correspondants humains et peu vénaux.
Heureusement pour nous, tous les MTA (Mail Transfer Agents) possèdent des capacités de filtrage permettant de limiter l'acceptation de mails comme nous l'avons vu dans un article précédent. Il est ainsi possible de refuser tout message provenant qu'une machine arbitraire ou d'une IP déterminée. Le spam est formellement interdit par la plupart des providers Internet et autres fournisseurs d'accès. Les spammeurs utilisent donc leurs propres serveurs SMTP ou des machines permettant de faire office de relais pour dissimuler la provenance du spam.
Le problème de l'Open Relay
Dans l'article d'introduction, nous avons parlé d'une directive host_accept_relay permettant de désigner le nom de machine ou la fourchette d'adresses IP des machines étant autorisées à utili- ser le serveur SMTP pour l'expédition de messages. La configuration la plus classique pour un serveur SMTP est d'envoyer et de recevoir des messages pour un certain nombre de personnes et en particu- lier, celles se trouvant sur un LAN connecté à Internet via une machine précise. Si le serveur SMTP est relié à la fois sur le LAN et Internet, il conviendra d'utiliser un masque comme 192.168.0.0/24 par exemple.
Les problèmes surviennent lorsque cette limitation n'est pas définie. Il arrive en effet qu'il soit nécessai- re de configurer le serveur de manière à ce qu'il accepte d'envoyer des messages pour des utilisa- teurs répartis un peu partout sur Internet. Dans ce genre de situation, la tentation d'utiliser une ligne comme host_accept relay=0 .0.0.0/0 est gran- de et malheureusement rapidement fatale.
En configurant de la sorte votre serveur SMTP, vous ouvrez la porte aux spammeurs. Vous avez confiniré votre serveur en Open Relay, c'est-à-dire en relais SMTP ouvert que tous les utilisateurs peu- vent employer à souhait.
En dehors du fait de limiter le nombre d'hôtes autorisés à utiliser votre serveur, vous pouvez employer une technique consistant à demander aux utilisateurs de s'authentifier par un mot de passe. Ceci vous permettra de facilement gérer les connexions SMTP de n'importe quelle provenance tout en ne laissant pas votre serveur ouvert.
Pour configurer exim de manière à gérer le type de fonctionnement, nous ajouterons en plus de notre ligne host accept relay une nouvelle ligne défi- nissant la manière de réagir si un client utilisant une autre adresse IP voulait envoyer un message avec notre serveur :
host_auth_accept_relay
ATTENTION: Dans le fichier de configuration par défaut installé par notre Debian Potato existent en commentaire deux exemples de configuration pour une authentification des utilisateurs. Nous avons remarqué une source de problème potentiel dans ce fichier. En effet, la dernière ligne non commentée concerne les règles de réécriture. Or, en décommen- tant simplement les lignes en fin de fichier de confi- guration, exim considérera que le mécanisme d'au-
thentification est en réalité une règle de réécriture. Il nous faut donc ajouter une directive end avant les lignes en commentaire pour clore la portée des règles de réécriture.
Nous définissons que n'importe quel hôte client peut demander à être authentifié auprès de notre serveur. Bien sûr, la transaction n'aura lieu que si l'authentification réussit. Il faudra ensuite définir le type d'authentification à utiliser. Le premier type est le mécanisme d'authentification Plain (RFC 2595) :
fixed_plain:
driver plaintext
public_name PLAIN
server_condition    ${if and
{{eg($2}{ph10}}{eq{$3}{secret} I I(yes}{no}l server_set_id = $2
Nous définissons une condition selon laquelle le login et le mot de passe à utiliser sont fixes (f ixed_plain). Ici le login est "ph10" et le mot de passe "secret". Si la condition est vérifiée (yes), l'authentification est réussie. Le client SMTP devra, au moment de la connexion, s'authentifier et passer à notre serveur les informations encodées en base 64 sous la forme [caractère NUL ]phlO[caractère NUL ]secret,    ce qui    nous    donne
AHBoMTAAc2VjcmVO.
Nous pouvons ensuite immédiatement tester le sys- tème d'authentification avec un simple telnet Connected to egon.
Escape character is
220 egon ESMTP Exim 3.12 #1 Tue, 05 Feb 2002 16:39:58 +0100
EHLO morgane
250-egon Hello denis at morgane [192.168.0.10] 250-SIZE
250-PIPELINING
250-AUTH PLAIN
250 HELP
AUTH PLAIN AHBoMTAAc2VjcmV0 235 Authentication succeeded QUIT
221 egon closing connection Connection closed by foreign host.
Les lignes en gras concernent successivement
•    la connexion au serveur SMTP ;
•    la notification des mécanismes mis à disposition par le serveur ;'
•    notre ligne d'authentification AUTH PLAIN [login et mot de passe formaté en base 64] :
•    enfin, la réponse du serveur confirmant le succès

de l'authentification.
Ce mécanisme d'authentification est normalement supporté par la plupart des applications mails gérant directement les connexions SMTP. C'est par exemple le cas de Netscape Messenger. Bien sûr, il existe toujours des applications réfractaires aux standards d'usage et aux RFC courantes. C'est le cas par exemple d'un client mail largement utilisé sur la plateforme Windows : Outlook Express.
Ce client ne reconnaît pas l'authentification RFC 2595 et utilise en lieu et place un mécanisme où le serveur doit demander sous la forme d'une invite Username: et Password: les éléments d'authentification. Si certains de vos utilisateurs ont fait le choix d'utiliser ce client mail, vous devrez configurer exim de manière à ce qu'il devienne compatible :
fixed_login:
driver = plaintext
public_name LOGIN
server_prompts User Name : Password server_condition    \
${if and {{eq{$1}{ph10}}{eq{$2}{secret}}}(yes){no}} server_set_id = $1
Ceci est l'équivalent de la configuration précédente, mais utilisant le mécanisme d'authentification Login. Il est, bien sûr, possible de faire cohabiter les deux systèmes d'authentification comme le montre le test avec t elnet :
Connected to egon.
Escape character is
220 egon ESMTP Exim 3.12 #1 Tue, 05 Feb 2002 17:15:59 +0100
EHLO morgane
250-egon Hello denis at morgane [192.168.0.10] 250-SIZE
250-PIPELINING
250-AUTH PLAIN LOGIN
250 HELP
AUTH LOGIN
334 VXN1ciBOYW11
cGgxMA==
334 UGFzc3dvcmQ=
c2VjcmV0
235 Authentication succeeded
QUIT
221 egon closing connection
Connection closed by foreign host.
Comme précédemment, les lignes en gras signalent les informations importantes :
•    Le serveur nous informe qu'il dispose des mécanismes d'authentification PLAIN et LOGIN.
•    Nous choisissons l'authentification par login.
•    Le serveur nous demande notre Username: (en base 64).
•    Nous lui répondons "ph 10" toujours en base 64.
•    Il demande le mot de passe correspondant.
•    Nous nous authentifions en lui répondant "secret" en base 64.
•    Et l'authentification réussit !
Attention : Les deux mécanismes d'authentification que nous venons de décrire ne représentent qu'une solution pour éviter l'Open Relay avec des clients non sédentaires. Il ne s'agit en aucun cas d'un système permettant d'ajouter une sécurité dans les transactions entre client et serveur. Ce n'est d'ailleurs pas le but de l'authentification. L'encodage en base 64 n'est pas un chiffrement des informations d'authentification. Un utilisateur "écoutant" le réseau pourra parfaitement reproduire le dialogue entre client et serveur. Ne vous repliez donc pas derrière ce genre de mécanisme en guise de sécurisation du serveur. Si vous souhaitez réellement sécuriser les transactions, utilisez un tunnel (voir article sur stunnel).
Quitte à vous lasser. disons-le encore une fois : laisser un système en Open Relay est très dangereux. Non seulement n'importe qui peut utiliser votre serveur SMTP, mais il faut également savoir qu'un certain nombre de serveurs SMTP à qui vous ou vos utilisateurs enverront des messages, testeront votre configuration. Si vous êtes en Open Relay, il y a de fortes chances que vous soyez placé sur une liste noire de serveurs dont il ne faut rien accepter. Ce dernier avertissement est l'occasion d'introduire le prochain chapitre de l'article : les Realtime Blackhole Lists.
Les Realtime Blackhole Lists
Les Realtime Blackhole Lists ou Realtime Blocking Lists, ou encore plus généralement appelée RBL sont des serveurs référençant les adresses des serveurs connus pour spammer des utilisateurs à travers le monde. Ces serveurs sont enregistrés dans un serveur DNS que votre serveur SMTP peut consulter lorsqu'il reçoit une connexion externe. S'il existe une entrée correspondante sur le serveur DNS du RBL, le message pourra être rejeté (en fonction de ce que vous aurez configuré). La liste des serveurs est régulièrement mise à jour et complétée via des réclamations d'utilisateurs spammés.
Votre fournisseur d'accès à Internet dispose sans doute d'une adresse abuse@... permettant de signaler le comportement outrageusement/sauvagement commercial de spammeurs. Si le ou les administra- teur(s) chez votre fournisseur d'accès sont compé- tents et soucieux du bien-être de leur client, ils feront sans doute les démarches adéquates. Dans le cas contraire, vous pourrez contacter directement les responsables de la RBL que vous utilisez.
Le plus connu et le plus utilisé des systèmes anti- spam de ce type est le MAPS RBL (Mail Abuse Prevention System Realtime Blackhole List). Il exis- te d'ailleurs des lignes prédéfinies (en commentaire) dans le fichier de configuration par défaut d'exim: rbl_domains rbl.maps.vix.com
rbl_reject_recipients false
rbl_warn_header true
Le simple fait de "décommenter" ces trois lignes dans le fichier de configuration aura pour effet de rejeter systématiquement tous les messages en pro- venance d'adresses IP présentes dans la RBL MAPS. Nous pouvons également ajouter quelques paramètres utiles comme recipients_reject_except -= postmaster@monsite.com qui définira une adresse acceptant les messages provenant d'un serveur sur la liste noire. Ceci permettra à l'administrateur de la machine prise en faute de s'informer sur les rai- sons du rejet.
ORBI
ORBL signifie Open Relay Black List. L'utilisation de ce type de liste est une technique bien plus violente qu'une simple RBL. Ici, ce sont tous les serveurs SMTP en Open Relay qui seront sur la liste noire. Là encore, une ORBL est une liste régulièrement tenue à jour et regroupant des adresses IP et des noms de machine étant SMTP en Open Relay. Accepter ou non de recevoir des messages en fonc- tion des entrées dans une telle base est une méthode brutale consistant à refuser tout message provenant d'un serveur SMTP, même dans le cas où il n'a jamais servi à envoyer du spam. Dans la plupart des cas, aucune différence n'est faite entre les gros pro- viders Internet et de simples machines d'entreprises ou de particuliers. Il y a moins d'un an, le principal fournisseur français (Wanadoo) s'est vu "black listé" de la sorte car un de ses serveurs était en Open Relay. Les serveurs SMTP faisant usage d'une telle liste refu- saient donc systématiquement tous les messages en provenance du principal fournisseur d'accès français. Le choix d'utiliser ou non une telle liste est difficile car,
d'un côté, vous vous protégez du mieux possible contre les spammeurs, mais d'un autre, vous risquez de péna- liser les expéditeurs "normaux-.
Une dernière solution du même tenant est d'utiliser via un filtre un script vérifiant si le serveur d'où provient le message est en Open Relay. Ceci est rela- tivement facile à faire puisque, manuellement. un simple telnet suffit :
Connected to egon.
Escape character is
220 egon ESMTP Exim 3.12 #1 Tue, 05 Feb 2002 18:01:34 +0100
EHLO morgane
250-egon Hello denis at morgane [192.168.0.10] 250-SIZE
250-PIPELINING
250-AUTH PLAIN LOGIN
250 HELP
MAIL FROM: denis <deniemonsite.com>
250 <deniemonsite.com> is syntactically correct RCPT TO: denis <denis@monsite.com>
550 relaying ta <denis@monsite.com> prohibited by administrator
QUIT
221 egon c1osing connection
Connection closed by foreign hast.
Comme ici, une connexion telnet sur le port SMTP (25) d'un serveur où nous tentons de nous envoyer un mail doit conduire à une erreur 550 : un refus de relais. Si la dernière commande (RCPT TO: ...) retourne un 250, le serveur est en Open Relay, et donc potentiellement capable d'être utilisé libre- ment par un spammeur.
Terminons en signalant qu'une ORBL se configure de la même manière qu'une RBL dans exim. Il vous suffira d'utiliser les paramètres donnés par le serveur que vous souhaitez utiliser. Vous le voyez, lutter contre le spam n'est pas forcément facile. Il est très malheureux que ce genre de pratiques commerciales existe. mais nous n'y pouvons rien. Il y a fort à parier que cela n'ira qu'en s'aggravant car de plus en plus de personnes se connectent chaque jour à Internet, venant ainsi grossir la liste des victimes des spammeurs...