Lorsque tu regardes, par exemple, l'implémentation du 'connection tracking', le code de chaque module est très petit. De plus, ils implémentent une seule feature dispatchée sur plusieurs modules à la fois, ce qui est dangereux et rend le code plus difficilement lisible. Sans compter les problèmes de performance.
Pour la doc.
Je suis d'accord que la doc est toujours difficile à maintenir. Mais, le problème ici est qu'il n'est tout simplement pas possible de décrire ce qu'ils font sans entrer dans des détails techniques de programmation dont l'utilisateur ne devrait pas avoir à entendre parler. Je vais esquiver la question, mais disons que si ton paquet IP ne fait pas parti d'une connection déjà existante et qu'il a le flag ACK à '1', et que tu acceptes les paquets NEW sans autre rêgle, il va non seulement passer à travers ton firewall mais en plus, il va créer une entrée dans ta table de connection. Ce qui, en passant, détruit tout l'intéret d'avoir un stateful firewall, car si aucune précaution supplémentaire n'est prise, on peut toujours se faire scanner son réseau avec un ACK scanning.
Pour ce qui est de la taille du code...
Tu me dis de proposer une implémentation plus belle et plus sûre. Et bien, j'y travaille. J'ai déjà soumis un papier pour la partie "packet filtering" (voir: http://www.cs.auc.dk/~fleury/papers/CF-infocom2003-submitted.ps.gz(...)) et j'ai trois étudiants actuellement en projet qui implémentent une extension de l'idée originale qui pourra traiter aussi les 'stateful firewalls' de la même façon. Mais, implémenter un firewall n'est pas une mince affaire et cela prend du temps. Ils ont jusqu'à cet été pour finir leur projet et je compte bien les aider.
Ensuite, en ce qui concerne les attaques DOS. Comme je l'ai dit plus haut, l'implémentation de Netfilter du 'connection tracking' est biaisée et ne permet de toute façon pas de faire du stateful sans avoir à corriger le problème avec des regles supplémentaires.
Pour ce qui est d'une alternative au 'stateful', j'ai pas mal travaillé dessus. J'ai quelques idées pour améliorer l'existant (par exemple, l'évaluation du 'round-trip time' afin de minimiser l'effet du timeout), mais, hélas, rien qui permette d'espérer s'affranchir totalement des attaques DOS. :-/
Peut-être as-tu une idée géniale ? Si c'est le cas, cela m'intéresse. :-)
Quant tu dis que ces faits sont "évidents", cela me fait un peu tiquer. Nous avons, après un an de travail, formalisé la plupart des problèmes qui touchent les firewalls actuels, nous avons aussi apporté pas mal de solutions et nous avons quelques pistes supplémentaires qui sont prometteuses. Mais, cela m'a pris du temps et pas mal de travail, alors si tu trouves cela 'facile', il va falloir que je me reconvertisse au tricot. :-)
[^] # Re: Non, non et non !
Posté par Alan_T . En réponse à la dépêche La sécurité en Open Source. Évalué à 3.
D'abord, le nombre de modules.
Lorsque tu regardes, par exemple, l'implémentation du 'connection tracking', le code de chaque module est très petit. De plus, ils implémentent une seule feature dispatchée sur plusieurs modules à la fois, ce qui est dangereux et rend le code plus difficilement lisible. Sans compter les problèmes de performance.
Pour la doc.
Je suis d'accord que la doc est toujours difficile à maintenir. Mais, le problème ici est qu'il n'est tout simplement pas possible de décrire ce qu'ils font sans entrer dans des détails techniques de programmation dont l'utilisateur ne devrait pas avoir à entendre parler. Je vais esquiver la question, mais disons que si ton paquet IP ne fait pas parti d'une connection déjà existante et qu'il a le flag ACK à '1', et que tu acceptes les paquets NEW sans autre rêgle, il va non seulement passer à travers ton firewall mais en plus, il va créer une entrée dans ta table de connection. Ce qui, en passant, détruit tout l'intéret d'avoir un stateful firewall, car si aucune précaution supplémentaire n'est prise, on peut toujours se faire scanner son réseau avec un ACK scanning.
Pour ce qui est de la taille du code...
Tu me dis de proposer une implémentation plus belle et plus sûre. Et bien, j'y travaille. J'ai déjà soumis un papier pour la partie "packet filtering" (voir: http://www.cs.auc.dk/~fleury/papers/CF-infocom2003-submitted.ps.gz(...)) et j'ai trois étudiants actuellement en projet qui implémentent une extension de l'idée originale qui pourra traiter aussi les 'stateful firewalls' de la même façon. Mais, implémenter un firewall n'est pas une mince affaire et cela prend du temps. Ils ont jusqu'à cet été pour finir leur projet et je compte bien les aider.
Ensuite, en ce qui concerne les attaques DOS. Comme je l'ai dit plus haut, l'implémentation de Netfilter du 'connection tracking' est biaisée et ne permet de toute façon pas de faire du stateful sans avoir à corriger le problème avec des regles supplémentaires.
Pour ce qui est d'une alternative au 'stateful', j'ai pas mal travaillé dessus. J'ai quelques idées pour améliorer l'existant (par exemple, l'évaluation du 'round-trip time' afin de minimiser l'effet du timeout), mais, hélas, rien qui permette d'espérer s'affranchir totalement des attaques DOS. :-/
Peut-être as-tu une idée géniale ? Si c'est le cas, cela m'intéresse. :-)
Quant tu dis que ces faits sont "évidents", cela me fait un peu tiquer. Nous avons, après un an de travail, formalisé la plupart des problèmes qui touchent les firewalls actuels, nous avons aussi apporté pas mal de solutions et nous avons quelques pistes supplémentaires qui sont prometteuses. Mais, cela m'a pris du temps et pas mal de travail, alors si tu trouves cela 'facile', il va falloir que je me reconvertisse au tricot. :-)