fin de grsecurity

Benjamin Pineau <ben@zouh.org> wrote:

je parlai d'architecture, au sens même ou NetBSD
est considéré comme plutôt portable bien que la branche stable ne soit
pas encore SMP):

NetBSD ne fait le SMP que dans -current pour i386, mais c'est en branche
stable pour vax et alpha depuis belle lurette.

--
Emmanuel Dreyfus
Publicité subliminale: achetez ce livre!
http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu@netbsd.org

NetBSD ne fait le SMP que dans -current pour i386, mais c'est en branche
stable pour vax et alpha depuis belle lurette.

Allons, allons, tu sais bien que seul compte le i386.

Et plus sérieusement, je n'ai pas vu tous les correctifs vfs et lockmgr
de pk passer en stable... pourtant, ils sont nécessaires pour que le
qualificatif de stable soit mérité.

Cedric Blancher wrote:

Le Tue, 08 Jun 2004 14:09:53 +0000, Benjamin Pineau a écrit :

A mon sens, le premier avantage est la (toute récente) possibilité de
faire des firewall redondant avec pfsync et carp (avec replication des
tables d'états etc.) pour une très haute ha des routeurs/firewall (et
sans fouler les brevets cisco sur vrrp).

Cisco n'a pas de brevet sur VRRP, qui fait l'objet d'une RFC, mais sur
HSRP.
Sinon, pfsync/carp, c'est vraiment excellent. J'espère que les gars de
Netfilter vont y jeter un coup d'oeil rapidement parce que leur projet à
eux, non content d'être compliqué, n'a pas pondu le moindre code
utilisable...
Netfilter failover me semble bien malade (5 posts en mai). VRPP semble plus

sage et plus fonctionnel également.

[...]

Je ne suis pas convaincu que le spam soit à traiter au niveau du filtre
de paquets.
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.

algos de load-balancing pour la redirection,

Idem.

filtrage vraiment statefull d'IPv6,

Gros manque de Linux, clairement un gros manque. Et puis beaucoup de
branlette intellectuelle pour mettre sur pied des usines à tout faire...
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.

blindages des stacks IPs fragiles (modulate state, random-id, syn proxy),

Existe fous Linux. Pour les IDs random, Linux utilise l'approche ID=0
systématique qui donne les mêmes résultats.

authentification,

Oui, authpf, c'est super pratique.

grammaire de mieux en mieux fichue,

Question de goût, mais bon, c'est vrai que la syntaxe iptables suxe pas
mal quand même.

outil de test de syntaxe + changements atomiques,

Dispo aussi.
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é.
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.

Oui, le besoin de SMP n'est pas une fantaisie, mais correspond vraiment à
des cas d'utilisation. Par exemple sur un firewall pur, c'est souvent
moins pertinent.

Tout à fait.
À part faire tourner l'usine à gaz et la GUI qui va avec pour certains
trucs commerciaux, aucun intérêt, tout le monde est d'accord je pense.


db

--
email : usenet blas net

Le 08 Jun 2004 15:24:00 GMT,
Cedric Blancher <blancher@cartel-securite.fr> écrivais:

Cisco n'a pas de brevet sur VRRP, qui fait l'objet d'une RFC, mais sur
HSRP.

Les deux. Cf. www.ietf.org/ietf/IPR/VRRP-CISCO ,
http://www.ietf.org/ietf/IPR/cisco-ipr-draft-ietf-vrrp-ipv6-spec.txt
et meme IBM: www.ietf.org/ietf/IPR/NAT-VRRP-IBM

qui peuvent s'avérer utiles selon les usages: intégration avec p0f pour
gestion du traffic selon l'OS source

Done, cf. patch'o'matic.

ts ts ts, tu triche, on avait dit pas de patch-o-matic ;)

avec altq (pour le QoS),

Linux possède une gestion de la QoS très efficace.

