Nom de domaine : apprenez à le sécuriser

La sécurisation de votre nom de domaine est une priorité

Pour une entreprise / TPE / PME , il est essentiel de sécuriser son nom de domaine. En effet, nombreux sont les dysfonctionnements et attaques possibles. Ainsi, si vous ne prenez pas votre CybeSécurité au sérieux, vous risquez de vous faire voler, voir transférer ou suspendre votre nom de domaine. De plus, des hackers peuvent usurper votre identité et prendre le contrôle de votre messagerie.

Quels sont les risques ?

Les risques endogènes

Les risques endogènes font référence aux dysfonctionnements, pertes, et plus généralement de toutes les défaillances liées à la gestion du nom de domaine. Ainsi, il en existe de plusieurs sortes :

  • Le non renouvellement d’un nom dans les temps

Effectivement, faites attention car votre nom de domaine peut se retrouver dans le domaine public !

  • La non mise à jour du titulaire

Ainsi, des situations très compliquées peuvent survenir, lorsque le titulaire a cessé d’exister. Par exemple, si le nom de votre entreprise est déposé par l’un de vos associés en son nom et qu’il y a litige entre vous ensuite.

  • La délégation volontaire ou non de la titularité et / ou du contact administratif du nom à un prestataire / partenaire

En effet, si un jour vos intérêts divergent de ceux de votre client, celui-ci pourrait être tenté d’utiliser contre vous le contrôle qu’il a sur le nom de domaine.

  • L’absence des contacts 

Et particulièrement les contacts électroniques. Ainsi, si le titulaire ne peut plus recevoir des notifications liées à la gestion du nom, les conséquences peuvent être désastreuses.

  • L’abandon par le titulaire du nom de domaine servant de support aux emails et aux contacts administratifs, commerciaux etc.

Erreur ! En effet, cela ouvre une faille de sécurité permettant au tiers qui re-déposera le nom de domaine de prendre le contrôle sur tous les autres noms.

  • Une politique de sécurité insuffisante quant aux accès aux interfaces de gestion

En effet, quand on a accès à tous les mots de passe, on peut modifier les serveurs ou même couper le service !

  • Ne pas assurer la gestion du nom de domaine dans de bonnes conditions de sécurité

Ainsi, gérer le nom sans réflexion sur la CyberSécurité est dangereux. En effet, vous risquez de nombreuses attaques et problèmes internes.

Les risques exogènes

Ainsi, nous faisons ici référence à l’inverse des risques internes. De plus, les risques exogènes sont bien plus médiatisés et connus que les risques endogènes. Néanmoins, ils sont intimement liés car de nombreuses attaques ont été facilitées par des failles de sécurité causées par les points ci-dessus.

  • Le vol

Risque le plus couru, les motivations sont multiples. En effet, de la vente à l’espionnage industriel en passant par l’extorsion, votre entreprise subira de lourdes conséquences.

  • Le dépôt par un tiers

Situation fréquente, vous risquez une interruption de vos services web et de messagerie jusqu’au rachat en catastrophe du nom (et à prix fort).

  • Les transferts abusifs

Cela permet d’installer un nom de domaine sur des serveurs non légitimes. Ainsi, on peut faire pointer ensuite le nom vers le site du choix du hacker.

  • Le détournement

Ce sont généralement des salariés en litige avec leurs employeurs qui, avec leur accès à l’interface de gestion, cherchent à leur nuire.

  • Les failles de sécurité lors d’échanges

En effet, si vos accès ne sont pas sécurisés, des hackers peuvent avoir accès à vos informations.

Comment limiter les risques ?

Les risques endogènes

Maîtriser les renouvellements

En effet, les dates d’échéance de vos noms de domaine doivent être connues et surveillées. Ainsi, la bonne date est celle se trouvant dans les WHOIS officiels en charge des TLD. De plus, il existe une fonction pour basculer en mode « renouvellement automatique ». Néanmoins, vous garder la possibilité de demander le non-renouvellement d’un nom.

Être vraiment titulaire de ses noms de domaine

Ainsi, l’entreprise doit être titulaire (ou registrant) des noms de domaine qu’elle dépose / fait déposer.
Par conséquent, il doit être clairement formalisé que l’entreprise est titulaire du nom, dans le cadre de sa collaboration avec tel ou tel prestataire ou partenaire. De plus, si un nom est déposé par un tiers, il doit être restitué sans contrepartie supérieure aux frais occasionnés.
En outre, c’est aussi valable pour les noms de domaine déposés au nom de l’entreprise par ses associés. Néanmoins, il est important, après le dépôt, que la titularité des noms lui soit transférée.

Trier ses contacts

