Pourquoi le monitoring de bout en bout ? L’exemple du filtrage par DNS

Mettons-nous en situation

Prenons le cas d’un gouvernement, cela pourrait être dans n’importe quel pays, qui entend bloquer le contenu sur Internet qu’il juge illicite. Après maintes délibérations, ledit gouvernement régalien réagit en permettant, sans contrôle judiciaire, de pouvoir filtrer l’Internet, sous les directives de ses services de Police. Je passe tous les problèmes éthiques que pose cette solution et j’ai suffisamment écrit (sur mon blog par exemple) sur ces thèmes.

Concentrons-nous plutôt sur l’aspect technique de la solution proposée et les conséquences évidentes. Comme j’ai déjà pu l’écrire : « re-centraliser ce qui ne le devrait pas conduira à affaiblir la robustesse de l’Internet qui deviendra plus sensible en cas d’attaque ou d’effets de bords. »

Le problème est maintenant comment devenir proactif face à ces risques et ne pas passer son temps à subir, trop tard, les dysfonctionnements qui ne manqueront pas de se produire.

 

Le Filtrage par Serveurs de Noms

La solution retenue par ce gouvernement est de filtrer les accès aux sites grâce au mécanisme de résolution du Serveur de nom (DNS). Ce “résolveur”, forcément proposé par le fournisseur d’accès, est ce qui permet le lien entre ce que vous demandez (www.witbe.net par exemple) et l’adresse physique du serveur censé répondre à la requête : 81.88.96.84.

Les risques inhérents à cette méthode sont nombreux, par exemple :

  • Risques de sur-blocage, car on s’attaque à un serveur entier et non la page précise qui contient le contenu illicite
  • Inutilité devant la facilité de passer outre ce type de contrôle
  • Risques de surenchère… quand on s’apercevra que l’on peut facilement détourner la mesure, le risque est grand d’imposer au fournisseur d’accès de n’accepter des requêtes de type résolution de nom que depuis ses serveurs “sous le contrôle” du gouvernement ou même d’imposer des mécanismes de DPI (Deep Packet Inspection) pour aller plus loin dans le contrôle de qui fait quoi, et quand ?
  • Risques politiques tout court. Pour le moment, nous vivons en démocratie. Que se passera-t-il le jour où, pour des raisons de sécurité, nous aurons re-centralisé le fonctionnement des réseaux Internet chez nous et que ce contrôle tombera dans de mauvaises mains ?
  • Risques liés aux effets de bords et en particulier de l’introduction de technologies modifiant le fonctionnement normal des mécanismes de l’Internet (résolution de noms, routage…) au travers de l’introduction d’exceptions.

« Des sites comme Google.fr, Wikipedia se sont retrouvés “parqués”, suite à une erreur humaine, apprend-on aujourd’hui. »

C’est possible tout cela ?

Et oui, c’est justement ce qui vient d’arriver en France. Des sites comme Google.fr, Wikipedia se sont retrouvés “parqués”, suite à une erreur humaine, apprend-on aujourd’hui.

La réponse d’Orange n’a pas tardé, devant le flot de clients mécontents :

« Suite à une erreur humaine lors d’une opération technique sur un serveur, nos clients ont pu rencontrer des difficultés à se connecter au site google.fr et wikipedia.fr et se voir re-routés vers un message du ministère de l’intérieur. L’incident a duré environ 1h et l’accès aux sites est en voie de rétablissement. »

Il n’est pas question de montrer un coupable ici. L’erreur peut toujours arriver. C’était prévisible. Cela peut arriver à tout opérateur et cela arrivera à tout opérateur. Comme toujours, le problème n’est pas dans le contrôle, mais dans la maîtrise d’une situation délicate.

 

Ces erreurs sont inévitables

Volontaires, involontaires, elles n’en sont que plus humaines et faciles à corriger… si on est prévenu d’un problème avant que cela ne soit trop tard, c’est à dire avant que de nombreux clients s’en aperçoivent.
Quand elles sont techniques, ces erreurs peuvent être beaucoup plus difficiles à contrôler et à corriger, du fait des technologies employées. En effet, les mécanismes de cache mis en jeu font qu’il n’existe pas un serveur de résolution de noms, mais plusieurs, qui eux même doivent se synchroniser avec une source commune et ensuite “vivent leur vie”. Des situations de “pollution de racine” ou pire, de piratage, peuvent toujours arriver et faire pointer une requête vers un site erroné.
C’est ce qu’il se passe quand un site identifié comme “terroriste” est redirigé vers la page “parking” du ministère. Mais on pourrait tout à fait imaginer que pour une zone géographique servie par le “résolveur”, un “pirate” fasse pointer un site bancaire, Google, ou des sites de vente en ligne, vers ses propres sites. Imaginons les dégâts… et surtout, le moyen de s’en apercevoir n’est pas si évident.

Les solutions de monitoring classique sont en échec car elles se basent plus sur la disponibilité d’un service (ou d’un équipement) que sur la qualité de sa réponse.

« Il est fondamental d’être prévenu le plus rapidement possible de tout dysfonctionnement, avant que l’utilisateur lui-même ne l’expérimente trop souvent et en vienne à se plaindre définitivement. Généralement, quand un utilisateur se plaint, c’est trop tard. »

« On ne résout pas les problèmes avec les modes de pensée qui les ont engendrés »

… disait Albert Einstein. On pourra toujours essayer de tout contrôler, mais rien ne remplace la pratique. Et c’est là que le Remote Monitoring comme nous le préconisons chez Witbe peut grandement aider, en fournissant des informations essentielles, à partir du lieu de réel risque opérationnel, en ce qui concerne :

  • la disponibilité des résolveurs
  • la performance : en combien de temps ils répondent, sont-ils sensibles à la charge et de quand ?
  • et l’intégrité… et nous y voilà : répondent-ils bien correctement ? Quand on demande www.bnp.fr, est ce qu’au moins 213.56.75.132 est bien retourné ?

Il convient en effet de réellement demander la résolution du nom que l’on veut contrôler, à l’endroit où il va être servi. Il faut “surveiller”, comme du lait sur le feu, le bon fonctionnement de tous les résolveurs installés dans le réseau.

 

Il existe pourtant des solutions : les Robots Witbe SLM assurent ce type de contrôle

Ils peuvent vérifier qu’un résolveur réponde correctement.
Ils peuvent vérifier qu’un site qui devrait être bloqué est bien toujours bloqué. C’est à dire qu’ils peuvent s’affranchir du mécanisme du résolveur et implémenter une partie de la liste gérée par l’OCLCTIC pour vérifier que les sites, en fonction de mises à jour de la liste dans les résolveurs, se retrouvent toujours bel et bien bloqués.

On le voit, la pratique prend le pas sur la théorie dans l’Internet. Il est fondamental d’être prévenu le plus rapidement possible de tout dysfonctionnement, avant que l’utilisateur lui-même ne l’expérimente trop souvent et en vienne à se plaindre définitivement. Généralement, quand un utilisateur se plaint, c’est trop tard. La QoE est alors durablement affectée et tout l’excellent travail fourni auparavant vole en éclat.

Pour plus d'informations sur nos technologies de test et de monitoring, n'hésitez pas à nous contacter!