Catégorie : Actualités

Conformité, Fiabilité, Portée

Noms de domaine - Conformité, Fiabilité, Portée

On m’avait dit que dans la vie, il fallait respecter trois éléments par ordre croissant : la santé, la famille, le travail. Pour les noms de domaine, il est possible de respecter un triptyque similaire face aux nombreuses interrogations que l’on se pose quant à sa campagne de communication sur Internet. Ce triptyque, C-F-P, est à garder à l’esprit :

Conformité :

Il est important de se demander si le nom de domaine que vous souhaitez acquérir est en conformité avec les règles d’enregistrement du registre. Car oui, sur Internet, il y a une territorialité. Souvenons-nous de Elsevier qui tenta de saisir SCI-HUB.ORG via un tribunal américain (car .ORG est géré par un registre états-unien). Souvenons-nous également des noms de domaine en .CAT et de l’action du gouvernement ibérique face à la demande d’indépendance de la Catalogne.

Fiabilité :

Dans un monde intangible, les noms de domaine peuvent sembler être dotés de super-pouvoirs et de compétences technologiques identiques. Pourtant, les évènements politiques, climatiques et technologiques nous rappellent que toutes les extensions ne disposent pas de la même stabilité supposée. Avant de communiquer avec une adresse, il convient de se poser la question la plus importante : est-ce que mon adresse est robuste ? Est-ce que :

  • L’extension choisie pour mon nom est gérée par un registre sérieux ?
    • .COM, c’est Verisign, entreprise américaine reconnue et qui gère un des treize serveurs racine ;
    • .DE c’est le DENIC, registre allemand certifié ISO 27001 et ISO 22301 ;
  • Mes noms de domaine sont-ils administrés par un registrar fiable ?
    • Nameshield est un registrar certifié ISO 27001 qui gère de nombreuses extensions,…

Portée :

L’utilisation d’un nom de domaine comportant une extension pays implique une zone de chalandise fixe, exception faite de certaines extensions détournées et devenues génériques. Ainsi, faire le choix de communiquer en .FR vous lie à la France. (L’AFNIC, le registre français du .FR, communique actuellement via l’initiative Réussir en .FR).Un .COM ou un .NET sera plus générique.

 

Nous développerons plus longuement dans un prochain article l’assurance qualité liée à la bonne gestion d’un nom de domaine.

Conséquences désastreuses du non renouvellement d’un nom de domaine

Conséquences désastreuses du non renouvellement d’un nom de domaine
Source de l’image : SEO Link Building

La société américaine de Télécommunication, Sorenson Communication, a oublié de renouveler un nom de domaine seulement quelques jours en juin 2016. La décision est tombée fin septembre 2017, Sorenson Communication doit payer une amende de 3 Millions de dollars. Pourquoi un montant aussi élevé ?

Le nom de domaine qui est retombé dans le domaine public était porteur d’un service critique pour certains usagers ! Il s’agit du « Video Relay System » que les entreprises de télécommunication doivent fournir aux sourds et aux personnes avec des déficiences vocales pour faire des appels vidéo et contacter le numéro d’urgence des Etats-Unis, le 911, en utilisant la langue des signes. Les résidents de l’Utah présentant ces handicaps se sont vus dans l’incapacité d’appeler le 911 pendant 3 jours !

Sorenson Communication s’est en effet rendu compte assez tardivement de son oubli et a fini par renouveler le nom de domaine seulement au bout de 3 jours.

Mais ce genre d’oubli peut être facilement évité, grâce à l’option « renouvellement automatique » pour l’ensemble de votre portefeuille de noms de domaine. Vos noms de domaine critiques, porteurs de services, de site web et/ou de messageries ne seront pas interrompus par un simple oubli de renouvellement.

Sur les 3 millions de dollars d’amende, 252 000$ sont reversés à « The Federal Communication Commission » et 2,7 millions, à la société de « Telecommunications Relay Services Fund », qui a trouvé une solution temporaire pour louer sa bande passante lors de ces 3 jours sensibles.

Les suites de l’affaire Equifax ou comment les contrôles mis en place dans le cadre d’un SMSI (ISO 27001) peuvent aider à éviter des incidents de sécurité ?

