fin de grsecurity

3 vues
Accéder directement au premier message non lu

Eric Razny

non lue,
5 juin 2004, 10:51:1805/06/2004
à
Comme il semble que ce soit la fin :
http://www.grsecurity.org/
(à moins d'un effet d'annonce)

pour ceux qui l'utilisent, à moins qu'ils aient le temps de le maintenir, il
est peut être temps de se former à LIDS ou autre... :-/

Eric

--
L'invulnérable :
Je ne pense pas etre piratable, infectable par un trojen oui!
Vu sur fcs un jour de mars 2004.

Xavier Roche

non lue,
5 juin 2004, 19:27:3305/06/2004
à
Eric Razny wrote:
> Comme il semble que ce soit la fin :
> http://www.grsecurity.org/

http://www.openwall.com/linux/ ?

Emmanuel Florac

non lue,
6 juin 2004, 10:31:0706/06/2004
à
Le Sat, 05 Jun 2004 23:27:33 +0000, Xavier Roche a écrit :

Ce qui serait bien ça serait d'expliquer rapidement les différences
entre les deux, pour ceux que ça intéresse. S'il vous plait :)

--
entia non sont multiplicanda praeter necessitatem.
Guillaume d'Ockham.

Djoume SALVETTI

non lue,
6 juin 2004, 11:28:5106/06/2004
à
Le dimanche 06/06/04 Emmanuel Florac <efl...@imaginet.fr> a écrit :

> Le Sat, 05 Jun 2004 23:27:33 +0000, Xavier Roche a écrit :
>
> >> http://www.grsecurity.org/
> >
> > http://www.openwall.com/linux/ ?
>
> Ce qui serait bien ça serait d'expliquer rapidement les différences
> entre les deux, pour ceux que ça intéresse. S'il vous plait :)

Rapidement je dirais que les deux sont des patchs qui améliorent la
sécurité du noyau Linux, GrSecurity étant a priori plus complet
(par exemple openwall ne permet pas d'attribuer de façon aléatoire les
numéros de processus) et plus simple à utiliser (utilisation des modes
préconfigurés).

--
Djoumé SALVETTI

Eric Masson

non lue,
6 juin 2004, 11:46:3606/06/2004
à
>>>>> "Djoume" == Djoume SALVETTI <salv...@crans.org> writes:

'Lut,

Djoume> Rapidement je dirais que les deux sont des patchs qui
Djoume> améliorent la sécurité du noyau Linux,

Sans troller exagérément, ces patchs ne doivent pas plaire des masses au
sieur Torvalds, sinon ils seraient intégrés dans les sources officiels,
non ?

Dans le cas présent, la maintenance d'un patchset non officiel doit être
un joyeux merdier avec les risques de bugs que cela implique, pourquoi
ne pas choisir un os ou ces principes sont intégrés de base (au hasard,
OpenBSD) ?

Eric Masson

--
Ol: Vivement la WWDC qu'on en apprenne plus, quand même...
EL: C'est sûr, on est au fond de la mine, on voit rien, juste du
charbon partout. Beurk. ;-)
-+ EL in Guide du Macounet Pervers : Les Nextiens préfèrent le jaune +-

Francois Cartegnie

non lue,
6 juin 2004, 15:51:1706/06/2004
à
Eric Razny wrote:
> Comme il semble que ce soit la fin :
> http://www.grsecurity.org/
> (à moins d'un effet d'annonce)
>
> pour ceux qui l'utilisent, à moins qu'ils aient le temps de le maintenir, il
> est peut être temps de se former à LIDS ou autre... :-/

Ou il serait peut être temps que certains gros hébergeurs (suivez mon
regard) financent les projets qu'ils utilisent pour faire leur beurre...

Xavier Roche

non lue,
6 juin 2004, 15:51:1706/06/2004
à
Eric Masson wrote:
> Sans troller exagérément, ces patchs ne doivent pas plaire des masses au
> sieur Torvalds, sinon ils seraient intégrés dans les sources officiels,
> non ?

Oui et non. Il y a pas mal de problèmes d'incompatibilité avec les patchs
sécurité et certaines applis. Par exemple serveur X et protection contre
la pile executable de mémoire, ou encore la protection sur la mémoire partagée
qui pose problème à d'autres (genre les problèmes de crash avec samba il y
a de ça quelques temps).

Bref activer ces fonctionnalités "casse" certaines choses, et donc leur
utilisation n'est pas totalement acceptée par tous.

> Dans le cas présent, la maintenance d'un patchset non officiel doit être
> un joyeux merdier avec les risques de bugs que cela implique

Oui et non - grsecurity reprend pas mal de choses venant de openwall,
et certaines parties du noyau ne bougent pas sans arrêt.

De plus openwall teste sérieusement ses patchs avant de les sortir -
pour mémoire le patch 2.6 n'est toujours pas validé pour cette raison.

> pourquoi ne pas choisir un os ou ces principes sont intégrés de base
> (au hasard, OpenBSD) ?

Moins "mainstream" ? Càd plus de problèmes avec les modules/drivers,
compatibilité parfois plus difficile etc.

Emmanuel Florac

non lue,
6 juin 2004, 15:51:1706/06/2004
à
Le Sun, 06 Jun 2004 15:46:36 +0000, Eric Masson a écrit :

>
> Sans troller exagérément, ces patchs ne doivent pas plaire des masses au
> sieur Torvalds, sinon ils seraient intégrés dans les sources officiels,
> non ?

