Protéger vos noms de domaine: faire les premiers pas – Serveur d’impression

Tout le monde et tout sur Internet dépendent du fonctionnement du DNS (Domain Name System). Le DNS a été un vecteur commun d'attaques ces dernières années, et 2019 ne semble pas être différent. Beaucoup de ces attaques ont des objectifs bien plus sinistres que de simplement mettre une entreprise hors ligne ou de détruire un site Web; les attaques signalées incluent la redirection de tout ou partie du domaine d'une organisation pour accéder aux ressources protégées, intercepter le trafic et même obtenir des certificats TLS pour ce domaine. Les organisations doivent effectuer des examens et des audits DNS réguliers. Les directives suivantes fournissent un point de départ pour votre examen.

Le DNS est essentiel pour toute organisation ayant une présence en ligne. L'attaque des noms de domaine est une méthode notable pour dénier le service (DoS), altérer, abuser ou autrement endommager toute organisation connectée à Internet. Les noms de domaine représentent non seulement votre marque, mais la façon dont vos clients interagissent avec votre entreprise. Dans le monde d'aujourd'hui, les noms de domaine sont essentiels pour le Web, la voix, la vidéo, le chat, les API et tous les autres services que votre entreprise peut offrir ou consommer. En bref, le contrôle de vos noms de domaine est essentiel à votre entreprise.

L'une des menaces les plus négligées à votre présence DNS est la négligence. De nombreuses organisations tiennent leur configuration DNS pour acquise, la configurant une fois et la laissant pour toujours. Les adversaires tirent parti de cette négligence et des faiblesses qui en résultent. La réalisation d'examens et d'audits DNS réguliers est une mesure préventive essentielle.

Les adversaires peuvent attaquer une architecture DNS via le Zone racine DNS, les Registres DNS / domaines de premier niveau (TLD) (par exemple .com, .net, .uk, .jp), le bureaux d'enregistrement de noms de domaine, les Inscrits de noms DNS (l'entité pour laquelle la zone est déléguée), le Fichiers de zone DNS, les faisant autorité Serveurs de noms DNS, et résolveurs DNS récursifs. Les attaquants peuvent également détourner des routes vers – ou usurper des adresses IP de – serveurs DNS. Comme vous pouvez le voir, il s'agit d'une large surface d'attaque. La bonne nouvelle est que le DNS est conçu pour être robuste et que de nombreuses organisations se concentrent sur la sécurité, la stabilité et la résilience du DNS.

Le premier domaine d'intérêt est l'administration de la zone DNS (par exemple example.com). L'administration de la zone DNS est un domaine que de nombreuses organisations négligent dans leurs audits de sécurité et de réseau. Ne sous-estimez pas la portée et les dommages potentiels d'une attaque: l'accès à une zone et / ou au bureau d'enregistrement permet de rediriger les e-mails entrants, d'acheminer le trafic via un hôte contrôlé par un attaquant et même d'obtenir des certificats TLS.

Le registraire de nom de domaine et le fichier de zone DNS

Entre autres choses, le registraire des noms de domaine contrôle la liste des serveurs de noms faisant autorité d'un domaine, ou «délégations». Ces délégations sont constituées des noms d'hôte et des adresses IP des serveurs DNS faisant autorité pour le domaine en question. Les serveurs DNS faisant autorité ont une copie du fichier de zone maître et répondent aux requêtes DNS avec le bit "réponse faisant autorité". La montée des attaques à grande échelle ces dernières années a changé la façon dont les propriétaires de domaine exploitent leurs serveurs de noms faisant autorité. Historiquement, la plupart des organisations exploitaient leurs serveurs de noms faisant autorité sur leurs propres systèmes. Aujourd'hui, les organisations ont plus d'options. Certains bureaux d'enregistrement de noms de domaine proposent des packages de services complets dans lesquels le bureau d'enregistrement opère et gère la configuration DNS complète d'un domaine. Par exemple, des fournisseurs basés sur le cloud tels que Fast DNS d'Akamai offrent une meilleure résilience aux attaques DDoS et une gestion simplifiée de l'infrastructure.

Les articles de presse, les équipes d'intervention en cas d'urgence informatique (CERT) et les avis du gouvernement peuvent vous inciter à «faire un audit DNS», mais les conseils s'arrêtent souvent là. Le reste de cet article est une collection de sujets qu'une organisation devrait examiner pour évaluer sa position DNS actuelle. Ces recommandations sont basées sur l’expérience d’Akamai, les travaux du Comité consultatif de sécurité et de stabilité (SSAC) de l’ICANN, du Centre d’opérations, d’analyse et de recherche DNS (DNS-OARC) et d’autres experts du DNS.

