Imaginons que l'on ferme tous les ports sauf le 80 et 443 sur un pare feu (reseau local vers le net) : comment fait on pour empêcher quelqu'un de faire un tunnel ssh ?

avec un proxy HTTP genre squid, mais meme dans ce cas il y aura quand meme une possibilite de passer outre avec les bons outils, enfin je vais pas trop detailler car je suis pas certain que ce soit charte-compliant

Je pense que le mieux c'est de ne laisser aucun port d'ouvert a part le proxy.
 
Et bien sur de na pas faire passerelle, comme ca, sa oblige les clients à passer par le proxy.
 
bon apres il se peut que certaine applications et besoin du net sans passer par le proxy etc... il y as quand meme des contraintes.

La seule différence qu'il y a enrte HTTPS et et SSH c'est les premiers paquets. En SSH le serveur envoit sa bannière (i.e. : SSH-2.0-OpenSSH_4.6p1 Debian-5 sur une debian lenny). En HTTPS le serveur attend. Il faut donc réussir à analyser le premier message et déterminer si c'est de l'HTTPS ou du SSH.
 
J'ai jamais regardé si squid ou un autre système de proxy gérait la conformité protocolaire de HTTPS... Sinon avec netfilter l7 ca devrait pouvoir se faire.

C'est pas tout récent (2005) mais ça donne des idées :
http://www.certa.ssi.gouv.fr/site/ [...] index.html

Merci les gars
En gros y doit pas avoir beaucoup de réseaux vraiment sécurisés alors ...

A mon avis c'est mort:
 
Regarder corkscrew, il est capable d'établir un ssh à travers une connexion SSL sur le port 443. Je vois pas comment c'est possible de détecter ça puisque c'est dans un tunnel ssl....

corkscrew = ssh over https
 
Il existe même du ssh over http tout court, et c'est pas sorcier de programmer un service en non connecté, donc il est même possible de faire passer des tunnels sur des proxys http. Bref, il manque plus que ssh over html/images/css et là c'est la fin des haricots... !
 
edit: bon après il n'y a pas que l'analyse protocolaire dans la vie, mais c'est plus le même prix