Ça paraît évident. Sans compter que le type de grsecurity a annoncé
que bien que ses développements soient GPL, il refuse que quelqu'un
d'autre s'en charge, bref ça ne fait pas très sérieux de planter tout
le monde plutôt que de repasser le bébé...

> Dans le cas présent, la maintenance d'un patchset non officiel doit être
> un joyeux merdier avec les risques de bugs que cela implique, pourquoi
> ne pas choisir un os ou ces principes sont intégrés de base (au hasard,
> OpenBSD) ?

OpenBSD a ses propres inconvénients. En particulier et de manière non
exhaustive, il ne tourne pas sur les mêmes architectures, il ne gère pas
le SMP, et il a des performances très mauvaises.

--
L'Algérie était au bord du gouffre, aujourd'hui elle a fait un grand pas
en avant.
Kaid Ahmed.

db

non lue,
6 juin 2004, 18:51:1206/06/2004
à
Eric Masson wrote:

>>>>>> "Djoume" == Djoume SALVETTI <salv...@crans.org> writes:
>
> 'Lut,
>
> Djoume> Rapidement je dirais que les deux sont des patchs qui
> Djoume> améliorent la sécurité du noyau Linux,
>
> Sans troller exagérément, ces patchs ne doivent pas plaire des masses au
> sieur Torvalds, sinon ils seraient intégrés dans les sources officiels,
> non ?

Et non. La stratégie de Linux est d'offrir l'architecture de base permettant
d'implanter telle ou telle politique de sécurité au niveau du noyau et non
de fournir la politique elle-même. C'est la voie Torwaldienne et c'est bien
ainsi. Il y a trop d'axes possibles pour tenter d'en inclure un dans le
noyau.
Ainsi snare, le patch NSA, j'ne passe et des meilleurs resteront des
patches.

db


>
> Dans le cas présent, la maintenance d'un patchset non officiel doit être
> un joyeux merdier avec les risques de bugs que cela implique, pourquoi
> ne pas choisir un os ou ces principes sont intégrés de base (au hasard,
> OpenBSD) ?
>
> Eric Masson
>

--
email : usenet blas net

Xavier Roche

non lue,
6 juin 2004, 18:59:2206/06/2004
à
Emmanuel Florac wrote:
> que bien que ses développements soient GPL, il refuse que quelqu'un
> d'autre s'en charge

Son refus n'a aucune valeur, au passage, étant donné la license.

Djoume SALVETTI

non lue,
6 juin 2004, 18:59:4806/06/2004
à
Le dimanche 06/06/04 Eric Masson <em...@free.fr> a écrit :

> Djoume> Rapidement je dirais que les deux sont des patchs qui
> Djoume> améliorent la sécurité du noyau Linux,
>
> Sans troller exagérément, ces patchs ne doivent pas plaire des masses au
> sieur Torvalds, sinon ils seraient intégrés dans les sources officiels,
> non ?

Ouaip, Linus a préfèré les LSM (Linux Security Modules) pour sécuriser
le noyau (cf selinux).

> Dans le cas présent, la maintenance d'un patchset non officiel doit être
> un joyeux merdier avec les risques de bugs que cela implique, pourquoi
> ne pas choisir un os ou ces principes sont intégrés de base (au hasard,
> OpenBSD) ?

Jusque la les développeurs de GrSecurity s'en sont plutôt bien sorti
pour maintenir leur patchs.

Quand au choix d'OpenBSD, les problèmes sont alors la lenteur [1], la
portabilité et surtout le manque de ports.

Mais bon, comme d'hab, OpenBSD, GrSecurity, selinux, Windows, peu
importe, l'important c'est de bien connaitre son système et de connaitre
ses points faibles en termes de sécurité.


[1] Bon d'accord c'était juste pour troller celui la ;-)
--
Djoumé SALVETTI

Cedric Blancher

non lue,
6 juin 2004, 19:02:2806/06/2004
à
Le Sun, 06 Jun 2004 22:59:48 +0000, Djoume SALVETTI a écrit :
> Ouaip, Linus a préfèré les LSM (Linux Security Modules) pour sécuriser
> le noyau (cf selinux).

Le choix des LSM n'a rien à voir avec le fait que Linus aime ou n'aime
pas les patches de sécurité. Il repose sur le fait que les mainteneurs
du noyau ont préféré offrir une interface spécialisée pour ce type de
fonctionnalités et ne pas avoir à gérer 15 produits différents inclus
dans le noyau. D'où les LSM.

--
BOFH excuse #249:

Unfortunately we have run out of bits/bytes/whatever. Don't worry, the
next supply will be coming next week.

Benjamin Pineau

non lue,
6 juin 2004, 23:07:3806/06/2004
à
Le 06 Jun 2004 19:51:17 GMT,
Xavier Roche <xro...@free.fr.NOSPAM.invalid> écrivais:

>
> Oui et non. Il y a pas mal de problèmes d'incompatibilité avec les patchs
> sécurité et certaines applis. Par exemple serveur X et protection contre
> la pile executable de mémoire, ou encore la protection sur la mémoire partagée
> qui pose problème à d'autres (genre les problèmes de crash avec samba il y
> a de ça quelques temps).
>
> Bref activer ces fonctionnalités "casse" certaines choses, et donc leur
> utilisation n'est pas totalement acceptée par tous.