Cybersecurity - Les suites de l’affaire Equifax ou comment les contrôles mis en place dans le cadre d’un SMSI (ISO 27001) peuvent aider à éviter des incidents de sécurité ?

 

Avant-hier (3 octobre 2017), l’ex CEO d’Equifax, Rick Smith, a dû expliquer devant le Congrès américain comment les données privées de presque un américain sur deux ont pu être piratées.

Rappelons brièvement la chronologie des faits (pour plus d’informations, nous vous invitons à lire l’article complet d’Adriana Lecerf) :

  • 09 mars 2017: une faille Apache Struts est détectée. Moins d’une semaine après, le patch de sécurité est validé et planifié, mais ce dernier n’est pas appliqué sur tous les serveurs.
  • 15 mars 2017: un scan est effectué mais aucune vulnérabilité n’est détectée.
  • Avril 2017: des hackers profitent de cette brèche (le patch de sécurité qui n’a pas été appliqué sur tous les serveurs) et volent les précieuses données.
  • 31 juillet 2017 : l’ex PDG est mis au courant du vol d’information.
  • 8 septembre 2017 : Communication officielle sur le piratage.

Comment la certification ISO 27001 et la mise en place d’un SMSI (Système de Management de la Sécurité de l’Information) associé peut aider à éviter ce type d’incident :

La norme ISO 27001 est la référence en matière de validation et d’amélioration continue d’un SMSI.
Elle s’appuie sur 114 points de contrôles qui balaient tous les domaines pour la mise en place d’un SMSI, dont la mise en place de procédures et processus de mise à jour des plateformes.

Cela comprend la mise en place et le contrôle régulier de processus de gestion des risques visant à garantir la sécurité des données. L’objectif premier de ce système de management est de mettre en œuvre les mesures adéquates afin de réduire voire éliminer l’impact des menaces pour les utilisateurs ou les clients.

Le SMSI est une roue d’amélioration continue et, dans le cas d’Equifax, les processus de contrôle instaurés et suivis via un SMSI auraient pu aider à éviter, à termes, ce genre d’incident.

Cette affaire démontre à nouveau l’obligation de repenser les stratégies de sécurité au sein des entreprises et de mettre en place les protocoles nécessaires pour s’assurer de la découverte des éventuelles failles de sécurité et des correctifs à appliquer.

Nameshield : premier registrar français accrédité ISO 27001 sur l’ensemble de son activité registrar

Le CAA devient obligatoire dans le petit monde du SSL

Ou comment en profiter pour mettre en place une stratégie de certification propre à votre société ?

Le CAA devient obligatoire dans le petit monde du SSL

En Janvier 2013, un nouveau type de Resource Record DNS a vu le jour pour améliorer la chaîne de contrôle dans l’émission des certificats SSL. Ce record appelé CAA pour Certificate Authority Authorization permet de préciser pour un nom de domaine donné, quelles sont les Autorités de Certification autorisées à émettre des certificats.

C’est une création extrêmement intéressante, particulièrement pour les grandes sociétés et groupes dont les équipes techniques sont éparpillées dans le monde et pour lesquelles il est souvent difficile d’imposer une stratégie globale de certification. Il n’est pas rare que les sociétés découvrent par hasard l’existence de certificats demandés par des équipes ne connaissant pas les processus, par des consultants externes, émis par des Autorités de Certification ayant une mauvaise image, ou encore pour des certificats de faible niveau d’authentification (DV). La mise en place de record CAA sur vos noms de domaine est une bonne solution pour contrôler ce que font les équipes et l’actualité du monde du SSL va vous y aider.

En effet, si le CAA a été détaillé dans la RFC-6844 de 2013, il n’était jusqu’à présent pas obligatoire pour une Autorité de Certification, de vérifier si elle était autorisée ou non à émettre un certificat sur un nom de domaine donné, d’où une certaine inutilité de la chose et une adoption très faible.

8 Septembre 2017 – Le CAA checking devient obligatoire

Il aura fallu attendre mars 2017 et un vote positif du CAB/forum (ballot 187) pour rendre cette vérification obligatoire. Depuis le 8 septembre, les Autorités de Certification se doivent de faire cette vérification sous peine de sanctions de la part du CAB/forum et des navigateurs, l’actualité récente entre Google et Symantec nous a montré à quel point ce n’est pas dans leur intérêt.