Examiner l'accès aux bureaux d'enregistrement de noms de domaine

Examinez les administrateurs de domaine actuels de votre organisation tels que vus par votre bureau d'enregistrement et assurez-vous qu'ils correspondent à vos attentes. Passez en revue tous les domaines configurés avec votre bureau d'enregistrement et assurez-vous que vous savez qui dans votre organisation a accès au portail en ligne du bureau d'enregistrement. Confirmez à ces utilisateurs qu'ils ont accès au portail en ligne du bureau d'enregistrement. Si vous avez des domaines enregistrés auprès de plusieurs bureaux d'enregistrement, assurez-vous de répéter cet exercice pour chaque bureau d'enregistrement. Vous voudrez peut-être envisager de consolider vos inscriptions avec un seul registraire. De plus, profitez-en pour vérifier que tous vos domaines sont pris en compte dans votre audit des bureaux d'enregistrement – quelqu'un peut avoir enregistré un domaine à l'aide d'un compte personnel, ce qui pourrait entraîner une perte de contrôle s'il quitte votre organisation.

Les adversaires profiteront de la négligence DNS d'une organisation. Ils trouveront des comptes qui ne sont pas correctement tenus et les compromettent. Examiner, mettre à jour et documenter qui a accès à chaque zone de chaque bureau d'enregistrement est la première étape.

Examiner les rôles et responsabilités DNS

Une bonne directive pour la sécurité est le principe de le moins d'accès: les gens devraient avoir le niveau d'accès le plus bas requis pour faire leur travail. Les utilisateurs ayant accès au registraire sont-ils les personnes dont la fonction nécessite cet accès? En plus d'un examen unique, planifiez un examen récurrent du niveau d'accès de chacun. Assurez-vous également qu'au moins deux personnes ont accès à chaque portail de registraire; si l'un des administrateurs devait partir, la perte d'accès pourrait être catastrophique pour une organisation.

N'oubliez pas que les attaquants utilisent souvent les médias sociaux dans le cadre de tentatives de phishing. Ils peuvent facilement cibler des employés de haut niveau sur les plateformes de médias sociaux, sachant que les organisations peuvent oublier de supprimer l'accès du bureau d'enregistrement après les réorganisations, les licenciements ou la retraite.

Transitions des employés

Le processus de pré-résiliation d’une organisation doit inclure un examen des rôles des utilisateurs. Dans le cadre de cet examen, l'organisation doit auditer l'accès des employés aux ressources telles que les comptes de registraire ou les fournisseurs de cloud DNS, et mettre fin à tout accès. L'accès devrait être accordé à un employé remplaçant ou successeur dès que possible.

Le processus de licenciement devrait également déclencher la rotation ou la révocation de tous les secrets auxquels l'employé au départ avait accès. En plus des mots de passe, cela devrait inclure des jetons d'authentification à deux facteurs (2FA), des phrases de passe d'authentification verbale et toutes les listes d'employés autorisés que le registraire peut avoir dans le dossier. Ces changements devraient être une pratique courante, quelles que soient les circonstances du départ de l’employé. Ils ne salissent pas l'employé qui part, mais reflètent plutôt la menace qui pèse sur l'organisation.

Mettre à jour toutes les informations d'inscription

Ensuite, regardez les informations de contact associées à vos noms de domaine enregistrés. Assurez-vous que les dates d'expiration de chaque nom de domaine sont suffisamment éloignées à l'avenir (au moins un an est un objectif recommandé) et que toutes les options, telles que le renouvellement automatique, sont définies de manière appropriée. Un nom de domaine qui expire de manière inattendue peut entraîner des coûts financiers importants et, dans le pire des cas, peut être irrémédiablement perdu ou enregistré par un concurrent.

Les domaines ont également généralement quatre points de contact: le inscrit, technique, administratif, et facturation Contacts. Votre registraire peut envoyer certains types de communication à un seul de ces rôles, et dans certains cas, le contact du déclarant a généralement la priorité. Assurez-vous que toutes les informations de contact sont à jour – les mises à jour des contacts sont souvent ignorées lorsque les organisations grandissent, se réduisent, se déplacent ou sont acquises.