D'où la pertinence de sa question: pourquoi préferer les patches (voir
les entassements de patches), au résultat incertain, à un OS dont l'userland
est maintenu par les developpeurs du noyau (et dont le noyau intègre
d'emblée les fonctionalités sécu les plus pertinentes) avec donc un
résultat stable garanti ?
Le plaisir des architectures baroques ?

> > pourquoi ne pas choisir un os ou ces principes sont intégrés de base
> > (au hasard, OpenBSD) ?
>
> Moins "mainstream" ? Càd plus de problèmes avec les modules/drivers,
> compatibilité parfois plus difficile etc.

Il est plutôt rare de tomber sur du matériel serveur (cartes raid, scsi,
réseau, crypto) non supporté. Et aucun driver n'est distribué sous forme
de module (alors les problèmes de modules ....). Ah, il y a le jdk ...

Emmanuel Florac

non lue,
7 juin 2004, 03:40:1507/06/2004
à
Le Sun, 06 Jun 2004 22:59:22 +0000, Xavier Roche a écrit :

>
> Son refus n'a aucune valeur, au passage, étant donné la license.

Certes mais comme en pratique le site n'est plus en ligne, qui a conservé
toutes les sources, la doc, etc?

--
Ne pas savoir de quoi on parle est un avantage dont il ne faut pas
abuser.
R.Debray

Patrice Auffret

non lue,
7 juin 2004, 03:40:1507/06/2004
à
On 06 Jun 2004 19:51:17 GMT
Emmanuel Florac <efl...@imaginet.fr> wrote:
[..]

> Ça paraît évident. Sans compter que le type de grsecurity a annoncé
> que bien que ses développements soient GPL, il refuse que quelqu'un
> d'autre s'en charge, bref ça ne fait pas très sérieux de planter tout
> le monde plutôt que de repasser le bébé...
[..]


Ca, ca ne m'étonne pas du tout. J'avais échangé quelques mails au
sujet d'un comportement intéressant que je considérais comme un
bug, et bonjour les réponses que j'ai eu: dignes d'un enfant.

Djoume SALVETTI

non lue,
7 juin 2004, 04:24:0407/06/2004
à
Le lundi 06/07/04 Cedric Blancher <blan...@cartel-securite.fr> a écrit :

> Le choix des LSM n'a rien à voir avec le fait que Linus aime ou n'aime
> pas les patches de sécurité. Il repose sur le fait que les mainteneurs
> du noyau ont préféré offrir une interface spécialisée pour ce type de
> fonctionnalités et ne pas avoir à gérer 15 produits différents inclus
> dans le noyau. D'où les LSM.

Oui mais Grsecurity n'utilise pas cette interface et n'a donc aucune
chance de se voir intégré officiellement au noyau.

--
Djoumé SALVETTI

Benjamin Pineau

non lue,
7 juin 2004, 08:24:1807/06/2004
à
Le 06 Jun 2004 22:59:48 GMT,
Djoume SALVETTI <salv...@crans.org> écrivais:

>
> Quand au choix d'OpenBSD, les problèmes sont alors la lenteur [1], la
> portabilité et surtout le manque de ports.

La portabilité ? j'ai l'impression que la désinformation a vite gagnée
ce thread. Dites moi quelle architecture manque qui fasse objection au
déploiment de cet OS sur de serveurs modernes.

Si vous manquez de ports, vous pouvez toujours utiliser les pkgsrc de NetBSD
(ok ils ne compilent pas tjrs parfaitement sous Open ; il faudrai faire des
pr parraît-il).

> Mais bon, comme d'hab, OpenBSD, GrSecurity, selinux, Windows, peu
> importe, l'important c'est de bien connaitre son système et de connaitre
> ses points faibles en termes de sécurité.

Ce n'est pas faux. Mais inssufisant. Le "bien connaitre" a ses limites:
qui peut encore s'offrir le luxe d'auditer complétement le code de son
OS et de ses services ? Et cet audit sera-t-il suffisant ? sans parler
des OS où l'audit est impossible. Bref, on ne peut pas dire qu'être en
mesure d'éviter les erreurs d'administration de débutant soit suffisant
pour tout les besoins en termes de sécurité.

C'est où les mécanismes de sécurités étendus, objet de ce thread,
trouvent leur raison d'être (de même que le rôle d'un firewall ne se
limite pas à protéger contre les erreurs de débutants, services
"oubliés" etc.).

Et c'est à ce titre que des questions de politique d'administration peuvent
entrer en jeu dans le choix : qualité de l'integration avec l'OS, du
support (tel patch/os, affaire d'un seul developpeur, sera-t-il abandoné ?
est-il suffisament testé ? mon userland est-il bien compatible ? ),
contraintes (casse-t-il le fonctionnement de tel logiciel ? de telle
standard ou appel système normalisé ? etc.), de fonctionalités (si j'ai
besoin d'IPsec, je n'ai que faire de Grsecurity ...). Et encore, de
qualité de l'ensemble de l'architecture cible en fonction des solutions
(e.g. je veut une protection par filtrage des appels systèmes, un stack
IPsec de qualité, des MACs, quel est le choix le plus cohérent ?).

Pour répondre à d'autres posts encore: non, lids, les nsa/selinux, grsecurity,
openbsd ou openwall ne sont en rien équivalents, ne sont pas substituables
et n'offrent pas les mêmes fonctionalités de renforcement de la sécurité.

Djoume SALVETTI

non lue,
7 juin 2004, 09:38:5007/06/2004
à
Le lundi 06/07/04 Benjamin Pineau <b...@zouh.org> a écrit :

> > Quand au choix d'OpenBSD, les problèmes sont alors la lenteur [1], la
> > portabilité et surtout le manque de ports.
>
> La portabilité ? j'ai l'impression que la désinformation a vite gagnée
> ce thread. Dites moi quelle architecture manque qui fasse objection au
> déploiment de cet OS sur de serveurs modernes.