Et même plus sophistiquée. Mais je disait que celle-ci était intégrée
au firewall (permettant entre autres de parcourir les paquets en une
seule passe. hé, c'est comme ça qu'on se passe de smp ;). En fait,
c'est bien l'_intégration_ de tout ces gadgets qui permet de faire
des choses rigolotes ... et parfois innatendues.

avec l'outil de filtrage de spam natif,

Je ne suis pas convaincu que le spam soit à traiter au niveau du filtre
de paquets.

A vrai dire moi non plus ; mais la méthode est assez astucieuse ...
et a sa décharge, il ne s'agit pas vraiment du traitement du spam (en
l'occurence, seulement de la gestion de tables pour la redirections de
traffic).

algos de load-balancing pour la redirection,

Idem.

Le resultat n'est pas le même que, par exemple, un bête round robin dns.

blindages des stacks IPs fragiles (modulate state, random-id, syn proxy),

Existe fous Linux. Pour les IDs random, Linux utilise l'approche ID=0
systématique qui donne les mêmes résultats.

Cool, s'il existe aussi un astuce pour obtenir un résultat similaire au
"synproxy state" avec iptables, je suis preneur (bin oui, j'ai aussi
des firewalls sous linux a entretenir ;).

grammaire de mieux en mieux fichue,

Question de goût, mais bon, c'est vrai que la syntaxe iptables suxe pas
mal quand même.

Je ne comparais que pf avec lui même hein (pas dit: mieux qu'iptables).
Evidement, affaire de goûts...

outil de test de syntaxe + changements atomiques,

Dispo aussi.

Et là je suis encore plus preneur. Marre de serrer les dents à chaque
reload d'un ruleset iptables. Bref, comment s'y prend-t-on pour valider
un ruleset iptables sans le charger ?

Le Wed, 09 Jun 2004 01:36:25 +0000, Benjamin Pineau a écrit :

ts ts ts, tu triche, on avait dit pas de patch-o-matic ;)

L'habitude.
Mais l'OSFP marche vachement bien.

Et même plus sophistiquée. Mais je disait que celle-ci était intégrée
au firewall (permettant entre autres de parcourir les paquets en une
seule passe. hé, c'est comme ça qu'on se passe de smp ;). En fait,
c'est bien l'_intégration_ de tout ces gadgets qui permet de faire
des choses rigolotes ... et parfois innatendues.

Sous Linux, le routage et la gestion de la QoS supportent l'examen de la
nfmark qui est affectée par le firewall. D'où la relation directe FW <->
QoS et FW <-> routage. Je l'utilise surtout pour le routage, mais ça
marche très bien.
Tu as un bon document sur la gestion de la QoS via les marques dans le
LARTC et sur le site L7filter (c'est pas du pom ;))).

A vrai dire moi non plus ; mais la méthode est assez astucieuse ...
et a sa décharge, il ne s'agit pas vraiment du traitement du spam (en
l'occurence, seulement de la gestion de tables pour la redirections de
traffic).

Avec la cible QUEUE, on doit pouvoir faire pas mal de trucs dans ce genre.

Le resultat n'est pas le même que, par exemple, un bête round robin
dns.

Non.
En matière de round robbin, voir la cible NTH.

Cool, s'il existe aussi un astuce pour obtenir un résultat similaire au
"synproxy state" avec iptables, je suis preneur

Là, par contre, pour les SYN proxy.

outil de test de syntaxe + changements atomiques,
Dispo aussi.

Et là je suis encore plus preneur. Marre de serrer les dents à chaque

reload d'un ruleset iptables. Bref, comment s'y prend-t-on pour valider
un ruleset iptables sans le charger ?

Pour les changements atomiques : iptables-restore.
Pour les tests de ruleset, l'équipe de développement de Netfilter a
produit un outil de test userspace d'un fremawork Netfilter. Ça permet
non seulement de tester des rulesets, mais ça permet aussi de tester
l'intégration de nouvelles extensions (en fait, c'est surtout fait pour
ça). Cf. les archives de la ML de dev, j'ai la flemme de chercher ;)


