Ces règles sont-elle sécurisées ?

Bonjour,

Je voulais faire vérifier ces règles par un pro, pour savoir si ces règles que j'ai créés sont bel et bien sans risque (à savoir, les laisser 24/7). Le logiciel s'appelle EasyBox, c'est un freeplayer, pour regarder des vidéos ou photos de son PC directement à la freebox HD (tv).

Voici les règles :

TCP :
http://img352.imageshack.us/my.php?image=easyboxtcpln7.png

UDP :
http://img90.imageshack.us/my.php?image=easyboxudpfg8.png

Merci bien
Cordialement

 

Bonjour subut3x

Vous serait-il possible de téléverser ("to upload") une copie de votre jeu de règles ?

Bien que le "contenu" d'une règle soit important, la position relative de cette règle dans la liste des règles est aussi pertinente.

Le fichier ".rls" se trouve dans ce dossier:
C:\Documents and Settings\NetworkService\Local Settings\Application Data\looknstop

Il peut aussi se trouver dans: C:\Program Files\Soft4Ever\looknstop
si vous avez choisi ce dossier pour vos règles...

Etc.

Faites une copie du fichier rls
Renommez-le en y ajoutant une .TXT à la fin
téléversez-le avec votre prochain message en utilisant le bouton "manage attachment" en-bas de la fenêtre d'édition du forum. Une copie du log serait aussi une bonne source d'information. Même procédure que pour le fichier .rls...

A+

 

Bonjour Climenole,

Voici comme prévue en attachement la liste de mes règles complètes actuelles.
Tant qu'à faire, pouvez-vous me dire si les règles pour eMule et autres sont aussi sans risque svp ?

Merci beaucoup,
a bientôt

 

Bonjour subut3x

J'ai mis un peu d'ordre dans la liste des règles...

Certaines règles doivent être modifiées en ajoutant le programme correspondant à ces règles. Par exemple: toutes les règles relatives à µTorrent doivent inclure ce programme dans ces règles. Ce sont des règles spécifiques à un programme et non des règles générales pour tous les programmes.

Des règles pour des applications serveurs (en TCP) doivent toujours être spécifiques.
De même, toutes les règles d'applications clientes en UDP doivent être, elles aussi, spécifiques.

J'ai ajouté une règle poir l'InfoHash de µTorrent et une règle de blocages des paquets UDP en sortie. Ces blocages indiquent qu'une règle UDP doit être crée ou modifiée. Cela va vous aider à créer ou adapter vos règles d'applications clientes en UDP.

En P.J. Le nouveau jeu de règles subut3x et 3 captures d'écran.
Dites-nous si cela a résolu le problème.
A+

 

Re-bonjour,

je commence à un peu mieux comprendre comment ça marche pour le filtrage auto des logiciel dès qu'on les quitte, c'est très pratique en effet merci pour le tips
En faite je n'avais aucun problème, c'était juste pour savoir si on pouvait me confirmer que laisser ces règles 24/7 était sécurisé mais avec le filtrage auto ça va beaucoup mieux donc.

Sinon j'ai deux questions qui subsistent :
- Dans les réglages divers des options avancées, j'ai du mal à comprendre ces deux lignes:
"Laisser actif le filtrage internet lorsqu'on quitte l'application."
"Laisser le filtrage logiciel actif lorsqu'on quitte l'application."

Cela voudrais dire que si par exemple avec le jeu de règle de uTorrent actuel (que vous m'avez fournit), si je coche ces cases, le filtrage se désactive et laisse donc entrer les IP du P2P dans mon pc ? ou au contraire les bloque-t-elles ?

La deuxième question est en faite de savoir quelle est la différence entre la partie gauche (que j'ai encadré en bleu) et droite (rouge) de l'édition d'une règle, si vous pouvez m'éclairer sur ce point.
http://img133.imageshack.us/my.php?image=easyboxudpjl6.png

Merci beaucoup pour ces informations et a bientôt.

 

Bonjour subut3x

1)
Les options pour laisser les filtrage Logiciel et Internet actifs devraient AMHA rester cochées. Ces options permettent de continuer à bénéficier de ces deux niveau de filtrage même si l'interface graphique de LnS est fermée.

2)