N'importe laquelle qui ai plusieurs processeurs, et je doute que
l'hyperthreading soit supporté.



> Si vous manquez de ports, vous pouvez toujours utiliser les pkgsrc de NetBSD
> (ok ils ne compilent pas tjrs parfaitement sous Open ; il faudrai faire des
> pr parraît-il).

Ceux de NetBSD n'apportent pas grand chose de plus, et si l'on commence
à rajouter du code non officiellement supporté, Open pert beaucoup de
son intéret (code audité, etc...).

--
Djoumé SALVETTI

F. Senault

non lue,
7 juin 2004, 09:38:5007/06/2004
à
Le 07 juin à 14:24, Benjamin Pineau a écrit :

> Le 06 Jun 2004 22:59:48 GMT,
> Djoume SALVETTI <salv...@crans.org> écrivais:
>>
>> Quand au choix d'OpenBSD, les problèmes sont alors la lenteur [1], la
>> portabilité et surtout le manque de ports.
>
> La portabilité ? j'ai l'impression que la désinformation a vite gagnée
> ce thread. Dites moi quelle architecture manque qui fasse objection au
> déploiment de cet OS sur de serveurs modernes.

Pas de support ia64, pas de SMP. Si ça, c'est pas un problème sur un
serveur moderne (et moins moderne), je sais pas ce que c'est.

Mais bon, je dis ça, je dis rien.

Fred
Suivi sur fcob, là.
--
Sous la lumière en plein Et dans l'ombre en silence
Si tu cherches un abri Inaccessible
Dis toi qu'il n'est pas loin et qu'on y brille
A ton étoile (Noir Désir, A ton étoile)

Le message a été supprimé

Cedric Blancher

non lue,
7 juin 2004, 10:01:4407/06/2004
à
Le Mon, 07 Jun 2004 13:56:56 +0000, jdc a écrit :
> On peut imaginer que ces braves gens de chez OpenBSD ne sont pas
> nécessairement des baltringues et qu'ils ont sacrifié un peu de peps
> au bénéfice de la robustesse et autres considérations nettement moins
> glamour.

Effectivement.

> Un bipro pour faire une passerelle de sécu je veux bien, faut pas être
> rétrograde, mais bon.

Déjà, l'utilisation d'OpenBSD pour faire un firewall peut être
discutée dans certains cas de figure. L'absence de support d'ALG comme
FTP par exemple me semble cruellement manquer, d'autant que ce qui faisait
sa force, le suivi de fenêtre TCP, est intégrable sous Linux. Enfin,
pour une machine sur laquelle aucun port n'est ouvert...

L'intérêt que je vois à OpenBSD, c'est de mettre en place des serveurs
applicatifs sécurisés, parce que les applications sont auditées, parce
qu'on dispose d'outils audités efficace, etc. Mais si j'ai besoin d'un
bipro parce que mon Web a besoin de puissance de calcul, ben paf.
Considérer que le bipro est un guizmo à la mode me semble clairement
_très_ rétrograde. Mais bon, ce n'est pas le genre d'argument qui me
font travailler sur une autre plate-forme.


--
BOFH excuse #408:

Computers under water due to SYN flooding.

Marwan Burelle

non lue,
7 juin 2004, 10:44:5407/06/2004
à
On 07 Jun 2004 13:38:50 GMT
Djoume SALVETTI <salv...@crans.org> wrote:

> Ceux de NetBSD n'apportent pas grand chose de plus, et si l'on
> commence à rajouter du code non officiellement supporté, Open pert
> beaucoup de son intéret (code audité, etc...).

Je penses que vous n'avez pas regarder l'arbre des ports de NetBSD
depuis un petit moment (actuellement, s'il l'on prend la liste brut des
pkg dispo, elle fait 4701 lignes ... )

Je penses que vous devriez mieux vous renseigner sur ce sujet.

--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
(bur...@lri.fr | Marwan....@ens.fr)

Le message a été supprimé

VANHULLEBUS Yvan

non lue,
7 juin 2004, 11:18:5207/06/2004
à
j...@dugenou.removethis.net (jdc) writes:

> Cedric Blancher:
>
[OpenBSD / Bipro / etc...]


> >Mais si j'ai besoin d'un
> >bipro parce que mon Web a besoin de puissance de calcul, ben paf.
> >Considérer que le bipro est un guizmo à la mode me semble clairement
> >_très_ rétrograde.
>

> Je parlais dans le contexte d'une passerelle de sécurité où ça me
> semble luxus. Après tout, un fait que les lunixiens ne manquent
> jamais de mettre en avant c'est que leur fw peut tourner sur une
> architecture minimale tout en faisant le café d'une main et jouer du
> violon de l'autre. Ce que je ne conteste en aucune façon.

Bah avec OpenBSD, sur la meme architecture, on ne peut pas faire jouer
du violon pendant ce temps, avoues que c'est vraiment dommage !!

Plus serieusement, il y a effectivement des fois ou ca peut etre
"dangereux" d'utiliser des algos rapides pour certains traitements
(algos pas fiables a 100%, implementations delicates a faire, dont
sujettes a bugs, etc....), mais faut arreter de systematiquement se
planquer derriere l'argument "je fais du secure, ranafout si ca rame
sa mere !".

D'ailleurs, a l'epoque ou un gros bench avait defraye la chronique en
annoncant des perfs pourries d'OpenBSD, certains avaient crie a
l'heresie, d'autres se sont penches sur le code, ont justifie certains
points (si ma memoire est bonne, ou plus vraisemblablement si j'ai de
la chance :-), et ont reecrit d'autres, parcequ'elles avaient vraiment
ete ecrites avec des moufles !!!

