Détournement DNS WordPress : Comment savoir si votre domaine a été volé ou votre site piraté

Vous tapez votre domaine dans un navigateur, et autre chose s'affiche, comme une page de parking couverte de publicités ou un site de pharmacie dans une langue que vous ne lisez pas.

La première pensée de presque tout le monde est la même : J'ai été piraté.

Peut-être. Mais quatre problèmes différents se ressemblent depuis le navigateur, et leurs solutions n'ont rien en commun.

Voici ce qui pourrait se passer :

• Quelqu'un a pris le contrôle de votre domaine chez votre registraire ou votre hébergeur DNS.
• Vos fichiers WordPress ont été infectés et redirigent.
• Votre appareil résout mal le domaine alors que tout le monde voit votre site correctement.
• Ou rien n'a été attaqué du tout, et il s'agit d'une migration, d'un délai de propagation, ou d'un domaine expiré.

Les solutions n'ont presque rien en commun. Nettoyer votre installation WordPress ne fait rien pour un domaine piraté. Réinitialiser votre mot de passe de registraire ne fait rien pour un code injecté. Restaurer une sauvegarde, ce qui est le conseil que vous recevrez le plus souvent, n'aide que pour l'un des quatre problèmes.

Donc, avant de changer quoi que ce soit, vous devez savoir quel problème vous avez.

Dans cet article, j'expliquerai ce qu'est le piratage DNS et comment réduire la cause en une dizaine de minutes. Ensuite, je vous montrerai comment récupérer un domaine qui a été véritablement volé et comment sécuriser les choses pour que cela ne se reproduise pas.

Points clés à retenir

• Quatre problèmes différents produisent le même symptôme. Un domaine volé, un malware de redirection injecté, un appareil qui vous ment, ou rien n'a été attaqué du tout.
• Le piratage DNS ne touche jamais votre installation WordPress. Vos fichiers restent intacts ; le domaine cesse simplement d'y pointer.
• Restaurer une sauvegarde ne fait rien pour un domaine piraté. Votre domaine ne se trouve pas dans un fichier de sauvegarde ; c'est un enregistrement détenu par un registraire.
• Une sauvegarde résout d'autres causes. Si un malware de redirection a été injecté dans vos fichiers ou votre base de données, une copie propre d'avant l'infection le supprime.
• Le test de trente secondes vient en premier. Chargez votre site sur votre cellulaire avec le Wi-Fi désactivé. Si vous êtes le seul à voir le problème, votre domaine est correct.
• La date de mise à jour de votre WHOIS est le signal le plus clair. Un changement que vous n'avez pas effectué vous indique ce qui s'est passé et à peu près quand cela s'est produit.
• Votre e-mail suit vos serveurs de noms. Le contrôle des enregistrements MX signifie que les réinitialisations de mot de passe sont acheminées vers celui qui détient le domaine, ce qui modifie la façon dont vous gérez la récupération.
• Vous ne pouvez pas déposer vous-même un litige TDRP. Il s'exécute entre les registraires, donc votre registraire dépose en votre nom, dans les douze mois suivant le transfert.
• La prévention est une hygiène de compte, pas un logiciel. Le verrouillage du bureau d'enregistrement et un e-mail de récupération qui ne réside pas sur le domaine couvrent la plupart des cas réels.

Table des matières

Qu'est-ce que le détournement DNS ?

Le DNS (Domain Name System) est le système qui transforme votre nom de domaine en l'adresse du serveur hébergeant votre site. Chaque fois que quelqu'un visite, son navigateur demande à un résolveur DNS où se trouve votredomaine.com, et le résolveur répond avec une adresse IP.

Le détournement de DNS signifie que la recherche renvoie une réponse que vous n'avez pas choisie.

Votre site peut fonctionner parfaitement. Vos fichiers peuvent être complètement intacts. Si la réponse renvoyée pointe ailleurs, vos visiteurs vont ailleurs, et rien dans WordPress ne peut l'arrêter.

