Autre bug du plugin RAW

Salut Frederic,

j'ouvre un nouveau post pour cette anomalie qui ne me semble pas liée à celle que j'ai déjà remontée.
Je veux obtenir le résultat suivant :
écarter tous les paquets IP dont l'adresse source ou destination (selon que le paquet est entrant ou sortant) est comprise entre X.Y.0.0 & X.Z.255.255 sauf pour les adresses IP comprises entre X.U.V.0 & X.U.V.255 avec Y < U < Z et ou mon adresse IP est comprise dans la seconde plage (X.U.V.0 <= Mon IP <= X.U.V.255).

Avec les deux règles successives suivantes,

Règle 1: Bloquer en entrée/sortie​

Field 0 : Offset ETH In(12) Out(12) EQUAL_VALUE 08.00
Field 1 : Offset IP In(12) Out(16) RANGE_IN X.Y.0.0, X.U.V-1.255​

Règle 2: Bloquer en entrée/sortie​

Field 0 : Offset ETH In(12) Out(12) EQUAL_VALUE 08.00
Field 1 : Offset IP In(12) Out(16) RANGE_IN X.U.V+1.0, X.Z.255.255​

j'obtiens le résultat escompté!

Par contre avec l'unique règle suivante:

Règle 1: Bloquer en entrée/sortie​

Field 0 : Offset ETH In(12) Out(12) EQUAL_VALUE 08.00
Field 1 : Offset IP In(12) Out(16) RANGE_IN X.Y.0.0, X.Z.255.255
Field 2 : Offset IP In(12) Out(16) RANGE_OUT X.U.V.0 & X.U.V.255
​

je n'obtiens pas le résultat escompté, alors que pourtant, d'un point de vue logique pure, il me semble que c'est strictement identique. Tous les paquets qui me sont destinés sont bloqués par cette règle.
Je rappelles que mon adresse IP fait parti de la seconde plage, si ça peut avoir une relation de cause à effet. Deuxièmement, ce problème se produit immédiatement, sans avoir à sauvegarder et recharger les règles.