Et au passage, pour un OS qui se dit "secure", avoir des portions de
code qui "encouragent" la surcharge CPU (donc pourquoi pas un DOS), ca me
parait moyen......


> De plus il me semble "injuste" - mais je m'en remettrai - qu'on fasse
> ce reproche à OpenBSD, un OS dont le but n'est pas de faire avec un
> serveur applicatif.

Ah ?

Et c'est quoi, le but d'OpenBSD, alors ?
De faire firewall ?

Bah faudrait prevenir les gens qui passent du temps a y
integrer/auditer des serveurs HTTP, SMTP, autres, les gens qui
s'embetent a developper des trucs genre jail, chroot, NX patches et
autres, les gens qui maintiennent les ports d'OpenBSD, parceque tout
ca, ca sert a rien sur un firewall.....


> Maintenant si on me dit qu'il faut vraiment un bipro pour faire
> tourner un fw sur OpenBSD moi je n'ai rien contre. M'enfin doit
> exister des brouettes moins chères chez Casto.

Bah tout est relatif, si c'est un firewall avec plusieurs interfaces
Gigabit, qu'on veut absolument tout loguer et qu'on fait un usage
massif de VPNs IPSec (en 3DES, c'est moins rapide :-), doit commencer
a falloir une bonne puissance CPU !

Comment ca, je suis de mauvaise foi ???? :-)


> Pour le reste, notre serveur Oracle est un bipro comme notre serveur
> d'Intranet. Comme chaque fois qu'il y a besoin de puissance.

Euh, ouais, mais avec Oracle, on derive un peu, parceque c'est un
Systeme d'Exploitation tres specifique :-)


A +

VANHU.

Djoume SALVETTI

non lue,
7 juin 2004, 12:10:5407/06/2004
à
Le lundi 06/07/04 VANHULLEBUS Yvan <vanhu@nospam_free.fr> a écrit :

> D'ailleurs, a l'epoque ou un gros bench avait defraye la chronique en
> annoncant des perfs pourries d'OpenBSD,

http://bulk.fefe.de/scalability/

--
Djoumé SALVETTI

Djoume SALVETTI

non lue,
7 juin 2004, 12:10:5407/06/2004
à
Le lundi 06/07/04 Marwan Burelle <bur...@lri.fr> a écrit :

> On 07 Jun 2004 13:38:50 GMT
> Djoume SALVETTI <salv...@crans.org> wrote:
>
> > Ceux de NetBSD n'apportent pas grand chose de plus, et si l'on
> > commence à rajouter du code non officiellement supporté, Open pert
> > beaucoup de son intéret (code audité, etc...).
>
> Je penses que vous n'avez pas regarder l'arbre des ports de NetBSD
> depuis un petit moment (actuellement, s'il l'on prend la liste brut des
> pkg dispo, elle fait 4701 lignes ... )

Il y en a quasiment le double dans Debian Stable (et plus du triple dans
Debian Testing).

--
Djoumé SALVETTI

Le message a été supprimé

Patrice Auffret

non lue,
8 juin 2004, 03:23:4608/06/2004
à
On 07 Jun 2004 15:18:52 GMT
VANHULLEBUS Yvan <vanhu@nospam_free.fr> wrote:

[..]


> Et au passage, pour un OS qui se dit "secure", avoir des portions de
> code qui "encouragent" la surcharge CPU (donc pourquoi pas un DOS), ca me
> parait moyen......

[..]

Dans le meme registre, mais encore plus troll:

obsd34-defaut-install# netstat -anf inet | grep LISTEN
tcp 0 0 *.22 *.* LISTEN
tcp 0 0 127.0.0.1.587 *.* LISTEN
tcp 0 0 127.0.0.1.25 *.* LISTEN
tcp 0 0 *.37 *.* LISTEN
tcp 0 0 *.13 *.* LISTEN
tcp 0 0 *.113 *.* LISTEN

Alors que ici: http://www.openbsd.org/security.html#default
[..]
All non-essential services are disabled.
[..]

C'est clair que timserver et daytime c'est essentiel.

Thomas Nemeth

non lue,
8 juin 2004, 03:23:4608/06/2004
à
Le lun 07 jun 2004 à 18:10, Djoume SALVETTI a tapoté :

La différence n'est plus si grande que ça si on vire les packages
dédiés à la doc et aux -dev...


Thomas
--
BOFH excuse #282:
High altitude condensation from U.S.A.F prototype aircraft has contaminated the
primary subnet mask. Turn off your computer for 9 days to avoid damaging it.

Cedric Blancher

non lue,
8 juin 2004, 03:35:3908/06/2004
à
Le Mon, 07 Jun 2004 14:44:54 +0000, jdc a écrit :
> De plus il me semble "injuste" - mais je m'en remettrai - qu'on fasse
> ce reproche à OpenBSD, un OS dont le but n'est pas de faire avec un
> serveur applicatif.

Faudra que je l'envoie à Theo, Niels et autres celle-là, ça va leur
faire plaisir.

C'est quoi l'intérêt d'avoir des packages audités de Apache, BIND,
Postfix, PGSQL, MySQL, PHP4, etc. si le but n'est pas de faire des
serveurs applicatifs comme des serveurs Web, des serveurs SMTP, etc. ?
Paraît même qu'il y en a qui en font des stations de travail...

> Maintenant si on me dit qu'il faut vraiment un bipro pour faire tourner
> un fw sur OpenBSD moi je n'ai rien contre.