Quels sont les quatre types de détournement DNS ?

Il existe quatre types d'attaques de détournement de DNS, et chacune se produit à un endroit différent. L'endroit où l'attaque atterrit détermine qui peut la corriger et comment, donc il vaut la peine de connaître les quatre.

1. Prise de contrôle du compte du bureau d'enregistrement ou de l'hôte DNS. Quelqu'un accède au compte qui contrôle votre domaine et modifie nos serveurs de noms ou notre enregistrement A (l'entrée qui mappe votre domaine à une adresse IP spécifique). Votre site est intact, mais votre domaine pointe maintenant vers le serveur de quelqu'un d'autre.
2. Détournement local ou de routeur. Un logiciel malveillant sur un appareil ou un routeur compromis modifie le résolveur utilisé par cette machine. Seules les personnes sur cet appareil ou ce réseau sont affectées. Tous les autres chargent votre site normalement.
3. Résolveur non fiable ou malhonnête. Le serveur DNS interrogé répond incorrectement à dessein, généralement pour l'injection de publicités ou la censure. C'est généralement hors de votre contrôle.
4. Empoisonnement du cache DNS. De faux enregistrements sont injectés dans le cache d'un résolveur, de sorte qu'il distribue une mauvaise réponse jusqu'à ce que cette entrée mise en cache expire.

Si vous avez lu trois articles à ce sujet et obtenu trois définitions différentes, c'est pourquoi. Le détournement de DNS est le terme générique. Le détournement de domaine et l'empoisonnement du cache DNS sont des cas spécifiques qui s'y rattachent.

S'agit-il d'un détournement DNS ou d'un logiciel malveillant de redirection dans WordPress ?

Les deux problèmes redirigent vos visiteurs vers un site qui n'est pas le vôtre, donc les gens les traitent comme une seule urgence. Ce qui les différencie, c'est l'endroit où la redirection se produit : avant que la requête n'atteigne jamais votre serveur, ou après qu'elle y soit parvenue.

Le logiciel malveillant de redirection vit dans vos fichiers et votre base de données. Votre DNS est correct. Votre domaine est correct. Votre propre serveur transmet aux visiteurs un code empoisonné, exactement comme il a été programmé pour le faire.

Le détournement de DNS ne touche jamais votre installation WordPress. Vos fichiers sont intacts. Le domaine a juste cessé d'y pointer.

Il n'y a aucun chevauchement dans les corrections. L'analyse et le nettoyage d'un site WordPress ne servent à rien lorsque le problème se situe au niveau de votre bureau d'enregistrement. Verrouiller votre bureau d'enregistrement ne sert à rien lorsque le problème est une ligne de JavaScript dans l'en-tête de votre thème.

C'est pourquoi ce qui suit concerne cinq vérifications, pas une simple solution unique.

Pourquoi le détournement DNS affecte-t-il les sites WordPress plus durement que prévu ?

Les dommages évidents d'une attaque DNS sont que les visiteurs atterrissent sur la mauvaise page. Les dommages qui surprennent les gens sont tout le reste qui repose sur ces mêmes enregistrements DNS.

Votre e-mail l'accompagne. Le contrôle du serveur de noms signifie le contrôle des enregistrements MX, et les enregistrements MX sont ce qui achemine le courrier vers votre domaine.

Quiconque possède vos serveurs de noms peut rediriger votre courrier vers un endroit où il sera lu. Cela affecte les réinitialisations de mot de passe, les factures clients et les messages de confirmation de votre bureau d'enregistrement.

Réfléchissez-y une seconde, car cela change la façon dont vous gérez la récupération. Le flux de récupération de compte que vous êtes sur le point de commencer vous envoie probablement un e-mail à votre domaine.

Ensuite, il y a le SSL. Chaque visiteur reçoit un avertissement de certificat, car le serveur vers lequel il a été envoyé ne détient pas de certificat valide pour votre nom. C'est généralement comme ça que vous le découvrez. Quelqu'un vous envoie un e-mail pour vous demander si vous savez que votre site est en panne.