--
Le dino, c'est celui qui comprend un message qu'il ne lit pas.
Le neuneu, c'est celui qui ne comprend pas un message qu'il lit.
-+-GF in Guide du Neuneu Usenet - Et c'est ainsi qu'Allah est grand-+-

Miod Vallat <miod@online.fr> wrote:

NetBSD ne fait le SMP que dans -current pour i386, mais c'est en branche
stable pour vax et alpha depuis belle lurette.
Allons, allons, tu sais bien que seul compte le i386.

Ah, j'ai toujours eu un faible pour le matos un peu original. En ce
moment on fait de beaux serveurs en PowerPC ou en AMD64. Avantage: les
exploits sont d'abord ecrit pour Linux/i386, donc on a quelques jours de
répit de plus quand un exploit est publié avant un correctif.

Et puis coté PDA, le i386 c'est pas trop ça (quoi que le SMP sur PDA
c'est pas très interessant). Pour les portables, y'a aussi un vrai
interet à prendre du PowerPC plutot que du i386, pour la consommation
moindre. J'aimerai bien voir un portable à base d'ARM, tiens.

Mais ca n'est pas toi que je vais convaincre de tout ca: tu sais tout ca
mieux que moi.

Et plus sérieusement, je n'ai pas vu tous les correctifs vfs et lockmgr
de pk passer en stable... pourtant, ils sont nécessaires pour que le
qualificatif de stable soit mérité.

Question de point de vue. Pour moi c'est stable quand ca ne plante pas
:)

--
Emmanuel Dreyfus
Un bouquin en français sur BSD:
http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu@netbsd.org

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.

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.

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

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 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.

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/

Ça permet de faire tourner le code Netfilter en espace utilisateur et
donc de tester les règles. Voir le HOWTO, section 4.


--

Et le port ISA avec des port serie ? ;-)
Le bus ISA est géré par un pont avec le bus PCI et part donc lui aussi

dans la stratosphère.
-+- TP in GFA : "Comment envoyer Linux sur orbite" -+-

In article <1gf37wk.sl7ax2k4hjhzN%manu@netbsd.org>, Emmanuel Dreyfus wrote:

Benjamin Pineau <ben@zouh.org> wrote:

je parlai d'architecture, au sens même ou NetBSD
est considéré comme plutôt portable bien que la branche stable ne soit
pas encore SMP):

NetBSD ne fait le SMP que dans -current pour i386, mais c'est en branche
stable pour vax et alpha depuis belle lurette.

Ca marche bien aussi sous sparc ! Sparc étant l'architecture qui va détrôner le
PC dans les années à venir, il ne faut pas l'oublier ;-)

oc

NetBSD ne fait le SMP que dans -current pour i386, mais c'est en branche
stable pour vax et alpha depuis belle lurette.

Ca marche bien aussi sous sparc ! Sparc étant l'architecture qui va détrôner le
PC dans les années à venir, il ne faut pas l'oublier ;-)

Il était question de la branche 1.6 stable, dans laquelle le port sparc
n'a aucun support multiprocesseur.

"Emmanuel" == Emmanuel Dreyfus <manu@netbsd.org> writes:

'Lut,

Emmanuel> NetBSD ne fait le SMP que dans -current pour i386, mais c'est
Emmanuel> en branche stable pour vax et alpha depuis belle lurette.

Euh, le smp n'est pas implémenté de la même manière sur toutes les
archis, genre services md spécifiques à chaque archi et support mi pour
les fonctionnalités générales ?

Eric Masson

--
Je cherche un organisme fournisseur d'oeufs embryonnés autre que le
centre d'élevage d'Artenay qui vient de fermer, pour la réalisation de
TP de culture de cardiomyocytes
-+- DZ in : Guide du Neuneu Usenet - Pas de neuneux félés chez fbci -+-