Look'n'Stop pas vraiment statefull ?!?

Bonjour,
je viens d'essayer votre firewall il est vraiment très complet mais malheureusement je ne comprend pas la façon d'on il as été conçu.

je m'explique sur un firewall ordinaire (pix,FW-1, ...) on défini une règle dans un seul et unique sens le firewall match le syn et accepte automatiquement le syn ack pourvu qu'il corresponde à la connexion qui est en train de s'établir.
Or look'n'stop lui ne le fait pas l'on doit donc utiliser la notion de double sens (in et out dans la même règle) mais cela permet souvent de le bypasser

Exemple : je veux pouvoir me connecter à un serveur irc et protéger un serveur web qui tourne sur la machine port 3080 je crée donc ma règle :
accept mon @ip :all all @ip:6667
dans les 2 sens sinon les paquets de retour du serveur seront bloquer

deny all en dernière règle.

mais voila si quelqu'un sais que j'utilise un serveur irc et veux se connecté a ma machine il lui suffit de se connecté de son ip avec le port source 6667 vers mon ip sur le port 3080 (nc -p 6667 ipcible 3080)
et voila en effet le paquet est bien matcher par la règle 1 il le laisse donc passer

voila ma question pourquoi n'avoir pas mit un vrai mode statefull qui gère complètement l'établissement de la session plutôt que votre mode qui ne check que si le paquet correspond bien a une connexion existante ?

ps: je sais qu'en bloquant les syn l'on règle le problème mais il faut être sur d'avoir mit en 1er les règles mode serveur 2eme une règle qui bloque les syn et enfin les règles en mode client cela est pas super pratique (genre les règle pour le ftp).

 

Bonsoir,

Bon ben je t'avouerais que cette histoire de double regle m'a aussi perturbé mais pas dans le principe... Je suis loin d'etre une bete dans le domaine mais je pense que si le stateful inspection n'est pas built-in (mais tout de meme activable a la demande ) c'est simplement parce que la charge peut dans certains cas etre trop importante et donc susceptible de faire planter LnS...

 

le fait que le stateful soit activable/desactivable LnS ne me gene pas au contraire.
mais quand on l'active cela aurai ete bien qu'il gere aussi l'etablisement de la connexion ...

surtout que LnS gere en partie les connexions donc le morceau de code a ajouté n'est pas enorme et cela eviterai que LnS se transforme en passoire ...

 

bonjour,

si j'ai bien compris ton problème, i suffirait juste que le SPI s'applique avant les règles de filtrage, et non après comme il semble etre le cas actuellement ?
(comme ca un SYN-ACK est accepté par le SPI sans risque d'être bloqué par une règel de filtrage).
Ceci dit je ne sais pas comment le SPI est implémenté dans le code, c'est pas moi qui vais savoir

Je comprend bien ton problème, et selon l'implementation actuelle, soit il faut deplacer le SPI s'il n'est pas au tout debut, soit le modifier comme tu le suggère.
Malheureusement je crois que les pbs d'incompatibilité eMule/SPI sont prioritaires car très demandés :-/

gkweb.

 

Ce qu'il faudrait pour emule c'est :

1) soit améliorer le SPI pour le rendre compatible avec un plus grand nombre de connexions (deporter le code, priorité accrue/reglable, plus proche du noyau?)
2) ou tout du moins connaitre les limites du SPI pour pouvoir proposer un reglage pour la mule qui soit fiable (max connections emule < max connections SPI LnS).

Sait on comment est borné le SPI actuel (plafond nb connexions) ou cela depend il de la machine qui l'acceuille?

Ralala que de questions

 

houla j'ai pas du être clair dans mes explications
Il ni a pas de problème dans le code du mode stateful c juste que pour moi il manque une partie de code qui gère l'établissement de la connexion.

Cette partie pourra évité les règles à double sens qui si elles sont mal positionnées permettent de bypassé LnS.

Pour ce qui est du nbre de connexion, le problème est valable pour tous les firewall.
Au plus il y a de connexion au plus cela prend de la mémoire et du CPU
il ni as pas de solution miracle.

pour répondre a la 2)
la limite et de 128 pour la 2.05 et 64 pour la 2.04

 

Bonjour,

Merci pour ta réponse! Je viens de consulter l'aide de LnS 2.05 et effectivement le nombre maximum de connexions TCP surveillées passe de 64 à 128 pour le TCP Stateful Inspection (shame on me!!!). Autre chose, je ne pretend pas que le SPI est mal codé, juste que les limitations actuelles rendent difficile l'utilisation d'emule si pas de reglages adéquates. Comme je ne suis pas le seul a avoir eu le pb j'essaie de trouver une solution rationnelle a celui ci (les incantations vaudous n'ont rien donné ). Pour ce qui est du design du SPI/bout de code que tu veux rajouter je ne peux etre que d'accord.

Bon j'ai réduit le nb de connexions max d'emule a 64 (passerai a 96) et réactivé le SPI pour voir

Vive LnS

 

pourtant le sacrifice de vierge marche bien d'habitude

 

Bon ben va falloir que j'essaie les sacrifices pcq mon reglage n'a pas tenu plus de 4 heures, jusqu au moment ou les 3/4 des connexions web et mises a jour d'AV foiraient (specifiées dans le journal comme bloquées par le SPI)...