Google explore tout ce vers quoi votre domaine se résout actuellement. S'il s'agit d'une destination de spam ou de logiciels malveillants, votre domaine peut être signalé, et le signalement survit à la correction pendant longtemps.

Les dommages à la réputation durent plus longtemps que la réparation. Les clients qui ont vu une publicité pour une pharmacie sur votre domaine pourraient s'en souvenir même après la correction du DNS.

Les opérations WordPress comportent une exposition supplémentaire que la plupart des sites n'ont pas, et si vous gérez plus d'une poignée de sites, c'est la première chose que j'irais vérifier.

Qu'est-ce que le DNS suspendu et pourquoi les sites WordPress le collectent-ils ?

La façon la plus courante dont une opération WordPress est détournée n'est pas une attaque sophistiquée. C'est un enregistrement que personne n'a pensé à supprimer.

Un enregistrement DNS orphelin pointe vers un service que vous ne contrôlez plus. Le service a été mis hors service, l'hébergement a expiré ou le serveur a été arrêté. L'enregistrement est resté exactement là où il était.

Quiconque peut revendiquer ce service contrôle désormais ce qui se charge sur votre sous-domaine.

Le schéma est facile à repérer une fois que vous le connaissez. Il y a blog.example.com d'une campagne qui s'est terminée il y a deux ans ou dev.example.com d'une refonte. L'hébergement s'est arrêté. L'enregistrement CNAME ne l'a pas fait.

Ouvrez votre fichier de zone et supprimez tout ce qui pointe vers un hôte que vous ne payez plus.

Comment savoir si votre DNS a été détourné ?

Voici comment détecter le détournement de DNS en cinq vérifications. L'ordre est important, car il vous empêche de corriger la mauvaise chose, et le test le moins cher permet d'exclure le plus.

• Vérification 1 : Est-ce que quelqu'un d'autre le voit ? Trente secondes sur données cellulaires vous indiquent si le problème vient de votre domaine ou simplement de votre appareil.
• Vérification 2 : Que disent WHOIS et vos serveurs de noms ? Quatre champs révèlent si quelqu'un a modifié votre domaine et quand il l'a fait.
• Vérification 3 : Différents résolveurs sont-ils d'accord ? Des réponses incorrectes cohérentes signifient que l'enregistrement a été modifié à la source ; des réponses incohérentes signifient une propagation.
• Vérification 4 : Que dit WordPress lui-même ? Les URL du site, .htaccess et les horodatages de modification exposent le code de redirection injecté.
• Vérification 5 : Avez-vous écarté l'explication ennuyeuse ? Les migrations, les domaines expirés et les caches obsolètes en sont la cause plus souvent que les attaques.

Vérification 1 : Quelqu'un d'autre voit-il le problème ?

Ce test unique divise le problème en deux en environ trente secondes, alors exécutez-le avant de toucher quoi que ce soit.

Sortez votre téléphone, désactivez le Wi-Fi et chargez le site via les données cellulaires. Ou demandez à quelqu'un dans une autre ville d'essayer. Si vous ne voulez pas déranger qui que ce soit, un vérificateur de disponibilité tiers chargera votre site à partir de ses propres serveurs.

Si vous êtes le seul à voir le problème, votre domaine est correct. Le problème vient de votre appareil, de votre routeur ou de votre fichier hosts.

Votre fichier hosts mérite une attention particulière. Si vous avez déjà migré un site, vous avez probablement ajouté une entrée dans le fichier hosts pour le prévisualiser sur le nouveau serveur, et il y a de fortes chances que vous ne l'ayez jamais retirée.

Votre ordinateur est toujours invité à envoyer ce domaine vers une ancienne adresse IP. Tout le monde charge le site correctement pendant que vous êtes là, convaincu que vous avez été piraté.

