> Oui, mais il est difficile de documenter une telle fonctionalité.
Pas vraiment. Si tu commences par expliquer que la gestion d'etats est un concept plus general que TCP et ce que ca implique. Je suis en train de finir un article sur Netfilter, j'espere que ce sera clair ;)
> Plutôt que de dire que c'est un bug, je préfère dire que c'est une erreur de design.
Une erreur de design, non, pas plus qu'un bug d'ailleurs.
De mon point de vue, c'est une option dont la valeur par defaut serait mal positionnee. Je m'explique.
Le fait de pouvoir flaguer un paquet ACK en NEW est utile (pour moi en tout cas). Mais il est certain que le patch no-pickup devrait etre applique par defaut et que les utilisateurs devraient avoir a le desactiver pour passer au fonctionnement actuel. La dessus on est OK.
Sur l'erreur de design, que je comprends comme l'affirmation qu'un tel comportement ne devrait pas etre possible, je ne suis pas d'accord, dans la mesure ou il se justifie parfaitement, non pas par une histoire fumeuse de reboot, mais par le fait qu'un etat est un concept qui, pour etre applique a l'ensemble des flux qu'on peut etre amene a traite (TCP, UDP, GRE, ESP, etc.) doit amha etre dans une certaine mesure decorrelable du concept de connexion TCP. La encore je m'explique.
L'usage courant de la gestion des etats des connexions TCP est de suivre une connexion TCP dans son ensemble, du SYN/SYN-ACK/ACK au FIN/double FIN-ACK/ACK de fin. Mais on peut aussi vouloir traiter l'etat de flux _IP_, dont la charge serait des paquet TCP particuliers. Par exemple reperer un ACK scan en matchant justement les paquet TCP ACK en etat NEW.
Bref, il me semble une bonne chose de garder cette lattitude. Par contre, en faire le comportement par defaut, c'est autre chose. En tout cas, je te trouve bien severe avec Netfilter.
Sinon, j'ai lu ton papier, mais je te fais suivre mes commentaires/questions par email, ce n'est pas trop le lieu pour cela ;)
[^] # Re: --state NEW et Syn
Posté par Cédric Blancher . En réponse à la dépêche La sécurité en Open Source. Évalué à 2.
Pas vraiment. Si tu commences par expliquer que la gestion d'etats est un concept plus general que TCP et ce que ca implique. Je suis en train de finir un article sur Netfilter, j'espere que ce sera clair ;)
> Plutôt que de dire que c'est un bug, je préfère dire que c'est une erreur de design.
Une erreur de design, non, pas plus qu'un bug d'ailleurs.
De mon point de vue, c'est une option dont la valeur par defaut serait mal positionnee. Je m'explique.
Le fait de pouvoir flaguer un paquet ACK en NEW est utile (pour moi en tout cas). Mais il est certain que le patch no-pickup devrait etre applique par defaut et que les utilisateurs devraient avoir a le desactiver pour passer au fonctionnement actuel. La dessus on est OK.
Sur l'erreur de design, que je comprends comme l'affirmation qu'un tel comportement ne devrait pas etre possible, je ne suis pas d'accord, dans la mesure ou il se justifie parfaitement, non pas par une histoire fumeuse de reboot, mais par le fait qu'un etat est un concept qui, pour etre applique a l'ensemble des flux qu'on peut etre amene a traite (TCP, UDP, GRE, ESP, etc.) doit amha etre dans une certaine mesure decorrelable du concept de connexion TCP. La encore je m'explique.
L'usage courant de la gestion des etats des connexions TCP est de suivre une connexion TCP dans son ensemble, du SYN/SYN-ACK/ACK au FIN/double FIN-ACK/ACK de fin. Mais on peut aussi vouloir traiter l'etat de flux _IP_, dont la charge serait des paquet TCP particuliers. Par exemple reperer un ACK scan en matchant justement les paquet TCP ACK en etat NEW.
Bref, il me semble une bonne chose de garder cette lattitude. Par contre, en faire le comportement par defaut, c'est autre chose. En tout cas, je te trouve bien severe avec Netfilter.
Sinon, j'ai lu ton papier, mais je te fais suivre mes commentaires/questions par email, ce n'est pas trop le lieu pour cela ;)