Dans le cas d'une règle dont les paquets sont unidirectionnels, la partie de gauche est toujours la source des paquets et la partie de droite est toujours la destination des paquets.

Dans ce cas:

Si les paquets proviennent de ton PC
alors les ports locaux sont les mêmes que les ports sources
et se placent à gauche.

Si les paquets proviennent du réseau (local ou Internet)
alors les ports distants sont les mêmes que les ports sources
et se placent à gauche.

Dans le cas d'une règle dont les paquets sont bi-directionnels, les ports locaux et distants échangent sans cesse leurs fonctions de source et de destination...

Dans ce cas et en général AMHO il est préférable de procéder avec un ordre similaire:

Les ports locaux sont inscrits du côté gauche et les ports distants du côté droit.

« Commentaire: ambigüité de source et destination. Dans le cas d’un échange de paquets en entrée et sortie la source et la destination varient. Le terme plus exact serait local [L] plutôt que “source” et distant [D] plutôt que “destination”. C’est d’ailleurs ainsi que les indications doivent être comprises. Dans le cas de l’édition des règles de L’n'S, “source” désigne les champs d’adresses et de ports à gauche, tandis que “destination” désigne les champs à droite. »

Extrait de:
Les normes et les faits

Je joint 3 captures d'écran:


1- Une règle bi-directionnelle
2 -Une règle ICMP unidirectionnelle depuis mon PC vers la passerelle du réseau
3- La même règle ICMP unidirectionnelle vers mon PC


Est-ce que c'est plus clair comme ça?

A+

 

Re Climenole,

Merci beaucoup pour ta réponse, c'est parfait, c'est vraiment ce que je recherchait comme réponse et qui plus est, parfaitement rédigée

Ça va me prendre un petit moment avant d'assimiler ceci, mais c'est parfait en tout cas encore merci pour tes réponses !
Heureusement que j'ai fait un peu d'études de réseaux, pour en connaitre un minimum, sinon j'aurais été vraiment perdu

Encore merci et je te souhaite de passer une excellente soirée.
Cordialement

 

Bonjour Monsieur Claude,

