212 lines
17 KiB
Markdown
212 lines
17 KiB
Markdown
# Instructions détaillées
|
||
|
||
Le démonstrateur démarre un serveur Web sur le port 8080, accessible à tous par défaut.
|
||
|
||
Dans un navigateur, connectez-vous à l’adresse de la machine, port 8080. Vous devriez obtenir une page d’accueil. Cliquez sur le bouton « Commencer ».
|
||
|
||
Vous arrivez alors sur une page « dashboard ». Un menu en haut de la page propose des sous-menus nommés « Attaquant », « Expéditeur » et « Destinataire ».
|
||
|
||
Pour relever les courriels du côté du destinataire, utilisez l’identifiant **destinataire** et le mot de passe **PasSecretDuTout**. Vous devriez alors arriver sur une boîte mail entièrement vierge.
|
||
|
||
## La fausse confirmation de commande
|
||
|
||
Vous êtes le DSI d’une entreprise de savonnettes. Cette entreprise a une présence en ligne et un site Web qui permet de commander des produits. L’entreprise envoie des mails pour deux cas d’usage : pour informer de l’avancement de la commande d’un client, et pour envoyer des newsletters.
|
||
|
||
Depuis peu, une campagne de hameçonnage usurpant votre identité vous cause du fil à retordre. Un attaquant est parvenu à imiter vos courriels de confirmation de commande. Il en profite pour envoyer à ses victimes des courriels frauduleux très convaincants car ils vont même jusqu’à reprendre l’adresse de l’expéditeur ! Ces confirmations de commande, qui font croire à une commande pour des milliers d’euros de produits, sont conçues pour faire peur et pousser la victime à cliquer sur le lien d’annulation présent dans le mail et remplir ses informations de carte bancaire.
|
||
|
||
Que faire pour arrêter cette campagne de hameçonnage ?
|
||
|
||
### Envoi d’un courriel légitime
|
||
|
||
Tout d’abord, pour tester le système, envoyez un courriel de confirmation de commande légitime en utilisant l’infrastructure de l’expéditeur :
|
||
|
||
1. Dans le menu, cliquez sur **Expéditeur** > **Envoyer un message légitime**.
|
||
|
||
2. Dans la boîte intitulée **Confirmation de commande**, cliquez sur **Envoyer**.
|
||
|
||
3. Dans le message de confirmation qui est apparu, cliquez sur le bouton **Relever les courriels du destinataire**.
|
||
|
||
4. Renseignez l’identifiant **destinataire** et le mot de passe **PasSecretDuTout** si vous ne l’avez pas déjà fait. Vous devriez y voir un nouveau message : une confirmation de commande pour une savonnette.
|
||
|
||
### Envoi d’un mail frauduleux
|
||
|
||
Il est maintenant temps de passer du côté de l’attaquant et d’envoyer votre premier courriel frauduleux.
|
||
|
||
Dans le menu, cliquez sur **Attaquant** > **Envoyer des messages frauduleux**. L’outil « Usurpateur d’identité de courriel » comportant plusieurs réglages.
|
||
|
||
Le **scénario** permet de choisir la nature du courriel frauduleux que l’attaquant doit envoyer.
|
||
|
||
Le champ **HELO/EHLO** est utilisé dans le protocole SMTP par le serveur émetteur de courriel pour s’identifier auprès du destinataire. Il est courant que des systèmes destinataires rejettent des HELO/EHLO non valables.
|
||
|
||
Les champs **Adresse RFC5321.MailFrom** et **Adresse RFC5322.From** illustrent une subtilité dans le courriel : de la même façon qu’un courrier physique, on peut écrire une adresse à l’arrière de l’enveloppe qui ne corresponde pas nécessairement à l’adresse figurant sur le papier à en-têtes dans le contenu de l’enveloppe. Le second champ est fixe ; il s’agit d’une adresse prédéterminée par le scénario. Mais le premier champ est un menu déroulant qui permet de choisir entre une adresse identique au second ou une adresse différente.
|
||
|
||
Pour envoyer ce courriel frauduleux :
|
||
|
||
1. Dans le menu déroulant « Scénario », sélectionnez le scénario **Fausse confirmation de commande**.
|
||
|
||
2. Laissez le champ « HELO/EHLO » à « attaquant.example » et le champ « Adresse RFC5321.MailFrom » à « support@expediteur.example ».
|
||
|
||
3. Cliquez sur **Envoyer le message frauduleux**.
|
||
|
||
L’outil remet ensuite le courriel frauduleux au serveur du destinataire et vous pourrez voir que le message est accepté par le serveur destinataire. Ce faisant, les échanges, réalisés au moyen du protocole SMTP, sont affichés.
|
||
|
||
La première ligne, `220 mx.destinataire.example ESMTP Postfix`, indique que le serveur est prêt. Notez en particulier :
|
||
|
||
* la commande `MAIL FROM`, qui donne une adresse e-mail qui n’est pas celle de l’attaquant ;
|
||
* le corps du message, transmise après la commande `DATA`, qui contient une ligne `From` dont l’adresse e-mail est également fausse.
|
||
|
||
Et lorsque vous affichez la boîte de réception du destinataire, vous verrez qu’une fausse confirmation de commande a bien été remise dans la boîte de réception.
|
||
|
||
Vous venez de réaliser votre première usurpation d’identité !
|
||
|
||
### Installation de la politique SPF
|
||
|
||
Nous allons maintenant nous défendre contre ce scénario précis en déployant une politique SPF.
|
||
|
||
Avec SPF, nous allons spécifier que seul le serveur de `expediteur.example`, c’est-à-dire la machine qui a envoyé la vraie confirmation de commande, a le droit d’envoyer des courriels avec ce nom de domaine. Cela se fait en ajoutant une entrée TXT dans la zone `expediteur.example` dont le contenu suit les règles de SPF.
|
||
|
||
Pour cela :
|
||
|
||
1. Dans le menu, cliquez sur **Expéditeur** > **Éditer la zone DNS**. Un éditeur s’ouvre, affichant le contenu du fichier de zones pour `expediteur.example`.
|
||
|
||
2. Une politique SPF a été préparée pour ce nom de domaine, mais n’est pas encore active. Repérez la ligne située juste sous le commentaire `;; Politique SPF`, puis supprimez le caractère `;` en début de ligne pour activer la politique SPF.
|
||
|
||
3. Cliquez sur le bouton **Enregistrer et appliquer**. La zone DNS a été réactualisée.
|
||
|
||
4. Dans la barre de menu en haut de la page, cliquez sur « Tableau de bord ». Vous verrez désormais que dans la section « État des systèmes », une politique SPF est en vigueur pour `expediteur.example`.
|
||
|
||
**Remarque :** Les lecteurs avertis noteront qu’il faudrait aussi incrémenter le champ « numéro de série » dans l’entrée SOA. Pour simplifier les choses, le démonstrateur a été conçu pour que cette manipulation ne soit pas nécessaire. Par ailleurs, les TTL de toutes les entrées DNS servies dans ce démonstrateur est fixé à 0 pour que les effets soient visibles immédiatement, juste en rechargeant le fichier de zones.
|
||
|
||
### Activation du contrôle SPF chez le destinataire
|
||
|
||
Ce que vous venez de faire est la configuration nécessaire chez l’expéditeur.
|
||
|
||
Cependant, si vous réessayez d’envoyer le même courriel frauduleux via l’usurpateur d’identité de courriel, vous verrez que le message passe toujours. Comment est-ce possible ?
|
||
|
||
Vous avez certes installé une politique SPF pour `expediteur.example`, mais le serveur de courriels chez `destinataire.example` ne fait pas encore de contrôle de politiques SPF. Il s’agit d’activer cela. Pour ce faire, procédez ainsi :
|
||
|
||
1. Dans le menu, cliquez sur **Destinataire** > **Paramétrer le système**.
|
||
|
||
2. Cliquez sur l’interrupteur à gauche du texte « Activer le contrôle SPF », puis cliquez sur **Valider**.
|
||
|
||
### Victoire ?
|
||
|
||
En enfilant le chapeau de l’attaquant, essayez d’envoyer une fausse confirmation de commande avec les mêmes paramètres que plus haut. Vous verrez que les choses ne se passent plus comme prévu : le serveur de courriels du destinataire refuse désormais le message. En fait, l’attaquant n’a même pas l’occasion d’envoyer le contenu du courriel avec la commande `DATA`, car c’est l’adresse de l’expéditeur dans la commande `MAIL FROM` qui est contrôlée.
|
||
|
||
D’ailleurs, vous pouvez vérifier que les vraies confirmations de commande passent toujours : depuis le menu **Expéditeur** > **Envoyer un message légitime**, envoyez un autre courriel de confirmation. Vous le verrez apparaître quelques secondes plus tard dans la boîte de réception du destinataire.
|
||
|
||
Peut-on crier victoire ? Pas tout de suite. L’attaquant peut encore contourner cette mesure.
|
||
|
||
Sur un courrier physique, on peut écrire une adresse retour sur l’enveloppe et une adresse différente sur le papier à en-têtes qu’on glisse dans l’enveloppe. Un attaquant peut faire la même chose avec un courriel, ce qui a pour effet de contourner la protection que devait apporter SPF.
|
||
|
||
### Envoi d’un mail frauduleux avec une enveloppe différente ###
|
||
|
||
Pour voir cela en action, procédez ainsi :
|
||
|
||
1. Dans le menu, cliquez sur **Attaquant** > **Envoyer des messages frauduleux**.
|
||
|
||
2. Dans le menu déroulant « Scénario », sélectionnez le scénario **Fausse confirmation de commande**.
|
||
|
||
3. Laissez le champ « HELO/EHLO » à « attaquant.example ». En revanche, dans le menu déroulant « Adresse RFC5321.MailFrom », sélectionnez « usurpateur@attaquant.example ».
|
||
|
||
4. Cliquez sur **Envoyer le message frauduleux**.
|
||
|
||
Cette fois, le courriel est accepté par le serveur SMTP : l’attaquant a prétendu que le courriel frauduleux venait de chez lui dans l’enveloppe ; mais dans le courriel lui-même, visible après la commande DATA, l’attaquant se fait toujours passer pour le service client. De plus, c’est toujours l’adresse du service client qui apparaît dans les en-têtes que voit le destinataire dans son logiciel de courriels.
|
||
|
||
Pour se défendre contre cela, nous avons besoin de DMARC. DMARC requiert que l’expéditeur ait mis en place SPF, mais aussi DKIM. Nous allons donc installer DKIM dans un premier temps, puis mettre en place DMARC pour compléter notre protection.
|
||
|
||
### Génération de clefs DKIM ###
|
||
|
||
DKIM consiste à signer cryptographiquement le corps et certains en-têtes de courriels. Dans l’infrastructure de l’expéditeur, c’est le logiciel **opendkim** qui se charge d’insérer les signatures. Ce même logiciel est aussi responsable de la vérification des signatures DKIM chez le destinataire.
|
||
|
||
La première chose à faire est de générer des clefs DKIM chez l’expéditeur. On en génère deux : le premier est utilisé tout de suite et le second est une clef de réserve. Les clefs cryptographiques ont besoin d’être renouvelées régulièrement, donc lorsque la première clef est retirée du service, une troisième clef est générée et toutes les signatures se font avec la deuxième clef.
|
||
|
||
Générons des clefs DKIM pour le domaine `expediteur.example`. Pour cela, procédez ainsi :
|
||
|
||
1. Dans le menu, cliquez sur **Expéditeur** > **Afficher des clefs DKIM**. Vous constatez que la liste des clefs DKIM est vide.
|
||
|
||
2. Dans le menu, cliquez sur **Expéditeur** > **Générer des clefs DKIM**.
|
||
|
||
3. Dans le champ « Sélecteur », saisissez **demo1**.
|
||
|
||
4. Cliquez ensuite sur **Générer**. Une boîte devrait apparaître, contenant un texte à copier-coller dans le fichier de zones. Cliquez sur **Copier** pour copier l’entrée DNS dans le presse-papiers (si le texte du bouton « Copier » ne se change pas en « Texte copié », faites la copie manuellement).
|
||
|
||
5. Dans l’éditeur de la zone `expediteur.example`, collez le texte précédemment copié quelque part entre le commentaire `;; Clef publique DKIM` et le commentaire `;; Politique DMARC`. Validez les modifications.
|
||
|
||
6. Répétez les étapes 2 à 5 pour générer une autre clef DKIM ayant pour sélecteur **demo2**.
|
||
|
||
7. Dans le menu, cliquez sur **Expéditeur** > **Afficher des clefs DKIM**. Vous constatez maintenant que pour le domaine `expediteur.example`, deux clefs DKIM sont disponibles et la clef « demo1 » est active.
|
||
|
||
Le serveur Postfix de l’expéditeur est déjà configuré pour que les courriels sortants passent par **opendkim** avant d’être remis au serveur mail destinataire. Mais il faut aussi que le serveur de courriels du destinataire vérifie les signatures !
|
||
|
||
### Configurer la vérification DKIM et DMARC chez le destinataire ###
|
||
|
||
Nous allons faire d’une pierre deux coups et activer à la fois la vérification DKIM et DMARC chez le destinataire. Pour cela :
|
||
|
||
1. Dans le menu, cliquez sur **Destinataire** > **Paramétrer le système**.
|
||
|
||
2. Cliquez sur l’interrupteur à gauche du texte « Activer le contrôle DKIM ».
|
||
|
||
3. Faites de même pour « Activer le contrôle DMARC ».
|
||
|
||
4. Cliquez sur **Valider**.
|
||
|
||
### Essai de DKIM ###
|
||
|
||
Nous allons maintenant envoyer une nouvelle confirmation de commande, qui devrait désormais arriver dans la boîte de réception du destinataire munie d’une signature DKIM :
|
||
|
||
1. Dans le menu, cliquez sur **Expéditeur** > **Envoyer un message légitime**.
|
||
|
||
2. Dans la boîte intitulée **Confirmation de commande**, cliquez sur **Envoyer**.
|
||
|
||
3. Dans le message de confirmation qui est apparu, cliquez sur le bouton **Relever les courriels du destinataire**.
|
||
|
||
Vous devriez voir un nouveau courriel non lu chez le destinataire. Ouvrez-le, puis cliquez sur « En-têtes » pour visionner l’intégralité des en-têtes. Notez l’apparition de plusieurs nouveaux en-têtes.
|
||
|
||
Les en-têtes **Authentication-Results** ont été insérés par le système destinataire, au moment des contrôles SPF, DKIM et DMARC. Notez le `spf=pass`, `dkim=pass` et `dmarc=none` : cela signifie que le courriel a été émis par un serveur autorisé par la politique SPF, que la signature DKIM est bonne mais qu’il n’y avait aucune politique DMARC.
|
||
|
||
Vous devriez aussi voir un en-tête **DKIM-Signature**, contenant la signature DKIM.
|
||
|
||
### Configuration DMARC chez l’expéditeur ###
|
||
|
||
À ce stade, nous n’avons toujours pas contrecarré la campagne de hameçonnage que mène l’attaquant au moyen de ces fausses confirmations de commande. C’est là où DMARC entre en jeu.
|
||
|
||
Maintenant que le système destinataire contrôle SPF, DKIM et DMARC, nous pouvons protéger l’expéditeur en ajoutant une politique DMARC.
|
||
|
||
Pour configurer DMARC chez l’expéditeur :
|
||
|
||
1. Dans le menu, cliquez sur **Expéditeur** > **Éditer la zone DNS**.
|
||
|
||
2. Repérez la ligne `;; Politique DMARC`. Décommentez la ligne suivante en supprimant le caractère `;`. Changez le `p=none` en `p=reject`.
|
||
|
||
3. Validez les modifications.
|
||
|
||
### L’attaquant est-il vaincu ? ###
|
||
|
||
Voyons voir maintenant si les mails d’hameçonnage de l’attaquant passent encore. Faites un envoi d’e-mail frauduleux avec le scénario **Fausse confirmation de commande** et l’adresse RFC5321.MailFrom `usurpateur@attaquant.example`.
|
||
|
||
Cette fois, après que l’attaquant ait envoyé le mail complet, le serveur de courriels du système destinataire effectue le contrôle SPF, DKIM et DMARC. Le message ne passe pas le contrôle et est rejeté par le serveur : on peut le voir avec l’erreur `550 5.7.1 rejected by DMARC policy for expediteur.example`, vers la fin de la conversation.
|
||
|
||
Vous pourrez ensuite vérifier que les confirmations de commande authentiques passent encore.
|
||
|
||
## Et les sous-domaines ? ##
|
||
|
||
En effet, dans une adresse de courriel, on peut très bien avoir un sous-domaine à droite de l’arobase : les newsletters de l’entreprise de savonnettes sont par exemple envoyées avec l’adresse d’expéditeur `info@newsletter.expediteur.example`.
|
||
|
||
Mais la politique DMARC que vous venez d’installer a cassé les newsletters ! Si vous essayez d’envoyer une newsletter à ce stade, le courriel n’arrivera jamais (une limitation technique de la plate-forme fait qu’elle indique que le courriel a bien été envoyée, mais ne montre pas qu’elle a été bloquée par la politique DMARC de `expediteur.example`).
|
||
|
||
Pour corriger cela, il suffit de publier une politique SPF pour le sous-domaine `newsletter.expediteur.example` et de générer des clefs DKIM pour ce même sous-domaine. Il serait théoriquement possible d’utiliser les clefs de `expediteur.example` pour signer les courriels venant de `info@newsletter.expediteur.example`, mais ce n’est pas encore possible à cause d’une limitation technique de la plate-forme.
|
||
|
||
Bien entendu, vérifiez également que l’attaquant ne parvienne pas non plus à envoyer ses fausses newsletters ! Pour cela, sélectionnez le scénario **Fausse newsletter** dans l’outil d’usurpation d’identité de courriel.
|
||
|
||
## Et les courriels prétendant être envoyés depuis votre propre adresse ? ##
|
||
|
||
Le scénario **Extorsion** couvre, quant à lui, le cas d’un courriel prétendant être envoyé depuis votre propre adresse de courriel à vous-même : un stratagème utilisé dans certains spams d’extorsion pour faire croire que l’auteur du courriel a obtenu l’accès à votre compte de messagerie. Dans ce cas précis, il faut mettre en place SPF et DMARC chez `destinataire.example` (l’envoi de courriels est désactivé sur ce système, donc il n’y a pas besoin de mettre en place DKIM car il n’y a pas de courriel à signer).
|
||
|
||
|
||
## Conclusion ##
|
||
|
||
Vous avez maintenant vu par vous-même comment protéger le courriel contre l’usurpation d’identité dans les adresses d’expédition, y compris dans le cas plus complexe d’un sous-domaine.
|
||
|
||
L’élaboration d’une politique SPF peut s’avérer difficile en pratique, pour des raisons purement organisationnelles. En effet, il faut préalablement avoir fait un inventaire exhaustif de toutes les machines envoyant des courriels : en fonction de la taille d’une organisation, de son historique et de la présence ou non de prestataires d’envoi de courriels (aussi appelés « routeurs »), cela peut être plus ou moins difficile.
|