Intercepté et empêcher un Tunnel http

Quelqu’un peut me dire comment détecter et tuer un tunnel http.

Merci d’avance

Sois plus précis… (et bonjour au fait)

Désolé pour les bonnes manières … Bonsoir,

Alors j’ai un script que j’ai écrit en python qui me permet de faire un tunnel http via un proxy. Donc via le tunnel j’arrive à faire du ssh. Mon but est mettre en place une solution qui me permettra:

  • De détecter un tunnel http qui passe par le proxy.
    _ D’empêcher que le tunnel fonction.

Les modos ne font pas leur travail :unamused: ,on voit qu’ils sont fatigués de marcher à pied :mrgreen:
Je bascule dans SD.

Bonsoir.

D’après mes connaissances, je connais 1 bon moyen de détecter et d’empêcher un tunnel SSH, mais ça va te faire sourire.

  • je suis administrateur de mon réseau, j’ai donc pour réflexe de l’analyser; De vérifier que mes clients l’utilisent à bon escient et ne pas hésiter à utiliser des logiciels comme Wireshark, ainsi que NMAP (oh le méchant !!) mais encore plein d’autres dont je ne ferais pas la pub’ ici.
    Exemple, un hôte de ton réseau qui communique en https avec un hôte distant (sur la toile), pas mal de données circulent, chiffrées. Bon la tu t’inquiètes pas ! Une petite résolution de nom pour voir si c’est un site internet, (eu sa boite mail par exemple) ou alors si c’est un nom qui te fait penser à un fournisseur d’accès avec la ville ou le quartier indiqué dans le nom… euh la par contre je crois qu’il fait du tunneling… ou qu’il a un vpn (petite pub au passage pour openvpn). Pas de panique ! avant d’être parano, vérifie bien, par exemple un telnet sur le 443 de l’hôte distant, ou essaye avec ton naviguateur web ! Ca ne donne rien ? tu voie la version de ssh (ou d’openvpn !) apparaître ? Bon là ok, tu peux être sur… il détourne ton proxy.
    La solution, simple. Soit tu créer une rêgle dans ton firewall qui interdit la communication entre les 2 hôtes (brutale et efficace, j’adore cette méthode !) sinon tu bloque avec le proxy… mais moins marrante.

Il existe d’autres méthodes, j’ai vu ça sur un site, des italiens ont fait des recherches et ont même publiés un livre.
Liens :
http://coderrr.wordpress.com/2008/06/28/detecting-ssh-tunnels/
http://www.ieeexplore.ieee.org/xpl/freeabs_all.jsp?isnumber=4533036&arnumber=4533370&count=1109&index=333

J’espère ne pas avoir trop dit de bêtises à cette heure-ci mais si tu as des questions, n’hésite pas.

Bon courage,

A au fait, je n’ai pas parlé des sondes IPS, du firewall Checkpoints, des Arkoons (…), nous sommes dans un forum Debian, je veux pas me faire luncher !

Une réserve : il existe un programme dont je ne me rappelle plus le nom qui écoute sur un port (par exemple 443) et aiguille les connexions entrantes soit vers un serveur HTTPS soit vers un serveur SSH en fonction du protocole utilisé par le client.

un proxy socks ?

enfin c’est plus rare déjà… ça devient poussé ! je pense que c’est déjà pas mal de detecter un serveur ssh !

Non, rien à voir avec un proxy SOCKS. Si je devais le qualifier, ce serait plutôt une espèce de reverse proxy HTTPS+SSH transparent. Son but est de faire cohabiter les deux services sur un même port.

avec la même @IP?

bon j’ai une petite question à poser… on va dire que le SSH est autorisé vers l’extérieur … je en vois pas comment tu peux bloquer mon proxy socks? comme je lui dis que le “traffic web” passe pas mon tunnel ssh… :slightly_smiling:.

Si tu as la réponse j’aimerai bien savoir !

bé je fais le brutus et je créer une règle dans mon pare-feu qui bloque les discussions entre les 2 hôtes sur tel ou tel port, ou tous !

Au fait la meilleur solution est de prendre une mesure préventive. Autrement dit de détecter et d’empêcher de manière automatique le tunnel…

J’ai trouvé une solution (monkey.org/~jose/blog//viewpage. … e=flowgrep) que je vais essayer.

Une réserve : il existe un programme dont je ne me rappelle plus le nom qui écoute sur un port (par exemple 443) et aiguille les connexions entrantes soit vers un serveur HTTPS soit vers un serveur SSH en fonction du protocole utilisé par le client.[/quote]

Il s’agit d’sslh que j’utilise: le principe est essez simple:
Une connexion sur un serveur SSH commence par un envoi de la banière par le serveur.
Une connexion HTTP commence par un envoi de la requête par le client.

sslh attend donc 2s, si il ne reçoit rien, c’est que c’est une requête SSH et il envoit le tout sur le serveur SSH sinon il envoit le tout sur le serveur Web.

PS: Refais ton lien.

Le nom ne me dit rien, mais le principe était bien celui-là.
Quel lien ?

Le lien de fifiant je crois

Le lien monkey.org/~jose/blog//viewpage. … e=flowgrep

[quote=“PascalHambourg”]Le nom ne me dit rien, mais le principe était bien celui-là.
Quel lien ?[/quote]
C’est un source que j’ai récupéré je ne sais où, tu as le paquet chez moi

deb boisson.homeip.net/debian lenny divers

source

deb-src boisson.homeip.net/source/ ./

J’ai corrigé un bug (les processus restaient zombies, j’ai mis un signal(SIGCHLD,SIG_IGN));
qui règle (un peu cradement) la chose). C’est le paquet sslh que j’utilise avec succès depuis une bonne année. Je l’ai même signaler dans les applications du jour je crois bien.

On s’est mal compris. Je demandais “quel lien” non au sujet de sslh mais de ta remarque [quote=“fran.b”]PS: Refais ton lien.[/quote]
que j’avais prise pour moi puisque tu l’as écrite après m’avoir cité, mais il semble que tu t’adressais en fait à fifiant.

Mouais c’est pas une solution … si dans ta boite il y’a 1000 personnes et 1/10 fait du ssh… c’est ingérable…

personne n’a une solution?

que j’avais prise pour moi puisque tu l’as écrite après m’avoir cité, mais il semble que tu t’adressais en fait à fifiant.[/quote]
Maintenant on s’est bien compris :slightly_smiling: