Forum Linux.debian/ubuntu Chiffrement SSH, proxy et politique de sécurité.

Posté par  .
Étiquettes : aucune
0
19
juin
2008
Hello world,

Je suis reponsable de sécurité reseaux et comme dans toute boite, on a un proxy SQUID que je gère. J'ai l'impression que certains contournent la politique de sécurité en faisant des tunnels SSH sur le 443 (HTTPS ouvert sur le proxy forcément).

Mon boulot n'est pas de leur taper sur les doigts, d'autre s'en chargent, mais de faire en sorte que ca n'arrive plus.

Bcp de postes de travails sous Windows, donc certains doivent utiliser Putty...

Je ne suis pas cryptographe, et donc j'aimerai des eclaircissement sur le chiffrement ssh.

Normalement on a:

Poste_travail <=> Squid(443)|Firewall <=> serveur_ssh_externe <=> world.

J'aimerai savoir comment sont chiffrées les données avec l'option Proxy de putty. J'ai fais des captures tcpdump / wireshark mais je n'arrive pas a lire les payloads.

Est ce que les données sont entièrement chiffrées du Poste_de_travail jusqu'au serveur_ssh_externe et le squid ne peut rien dechiffrer? J'ai verifie dans mes logs, c'est une juste ligne connect mais jai pas le contenu des paquets.

Ou alors est ce qu'elles sont chiffrées juste du Squid jusquau ssh_externe et en clair du poste_de_travail jusqau Squid?

Je suis en train de chercher une feature pour pouvoir detecter une connexion ssh cachée dans https, et je pense que c'est possible juste avec les entetes tcp + le serveur qu'il contacte + une gestion fine de CRL et x509 + une durée assez longue de la session.

Pour resumer, savoir exactement, d'où à où les données transitent en clair et d'où à où en chiffrées, dans le tunnel.

Merki :-)

  • # Imposture ?

    Posté par  . Évalué à 7.

    Je suis reponsable de sécurité reseaux
    certains contournent la politique de sécurité en faisant des tunnels SSH

    Je vais être méchant là: un responsable sécurité qui ne sait pas utiliser google pour trouver la réponse à une problématique très courante... ça s'appelle un imposteur.

    Ca ne t'es jamais venu à l'idée de faire toi-même ce tunnel de contournement ? Non je dis ça juste comme ça, mais ça t'aurais permis de comprendre.

    • [^] # Re: Imposture ?

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

      Pareil... ca me fait peur ... ca me rappelle le responsable sécurité réseaux de ma boite, qui voit rien passé... oups ^^

      • [^] # Re: Imposture ?

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

        Soyez pas mechants! Il y a plein de petites boites qui n'ont pour responsable informatique/reseau/securite/etc qu'un pauvre gars choisit plus ou moins au hazard dans la boite ("parce qu'il a deja installe office tout seul, c'est pour dire qu'il touche en info!")...

        Mathias
        SP: par contre, si la boite est plus grosse qu'une pme, alors c'est plus inquietant!

        • [^] # Re: Imposture ?

          Posté par  . Évalué à 2.

          Je pertine ta contribution, mais il n'est pas dans le cas que tu décris. Il est responsable de la sécurité, ce qui veut dire que l'entreprise est relativement grosse. Ce n'est pas une boîte de 500 personnes qui dépense de l'argent dans un responsable de la sécurité.

          A mon avis il faut atteindre les 1000 personnes pour avoir ce type de poste. Quelqu'un peu confirmer/infirmer ?

          Bien sûr il y a des tonnes d'exceptions. Par exemple l'APEC a un service informatique doté d'un informaticien pour 20 employés. Et en plus ils ont des contrats de maintenance pour des choses basiques (et en plus leur site web est pourri, et leur liste de diffusion aussi mais il ne faut pas trop en demander: ils n'ont aucun comptes à rendre).

          Tient je viens de trouver ça http://www.zdnet.fr/actualites/informatique/0,39040745,39367(...)
          Ouarf, les grosses brelles... :-) Un informaticien pour 15 personnes, record à battre.

  • # Bon allé ...

    Posté par  . Évalué à 5.

    Comme dit plus haut tu aurais pu lire une peu ne serait ce que la RFC de HTTP afin de savoir ce que fait la méthode CONNECT.

    Cette méthode ne fait une seule chose bête et méchante: ouvrir une connexion vers le serveur en question et faire suivre toutes les données qu'il reçoit vers ce serveur.

    Le proxy ne fait strictement rien d'autre: pas de chiffrement/déchiffrement, pas d'interprétation des données, rien de rien. C'est sur ce principe qu'on conserve un niveau de sécurité correct pour le SSL: la négociation SSL a toujours lieu entre le client et le serveur, le proxy n'est qu'un intermédiaire aveugle.... On pourrait dire qu'ici, le proxy est comparable à un pipe unix, il prend à un bout et renvoi à l'autre.

    Il n'y a pas de solution propre à ma connaissance pour palier à cela.
    Je sais qu'il y a des solutions propriétaires qui présente un certificat auto signé à ton client, puis qui négocie eux même la connexion au serveur pour ensuite forwarder ton traffic.
    On aura donc ici:
    client ~~ chiffré ~~> Proxy ("en clair" ds l'espace mémoire du proxy) ~~ chiffré ~~> Serveur

    Autant dire que pour mettre en place une telle solution tu dois:

    1/ faire signer une charte informatique à tes utilisateurs car, comme ça à vue de nez, c'est pas légal.

    2/ accepter que chaque visite sur un site HTTPS engendre un warning de sécurité du navigateur pour ton utilisateur.

    3/ commencer à envisager de prendre ta carte au insère ici le nom de ton parti politique liberticide favori

  • # S'ils le font, c'est qu'il en ont besoin ?

    Posté par  . Évalué à 5.

    non ? je doute fort qu'ils fassent ça pour le plaisir, surtout s'ils sont plusieurs !

    Alors pourquoi ne pas réétudier leurs besoins et proposer un service nouveau, s'intégrant dans la politique de sécurité de la boîte (et la faire évoluer par la même occasion) ?

    bon, je râle un peu, mais faut pas s'étonner si les gens en viennent à faire des tunnels HTTP s'ils n'ont pas moyen de faire autrement pour leurs besoins. Faire évoluer les choses, en plus, ça permet d'enfoncer le clou entre ce qui est utile pour le travail et ce qui ne l'est pas, et qu'ils ne puissent plus s'abriter sur "mais j'en ai besoin ! " si c'était pour un usage privé.

  • # beuh

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

    De toutes façons, tu ne pourras jamais empêcher que des gens fassent du tunneling (sur HTTP, simple) pour faire passer n'importe quoi / n'importe quel protocole, pour peu qu'ils puissent installer un relai sur un serveur à eux sur le net.

    Poste_de_travail <=> Serveur_relai_qui_va_bien(80) <=> Serveur_cible(n'importe quel port)

    Pour peu qu'on ait un serveur_relai_qui_va_bien un peu bien foutu, n'importe quel protocole (bon, sur TCP) passe. Une "politique de sécurité" ne pourra que tenter de détecter ce genre de chose, mais si le relai est bien foutu, c'est très difficile à détecter.

    La seule solution c'est de faire signer des chartes informatiques aux utilisateurs, et qu'ils soient pleinement responsables en cas de non-respect de cette charte.

Suivre le flux des commentaires

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