Jamais dit qu'il fallait un bipro pour faire un firewall, mais il me
semble qu'il est des champs d'application d'OpenBSD où un bipro ne ferait
pas de mal. Mais bon, moi ce que j'en dis...


--
> les débilos qui ont décrété qu'il fallait tout éteindre pendant le w.e.!!
define(`Y2K_Auto_Purge_Queue',`True')dnl
define(`Y2K_Auto_Murge_Admin',`True')dnl
-+- fyr in Guide de l'admin pervers - "Ne pas gâcher son nouvel an" -+-

VANHULLEBUS Yvan

non lue,
8 juin 2004, 05:09:5608/06/2004
à
j...@dugenou.removethis.net (jdc) writes:

> VANHULLEBUS Yvan:
>
> >j...@dugenou.removethis.net (jdc) writes:

[OpenBSD / Bipro / firewall / applicatifs / etc...]

> >Bah faudrait prevenir les gens qui passent du temps a y
> >integrer/auditer des serveurs HTTP, SMTP, autres, les gens qui
> >s'embetent a developper des trucs genre jail, chroot, NX patches et
> >autres, les gens qui maintiennent les ports d'OpenBSD, parceque tout
> >ca, ca sert a rien sur un firewall.....
>

> Bin je sais pas, les autres ils font ce qu'ils veulent, mais moi je
> mets tout ça (SMTP, HTTP)sur une DMZ[*]. Un firewall ça fait du
> fireoualle.

Ah bah puisqu'on parlait de faire dire aux autres ce qu'ils n'ont pas
dit....

La, je ne parlait pas de la conception reseau (bien sur que, quand on
peut se le permettre, on met les serveurs dans des DMZs), mes des
choix de plateformes soft/hard pour differents types d'equipements.


[....]
> C'est marrant tout de même la morale à deux vitesse. Les spécialistes
> de la sécurité, peut-être pas tous je ne les connais pas, mais
> beaucoup, n'arrêtent pas de dire aux béotiens assumés dans mon genre :
> "Houlà ! évitez de fragiliser votre machine avec des applications, que
> etc, ports ouverts qui fragilisent bidules, oeufs dans le même panier
> pas bon, DMZ et tout ça.".
> Un raisonnement qui paraît on ne peut plus sain.

Et ca reste une bonne pratique quand on peut se le permettre:
segmenter le plus possible en fonction de ses ressources et de ses
contraintes.


> Et là pour les besoins d'une brillante démonstration on me dit "Zyva
> mon gars ! Tu peux installer ton Samba, ton Postfix, ton Apache et
> soyons fous ton MySQL sur ton fw jailés dans du chroot, parce que des
> tits gars bien courageux se font suer jusqu'à pas d'heure la nuit à
> porter tout ça de leurs petites mains habiles".

Et apres ca, c'est moi qui suis doue pour faire dire aux autres ce
qu'ils n'ont pas dit ?????

Non seulement il est bien sur deconseille de mettre tout ca sur le
firewall (la encore, tout est question de compromis, il est probable
que des particuliers ou de petites structures sans beaucoup de moyens
utilisent ce genre de procedes), mais il est carrement aussi
deconseille de mettre sur la meme DMZ (note: j'ai pas dit "sur la meme
machine", mais bien "sur la meme DMZ") les serveurs prives et les
serveurs publics (voire meme "les serveurs prives qui doivent
communiquer avec les serveurs publics").

A cote de ca, ca ne veut pas dire que le concept de jail est inutile
pour autant.

Deja parceque, comme dit au dessus, des fois, on a pas trop le choix,
et on ne peut pas mettre autant de "vraies" machines qu'on veut.

Ensuite, parceque meme si la machine heberge uniquement un service,
bah ca peut etre interessant d'enfermer ce service, comme ca ca limite
fortement les risques de compromission root de la machine, donc ca
permet a un admin consciencieux de reperer/rattraper une eventuelle
compromission plus facilement.


> Mais je suis convaincu, OpenBSD c'est une grosse daube.

Pour anecdote, a l'EuroBSDCON 2002, j'ai discute avec un developpeur
OpenBSD qui cherchait desesperement des utilisateurs de ce systeme, et
quand il a su que je m'en servais un peu, il m'a demande pourquoi je
m'en servais, sur un ton genre "mais il n'y a pas de raison de s'en
servir, pourquoi tu t'en sers quand meme ????".

Mais je n'irai pas jusqu'a dire qu'OpenBSD est "une grosse daube",
meme si ca n'est pas mon OS de predilection.


> Ceci dit faut tout de même être pervers alors pour installer des
> applications sur un truc aussi pérave.

Pour s'en servir en tant que station de travail, faut commencer a etre
vicieux, je trouve.... ou bosser dans certains cabinets de
consultants, ou le portable sous OpenBSD est la norme :-)


[Perfs de firewall]


> >Bah tout est relatif, si c'est un firewall avec plusieurs interfaces
> >Gigabit, qu'on veut absolument tout loguer et qu'on fait un usage
> >massif de VPNs IPSec (en 3DES, c'est moins rapide :-), doit commencer
> >a falloir une bonne puissance CPU !
> >
>

> On achète un monstre spécialisé bardé d'ASIC avec accélérateur VPN en
> hardware.


> Comment ca, je suis de mauvaise foi ???? :-)

Au contraire, c'est pas de la mauvaise foi, j'ai hesite a signaler
cette eventualite.
Et en l'occurence, c'est justement pour son support de cartes crypto
(utilisees par la pile IPSec) que j'avais commence a regarder OpenBSD.


[concours de mauvaise foi.....]

> Mon seul propos était, disons "de principe", "attendons un peu avant
> de se jeter sur la modernité et d'essuyer quelques plâtres". Et il
> était implicite, mais pas dit effectivement que le progrès n'est pas
> fait que pour faire vendre.

Bah le SMP, en l'occurence, ca commence plus trop a etre de "la
modernite", je trouve, et si tout le monde ici semble d'accord sur le
fait que c'est probablement pas utile pour un firewall "normal", c'est
quand meme vachement interessant pour d'autres types de serveurs,
qu'on pourrait vouloir faire tourner sous OpenBSD pour d'autres
raisons.....

A +

VANHU.

Eric Masson

non lue,
8 juin 2004, 05:43:2308/06/2004
à
>>>>> "VANHU" == VANHULLEBUS Yvan <vanhu@nospam_free.fr> writes:

'Lut,

VANHU> A cote de ca, ca ne veut pas dire que le concept de jail est
VANHU> inutile pour autant.

C'est même fichtrement pratique, même si ce n'est pas implémenté sous
Open (qui utilise plutôt privsep et les chroots) et qu'un advisory vient
de sortir concernant l'implémentation disponible dans FreeBSD 4.* :
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-04:12.jailroute.asc

VANHU> Mais je n'irai pas jusqu'a dire qu'OpenBSD est "une grosse
VANHU> daube", meme si ca n'est pas mon OS de predilection.

Un des ses gros atouts est la simplicité, et une documentation qui te
permet d'arriver à un résultat probant sans rechercher des
renseignements éparpillés dans des man pages ou des infos files
merdiques ou encore dans des howto écrits avec les pieds.

Les performances ne sont pas toujours optimales, par exemple, le
sous-système crypto de Free et Net dérive de celui d'Open dans lequel
Sam Leffler a trouvé du "suboptimal code" ;), mais certains
sous-systèmes comme pf/altq valent à eux seuls que l'on s'accomode des
positions rigides de certains développeurs d'Open.

VANHU> Pour s'en servir en tant que station de travail, faut commencer
VANHU> a etre vicieux, je trouve.... ou bosser dans certains cabinets
VANHU> de consultants, ou le portable sous OpenBSD est la norme :-)

Toujours le même point, les docs sont bien foutues, ce qui fait que
monter une station est plutôt aisé.

VANHU> Bah le SMP, en l'occurence, ca commence plus trop a etre de "la
VANHU> modernite", je trouve, et si tout le monde ici semble d'accord
VANHU> sur le fait que c'est probablement pas utile pour un firewall
VANHU> "normal", c'est quand meme vachement interessant pour d'autres
VANHU> types de serveurs, qu'on pourrait vouloir faire tourner sous
VANHU> OpenBSD pour d'autres raisons.....

Comme le disait Miod, le support SMP est attendu pour ce qui devrait
être la 3.7.

Eric Masson

--
JL> C'est moi ou Julien II qui te dois une bière ?
JB> C'est moi qui lui dois une mousse.
FF> L'autre aussi, ya pas de raison.
-+- FF in <http://www.le-gnu.net> : Y'en aura pour tout le monde -+-

Benjamin Pineau

non lue,
8 juin 2004, 09:48:0708/06/2004
à
Le 07 Jun 2004 13:38:50 GMT,

>
> Ceux de NetBSD n'apportent pas grand chose de plus, et si l'on commence

Par rapport à la problématique que vous interessait si: ils sont très
nombreux.

> à rajouter du code non officiellement supporté, Open pert beaucoup de
> son intéret (code audité, etc...).

Au passage: les ports natifs ne sont pas non plus supportés (et beaucoup
moins audités).

Benjamin Pineau

non lue,
8 juin 2004, 10:09:5308/06/2004
à
Le 07 Jun 2004 14:01:44 GMT,
Cedric Blancher <blan...@cartel-securite.fr> écrivais:

>
> Déjà, l'utilisation d'OpenBSD pour faire un firewall peut être
> discutée dans certains cas de figure. L'absence de support d'ALG comme
> FTP par exemple me semble cruellement manquer, d'autant que ce qui faisait
> sa force, le suivi de fenêtre TCP, est intégrable sous Linux. Enfin,
> pour une machine sur laquelle aucun port n'est ouvert...

Effectivement, le ftp est moins pratique (il faut passer par le
proxy-ftp natif, quitte à utiliser la redirection transparente).
L'interet d'un firewall sous pf (puisque l'objet est la comparaison
avec Linux) peut néanmoins, selon les besoins, être réel (surtout si
l'on omet les linux patch-o-matisés, moins audités/stables/...).

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).
Il y a aussi des fonctionalités plus secondaires (voir gadgets) mais
qui peuvent s'avérer utiles selon les usages: intégration avec p0f pour
gestion du traffic selon l'OS source, avec altq (pour le QoS), avec l'outil
de filtrage de spam natif, algos de load-balancing pour la redirection,
filtrage vraiment statefull d'IPv6, blindages des stacks IPs fragiles
(modulate state, random-id, syn proxy), authentification, grammaire de
mieux en mieux fichue, outil de test de syntaxe + changements atomiques,
etc.

Dans d'autres cas Linux/netfilter présente des avantages (comme la
possibilité de filtrage au niveau applicatif ou le NAT sur certains
protos plus rares).