Trois cas de figure se présentent lors de cette vérification sur un nom de domaine donné :

  • Un CAA record est en place et mentionne le nom de l’Autorité de Certification, celle-ci peut émettre le certificat ;
  • Un CAA record est en place et mentionne un nom d’Autorité de Certification différente, celle-ci NE peut PAS émettre le certificat ;
  • Aucun CAA record n’est en place, n’importe quelle Autorité de Certification peut émettre un certificat SSL

CAA found - not found : Le CAA devient obligatoire dans le petit monde du SSL

Il est important de noter que pour un nom de domaine donné, plusieurs records CAA peuvent être déclarés. Un outil simple (parmi tant d’autres) pour tester vos noms de domaine est disponible en ligne : https://caatest.co.uk/

Comment profiter du CAA pour ma société ?

Si ce n’est pas déjà fait, l’avènement du CAA checking est l’opportunité pour votre société de définir une stratégie de certification et de pouvoir s’assurer qu’elle soit respectée. Définir une (ou plusieurs) Autorité de Certification qui correspond à vos valeurs et à votre attente en terme de qualité de service est une première étape. Il faudra pour cela mettre autour de la table les intervenants du marketing pour valider l’impact sur l’affichage dans les sites web et les services techniques pour s’assurer de la qualité du fournisseur choisi. Il conviendra ensuite de déclarer ces records CAA dans les différentes zones de vos noms de domaine.

Il convient ensuite de bien communiquer auprès de l’ensemble des opérationnels pour qu’ils prennent conscience des règles imposées au sein de la société, afin de ne pas les bloquer dans l’obtention d’un certificat. En effet, l’expérience de Nameshield montre que très souvent les certificats SSL sont demandés dans l’urgence ; de plus les dernières versions des navigateurs ne sont pas tendres vis-à-vis des erreurs de certificats en affichant de manière ostentatoire du « Not Secure ». En conséquence, bloquer l’émission d’un certificat parce que la communication n’est pas passée peut être dommageable.

Une telle stratégie présente de réels avantages dans la maîtrise des certificats, sur le plan marketing, technique, maîtrise des risques et coûts liés aux certificats. Il convient de la mener en toute connaissance de cause et pour se faire, notre équipe d’experts SSL peut vous accompagner.

Référendum en Catalogne

Référendum en Catalogne - .CAT

Un contexte

L’Espagne, divisée en 17 communautés autonomes ne peut être comparée au découpage administratif des régions. En effet, ces communautés espagnoles n’ont pas toutes la même autonomie, et la Catalogne, située au Nord-Est, bénéficie d’un statut autonome, en vigueur depuis 2006.

L’enjeu du 1er octobre

Le gouvernement régional indépendantiste catalan a organisé dimanche dernier un référendum relatif à l’indépendance de la Catalogne auprès des 7,5 millions d’habitants. Cette initiative est assez mal perçue par le pouvoir conservateur espagnol qui cherche par différents moyens à freiner voire suspendre le mouvement. Pour plusieurs médias, il s’agirait là de l’une des pires crises politiques de ces 40 dernières années.

Comme de nombreux territoires ou régions, la Catalogne bénéficie de son propre TLD : le .CAT.

En France, la Bretagne, la Corse, l’Alsace et Paris bénéficient également d’une extension dédiée, à savoir respectivement .BZH, .CORSICA, .ALSACE et .PARIS.

A l’étranger, on peut retrouver le .SCOT pour l’Ecosse, .EUS pour la culture Basque, .FRL pour la Frise, etc.

9 juin 2017

Le référendum sur l’indépendance de la Catalogne est annoncé. Il aura lieu le 1er octobre. La question que les électeurs auront à répondre est la suivante : « Voulez-vous que la Catalogne soit un Etat indépendant sous forme de république ? ».

13 septembre 2017

Les forces de l’ordre espagnoles saisissent du matériel électoral.

15 septembre 2017