Je me suis fait avoir. Plus d'une fois. Donc, avant de vous lancer dans un dépannage plus approfondi, vérifiez votre fichier hosts.

Vérification 2 : Que disent votre enregistrement WHOIS et vos serveurs de noms ?

Votre enregistrement de registraire est la source de vérité pour savoir qui contrôle le domaine, et il horodate commodément l'attaque pour vous.

Effectuez une recherche WHOIS et lisez quatre champs :

• Serveurs de noms. Ils devraient appartenir à votre hébergeur DNS ou à votre registraire. Si vous ne les reconnaissez pas, passez directement à la section de récupération.
• E-mail du propriétaire. Si celui-ci a été modifié pour une adresse qui ne vous appartient pas, le compte est déjà perdu.
• Date d'expiration. Nous y reviendrons dans un instant, mais regardez-la pendant que vous y êtes.
• Date de mise à jour. C'est le signal le plus clair. Un changement que vous n'avez pas effectué, à une date que vous pouvez indiquer, vous dit ce qui s'est passé et à peu près quand.

Pendant que vous y êtes, regardez les codes d'état EPP. Ce sont des indicateurs standardisés que le registre de domaine conserve sur votre domaine, et celui que vous voulez voir est clientTransferProhibited. C'est le verrouillage du registraire, et il bloque les demandes de transfert au niveau du registre avant qu'elles n'aillent plus loin.

Un verrou manquant associé à une date de mise à jour récente est la pire combinaison sur cette page.

Encore une chose avant de paniquer. Vérifiez si le domaine n'a pas simplement expiré. Un domaine expiré produit un symptôme identique à un piratage.

Vérification 3 : Différents résolveurs DNS donnent-ils la même réponse ?

Cette vérification vous indique si l'enregistrement a été modifié ou si quelque chose entre les deux vous ment.

Sur macOS ou Linux, interrogez votre résolveur par défaut, puis un résolveur public spécifique, puis regardez directement vos serveurs de noms :

dig example.com +short

dig @8.8.8.8 example.com +short

dig example.com NS +short

Sur Windows, nslookup fait le même travail :

nslookup example.com

nslookup example.com 8.8.8.8

Si les terminaux ne sont pas votre tasse de thé, un vérificateur de propagation DNS mondial interrogera des résolveurs dans une douzaine de pays et vous montrera toutes les réponses côte à côte.

Ensuite, lisez ce qui revient :

• Tous les résolveurs s'accordent sur une IP qui n'est pas la vôtre. L'enregistrement a été modifié à la source. C'est un vrai piratage, ou un changement que quelqu'un de votre équipe a effectué et a oublié de mentionner.
• Les réponses divergent selon la région. La propagation est toujours en cours, ce qui signifie presque toujours un changement que vous ou votre hébergeur avez effectué récemment.
• Un réseau est en désaccord avec tous les autres. Interférence locale ou au niveau du FAI, ce qui vous ramène à la vérification 1.

Vérification 4 : Que dit WordPress ?

Si le DNS revient propre, le problème se situe à l'intérieur de votre installation, et vous chassez maintenant le code injecté.

Commencez par les URL de votre site. Allez dans Paramètres » Général et comparez Adresse WordPress (URL) et Adresse du site (URL) avec votre domaine réel.

Si vous ne parvenez pas à vous connecter, ces mêmes valeurs se trouvent dans les lignes siteurl et home de la table wp_options, et vous pouvez les lire via phpMyAdmin ou WP-CLI.

Vérifiez les infections de fichiers comme la plupart :

• .htaccess, pour les règles de redirection que vous n’avez pas écrites
• wp-config.php
• index.php, surtout tout en haut du fichier
• Les fichiers d’en-tête et de pied de page de votre thème actif

Triez tout par date de modification pendant que vous y êtes. La plupart des infections laissent un groupe d’horodatages du même après-midi, et ce groupe est généralement la carte entière.