> L'intérêt que je vois à OpenBSD, c'est de mettre en place des serveurs
> applicatifs sécurisés, parce que les applications sont auditées, parce
> qu'on dispose d'outils audités efficace, etc. Mais si j'ai besoin d'un
> bipro parce que mon Web a besoin de puissance de calcul, ben paf.
> Considérer que le bipro est un guizmo à la mode me semble clairement
> _très_ rétrograde. Mais bon, ce n'est pas le genre d'argument qui me
> font travailler sur une autre plate-forme.

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.

Comme toujours en ce qui concerne le choix d'architecture, il n'y a pas
une et une seule solution valable dans tout les cas. L'important est
alors de connaître les choix possibles à un instant t.
A ce titre les utilisateurs de fcos qui ne connaissaient pas l'existence
d'autres systèmes robustes (que Linux ou Kerio, visiblement les plus
populaires) pourraient être intéréssés par une telle discussion, en
dépit des detours trollistiques ;)

Cedric Blancher

non lue,
8 juin 2004, 11:24:0008/06/2004
à
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...

> Il y a aussi des fonctionalités plus secondaires (voir gadgets) mais
> 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.

> avec altq (pour le QoS),

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

> avec l'outil de filtrage de spam natif,

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

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

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

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


--
Il s'est sans doute laissé impressionner par les cris d'orfraie du
quarteron de fufopithèques en furie.
-+- MB in: Guide du Cabaliste Usenet - Bien configurer son MB -+-