Madrid, jugeant le référendum catalan illégal, a perquisitionné le registre gérant le .CAT, PuntCat pour rendre indisponible l’accès aux sites prônant l’indépendance, les hébergements de ces derniers étant à l’étranger. Les registres des autres pays se sont offusqués de cette situation : le .EUS et le .SCOT ont ainsi fait des communiqués sur le sujet. Si l’on peut noter les réactions de l’EFF ainsi que de l’ISOC, à ce jour, ni le GeoTLD Group ou l’ICANN n’ont encore communiqué à ce propos. Le sujet ayant été traité au-delà des frontières, on notera un article du NYT sur le sujet, il paraît naturel qu’un premier communiqué de l’ICANN soit prochainement publié.

PuntCat, le registre du .CAT, a communiqué sur l’incident par des mots et demandé de l’aide à l’ICANN : « The show that we have experienced in our offices this morning has been shameful and degrading, unworthy of a civilized country. We feel helpless in the face of these immensely disproportionate facts ».

20 septembre 2017

Lancement de « Opération Anubis », visant à empêcher le référendum.

24 septembre 2017

Le secrétariat des télécommunications de Catalogne se plaint à la commission européenne du bloquage de certains sites en .CAT et de la perquisition du registre catalan.

25 septembre 2017

Devant l’impossibilité de couper les sites internet indépendantistes, le gouvernement espagnol les fait bloquer.

1er octobre 2017

Le vote a lieu. 90 % de OUI pour l’indépendance, 42 % de taux de participation.

4 octobre 2017

Jour de la publication de cet article, le gouvernement catalan devrait annoncer l’indépendance de la Catalogne.

Les noms de domaine au cœur du litige

Charlottesville - Les noms de domaine au cœur du litige

Aux États-Unis, les événements relatifs à la manifestation de Charlottesville en août dernier nous ont rappelé que la haine se propage maintenant par Internet.

Comme nous le savons, tout contenu circulant sur le web est hébergé chez un hébergeur et le nom de domaine vendu et administré par un registrar. Concernant l’hébergement, en cas de propos litigieux, il est possible de contacter l’hébergeur et lui demander de couper les pages concernées. C’est exactement ce qui s’est passé dans l’affaire simoneveil.com : OVH l’hébergeur a coupé l’accès au contenu alors qu’OVH le registrar gère toujours le nom de domaine.

Mais revenons à Charlottesville. Parmi les contre-manifestants, une jeune femme a été tuée par une voiture fonçant dans la foule. La victime a ensuite été considérée en des termes blessants et humiliants, à la limite de la loi, dans les articles d’un journal en ligne appelé The Daily Stormer.

Des activistes ont alors demandé aux entreprises gérant hébergement et nom de domaine si les propos n’étaient pas contraires à leurs valeurs. C’est ainsi que GoDaddy a tweeté qu’ils avaient demandé à The Daily Stormer de se trouver un autre registrar. Puis Google en a fait de même, tout comme CloudFare. Le journal américain a alors tenté de changer d’extension de nom de domaine en déposant un .LOL, enregistrement qui fut refusé par Namecheap, son CEO s’en étant exprimé sur le blog de l’entreprise. Dans un même temps, le registre du .RU (Russie) a également refusé (17 août). Puis vinrent le tour du .AT (Autriche) (11 septembre) et du .IS (Islande) (13 septembre).

Tweet GoDaddy - Les noms de domaine au cœur du litige
Compte Twitter de GoDaddy

Une question vient logiquement face à cette levée de boucliers : est-il normal qu’une entreprise technologique intervienne avant une action juridique, certes parfois longue et sinueuse, face à un Internet viral ?

Notons toutefois que les entreprises impactées ont pu mettre en avant leurs conditions d’utilisation que les utilisateurs ont acceptées lorsqu’ils ont fait appel au service en question.

Car si la question du Daily Stormer n’en est pas vraiment une et qu’un consensus quasi général est de mise, la récente perquisition au sein du registre catalan du .CAT laisse interrogatif.

Donuts rachète Rightside: quelles conséquences sur les programmes DPML ?

Donuts rachète Rightside : quelles conséquences sur les programmes DPML ?

Au lancement des nouvelles extensions internet, l’opérateur DONUTS, le plus gros déposant d’extensions (.services, .legal, .photos, .vin etc) avait lancé un programme de protection spécifique en complément de la TMCH.

La Donuts Protected Mark List (DPML) permet de bloquer l’enregistrement par les tiers d’un nom de domaine similaire à la marque sous toutes les extensions gérées par le registre.