Un comportement envoie les gens sur la mauvaise voie du DNS, et il est bon de le savoir. De nombreux malwares de redirection se déclenchent conditionnellement. Ils ne se déclenchent que pour les visiteurs sur mobile, ou seulement pour les personnes arrivant d’un résultat de recherche, et ils laissent les visites directes complètement indemnes.

Vous tapez donc votre domaine, le site se charge parfaitement, et vous concluez que le problème doit se situer en dehors de WordPress.

Ce n’est pas le cas. Le DNS n’a aucune idée de l’appareil qui demande ou de l’origine d’un visiteur. Seul le code exécuté sur votre serveur peut faire la différence.

C’est à ce moment qu’un scanner de logiciels malveillants gagne son argent. C’est aussi la seule façon dont la restauration d’une sauvegarde propre résout le problème.

Vérification 5 : Avez-vous écarté les explications banales ?

Avant d’aggraver quoi que ce soit, passez deux minutes sur les causes qui ne sont pas des attaques du tout :

• Une migration dans les dernières 48 heures qui est encore en cours de propagation
• Un domaine qui a expiré ou un paiement de renouvellement automatique qui a échoué silencieusement
• Un CDN ou un proxy inverse pointe toujours vers votre ancien serveur d’origine
• Cache de navigateur obsolète, cache DNS obsolète ou une entrée dans le fichier hosts

Videz votre cache DNS local et réessayez dans une fenêtre privée avant de tirer des conclusions.

À ce stade, vous avez l’enregistrement WHOIS et les réponses du résolveur devant vous. C’est ce dont vous avez besoin pour distinguer un délai de propagation d’un changement réel.

Référence rapide : symptômes, causes et correctifs du détournement DNS

Si vous êtes en pleine panne et que vous voulez la version courte, trouvez votre symptôme de détournement de DNS dans la colonne de gauche.

Ce que vous voyez	Cause la plus probable	Ce qui le résout	La restauration d’une sauvegarde aide-t-elle ?
Vous seul voyez le mauvais site	DNS local, routeur ou fichier hosts	Videz le DNS, vérifiez le routeur, modifiez le fichier hosts	Non
Tout le monde voit une page de stationnement ou une page non pertinente	Prise de contrôle du compte d’enregistreur ou de DNS	Récupérez le compte d’enregistreur	Non
Le site se charge mais redirige vers du spam pour certains visiteurs	Malware de redirection WordPress	Nettoyer les fichiers et la base de données, ou restaurer une sauvegarde propre	Oui
Mauvais site juste après un changement d'hôte	Propagation ou enregistrement obsolète	Attendre, ou corriger l'enregistrement A	Non
Le site a disparu et WHOIS semble incorrect	Domaine expiré ou transfert non autorisé	Renouveler, ou ouvrir un litige auprès de votre bureau d'enregistrement	Non

Comment récupérer un domaine piraté ?

Savoir comment résoudre le détournement de DNS relève principalement de l'ordre des opérations, pas de la vitesse, et la première heure vaut plus que la semaine qui suit.

Je serai honnête sur le calendrier dès le départ. Si le domaine est toujours chez votre bureau d'enregistrement, cela prend des heures. S'il a été transféré, prévoyez des semaines.

Réintégrez d'abord le compte du registraire

Rien de ce que vous faites n'a d'importance tant que vous ne contrôlez pas le compte qui contrôle votre domaine.

Commencez la récupération directement auprès du bureau d'enregistrement, pas par e-mail. Si vos enregistrements MX ont suivi vos serveurs de noms, votre courrier est acheminé via le domaine compromis, et une réinitialisation de mot de passe atterrit dans la boîte de réception de quelqu'un d'autre.

Appelez-les. Les bureaux d'enregistrement conservent le support téléphonique exactement pour cela, et un appel téléphonique est hors bande, ce qui signifie qu'il ne transite pas par quelque chose que l'attaquant contrôle.