Y-a-t-il un moyen d'activer des traces pour analyser ce qui se passe plus précisément ? si oui, comment ?
Voilà, en espérant que le plugin RAW (si c'est bien lui qui est en cause et non pas moi) sera corrigé le plus rapidement possible.
Si jamais tu as besoin de moi pour des tests, n'hésite pas.

P.S.
Une petite idée d'évolution mineure pour le plugin RAW me vient : il serait bien pratique d'avoir un champ commentaire pour chacun des 10 Champs (Fields), ça permettrait d'améliorer la lisibilité d'une règle créée par quelqu'un d'autre.

 

Voici un complément d'information.
Avec l'unique règle suivante:

Règle 1: Bloquer en entrée/sortie​

Field 0 : Offset ETH In(12) Out(12) EQUAL_VALUE 08.00
Field 1 : Offset IP In(12) Out(16) RANGE_IN X.Y.0.0, X.Z.255.255
Field 2 : Offset IP In(12) Out(16) NOT_EQUAL X.U.V
​

j'obtiens le résultat escompté
Donc le problème semble venir du critère RANGE_OUT.

 

Salut r_e_endymion

Je vois que tu ne lâche pas ! Bravo !

En somme tu es le BETA testeur de ce plug-in (comme on dit à Paris).

Quand tout sera au point on pourra l'utiliser...

Bonne journée.

 

Bonjour,

Il y a une petite astuce que j'ai passée sous silence pour ne pas compliquer, car je n'imaginais pas de telle règle

Quand 2 champs consécutifs ont exactement les mêmes offsets, alors c'est un OU qui est fait entre les 2 champs et non un ET.
En effet, faire un ET sur la même position avec 2 valeurs différentes n'a en général pas de sens (la valeur d'un champ ne peut être égale qu'à une valeur à la fois, pas à 2).
Sauf que dans le cas présent où les 2 champs successifs se recouvrent un ET aurait du sens, mais c'est bien un OU qui est fait et donc ça ne fait pas le résultat attendu.

Cette astuce du OU a été introduite pour éviter de faire plusieurs règles successives quand un champ (un port, une IP...) peut prendre plus de 2 valeurs. Il est par exemple possible en une seule règle d'autoriser une 10aines de ports ou d'adresses IP.

Sur le cas ci-dessus, ce qu'il faut essayer:
Field 0 : Offset IP In(12) Out(16) RANGE_IN X.Y.0.0, X.Z.255.255
Field 1 : Offset ETH In(12) Out(12) EQUAL_VALUE 08.00
Field 2 : Offset IP In(12) Out(16) RANGE_OUT X.U.V.0 & X.U.V.255

Les offset12/16 ne sont plus dans 2 champs consécutifs et un ET sera bien fait entre les 3 champs.

Utiliser un masque plutôt qu'un range permettrait peut être aussi de résoudre le problème (car l'astuce du OU ne s'applique pas aux critères de type masque).

Frédéric

 

Salut r_e_endymion et Frédéric

De plus en plus intéressant comme thread.
Finalement le topo que j'avais souhaité je vais finir par l'avoir ...

Question pour Frédéric:

Dans le filtrage internet il y a l'option
"si la règle s'applique, les règles suivantes ne sont pas examinées" ...

Dans le cas ou cette option n'est pas cochée cela devient-il:

"si la règle s'applique, les règles suivantes sont examinées"
(un "ET"...)
ou
"si la règle ne s'applique pas, les règles suivantes sont examinées"
(Un "OU"...)

ou bien alors ... Peux-tu m'éclairer là-dessus ?

( Pour une version future de L'n'S ce serait bien d'avoir des règles conditionnelles...

Bon: j'avais promis pas de "wish list" , alors je me tais...)

 

Frederic, merci de cette réponse rapide qui ouvre de nouvelles perspectives.
D'une façon générale, je pense qu'il faudrait légèrement modifier ta gestion des ET/OU de la façon suivante:

• un OU s'applique sur 2 champs successifs identiques (même offset) si les critères des deux champs sont tous les 2 'positifs' (EQUAL_VALUE1, EQUAL_VALUE1OR2, RANGE_IN, RANGE_IN_REV)
• un ET s'applique sur 2 champs successifs identiques (même offset) si les critères des 2 champs sont 'négatifs' (NOT_EQUAL_VALUE1, NOT_EQUAL_VALUE1AND2, RANGE_OUT, RANGE_OUT_REV)
• même si deux champs successifs ont les mêmes offsets, il suffit qu'ils aient des types de critère différents (positif/négatif) pour basculer d'un ET vers un OU ou vice-versa

Je ne sais pas si j'ai été clair, mais si tu as besoin d'autres explications, n'hésite pas. En tout cas, avec une gestion comme celle-ci on garde la souplesse de ton système ET/OU, tout en gérant plus de cas de figures!

Pour Climenole, tu as sûrement raison, le plugin RAW ne me semble pas très utilisé, et j'essuies sûrement quelques platres à m'en servir de façon un peu avancée, mais ça nous permet à tous d'en apprendre d'avantage sur lui, et ça donnera peut-être envie à d'autres de l'utiliser à leur tour.
En tout cas, pour le moment, l'anomalie en cours n'est pas bloquante en ce qui me concerne, car contournable, mais je n'en reste pas moins désireux de voir une correction, et d'éventuelles évolutions apportées à ce précieux plugin!

Voilà, très bonne journée à toutes et à tous

 

Salut Climenole,

Oui, et moi qui pensais qu'il ny avait pas grand chose à dire

Oui, c'est plutôt le "ou bien alors".

En fait quand cette option est décochée pour une règle, cette règle n'intervient pas du tout dans le filtre, qu'elle s'applique ou non, peu importe, c'est la prochaine règle (avec l'option cochée) qui s'applique qui fera le filtre.

Ce qui change quand on coche cette option, c'est que le paquet peut être loggé indépendemment des autres règles.
C'est plus une option pour sniffer les paquets sans interférer dans les règles de filtrage.

Conditionnelles sur ?

Pas de problème, s'il y a de bonnes idées et que ça reste dans l'esprit de Look 'n' Stop, elle seront considérées.

Frédéric

 

Bonjour r_e_endymion,

Pas de problème c'est bien la dénomination que j'utilise aussi: critères positifs/critères négatifs.
Et globalement, c'est bien fait comme tu le décris (tu vas finir par faire le topo final à ma place ), sauf pour les critères RANGE_OUT, que j'avais laissé du coté des critères positifs car ça me semblait plus judicieux dans un cas standard où les 2 ranges ne se recouvrent pas.

Par exemple si on a 2 critères:
- RANGE_OUT [3,5]
- RANGE_IN [7,8]

Avec un ET, le premier critère ne sert à rien.
Avec un OU, les 2 critères servent.

Avec des ranges qui se chevauchent (le cas sur lequel tu es tombé) c'est plus compliqué, et il semble qu'un ET était plus judicieux.

Frédéric

 

Salut à tous,

même s'il n'y a pas de topo complet sur ce plugin, ce post devrait permettre à ceux qui sont intéressés de bien comprendre la philosophie de ce plugin.

Climenole, je confirme les dires de Frederic : l'intérêt de décocher la petite flêche jaune pour une règle, c'est de pouvoir logger des paquets avant qu'ils ne soient autorisés ou refusés, et ce, sur des critères différents de la règle qui autorise/bloque le paquet au final. Je m'en suis déjà servi pour tracer et analyser certains paquets avant de créer de nouvelles règles, un peu à l'instar de ta règle temporaire sans restrictions pour une application à surveiller.

Frederic, je comprends effectivement, que selon la façon dont on utilise les critères, on veuille parfois avoir un ET et d'autres fois un OU. Comme quoi, il serait bien utile de rendre ça paramètrable.
Une possibilité serait d'ajouter dans la boite de dialogue un champ ET/OU devant les critères. Ce champ serait grisé tant que les offsets du champ courant ne seraient pas identiques à ceux du champ précédent. Une fois les offset identiques, l'opérateur aurait alors le choix de choisir ce qu'il veut faire précisément.
Une autre possibilité serait de doubler le critère RANGE_OUT, et présenter un RANGE_OUT_AND et un RANGE_OUT_OR. Je trouve malgré tout que cette seconde méthode est moins élégante et souple que la première.
Il y a sûrement d'autres possibilités, mais je n'y ai pas plus réfléchi que ça.

Sinon, concernant ce plugin et la correction à apporter, la prochaine fois que tu travailles dessus, ce serait sympa de faire les 2 petites modifications suivantes:

• se souvenir du dernier display mode utilisé lorsque l'on ouvre une règle en RAW (c'est un ti peu casse-pied d'avoir à chaque fois à changer ce champ car la valeur par défaut decimal n'est pas vraiment adaptée à ce plugin).
• ré-ordonner l'ordre de tabulation des champs de la boite de dialogue de telle sorte que lorsque l'on se déplace d'un champ à un autre avec le clavier, cela se fasse d'une façon plus intuitive et linéaire.

Voilà, bonne continuation à tous.