En effet, il est important de régulièrement faire le tri dans son carnet d’adresse. Ainsi, si vous n’avez aucun lien avec le PDG, inutile de le noter en contact.
De plus, une adresse générique doit être utilisée à chaque changement de responsable du dossier (« dns.admin@exemple.com« ). Ainsi, plus de problèmes en cas de départ : pas de blocage qui empêcherait le nom de domaine de fonctionner.
Plus généralement, il faut faire attention à vos contacts et bien maîtriser vos adresses de messagerie.

Faites attention à vos identifiants

Puisque vos identifiants et mots de passe sont des données sensibles, il faut y faire particulièrement attention. En effet, une personne en possession de ces data peut faire ce qu’elle veut de votre nom de domaine.
Ainsi, ne communiquez pas ces informations par email et ne les notez pas non plus sur des supports accessibles à tous. De plus, les codes d’accès doivent être assez robustes et changés régulièrement. En outre, si un membre de votre équipe vient à partir, les mots de passe doivent être mis à jour.
Comme pour la titularité des noms de domaine, il est capital que ce soit l’entreprise, et seulement elle, qui ait les clés de l’interface de gestion. Néanmoins, cela peut être difficile lorsque l’on passe par un prestataire gérant les noms de domaine. Ainsi, faute d’être le seul « gardien des clés », vous devez garantir la sécurité de vos accès avec un contrat solide.

Une organisation interne solide

  • Avoir un référent coordinateur identifié
  • Adopter une vision globale des besoins et des risques
  • Mettre en place des procédures claires pour toute demande de modification d’un nom de domaine

Les risques exogènes

Sécurisez vos échanges avec vos prestataires

Généralement, les services d’enregistrement proposent à leurs clients des interfaces de gestion. Ainsi, vous pouvez gérer des noms de domaine sans passer par votre prestataire. Par conséquent, vous devez vous assurer que cet accès est réalisé en mode https.
Néanmoins, ce n’est pas toujours possible. En effet, si vous passez par un revendeur (agence web, conseil etc.), ce dernier gérera vos noms de domaine via son propre compte au bureau d’enregistrement. Ainsi, vous devrez mettre en place certaines procédures pour limiter les risques.

  • L’identification claire des adresses emails que vous et votre prestataire utilisez. Ainsi, tout autre mail reçu provenant d’une autre adresse sera considérée avec méfiance.
  • Savoir précisément qui est chargé de quoi, et quels sont les interlocuteurs intervenant sur les noms de domaine.
  • Mettre en place un système de confirmation passant par un autre canal pour confirmer une opération sur le nom de domaine.
  • La confirmation de réception par le prestataire de toute demande d’opération menée sur les noms.
  • Créer une procédure et des contacts d’urgence afin d’accéder à une assistance immédiate.

Différents niveaux de sécurité

En effet, vos différents noms de domaine ont différents niveaux de sécurité. Néanmoins, vous devez prévoir les risques en les sécurisant par divers moyens :

  • Des systèmes de restauration
  • Le verrouillage des noms de domaine
  • Un système de récupération des noms stratégiques
  • Recours aux « Registry Lock« 

Prendre des précautions internes

  • Prendre en compte des noms de domaine dans la politique de gestion des risques de l’entreprise
  • Élaborer un plan de continuité stratégique en cas d’incident sur un nom de domaine stratégique
  • Protéger vos noms par des contrats d’assurance
  • Mettre en place des surveillance sur les WHOIS

Nom de domaine : au niveau technique

Enregistrement SPF

En théorie

Il est recommandé de créer un enregistrement Sender Policy Framework (SPF) pour votre nom de domaine. En effet, c’est un type d’enregistrement DNS (Domain Name Service) servant à déterminer quel serveur de messagerie est autorisé à envoyer des messages à votre nom de domaine.
Ainsi, l’enregistrement SPF empêche les expéditeurs de courriers indésirables d’envoyer des emails via une fausse adresse d’expédition de votre domaine. De plus, les destinataires ont la possibilité de se référer au SPF afin de vérifier sur un message provenant de votre domaine a bien été envoyé via un serveur autorisé.
Par exemple, imaginons que votre nom de domaine example.com utilise Gmail. Ainsi, en créant un enregistrement SPF, vous définirez les serveurs de messagerie G Suite comme autorisés. Par conséquent, quand un serveur de messagerie reçoit un email venant de utilisateur@example.com, le destinataire peut rechercher votre nom de domaine dans l’enregistrement SPF pour vérifier l’authenticité du mail. Néanmoins, si l’email vient d’un autre serveur que ceux G Suite répertoriés dans l’enregistrement SPF, le serveur du destinataire peut le considérer comme un spam.
De plus, si votre domaine ne possède pas d’enregistrement SPF, certains domaines de vos destinataires peuvent rejeter vos messages ! En effet, ils ne pourront pas les authentifier comme en provenance d’un serveur de messagerie autorisé.
Pour configurer l’enregistrement SPF pour utiliser G Suite, cliquez ici !

