Mise à jour de la documentation
This commit is contained in:
Marc van der Wal
parent
9c8b6e3034
commit
ee989e3541
259
INSTRUCTIONS.md
259
INSTRUCTIONS.md
|
|
@ -1,58 +1,54 @@
|
||||||
# Instructions détaillées
|
# Instructions détaillées
|
||||||
|
|
||||||
## Démarrage et prise en main
|
Le démonstrateur démarre un serveur Web sur le port 8080, accessible à tous par défaut.
|
||||||
|
|
||||||
Le plus simple est de faire fonctionner le démonstrateur sur une machine virtuelle Linux dotée de Docker qui soit accessible en SSH.
|
Dans un navigateur, connectez-vous à l’adresse de la machine, port 8080. Vous devriez obtenir une page d’accueil. Cliquez sur le bouton « Commencer ».
|
||||||
|
|
||||||
Le démonstrateur démarre un serveur Web sur le port 8225. Pour des raisons de sécurité, ce service n’est accessible que sur la boucle locale de votre machine virtuelle. Pour pouvoir l’utiliser sur votre machine, il vous faut vous connecter à la machine qui exécute le démonstrateur à l’aide de la commande :
|
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 ».
|
||||||
|
|
||||||
$ ssh -L 8225:localhost:8225 <nom de votre machine>
|
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.
|
||||||
|
|
||||||
Vérifiez que Docker et `tmux` soient bien installées sur la machine exécutant le démonstrateur.
|
|
||||||
|
|
||||||
Rendez-vous dans le répertoire dans lequel vous avez cloné le dépôt Git du démonstrateur, puis démarrez l’environnement en exécutant le script `start.sh` :
|
|
||||||
|
|
||||||
$ ./start.sh
|
|
||||||
|
|
||||||
Vous devriez alors voir s’afficher une fenêtre comme celle-ci (TODO capture d’écran)
|
|
||||||
|
|
||||||
Notez la dernière ligne du terminal, qui indique une liste de fenêtres. Ce sont des onglets : vous pouvez cliquer sur l’un des cinq onglets (« Système », « Expéditeur », « Destinataire », « Attaquant », « DNS ») pour changer de point de vue.
|
|
||||||
|
|
||||||
Si la souris ne fonctionne pas, il est possible d’utiliser le clavier pour changer de fenêtre : pour cela, tapez **Ctrl+B**, relâchez toutes les touches, puis tapez le chiffre entre parenthèses (compris entre 0 et 4 inclus) correspondant au numéro de la fenêtre que vous souhaitez afficher.
|
|
||||||
|
|
||||||
En parallèle, dans un navigateur, ouvrez un nouvel onglet et connectez-vous à l’adresse <http://localhost:8225>. Vous devriez obtenir une page de connexion pour la webmail Roundcube. Connectez-vous avec 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
|
## La fausse confirmation de commande
|
||||||
|
|
||||||
Nous allons étudier le cas d’un attaquant qui usurpe l’identité de l’entreprise pour envoyer de fausses confirmations de commande. 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 bleue.
|
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.
|
||||||
|
|
||||||
### Envoi d’un mail légitime
|
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.
|
||||||
|
|
||||||
Tout d’abord, pour tester le système, envoyez un mail de confirmation de commande légitime en utilisant l’infrastructure de l’expéditeur :
|
Que faire pour arrêter cette campagne de hameçonnage ?
|
||||||
|
|
||||||
1. Dans le terminal, basculez sur la fenêtre **Expéditeur**.
|
### Envoi d’un courriel légitime
|
||||||
|
|
||||||
2. Exécutez le script d’envoi de mail de confirmation avec la commande `./scripts/send_confirmation_email.sh` (vous pouvez utiliser la touche **Tab** pour compléter les noms de fichiers et de répertoires).
|
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 :
|
||||||
|
|
||||||
3. Dans la boîte mail du destinataire devrait apparaître un nouveau message : une confirmation de commande pour une savonnette.
|
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
|
### Envoi d’un mail frauduleux
|
||||||
|
|
||||||
Il est maintenant temps de passer du côté de l’attaquant et d’envoyer votre premier courriel frauduleux. Pour cela :
|
Il est maintenant temps de passer du côté de l’attaquant et d’envoyer votre premier courriel frauduleux.
|
||||||
|
|
||||||
1. Dans le terminal, basculez sur la fenêtre **Attaquant**.
|
Dans le menu, cliquez sur **Attaquant** > **Envoyer des messages frauduleux**. L’outil « Usurpateur d’identité de courriel » comportant plusieurs réglages.
|
||||||
|
|
||||||
2. Exécutez le script de l’attaquant avec la commande `./scripts/send_email.py`.
|
Le **scénario** permet de choisir la nature du courriel frauduleux que l’attaquant doit envoyer.
|
||||||
|
|
||||||
3. Sélectionnez le scénario **Fausse confirmation de commande** en tapant **2** puis **Entrée**.
|
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.
|
||||||
|
|
||||||
4. Utilisez la même adresse dans l’enveloppe SMTP que dans le corps du mail : sélectionnez le choix **1**.
|
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.
|
||||||
|
|
||||||
5. Utilisez le HELO par défaut en tapant directement **Entrée**.
|
Pour envoyer ce courriel frauduleux :
|
||||||
|
|
||||||
6. N’ajoutez pas de signature DKIM en tapant directement **Entrée**.
|
1. Dans le menu déroulant « Scénario », sélectionnez le scénario **Fausse confirmation de commande**.
|
||||||
|
|
||||||
Le script remet ensuite le courriel frauduleux au serveur du destinataire. Ce faisant, le programme affiche les échanges au moyen du protocole SMTP.
|
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 première ligne, `220 mx.destinataire.example ESMTP Postfix`, indique que le serveur est prêt. Notez en particulier :
|
||||||
|
|
||||||
|
|
@ -71,61 +67,33 @@ Avec SPF, nous allons spécifier que seul le serveur de `expediteur.example`, c
|
||||||
|
|
||||||
Pour cela :
|
Pour cela :
|
||||||
|
|
||||||
1. Dans le terminal, basculez sur la fenêtre **DNS**.
|
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. Ouvrez le fichier de zones pour `expediteur.example` avec la commande :
|
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.
|
||||||
|
|
||||||
nano example/expediteur.zone
|
3. Cliquez sur le bouton **Enregistrer et appliquer**. La zone DNS a été réactualisée.
|
||||||
|
|
||||||
3. Utilisez les flèches du clavier pour atteindre la ligne repérée par le commentaire `;; Politique SPF`, puis supprimez le caractère `;` en début de ligne pour activer la politique SPF.
|
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`.
|
||||||
|
|
||||||
4. Sauvegardez le fichier de zone modifié (tapez **Ctrl+O** puis **Entrée**), puis quittez (en tapant **Ctrl+X**).
|
**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.
|
||||||
|
|
||||||
5. De retour à l’invite de commandes, rechargez le fichier de zones avec la commande :
|
|
||||||
|
|
||||||
rndc reload expediteur.example
|
|
||||||
|
|
||||||
Vous devriez voir le message « ok ». Sinon, cela signifie qu’une erreur de syntaxe s’est glissée dans le fichier de zone.
|
|
||||||
|
|
||||||
6. Interrogez le DNS pour vérifier que votre politique SPF a été bien installée, avec la commande :
|
|
||||||
|
|
||||||
dig TXT expediteur.example
|
|
||||||
|
|
||||||
Dans l’affichage de cette commande, vous devriez pouvoir identifier la politique SPF que vous venez d’installer.
|
|
||||||
|
|
||||||
Pour les lecteurs avertis : normalement, après chaque modification d’un fichier de zone, il faudrait incrémenter le numéro de série contenu 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 dans `nsd`.
|
|
||||||
|
|
||||||
### Activation du contrôle SPF chez le destinataire
|
### Activation du contrôle SPF chez le destinataire
|
||||||
|
|
||||||
Ce que vous venez de faire est la configuration nécessaire chez l’expéditeur.
|
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 mail frauduleux via la fenêtre « Attaquant », vous verrez que le mail passe toujours. Comment est-ce possible ?
|
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 :
|
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 terminal, basculez sur la fenêtre **Destinataire**.
|
1. Dans le menu, cliquez sur **Destinataire** > **Paramétrer le système**.
|
||||||
|
|
||||||
2. Ouvrez le fichier de configuration principal du serveur mail dans un éditeur de texte :
|
2. Cliquez sur l’interrupteur à gauche du texte « Activer le contrôle SPF », puis cliquez sur **Valider**.
|
||||||
|
|
||||||
nano /etc/postfix/main.cf
|
|
||||||
|
|
||||||
3. Repérer la ligne qui suit le commentaire « Décommenter pour activer le contrôle SPF au niveau SMTP » (celle qui commence par `smtpd_recipient_restrictions`). Sur cette ligne, supprimez le caractère `#` et l’espace qui suivait ce caractère (c’est important ; ne laissez pas de blanc au début de la ligne).
|
|
||||||
|
|
||||||
4. Sauvegardez le fichier ainsi modifié (**Ctrl+O**, **Entrée**) puis quittez (**Ctrl+X**).
|
|
||||||
|
|
||||||
5. Informez le serveur de courriel que sa configuration a été modifiée, qu’il doit la relire et la prendre en compte :
|
|
||||||
|
|
||||||
postfix reload
|
|
||||||
|
|
||||||
Un message devrait apparaître, indiquant que Postfix est en train de relire la configuration.
|
|
||||||
|
|
||||||
### Victoire ?
|
### 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, car c’est l’adresse de l’expéditeur dans la commande `MAIL FROM` qui est contrôlée.
|
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 la fenêtre **Expéditeur**, relancez le script d’envoi d’e-mail de confirmation. Vous verrez ce courriel apparaître quelques secondes plus tard dans la boîte de réception du destinataire.
|
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.
|
||||||
|
|
||||||
## SPF tout seul ne suffit pas ##
|
|
||||||
|
|
||||||
Peut-on crier victoire ? Pas tout de suite. L’attaquant peut encore contourner cette mesure.
|
Peut-on crier victoire ? Pas tout de suite. L’attaquant peut encore contourner cette mesure.
|
||||||
|
|
||||||
|
|
@ -135,17 +103,13 @@ Sur un courrier physique, on peut écrire une adresse retour sur l’enveloppe e
|
||||||
|
|
||||||
Pour voir cela en action, procédez ainsi :
|
Pour voir cela en action, procédez ainsi :
|
||||||
|
|
||||||
1. Dans le terminal, basculez sur la fenêtre **Attaquant**.
|
1. Dans le menu, cliquez sur **Attaquant** > **Envoyer des messages frauduleux**.
|
||||||
|
|
||||||
2. Exécutez le script de l’attaquant avec la commande `./scripts/send_email.py`.
|
2. Dans le menu déroulant « Scénario », sélectionnez le scénario **Fausse confirmation de commande**.
|
||||||
|
|
||||||
3. Sélectionnez le scénario **Fausse confirmation de commande** en tapant **2** puis **Entrée**.
|
3. Laissez le champ « HELO/EHLO » à « attaquant.example ». En revanche, dans le menu déroulant « Adresse RFC5321.MailFrom », sélectionnez « usurpateur@attaquant.example ».
|
||||||
|
|
||||||
4. Cette fois, utilisez une adresse différente dans l’enveloppe SMTP : sélectionnez le choix **2**, et non pas **1** comme vous le faisiez précédemment.
|
4. Cliquez sur **Envoyer le message frauduleux**.
|
||||||
|
|
||||||
5. Utilisez le HELO par défaut ; tapez directement **Entrée**.
|
|
||||||
|
|
||||||
6. N’ajoutez pas de signature DKIM ; tapez directement **Entrée**.
|
|
||||||
|
|
||||||
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.
|
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.
|
||||||
|
|
||||||
|
|
@ -159,69 +123,19 @@ La première chose à faire est de générer des clefs DKIM chez l’expéditeur
|
||||||
|
|
||||||
Générons des clefs DKIM pour le domaine `expediteur.example`. Pour cela, procédez ainsi :
|
Générons des clefs DKIM pour le domaine `expediteur.example`. Pour cela, procédez ainsi :
|
||||||
|
|
||||||
1. Dans le terminal, basculez sur la fenêtre **Expéditeur**.
|
1. Dans le menu, cliquez sur **Expéditeur** > **Afficher des clefs DKIM**. Vous constatez que la liste des clefs DKIM est vide.
|
||||||
|
|
||||||
2. Créez l’arborescence de répertoires nécessaire pour gérer proprement les clefs :
|
2. Dans le menu, cliquez sur **Expéditeur** > **Générer des clefs DKIM**.
|
||||||
|
|
||||||
cd /etc/opendkim/keys
|
3. Dans le champ « Sélecteur », saisissez **demo1**.
|
||||||
mkdir expediteur.example
|
|
||||||
cd expediteur.example
|
|
||||||
|
|
||||||
3. Génerez ensuite deux clefs. On utilise les sélecteurs `demo1` et `demo2`. Le choix des sélecteurs est libre (vous pouvez choisir `toto1` et `toto2` par exemple), mais il faut utiliser les bons sélecteurs partout pour que les courriels soient correctement signés.
|
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).
|
||||||
|
|
||||||
Tapez deux fois la commande `opendkim-genkey` ci-dessous, ceci afin de bien générer deux clefs différentes :
|
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.
|
||||||
|
|
||||||
opendkim-genkey -d expediteur.example -b 2048 -s demo1
|
6. Répétez les étapes 2 à 5 pour générer une autre clef DKIM ayant pour sélecteur **demo2**.
|
||||||
opendkim-genkey -d expediteur.example -b 2048 -s demo2
|
|
||||||
|
|
||||||
4. Donnez les bonnes permissions pour que le logiciel **opendkim** puisse accéder aux clefs privées :
|
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.
|
||||||
|
|
||||||
chown -R opendkim /etc/opendkim/keys
|
|
||||||
|
|
||||||
Les clefs sont maintenant générées. Les clefs privées, à garder secrètes, se trouvent dans des fichiers appelés `demo1.private` et `demo2.private`. Les clefs publiques, quant à elles, se trouvent dans les fichiers `demo1.txt` et `demo2.txt` et doivent être publiées dans le DNS.
|
|
||||||
|
|
||||||
### Publication des clefs publiques DKIM dans le DNS ###
|
|
||||||
|
|
||||||
L’étape suivante est donc de publier les clefs publiques dans le DNS :
|
|
||||||
|
|
||||||
1. Toujours dans la fenêtre **Expéditeur**, obtenez les clefs publiques :
|
|
||||||
|
|
||||||
cat demo1.txt demo2.txt
|
|
||||||
|
|
||||||
2. Les clefs publiques se présentent sous le format nécessaire pour un fichier de zone DNS. Sélectionnez à la souris l’intégralité de la sortie de la commande précédente (il se peut que vous ayez besoin de maintenir la touche **Maj** enfoncée pour pouvoir sélectionner), puis copiez cette sélection dans le presse-papiers.
|
|
||||||
|
|
||||||
3. Basculez sur la fenêtre **DNS**.
|
|
||||||
|
|
||||||
4. Éditez le fichier de zone pour le domaine `expediteur.zone`, comme pour l’installation de la politique SPF :
|
|
||||||
|
|
||||||
nano example/expediteur.zone
|
|
||||||
|
|
||||||
5. Placez le curseur au début de la ligne suivant immédiatement le commentaire `;; Clef publique DKIM`. Supprimez cette ligne, puis collez le contenu du presse-papiers (suivant le terminal que vous utilisez, la combinaison de touches à utiliser est **Ctrl+Maj+V** ou **Maj+Inser**). Il se peut que l’affichage de l’éditeur `nano` soit perturbé par ce collage ; tapez **Ctrl+L** pour forcer un rafraîchissement complet de l’écran. Vérifiez que vous avez bien ajouté deux entrées DNS de type TXT : une pour chaque clef.
|
|
||||||
|
|
||||||
6. Sauvegardez et quittez l’éditeur. Rechargez la zone :
|
|
||||||
|
|
||||||
rndc reload expediteur.example
|
|
||||||
|
|
||||||
7. Vérifiez la bonne présence de clefs DKIM avec `dig` :
|
|
||||||
|
|
||||||
dig TXT demo1._domainkey.expediteur.example
|
|
||||||
dig TXT demo2._domainkey.expediteur.example
|
|
||||||
|
|
||||||
### Terminer la configuration de DKIM chez l’expéditeur ###
|
|
||||||
|
|
||||||
Nous avons donc bien publié nos clefs DKIM dans le DNS. Finissons de configurer **opendkim** chez l’expéditeur :
|
|
||||||
|
|
||||||
1. Rebasculez sur la fenêtre **Expéditeur**.
|
|
||||||
|
|
||||||
2. Éditez le fichier `/etc/opendkim/opendkim.conf` et décommentez les deux lignes, à la fin du fichier, commençant par `SigningTable` et par `KeyTable` respectivement. Là encore, pensez bien à supprimer le caractère `#` mais aussi l’espace qui le suivait.
|
|
||||||
|
|
||||||
3. Éditez le fichier `/etc/opendkim/signing_table` et décommentez la ligne commençant par `expediteur.example`. Ceci active l’ajout de signatures DKIM pour ce domaine et spécifie que la clef de signature à utiliser est celle dont le sélecteur est `demo1`.
|
|
||||||
|
|
||||||
4. Éditez le fichier `/etc/opendkim/key_table` et décommentez les deux lignes commençant par `demo1._domainkey.expediteur.example` et `demo2._domainkey.expediteur.example` respectivement. Ceci spécifie l’emplacement des fichiers de clef privées associées aux clefs que nous comptons utiliser pour `expediteur.example`.
|
|
||||||
|
|
||||||
5. Informez **opendkim** de la nécessité de recharger sa configuration en tapant la commande :
|
|
||||||
|
|
||||||
killall -USR1 opendkim
|
|
||||||
|
|
||||||
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 !
|
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 !
|
||||||
|
|
||||||
|
|
@ -229,75 +143,47 @@ Le serveur Postfix de l’expéditeur est déjà configuré pour que les courrie
|
||||||
|
|
||||||
Nous allons faire d’une pierre deux coups et activer à la fois la vérification DKIM et DMARC chez le destinataire. Pour cela :
|
Nous allons faire d’une pierre deux coups et activer à la fois la vérification DKIM et DMARC chez le destinataire. Pour cela :
|
||||||
|
|
||||||
1. Basculez sur la fenêtre **Destinataire**.
|
1. Dans le menu, cliquez sur **Destinataire** > **Paramétrer le système**.
|
||||||
|
|
||||||
2. Placez-vous sur la ligne qui suit le commentaire `# Décommenter pour activer DKIM et DMARC`. Supprimez le `#` et l’espace qui suivait ce caractère.
|
2. Cliquez sur l’interrupteur à gauche du texte « Activer le contrôle DKIM ».
|
||||||
|
|
||||||
3. Sauvegardez, quittez puis notifiez Postfix d’un changement de configuration (`postfix reload`).
|
3. Faites de même pour « Activer le contrôle DMARC ».
|
||||||
|
|
||||||
|
4. Cliquez sur **Valider**.
|
||||||
|
|
||||||
### Essai de DKIM ###
|
### 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 :
|
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. Basculez sur la fenêtre **Expéditeur**.
|
1. Dans le menu, cliquez sur **Expéditeur** > **Envoyer un message légitime**.
|
||||||
|
|
||||||
2. Renvoyez le mail de confirmation de commande :
|
2. Dans la boîte intitulée **Confirmation de commande**, cliquez sur **Envoyer**.
|
||||||
|
|
||||||
cd /home/expediteur
|
3. Dans le message de confirmation qui est apparu, cliquez sur le bouton **Relever les courriels du destinataire**.
|
||||||
./scripts/send_confirmation_email.sh
|
|
||||||
|
|
||||||
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.
|
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 du contrôle SPF, DKIM (et aussi 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.
|
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.
|
Vous devriez aussi voir un en-tête **DKIM-Signature**, contenant la signature DKIM.
|
||||||
|
|
||||||
#### Dépannage ####
|
### Configuration DMARC chez l’expéditeur ###
|
||||||
|
|
||||||
Si le courriel n’arrive pas, il se peut qu’il n’ait pas pu être signé par opendkim. Le symptôme est l’apparition, dans la fenêtre **Système**, de messages comme :
|
|
||||||
|
|
||||||
milter-reject: END-OF-MESSAGE from localhost[127.0.0.1]: 4.7.1 Service unavailable - try again later; from=<support@expediteur.example> to=<destinataire@destinataire.example>
|
|
||||||
|
|
||||||
Dans ce cas :
|
|
||||||
|
|
||||||
* vérifiez qu’il n’y ait pas eu d’erreurs dans la configuration d’opendkim ;
|
|
||||||
* vérifiez que le compte UNIX `opendkim` ait bien accès aux clefs privées.
|
|
||||||
|
|
||||||
Après contrôle, il est possible de resoumettre le message avec la commande `postqueue -f`. Le courriel devrait arriver dans la boîte du destinataire.
|
|
||||||
|
|
||||||
## DMARC, la clef de voûte ##
|
|
||||||
|
|
||||||
À 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.
|
À 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.
|
Maintenant que le système destinataire contrôle SPF, DKIM et DMARC, nous pouvons protéger l’expéditeur en ajoutant une politique DMARC.
|
||||||
|
|
||||||
### Configuration DMARC chez l’expéditeur ###
|
|
||||||
|
|
||||||
Pour configurer DMARC chez l’expéditeur :
|
Pour configurer DMARC chez l’expéditeur :
|
||||||
|
|
||||||
1. Basculez sur la fenêtre **DNS**.
|
1. Dans le menu, cliquez sur **Expéditeur** > **Éditer la zone DNS**.
|
||||||
|
|
||||||
2. Ouvrez une nouvelle fois le fichier de zone du domaine `expediteur.example`.
|
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. 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.
|
||||||
|
|
||||||
4. Rechargez le fichier de zones, puis vérifiez la bonne publication de la politique DMARC avec la commande `dig TXT _dmarc.expediteur.example`.
|
|
||||||
|
|
||||||
### L’attaquant est-il vaincu ? ###
|
### L’attaquant est-il vaincu ? ###
|
||||||
|
|
||||||
Voyons voir maintenant si les mails d’hameçonnage de l’attaquant passent encore. Pour rappel :
|
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`.
|
||||||
|
|
||||||
1. Dans le terminal, basculez sur la fenêtre **Attaquant**.
|
|
||||||
|
|
||||||
2. Exécutez le script de l’attaquant avec la commande `./scripts/send_email.py`.
|
|
||||||
|
|
||||||
3. Sélectionnez le scénario **Fausse confirmation de commande** (choix **2**).
|
|
||||||
|
|
||||||
4. Utilisez une adresse différente dans l’enveloppe SMTP (choix **2**).
|
|
||||||
|
|
||||||
5. Utilisez le HELO par défaut ; tapez directement **Entrée**.
|
|
||||||
|
|
||||||
6. N’ajoutez pas de signature DKIM ; tapez directement **Entrée**.
|
|
||||||
|
|
||||||
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.
|
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.
|
||||||
|
|
||||||
|
|
@ -305,4 +191,21 @@ Vous pourrez ensuite vérifier que les confirmations de commande authentiques pa
|
||||||
|
|
||||||
## Et les sous-domaines ? ##
|
## Et les sous-domaines ? ##
|
||||||
|
|
||||||
(TODO : Les newsletters ne marchent plus ; c’est parce que la politique DMARC `p=reject` s’applique aux sous-domaines de `expediteur.example`. Il manque aussi une politique SPF pour `newsletter.expediteur.example` et des clefs DKIM pour ce sous-domaine.)
|
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.
|
||||||
|
|
|
||||||
43
README.md
43
README.md
|
|
@ -1,16 +1,41 @@
|
||||||
# Démonstrateur SPF, DKIM et DMARC
|
# Démonstrateur SPF, DKIM et DMARC
|
||||||
|
|
||||||
Ce démonstrateur est une infrastructure minimale sur lequel SPF, DKIM et DMARC doivent être déployés. Le but est d’illustrer le fonctionnement de ces protocoles, montrer comment ils peuvent éventuellement être contournés et enfin de servir de support de formation ou de travaux pratiques.
|
Ce démonstrateur est un support pédagogique pour apprendre à sécuriser ses courriels avec [SPF], [DKIM] et [DMARC]. Le but est d’illustrer le fonctionnement de ces protocoles, de proposer un cas pratique de déploiement et montrer comment ils peuvent éventuellement être contournés.
|
||||||
|
|
||||||
Ce système est conçu pour pouvoir alterner entre trois points de vue :
|
Ce système est conçu pour pouvoir alterner entre trois points de vue :
|
||||||
|
|
||||||
* d’une entreprise qui cherche à se protéger contre l’usurpation d’identité dans les courriels ;
|
* d’une entreprise qui cherche à se protéger contre l’usurpation d’identité dans les courriels ;
|
||||||
|
|
||||||
* d’une « personne lambda » qui reçoit à la fois des mails de cette entreprise mais aussi des tentatives de hameçonnage ;
|
* d’une « personne lambda » qui reçoit à la fois des courriels de cette entreprise mais aussi des tentatives de hameçonnage ;
|
||||||
|
|
||||||
* d’un attaquant, muni d’outils pour envoyer des faux mails convaincants.
|
* d’un attaquant, muni d’outils pour envoyer des courriels frauduleux convaincants.
|
||||||
|
|
||||||
Il est composé de quatre conteneurs Docker :
|
## Prise en main
|
||||||
|
|
||||||
|
Munissez-vous d’une machine sous Linux dotée de Docker qui soit accessible en SSH.
|
||||||
|
|
||||||
|
Clonez le dépôt. Placez-vous dans le répertoire racine du dépôt, puis générez ensuite les conteneurs Docker avec la commande :
|
||||||
|
|
||||||
|
$ docker compose build
|
||||||
|
|
||||||
|
Démarrez ensuite le démonstrateur avec :
|
||||||
|
|
||||||
|
$ docker compose up
|
||||||
|
|
||||||
|
Suivez ensuite les [instructions détaillées].
|
||||||
|
|
||||||
|
L’infrastructure est conçue pour que toute modification qui y est apportée soit éphémère. Pour réinitialiser la plate-forme à l’état d’origine, tapez les deux commandes suivantes :
|
||||||
|
|
||||||
|
$ docker compose down
|
||||||
|
$ docker compose up
|
||||||
|
|
||||||
|
## Architecture
|
||||||
|
|
||||||
|
Ce démonstrateur est composé de six conteneurs Docker :
|
||||||
|
|
||||||
|
* **frontend** : un simple proxy inversé donnant l’accès à l’interface Web du démonstrateur ;
|
||||||
|
|
||||||
|
* **console** : contient l’interface Web du démonstrateur proprement dite ;
|
||||||
|
|
||||||
* **dns** : contient un résolveur DNS (unbound) et un serveur faisant autorité (nsd), dont les fichiers de zone peuvent être édités pour introduire SPF, DKIM et DMARC
|
* **dns** : contient un résolveur DNS (unbound) et un serveur faisant autorité (nsd), dont les fichiers de zone peuvent être édités pour introduire SPF, DKIM et DMARC
|
||||||
|
|
||||||
|
|
@ -18,12 +43,12 @@ Il est composé de quatre conteneurs Docker :
|
||||||
|
|
||||||
* **attacker** : le système mail de l’attaquant ;
|
* **attacker** : le système mail de l’attaquant ;
|
||||||
|
|
||||||
* **recipient** : le système mail destinataire des mails de l’entreprise et de l’attaquant.
|
* **recipient** : le système mail destinataire des mails de l’entreprise et de l’attaquant ;
|
||||||
|
|
||||||
Pour commencer, clonez le dépôt et tapez la commande :
|
Hormis le conteneur **frontend**, aucun de ces conteneurs n’a accès à Internet.
|
||||||
|
|
||||||
$ docker compose build
|
|
||||||
|
|
||||||
Suivez ensuite les [instructions détaillées].
|
|
||||||
|
|
||||||
|
[DKIM]: https://www.rfc-editor.org/rfc/rfc6376.html
|
||||||
|
[DMARC]: https://www.rfc-editor.org/rfc/rfc7489
|
||||||
[instructions détaillées]: INSTRUCTIONS.md
|
[instructions détaillées]: INSTRUCTIONS.md
|
||||||
|
[SPF]: https://www.rfc-editor.org/rfc/rfc7208
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue