Gérer son DNS en interne

Gérer son propre serveur de résolution de nom de domaine est l’une des choses les plus simples et les moins onéreuses qu’un administrateur puisse faire pour surveiller et protéger les applications, les services et les utilisateurs, de potentiels risques.

Il est très rare de nos jours qu’un ordinateur ne soit pas relié à un réseau, parce que la plupart des activités aujourd’hui reposent sur l’utilisation de données et de services distribués par l’intermédiaire d’une forme d’« internet » – c’est-à-dire d’un réseau  avec  des adresses IP publiques ou privées.

Tous les réseaux non basés sur Internet ont clairement échoué – on ne développera rien et ne se connectera plus jamais via les réseaux AppleTalk, DECnet, SNA ou XNS. Partons donc du principe tout aujourd’hui repose sur le TCP/IP qui lui-même repose sur le Système de Noms de Données, le DNS. Il est donc important d’en savoir le plus possible sur l’usage que nous faisons du DNS, mais la plupart des administrateurs systèmes sont beaucoup trop occupés par leur propre spécialité pour pouvoir devenir aussi experts de toutes les technologies spécifiques.

Dans cet article je vais décrire la façon dont les utilisateurs utilisent le DNS et les applications associés, c’est à dire la résolution de nom de domaine. Il y aurait beaucoup plus à dire sur le DNS, on pourrait par exemple parler de la gestion du contenu et de sa mise à disposition. Mais si la mise à disposition de contenu de DNS est une tâche très spécifique, l’accès à du contenu de nom de domaine est en revanche universel, car aucune activité d’aucune sorte ne peut débuter sur des réseaux TCP/IP avant d’avoir accédé au DNS au moins une fois, et probablement de nombreuses fois. Il est important de signaler que, dans notre discussion, par ‘activité je me réfère à la criminalité sur internet, l’utilisation illégale du réseau, et la surveillance électronique.

Les débuts du DNS

Au début des années 1980 quand la structure du TCP/IP a été finalisée, principalement par des chercheurs et des communautés universitaires, il était courant de n’avoir qu’un seul ou que quelques rares ordinateurs par campus, car les ordinateurs étaient alors volumineux et couteux, non seulement à l’achat mais aussi à faire fonctionner et à entretenir. Cette concentration amenait de nombreux services et applications à partager le même ordinateur, auquel les utilisateurs accédaient en utilisant des terminaux « passifs ». Quand le DNS a été créé, le service de résolution a donc été installé sur au moins un ordinateur par campus. Nous nous sommes habitués à obtenir des réponses rapides à la plupart des requêtes relatives au DNS, la réponse arrivant en général en une milliseconde environ. Les applications en réseau comme les emails ou la gestion de fichiers fonctionnaient en partant du principe qu’au moins un accès au DNS serait nécessaire pour chaque opération, mais que l’accès au DNS serait suffisamment rapide pour que cela ne réduise pas l’efficacité des applications et des services qui en dépendaient.

Avant la commercialisation et la privatisation d’internet dans les années 1990, la criminalité et l’usage abusif en ligne étaient pour ainsi dire inexistants. Quand seuls les scientifiques et les ingénieurs avaient accès à Internet et que les objectifs étaient universitaires plus que commerciaux, la sécurité s’imposait de fait « par défaut ». La plupart de la criminalité et de l’usage illégal d’internet d’aujourd’hui est rendue possible par l’absence totale de prise en compte de la sécurité dans certains des plus anciens protocoles et services centraux, et il s’est révélé très difficile d’ajouter des considérations de sécurité des décennies plus tard à un réseau qui avait été construit pour accueillir uniquement des usagers de confiance et des applications sûres.  L’un des plus graves problèmes de sécurité vient de ce que des utilisateurs malveillants sont en mesure de créer du contenu de DNS pour faciliter leurs actions criminelles en ligne, et qu’ils recevront le même service pour leurs activités criminelles que celui que nous recevons pour du contenu non criminel.

Le DNS aujourd’hui

Les fusions répétées entre les sociétés de l’internet ont fait naître quelques acteurs dominants comme Google, Cisco, IBM et Cloudfare, qui proposent chacun un service de résolution de nom de domaine global identique à celui que chaque réseau devait gérer lui-même à l’origine. C’est d’une certaine manière une progression naturelle puisque ces services de résolution de noms de domaines (comme 8.8.8.8, 9.9.9.9 ou 1.1.1.1) sont gratuits, pratiques et, sans que la plupart des usagers ne le sachent, sont aussi une source vitale de renseignements pour les sociétés qui les exploitent.

