Email : comment améliorer la délivérabilité et réduire les abus liés au phishing par Geoffrey en RISR2015 – Actualité des Promotions Informatiques du Campus Cesi Arras
Email : comment améliorer la délivérabilité et réduire les abus liés au phishing par Geoffrey en RISR2015
19 juillet 2017 5 juin 2017 Frédéric Szusciak
Depuis la démocratisation de l’informatique en 1975, notamment par Microsoft, le volume de données généré ne cesse de croitre chaque année. La ou en 1975, 2 Mo suffisaient à supporter le système d’exploitation et les fichiers de l’utilisateur, en 2010 la création de données dans le monde dépassait le téraoctet par jour, en 2020 les experts estiment que nous en créeront 109 téraoctets par jour, et nous produiront plus données que nous pourrons en stocker.
Ainsi la protection d’une telle quantité de données est devenue l’un des enjeux majeurs du 21eme siècle, car nombre de données numériques sensibles sont accessibles via le réseau des entreprises. Et pour qui aurait à intérêt à les exploiter ou les « prendre en otage », ces données sont une vraie mine d’or, et tous les moyens sont bon pour les récupérer ou les détruire, exposant les utilisateurs, souvent néophyte, à des dangers qu’ils ne soupçonnent pas.
Parmi ces dangers nous pouvons en distinguer 2 groupes, tout d’abord les menaces directes :
– Virus / vers / chevaux de Troie
Actuellement, nous avons à disposition plusieurs solutions (antivirus, antimalware, antispam) qui nous permette de lutter efficacement (sans être infaillible) et de protéger les utilisateurs de nos systèmes d’informations, même si bien entendu la première des protections reste la sensibilisation.
Ensuite nous avons les menaces indirectes :
Par exemple, en temps normal, le transite des données se fait (pour schématiser) du point A au point B, mais si un pirate se met au milieu, il est capable de capter les données, soit pour les récupérer et les exploiter, soit pour les corrompre et faire du dégât dans le système d’information cible.
– L’usurpation d’identité par mail,
Il est facile de vérifier l’identité de son interlocuteur par téléphone par exemple, vous recevez un appel, vous voyez le numéro s’afficher, le nom de la personne si elle est dans vos contact, puis vous décrochez, vous entendez sa voix, vous êtes sûr que c’est elle, sauf si vous tombé sur un(e) bon(ne) imitateur(trice), ou la NSA qui dispose de système perfectionner pour imiter une voix, ce qui reste très peu probable …
Mais le scénario n’est pas le même quand vous recevez un mail, comment pouvez-vous vérifier l’identité de l’expéditeur ?
Pour ce faire, plusieurs bonnes pratiques peuvent être appliquer afin de certifier a votre destinataire que vous êtes bien qui vous prétendez être.
2. FCrDNS
La première mesure à mettre en place (qui devrait être une bonne pratique systématique d’ailleurs) si elle n’est pas déjà existante, est la création d’un enregistrement Pointeur (PTR) dans la zone de recherche indirecte de votre serveur DNS Publique (contenant le domaine de vos emails). Cela permettra notamment au contrôle de réception de l’email de vérifier si les serveurs DNS sont en pleine maitrise du propriétaire émetteur. C’est une forme d’authentification établissant une relation fiable entre le propriétaire du nom de domaine et le propriétaire de la machine qui a initiée la requête SMTP.
3. FQDN HELO
La seconde mesure à vérifier sur les serveurs de messagerie sortants est le nom de domaine configuré lors de la réponse FQDN HELO, il doit de l’ordre de « monentreprise.fr » et non « monentreprise.local ». Dans les faits, ceci n’est pas bloquant pour le transfert du message mais distingue les serveurs correctement installés des autres pour un anti-spam. Quand un serveur mail établi une connexion, il se présente avec la commande HELO. Par exemple: « HELO mail.company.com ». Le nom de serveur fourni doit être conforme FQDN (Fully Qualified Domain Name). Ce qui veut dire que ce nom est valide et joignable sur internet.
La troisième mesure à mettre en place consiste à créer un type d’enregistrement DNS de type TXT qui détermine les serveurs de messagerie autorisés à envoyer des messages au nom de votre domaine. Cette norme de vérification s’appelle le Sender Policy Framework (SPF).
Voici quelques exemples de ce qu’il est possible de faire avec les enregistrements SPF :
v=spf1 ip4:5.5.5.0/24 –all
Autorise toutes les adresses IP comprises entre 5.5.5.1 et 5.5.5.254
v=spf1 a:mailers.example.com –all
Autorise toutes les adresses IP de tous les enregistrements de type A pour le domaine
v=spf1 mx/24 mx:offsite.domain.com/24 -all
Autorise toutes les adresses IP de tous les enregistrements de type MX pour le domaine avec une marge de range (Peut être qu’un serveur MX de domaine a reçu un mail sur une adresse IP, mais a envoyé le mail sur une adresse IP différente mais proche)
5. Domain Key Identified Mail
Nous pouvons également signer chaque mail sortant en ajout une signature numérique à l’en-tête des messages de façon à ce que le processus anti-spam du destinataire puisse vérifier que le mail n’a pas été déformé depuis l’expédition en décodant la signature avec la clé publique contenue dans un enregistrement DNS. Cela permet de lutter contre le spoofing.
DMARC (Domain-based Message Authentication, Reporting and Conformance) est une norme d’authentification des emails basée sur SPF et/ou DKIM. Il ne remplace pas ces protocoles mais il va les rendre plus intelligent en les unissant.
Il standardise la façon dont un MTA destinataire doit gérer un message dont les vérifications DKIM et/ou SPF ont échoué.
DMARC est implémenté sous la forme d’un enregistrement txt dans le DNS du MTA expéditeur.
v=DMARC1;p=reject;pct=100;rua=mailto:postmaster@mondomaine.com
DMARC possède 3 politiques :
Avec cette configuration activée « en monitor mode », l’adresse courriel indiquée (dans l’option mailto) reçoit des rapports quotidiens des fournisseurs en ce qui concerne le nombre de messages qui ont été reçus et qui ont passés les contrôles de la politique ou non.
Avec cette configuration activée, les messages qui ne passent les contrôles de politiques sont mis en quarantaine.
Avec cette configuration activée, les messages qui ne passent les contrôles de politiques sont rejetés par le MTA destinataire.
La balise rua permet à l’administrateur du MTA expéditeur de recevoir des rapports quotidiens. Les rapports quotidiens sont présentés au format XML. Leur lecture permet de mieux comprendre les flux de messages. Ces rapports aident à vérifier que les sources de courrier sortant sont correctement authentifiées. Lorsque des règles de blocage sont en place, les rapports permettent également aux administrateurs de réagir rapidement si une nouvelle source de courrier apparaît en ligne ou si la configuration d’une source existante n’est plus appliquée.
DMARC demeure l’arme la plus puissante jamais conçue pour lutter contre les tentatives d’usurpation d’identité (spoofing) et d’hameçonnage (phishing). Ce protocole d’authentification des emails a transformé de manière radicale le paysage des pratiques frauduleuses ciblant la messagerie électronique et enrayé des tactiques de phishing de longue date, protégeant des marques, l’image des sociétés sur Internet, des effectifs et des usagers.
Tagué pishing
Article précédentHyperConvergence par Kevin et John en RISR2015
Article suivantBonne continuation aux GMSICP2015 !