Par exemple, si la marque « iPhone » est inscrite à la TMCH (pré-requis) puis dans la DPML, personne ne pourra enregistrer <iphone.photos> ou <iphone.services>, ainsi que la centaine d’autres extensions Donuts.

D’autres registres ont également créé des programmes de protection à l’instar de la DPML de Donuts, sur des périmètres plus restreints. C’était le cas de Rightside qui gérait les 40 extensions :

.ACTOR

.AIRFORCE

.ARMY

.ATTORNEY

.AUCTION

.BAND

.CONSULTING

.DANCE

.DEGREE

.DEMOCRAT

.DENTIST

.ENGINEER

.FAMILY

.FORSALE

.FUTBOL

.GAMES

.GIVES

.HAUS

.IMMOBILIEN

.KAUFEN

.LAWYER

.LIVE

.MARKET

.MODA

.MORTGAGE

.NAVY

.NEWS

.NINJA

.PUB

.REHAB

.REPUBLICAN

.REVIEWS

.RIP

.ROCKS

.SALE

.SOCIAL

.SOFTWARE

.STUDIO

.VET

.VIDEO

Fin juillet, Donuts a annoncé le rachat de Rightside.

Quels sont les impacts de ce rachat pour les détenteurs de ces deux programmes de protection ?

  • La DPML intègre désormais les extensions de Rightside, sans coût supplémentaire.
  • Il n’est plus possible de souscrire uniquement au programme de Rightside, il faudra se tourner nécessairement vers la DPML de Donuts.
  • Cela ne protège pas les noms précédemment enregistrés par des tiers.
  • Cela exclut les noms de domaine premiums.

Si vous souhaitez enregistrer votre marque dans la TMCH et/ou dans la DPML, n’hésitez pas à contacter votre interlocuteur chez Nameshield.

Equifax victime d’une cyberattaque massive

Equifax victime d'une cyberattaque

La société américaine Equifax, basée à Atlanta, présente dans 24 pays, a été la proie d’une attaque particulièrement préoccupante. Equifax récolte et analyse les données personnelles de clients sollicitant un crédit. Début septembre, la société a révélé une intrusion dans ses bases de données.

Ce piratage informatique pourrait concerner potentiellement environ 143 millions de clients américains, ainsi que d’autres clients au Canada et au Royaume-Uni. Les criminels ont exploité une faille dans une application web entre mi-mai et juillet. Ils ont obtenu les noms, numéros de sécurité sociale, dates de naissance, adresses et certains numéros de permis de conduire. Le vol de ces données est très préoccupant. Ces informations faciliteront les usurpations d’identité et le piratage de comptes. Le numéro de sécurité sociale est indispensable aux Etats-Unis pour travailler, ouvrir un compte en banque ou encore obtenir un permis de conduire et souvent louer un appartement. Il se pourrait même que certaines de ces données soient déjà en vente sur le Dark Web [une partie du web non indexée par les principaux moteurs de recherche généralistes].

Cette attaque touche directement le cœur de l’identité et de l’activité d’Equifax. La société a mis en place un site internet (www.equifaxsecurity2017.com) et un numéro de téléphone à la disposition de ses clients et leur promet «gratuitement» une aide contre l’usurpation d’identité. Equifax collabore avec les autorités et une société de sécurité pour évaluer les dommages.

Equifax victime d'une cyberattaque
Site Internet Equifaxsecurity2017.com

Toutes les sociétés devraient voir cette attaque comme un avertissement. Cet exemple est bien la preuve que les entreprises peuvent peiner à voir ce qui est en train de se passer au sein de leurs propres réseaux informatiques. Les nouvelles attaques, chaque jour plus sophistiquées, passent de plus en plus inaperçues.

De surcroît, Equifax affirme avoir découvert l’attaque le 29 juillet. Pourtant, la communication faite aux clients n’intervient que début septembre : un délai anormal quant à la protection de données aussi sensibles. Aujourd’hui ces données ont disparu dans la nature.

Ce piratage de grande ampleur est loin d’être le premier. L’année dernière, le groupe Yahoo annonçait qu’un milliard de comptes avaient été piratés tandis que d’autres entreprises américaines ont elles aussi été victimes de piratages, comme le site de rencontres Adult Friend Finder, ou encore le groupe de distribution Target. Les voleurs n’ont cependant, pas eu accès aux numéros d’assurance sociale ou de permis de conduire.

