Socket d'écoute sur le port 80 derrière IPCOP ...

[zorgh]

Bonsoir

J'ai installé un IPCOP avec les addons suivants : guardian, psad et fail2ban

Derrière le FW, j'ai un serveur avec une application en écoute sur le port 80.

Ma configuration est la suivante :

Routeur lan/wifi (avec un filtre TCP/IP) qui redirige les paquets sur le port 80 vers le FW IPCOP <--> IPCOP <--> Serveur

J'ai redirigé les communications entrantes (port source 80) sur mon eth1 (rouge) vers le port de destination 80 et ll'interface réseau eth0 (vert).

J'ai deux questions :

1) dans la mesure où j'ai qu'une machine derrière le fw, je suppose que je n'ai pas besoin de poser une DMZ. S'agissant d'un service qui doit être le plus secure possible, est-ce que mon raisonnement est bon ?

2) j'ai fait des test depuis un poste nomade connecté en wifi sur le routeur. Je saisi le nom de domaine et le chemin qui va bien sur mon navigateur. J'accède alors au service sur le port 80.
tcpdump -i eth0 et tcpdump -i eth1 me renvoie bien les traces des communications entre ma machine nomade et le serveur.

Lorsque je demande à un ami sur un hôte distant de se connecter dans les mêmes conditions, il ne parvient pas à accéder à la page web d'accueil et je ne vois aucune trace de la transaction.

Pourriez-vous m'aider à analyser cette situation ?

Merci bien

[ccnet]

Routeur lan/wifi (avec un filtre TCP/IP) qui redirige les paquets sur le port 80 vers le FW

Dans un premier temps je vérifierai que c'est bien ce qui se passe. Au vu du test effectué on peut ne pas en être certain. Ce routeur c'est une livebox, freebox ou qq chose de ce type en mode routeur ?

Je ne suis pas certain que les connexions wifi et externes sont traitées de la même façon par le routeur, ce qui expliquerai la différence observée.

[zorgh]

Le routeur est un linksys wrt54g. Il est en mode gateway.

J'ai branché également derrière ce routeur, un autre serveur. Sur ce dernier, un serveur web est actif.
Entre le routeur et le serveur se trouve un pont filtrant qui tourne sous une debian avec des règles IPTABLES maison.

Le paramétrage de la redirection des paquets sur le routeur et concernant le port 80 est identique à la situation que j'ai évoquée s'agissant du service tournant derrière IPCOP.

Dans ce contexte, la connexion depuis le poste nomade ou depuis un poste distant est effective.

Pour faire mes tests (puisque j'avais déjà un service en écoute sur le port 80), j'ai dans un premier temps changé le port d'écoute en 8080 (sur le service derrière IPCOP) en adaptant préalablement la redirection sur IPCOP. Cela ne fonctionne pas depuis un poste distant.
J'ai ensuite désactivé le serveur Web sur le premier serveur (derrière le pont filtrant) et reparamétré le service derrière IPCOP en socket d'écoute 80. Cela ne fonctionne pas depuis une machine distante d'où mon post.

[zorgh]

J'ai essayé d'utiliser un proxy anonyme pour simuler une connexion externe.
tcpdump -i eth1 sur ipcop neme renvoie rien.
J'ai lancé un sniffeur sur le poste nomade au moment de la connexion.
J'ai une connexion en syn / syn, ack / ack, par contre derrière, j'ai un timeout avec la page suivante qui s'affiche :



Est-ce que le fait de faire du forwarding à 2 reprises (au niveau du routeur et au niveau du pare-feu) est gênant ?

Quelqu'un a t-il une idée pour analyser le problème ?

Je mettrais le problème sur le compte d'IPCOP et d'une mauvaise configuration. Mais où !?

Merci

[zorgh]

Après plusieurs tests, j'ai ajouté dans les paramètres du routeur un "Port Triggering" sur le port 8080.
Cela semble fonctionner.

Est-ce que quelqu'un peut m'expliquer le "Port Triggering" associé au "Port Forwarding" était indispensable ?

Merci

[ccnet]

Port triggering : probablement un NAT "conditionnel", déclenché lorsqu'une condition définie survient. Le transfert de port n'est effectif que sous certaines conditions. Elles sont sans doute définies dans le Linksys.
Finalement nous avons un problème non pas d'ipcop mais de fonctionnement, paramétrage du Linksys.
Je ne connais pas en détail ce produit donc je ne sais dire si c'est indispensable, pourquoi et quand cela se déclenche.

[zorgh]

Pour évacuer le problème du linksys, je l'ai supprimé et j'ai placé IPCOP et le service derrière le FW dans un autre environnement (à savoir sur un autre site).

Tout fonctionne correctement. Je parviens bien à accéder au service (port 80) et à son paramétrage (port supérieur à 5000).

Voilà que maintenant, je ne parviens plus à me connecter à IPCOP en https sur le port par défaut 445.

Syn, syn, syn mais jamais de syn/ack ...

C'est bizarre car il n'y a à priori pas de filtre en amont d'IPCOP.