Serveur de Messagerie
M3204-SEANCE03-Lutte Anti Spams
Patrice Gommery – Septembre 2021
Consignes Générales pour le TP
Votre serveur virtuel (VPS) est hébergé sur le serveur Proxmox de la salle réseau.
Il est accessible en SSH avec la commande : ssh root@172.16.VM.ID Pendant tout le TP, remplacez VMID par le numéro de votre VPS
Prérequis: Test de fonctionnement
Normalement, votre serveur de messagerie est complètement fonctionnel et vous possédez une adresse email personnalisée dans votre domaine : pnom@domVMID.net
Commencez par reconfigurez le client de messagerie Claws-Mail sur votre poste de travail avec cette adresse. Pour vérifier que tout est OK, envoyez un mail à un de vos camarades et attendez sa réponse pour continuer le TP.
Si cela ne fonctionne pas, reprenez les TP précédents et essayez de régler le problème.
Si tout est OK, allez écrire votre adresse email au tableau
Partie 1 : Les Spams
Cette partie du TP va se concentrer à un des « fléaux » de la messagerie moderne : LE SPAM ou courrier indésirable appelé aussi : pourriel.
Pour illustrer ce qu’est un spam, rien de tel que de comprendre comment est fabriqué un tel message. Pour cela nous allons utiliser un script qui sera chargé d’envoyer des mails à vos différents utilisateurs de façon automatique.
DEMONSTRATION :
Connectez-vous en ftp au serveur 172.16.100.1 (login mmis3, PASSWORD) et téléchargez le fichier : testspam.sh qui se trouve dans mmis3/scripts Rendez-le exécutable à l’aide la commande : chmod 750 testspam.sh
Pour l’exécuter, utilisez la syntaxe : ./testspam.sh (avec le point et / devant).
Le script vous demande alors les informations suivantes :
• Le nom du serveur de mail que vous voulez utiliser pour envoyer les pourriels : mail.domVMID.net (REMARQUE, vous n'êtes pas obligé d'utiliser le vôtre)
• L’adresse email de l’expéditeur qui sera utilisée pour l’envoi des pourriels.
Cette adresse peut être n’importe quelle adresse du moment qu’elle est au format nom@domaine.tld.
Elle peut correspondre à une adresse réelle sur Internet, comme par exemple votre adresse email étudiante : prenom.nom@etudiant.univ-reims.fr
ou à une adresse comme : batman@gotham.fr
• L'adresse email d'un destinataire (demandez la sienne à votre voisin) Pour l'instant nous n'allons "spammer" que lui, mais patientez ...
• Un sujet : Il n’est pas obligatoire mais cela vous permettra de repérer le message dans votre boite aux lettres (vous risquez d'en recevoir beaucoup pendant ce TP).
• Un contenu : N’importe quel texte mais sur une seule ligne.
C’est le corps de votre pourriel.
Après avoir validé la ligne de contenu, une connexion Telnet sera établie sur le port 25 du serveur de mail désigné en premier. Cette connexion enverra un message à votre voisin (ou à l'étudiant dont vous aurez mis l'adresse de destination).
Quelques explications sur le script :
Le script a généré un fichier spam.tmp dans le répertoire d’où il a été lancé. Vous pouvez ouvrir ce fichier à l’aide de l’éditeur de texte. Vous pouvez constater qu’il ne contient que des commandes destinées au serveur SMTP (Les commandes utilisées dans le premier TP) :
• HELO pour se présenter au serveur
• MAIL FROM :<Adresse Mail> pour désigner l’expéditeur
• RCPT TO :<Adresse Mail> pour désigner un destinataire
• DATA pour commencer la saisie du message lui-même (terminé par [.] et [Entrée])
Dans la section DATA on retrouve le contenu mais aussi des mots clés comme subject qui correspond au sujet du message.
• QUIT pour terminer la connexion avec le serveur.
Ce fichier est réutilisable avec la syntaxe : telnet mail.domVMID.net 25 < spam.tmp mail.domVMID.netdésignant le serveur servant de relais pour le spam
25 son n° de port (SMTP par défaut)
Vous pouvez donc modifier ce fichier pour renvoyer d’autres pourriels en modifiant le nom de présentation de votre machine (HELO super-spam), l’adresse email de
l’expéditeur , le sujet et le contenu du message. Mais vous pouvez aussi ajoutez des destinataires, il suffit de dupliquer la ligne de la commande RCPT TO: (Ctrl+K et CTRL+U sous nano)
EXERCICE : Modifiez le fichier spam.tmp pour qu'il envoi des spams à votre adresse mail personnalisée (pnom@domVMID.net), ainsi qu'à quelques-uns de vos camarades
(les emails sont écrits au tableau).
L'expéditeur , le sujet et le contenu de votre "spam" sont libres, mais restez correct.
Ne modifiez pas le HELO super-spam pour l'instant.
EN UTILISANT CLAWS-MAIL et votre adresse personnalisée
Envoyez une copie de votre fichier spam.tmp à prof@domprof.net avec comme sujet de message : SPAMS VMID
Voilà, vous savez maintenant comment on envoie simplement un spam avec quelques lignes de commandes, mais pourquoi cela fonctionne-t-il ? Tout simplement parce que vos serveurs mails ne sont pas protégés et acceptent des mails provenant de n’importe quel domaine sans aucune vérification.
Partie 2 : Identification des Spams
Envoyez des spams, n'est donc pas si compliqué, mais comment faire pour les identifier ? Vous connaissez déjà la réponse : En analysant les en-têtes des messages.
Ouvrez les entêtes d'un des supposés "spams" que vous avez dû recevoir de vos camarades.
Quelles incohérences pouvez-vous constater ? A part le fait que peut-être le serveur smtp initial n'est pas dans le même domaine que l'adresse mail de l'expéditeur (ce qui ne prouve rien en soit), il n'est pas évident d'identifier clairement le spam.
Alors, comment lutter contre ce fléau ? Une solution (parmi d'autres) , bloquer les mails dès leur arrivée sur votre serveur en renforçant la sécurité et en filtrant les mails en fonction de leur respect des recommandations (chiffrement, présentation d'enregistrement DNS spécifiques etc ...)
Partie 3 : Anti-Spam
3a) EXPLICATIONS
Maintenant que nous comprenons mieux comment notre boite aux lettres est "spammée", essayons de paramétrer notre serveur POSTFIX pour limiter le relais de ces messages indésirables.
Ces restrictions vont se baser sur les informations transmises par le client (en fait le serveur SMTP sur lequel la connexion telnet précédente a été faite) :
• Adresse IP du client ou nom d’hôte obtenu par résolution inverse (le fichier .rev du DNS).
• Adresse IP ou nom du client mentionné dans la commande HELO.
• Adresse mail de l’expéditeur mentionné dans la commande MAIL FROM.
• Adresse mail du destinataire mentionné dans la commande RCPT TO.
Elles définissent des règles de contrôle qui découleront sur des actions de rejets (REJECT) ou de permissions (PERMIT). On peut distinguer trois types de règles :
• Règle simple : règle appliquée à la syntaxe, la résolution DNS
• Règle par table désigne un contrôle faisant référence à une table indexée (fichier externe)
• Classe de restrictions pour désigner un ensemble de règles portant sur une même zone de contrôle (HELO, MAIL FROM, RCPT TO, …)
Lors du traitement d’un mail, POSTFIX compare l’information reçue avec chacune des règles présentes dans une classe de restrictions et prend une décision en fonction du résultat (condition vérifiée ou pas).Il existe principalement trois types de décisions :
• OK ou PERMIT si la règle est de type permit_ et que la condition est vérifiée le mail est accepté par cette classe de restrictions et les autres règles de la classe ne sont pas évaluées. Le mail peut encore être refusé par les restrictions d’une autre classe.
• REJECT : le mail est rejeté et aucune autre règle ne sera vérifiée, même dans une autre classe de restrictions.
• DUNNO : Pas de décision sur le test en cours (aucune condition ne s’applique au mail). On passe à la règle suivante.
Dans le cas d’une règle par table d’autres décisions peuvent être prises :
• HOLD : le mail sera automatiquement mis dans la file d’attente hold.
Il ne pourra en sortir que par une action de l’administrateur. (postsuper)
• DISCARD : le mail n’est pas traité. Le destinataire ne le reçoit pas, mais l’expéditeur reçoit quand même une notification de bonne remise.
• 5xx [texte] : le mail est rejeté avec le code spécifié et éventuellement un texte expliquant le refus.
Il existe d’autres actions (4xx, BCC, DEFER_IF_PERMIT, …). Vous pouvez obtenir le détail de ces actions avec une commande man access. Cette même commande donne aussi d’autres détails sur le fonctionnement des tables.
3b) RESTRICTIONS GENERIQUES
Appliquons maintenant quelques règles de restrictions :
Toutes les lignes suivantes seront à rajouter dans le fichier /etc/postfix/main.cf
#restrictions
smtpd_helo_required = yes strict_rfc821_envelopes = yes
N'oubliez pas de rechargez la configuration de POSTFIX avec la commande postfix reload
Ces deux restrictions vont vérifier que l’envoi du mail commence bien par HELO et que les adresses mail respectent la RFC 821. Dans le cas contraire c’est un rejet systématique du message qui sera appliqué.
Modifiez le fichier spam.tmp en changeant simplement l’expéditeur derrière
MAIL FROM par toto@domVMID.net afin de repérer facilement ce message dans les logs. Conservez votre adresse personnalisée comme destinataire.
Exécutez de nouveau la commande telnet mail.domVMID.net 25 < spam.tmp
Vérifier dans Claws-Mail que vous n’avez reçu aucun message.
Dans le cas contraire, vérifiez votre fichier main.cf et rechargez POSTFIX.
Si vous ne recevez rien, c’est normal :
Une des deux restrictions précédentes a été appliquée et a rejeté votre message.
Pour voir ce qui s'est passé, ouvrez le fichier /var/log/mail.log et cherchez les lignes contenant le nom de votre expéditeur toto@domVMID.net
Exemple de commande à saisir pour voir les logs : cat /var/log/mail.log | grep toto@domVMID.net Le résultat de la commande doit ressembler à ceci :
Sep 17 14 :58 :39 poste1 postfix/smtpd[2725] : warning : illegal address syntax from unknown[172.16.1.1] in MAIL command : toto@domVMID.net
Cette entrée dans le fichier de log nous montre que l’adresse toto@domVMID.net n’est pas valide car elle ne respecte pas la syntaxe de la RCF821. Le message n’a donc pas été traité par le système. La bonne syntaxe pour une adresse email respectant la RFC821 doit être encadrée par les signes < et > ce qui donnerait : < toto@domVMID.net >.
Modifiez le fichier spam.tmp en corrigeant l’adresse de l’expéditeur derrière MAIL FROM ainsi que celles de tous les destinataires derrière RCPT TO.
Exécutez de nouveau la commande telnet mail.domVMID.net 25 < spam.tmp et vérifiez que vous avez de nouveau reçu le message (celui respectant maintenant la norme).
3c) FILTRAGE sur HELO
Nos premières restrictions n’ayant pas eu beaucoup d’impact sur le spam, rajoutons d’autres restrictions dans notre fichier /etc/postfix/main.cf
ATTENTION un espace minimum est obligatoire devant les lignes « reject » et « permit » sinon elles seront considérées comme de nouvelles commandes.
#Vérification du HELO smtpd_helo_restrictions =
permit_mynetworks, (ne pas saisir cette ligne) reject_non_fqdn_hostname,
reject_invalid_hostname, permit
Ces lignes décrivent les règles à appliquer sur la classe HELO. L’ordre des règles est important puisque dès qu’une condition est vérifiée on arrête le traitement de la classe, voir du message dans le cas d’un rejet.
Nous ne saisissons pas la condition permit_mynetworks dans notre cas car elle laisserait passer tous les messages dans notre configuration. Cette condition fait en effet référence à la directive mynetworks du fichier main.cf qui indique quels sont les réseaux dont les
machines sont autorisées à déposer sur notre serveur. Toutes nos machines étant sur le réseau 172.16.0.0, cette règle n’a aucun intérêt pour nous.
reject_non_fqdn_hostname et reject_invalid_hostname: rejetteront tous les clients indiquant dans la commande HELO un nom d’hôte non conforme au format FQDN (nom.domaine.tld).
Rechargez de nouveau POSTFIX pour accepter les modifications.
Exécutez de nouveau la commande telnet mail.domVMID.net 25 < spam.tmp
La commande HELO étant suivi pour l’instant du nom super-spam vos messages devraient être rejetés par la règle reject_invalid_hostname.
Modifiez de nouveau le fichier spam.tmp afin de pouvoir continuer à envoyer des spams.
Remplacez super-spam par le nom DNS de votre serveur : mail.domVMID.net
ATTENTION : La restriction s'applique aussi à Claws-Mail qui par défaut ne formate pas correctement la balise HELO. Pour corriger le problème, dans Claws-Mail, modifiez la configuration de votre compte courant : Dans la partie avancée, Cochez l'option Nom de Domaine et renseignez le champ avec : domVMID.net
3d) FILTRAGE sur MAIL FROM
La classe concernée est smtpd_sender_restrictions. Les règles suivantes vont s’appliquer sur l’adresse mail de l’émetteur précisée derrière la commande MAIL FROM.
#Vérification du MAIL FROM smtpd_sender_restrictions =
permit_mynetworks, (ne pas saisir cette ligne) reject_unverified_sender,
permit
La seule règle présente ici reject_unverified_sender rejette tous les messages dont l’expéditeur n'est pas un de vos utilisateurs.
Rechargez de nouveau POSTFIX pour accepter les modifications.
Testez ces règles comme précédemment : telnet mail.domVMID.net 25 < spam.tmp
Vérifiez que vous n'avez rien reçu et regardez les logs ( /var/log/mail.log )pour voir que c'est bien cette règle qui bloque vos spams.
toto@domVMID.net n'étant un pas un de vos utilisateurs, vous ne devriez pour l'instant plus pouvoir envoyer de spams.
Pour contourner le problème, créez une nouvelle boite aux lettres nommée toto@domVMID.net et testez de nouveau l'envoi de nouveaux spams.
3e) FILTRAGE sur RCPT_TO
La classe concernée est smtpd_recipient_restrictions. Les règles suivantes vont s’appliquer sur l’adresse mail du destinataire précisé derrière la commande RCPT TO.
Par défaut notre serveur n’accepte que les mails qui lui sont destinés, mais il peut être amené à relayer ces mails vers un autre serveur si celui-ci l’y autorise.
C’est le cas de nos serveurs qui étant sur le même réseau accepte des mails à destination des autres domaines.
#Vérification du RCPT TO smtpd_recipient_restrictions =
permit_mynetworks, (ne pas saisir cette ligne) reject_unauth_destination,
permit
La règle reject_unauth_destination va rejeter tous les mails dont les domaines destinataire ne sont pas listés dans les directives : mydestination, virtual_alias_maps et virtual_mailbox_maps et relay_domains du fichier main.cf.
En activant cette règle, vous empêcherait alors toute tentative de spam à partir de votre serveur, mais cela ne l’empêchera pas d’en recevoir. Autre conséquence, vos utilisateurs légitimes ne peuvent plus envoyer de mail vers un autre domaine non plus !!!
Modifiez le fichier spam.tmp en ajoutant des destinataires externes à votre domaine.
Testez et vérifiez dans le fichier /var/log/mail.log que ceux-ci n’ont pas été relayé
Pour continuer, ajouter la Directive suivante dans votre fichier main.cf relay_domains = domprof.net, domVM10.net,.., domVM26.net,
(ajoutez uniquement domprof.net et les domaines domVMID.net que vous voulez atteindre, ne mettez pas le vôtre, il est déjà déclaré dans $mydestination)
Avant de continuer, envoyez en pièce jointe une copie de votre fichier main.cf à : prof@domprof.net avec comme sujet de message : BLOCAGES VMID
4f) FILTRAGE avec une table
Comme vous avez pu le voir précédemment, pas facile de trouver des règles qui répondent à toutes les problématiques et à l’environnement de chacun. Certaines règles sont trop
restrictives, d’autres pas assez. Normal puisqu’elles ne s’appliquent pas à des cas particuliers mais à des généralités. Dans la pratique, il faut donc faire très attention à ne pas trop restreindre le service au point de ne plus rien recevoir ou ne plus pouvoir rien envoyer.
Les règles basées sur des tables permettent de personnaliser un peu plus les restrictions en ne les appliquant qu’à des cas précis et en permettant même le choix de l’action à réaliser.
Voici un exemple de règle basée sur une table ne permettant la réception sur notre serveur que de mail venant de certains utilisateurs en particulier (les nôtres et quelques autres).
Rajouter cette ligne dans la classe smtpd_sender_restrictions : check_sender_access hash:/etc/postfix/sender_list,
Créez un fichier sender_list dans le répertoire /etc/postfix ressemblant à ceci :
domVMID.net OK
domVMXX.net REJECT
domVMYY.net REJECT
domVMZZ.net OK
mickey@disneyland.fr REJECT
prof@domprof.net OK
Placez-vous dans le dossier /etc/postfix et tapez la commande postmap sender_list
Cette commande génère un fichier sender_list.db qui est le hash du précédent.
Relancez POSTFIX et testez des envois de mail avec différentes adresses derrière la commande MAIL FROM.
Pour terminer, envoyez en pièce jointe une copie de sender_list,
à : prof@domprof.net avec comme sujet de message : SENDERS VMID ET APRES
Ceci n’est bien sûr qu’un aperçu des possibilités de POSTFIX en tant que MTA pour notre messagerie. Pour aller plus loin, vous pouvez consulter la documentation.
Pour l’installer : apt-get install postfix-doc
Pour la lire ouvrez le navigateur et allez sur l’URL : /usr/share/doc/postfix/html
La partie de référence pour ce TP se trouve dans RESTRICTIONS_CLASS_README.
A partir de cette page , vous pouvez consulter toutes les règles propres à une classe.
NOTATION DU TP :
1 PTS - Mail SPAMS VMID avec fichier spam.tmp modifié
2 PTS - Mail 1 OK + Mail BLOCAGES VMID avec fichier main.cf modifié correctement 3 PTS - Uniquement si les 2PTS précédents sont acquis
+ Mail SENDERS VMID avec fichier sender_list