Utiliser des rôles pour les informations d'enregistrement de domaine

Pour faciliter la gestion des informations de contact d'enregistrement de domaine, les organisations utilisent souvent un compte de rôle pour les quatre contacts de domaines requis. La mise en œuvre du compte de rôle diffère d'une organisation à l'autre, mais l'idée de base est d'avoir une liste de diffusion strictement restreinte à laquelle toute la correspondance d'enregistrement de domaine peut être envoyée. Souvent, les rôles seront nommés «Administrateur de domaine» ou «Hostmaster» avec les coordonnées du siège social de l'organisation répertoriées pour l'adresse, le téléphone et le numéro de fax. Assurez-vous que les appels téléphoniques et les télécopies légitimes dirigés vers ces numéros parviendront toujours à l'administrateur DNS. L'utilisation d'un rôle plutôt que d'une personne nommée permet de modifier les responsabilités professionnelles ou d'ajouter et de supprimer des personnes sans que des mises à jour majeures ne se produisent au niveau du registraire. Si vous utilisez une liste de diffusion, votre audit régulier doit examiner les employés inscrits à la liste de diffusion pour limiter les abus potentiels.

N'utilisez pas d'adresses électroniques personnelles

Les adresses e-mail personnelles ne doivent jamais être utilisées comme points de contact pour les administrateurs de domaine d'entreprise, gouvernementaux ou organisationnels. Dans le cadre du processus d'examen, assurez-vous que les adresses e-mail personnelles ne sont jamais utilisées pour les informations de contact du domaine ou les comptes d'accès du registraire.

• L'utilisation de l'adresse e-mail personnelle d'un employé (par exemple, joe@gmail.com) comme point de contact confie efficacement le contrôle du domaine à cet employé. En plus du fait que vous ne savez pas quel type de pratiques de sécurité vos employés utilisent sur leurs comptes de messagerie personnels, vous vous exposez à des mesures de représailles de la part d'un employé mécontent ou actuel. Tous vos points de contact de domaine doivent inclure des adresses e-mail contrôlées par votre organisation ou une organisation mère.

• Il faut également éviter d'utiliser l'adresse e-mail de l'organisation ou de l'entreprise d'un employé (par exemple, jane.q.smith@examplecompany.com). Fournir les noms des personnes impliquées dans l'administration des noms de domaine d'entreprise les expose à un risque accru d'ingénierie sociale et d'attaques de spear phishing visant l'entreprise. Utilisez plutôt des noms basés sur les rôles ou les départements (par exemple hostmaster-technical@example.com, hostmaster-billing@example.com), idéalement avec plusieurs utilisateurs recevant des communications envoyées à ces adresses.

Protéger contre les attaques de phishing

Le phishing est l'une des principales attaques utilisées pour compromettre les comptes des bureaux d'enregistrement. Il faut s'attendre à des attaques de phishing contre vos administrateurs DNS, donc une défense complète contre le phishing est impérative. La suite suivante de techniques anti-phishing peut fournir une protection efficace contre les attaques de phishing.

• Utilisez des adresses e-mail génériques, basées sur des rôles ou des départements, telles que domain_admin@example.com. Les e-mails de phishing qui arrivent dans un compte basé sur les rôles sont souvent plus faciles à repérer pour les administrateurs.
• Incluez une formation anti-phishing dans votre examen annuel de la sécurité et demandez à tous les administrateurs DNS de suivre la formation.
• Déployez un logiciel de sécurité des points d'extrémité et appliquez des politiques de sécurité sur tous les appareils utilisés par les administrateurs DNS (ainsi que tous les membres de votre organisation).
• Déployez un service de filtrage des e-mails pour empêcher certaines attaques de phishing et de logiciels malveillants courantes sur vos administrateurs DNS ainsi que sur le reste de votre organisation.
• Filtrez les requêtes DNS pour empêcher les employés de visiter des sites de phishing connus. Des outils tels que Enterprise Threat Protector (ETP) d'Akamai offrent une sécurité d'entreprise au niveau DNS.

Il n'y a pas de «solution miracle» pour arrêter les attaques de phishing, mais l'adoption de la bonne combinaison de défenses pour votre organisation contribuera à limiter le risque.

Mises à jour des informations d'identification – Modifier les mots de passe

