SPF Checker en PowerShell

Coucou les gens, on se fait un quicky aujourd’hui ? je vous partage vite fait un SPF Checker en PowerShell pour contrôler vos configurations SPF. Je m’explique, j’ai un psychopathe des mails dans mon équipe, il terrorise tout le monde en usurpant les domaines qui ont mal configuré leur SPF. Du coup, ca me semble utile de vous former un peu la dessus, parce que je ce que vous en dehors de chez nous m’inquiète un peu pour être honnête.

SPF ?

Alors quand on parle sécurisation des mails, Il y’a 3 protocoles qu’il faut connaître :

• SPF (doc pour les nuls).
• DKIM ;
• DMARC; et

On va les détailler « vue macro » ci-après, pour que vous compreniez les grands principe de chaque.

SPF

C’est le plus ancien et le plus simple à comprendre. Avec SPF, vous listez simplement dans un enregistrement DNS les serveurs SMTP autorisé à envoyer des mails pour votre nom de domaine. Par exemple, si vous regardez pour geekeries.org, vous verrez que j’autorise « mx.ovh.com » à envoyer des mails à ma place, parce que j’ai la grosse flemme de configurer un serveur SMTP moi même.

Vous noterez le « -all » à la fin (lire « moins/minus all » et pas « tiret all »), qui signifie qu’en dehors de ceux listé avant tout autre émetteur doit être rejeté par défaut. SPF vous autorise plusieurs « qualifier » :

• le + qui ajoute, si vous mettez rien c’est lui qui s’applique (par exemple le mx au dessus est équivalent à +mx en fait).
• le ? qui dit qu’il y a pas de policy (i.e si t’es le serveur qui reçoit le mail démerde toi…).
• le – pour le fail, signifie que s’il match la règle, le mail doit être rejeté.
• le ~ (tilde) pour Softfail, sensé servir pour du debug en laissant passer le message en le « marquant ».

Problème ? les 3/4 des domaines sont configuré en « ~all » à la fin et la notion de marquage est un truc interne au serveur, pas affiché à l’utilisateur. Ce qui fait qu’en « softfail » le mail arrive jusqu’à l’utilisateur dans la grande majorité des cas.

DKIM

Ensuite, DKIM, est une méthode toujours basée sur les record DNS, mais également la cryptographie asymétrique pour vous permettre d’aprouver un émetteur.

Un exemple très simple : vous êtes l’entreprise « gagatoteau.fr » qui vend des gâteaux sur internet et vous voulez déléguer l’envoi de vos mails de promotion à un tiers (ovh, mailchimp, etc.). Rien de plus simple: vous générez une biclé et mettez la partie publique dans un enregistrement DNS (type TXT) de du domaine « gagatoteau.fr », et vous donner la clé privé à votre tiers. Ces derniers vont pouvoir signer cryptographiquement les mails à l’aide de cette clé privé. Ainsi tout serveur réceptionnaire de ces mails peut vérifier que vous avez autorisé ce tiers à envoyer des mails en votre nom, en se vérifiant la signature à l’aide de la clé publique présente sur le DNS (une bonne doc ici).

Notez que DKIM n’a de vraiment du sens que si vous déléguez l’envoi de vos mails à un tiers. DKIM est notamment utilisé pour éviter que les grosses campagnes de pub se fasse bloquer par les antispam.

DMARC

C’est le dernier né de la famille, c’est en quelque sorte une surcouche à SPF et DKIM qui va permettre vérifier l’alignement de ces 2 derniers par rapport à une politique que vous aurez configurée pour votre domaine. En version courte vous indiquez aux autres serveurs mails « quoi faire » quand un mail n’est pas conforme avec votre politique DMARC.

Le gros intérêt de DMARC, c’est qu’il permet de configurer des l’envoi de rapports que les autres serveurs de mails vous enverront quand il voit passer des mails non conforme à votre politique. Vous permettant ainsi de surveiller à quel point vos domaines se font usurper par des spams et autres phishing. Encore faut-il monitorer ces reports de votre côté ensuite.

Pourquoi on parle que de SPF ?

Alors d’abord si vous voulez un bon résumé le site dmarc.org a fait un jolie dessin pour résumer les étapes de filtrage d’un mail que je peux vous partager car il l’ont gentiment mis en Licence CC3 :

Du coup, si je vous dit que DKIM n’est configuré que pour les envoi massifs, que SPF est configuré en softfail la moitié du temps, et que DMARC ne fait que que configurer l’envoi de report le plus souvent et qu’il se base sur les 2 précédents (mal configurés, suivez un peu) pour qualifier les mails. Vous la voyez venir la douille ?

Et au final le « seul » élément que vous pouvez vraiment durcir pour rejeter les mails d’un attaquant : c’est le SPF (bein ouais vous pouvez pas bloquer tous les senders sans DKIM en général).

Un petit exemple?

Alors on remercie Jules de m’avoir filer le tuto (vous allez voir c’est pas compliqué, mais depuis que je suis chef, j’ai plus le temps de creuser assez la technique…). Prérequis : on a juste besoin d’une interface roundcube, genre ce que vous avez par défaut avec n’importe quel MX plan chez OVH.

Vous allez dans les « paramètres » sur votre interface et créez une nouvelle identité avec le domaine qui à son enregistrement SPF mal configuré.

Puis vous retourner sur la mailbox et pour envoyer le mail avec l’identité que vous venez de créer.

Et y’a plus qu’a attendre que ca arrive :

Detection – le SPF Checker en PowerShell

Je vous ai promis un One Liner PowerShell pour checker vos domaines le voilà avec 2 exemples

PS C:\> [Regex]::Match(((Resolve-DnsName -Name "geekeries.org" -Type TXT | Where-Object { $_.Strings -match "^v=spf1" }).Strings),'-all').Success
True #bien configuré
PS C:\> [Regex]::Match(((Resolve-DnsName -Name "cia.org" -Type TXT | Where-Object { $_.Strings -match "^v=spf1" }).Strings),'-all').Success
False #pas bien configuré

Y’a plus qu’à !

Remediation

C’est très, très, simple : vous passez sur tous vos domaines et vous ajoutez ou modifiez la configuration SPF pour « -all », à la fin, et pour tous les domaines. Ensuite vous ramassez 1 par 1 en incident tous les projets IT qui faisait n’importe quoi avec des mails qui partait depuis des serveurs externes… Résumé si vous êtes dans un grand groupe, commencez par audité les mails qui partent de partenaire pour éviter un incident de prod et devoir rollback…

Conclusion

Ce défaut de configuration est très courant car beaucoup de fournisseur de domaine ne configurent pas par défaut le SPF à « -all » quand il vous livre un domaine (souvent à ~all, parfois vide). C’est relou parce que pour des attaques de spear phishing, c’est quand même super utile pour des redteamer ou autre.

Gardez en tête aussi que ça peut paraître « assez simple » à corriger. Mais, dans des grands environnement où les emails sont utilisés de partout depuis longtemps et sans contraintes, comptez facile quelques mois (voire années) pour remettre le truc au propre.

Enfin un merci à Jules pour avoir partager ça avec l’équipe et nous permettre de nettoyer tout ça.