Cette attaque ne vient que renforcer la nécessité pour les entreprises d’envisager dans leur stratégie de sécurité toutes les failles susceptibles de servir d’entrée aux cybercriminels.

La tempête Irma et ses conséquences inattendues sur l’industrie des noms de domaine

Irma hurricane - conséquences inattendues sur l’industrie des noms de domaine
Source : NASA Worldview

.TV, c’est la télévision, .FM, la radio FM, .IO les entreprises de la tech’,…

En fait non. En fait oui mais non. Ces codes ne désignent pas des secteurs d’activité mais des territoires selon l’ISO 3166-1 alpha 2 :

  • TV pour Tuvalu, un état polynésien ;
  • FM pour Federated States of Micronesia ;
  • IO pour British Indian Ocean Territory.

Pourquoi un tel mélange des genres ? En fait, noms de domaine et géopolitique font un tout.

Lorsque vous communiquez avec un nom de domaine en .COM, vous faîtes confiance à Verisign, une entreprise américaine. Avec un .FR, c’est l’AFNIC ! Pour le .TV, rien à craindre, cette extension est techniquement déléguée à Verisign. Et pour le .IO, on dira que l’infrastructure est assez résiliente. Pourquoi évoquer cette réalité ?

Tout simplement car la géopolitique étant mouvante, des événements politiques ont fréquemment coupé les extensions de noms de domaine. C’est le cas du .LY qui correspond à la Libye. Des professionnels du Sud-Ouest qui communiquaient en .SO se sont par exemple retrouvés démunis lorsque la Somalie a coupé son infrastructure DNS pendant quelques temps.

Justement, c’est ce qui se passe avec les .AI. AI pour Artificial Intelligence ? Pas du tout, c’est le code pays d’Anguilla, un territoire durement touché par l’ouragan Irma. Ainsi, de nombreuses entreprises utilisant des noms de domaine en .AI ont rencontré des difficultés pour enregistrer, gérer ou renouveler leur nom de domaine.

Mais alors comment faire ? C’est justement ce qui est passionnant dans cette industrie immatérielle : si aucun guide n’est disponible pour suivre en temps réel les mouvements géopolitiques et les conséquences sur les disponibilités DNS des registres, Nameshield vous informe en temps réel.

N’hésitez pas à nous contacter en cas d’interrogation.

Les 3 attaques DNS les plus communes et comment les combattre

Cyberattaque - Attaques DNS

En octobre 2016 de nombreux sites Web populaires tels qu’Amazon, Twitter, Netflix et Spotify sont devenus inaccessibles à des millions d’internautes aux Etats-Unis pendant près de 10 heures, autant dire une éternité. En cause, une des plus grosses attaques de l’histoire d’Internet sur les services DNS de Dyn, un acteur majeur dans ce secteur d’activité.

D’autres sociétés telles que Google, The New York Times et de nombreuses banques ont également été victimes de différentes variétés d’attaques ciblant le DNS ces dernières années et, si dans beaucoup de sociétés le DNS reste un grand oublié, les choses sont en train d’évoluer vers une prise de conscience forcée par ces nombreuses attaques.

Mais au fait, quelles sont ces attaques ?

Attack #1: DNS Cache Poisoning and Spoofing

La finalité de l’empoisonnement DNS est d’acheminer les utilisateurs vers un site Web frauduleux. Par exemple, un utilisateur tape « gmail.com » dans un navigateur Web avec pour objectif d’aller consulter sa boîte email. Le DNS ayant été empoisonné, ce n’est pas la page gmail.com qui s’affiche mais une page frauduleuse choisie par l’attaquant, dans le but par exemple de récupérer les accès aux boîtes emails. Les utilisateurs saisissant le nom de domaine correct, ils ne se rendent pas compte que le site Web qu’ils visitent est un faux, une escroquerie.

Cela crée une opportunité parfaite pour les attaquants d’utiliser des techniques de phishing pour soutirer de l’information, qu’il s’agisse des informations d’identification ou des informations de carte de crédit, auprès de victimes peu méfiantes. L’attaque peut être dévastatrice, en fonction de plusieurs facteurs, selon l’intention de l’attaquant et la portée de l’empoisonnement DNS.