Juste une courte note pour vous faire part de mon apréciation pour vos lumineuses explications et prises d'écran. Je n'ai pas encore fait le saut concernant Look 'n' S top (je suis un accroc à 8signs, mais j'ai déjà une idée de mon plan de sevrage via L 'n' S...), mais c'est toujours une joie de lire vos commentaires ici et sur votre blogue. [hors-sujet, j'ai littéralement éclaté de rire en partageant votre récente apostrophe adressée à la contrepetroskieuse...]

J'ai d'ailleurs archivé et mis en réserve plusieurs de vos réponses pour mieux les relire certains soirs de tempêtes quand je me déciderai enfin à la migration, ce qui devrait être pour bientôt.

Sincérement, merci de vos contributions technique et sociétale.

 

C'est vrai qu'il est très doué !

D'ailleurs j'en profite pour poser deux autre petites questions :
- Je ne voit aucune différence entre placer une règle la ou vous dites que placé tout en haut par exemple pour la règle eMule, qui fonctionne aussi bien tout en haut que placé comme vous me l'avez montré dans ma règle refaite par vos soin, est-ce normal? j'avoue ne pas trop comprendre, je suis un peu perdu si vous pouvez m'éclaircir sur ce point.
- Comment ne pas afficher le flood/spam dans le journal des IP du P2P qui se connectent lorsque je quitte l'application eMule (et si possible lorsque je laisser ouvert aussi) ?

Merci beaucoup,
Cordialement

 

Merci de votre appréciation.

Tant mieux: le rire est excellent pour la santé !
[ J'avais la "contrepetroskieuse" dans la mire depuis un bon moment... ]

Très bien. Au besoin, je serai disponible pour vous faciliter les choses.

A+

 

Bonjour subut3x

Il y a deux règles pour eMule:

TCP: eMule (Serveur) Port local 57193

Cette règle doit être placée avant (ou au-dessus) de la règle TCP : Bloquer les connexions entrantes.. Cela permet au serveur d'eMule de permettre la connexion des utilisateurs du réseau eDonkey de se connecter à votre PC pour y télécharger des fichiers partagés.

Les paquets TCP avec le flag syn envoyés à votre PC sont d'abord vérifiés par LnS s'.ils passent toute les règles précédentes jusqu'à la règle en question. Puis ils sont pris en charge par eMule si et seulement les conditions précédentes ont été respectées.

Si par exemple un paquet TCP même envoyé sur le port 57193 était reçu par le PC et que ce paquet était malformé, anormal ou illégal il serait bloqué et n'atteindrait ni eMule ni le système d'exploitation.

Si les paquet TCP n'est pas bloqué par un des règles précédentes et qu'il correspond au port choisi pour eMule il devient alors accessible à eMule qui vérifie le format et les données du paquet pour l'accepter ou le rejeter.

La sécurité est assurée par la combinaison deux niveau de filtrage: par LnS qui vérifie la conformité des paquets avec les protocole TCP-IP utilisés et le programme d'application qui vérifie si le contenu des données est valide ou pas.

Les paquets non valides sont alors bloqués par la règle TCP : Bloquer les connexions entrantes.

Ce qu'il faut comprendre ici c'est que le protocole TCP avec l'option Stateful Packet Inspection permet aussi de vérifier non seulement chaque paquet mais aussi si ce paquet fait bel et bien partie de la séquence de connexion. Si ce n'est pas le cas il est rejeté.

UDP: eMule UDP ( Port local 63497)

Cette règle est un règle d'application cliente. La position de la règle dépend des règles de blocage de paquets UDP anormaux/illégaux. La règle de l'application doit de placer après ces règles... et avant les règles de fermeture UDP telles que:

UDP : Bloque paquets sortants !! >>
UDP : Bloque le reste.

Bonne question. Il faut créer une règle de blocage analogue à la règle TCP : Bloquer les connexions entrantes. mais uniquement pour les ports utilisés par eMule ... Il suffit d'indiquer sur la ligne de la règle de ne pas journaliser d'entrée dans le log. (3 ième colonne: pas de point d'exclamation)

Cette règle doit être placée juste au-dessus ou avant la règle TCP : Bloquer les connexions entrantes.

Quelque chose comme ceci:.
.
.
.
TCP: bloquer les paquets eMule post-connexions
TCP : Bloquer les connexions entrantes
.
.
.

Même chose pour les paquets UDP. Placée après la règle client d'eMule et juste avant la règle de fermeture pour les paquets UDP. QQ chose comme ceci:
.
.
.
UDP: Bloque les paquets post-connexion eMule
UDP : Bloque paquets sortants !! >>
UDP : Bloque le reste.
.
.
.

Voyez l'idée?

Dites-nous si cela a résolu le problème.
A+

 

Merci beaucoup pour l'explication de la première question, c'est parfait je comprends maintenant beaucoup mieux le fonctionnement.

Pour la deuxième question sur le post-connexions d'eMule, j'ai fait ce que vous avez dit, et voici un extrait d'eMule en fonctionnement du journal de LNS :

http://img66.imageshack.us/my.php?image=emulepostconnexionsnm3.png

Je pense qu'on y est presque, ça a failli marcher totalement, déjà je n'ai plus les adresses IP des ports TCP (57193) et UDP (63497) d'eMule.
Une idée ?


Sinon nouvelle question, je voulais savoir s'il était normal que je puisse me connecter en ipv6 qu'une fois sur cinq environ, je pensais au début qu'il s'agissait d'un petit bug au niveau de l'application automatique de mes règles ipv6 mais en faite non, je ne sais pas trop pourquoi, il y a-t-il un moyen contre cela ?

Ci-joint, ma liste actuelle re-modifiée un peu depuis la votre, si vous pouvez en profiter pour voir et me dire si tout est ok, et trouver la faille de l'ipv6, je vous en serai fort reconnaissant.

Merci infiniment pour ce que vous faite depuis le début en tout cas.

 

Le log indique qu'eMule tente de se connecter en UDP sur les ports par défaut. Avez-vous vérifié les paramètres d'eMule? Les ports indiqués doivent correspondre à ceux de LnS... (et vice versa)

Les ICMP indiqués sont normaux ...

Je vérifie pour les autres question avant de donner la réponse...

A+

 

En effet les paramètres de LNS pour eMule sont les mêmes sur mes paramètres d'eMule niveau port, voici l'imprime écran de mes paramètres actuels d'eMule :

http://img528.imageshack.us/my.php?image=paramsemulerz8.png

Je vais me coucher, à demain !
Bonne soirée / nuit

Encore merci,
Cordialement

 

Bonjour subut3x


1) Quelques informations pour l'IPv6
http://fr.wikipedia.org/wiki/Ipv6

2) La règle "ipv6" du jeu de règles ne sert à rien...
L'utilisation de l'IPv6 ne dépend pas d'une règle de pare-feu mais des FAI par exemple. Le paramètre IPv6 ne fait qu'ajouter les support de l'IPv6 mais ne le crée pas...

3) Le reste des règles est correct.
Les deux règles que vous avez créé sont OK ! Bravo!

A+

P.S. pour eMule le problème semble provenir des tentatives de connexion "anarchiques" d'eMule sur des ports aléatoires... (Je n'utilise pas la mule souvent et je ne me souvenais plus de ce détail...)