Ayez votre preuve prête avant de composer le numéro : reçus d'enregistrement originaux, relevés de facturation, relevés de carte montrant les renouvellements, anciennes factures avec le domaine. Le support vous le demandera, et l'avoir devant vous réduit le processus de plusieurs heures.

Lorsque vous récupérez l'accès, notez ce qui a changé et quand vous l'avez remarqué. Vous en aurez besoin dans une minute.

Verrouillez-le une fois que vous êtes de retour

Quelqu'un qui est entré une fois essaiera la même porte deux fois, alors fermez-les toutes avant de faire quoi que ce soit d'autre.

• Activez le verrouillage du bureau d'enregistrement et confirmez que clientTransferProhibited apparaît dans votre enregistrement WHOIS.
• Activez l'authentification à deux facteurs séparément sur votre bureau d'enregistrement et votre hôte DNS.
• Réinitialisez le code EPP, également appelé code d'autorisation. C'est le mot de passe requis pour déplacer un domaine entre les bureaux d'enregistrement, et sa réinitialisation invalide toute copie que l'attaquant aurait faite.
• Déplacez l'e-mail de contact du registraire vers une adresse qui ne réside pas sur ce domaine.
• Auditez chaque enregistrement DNS, pas seulement celui qui a changé. Vérifiez spécifiquement vos enregistrements MX, car la redirection de courrier est beaucoup plus discrète que la redirection de site et peut fonctionner pendant des semaines avant que quelqu'un ne s'en aperçoive.

Et si le domaine a déjà été transféré à un autre registraire ?

C'est le cas difficile, et il est plus lent et moins sous votre contrôle.

Si votre domaine a déjà été transféré, contactez immédiatement votre bureau d'enregistrement perdant. C'est celui avec lequel vous étiez avant le transfert, et c'est la partie qui a qualité pour agir.

La politique de résolution des litiges de transfert de registrars de l'ICANN, la TDRP, est un litige entre registrars. Le plaignant est soit le registrar perdant, soit le registrar gagnant. Vous ne pouvez pas en déposer une vous-même en tant que propriétaire du domaine.

De nombreux articles disent aux lecteurs de déposer une TDRP, et si vous cherchez ce formulaire, il n'y en a pas pour vous. Ce que vous faites à la place, c'est de remettre vos preuves à votre registrar perdant et de lui demander de déposer en votre nom.

Deux calendriers sont à connaître :

• La date limite de dépôt est de douze mois après la violation alléguée. Après cela, le transfert est maintenu, quelle que soit la manière dont il s'est produit.
• Les bureaux d'enregistrement sont censés essayer de le résoudre entre eux d'abord, avant que la procédure formelle ne s'applique.

Une règle joue en votre faveur. Lorsque les informations de contact de l'enregistrant changent, l'ICANN exige un verrouillage de 60 jours qui empêche le domaine d'être transféré à nouveau. Il vise à empêcher le passage rapide d'un bureau d'enregistrement à l'autre, et cela signifie qu'un voleur ne peut généralement pas continuer à éloigner votre domaine pendant que vous le poursuivez.

Attendez-vous à des semaines. La documentation que vous avez rassemblée lors de la première heure est ce qui fait gagner cette bataille.

Reconstruisez sur une infrastructure propre pendant que vous attendez

La bataille pour le domaine et la reconstruction du site sont deux pistes distinctes, et il n'y a aucune raison de les exécuter l'une après l'autre.

Supposez que votre compte d'hébergement puisse également être compromis, surtout s'il partageait un mot de passe ou un e-mail de récupération avec votre bureau d'enregistrement. Quiconque y est parvenu a presque certainement essayé les deux.

Alors ne reconstruisez pas sur place. Prenez une sauvegarde d'avant l'incident et mettez le site en ligne sur un serveur auquel l'attaquant n'a jamais eu accès.

C'est là qu'une sauvegarde portable est essentielle. L'installateur autonome de Duplicator installe votre site complet sur un serveur vierge sans nécessiter l'installation préalable de WordPress.