Beaucoup d’administrateurs de réseau en activité aujourd’hui ne travaillaient pas dans ce domaine à l’époque où les services de résolution de nom de domaine étaient toujours fournis sur le campus, et gérés via des stratégies locales par du personnel local. Cette évolution et ce fossé entre générations ont entraîné une augmentation des coûts et de la diminution des bénéfices, voire de pertes, dues à l’utilisation de serveurs externes de résolution de domaine, qu’ils soient mondiaux (8.8.8.8 et autres) ou régionaux (fournis par les FAI eux-mêmes).

Bilan des pertes

La première victime de l’externalisation du service de résolution de nom de domaine, qui auparavant était local, c’est la confidentialité. Nos requêtes externes de DNS sont rarement protégées contre la surveillance électronique et même si cette protection se développe, elle se fait au prix d’une complexité accrue. Le meilleur moyen d’éviter que nos opérations liées au DNS soient observées, suivies et analysées par des tiers, est d’abord de ne pas externaliser ces opérations. La plupart d’entre nous n’a pas de raison de craindre la surveillance des flux dans ses propres réseaux, ce qui fait de ces réseaux privés un excellent endroit pour stocker les données que nous ne voulons pas voir publiées.

La seconde déperdition liée à l’externalisation des services de résolution des noms de domaines, c’est la performance. Quel que soit le nombre de services DNS externalisés, aucun ne sera jamais accessible à nos utilisateurs et nos applications en moins d’une milliseconde.  Et donc le nombre de requêtes que nous pouvons traiter par unité de temps est réduite, parce que nous sommes dépendants des délais de transmission à la vitesse de la lumière sur une distance bien plus grande que celle de nos campus. La plupart des navigateurs ont maintenant un cache interne DNS qui permet de compenser ce handicap, ce qui n’est pas le cas de la plupart des autres applications en réseau. Là encore on peut se poser la question du bien-fondé et du besoin de cache au niveau des applications, alors qu’un simple service de résolution de DNS offrirait les mêmes avantages à toutes les applications en réseau d’un organisme.

La troisième perte que nous subissons en utilisant un serveur  externe plutôt que d’en installer un sur notre propre campus concerne la possibilité de surveillance. La majorité des malware et des botnets utilisent le DNS pour atteindre les opérateurs de commande et contrôle et certains utilisent le DNS comme un canal d’exfiltration des informations personnelles des victimes. Tous les services de résolution de noms de domaine ont le moyen de surveiller les flux sortant pour détecter d’éventuelles menaces internes. Néanmoins pour tirer les bénéfices d’une telle surveillance, il est nécessaire de visualiser son propre trafic. Si chacune des applications fonctionnant dans le réseau est directement lié à un service de résolution de noms de domaine, alors seul le gestionnaire de ce service – et non l’administrateur du système de l’organisme – sera en capacité d’en surveiller les éventuelles menaces. Certains de ces services de résolution de noms de domaine proposent cette capacité de surveillance à leurs usagers, mais la plupart ne le font pas et ceux qui le font monnayent la surveillance du trafic. (C’est ce que l’on appelle le ‘capitalisme de surveillance’, les requêtes venant d’un consommateur d’un fournisseur d’accès peuvent, par exemple, faire l’objet d’une extraction de mots clés qui sont ensuite utilisés pour lui envoyer des publicités ciblées).

La quatrième répercussion négative du recours à un service de résolution de noms de domaine externe plutôt qu’interne, c’est la perte de contrôle. Les technologies modernes de DNS permettent d’appliquer des stratégies qui rejettent les noms de domaine malveillants en fonction de critères (fixés par le SOC local) ou d’abonnements (fixés par les fournisseurs d’information externes). Une stratégie de ce type peut rejeter des résolutions basées sur des noms de domaine, de serveurs, d’adresses de serveurs, ou d’adresses de serveurs de messagerie, web et contenu distants de mauvaise réputation. Mais cet outil incroyablement puissant n’est disponible qu’aux opérateurs de serveurs DNS locaux. Quelques fournisseurs externes offrent ce service de filtrage mais sans avoir la finesse que peut avoir un serveur géré en interne.