Je vous en parles demain...

 

Bonjour Climenole

Je veut bien comprendre, et en effet je vous approuve totalement, seulement comment ce fait-il que lorsque j'active mes 3 règles ICMPV6, j'accède à la tortue animée sur http://www.kame.net (un site de test pour vérifier si on est "connectable" en ipv6, alors que si au contraire je les désactives, je suis soit disant sur le site connecté en ipv4 (donc tortue immobile) ?

Je suit votre avis, ce n'est pas très grave de toute façon, tant que ces IP sont bloquées par LNS (ouf!)
J'ai hâte de connaitre votre avis plus en détail aujourd'hui si vous pouvez.

Encore merci,
Cordialement

 

Bonjour subut3x

À propos des connexions "anarchiques" d'eMule...

Les paramètres des ports d'eMule sont au choix de l'utilisateur et ceux-ci doivent correspondre aux ports des deux règle eDonkey dont nous avons déja discuté...

Mais il y a plus: eMule se connecte aussi en TCP et en UDP via des ports aléatoires ce qui oblige à utiliser 2 règles en prévision de cela:

La première n'a pas à être crée si on utilise le jeu de règles évoluées de LnS ou les règles climenole: il s'agit de la règle TCP: Autoriser les Services Internet Standards ( R E LnS ) ou {S..0000001}; [TCP] {{ Applications Internet }} (R Clim.).

Cette règle générale autorise les ports locaux en TCP pour tous les programmes autorisés dans le filtrage logiciel.

Les ports aléatoires utilisés par eMule seront gérés par cette règle.

En ce qui concerne l'autre règle en UDP il faut la créer comme ceci:

Type : IP
Protocole: UDP
Ports locaux : dans Local
Ports distants : tous
Application: eMule

De cette façon les connexions d'eMule devraient être optimales. Les reste ne dépendent que de la vitesse du réseau local, s'il y a lieu, et de la connexion Internet.

J'espère que cela a clarifié les questions au sujet d'eMule et de LnS.
En cas contraire il suffit de poser la question ici.

Cordialement.