Comment les pirates mènent-ils cette attaque ? En exploitant le système de mise en cache DNS.

La mise en cache DNS est utilisée dans tout le Web pour accélérer les temps de chargement et réduire les charges sur les serveurs DNS. La mise en cache de document Web (ex : page web, images) est utilisée afin de réduire la consommation de bande passante, la charge du serveur web (les tâches qu’il effectue), ou améliorer la rapidité de consultation lors de l’utilisation d’un navigateur. Un cache Web conserve des copies de documents transitant par son biais. Une fois qu’un système interroge un serveur DNS et reçoit une réponse, il enregistre les informations dans un cache local pour une référence plus rapide, sur un laps de temps donné, sans avoir à aller rechercher l’information. Le cache peut donc répondre aux requêtes ultérieures à partir de ses copies, sans recourir au serveur Web d’origine.

Cette approche est utilisée à travers le Web de manière routinière et en chaîne. Les enregistrements d’un serveur DNS servent à mettre en cache des enregistrements sur un autre serveur DNS. Ce serveur sert à mettre en cache les enregistrements DNS sur les systèmes de réseau tels que les routeurs. Ces enregistrements sont utilisés pour créer des caches sur des machines locales.

L’empoisonnement DNS survient lorsque l’un de ces caches est compromis.

Par exemple, si le cache sur un routeur réseau est compromis, alors quiconque l’utilise peut être mal orienté vers un site Web frauduleux. Les faux enregistrements de DNS se ramifient vers les caches DNS sur la machine de chaque utilisateur.

Cette attaque peut également viser des maillons hauts de la chaîne. Par exemple, un serveur DNS majeur peut être compromis. Cela peut endommager les caches des serveurs DNS gérés par les fournisseurs de services Internet. Le « poison » peut se répercuter sur les systèmes et les périphériques de réseautage de leurs clients, ce qui permet d’acheminer des millions de personnes vers des sites Web frauduleux.

Cela vous semble fou ? En 2010, de nombreux internautes américains ne pouvaient plus accéder à des sites comme Facebook et YouTube, car un serveur DNS d’un fournisseur d’accès Internet de haut niveau avait accidentellement récupéré les enregistrements du Grand Pare-feu Chinois [le gouvernement chinois bloquait les accès à ces sites].

L’antidote à ce poison

L’empoisonnement du cache DNS est très difficile à détecter. Il peut durer jusqu’à ce que le TTL (Time To Live – durée de validité d’une requête mise en cache) expire sur les données en cache ou qu’un administrateur le réalise et résolve le problème. En fonction de la durée du TTL, les serveurs peuvent prendre des jours pour résoudre le problème de leur propre chef.

Les meilleures méthodes pour empêcher une attaque par empoisonnement du cache DNS incluent la mise à jour régulière du programme, la réduction des temps TTL et la suppression régulière des caches DNS des machines locales et des systèmes réseau.

Pour les registres qui le permettent la mise en place de DNSSEC est la meilleure réponse afin de signer les zones des noms de domaine sur l’ensemble de la chaine et rendre impossible une attaque par empoisonnement du cache.

 

Attack #2: Attaque par amplification DNS (de type DDoS)

Les attaques par amplification DNS ne sont pas des menaces contre les systèmes DNS. Au lieu de cela, elles exploitent la nature ouverte des services DNS pour renforcer la force des attaques de déni de service distribuées (DDoS). Ces attaques ne sont pas les moins connues, ciblant par exemple des sites bien à forte notoriété tels que BBC, Microsoft, Sony…

Accrocher et amplifier

Les attaques DDoS se produisent généralement à l’aide d’un botnet. L’attaquant utilise un réseau d’ordinateurs infectés par des logiciels malveillants pour envoyer de grandes quantités de trafic vers une cible, comme un serveur. Le but est de surcharger la cible et de ralentir ou de l’écraser.

Les attaques par amplification ajoutent plus de puissance. Plutôt que d’envoyer le trafic directement d’un botnet à une victime, le botnet envoie des demandes à d’autres systèmes. Ces systèmes répondent en envoyant des volumes de trafic encore plus importants à la victime.