Vous aurez juste besoin d'une sauvegarde précédemment enregistrée. Téléchargez les deux fichiers de sauvegarde sur le nouveau serveur et lancez l'installateur de Duplicator.

Ajoutez une entrée dans le fichier hosts de votre propre machine redirigeant votre vrai domaine vers l'IP du nouveau serveur, et chargez le site. Vous testez le domaine réel contre le nouveau serveur en privé, pendant que tout le monde voit toujours ce qui est servi en votre nom.

Notre guide pour déplacer un site WordPress vers un nouvel hébergeur détaille cette étape.

Lorsque le contrôle DNS revient, vous ne commencez pas une reconstruction. Vous modifiez un enregistrement A pour qu'il pointe vers un serveur déjà testé et déjà propre.

Ce qu'une sauvegarde peut et ne peut pas faire contre le détournement de DNS

Lorsque quelque chose de grave arrive à votre site, le premier réflexe est de restaurer une sauvegarde. Cependant, même les sauvegardes de site ont leurs limites.

Ce qu'une sauvegarde ne peut pas corriger :

• Un domaine volé. Votre domaine ne se trouve pas dans votre sauvegarde. C'est un enregistrement détenu par un bureau d'enregistrement, et aucune archive nulle part ne le contient.
• Un changement de serveur de noms ou d'enregistrement A. Ces enregistrements résident dans le DNS chez votre hébergeur DNS, pas dans vos fichiers de site.
• Un résolveur malveillant sur le routeur d'un visiteur. C'est son appareil, pas votre serveur.
• Empoisonnement du cache chez un FAI. Rien de votre côté ne l'atteint.

Si votre domaine a été détourné, restaurer la sauvegarde d'hier soir n'aboutit à rien. Le site n'a jamais été le problème. Vous vous retrouverez avec une copie parfaite d'un site que personne ne peut atteindre.

Maintenant, l'autre moitié, car une sauvegarde n'est pas inutile ici non plus :

• Elle corrige la branche de malware de redirection, et c'est la cause la plus fréquente du même symptôme
• Elle vous donne une copie connue comme étant saine à mettre en ligne ailleurs dès que vous reprenez le contrôle
• Elle vous permet de quitter un hébergement compromis en un après-midi au lieu de négocier avec lui pendant une semaine
• Cela prouve à quoi ressemblait votre site avant l'incident, ce qui est important pour les clients, les assureurs et toute personne posant des questions plus tard.

Alors sauvegardez votre site, car cela offre une sécurité énorme. Sachez simplement qu'une sauvegarde ne peut pas annuler un détournement de DNS.

Comment prévenir le piratage DNS ?

Apprendre à arrêter le détournement de DNS de WordPress relève presque entièrement de l'hygiène du compte, pas du logiciel. Il n'y a pas de plugin pour cela, c'est probablement pourquoi cela est négligé.

Voici comment sécuriser le DNS de votre site Web :

