Pare Feu - Page 1

Là où je bosse, y'a un parefeu qui fait chier... Quand on veut faire des tests sur le serveur tomcat distant, on a accès à http (port 80), https (443) mais pas moyen de faire d'accès en http sur port 8080... il est à priori bloqué par le firewall de la boite (les clients testeurs parviennent à le consulter).

quel moyen y a t il pour moi (win xp), depuis l'intérieur, de savoir quels sont les ports qui sont ouverts ou fermés par le firewall ? j'avais pensé à netstat ou traceroute mais ça ne cadre pas du tout...

(l'idée étant de trouver un port ouvert "non standard" qui ne serait pas utilisé par le serveur pour pouvoir modifier la config tomcat en l'exploitant à la place du 8080)

t'as essayé le port 22, ou 81 ?

sinon, essaye de passer par un tunnel SSH en utilisant le port 443 (c'est que j'utilise quand je suis chez des clients)

le port 22 est déjà utilisé... 81 aussi je crois

Le port 22 c'est pour les vpn... Il faut passer par le vpn dans ce cas...

Spipu (./2) :
sinon, essaye de passer par un tunnel SSH en utilisant le port 443 (c'est que j'utilise quand je suis chez des clients)

On peut aussi utiliser un tunnel SSH inversé, c'est-à-dire on se connecte depuis l'intérieur du pare-feu à un serveur distant et on tunnelle en sans inverse depuis un port de ce serveur. Ça permet de percer presque n'importe quel pare-feu. (Seul moyen que je connais pour bloquer ça: interdire le SSH sortant.)

pas franchement, 22 c'est SSH

openvpn par exemple utilise le port 1194

cross

toujours est il que la suggestion de K² m'a donné une idée, je testerai http://inaps.org/articles/linux-logiciel-libre/putty_ssh_tunnel (tunnel ssh mais pas inversé)

ben c'est ce que j'ai conseillé au ./2

ouais mais j'étais fatigué, je revenais d'une séance de vtt

Bon bah pour info, ça ne marche qu'en TCP, en UDP il ne veut rien savoir

Les tunnels SSH sont effectivement faits pour le TCP uniquement.

J'imagine que tu peux faire du TCP, et y faire passer un tunnel OpenVPN en mode tcp, qui lui fera passer de l'udp tranquillou.