Les changements de mot de passe réguliers sont une bonne pratique pour tous les comptes en ligne, et les comptes d'enregistrement de nom de domaine ne font pas exception. Lorsque vous effectuez un audit de votre infrastructure DNS, demandez à tous ceux qui ont accès au bureau d'enregistrement de faire pivoter leurs informations d'identification. Bien que votre organisation puisse avoir une politique de mot de passe complète, il est courant d'oublier les services externes comme votre registraire. Les comptes externes doivent être soumis à vos directives internes de sécurité par mot de passe et à votre calendrier de rotation. Les mots de passe des comptes de registraire doivent être longs et complexes; l'utilisation d'un gestionnaire de mots de passe peut faciliter la génération et le stockage de mots de passe complexes de manière chiffrée, redondante et trouvable. Les mots de passe ne doivent jamais être écrits ou stockés sous une forme non cryptée.

Authentification à deux facteurs (2FA) pour les comptes de registraire

Lorsqu'elle est prise en charge par votre registraire, l'authentification à deux facteurs (2FA) doit être requise pour tous les comptes. Avec 2FA, toute personne tentant de se connecter au bureau d'enregistrement aura besoin non seulement du mot de passe du compte, mais d'un deuxième facteur tel qu'une application pour smartphone ou un jeton matériel. 2FA peut contrecarrer ce qui aurait pu être une tentative de phishing réussie.

Dans la mesure du possible, les 2FA basés sur SMS doivent être évités. Le 2FA basé sur SMS est toujours meilleur que les comptes sécurisés uniquement avec des mots de passe, mais d'autres méthodes telles que les mots de passe à usage unique basés sur le temps (TOTP), les jetons matériels ou le 2FA basé sur les push doivent être préférés. Les nouvelles directives d'identité numérique du NIST recommandent que les SMS faisant partie de 2FA soient déconseillés (voir la publication spéciale NIST 800-63B).

Si votre registraire ne prend pas en charge 2FA, demandez cette fonctionnalité. S'ils ne sont pas réceptifs à vos préoccupations, envisagez d'explorer d'autres bureaux d'enregistrement. Dans de nombreux cas, il existe des bureaux d'enregistrement de domaine concurrents pour les mêmes TLD, ccTLD et gTLD.

Comprendre les politiques, outils et processus de sécurité du registraire

Il existe des centaines de bureaux d'enregistrement de noms de domaine dans le monde qui prennent en charge plus de 1 500 TLD. Certains bureaux d'enregistrement ont de meilleures pratiques de sécurité que d'autres. Votre organisation peut aider à orienter l'industrie vers de meilleures pratiques. Découvrez les pratiques et politiques de sécurité de votre bureau d'enregistrement en consultant leur documentation en ligne. Si vous ne parvenez pas à trouver ces informations, ouvrez un dialogue avec votre registraire et encouragez-les à publier ces informations.

Par exemple, votre registraire fournit-il les services d'assistance dont vous avez besoin pour exploiter votre domaine? Le registraire offre-t-il une assistance technique 24h / 24 et 7j / 7 qui permet le dépannage en dehors des heures ouvrables? La politique de l'ICANN exige que votre registraire actuel vous informe de toute demande de transfert de domaine qu'il reçoit du registre, indiquant que quelqu'un a demandé de transférer le domaine vers un nouveau registraire. Votre registraire enverra-t-il ces informations uniquement par e-mail ou avez-vous la possibilité de les demander par téléphone ou par fax? Votre registraire envoie-t-il des notifications pour toutes les autres mises à jour de vos domaines? Comité consultatif de l'ICANN sur la sécurité et la stabilité (SSAC) travaille avec la communauté de l'ICANN pour fournir des conseils opérationnels et de sécurité sur le DNS. Mesures SAC 40 de l'ICANN pour protéger les services d'enregistrement de domaine contre l'exploitation ou la mauvaise utilisation et SAC 44 Guide du titulaire pour la protection des comptes d'enregistrement de noms de domaine sont d'excellents guides pour comprendre et évaluer les pratiques de sécurité d'un registraire.

Consultez les options d'enregistrement de confidentialité

De nombreux bureaux d'enregistrement de noms de domaine offrent des services d'enregistrement de confidentialité ou de proxy. Ces services cacheront vos informations de contact personnelles au public et les remplaceront par des informations de contact de plainte ICANN. Le règlement général sur la protection des données (RGPD) de l'Union européenne (UE) a modifié la façon dont les informations sont publiées dans les bases de données d'enregistrement de domaine comme WHOIS. En règle générale, une approche basée sur les rôles des informations sur le titulaire de domaine est un moyen d'être compatible avec le RGPD tout en fournissant à la communauté des informations de contact à jour sur votre domaine.