En pratique

Ainsi, lorsque vous décidez de publier un enregistrement SPF sur votre serveur DNS, cela donne quelque chose comme ça : Nom de domaine DNS enregistrement SPF
Ci-dessus, nous avons deux enregistrements DNS semblables. En effet, l’un est de type SPF et l’autre TXT, pour la rétrocompatibilité. Ainsi, cela signifie que les serveurs avec pour adresse IP 198.51.100.123 et les adresses IP du bloc 192.0.2.0/24 peuvent envoyer des emails au nom de example.net. De plus, le « a » précise que toutes les adresses IP de l’enregistrement A ont eux aussi le droit d’envoyer des mails pour ce nom de domaine. En outre, « -all » exprime le fait que toutes les autres adresses IP doivent être rejetées – « SPF=FAIL« .
Néanmoins, un email qui échoue au test du SPF ne sera pas forcément considéré comme un SPAM. Par contre, un nom de domaine avec un SPF qui fonctionne correctement recevra moins de spams.
Pour tout savoir sur les SPF, consultez le site (anglais) officiel en cliquant ici !

La norme DKIM

En théorie

Afin de lutter contre l’usurpation d’adresse IP (ou spoofing), vous pouvez utiliser la norme DKIM. Ainsi, vous ajoutez une signature numérique à l’en-tête de vos messages sortants. En effet, vous utilisez ici une clé de domaine afin de chiffrer les en-têtes des emails sortants de votre domaine. De plus vous ajoutez une version publique de la clé en question aux enregistrements DNS de votre nom de domaine. Ainsi, le serveur de destination peut ensuite récupérer cette clé publique pour déchiffrer l’en-tête du mail entrant. Par conséquent, il peut contrôler que celui-ci vient bien de votre domaine sans avoir été entre-temps modifié.
Pour plus de détails sur DKIM visitez le site officiel !

En pratique

Précisément, DKIM associe le nom de domaine à un message en y collant une signature numérique, tandis que le SPF lie le nom à l’adresse IP du message entrant. Ainsi, avec DKIM, la signature est vérifiée via une clé cryptée localisée dans un enregistrement DNS. Ainsi, DKIM vérifie si le message a été modifié et endommagé pendant son transport entre différents serveurs SMTP. De plus, DKIM garanti que le contenu arrivera sain et sauf jusqu’à son destinataire.
Néanmoins, comme SPF, DKIM n’empêche pas les spams mais permet aux serveurs qui reçoivent les messages de les voir comme légitimes.
Voici un exemple de signature par DKIM insérée dans le header d’un mail :
DKIM nom de domaine DNS Expert-Com

Enregistrement DMARC

En théorie

Lorsque vous avez mis en place SPF et DKIM, vous pouvez alors configurer DMARC (Domain-based Message Authentication, Reporting and Conformance). En effet, ce dernier fait le lien entre les deux premiers en les unissant et en les rendant plus intelligents.
Ainsi, il y a deux utilisations principales de DMARC :

  1. Le DMARC aiguille le FAI / Webmail sur ce qu’il doit faire du message si son authentification échoue
  2. Le DMARC notifie l’expéditeur quand l’authentification échoue

Par conséquent, pour configurer le DMARC, vous devez ajouter des règles aux enregistrements DNS de votre domaine sous formes d’enregistrements TXT (même principe que pour le SPF ou ADSP).

En pratique

Ainsi, pour créer un enregistrement TXT, vous devez suivre les instructions caractéristiques aux principaux hôtes de domaine (cliquez ici pour plus de précisions). De plus, son nom d’enregistrement doit être « _dmarc.votredomaine.fr« . Voici les balises les plus couramment employées dans les enregistrements TXT DMARC :
nom de domaine DMARC balise TXT Expert-Com
Vous pouvez retrouver les autres balises en cliquant ici.
Les balises v (versions) et p (policy) sont obligatoires. De plus, 3 paramètres de règles sont disponibles :

  • none : aucune action en particulier
  • quarantine : désignation de spam des messages en question
  • reject : annulation de l’email au niveau SMTP

De plus, le mode d’application réfère à la précision avec laquelle les enregistrements des expéditeurs sont comparés aux signatures SPF et DKIM. En effet, on retrouve deux valeurs : r (relaxed, souple) et s (strict). Ainsi, la valeur r permet des correspondances partielles (sous-domaines d’un domaine par exemple). Néanmoins, la valeur s demande une correspondance exacte. Enfin, pour vos rapports quotidiens, insérez la balise « rua ».

Exemples d’enregistrements