Les attaques par amplification DNS en sont un exemple parfait. Les attaquants utilisent un botnet pour envoyer des milliers de demandes de recherche pour ouvrir des serveurs DNS. Les demandes ont une adresse source falsifiée et sont configurées pour maximiser la quantité de données renvoyées par chaque serveur DNS.

Le résultat: un attaquant envoie des quantités relativement restreintes de trafic à partir d’un botnet et génère des volumes de trafic proportionnellement supérieurs ou « amplifiés » des serveurs DNS. Le trafic amplifié est dirigé vers une victime, ce qui provoque une panne du système.

Détecter et se défendre

Certains pare-feu peuvent être configurés pour reconnaître et arrêter les attaques DDoS au fur et à mesure qu’elles se produisent en supprimant des paquets artificiels essayant d’inonder les systèmes sur le réseau.

Une autre façon de lutter contre les attaques DDoS consiste à héberger votre architecture sur plusieurs serveurs. De cette façon, si un serveur devient surchargé, un autre serveur sera toujours disponible. Si l’attaque est faible, les adresses IP d’envoi du trafic peuvent être bloquées. En outre, une augmentation de la bande passante du serveur peut lui permettre d’absorber une attaque.

De nombreuses solutions dédiées existent également conçues exclusivement pour lutter contre les attaques DDoS.

 

Attack #3: Attaque DDoS sur le DNS

Les attaques DDoS peuvent être utilisées contre de nombreux types de systèmes. Cela inclut les serveurs DNS. Une attaque DDoS réussie contre un serveur DNS peut provoquer une panne, ce qui rend les utilisateurs incapables de naviguer sur le Web (note: les utilisateurs seront susceptibles de continuer à atteindre les sites Web qu’ils ont visités récemment, en supposant que l’enregistrement DNS soit enregistré dans un cache local).

C’est ce qui est arrivé aux services DNS de Dyn, comme décrit en début d’article. L’attaque DDoS a surchargé les infrastructures DNS, ce qui a empêché des millions de personnes d’accéder aux principaux sites Web dont les noms de domaine étaient hébergés dessus.

Comment se défendre contre ces attaques ? Tout dépend de la configuration de vos DNS.

Par exemple, hébergez-vous un serveur DNS? Dans ce cas, il existe des mesures que vous pouvez prendre pour le protéger, en mettant à jour les derniers patchs et en autorisant uniquement les ordinateurs locaux à y accéder.

Peut-être essayez-vous d’atteindre le serveur DNS attaqué ? Dans ce cas, vous aurez probablement du mal à vous connecter. C’est pourquoi il est judicieux de configurer vos systèmes pour compter sur plus d’un serveur DNS. De cette façon, si le serveur principal venait à ne plus répondre, un serveur de repli sera lui disponible.

Prévoir et atténuer les attaques

Les attaques du serveur DNS constituent un risque majeur pour la sécurité du réseau et doivent être prises au sérieux. Les entreprises, hébergeurs et fournisseurs d’accès doivent mettre en place des mesures de sauvegarde afin de prévenir et de réduire les effets d’une telle attaque lorsqu’ils en sont victimes.

À la suite de ces attaques, l’ICANN a souligné plus fortement que jamais la nécessité d’utiliser le protocole DNSSEC pour signer chaque requête DNS avec une signature certifiée, en garantissant ainsi l’authenticité. L’inconvénient de cette technologie est le fait qu’il doit être mis en œuvre à tous les stades du protocole DNS pour fonctionner correctement – ce qui arrive lentement mais sûrement.

Optez pour des infrastructures hébergées et maintenues par des spécialistes du DNS, et assurez-vous que le réseau soit anycasté (points de présences multiples et répartis sur l’ensemble de la planète, ou au moins sur vos zones d’influence) et bénéficie de filtrage anti-DDoS, et vous propose des solutions de sécurité supplémentaires telles que DNSSEC mais aussi failover pour intégrer le DNS dans vos PCA et PRA.

Nameshield dispose de sa propre infrastructure DNS Premium pour répondre aux besoins de ses clients. Cette infrastructure répond notamment (voire dépasse) à tous les pré-requis ANSSI. La solution DNS Premium est intégrée dans le scope de notre certification ISO 27001.

N’hésitez pas à nous contacter pour toutes questions relatives aux cyberattaques.