Remarque: Dans certains cas, le proxy ou l'enregistrement de confidentialité entraverait le processus de vérification requis pour obtenir les certificats SSL / TLS de validation d'organisation (OV) et de validation étendue (EV). Le processus d'activation ou de désactivation de l'enregistrement proxy ou de la confidentialité peut varier selon le bureau d'enregistrement et les délais doivent être bien compris avant de souscrire à ces services. Les retards dans la désactivation de l'enregistrement de la confidentialité peuvent entraîner des échecs de rotation des certificats ou des retards dans les transferts de domaine si l'un ou l'autre est nécessaire. Ces risques doivent être examinés attentivement.

Examinez et conservez les enregistrements dans votre zone

Les zones DNS contiennent de nombreux noms d'hôte et sous-domaines, mais de nombreux administrateurs DNS peuvent ne pas savoir quel service ou unité commerciale est responsable d'une entrée donnée. UNE nom d'hôte fait référence à un enregistrement avec un type tel que A, AAAA, CNAME, TXT, entre autres. UNE sous-domaine est indiqué par la présence d'enregistrements NS et délègue le contrôle de cette partie de votre zone à une zone d'un autre serveur de noms.

Les administrateurs DNS doivent savoir quels groupes ou équipes sont responsables de chaque entrée dans le fichier de zone de leur organisation. Si votre organisation utilise un système de suivi des tickets interne, les informations peuvent y être stockées, mais il peut ne pas être facile d'y accéder à court terme. S'assurer que vous suivez avec précision les modifications de la zone au fil du temps peut nécessiter des mises à jour de vos processus internes. Une fois que vous pouvez identifier la partie responsable de chaque entrée dans votre fichier de zone, vous devez effectuer des révisions périodiques et vous assurer que les enregistrements sont toujours nécessaires. La vérification de la propriété de chaque nom d'hôte et sous-domaine et la suppression des entrées obsolètes doivent faire partie d'un audit DNS normal.

Des enregistrements peuvent être ajoutés rapidement pour de nouvelles applications, de nouveaux services ou des démonstrations en direct, mais ces enregistrements peuvent persister longtemps après la fermeture ou la migration des services en question. Dans le cadre du cycle de vie de votre produit interne, assurez-vous qu'une attention suffisante est accordée à la mise hors service d'un service et que le processus de mise hors service inclut la notification à l'administrateur DNS qu'un nom d'hôte ou un sous-domaine n'est plus nécessaire.

Portez une attention particulière aux sous-domaines délégués, car ils sont conçus pour céder le contrôle d'une partie de votre zone à un autre serveur de noms. Assurez-vous que les enregistrements NS sont exacts et qu'ils fournissent toujours des réponses faisant autorité pour le sous-domaine. Si votre organisation délègue un sous-domaine à un fournisseur DNS tiers, il est encore plus important de vérifier fréquemment les réponses des sous-domaines délégués, car le fournisseur externe peut réutiliser ces adresses IP sans vous en informer, son client. Si une zone est déléguée à un serveur de noms exploité par votre organisation dans un fournisseur de cloud tiers, assurez-vous de suivre les modifications d'adresse IP et de mettre à jour les délégations de zone en conséquence. Les clouds publics ont tendance à réutiliser rapidement les adresses IP et l'échec de l'audit de vos enregistrements NS et des adresses IP associées peut entraîner une prise de contrôle de zone.

Meilleures pratiques pour le serveur de noms et les fichiers de zone

Un audit DNS doit inclure un examen de tous les comptes d'utilisateurs sur tous les serveurs de noms sous votre contrôle, y compris les serveurs de noms «principaux» et «secondaires». Les utilisateurs ayant accès à un serveur de noms peuvent modifier directement les fichiers de zone ou changer le logiciel qui s'exécute sur le système. Ne vous fiez pas uniquement aux autorisations du système de fichiers ou aux protections de niveau d'accès dans votre système d'exploitation, car les exploits ou les mauvaises configurations pourraient permettre à toute personne disposant d'un compte d'accéder aux fichiers de zone ou aux utilitaires de configuration du serveur. Assurez-vous que les journaux d'accès sont conservés pour suivre qui s'est connecté aux serveurs; le contrôle d'accès et la responsabilité sont essentiels pour toutes les parties de votre infrastructure DNS. Ceci est particulièrement important dans un modèle primaire-secondaire, où un serveur de noms "principal" contient une copie canonique du fichier de zone, et les serveurs de noms "secondaires" la transfèrent du primaire périodiquement ou sur demande.