Voici des exemples d’enregistrements TXT DMARC (_dmarc.votre_domaine.fr IN TXT), modifiables selon ce que vous souhaitez.

  • Enregistrement TXT 1 : si un message a l’air de provenir de votre domaine mais n’est pas validé par DMARC, alors une action n’est réalisée. Néanmoins, ces messages apparaissent dans le rapport quotidien envoyés à « postmaster@votre_domaine.fr » :
    v=DMARC1; p=none; rua=mailto:postmaster@votre_domaine.fr
  • Enregistrement TXT 2 : si un message semble provenir de votre domaine et n’est pas validé par DMARC, il est alors placé en quarantaine, 5% du temps.
    v=DMARC1; p=quarantine; pct=5; rua=mailto:postmaster@votre_domaine.fr
  • Enregistrement TXT 3 : ici, les messages sont systématiquement rejetés quand ils ont l’air de provenir de votre domaine sans être validés par DMARC.

v=DMARC1; p=quarantine; pct=5; rua=mailto:postmaster@votre_domaine.fr

Exemples de rapport

Les rapports envoyés au quotidien sont au format XML, et vous permettent de mieux comprendre votre flux de messages. De plus, ils vous permettent de vérifier que vos sources de mails sortants sont bien authentifiées. Néanmoins, vous devez vous assurer que les adresses IP envoyant les emails et qui disent être de votre domaine le sont bien ! Ainsi, configurez-les avec DKIM ou bien ajoutez-les au SPF. En outre, lorsque des règles de blocage sont activées, ces rapports vous permettent de réagir vite si une nouvelle source de messages apparaît ou si une source pré-existante n’est plus configurée.
Ainsi, voici un exemple de rapport qui présente les résultats en lien avec les messages envoyés depuis deux adresses IP, l’un envoyé directement et l’autre transféré :

<record>
 <row>
 <source_ip>207.126.144.129</source_ip>
 <count>1</count>
 <policy_evaluated>
 <disposition>none</disposition>
 </policy_evaluated>
 </row>
 <identities>
 <header_from>stefanomail.com</header_from>
 </identities>
 <auth_results>
 <dkim>
 <domain>stefanomail.com</domain>
 <result>pass</result>
 <human_result></human_result>
 </dkim>
 <spf>
 <domain>stefanomail.com</domain>
 <result>pass</result>
 </spf>
 </auth_results>
 </record>
 <record>
 <row>
 <source_ip>207.126.144.131</source_ip>
 <count>1</count>
 <policy_evaluated>
 <disposition>none</disposition>
 <reason>
 <type>forwarded</type>
 <comment></comment>
 </reason>
 </policy_evaluated>
 </row>
 <identities>
 <header_from>stefanomail.com</header_from>
 </identities>
 <auth_results>
 <dkim>
 <domain>stefanomail.com</domain>
 <result>pass</result>
 <human_result></human_result>
 </dkim>
 <spf>
 <domain>stefanomail.com</domain>
 <result>pass</result>
 </spf>
 </auth_results>
 </record> 

Déploiement

Il est recommandé de déployer DMARC progressivement, en mettant en place les règles ci-dessous dans cet ordre précis. Tout d’abord, contrôlez votre trafic à la recherche de possibles anomalies dans les rapports. Ensuite, remplacez le paramètre « none » par « quarantine » au sein des règles d’enregistrement TXT. Puis, quand vous savez que tous les messages sont bien signés, remplacez le paramètre de vos règles par « reject« . Ainsi, vous pourrez tirer parti de DMARC de façon optimale. De plus, continuez à surveiller vos rapports pour être sûr que vos résultats soient acceptables.
Ainsi, vous pouvez vous servir de la balise « pct » pour appliquer progressivement DMARC. Par conséquent, la valeur par défaut étant 100%, vous pouvez ajouter « pct=20 » à votre enregistrement TXT DMARC pour que les règles en vigueur ne soient appliquées qu’à un cinquième des messages et pas à tous. C’est très utile lorsque vous voulez mettre en quarantaine et rejeter les messages. Ainsi, commencez avec un pourcentage bas et laissez passer quelques jours entre chaque augmentation.
Voici un cycle de déploiement prudent :

  1. Surveillance systématique
  2. Mise en quarantaine de 1 %
  3.  »  »  »  » 5 %
  4.  »  »  »  » 10 %
  5.  »  »  »  » 25 %
  6.  »  »  »  » 50 %
  7. Mise en quarantaine systématique
  8. Rejet de 1 %
  9.   »  » 5 %
  10.   »  » 10 %
  11.   »  » 25 %
  12.   »  » 50 %
  13. Rejet systématique

En effet, essayez de supprimer les pourcentages le plus tôt possible pour terminer le déploiement. Puis, continuez à examiner vos rapports quotidiens.

Partagez l'article

Partager sur facebook
Partager sur twitter
Partager sur linkedin
Partager sur email