Méthodologie

Malgré ce glissement croissant vers des services externes de résolution de nom de domaine, il n’est pas nécessaire de ne choisir qu’une seule méthode de résolution de DNS pouvant être fournie aux usagers et serveurs locaux. Le panachage n’est pas seulement une possibilité, mais est de fait déjà très courant. Le service de résolution de DNS qui sera utilisé par un serveur est en général géré depuis son panneau de configuration ou le panneau de configuration du cloud privé, et pour un ordinateur portable, une tablette ou un service mobile, le panneau de configuration du serveur DHCP. Il est donc possible d’expérimenter et  de mettre en place une transition très progressive et sans surprise pour passer de serveurs de résolution externes à des serveurs internes. Toutes les plateformes open source comme Linux ou BSD proposent de nombreuses implémentations gratuites du service de résolution des noms de domaine. Le plus ancien s’appelle BIND mais des implémentations plus récentes comme PowerDNS, Unbound et Knot constituent aussi des progiciels prêts à l’usage et très fiables. La plupart propose un modèle de configuration qui comprend la résolution interne de noms de domaine. Même si vous allez certainement affiner et améliorer cette configuration au fil du temps, le coût du « lancement » est extrêmement faible. Des produits sont aussi disponibles dans le commerce pour la résolution de noms de domaine, chez des fournisseurs comme Microsoft, Infoblox, Nominum, BlueCat et autres.

La diversification est essentielle. Chaque campus a besoin d’au moins deux serveurs de résolution de DNS indépendants, qui devraient idéalement être situés dans des segments de réseaux différents et connectés à des sources électriques différentes. Une configuration sécuritaire est tout aussi indispensable – les opérateurs doivent s’assurer qu’il ne sera répondu à aucune requête venant de l’extérieur, c’est en effet une méthode bien connue et très populaire chez les cybercriminels pour amplifier leurs attaques DDoS.  Il vaut toujours le coup de passer une demi-journée à étudier la documentation, les modes d’emploi et les forums avant d’installer un nouveau service, mais cela est particulièrement le cas pour un service de résolution de DNS. Les grandes lignes des procédures à mettre en place pour créer et faire fonctionner un service de résolution de DNS sur votre campus sont les suivantes :

• Recherchez et testez une solution et une configuration qui vous convienne pour débuter.
• Déployez au moins deux serveurs internes différents – probablement des serveurs virtuels.
• Configurez le serveur de gestion de façon à automatiser le programme, les configurations et les mises à jour.
• Faites des essais, sur le campus et en dehors, pour vous assurer que l’opération se déroule de façon adéquate (et uniquement adéquate)
• Surveillez à la fois les évènements opérationnels – comme l’accessibilité – et l’enregistrement des opérations.
• Reconfigurez un petit groupe d’éléments expérimental, comprenant des serveurs et quelques utilisateurs finaux
• Respectez une période mise en route en restant vigilant sur les résultats, pour vous sentir en confiance avec la nouvelle méthodologie
• Reconfigurez un plus grand nombre d’éléments, voire l’ensemble si possible.
• Déployez un serveur de test pour tester l’enregistrement automatisé et la politique de filtrage.
• Faites des recherches et des essais sur des options alternatives de suivi des opérations
• Faites des recherches et des essais sur des options alternatives de politique de filtrage
• Mettez en œuvre progressivement les nouvelles solutions dont les essais ont donné de bons résultats.

Conclusion

Gérer son propre résolveur local est l’une des tâches les plus simples et les plus économiques qu’un administrateur de réseau puisse mettre en place pour contrôler et protéger ses applications, ses services et ses utilisateurs, de potentiels risques. Ces risques, qui comprennent le « capitalisme de surveillance », des dépendances externes non gérées, des attaques menées via le DNS et des attaques qui pourraient être détectées via le DNS, ont un coût potentiel bien supérieur à la stratégie de limitation des dommages décrite ici. De plus, le service de résolution est tellement central à toutes les autres tâches des administrateurs de réseau que tout administrateurs qui prend le temps d’étudier  et de maitriser cette technologie augmentera son efficacité et son utilité dans son entreprise.

Cet article a été publié pour la première fois ICI.