Contrôle de révision des fichiers de zone DNS

La gestion du fichier de zone lui-même doit également être auditée pour s'assurer qu'un processus de gestion des changements approprié existe et est appliqué. La copie principale du fichier de zone doit être stockée dans un système de contrôle des révisions ou un autre stockage à accès contrôlé. En cas de demande de modification, l'administrateur DNS génère un fichier de zone mis à jour, le soumet à un processus de révision, le vérifie pour détecter les erreurs, puis envoie la nouvelle copie en production. Dans le cas où la mise à jour entraînerait un comportement inattendu, il devrait y avoir une procédure régulièrement testée et facile à exécuter pour restaurer la zone au dernier bon état connu; un système de contrôle des révisions peut faciliter cette restauration. L'audit de votre infrastructure DNS doit également inclure un examen régulier des comptes qui ont un accès en modification au système de contrôle des révisions utilisé pour gérer le fichier de zone.

Comme toutes vos données importantes, le fichier de zone et son journal des modifications doivent être sauvegardés régulièrement dans une sauvegarde hors site sécurisée. Une sauvegarde de confiance, combinée à un contrôle des révisions, aidera à établir une «dernière bonne version connue» du fichier pour la reprise après sinistre.

Dans les cas où la copie principale de votre fichier de zone existe sur un fournisseur DNS cloud, vous devez vous assurer que tous les comptes autorisés à modifier les enregistrements de zone sont soumis aux mêmes pratiques de sécurité strictes recommandées pour les comptes de registraire. Même lorsque vous utilisez un fournisseur de cloud, assurez-vous de stocker régulièrement une copie de sauvegarde du fichier de zone pour une utilisation dans la récupération après sinistre. Le produit Fast DNS d'Akamai offre un contrôle d'accès granulaire, une authentification à deux facteurs et la possibilité de télécharger facilement une copie de votre zone à des fins de sauvegarde ou d'audit.

Votre domaine est-il verrouillé au bureau d'enregistrement?

Le verrouillage de domaine est un moyen d'empêcher les modifications non autorisées de l'enregistrement d'un domaine. La plupart des bureaux d'enregistrement de noms de domaine le permettent verrous du registraire, aussi connu sous le nom verrous client, pour les domaines qu'ils enregistrent. Vérifiez auprès de votre registraire pour voir s'il prend en charge ce service. Si disponible, assurez-vous que vos domaines sont verrouillés. Plus précisément, il est recommandé qu'au moins vos domaines aient tous les verrous Client Delete, Client Update et Client Transfer définis, avec le verrou Client Renew ne pas ensemble. Certains bureaux d'enregistrement ne présenteront qu'une seule option de verrouillage dans leur portail qui définit souvent les trois verrous recommandés. Cette collection de verrous empêchera toute mise à jour ou transfert non autorisé de votre domaine tout en empêchant un attaquant de supprimer l'enregistrement de domaine sans déverrouiller d'abord le domaine. Si vous ne définissez pas le verrouillage de renouvellement, vous pourrez toujours renouveler les domaines ou profiter de la fonctionnalité de renouvellement automatique de votre bureau d'enregistrement, si elle est proposée. De nombreux bureaux d'enregistrement ne vous factureront pas pour ajouter des verrous de bureau d'enregistrement ou des verrous client à vos domaines; certains verrouillent même les domaines par défaut sans que vous ayez à faire quoi que ce soit.

En plus des verrous client / registraire, certains opérateurs gTLD ou ccTLD offrent verrouillage du serveur, aussi connu sous le nom verrouillage du registre, prestations de service. Les verrous de serveur ajoutent une couche de protection supplémentaire aux mises à jour de domaine et ne peuvent être ajoutés ou supprimés qu'à la demande du titulaire via un processus coordonné «hors bande» avec l'opérateur de registre, souvent par téléphone. Comme les verrous client, les verrous serveur suggérés sont Supprimer le serveur, Mettre à jour le serveur et Transférer le serveur, avec le renouvellement du serveur ne pas étant suggéré pour la même raison que précédemment. Il convient de noter qu'il existe des opérateurs de registres / TLD qui n'offrent pas ce service. L'utilisation du serveur ou du service de verrouillage du registre a souvent un coût supplémentaire et implique une interaction supplémentaire entre le registrant et le registrar.