• Verrou du registraire. Activez clientTransferProhibited et confirmez-le dans WHOIS plutôt que de faire confiance au basculement dans votre tableau de bord. S'il n'apparaît pas, c'est votre première tâche aujourd'hui.
• Authentification à deux facteurs sur le registraire et l'hôte DNS. Comptes séparés, connexions séparées, 2FA séparé. Utilisez une application ou une clé matérielle au lieu des SMS, car le changement de carte SIM est un chemin bien connu pour accéder à ce type de compte.
• Un e-mail du registraire qui ne réside pas sur le domaine. Presque tout le monde se trompe sur ce point, et c'est la différence entre un mauvais après-midi et un mauvais mois. Si votre connexion au registraire est vous@votredomaine.com, alors perdre le domaine et perdre votre boîte de réception de récupération se produisent au même instant. Utilisez une adresse sur un domaine complètement différent, et configurez-la maintenant, car l'ajouter après coup ne vous sera d'aucune utilité.
• Renouvellement automatique avec une carte qui n'est pas expirée. Un domaine expiré ressemble à un détournement, est volé tout aussi rapidement et se produit beaucoup plus souvent. Vérifiez la carte enregistrée une fois par an.
• Verrouillage du registre pour les domaines que vous ne pouvez pas vous permettre de perdre. Il se situe un cran au-dessus du verrou du registraire. Les modifications nécessitent une vérification manuelle et hors bande, de sorte qu'un attaquant détenant votre mot de passe ne peut toujours rien déplacer. La plupart des registrars facturent pour cela, et pour un domaine professionnel, c'est bon marché.
• DNSSEC, avec des attentes réalistes. Il signe vos enregistrements DNS cryptographiquement afin qu'un résolveur puisse vérifier qu'ils n'ont pas été falsifiés pendant le transit, ce qui couvre l'usurpation de DNS et l'empoisonnement du cache. Il ne fait rien si quelqu'un se connecte à votre registraire et modifie légitimement les enregistrements. Activez-le ; ne le classez pas sous traité.
• Audit trimestriel des enregistrements DNS. Ouvrez votre fichier de zone et supprimez tout ce qui pointe vers un service que vous ne contrôlez plus. C'est le problème du DNS pendant suspendu mentionné précédemment, et quinze minutes par trimestre le résolvent.
• Moins de personnes ayant un accès au registraire. Chaque connexion supplémentaire est une autre voie d'accès. Les sous-traitants qui sont partis, les agences avec lesquelles vous avez cessé de travailler, l'ancien membre de l'équipe dont le compte n'a jamais été désactivé.

Deux de ces éléments portent le plus de poids : le verrou du registraire et l'e-mail hors domaine. Si vous ne faites que deux choses cette semaine, faites celles-ci.

Questions fréquemment posées (FAQ)

Votre domaine est la seule chose que vous ne pouvez pas restaurer

Vous possédez vos fichiers et votre base de données. Vous louez votre domaine.

C’est facile à oublier, car un domaine ressemble à une propriété jusqu’au moment où quelqu’un d’autre le détient.

Le diagnostic des attaques de détournement DNS peut être rapide. Trente secondes sur votre téléphone, désactivé le Wi-Fi, élimine la moitié des possibilités, et une recherche WHOIS s’occupe du reste.

La récupération peut être difficile. Si le domaine a bougé, vous attendez que deux registraires se parlent, et vous ne pouvez pas faire grand-chose pour les presser. Pour éviter de futurs problèmes, je recommande de passer un après-midi à renforcer la sécurité de votre DNS.

Reconstruisez rapidement, quoi qu'il arrive à votre domaine

Un litige DNS est un combat que vous pourriez gagner en une semaine. Votre site ne devrait pas rester inaccessible en attendant le résultat. La partie que vous contrôlez entièrement est d’avoir une copie propre et portable prête à être déployée au moment où vos enregistrements reviennent.

Duplicator Pro s’occupe de cet aspect. Vous obtiendrez des sauvegardes complètes automatisées du site, un installateur autonome qui dépose votre site sur un serveur vierge sans WordPress préinstallé, des restaurations en un clic et une URL de récupération d’urgence qui fonctionne même lorsque WordPress est verrouillé.

Plus de 1,5 million de professionnels WordPress utilisent Duplicator, et il a plus de 4 000 avis cinq étoiles. Chaque plan payant est assorti d’un remboursement de 14 jours, sans poser de questions.

Si cet article vous a fait réfléchir à la façon dont votre domaine et votre site sont réellement exposés, ces guides méritent d’être lus ensuite.

• Comment protéger votre site WordPress contre les pirates
• Checklist de sécurité WordPress : Guide étape par étape pour protéger votre site
• 4 plugins WordPress de suppression de logiciels malveillants qui nettoient les fichiers infectés (pas seulement les signalent)
• Pourquoi votre site WordPress est bloqué dans une boucle de redirection (et comment je l'ai résolu en 5 minutes)
• Comment créer un site de staging WordPress (pour des tests en toute sécurité)