Journal Détecter le tunneling SSH

Posté par  .
Étiquettes :
0
30
juin
2008
Bonjour,

Le tunneling SSH pour ceux qui ne connaissent pas (mais qui sur ce site ne le pratique pas quotidiennement pour accéder à son serveur à la maison pour contrôler la température de son bain... bref, je m'égare), le tunneling SSH donc, c'est l'utilisation d'une fonctionnalité du protocole SSH qui permet de faire passer un protocole quelconque à travers la connexion SSH qui elle-même est une connexion SSL comme une autre. Le but étant, la plupart du temps, de masquer l'utilisation d'un protocole habituellement proscrit (smtp, pop, vnc, protocole de gestion de la baignoire, etc.), voire de traverser un proxy qui pense bêtement faire du HTTPS...

Une équipe de chercheurs italiens a publié un papier (http://www.ieeexplore.ieee.org/xpl/freeabs_all.jsp?isnumber=(...) expliquant comment différencier une connexion légitime d'une autre et expliquant comment identifier différents types de protocoles (en particulier du p2p) pour pouvoir faire tomber ces connexions. le principe de la différenciation est basé sur une étude comportementale de la connexion (taille et fréquence des paquets, etc.)

L'article expliquant rapidement mais dans un langage plus compréhensible (mais en anglais) est là : http://coderrr.wordpress.com/2008/06/28/detecting-ssh-tunnel(...) . En gros :
- la méthode ne fonctionne pour l'instant que si l'on maîtrise le serveur SSH distant mais elle pourrait rapidement évoluer pour s'en affranchir
- il y a quelques détections de faux positifs (dans le cas d'une ré-authentification) mais les chercheurs disent que ce n'est pas grave, un utilisateur légitime ré-essayera et pourra se connecter. Mouais...
- l'idée derrière tout ça est pour un FAI (grand public ou bien une société vis-à-vis de ses utilisateurs) de pouvoir filtrer et/ou brider certains types de trafic
- il est également indiqué que la méthode serait contournable par des outils de tunneling spécialement conçus pour modifier les tailles et fréquence d'envoi de paquets pour perturber la détection... Bref, le chat et la souris...rien de neuf...

voilà voilà...

  • # La problématique habituelle

    Posté par  (site web personnel) . Évalué à 6.

    Sois G l'effort fournis pour generer le traffic illicite.
    Soit D l'effort fournis pour detecter le traffic illicite.
    Si G/D < 1, le cas actuel, la souris gagne.
    Si G/D > 1, le chat gagne.
    Si G/D= 1: heu, quelqu'un a déjà vu ce cas ?

    Dans notre cas, ssh est extrement simple à utiliser et demande de moins en moins de ressource (CPU ayant une unité crypto).
    Par contre, l'analyse du profil d'une connection demande une grosse masse de calcul et ne fonctionne qu'aprés coup (on a déjà établis le tunnel et commencé à balancer le flux de données).

    En prime, ici ca ne fonctionne pas si la compression zlib est active !!

    Donc cas 1), la souris gagne.

    • [^] # Re: La problématique habituelle

      Posté par  . Évalué à 4.

      Question bête : la compression zlib n'est pas activée par défaut sur la plupart des distrib Linux ?

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: La problématique habituelle

      Posté par  . Évalué à 10.

      L'effort fourni !

      C'est drôle comme les gens ont du mal avec les participes passés en « i ». C'est probablement dû au fait que les trois verbes en« ir » les plus fréquents sont en fait en « ire » et, par conséquent, du troisième groupe, pas du second : lire, dire, écrire (et je ne parle pas de «&nsbp;suffire&nsbp;», ce serait trop compliqué :-).

      Je le dis parce que certaines personnes sont même allées jusqu'à révoquer mes modifs Wikipédia pour restaurer les fautes. Pourtant, ce n'est pas bien dur de faire la différence :

      Au féminin, dit-on « fournie » ou « fournise » ?

    • [^] # Re: La problématique habituelle

      Posté par  . Évalué à 0.

      La méthode la plus simple: éducation des employés et charte informatique qui interdit ce genre de pratiques. Ensuite une seule porte de sortie du réseau (un proxy) simple à auditer...
      Normalement la personne qui "n'a pas compris" lors des explications initiales ne récidive pas.

      • [^] # Re: La problématique habituelle

        Posté par  . Évalué à 3.

        euh... oui mais encore faut-il que cette porte de sortie soit surveillée et si oui que les outils soient capables de détecter le tunneling.

        le tunneling ssh à travers un proxy est très simple à partir du moment où le serveur ssh distant écoute sur le port 443.

        concernant le compression zlib, effectivement c'est une limitation que j'ai oublié de mentionner dans le journal, mais c'est une question de temps avant que cette limitation ne soit levée (c'est le boulot du chat).

        de leur coté, les souris continuent leur bonhomme de chemin et finissent toujours par gagner (en tout cas dans Tom&Jerry!)

        • [^] # Re: La problématique habituelle

          Posté par  . Évalué à 1.

          Ce que j'essayait de dire, c'est que le problème ne doit pas être traité au niveau technique, sinon effectivement c'est sans fin.
          Il faut que l'entreprise sache eduquer (expliquer pourquoi les choses sont interdites) et communiquent régulièrement vers les employés. Il faut aussi que la direction ait le courage de ses décisions et que les personnes qui ne respectent pas la règle soient durement sanctionnées.
          Quand la règle et la sanction est connue, les personnes n'enfreignent plus la règle (surtout pour bosser), elles font *enfin* remonter leur besoin au service informatique (au lieu d'inventer des astuces tordues et dangereuses ...)

          Sinon des méthodes techniques y'en a pour les chats aussi, par exemple un proxy qui fait une sorte de man-in-the-middle pour vérifier le contenu de ce qui passe sur le port 443. mais y'a pas que le port 443 qui passe, y'a aussi des tunnels qui fonctionnent avec des requêtes HTTP (sans ssl)... il n'y aura jamais de solution technique définitive (sauf a couper le web ... et encore, les employés sont prêt a apporter des modems au boulot ...)

      • [^] # Re: La problématique habituelle

        Posté par  . Évalué à 3.

        et surtout, en même temps que l'éducation des employés, l'étude réelle et sérieuse de leurs besoins et l'adaptation de la politique de sécurité à leurs besoins (et parfois éduquer aussi les responsables sécurité pour qu'ils sachent se remettre en question :-)

        Il y en a qui s'étonnent de voir des commerciaux bougeant tout le temps, avec (très) peu de connaissances informatiques, mettre en place des tunnels HTTP pour pouvoir avoir accès à leur PC du bureau...

  • # Interdire et le meilleur moyen de ne rien contrôler

    Posté par  (site web personnel) . Évalué à 4.

    Interdire, interdire... Ou comment les gens vont faire plus de trous de sécurité en essayant de contourner l'interdiction.

    En informatique, la souris gagnera toujours, le meilleur moyen de gérer la sécurité est d'autoriser en contrôlant, ça évite aux gens (99% d'entre eux du moins) d'avoir l'idée de crypter leur communications...
    Une autre solution : tout interdire, mais l'entreprise mourra d'elle-même.

    A noter : il existe plusieurs logiciels obéissant à l'envoi de mail, donc pour interdire toute action il faudrait interdire les mails... Ca ferait mal à la productivité de l'entreprise.

    • [^] # Re: Interdire et le meilleur moyen de ne rien contrôler

      Posté par  . Évalué à 4.

      Oui, une fois on m'avait raconter qu'a une certaine epoque une entreprise avait décidé de bloquer l'acces internet. Et ben certains utilisateurs était passé avait fait leur propre acces en RTC (aujourd'hui ca pourrait etre avec du wifi). Bien sur ces points d'acces pirate était sans parfeu ni autre protection...

  • # intéressant, MAIS...

    Posté par  . Évalué à 2.

    Si tu ouvres le SSH, tu ouvres le SSH, point. En entreprise, c'est généralement uniquement ovuert vers des serveurs pour de l'administration de serveurs, pas vers un serveur extérieur permettant de relayer n'importe quoi. Sauf serveur web externalisé par exemple.
    Sinon, on est en train de parler des méthodes de contournement pour surfer/mailer/jabberiser peinard en allant en SSH sur port 443 pour faire croire à une connx https, c'est différent. Dans ce cas, voici mon point de vue :

    ----

    Moi qui m'étais toujours plus ou moins demandé comment arrêter ça dans la pratique (bien que personne ne m'ait empêché de le faire pendant 10 ans et qu'à mon tour maintenant je ne cherche pas à empêcher les gens de le faire).

    Par contre, en effet, ça doit être méga-couteux et forcera les gens à trouver (trouer ?) encore plus osé.... Bref, c'est très con.
    Un simple stunnel doit être encore plus dur à détecter, juste plus lourdingue à utiliser il me semble.

    D'autant qu'il y a plus simple pour enrayer beaucoup de cas : tu écoutes les messages retours des serveurs contactés sur port 443. Si y'a marqué en gros dedans "OpenSSH gnagnagna", ben tu bloques. Ca supprime tous les gens qui n'iront pas jusqu'à recompiler le serveur SSH pour changer le message par un joli "apache2 blabla" en guise de réponse. Et encore faudrait que le client suive non ? je ne suis pas sûr que putty aime voir un retour genre "apache2 blabla"
    T'as aussi la méthode qui consiste à aller voir le soit-disant site HTTPS. Via un simple wget, tu dois te claquer une belle erreur si c'est un SSH derrière.

    Bref, les souris ont encore de beaux jours devant elle. Et c'est un gros rat qui vous le dit :)

  • # beurk

    Posté par  . Évalué à 9.

    Sans même avoir besoin de la lire, je sais d'hors et déjà que cette étude est au mieux particulièrement médiocre (du moins si son résumé fait par ce journal est correct). L'analyse de trafic est une technique connue et appliqué depuis des dizaines d'années. Faire ce genre d'étude en ne parlant spécifiquement que de ssh et en sortant une ânerie aussi grosse que "ne fonctionne pour l'instant que si l'on maîtrise le serveur SSH distant", c'est faire preuve d'un manque de culture ce qui est impardonnable lorsque c'est justement la culture de son domaine de "recherche".

    Et évidemment les contres-contres-mesures pour être "pas mal" insensible à l'analyse de trafic existent aussi. La plus simple et plus efficace (mais un peu contraignante...) étant de combler les périodes ou le débit est faible avec du garbage et de shaper celles ou le débit est fort pour obtenir un flux à débit constant.

    Alors si les FAI s'amusent à vouloir faire de l'analyse de trafic et qu'en rétorsion les logiciels de P2P jouent à la courses aux armements en lissant le traffic à un niveau constant, je vous dit pas le putain de bordel que ça va engendrer.

    En plus d'être mauvaise, cette étude est donc irresponsable.
    hop -> poubelle.

    • [^] # Re: beurk

      Posté par  (site web personnel) . Évalué à 1.

      Ce n'est en effet a priori pas nouveau. Cf. fl0p (http://lcamtuf.coredump.cx/soft/fl0p-devel.tgz ) par exemple:

      Fl0p is a passive L7 flow fingerprinter that does not examine packet payloads, only their relative sizes, the sequence of client-server traffic, and its timing. The tool can be thus used to peek into encrypted tunnels, automatically tell users from robots, and far more.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.