Bonsoir a tous
Je suis actuellement entrain de tester la “visibilité” de mon routeur de l’extérieur grâce au site shilds up . Pour ce faire j’ai ajouté une règle dont les paramètres sont affichés dans l’image ci dessous.
Il s’agit donc de rejeter toutes connexions entrantes (ICMP pour que mon routeur ne réponde pas aux ping et TCP pour contrer les scan de ports).
Le problème c’est qu’en mettant en application cette règle, cela empêche toute connexion de mon PC vers n’importe quel site web
Ce résultat est-il logique ? les connections sortantes (initiées de lintérieur) ne devraient pas etre bloquées non ? Ou bien y a t il en parallèle des connections entrantes (comme celle qui sont relatives aux serveurs DNS sur le port 53) qui serait indispensables pour une connexion vers un serveur web ?
[Photo supprimée]
MERCI
A mon avis, tout ce qui sort n’est pas bloqué, mais tout ce qui en revient si ! :paf:
Incoming connexions ne fait pas reference qu’aux connexions entrantes initiées de lextérieur ???
En fonction des routeurs, l’interprétation peut en être différente. Mais si c’est cette règle que tu nous montres t’empêche d’aller sur le net, effectivement, ça ne fait pas référence qu’aux connexions initiées depuis l’extérieur.
Tu veux résoudre ton problème? Dans TCP flag, mets SYN. (tu dois mettre TCP dans protocol, pour UDP, j’y reviens plus tard. )
Rappel sur le fonctionnement de TCP, histoire de bien comprendre ce que tu fais:
Une connexion initiée de lextérieur vers ton PC se déroule comme ça:
Connexion en 3 étapes : SYN (demande de connexion) - SYN,ACK (connexion vers l’autre sens + ok j’ai bien reçu ton syn) - ACK (ok)
attaquant :paf: =================> SYN ====> TOI
attaquant <================= SYN, ACK <====TOI
attaquant ==================> ACK =======> TOI
attaquant ==================> DONNÉES =======> TOI
…
…
…
C’est un peu simplifié
Bref, pour éviter ça, interdis TOUT paquets TCP venant de l’extérieur (incoming donc) ayant le FLAG SYN positionné à 1 à passer ton routeur. (poubelle) (flag = drapeau, 1=on 0=off)
Par contre, autorises les paquets ayant les FLAG SYN ET ACK à entrer. Car par exemple, quand tu te connectes sur clubic.com tu lui envois un paquet TCP avec le flag SYN et lui doit te répondre avec un paquet TCP avec les flags SYN et ACK. (Autorises aussi les paquets ayant que le flag ACK positionnée à entrer. Et aussi ceux avec les flags FIN, RST.)
Pour ces deux points à autoriser, penses en premier à appliquer la 1er règle d’interdiction, le reste tu peux l’autoriser via une seule règle qui laisse passer “tout le reste qui n’est pas initiée de lextérieur”, ce qui correspond correspond aux réponses dues à tes requêtes, comprendre connexions initiées depuis lintérieur. Pour ce faire, tu prends ta capture d’écran et tu change “deny” par “accept” mais cette règle DOIT être située APRÈS la règle d’interdiction ci-dessus, sinon tu laisses la porte grande ouverte! En effet, les routeurs/firewalls appliquent les règles dans l’ordre. Si la première est contradictoire avec la seconde, c’est la première qui passe.
Tu peux quand même interdire en entrée les paquets tcp avec le flags PSH, pas utile. (attention, si tu as à la maison un serveur administrable à distance, ne le fais pas!) .
Le routeur doit être capable de faire la différence entre une connexion initiée depuis lextérieur et une réponse à une requête initiée de l’intérieur, via ces flags TCP par exemple. (mais pas seulement).
Et aussi, coches la case “APPLY STATEFUL INSPECTION”. Toujours.
Ça permet au routeur de mieux faire la différence entre une connexion initiée depuis lextérieur et une réponse de l’extérieur due à une requête initiée de lintérieur. En effet, sinon un pirate peut très bien passer directement à l’étape syn-ack/ack, et gruger ton routeur… Dans ce cas, un port, qu’il soit fermé ou ouvert, renvoi un paquet RST, qui peut trahir la présence soit de ta machine (sous certaines conditions!), soit de ton routeur malgré que tu bloques le ping. En cochant la case, il vérifie que les paquets soient dans un contexte logique, genre pas de syn-ack si tu n’as pas émis un syn juste avant…
D’ailleurs, je t’ai fais tout un speech sur les flags TCP, mais si ça se trouve cocher la case Apply stateful inspection suffit :paf:
Vérifies?
Pour ce qui est du filtrage UDP, je ne suis pas sûr avec ton routeur, essais en interdisant tout le protocole UDP en Incoming, tout en cochant “apply stateful inspection” en croisant les doigts pour que ça suffise pour lui à faire la différence entre connexion depuis lextérieur ou simples réponses.(pas de flag en udp) Parce que aller sur internet sans DNS ça va poser problème. :paf:
Sinon tu veux dire quoi par " […] TCP pour contrer les scan de ports"?
Les ordis de ton LAN sont sensés être en adressage privé!!! donc exit le scan de port sur ton ordi, et en adressage privée on ne peut pas se connecter dessus depuis lextérieur, à moins que tu ne sois dans une DMZ ou que tu ai fait de la redirection de port quand tu as un serveur chez toi…
Normalement, un scan de port ne donne rien du tout sur une connexion d’un particulier qui n’a pas de serveur chez soit. (excepté quand dmz ou qu’on ouvre des ports pour jouer à certains jeux en réseau où il n’y a pas de serveurs dédiés, comme CoD 6)
Ou bien y a t il en parallèle des connections entrantes (comme celle qui sont relatives aux serveurs DNS sur le port 53) qui serait indispensables
:non: Le port 53 (et c’est de l’UDP dans notre cas) c’est le port coté serveur. Coté client c’est un port dynamique (> 1024). Et non, tu n’as pas à ouvrir de port sur ton routeur pour que ça marche.
Un dernier point: J’ai cru comprendre que tu as bloqué TOUT l’ICMP? Contentes toi de bloquer les requêtes de ping entrantes, dans la config de ton routeur ça consiste à bloquer en incoming les messages ICMP echo request, (type 8 si jamais c’est demandé). (L’icmp ce n’est pas que le ping!)
Edité le 26/07/2011 à 01:15
En fonction des routeurs, l’interprétation peut en être différente. Mais si c’est cette règle que tu nous montres t’empêche d’aller sur le net, effectivement, ça ne fait pas référence qu’aux connexions initiées depuis l’extérieur.
Effectivement! et donc ça change tout !!
Bref, pour éviter ça, interdis TOUT paquets TCP venant de l’extérieur (incoming donc) ayant le FLAG SYN positionné à 1 à passer ton routeur. (poubelle) (flag = drapeau, 1=on 0=off)
Par contre, autorises les paquets ayant les FLAG SYN ET ACK à entrer. Car par exemple, quand tu te connectes sur clubic.com tu lui envois un paquet TCP avec le flag SYN et lui doit te répondre avec un paquet TCP avec les flags SYN et ACK. (Autorises aussi les paquets ayant que le flag ACK positionnée à entrer. Et aussi ceux avec les flags FIN, RST.)
Pour ces deux points à autoriser, penses en premier à appliquer la 1er règle d’interdiction, le reste tu peux l’autoriser via une seule règle qui laisse passer “tout le reste qui n’est pas initiée de lextérieur”, ce qui correspond correspond aux réponses dues à tes requêtes, comprendre connexions initiées depuis lintérieur. Pour ce faire, tu prends ta capture d’écran et tu change “deny” par “accept” mais cette règle DOIT être située APRÈS la règle d’interdiction ci-dessus, sinon tu laisses la porte grande ouverte! En effet, les routeurs/firewalls appliquent les règles dans l’ordre. Si la première est contradictoire avec la seconde, c’est la première qui passe.
Voila j’ai essayé de faire comme tu as dis, j’ai donc rajouté les deux règles dans l’ordre que tu m’as indiqué :
Le menu déroulant des TCP flags ne donne le choix que pour: ALL, SYN, NOT-SYN. J’ai donc mis dans la deuxième règle (celle qui est censée autoriser les packets) NOT-SYN mais malheureusement le résultat est le même; aucun site ne répond. J’ai changé “NOT-SYN” pour “ALL” et la aussi même résultat. Il semblerait que mon routeur interprète les règles d’une manière différente …?
[Photo supprimée]
Et aussi, coches la case “APPLY STATEFUL INSPECTION”. Toujours.
Ça permet au routeur de mieux faire la différence entre une connexion initiée depuis lextérieur et une réponse de l’extérieur due à une requête initiée de lintérieur. En effet, sinon un pirate peut très bien passer directement à l’étape syn-ack/ack, et gruger ton routeur… Dans ce cas, un port, qu’il soit fermé ou ouvert, renvoi un paquet RST, qui peut trahir la présence soit de ta machine (sous certaines conditions!), soit de ton routeur malgré que tu bloques le ping. En cochant la case, il vérifie que les paquets soient dans un contexte logique, genre pas de syn-ack si tu n’as pas émis un syn juste avant…
D’ailleurs, je t’ai fais tout un speech sur les flags TCP, mais si ça se trouve cocher la case Apply stateful inspection suffit
Vérifies?
Ok alors dans tous les cas l’autorisation directe des requêtes TCP avec les flags SYN+ACK est à eviter pour les raisons que tu as évoqué :neutre:
Apres avoir compris un petit peu le principe de l’option “apply statefull inspection” j’ai decidé de reprendre depuis le debut. J’ai supprimé les deux regles plus haut, j’en ai créé une qui autorise tous les packets sortants en ayant pris soin de cocher la fameuse case pour dire au routeur “fais gaffes à ces packets (TCP, UDP et autres…) ce sont les miens alors prends en soin ;)”. Puis j’ai ajouté une deuxième qui interdit TOUT ce qui rentre (comme celle de mon premier poste) et la… ca marche enfin :bounce: avec un rapport de shilds up faisant etat que tous les ports sont “Stealth”
[Photo supprimée]
Maintenant les questions que je me pose (car y’en a toujours sont:
-Est ce que cette maniere de proceder est correcte ?
-Qu’est ce que la “In interface” qu’on ne peut modifier qu’en mode “outgoing”? Lorsque je l’ai mise sur “Public” je suis revenu au même problème plus haut.
Sinon tu veux dire quoi par " […] TCP pour contrer les scan de ports"?
Les ordis de ton LAN sont sensés être en adressage privé!!! donc exit le scan de port sur ton ordi, et en adressage privée on ne peut pas se connecter dessus depuis lextérieur, à moins que tu ne sois dans une DMZ ou que tu ai fait de la redirection de port quand tu as un serveur chez toi…
En fait je crois que me suis mal exprimé ce que je voulais dire par “contrer” c’est juste rester invisible et que le routeur ne renvoie pas la réponse qu’un port est fermé (l’objectif de mon test) malgré que cela empêche déjà toute connexion sur mon ordi (NAPT sans DMZ sans redirection de ports)
@Matcav : j’ai supprimé la DMZ depuis ta réponse a mon précédant sujet
@TCP/IP je te remercie infiniment pour ta réponse claire et précise, ca m’a permis de comprendre beaucoup de choses à la fois!!