db

non lue,
8 juin 2004, 20:07:1508/06/2004
à
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

Benjamin Pineau

non lue,
8 juin 2004, 21:36:2508/06/2004
à
Le 08 Jun 2004 15:24:00 GMT,
Cedric Blancher <blan...@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 ?

Cedric Blancher

non lue,
9 juin 2004, 01:15:0509/06/2004
à
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-+-

Cedric Blancher

non lue,
9 juin 2004, 04:16:4409/06/2004
à
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" -+-

Benjamin Pineau

non lue,
9 juin 2004, 08:17:0409/06/2004
à
Le 09 Jun 2004 00:07:15 GMT,
db <nos...@spam.int> écrivais:

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

Encore une fois, il ne s'agit pas de filtrer du contenu au niveau du fw.
Je crois par contre que les outils de filtrages gagnent a offrir des
interfaces propres pour "dialoguer" avec le userland. Et reciproquement,
les outils userland à savoir causer au firewall.

Iptables (mark, QUEUE, ULOG, netlink ...) et pf (tables et anchor, logs
au format pcap, interface virtuelle pour les logs ...) sont au point sur
cet aspect.

J'ai plutôt l'impression que les outils userland sachant interagir
_proprement_ avec le firewall sont moins nombreux qu'il pourraient être
(antivirus, proxys, ids, polices ipsec/isakmp, authentification, filtres
divers etc.) pour un secteur si prometeur.

On s'en remet plus volontier aux bricolages en shell script, ou on joue
avec la redirection/duplication de traffic (pas très beau non plus) pour
éviter de coller des interfaces en promisc...

Bref, les initiatives userland visant une integration de qualité avec le
firewall méritent, amha, toute notre attention.

De quoi irriguer ce thread d'un nouvau thème non ? ;) d'une certaine
manière ça rejoint le thread plus bas sur les firewalls personels, et
même le sujet initial de ce thread sur l'inconstance des patchs (vs l'
intégration de qualité ?).

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

Benjamin Pineau

non lue,
9 juin 2004, 09:50:2609/06/2004
à
Le 09 Jun 2004 05:15:05 GMT,
Cedric Blancher <blan...@cartel-securite.fr> écrivais:

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

Tient profitons de l'occasion pour signaler au passage un autre outil de
filtrage offrant une solution QoS basique mais vraiment très simple et
agréable à utiliser: ipfw (dummynet). A ma connaissance, seulement pour
FreeBSD pour les versions récentes.

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

Effectivement, je viens de trouver spamcannibal qui sait faire ça.

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

Je viens de regarder la doc ; on dirait qu'il manque un moyen d'assurer
la constance nécessaire pour les protocoles applicatifs à état (eg.
sessions http), par exemple en s'assurant qu'une ip source donnée aura
toujours la même destination (source-hash sous pf). Tu confirme ?
Idem d'ailleur pour les états layer 4. J'imagine qu'on doit pouvoir
obtenir ça en jouant avec 'mark' mais ... bof.

> Pour les changements atomiques : iptables-restore.

Oui bien sûr. Mais pas précisément commode pour modifier un ruleset
avant de le recharger "atomiquement" il me semble.
Dans mon cas, j'insère ou modifie d'abord les nouvelles règles, une à
une, dans le firewall actif (pas très atomique donc), puis iptables-save.
Le restore ne me sert qu'en de rares occasion.
Je suis sûr que ce n'est pas la meilleure façon de s'y prendre, donc si
vous avez des suggestions/best-practices pour les modifications de
firewalls sous netfilter, je suis preneur (en excluant la modification
manuelle des dumps d'iptables-save, faut pas déconner ;).

> 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 ;)

Ok bin je vais tester ça. Ca pourrait m'epargner un ulcère ;)

Djoume SALVETTI

non lue,
9 juin 2004, 09:50:2609/06/2004
à
Le samedi 06/05/04 Eric Razny <new...@razny.net> a écrit :
> Comme il semble que ce soit la fin :
> http://www.grsecurity.org/
> (ŕ moins d'un effet d'annonce)

Le projet semble reparti :

http://grsecurity.net/news.php

--
Djoumé SALVETTI

db

non lue,
9 juin 2004, 18:47:4109/06/2004
à
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

non lue,
9 juin 2004, 18:47:4109/06/2004
à
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.

Cedric Blancher

non lue,
10 juin 2004, 01:45:0810/06/2004
à
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

Répondre à tous
Répondre à l'auteur
Transférer
0 nouveau message