La première présentation a été réalisée par Patrick McHardy où il détaille version noyau par version noyau les avancées de Netfilter.
L'évènement se déroule du 11 au 14 septembre. Tout comme en 2005, un compte rendu est proposé par INL, sponsor de l'évènement. Le site est mis à jour en temps réel en suivant les différentes présentations des intervenants.
NdM Le projet Netfilter vise à fournir des solutions de firewall sous GNU/Linux via notamment l'outil iptables.
Aller plus loin
- Résumé en français et en temps réel du Netfilter Workshop (2 clics)
- Netfilter Workshop résumé (1 clic)
- Site officiel de l'atelier Netfilter (1 clic)
- Netfilter (1 clic)
- INL (1 clic)
# Merci
Posté par Frederic Bourgeois (site web personnel) . Évalué à 2.
"Malheureusement, le projet n’a guère évolué depuis l’année dernière à cause du manque de temps et de développeurs"
Il existe maintenant d'autres projets, j'ai l'impression que ça part dans tous les sens.
Je me demande si je verrais un jour un systéme de réplication de session parfaitement fonctionnel sous Linux, de préférence intégré au projet netfilter.
Il ne manque plus que ça pour la HA de mes pare-feux netfilter
Dommage d'autant que ça fonctionne bien sous d'autres OS
[^] # Re: Merci
Posté par Eric Leblond (site web personnel) . Évalué à 6.
conntrackd de Pablo Neira, membre de la Coreteam de Netfilter, est d'ors et déjà intégré à Netfilter puisqu'il se base sur du code déjà existant au niveau noyau.
Le projet est utilisable et n'attends plus que les utilisateurs.
[^] # Re: Merci
Posté par Frederic Bourgeois (site web personnel) . Évalué à 1.
En tout cas merci de l'info
[^] # Re: Merci
Posté par Misc (site web personnel) . Évalué à 2.
[^] # Re: Merci
Posté par atmaniak (site web personnel) . Évalué à 1.
[^] # Re: Merci
Posté par Victor STINNER (site web personnel) . Évalué à 3.
# Changement de leader de la Netfilter Coreteam
Posté par naotemp . Évalué à 2.
[^] # Re: Changement de leader de la Netfilter Coreteam
Posté par Eric Leblond (site web personnel) . Évalué à 2.
[^] # Re: Changement de leader de la Netfilter Coreteam
Posté par Misc (site web personnel) . Évalué à 3.
# Module owner
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
-m owner --cmd-owner 'http'
J'utilsais cela sur mes serveurs debian pour que seul apt-get (et donc le sous processus de nom 'http') puisse allez sur le net chercher les mises à jour.
Certes, un utilisateur pouvait renommer lynx en http mais en pratique, il ne le faisait pas.
Bref, même si ce n'était pas super bien carré, je trouve que cela limitait pas mal ce qui était possible et donc ne pouvait qu'améliorer la sécurité tout en restant simple et clair.
Dommage que celui-ci ne fonctionne plus de nos jours. Je n'ai pas trouvé d'équivalent pour le moment.
[^] # Re: Module owner
Posté par Victor STINNER (site web personnel) . Évalué à 3.
[^] # Re: Module owner
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
[^] # Re: Module owner
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
iptables -A OUTPUT --m owner --cmd-owner 'acroread' -j DROP
Voila, c'est tout bête mais en pratique, ca marchait. Je faisais cela avec tous les logiciels propriétaires que je devais installer sur les postes et finalement, il n'y en a pas tant que cela.
[^] # Re: Module owner
Posté par nf nf . Évalué à 1.
Il existe un projet qui va plus loin dans cette idée, il se nomme network events connector http://www.synack.fr/project/cn_net/cn_net.html
Il pourrait clairement, d'apres ce que j'ai compris, etre utilisé pour faire un pare-feu personnel "maison", mais en tant qu'admin, je vois bien comment l'utiliser dans un reseau.
Le code est tres simple, et pour le moment les regles sont stockées dans une base de données SQL (postgresql ou sql), on est loin de cette usine a gaz qu'est nufw..
d'apres l'auteur, il reste beaucoup de choses, a faire, mais ce systeme de pare feu est fonctionnel, faut voir ce que va donner ce projet
[^] # Re: Module owner
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
> fonctionnelle sur les machines SMP
Oui je le savais, même si je ne vois pas bien le rapport entre ce module et le SMP...
> Le code est tres simple, et pour le moment les regles sont stockées
> dans une base de données SQL
Je ne suis pas sur que cela soit des plus simple de faire un pare-feu avec postgresql par derrière... Cela ne me tente pas du tout d'installer un serveur SQL sur tous mes postes ! Si c'est SQLite, c'est différent, c'est juste une autre manière que d'utiliser la Berkeley DB et en plus, on peut utiliser une autre DB au cas ou...
> d'apres l'auteur, il reste beaucoup de choses, a faire, mais ce
> systeme de pare feu est fonctionnel,
Même si j'en comprends l'esprit, ta phrase n'est quand même pas claire dans l'absolue.
Dans la pratique, je pense que nufw est intéressant mais avoir un pare-feu local à chaque poste est bien aussi. Surtout que pour moi il est facile avec cfengine de configurer 50 ou 100 postes ;-)
[^] # Re: Module owner
Posté par nf nf . Évalué à 1.
>> fonctionnelle sur les machines SMP
> Oui je le savais, même si je ne vois pas bien le rapport entre ce module et le SMP...
Cest un probleme de lock: pour connaitre le owner, l'astuce de l'extension c'est d'aller cherche la structure "file" relative au paquet skbuff, mais cependant, on ne peut pas "locker" cette structure pour l'utiliser depuis les "bottom halves" du kernel en SMP
>> Le code est tres simple, et pour le moment les regles sont stockées
>> dans une base de données SQL
> Je ne suis pas sur que cela soit des plus simple de faire un pare-feu avec
> postgresql par derrière... Cela ne me tente pas du tout d'installer un serveur SQL
> sur tous mes postes ! Si c'est SQLite, c'est différent, c'est juste une autre
> manière que d'utiliser la Berkeley DB et en plus, on peut utiliser une autre DB au
> cas ou...
Non l'idée de la base de données, c'est surtout qu'elle soit centralisée pour tous les postes bien sur.
Par contre pour une utilisation en station desktop, il existe un support sqlite3 effectivement.
> > d'apres l'auteur, il reste beaucoup de choses, a faire, mais ce
> > systeme de pare feu est fonctionnel,
> Même si j'en comprends l'esprit, ta phrase n'est quand même pas claire dans
> l'absolue.
Oui, virgule en trop.
Je voulais simplement dire que l'auteur pense encore beaucoup travailler dessus, mais il estime que l'architecture de base (notament la communication/le protocole kernel<->userspace) est stable
Son but est de faire mergrt ce systeme dans le kernel officiel.
> Dans la pratique, je pense que nufw est intéressant mais avoir un pare-feu local
> à chaque poste est bien aussi. Surtout que pour moi il est facile avec cfengine
> de configurer 50 ou 100 postes ;-)
Oui une des idées que je trouve tres interessante dans ce projet, c'est la possibilité que des machines d'un meme sous reseau puisse quand meme avoir une defense entre elles, ie un systeme de filtrage.
[^] # Re: Module owner
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
> c'est la possibilité que des machines d'un meme sous reseau puisse
> quand meme avoir une defense entre elles, ie un systeme de filtrage.
Je pense personnellement que l'on va tendre vers ce modèle. Avec la recentralisation des données sur des serveurs bien identifiés, il n'y a aucune raison que les machines se fassent confiance entre-elles.
Sur un réseau local, les machines ne devraient parler qu'aux serveurs ! C'est en partie ce qui me gène dans nufw, il ne résoud pas complètement la problématique.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.