Deep Packet Inspection : une définition du DPI #eg8

C’est très rapidement, à l’échelle de l’histoire d’Internet, qu’est apparue l’idée de filtrer ou de gérer le trafic. Le gérer, non plus seulement en fonction des données réseau, des adresses IP de destination et de source ainsi que des informations (metadatas) de routage du réseau. Mais aussi en fonction du contenu du message. La boite de Pandore était alors ouverte. Le but recherché : identifier les messages en se basant, non plus sur la simple base des informations réseau, l’enveloppe, mais sur le contenu réel des messages (la lettre). Cette technologie d’inspection allait prendre le nom d’inspection profonde de paquets. Le Deep packet inspection, DPI était né.

Le DPI « capture » le trafic réseau, afin de reconstituer la « conversation » réseau, c’est à dire la discussion crée par les lettres mises à la suite les unes des autres. Une fois la conversation réseau ré-établie, le DPI va « lire » cette conversation à la recherche de mots importants. le but principal est de classifier la communication par types. Le code des postes et des télécommunications assimilerait le DPI, dans la vie réelle, à une violation du sacro-saint secret des communications privées.

Quelques exemples :

  • téléphonie sur IP: qui appelle qui, combien de temps, depuis où et vers où, le type d’appareil ou de logiciel utilisé pour communiquer,
  • mail: qui a envoyé un mail à qui, combien de mails dans votre votre boite mail, qui vous a écrit aujourd’hui, à qui avez-vous répondu, les sujets de votre mail, leur contenu,
  • vidéo : quel film regardez vous, en quelle qualité, combien de temps a duré votre séance, enregistrer les séquences que vous visionnez.
  • Publicité : c’est l’anniversaire de votre maman et des publicités pour des fleuristes apparaissent ? Et vous croyez vraiment que c’est de la magie ?

D’un point de vue strictement technique, le DPI travaille souvent au niveau 2 du modèle OSI, en tant que bridge, et est donc invisible pour les niveaux réseau, transport et bien évidemment applicatif. Par exemple, lors d’un traceroute, vous ne le verrez pas apparaitre dans la liste des routeurs de votre fournisseurs d’accès. On ne peut donc pas pinguer un équipement de Deep Packet Inspection sur le réseau, on ne peut pas soupçonner sa présence. Cependant, certains signes (comme la présence de publicités un peu trop ciblées) nous donnent une petite idée sur la présence ou non de ces dispositifs au coeur de nos communications.

Cependant, il possède des fonctionnalités impactant les basses couches. Par exemple, interrompre un flux réseau, pour le DPI, est trivial. Il suffit d’envoyer un « reset » de la connexion au client, en lui faisant croire que cela provient du serveur, et un même « reset » du serveur, en lui faisant croire que cela provient du client (dans le cas de TCP), il ne reste plus qu’à supprimer l’autorisation relative à cette connexion sur le DPI.

Ces deux mécanismes sont donc la base du DPI : capturer le trafic, faire de la recherche dans la capture. Il ne reste plus que la folle et inintéressante course au support de tous les protocoles à tous les niveaux réseau, transport mais aussi applicatif : IPv4, IPv6, SCTP, DCCP, TCP, UDP, GTP, HTTP, P2P, boite mail Google, boite mail Yahoo, GoogleTalk, compte Facebook, FTP, IRC, NNTP… Tout y passe. Plus une seule de vos communications non chiffrées ne peut échapper à la « gestion » du Deep Packet Inspection.

Twitter Facebook Google Plus email


9 thoughts on “Deep Packet Inspection : une définition du DPI #eg8”

  1. La liste des services susceptibles d’être écoutés par un DPI, car non chiffrés, n’est pas forcément très représentative de la réalité, si ? Je pense notamment à Gmail et Facebook, dont la connexion peut être chiffrée via SSL, et je me demande même si celle-ci n’est pas « proposée » par défaut sur Gmail.

    Cependant, le SSL a ses limites, lui aussi, et ne permet pas totalement d’empêcher le DPI tel que décrit ici, puisque les adresses ne sont pas chiffrées, si je ne m’abuse, et donc permet d’analyser les échanges entre les deux points, quitte à les couper à la hache, à défaut de les comprendre.

    Le chiffrement a ses limites, d’ailleurs. N’ai-je pas lu l’année dernière que des scientifiques américains avaient réussi à identifier le contenu des conversations VOIP chiffrées rien qu’en analysant le volume des flux échangés et en le comparant à une base de données de conversations similaires ? Le chiffrement seul ne serait donc pas suffisant pour cacher l’information à une solution de DPI très indiscrète.

    1. Très bonne observation concernant SSL, nous allons d’ailleurs y revenir un peu plus tard dans notre dossier. Sachez simplement que les solutions d’inspection en profondeur de paquet proposent une panoplie de plugins pour ces applications.
      Il faut ensuite faire la différence entre reconnaître une signature applicative et en fonction de sa nature , décider de la router ou non, et lire le payload sans arriver à le déchiffrer (ce qui n’empêche pas d’appliquer une action).
      Exemple, je suis nord coréen, un équipement détecte une conversation chiffrée, le payload ne parle pas vraiment, donc l’intelligence placée en coeur de réseau décide de ne pas acheminer ma communication car elle n’en saisit que le contexte, pas le contenu.
      Nous verrons aussi qu’à l’échelle d’un état (donc de certaines dictatures), le problème du détail SSL est contournable par un simple man in the middle suffisant à tromper la vigilance de 80% des internautes… quand les grandes oreilles n’ont pas les certificats originaux permettant un déchiffrement à la volée. ;)

  2. Bluetouff,

    tes 3 articles sont TRES interessants, mais pas assez vulgarisés, AMHA. Je ne suis pas expert réseau, mais j’ai une petite culture dans le domaine, me permettant de ne pas être complètement perdu dans un article généraliste sur le sujet, mais parfois dans ces 3 derniers articles, je suis complètement perdu (on parle quand même une fois de couche OSI, que je ne connais plus depuis ma 2eme année d’école d’ingé).

  3. ‘soir
    s/même « reset » du serveur/même « reset » au serveur/
    s/–> à mon avis il faut vulgariser cette partie.// (serait-ce là un commentaire d’écriture/relecture oublié ;) )
    quelques faute de typo ici et là (pas d’espace après « : », pas d’espace après « . »

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *