Un truc intéressant (enfin !) dans iptables et vous me direz si cela existe dans ipf c'est la capacité de mémoirisation du filtre à savoir un test établi n'est vrai que si (en plus du test) l'adresse source, destination (et peut-être à l'avenir les ports) a déjà été rencontrée n fois au cours des s secondes passées.
A ma connaissance ça n'existe pas sous ipf ni sous pf (note: ipf != pf). Pour pf, et dans certains cas seulement, on peut obtenir un résultat approchant en jouant avec les options limit, timeout et/out tag mais bon, c'est assez pauvre au regard de cet objectif.
C'est, je pense, un domaine (ous sous-domaine) qui est appelé à devenir important car c'est un premier pas timide vers le filtrage comportemental et ça, ça m'a vachement manqué ces 2 ou 3 dernières années.
Après discuter si ce type de filtrage doit être réalisé par le noyau ou via userland est un autre débat mais au moins qu'il y ait un minimum dans le noyau quitte à configurer des trucs via sysctl.
db -- email : usenet blas net
Benjamin Pineau wrote:
Un truc intéressant (enfin !) dans iptables et vous me direz si cela
existe dans ipf c'est la capacité de mémoirisation du filtre à savoir un
test établi n'est vrai que si (en plus du test) l'adresse source,
destination (et peut-être à l'avenir les ports) a déjà été rencontrée n
fois au cours des s secondes passées.
A ma connaissance ça n'existe pas sous ipf ni sous pf (note: ipf != pf).
Pour pf, et dans certains cas seulement, on peut obtenir un résultat
approchant en jouant avec les options limit, timeout et/out tag mais
bon, c'est assez pauvre au regard de cet objectif.
C'est, je pense, un domaine (ous sous-domaine) qui est appelé à devenir
important car c'est un premier pas timide vers le filtrage comportemental
et ça, ça m'a vachement manqué ces 2 ou 3 dernières années.
Après discuter si ce type de filtrage doit être réalisé par le noyau ou via
userland est un autre débat mais au moins qu'il y ait un minimum dans le
noyau quitte à configurer des trucs via sysctl.
Un truc intéressant (enfin !) dans iptables et vous me direz si cela existe dans ipf c'est la capacité de mémoirisation du filtre à savoir un test établi n'est vrai que si (en plus du test) l'adresse source, destination (et peut-être à l'avenir les ports) a déjà été rencontrée n fois au cours des s secondes passées.
A ma connaissance ça n'existe pas sous ipf ni sous pf (note: ipf != pf). Pour pf, et dans certains cas seulement, on peut obtenir un résultat approchant en jouant avec les options limit, timeout et/out tag mais bon, c'est assez pauvre au regard de cet objectif.
C'est, je pense, un domaine (ous sous-domaine) qui est appelé à devenir important car c'est un premier pas timide vers le filtrage comportemental et ça, ça m'a vachement manqué ces 2 ou 3 dernières années.
Après discuter si ce type de filtrage doit être réalisé par le noyau ou via userland est un autre débat mais au moins qu'il y ait un minimum dans le noyau quitte à configurer des trucs via sysctl.
db -- email : usenet blas net
db
Cedric Blancher wrote:
Le Wed, 09 Jun 2004 00:07:15 +0000, db a écrit :
Netfilter failover me semble bien malade (5 posts en mai). VRPP semble plus sage et plus fonctionnel également.
VRRP ne fait que le failover. Netfilter+VRRP marche _très_ bien, mais c'est le failover du pauvre. Le problème, c'est la synchronisation des tables d'état du master et du slave. VRRP ne permet pas de faire ça et ne résout qu'une partie du problème. Certes mais c'est toujours mieux que de perdre le fw.
Maintenant c'est insuffisant dans les grosses config c'est vrai d'autant que les fw commerciaux savent faire.
Concernant Netfilter Failover, ça ne pourra partir que lorsque Harald Welte aura fini de coder l'interface ctnetlink qui permet à un utilitaire userspace de monitorer/modifier la table d'état de Netfilter via une socket netlink (de la même manière que les démons de routage accèdent à la table de routage sous Linux) qui est pré-requis incontournable de ce genre d'outil. De même, l'interface nfnetlink (monitoring/modification du ruleset via socket netlink) ne sera pas de trop. Eh ben, mazette, pourvu qu'il ne se perde pas en route le pauve Harald :-)
On n'est pas rendu sinon. Le projet Nf-failover a démarré il y a 3 ans je crois.
Ce serait même une hérésie : traiter du contenu au niveau du noyau. Mais gageons que nous en arriverons toute de même là, dans un souci de faire tout et officiellement pour des << petits >> besoins.
C'est même pas le problème. Si on fragmente assez, on va très vite bypasser le filtre, qui ne peut pas se permettre de garder trop de données en mémoire avant de les scanner sous peine de :
1. pénaliser ses perfs 2. introduire de la latence dans le réseau Oui mais c'est un choix consenti (s'il est compris) : où on possède un
véritable fw qui fait son boulot ou, pour le pauvre, son fw fait tout (couteau suisse) au prix à payer (baisse des performances voir émergences de bugs). Y'a plein de cas identiques (cf. d'autres plates-formes) où les puristes et les << mondialistes >> s'affrontent. Est-ce bien, est-ce mal ? Cf le cas du firewall VRPP ci-dessus.
Eh oui, j'ai pris un accès (puis 2) IPv6 afin de faire des tests avec ip6tables il y a ... presque 3 ans convaincu que ce produit évoluerait correctement. 3 ans après toujours pas de stateful à l'horizon mais je ne peux pas jeter la pierre à une entreprise bénévole.
C'est dans le pom, développé par un mec du projet USAGI. C'est fonctionnel
J'ai tenté de merger USAGI il y a un an à peu près : ça n'a pas compilé. J'ai farfouillé et changé 2, 3 trucs et finalement j'ai renoncé, croyant toujours que le 2.6 verrait l'apport de la table des connexions à IPv6. A 6 mois près, bah ...
mais ça ne sera pas mergé parce que la core team veut unifier le conntrack au niveau 3 (cf. pkttables). C'est peut être louable
comme but, mais on reste avec le pantalon sur les genoux. C'est amha un véritable point noir de Netfilter : le manque d'implémentations de trucs qui marchent en transition des outils finaux. Le transitionnel ne me gène pas outre mesure en soi. Ce qui me dérange c'est
transitionnel << adaptatif >> où les règles changent en permanence ou, pire, ne sont pas conformes avec l'éthique générale (j'ai horreur de revenir sur un truc qui fonctionne parce qu'il se trouve qu'il ne suit pas la règle générale ce qui entraînera forcément des dificultés de maintenance à l'avenir). J'ai ce problème (métaphysique ?) actuellement avec l'ipsec natif dans le 2.6 (voir mon post dans fr.comp.reseaux.ip)
L'outil de test de syntaxe iptables ne peut pas être considéré comme disponible : il affichait sans cesse << bientôt >>. Du reste il a été retiré.
Je parlais de l'environnement de test Netfilter :
http://ozlabs.org/~jk/projects/nfsim/ Difficile de déployer un environnement de test sur une machine en prod.
Ça permet de faire tourner le code Netfilter en espace utilisateur et donc de tester les règles. Voir le HOWTO, section 4. db
-- email : usenet blas net
Cedric Blancher wrote:
Le Wed, 09 Jun 2004 00:07:15 +0000, db a écrit :
Netfilter failover me semble bien malade (5 posts en mai). VRPP
semble plus sage et plus fonctionnel également.
VRRP ne fait que le failover. Netfilter+VRRP marche _très_ bien, mais
c'est le failover du pauvre. Le problème, c'est la synchronisation des
tables d'état du master et du slave. VRRP ne permet pas de faire ça et
ne résout qu'une partie du problème.
Certes mais c'est toujours mieux que de perdre le fw.
Maintenant c'est insuffisant dans les grosses config c'est vrai d'autant que
les fw commerciaux savent faire.
Concernant Netfilter Failover, ça ne pourra partir que lorsque Harald
Welte aura fini de coder l'interface ctnetlink qui permet à un utilitaire
userspace de monitorer/modifier la table d'état de Netfilter via une
socket netlink (de la même manière que les démons de routage accèdent
à la table de routage sous Linux) qui est pré-requis incontournable de
ce genre d'outil. De même, l'interface nfnetlink (monitoring/modification
du ruleset via socket netlink) ne sera pas de trop.
Eh ben, mazette, pourvu qu'il ne se perde pas en route le pauve Harald :-)
On n'est pas rendu sinon. Le projet Nf-failover a démarré il y a 3 ans je
crois.
Ce serait même une hérésie : traiter du contenu au niveau du noyau. Mais
gageons que nous en arriverons toute de même là, dans un souci de faire
tout et officiellement pour des << petits >> besoins.
C'est même pas le problème. Si on fragmente assez, on va très vite
bypasser le filtre, qui ne peut pas se permettre de garder trop de
données en mémoire avant de les scanner sous peine de :
1. pénaliser ses perfs
2. introduire de la latence dans le réseau
Oui mais c'est un choix consenti (s'il est compris) : où on possède un
véritable fw qui fait son boulot ou, pour le pauvre, son fw fait tout
(couteau suisse) au prix à payer (baisse des performances voir émergences
de bugs).
Y'a plein de cas identiques (cf. d'autres plates-formes) où les puristes et
les << mondialistes >> s'affrontent.
Est-ce bien, est-ce mal ? Cf le cas du firewall VRPP ci-dessus.
Eh oui, j'ai pris un accès (puis 2) IPv6 afin de faire des tests avec
ip6tables il y a ... presque 3 ans convaincu que ce produit évoluerait
correctement. 3 ans après toujours pas de stateful à l'horizon mais je ne
peux pas jeter la pierre à une entreprise bénévole.
C'est dans le pom, développé par un mec du projet USAGI. C'est
fonctionnel
J'ai tenté de merger USAGI il y a un an à peu près : ça n'a pas compilé.
J'ai farfouillé et changé 2, 3 trucs et finalement j'ai renoncé, croyant
toujours que le 2.6 verrait l'apport de la table des connexions à IPv6.
A 6 mois près, bah ...
mais ça ne sera pas mergé parce que la core team veut
unifier le conntrack au niveau 3 (cf. pkttables). C'est peut être louable
comme but, mais on reste avec le pantalon sur les genoux. C'est amha un
véritable point noir de Netfilter : le manque d'implémentations de trucs
qui marchent en transition des outils finaux.
Le transitionnel ne me gène pas outre mesure en soi. Ce qui me dérange c'est
transitionnel << adaptatif >> où les règles changent en permanence ou,
pire, ne sont pas conformes avec l'éthique générale (j'ai horreur de
revenir sur un truc qui fonctionne parce qu'il se trouve qu'il ne suit pas
la règle générale ce qui entraînera forcément des dificultés de maintenance
à l'avenir).
J'ai ce problème (métaphysique ?) actuellement avec l'ipsec natif dans le
2.6 (voir mon post dans fr.comp.reseaux.ip)
L'outil de test de syntaxe iptables ne peut pas être considéré comme
disponible : il affichait sans cesse << bientôt >>. Du reste il a été
retiré.
Je parlais de l'environnement de test Netfilter :
http://ozlabs.org/~jk/projects/nfsim/
Difficile de déployer un environnement de test sur une machine en prod.
Ça permet de faire tourner le code Netfilter en espace utilisateur et
donc de tester les règles. Voir le HOWTO, section 4.
db
Netfilter failover me semble bien malade (5 posts en mai). VRPP semble plus sage et plus fonctionnel également.
VRRP ne fait que le failover. Netfilter+VRRP marche _très_ bien, mais c'est le failover du pauvre. Le problème, c'est la synchronisation des tables d'état du master et du slave. VRRP ne permet pas de faire ça et ne résout qu'une partie du problème. Certes mais c'est toujours mieux que de perdre le fw.
Maintenant c'est insuffisant dans les grosses config c'est vrai d'autant que les fw commerciaux savent faire.
Concernant Netfilter Failover, ça ne pourra partir que lorsque Harald Welte aura fini de coder l'interface ctnetlink qui permet à un utilitaire userspace de monitorer/modifier la table d'état de Netfilter via une socket netlink (de la même manière que les démons de routage accèdent à la table de routage sous Linux) qui est pré-requis incontournable de ce genre d'outil. De même, l'interface nfnetlink (monitoring/modification du ruleset via socket netlink) ne sera pas de trop. Eh ben, mazette, pourvu qu'il ne se perde pas en route le pauve Harald :-)
On n'est pas rendu sinon. Le projet Nf-failover a démarré il y a 3 ans je crois.
Ce serait même une hérésie : traiter du contenu au niveau du noyau. Mais gageons que nous en arriverons toute de même là, dans un souci de faire tout et officiellement pour des << petits >> besoins.
C'est même pas le problème. Si on fragmente assez, on va très vite bypasser le filtre, qui ne peut pas se permettre de garder trop de données en mémoire avant de les scanner sous peine de :
1. pénaliser ses perfs 2. introduire de la latence dans le réseau Oui mais c'est un choix consenti (s'il est compris) : où on possède un
véritable fw qui fait son boulot ou, pour le pauvre, son fw fait tout (couteau suisse) au prix à payer (baisse des performances voir émergences de bugs). Y'a plein de cas identiques (cf. d'autres plates-formes) où les puristes et les << mondialistes >> s'affrontent. Est-ce bien, est-ce mal ? Cf le cas du firewall VRPP ci-dessus.
Eh oui, j'ai pris un accès (puis 2) IPv6 afin de faire des tests avec ip6tables il y a ... presque 3 ans convaincu que ce produit évoluerait correctement. 3 ans après toujours pas de stateful à l'horizon mais je ne peux pas jeter la pierre à une entreprise bénévole.
C'est dans le pom, développé par un mec du projet USAGI. C'est fonctionnel
J'ai tenté de merger USAGI il y a un an à peu près : ça n'a pas compilé. J'ai farfouillé et changé 2, 3 trucs et finalement j'ai renoncé, croyant toujours que le 2.6 verrait l'apport de la table des connexions à IPv6. A 6 mois près, bah ...
mais ça ne sera pas mergé parce que la core team veut unifier le conntrack au niveau 3 (cf. pkttables). C'est peut être louable
comme but, mais on reste avec le pantalon sur les genoux. C'est amha un véritable point noir de Netfilter : le manque d'implémentations de trucs qui marchent en transition des outils finaux. Le transitionnel ne me gène pas outre mesure en soi. Ce qui me dérange c'est
transitionnel << adaptatif >> où les règles changent en permanence ou, pire, ne sont pas conformes avec l'éthique générale (j'ai horreur de revenir sur un truc qui fonctionne parce qu'il se trouve qu'il ne suit pas la règle générale ce qui entraînera forcément des dificultés de maintenance à l'avenir). J'ai ce problème (métaphysique ?) actuellement avec l'ipsec natif dans le 2.6 (voir mon post dans fr.comp.reseaux.ip)
L'outil de test de syntaxe iptables ne peut pas être considéré comme disponible : il affichait sans cesse << bientôt >>. Du reste il a été retiré.
Je parlais de l'environnement de test Netfilter :
http://ozlabs.org/~jk/projects/nfsim/ Difficile de déployer un environnement de test sur une machine en prod.
Ça permet de faire tourner le code Netfilter en espace utilisateur et donc de tester les règles. Voir le HOWTO, section 4. db
-- email : usenet blas net
manu
Miod Vallat wrote:
Il était question de la branche 1.6 stable, dans laquelle le port sparc n'a aucun support multiprocesseur.
Par contre la 2.0 qui est en train de refroidir sur bord de la fenêtre le fait. C'est pas encore une release, mais c'est déjà plus -current. Oui mais 2.0 est nettement moins -stable pour le moment.
Ben oui, sinon ca serait une release.
-- Emmanuel Dreyfus A lire: 240 pages en français sur l'administration UNIX avec BSD http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
Miod Vallat <miod@online.fr> wrote:
Il était question de la branche 1.6 stable, dans laquelle le port sparc
n'a aucun support multiprocesseur.
Par contre la 2.0 qui est en train de refroidir sur bord de la fenêtre
le fait. C'est pas encore une release, mais c'est déjà plus -current.
Oui mais 2.0 est nettement moins -stable pour le moment.
Ben oui, sinon ca serait une release.
--
Emmanuel Dreyfus
A lire: 240 pages en français sur l'administration UNIX avec BSD
http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu@netbsd.org
Il était question de la branche 1.6 stable, dans laquelle le port sparc n'a aucun support multiprocesseur.
Par contre la 2.0 qui est en train de refroidir sur bord de la fenêtre le fait. C'est pas encore une release, mais c'est déjà plus -current. Oui mais 2.0 est nettement moins -stable pour le moment.
Ben oui, sinon ca serait une release.
-- Emmanuel Dreyfus A lire: 240 pages en français sur l'administration UNIX avec BSD http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
Cedric Blancher
Le Wed, 09 Jun 2004 22:47:41 +0000, db a écrit pleins de choses censées, et puis il a ripé :
http://ozlabs.org/~jk/projects/nfsim/ Difficile de déployer un environnement de test sur une machine en prod.
Parce que tu testerais tes rulesets sur tes machines de production ? Moi, perso, je l'installerai sur une machine dédiée (genre ma workstation) et je testerais mes ruleset là, dans la mesure où cet environnement complet me permet de tester toutes les configurations que j'ai déployées...
-- panic("floppy: Port bolixed."); 2.2.16 /usr/src/linux/include/asm-sparc/floppy.h
Le Wed, 09 Jun 2004 22:47:41 +0000, db a écrit pleins de choses
censées, et puis il a ripé :
http://ozlabs.org/~jk/projects/nfsim/
Difficile de déployer un environnement de test sur une machine en prod.
Parce que tu testerais tes rulesets sur tes machines de production ?
Moi, perso, je l'installerai sur une machine dédiée (genre ma
workstation) et je testerais mes ruleset là, dans la mesure où cet
environnement complet me permet de tester toutes les configurations que
j'ai déployées...
--
panic("floppy: Port bolixed.");
2.2.16 /usr/src/linux/include/asm-sparc/floppy.h
Le Wed, 09 Jun 2004 22:47:41 +0000, db a écrit pleins de choses censées, et puis il a ripé :
http://ozlabs.org/~jk/projects/nfsim/ Difficile de déployer un environnement de test sur une machine en prod.
Parce que tu testerais tes rulesets sur tes machines de production ? Moi, perso, je l'installerai sur une machine dédiée (genre ma workstation) et je testerais mes ruleset là, dans la mesure où cet environnement complet me permet de tester toutes les configurations que j'ai déployées...
-- panic("floppy: Port bolixed."); 2.2.16 /usr/src/linux/include/asm-sparc/floppy.h
Marwan Burelle
On 09 Jun 2004 22:46:39 GMT Miod Vallat wrote:
Non, nous nous contenterons de le supplicier en le forçant à coder le support COMPAT_MIOD dans NetBSD/brain.
Vous avez trouvé des fromages numériques ?
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
On 09 Jun 2004 22:46:39 GMT
Miod Vallat <miod@online.fr> wrote:
Non, nous nous contenterons de le supplicier en le forçant à coder le
support COMPAT_MIOD dans NetBSD/brain.
Vous avez trouvé des fromages numériques ?
--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
(burelle@lri.fr | Marwan.Burelle@ens.fr)
Seulement des oranges mécaniques, pour le moment, mais nous ne
désespérons pas.
Marwan Burelle
On 10 Jun 2004 08:15:12 GMT Miod Vallat wrote:
Seulement des oranges mécaniques, pour le moment, mais nous ne désespérons pas.
Encore faut-il que ce soit de vrais fromages, d'ici à ce que quelqu'un essaie de te refiler un sheddard numérique, un binaire fermé de Wensleydale ou quelque chose d'approchant ...
Bon, je penses que le fu2 sur la buvette s'impose ...
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
On 10 Jun 2004 08:15:12 GMT
Miod Vallat <miod@online.fr> wrote:
Seulement des oranges mécaniques, pour le moment, mais nous ne
désespérons pas.
Encore faut-il que ce soit de vrais fromages, d'ici à ce que quelqu'un
essaie de te refiler un sheddard numérique, un binaire fermé de
Wensleydale ou quelque chose d'approchant ...
Bon, je penses que le fu2 sur la buvette s'impose ...
--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
(burelle@lri.fr | Marwan.Burelle@ens.fr)
Seulement des oranges mécaniques, pour le moment, mais nous ne désespérons pas.
Encore faut-il que ce soit de vrais fromages, d'ici à ce que quelqu'un essaie de te refiler un sheddard numérique, un binaire fermé de Wensleydale ou quelque chose d'approchant ...
Bon, je penses que le fu2 sur la buvette s'impose ...
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
Olivier Cherrier
In article <40c6eb54$0$13926$, Miod Vallat wrote:
Il était question de la branche 1.6 stable, dans laquelle le port sparc n'a aucun support multiprocesseur.
Oups, désolé. Mais bon, quelle idée de tourner des -stables !
In article <40c6eb54$0$13926$636a15ce@news.free.fr>, Miod Vallat wrote:
Il était question de la branche 1.6 stable, dans laquelle le port sparc
n'a aucun support multiprocesseur.
Oups, désolé. Mais bon, quelle idée de tourner des -stables !
Il était question de la branche 1.6 stable, dans laquelle le port sparc n'a aucun support multiprocesseur.
Oups, désolé. Mais bon, quelle idée de tourner des -stables !
Thierry Boudet
On 2004-06-09, Miod Vallat wrote:
Rhooo, Miod! Tu fais du vaproware, maintenant?
Loin de moi cette idée. Je me borne à constater des faits.
Ton objectivité sur l'inclinaison me force à constater que ton "constateur (cTMr)" nécessite un upgrade, voire un remplacement par une technologie plus appropriée.
Non, nous nous contenterons de le supplicier en le forçant à coder le support COMPAT_MIOD dans NetBSD/brain.
J'ai pourtant des informations en provenance d'Allemagne, comme quoi il paraitrait que... mais je ne peux en dire plus.
-- Bien plus zen que le Contrat Social, et ouvert à tous: http://tth.vaboofer.com/Cette/cafe_social.html
On 2004-06-09, Miod Vallat <miod@online.fr> wrote:
Rhooo, Miod! Tu fais du vaproware, maintenant?
Loin de moi cette idée. Je me borne à constater des faits.
Ton objectivité sur l'inclinaison me force à constater que
ton "constateur (cTMr)" nécessite un upgrade, voire un
remplacement par une technologie plus appropriée.
Non, nous nous contenterons de le supplicier en le forçant à coder le
support COMPAT_MIOD dans NetBSD/brain.
J'ai pourtant des informations en provenance d'Allemagne,
comme quoi il paraitrait que... mais je ne peux en dire plus.
--
Bien plus zen que le Contrat Social, et ouvert à tous:
http://tth.vaboofer.com/Cette/cafe_social.html
Loin de moi cette idée. Je me borne à constater des faits.
Ton objectivité sur l'inclinaison me force à constater que ton "constateur (cTMr)" nécessite un upgrade, voire un remplacement par une technologie plus appropriée.
Non, nous nous contenterons de le supplicier en le forçant à coder le support COMPAT_MIOD dans NetBSD/brain.
J'ai pourtant des informations en provenance d'Allemagne, comme quoi il paraitrait que... mais je ne peux en dire plus.
-- Bien plus zen que le Contrat Social, et ouvert à tous: http://tth.vaboofer.com/Cette/cafe_social.html
