Bonjour,

J'ai une question dont je n'arrive pas à trouver (comprendre?) la logique.

Voici une partie du cours de réseaux :

Lors de l'établissement d'une connexion, que ce soit en TCP ou en UDP, un port source est choisi par la machine qui émet la requête. Nous allons nous servir de ce port pour identifier la machine qui a émis la requête à l'origine. Sachant que ce port est choisi aléatoirement entre 1024 et 65535.

Si nous reprenons l'envoi de la trame et y ajoutons les informations de couche 4, cela donne:

Donc si j'ai bien compris, une requête qui part d'un PC a toujours un port supérieur à 1024.

On fait donc notre requête vers un port 80 sur un serveur web et un paquet revient, mais à un autre port que que le port 80.

Lorsque je fais le parallèle avec la partie firewall, losqu'on créé une règle on nous dit qu'il ne faut pas oublier d'ouvrir le port dans l'autre sens afin que la réponse revienne. Mais le port du pc client qui fait la requête n'est pas le port 80 puisqu'il est nécessairement supérieur à 1024.

Donc il faudrait permettre via le firewall un retour sur tous les ports? Y'a comme qui dirait une c.... dans le potage...Ce serait open bar sinon non?

Évidemment la question est valable pour les autres ports : shh, ftp etc...

Par avance merci.

-
Edité par B.O. 9 octobre 2016 à 3:23:23

Salut,

C'est un bon raisonnement que de se poser cette question. Et la solution est assez simple : on autorise uniquement certains états TCP à rentrer (mais bien quelque soit le port). Par exemple, un nouvelle connexion TCP, initiée depuis l'extérieur (état NEW), ne passera pas par défaut. Par contre, une connexion initiée depuis l'intérieur et qui revient sera autorisée, car elle est dans l'état ESTABLISHED. Je t'invite à te renseigner sur le protocole TCP pour mieux comprendre tout ça

+1 Doezer

J'ajouterai que si on n'utilise pas les états (comme au bon vieux temps des noyaux 2.2 avec ipchains) on peut tout à fait filtrer le retour les paquets en utilisant là encore le port 80, mais non pas comme port destination mais comme port source. 

Je filtre à l'aller sur le port 80 destination, puis au retour sur le port 80 source.

Bonjour

Ok c'est plus clair maintenant . Merci à vous pour vos réponses!

Du coups j'ai une autre question en rapport avec le port forwarding.

Dans le cours, il est dit qu'il ne peut y'avoir qu'un seul type de service par réseau. (1 ssh, 1 ftp etc) sauf si on change le port d'écoute. J'essaie justement de mettre en pratique cette partie en essayant de faire ceci :

Sur la machine virtualbox sous débian, j'ai fait écouté le service ssh sur le port 23. (ip 192.168.1.102)

Sur mon routeur j'ai laissé le ssh sur le port 22. (ip 192.168.1.1)

J'ai fait un port forwarding sur le port 23  du routeur pour diriger ce qui arrive par le wan sur l'IP de VirtualBox (ip 192.168.1.102) sur son port 23
Pour me connecter via le client ssh de mon téléphone portable, j'ai saisi : user@monipfree:23 pour me connecter
--> Ceci fonctionne

Pour le serveur ssh en écoute sur le routeur (ip 192.168.1.1) sur le port 22, je n'ai rien changé.
Pour me connecter via le client ssh de mon téléphone portable, j'ai saisi : root@monipfree:22 pour me connecter
--> Ceci ne fonctionne pas

La politique par défaut des INPUT sur le routeur est ACCEPT

Donc ma question : y'a-t-il une erreur quelque part dans ma façon de procéder?

Encore merci.

Tu es sûr qu'il y a un serveur SSH sur le routeur ? Si c'est une box d'opérateur, ce n'est pas possible.

Un port ouvert ne veut pas dire qu'il y a forcément un serveur derrière.

Doezer a écrit:

Un port ouvert ne veut pas dire qu'il y a forcément un serveur derrière.

@Doezer : oui avec un netstat -antp je vois que le port 22 est bien sur LISTEN,  c'est un routeur sur Openwrt derrière la freebox (qui est en mode bridge)

@elalitte : puisque la connexion via WAN sur VirtualBox se fait correctement, il n'y a pas de raison de changer quelque chose à ce niveau soit mal configuré?

 Pour essayer de comprendre ce qui se passe en utilisant tcpdump, quel serait la commande pour : "écouter le port 22 et afficher packets perdus ou rejetés provenant d'internet"?

Encore merci pour votre aide.

-
Edité par B.O. 11 octobre 2016 à 12:52:41

Si les paquets sont perdus, c'est difficile de les afficher

elalitte a écrit:

Doezer a écrit:

Un port ouvert ne veut pas dire qu'il y a forcément un serveur derrière.

Doezer, je ne comprends pas bien cette phrase ? ;-)

Un port ouvert dans le firewall

Mais comme le dit B.O., le port n'est non seulement pas fermé, mais bien en LISTEN.

@B.O.: Elalitte parle de la chaine OUTPUT car si tu as autorisé les requêtes sur le port 22 en INPUT, mais que tu ne les as pas autorisé à repartir dans la chaine OUTPUT, ça ne marchera pas. Les paquets allant vers ta machine virtuelle ne passent par aucunes de ces deux chaines, qui sont spécifiques aux paquets "allant" ou étant créés dans les couches supérieures à la couche réseau.

tcpdump -i ethx port ssh

Peux-tu nous faire un schéma réseau, on y verra plus clair :-)

P

Voici un shcéma du réseau

r rapport

Et voici le contenu du firewall :

Config defaults
        option syn_flood '1'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'

config zone
        option name 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        option network 'lan'

config zone
        option name 'wan'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'
        option network 'wan wan6'

config zone
        option name 'VPN_FW'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'
        option network 'PIA_VPN'

config redirect
        option target 'DNAT'
        option src 'wan'
        option dest 'lan'
        option proto 'tcp udp'
        option dest_ip '192.168.1.102'
        option name 'ssh'
        option dest_port '23'
        option src_dport '23'

config forwarding
        option dest 'VPN_FW'
        option src 'lan'

config forwarding
        option dest 'VPN_FW'
        option src 'wan'

config forwarding
        option dest 'lan'
        option src 'wan'

config forwarding
        option dest 'wan'
        option src 'lan'

Dans la zone WAN, j'ai remplacé input REJECT par ACCEPT, mais cela n'a rien changé.

Par rapport à tcpdump, comme je me connecte à mon routeur vi putty, cette requette :

tcpdump -i ethx port ssh

M'affiiche ausi la connexion en cours de putty. Est-il donc possible d'ajouter un autre filtre pour les connexions entrantes depuis le web? J'ai vu qu'il existant l'option host mais j'ai l'impression que ça ne fonctionne que pour une ip privée.

Merci à vous.

-
Edité par B.O. 11 octobre 2016 à 18:00:35

Si tu peux utiliser host

tcpdump -i ethx pot ssh and host 192.168.0.1 par exemple.