Effectivement, y en un 1 qui suit :-)
Ma remarque n'etait pas motivée par le bug en question uniquement (en fait le bug porte sur un masque qui a "oublie" de fixer l'IP destination).
Il faudrait ameliorer les modules conntrack pour decortiquer les protocoles qui passent dans le port ouvert. Si j'autorise le DCC irc, y a pas de raison de laisser passer du SSL natif (bon ok, avec une machine complice a l'exterieur, tout est toujours possible, par exemple encapsuler le SSL dans des faux fichiers qui passent en vrai DCC).
Bref la securite c'est pas simple quand les utilisateurs veulent avoir accès a tout un tas de protocoles.
Si j'avais du temps, je me pencherai bien sur la validation des protocoles. Il faudrait pouvoir dire: j'ai autorisé le port 80, si c'est autre chose que de l'HTTP couic on ferme.
d'ailleur cela devrait etre en userland a brancher sur le module iptables qui demande la validation a un process userland ....
[^] # Re: Use the source, Luke !
Posté par PLuG . En réponse à la dépêche Trou de sécurité dans Netfilter. Évalué à 1.
Ma remarque n'etait pas motivée par le bug en question uniquement (en fait le bug porte sur un masque qui a "oublie" de fixer l'IP destination).
Il faudrait ameliorer les modules conntrack pour decortiquer les protocoles qui passent dans le port ouvert. Si j'autorise le DCC irc, y a pas de raison de laisser passer du SSL natif (bon ok, avec une machine complice a l'exterieur, tout est toujours possible, par exemple encapsuler le SSL dans des faux fichiers qui passent en vrai DCC).
Bref la securite c'est pas simple quand les utilisateurs veulent avoir accès a tout un tas de protocoles.
Si j'avais du temps, je me pencherai bien sur la validation des protocoles. Il faudrait pouvoir dire: j'ai autorisé le port 80, si c'est autre chose que de l'HTTP couic on ferme.
d'ailleur cela devrait etre en userland a brancher sur le module iptables qui demande la validation a un process userland ....
faut murir le projet :-)