N'oubliez pas que l'ajout ou la suppression de verrous de serveur / registre peut entraîner des retards prolongés (pouvant aller jusqu'à une semaine) dans la modification d'un domaine, tels que la mise à jour des informations de contact d'enregistrement, la mise à jour des enregistrements de délégation, les transferts de domaine ou la suppression de domaine. Par exemple, lors du transfert de domaines entre des bureaux d'enregistrement, vous devez déverrouiller le domaine avant que le processus de transfert puisse commencer.

Lorsque vous apportez des modifications à votre domaine, assurez-vous d'utiliser WHOIS pour vérifier que les verrous sont appliqués comme prévu. Pour interroger les informations WHOIS, vous pouvez utiliser la page WHOIS de l'ICANN, la commande whois via le terminal de votre ordinateur ou la page whois sur le site Web de votre bureau d'enregistrement. Ci-dessous, vous pouvez voir un exemple de la façon dont les verrous client / registraire apparaîtront lorsqu'ils seront appliqués:

De même, lors de la vérification du WHOIS pour les verrous client / registraire et serveur / registre, les éléments suivants doivent être renvoyés de votre requête WHOIS:

J'espère pour le mieux; planifier le pire

Les bureaux d'enregistrement de noms de domaine ont été piratés. Les comptes d'administrateur DNS ont été compromis. N'attendez pas que cela arrive à votre organisation – préparez-vous à cela dans le cadre de l'exercice de révision et d'audit DNS. Renseignez-vous auprès de vos bureaux d'enregistrement sur leur processus de récupération dans le cas où vos domaines seraient piratés. Ils devraient vous guider tout au long du processus de préparation de la documentation appropriée. Le SAC044 de l'ICANN recommande de collecter la documentation suivante pour le pire des cas où un domaine est piraté par le registraire:

• Copies des enregistrements d'enregistrement de domaine (ex: recherches WHOIS horodatées, captures d'écran ou exportations du portail du bureau d'enregistrement avec horodatages)
• Dossiers de facturation, en particulier ceux qui indiquent que des paiements ont été effectués
• Journaux, archives ou transactions financières qui associent un nom de domaine au contenu que vous, le titulaire légitime, avez publié.
• Annuaires téléphoniques (Pages jaunes), matériel de marketing, etc. qui contiennent de la publicité qui vous associe, vous, le titulaire, au nom de domaine
• Correspondance avec les registraires et l'ICANN qui mentionne le nom de domaine
• Documents juridiques, déclarations fiscales, pièces d'identité émises par le gouvernement, avis de taxe professionnelle, etc. qui vous associent, en tant que titulaire, au nom de domaine

Cette liste provient de l'ICANN SSAC, un groupe d'experts en sécurité nommé par le Conseil d'administration de l'ICANN. Votre organisation doit tirer parti de son expérience durement acquise de récupération de domaines piratés par le bureau d'enregistrement.

Ce guide n'est que le début de vos exercices de révision et d'audit DNS. Les prochains articles porteront sur DNSSEC, l'infrastructure DNS faisant autorité, le détournement BGP des ressources DNS, les résolveurs DNS sécurisés et la gamme de menaces DNS. Restez à l'écoute des blogs d'Akamai et de la communauté Akamai pour de futurs articles.

Ce sont des ressources et des références supplémentaires utilisées dans ce blog qui peuvent aider les organisations à créer leurs outils de révision.

Un grand merci à notre «équipe DNS Akamai» et à d'autres collègues d'Akamai qui ont contribué à l'élaboration et à la modification de ce document. Cela comprend Hans Cathcart, Tim April, Jon Reed, Gordon Marx, Bruce Van Nice, Mathias Koerber, Rory Hewitt, James Casey, Barry Greene et bien d'autres qui ont aidé.

*** Il s'agit d'un blog syndiqué Security Bloggers Network du blog Akamai rédigé par l'équipe DNS d'Akamai. Lisez l'article d'origine sur: http://feedproxy.google.com/~r/TheAkamaiBlog/~3/g_QNlPEoTXI/protecting-your-domain-names-taking-the-first-steps.html