Bonjour,
Un Firewall matériel 'grand public' (ciblé pour la protection d'un
petit réseau de moins de 20 postes) offre t-il toutes les garanties
contre les tentatives d'intrusion ? Quelles sont ses atouts face à une
protection par logiciel ?
Merci.
"Cedric Blancher" a écrit dans le message de news:
Dans sa prose, Eric Razny nous ecrivait :
Un FW matériel se justifie quand même, amha, quand tu as une très grosse bande passante à filtrer. Dans ce cas le hardware est dimensionné/spécialisé pour.
Et encore... Un certain éditeur fournit son soft, OS Linux based compris, sur n'importe quelle plateforme PC et, pour peu que la plateforme soit bien dimensionnée atteint des performances similaires à celles proposée par l'eéditeur qui utilise des ASIC.
Cool. C'est encore mieux que ce que je pensais. Noté!
Tu peux argumenter?
Je dirais :
pro BSD : véritable suivi d'état, avec gestion de la fenêtre TCP, et performances (pour pf)
tcp-window-tracking dans le pom ne fait pas l'affaire?
con BSD : absence d'équivalent de la chaîne FORWARD et manque de fonctionnalités "exotiques"
comme changer les TTL pour emmerder les adeptes du firewalking par exemple? :)
Quand à la facilité d'écrire une règle, ça peut entrer en ligne de compte, mais pas en ce qui concerne l'efficacité du produit. Netfilter a une syntaxe clairement trop verbeuse. En plus, l'ordre des paramètres étant extrêmement libre, certains rulesets peuvent s'avérer illisibles par d'autres. D'un autre côté, s'ils sont écrits proprement, ils n'ont même pas besoin de commentaires, c'est l'avantage du côté verbeux.
Au début c'est chiant mais après coup je pense que l'aspect "trois commentaires dans les règles suffisent" est bien agréable. Quand les params sont placés de façon bordeliques (la personne ne reste pas cohérente dans sa façon d'écrire les règles) un coup d'iptables-save permet de s'en sortir (enfin quand le pom n'a pas trop été utilisé, mais même la ça aide un peu)
Eric.
"Cedric Blancher" <blancher@cartel-securite.fr> a écrit dans le message de
news:pan.2003.09.27.06.58.46.205641@cartel-securite.fr...
Dans sa prose, Eric Razny nous ecrivait :
Un FW matériel se justifie quand même, amha, quand tu as une très
grosse bande passante à filtrer. Dans ce cas le hardware est
dimensionné/spécialisé pour.
Et encore... Un certain éditeur fournit son soft, OS Linux based compris,
sur n'importe quelle plateforme PC et, pour peu que la plateforme soit
bien dimensionnée atteint des performances similaires à celles proposée
par l'eéditeur qui utilise des ASIC.
Cool. C'est encore mieux que ce que je pensais. Noté!
Tu peux argumenter?
Je dirais :
pro BSD : véritable suivi d'état, avec gestion de la fenêtre TCP, et
performances (pour pf)
tcp-window-tracking dans le pom ne fait pas l'affaire?
con BSD : absence d'équivalent de la chaîne FORWARD et manque de
fonctionnalités "exotiques"
comme changer les TTL pour emmerder les adeptes du firewalking par exemple?
:)
Quand à la facilité d'écrire une règle, ça peut entrer en ligne de
compte, mais pas en ce qui concerne l'efficacité du produit. Netfilter
a une syntaxe clairement trop verbeuse. En plus, l'ordre des paramètres
étant extrêmement libre, certains rulesets peuvent s'avérer illisibles
par d'autres. D'un autre côté, s'ils sont écrits proprement, ils n'ont
même pas besoin de commentaires, c'est l'avantage du côté verbeux.
Au début c'est chiant mais après coup je pense que l'aspect "trois
commentaires dans les règles suffisent" est bien agréable.
Quand les params sont placés de façon bordeliques (la personne ne reste pas
cohérente dans sa façon d'écrire les règles) un coup d'iptables-save permet
de s'en sortir (enfin quand le pom n'a pas trop été utilisé, mais même la ça
aide un peu)
"Cedric Blancher" a écrit dans le message de news:
Dans sa prose, Eric Razny nous ecrivait :
Un FW matériel se justifie quand même, amha, quand tu as une très grosse bande passante à filtrer. Dans ce cas le hardware est dimensionné/spécialisé pour.
Et encore... Un certain éditeur fournit son soft, OS Linux based compris, sur n'importe quelle plateforme PC et, pour peu que la plateforme soit bien dimensionnée atteint des performances similaires à celles proposée par l'eéditeur qui utilise des ASIC.
Cool. C'est encore mieux que ce que je pensais. Noté!
Tu peux argumenter?
Je dirais :
pro BSD : véritable suivi d'état, avec gestion de la fenêtre TCP, et performances (pour pf)
tcp-window-tracking dans le pom ne fait pas l'affaire?
con BSD : absence d'équivalent de la chaîne FORWARD et manque de fonctionnalités "exotiques"
comme changer les TTL pour emmerder les adeptes du firewalking par exemple? :)
Quand à la facilité d'écrire une règle, ça peut entrer en ligne de compte, mais pas en ce qui concerne l'efficacité du produit. Netfilter a une syntaxe clairement trop verbeuse. En plus, l'ordre des paramètres étant extrêmement libre, certains rulesets peuvent s'avérer illisibles par d'autres. D'un autre côté, s'ils sont écrits proprement, ils n'ont même pas besoin de commentaires, c'est l'avantage du côté verbeux.
Au début c'est chiant mais après coup je pense que l'aspect "trois commentaires dans les règles suffisent" est bien agréable. Quand les params sont placés de façon bordeliques (la personne ne reste pas cohérente dans sa façon d'écrire les règles) un coup d'iptables-save permet de s'en sortir (enfin quand le pom n'a pas trop été utilisé, mais même la ça aide un peu)
Eric.
Cedric Blancher
Dans sa prose, Eric Razny nous ecrivait :
Et encore... Un certain éditeur fournit son soft, OS Linux based compris, sur n'importe quelle plateforme PC et, pour peu que la plateforme soit bien dimensionnée atteint des performances similaires à celles proposée par l'eéditeur qui utilise des ASIC. Cool. C'est encore mieux que ce que je pensais. Noté!
Ouais, mais faut un PC avec un bus PCI 64bits, et ça vaut son pesant de cacahouètes. Et dans le cas présent, je préfère bosser avec les plate-formes du monsieur aux ASIC, elles, au moins, ont un _vraie_ ligne de commande ;)
pro BSD : véritable suivi d'état, avec gestion de la fenêtre TCP, et performances (pour pf) tcp-window-tracking dans le pom ne fait pas l'affaire?
Ben justement, le problème est là, il est _encore_ dans le pom. Il est stable, mais manque d'optimisation à mon goût (faut pas chercher les perfs). En plus, ça te remplit les logs en deux temps trois mouvements. Bref, il n'y a pas de volonté claire de l'équipe Netfilter d'intégrer ça dans la release officielle avec la possibilité de le contrôler via le sysctl (activation/désactivation, gestion des timeouts). C'est comme le "-p tcp --syn -m state --state NEW". Pas mal de monde gueule, il y a des patches qui ont traîné pour faire qu'un paquet TCP NEW soit forcément un SYN, mais jamais de volonté d'intégrer cela dans le kernel et coller une entrée en sysctl pour passer du mode classique au mode intuitivement attendu.
J'oubliais un truc :
con Netfilter : un support IPv6 de merde, i.e. pas de stateful...
Là encore, on ne sait pas où on va. Deux personnes au moins ont bossé sur le truc et proposé des patches (un mec encore très récemment), mais la volonté d'avoir une interface commune au niveau 3 (i.e. pkttables), et donc le stateful qui va avec, fait rechigner l'intégration. Du coup, on se retrouve sans stateful IPv6, alors que ces patches pourraient au moins figurer au pom ou être intégrés en attendant pkttables qui n'est prévu que pour les 2.7.
Idem pour le failover (mais là, balle au centre) avec partage d'états. Rien n'est fait, rien n'est intégré, parce qu'au niveau où ils ont placé la barre, on ne verra pas de code fonctionnel avec les 2.7. Alors qu'il y a clairement de quoi sortir un système simple à base de VRRP et un système de transfert qui vaut ce qu'il vaut comme c'est le cas pour le failover des passerelles IPVS.
con BSD : absence d'équivalent de la chaîne FORWARD et manque de fonctionnalités "exotiques" comme changer les TTL pour emmerder les adeptes du firewalking par
exemple?
Oui, par exemple, mais pas que. Netfilter est structurellement plus extensible que pf, ce qui le rend de facto plus versatile. Rien que le marquage des paquets (-j MARK) est une fonctionnalité d'une puissance considérable, surtout si on considère que cette marque peut être utilisée pour router et faire de la QoS. Les cibles de la table mangle sont parfois fort utile, comme le flush des options IP. Bref, pas mal de petits trucs qui rendent l'outil puissant. Mais à côté de cela, des trucs de base qui ont du mal à avancer...
Ça ne m'empêche pas de préférer Netfilter ;)
-- BOFH excuse #415:
Maintenance window broken
Dans sa prose, Eric Razny nous ecrivait :
Et encore... Un certain éditeur fournit son soft, OS Linux based
compris, sur n'importe quelle plateforme PC et, pour peu que la
plateforme soit bien dimensionnée atteint des performances similaires
à celles proposée par l'eéditeur qui utilise des ASIC.
Cool. C'est encore mieux que ce que je pensais. Noté!
Ouais, mais faut un PC avec un bus PCI 64bits, et ça vaut son pesant de
cacahouètes. Et dans le cas présent, je préfère bosser avec les
plate-formes du monsieur aux ASIC, elles, au moins, ont un _vraie_ ligne
de commande ;)
pro BSD : véritable suivi d'état, avec gestion de la fenêtre TCP, et
performances (pour pf)
tcp-window-tracking dans le pom ne fait pas l'affaire?
Ben justement, le problème est là, il est _encore_ dans le pom. Il est
stable, mais manque d'optimisation à mon goût (faut pas chercher les
perfs). En plus, ça te remplit les logs en deux temps trois mouvements.
Bref, il n'y a pas de volonté claire de l'équipe Netfilter d'intégrer
ça dans la release officielle avec la possibilité de le contrôler via
le sysctl (activation/désactivation, gestion des timeouts). C'est comme
le "-p tcp --syn -m state --state NEW". Pas mal de monde gueule, il y a
des patches qui ont traîné pour faire qu'un paquet TCP NEW soit
forcément un SYN, mais jamais de volonté d'intégrer cela dans le kernel
et coller une entrée en sysctl pour passer du mode classique au mode
intuitivement attendu.
J'oubliais un truc :
con Netfilter : un support IPv6 de merde, i.e. pas de stateful...
Là encore, on ne sait pas où on va. Deux personnes au moins ont bossé
sur le truc et proposé des patches (un mec encore très récemment), mais
la volonté d'avoir une interface commune au niveau 3 (i.e. pkttables), et
donc le stateful qui va avec, fait rechigner l'intégration. Du coup, on
se retrouve sans stateful IPv6, alors que ces patches pourraient au moins
figurer au pom ou être intégrés en attendant pkttables qui n'est prévu
que pour les 2.7.
Idem pour le failover (mais là, balle au centre) avec partage d'états.
Rien n'est fait, rien n'est intégré, parce qu'au niveau où ils ont
placé la barre, on ne verra pas de code fonctionnel avec les 2.7. Alors
qu'il y a clairement de quoi sortir un système simple à base de VRRP et
un système de transfert qui vaut ce qu'il vaut comme c'est le cas pour le
failover des passerelles IPVS.
con BSD : absence d'équivalent de la chaîne FORWARD et manque de
fonctionnalités "exotiques"
comme changer les TTL pour emmerder les adeptes du firewalking par
exemple?
Oui, par exemple, mais pas que. Netfilter est structurellement plus
extensible que pf, ce qui le rend de facto plus versatile. Rien que le
marquage des paquets (-j MARK) est une fonctionnalité d'une puissance
considérable, surtout si on considère que cette marque peut être
utilisée pour router et faire de la QoS. Les cibles de la table mangle
sont parfois fort utile, comme le flush des options IP. Bref, pas mal de
petits trucs qui rendent l'outil puissant. Mais à côté de cela, des
trucs de base qui ont du mal à avancer...
Et encore... Un certain éditeur fournit son soft, OS Linux based compris, sur n'importe quelle plateforme PC et, pour peu que la plateforme soit bien dimensionnée atteint des performances similaires à celles proposée par l'eéditeur qui utilise des ASIC. Cool. C'est encore mieux que ce que je pensais. Noté!
Ouais, mais faut un PC avec un bus PCI 64bits, et ça vaut son pesant de cacahouètes. Et dans le cas présent, je préfère bosser avec les plate-formes du monsieur aux ASIC, elles, au moins, ont un _vraie_ ligne de commande ;)
pro BSD : véritable suivi d'état, avec gestion de la fenêtre TCP, et performances (pour pf) tcp-window-tracking dans le pom ne fait pas l'affaire?
Ben justement, le problème est là, il est _encore_ dans le pom. Il est stable, mais manque d'optimisation à mon goût (faut pas chercher les perfs). En plus, ça te remplit les logs en deux temps trois mouvements. Bref, il n'y a pas de volonté claire de l'équipe Netfilter d'intégrer ça dans la release officielle avec la possibilité de le contrôler via le sysctl (activation/désactivation, gestion des timeouts). C'est comme le "-p tcp --syn -m state --state NEW". Pas mal de monde gueule, il y a des patches qui ont traîné pour faire qu'un paquet TCP NEW soit forcément un SYN, mais jamais de volonté d'intégrer cela dans le kernel et coller une entrée en sysctl pour passer du mode classique au mode intuitivement attendu.
J'oubliais un truc :
con Netfilter : un support IPv6 de merde, i.e. pas de stateful...
Là encore, on ne sait pas où on va. Deux personnes au moins ont bossé sur le truc et proposé des patches (un mec encore très récemment), mais la volonté d'avoir une interface commune au niveau 3 (i.e. pkttables), et donc le stateful qui va avec, fait rechigner l'intégration. Du coup, on se retrouve sans stateful IPv6, alors que ces patches pourraient au moins figurer au pom ou être intégrés en attendant pkttables qui n'est prévu que pour les 2.7.
Idem pour le failover (mais là, balle au centre) avec partage d'états. Rien n'est fait, rien n'est intégré, parce qu'au niveau où ils ont placé la barre, on ne verra pas de code fonctionnel avec les 2.7. Alors qu'il y a clairement de quoi sortir un système simple à base de VRRP et un système de transfert qui vaut ce qu'il vaut comme c'est le cas pour le failover des passerelles IPVS.
con BSD : absence d'équivalent de la chaîne FORWARD et manque de fonctionnalités "exotiques" comme changer les TTL pour emmerder les adeptes du firewalking par
exemple?
Oui, par exemple, mais pas que. Netfilter est structurellement plus extensible que pf, ce qui le rend de facto plus versatile. Rien que le marquage des paquets (-j MARK) est une fonctionnalité d'une puissance considérable, surtout si on considère que cette marque peut être utilisée pour router et faire de la QoS. Les cibles de la table mangle sont parfois fort utile, comme le flush des options IP. Bref, pas mal de petits trucs qui rendent l'outil puissant. Mais à côté de cela, des trucs de base qui ont du mal à avancer...
Ça ne m'empêche pas de préférer Netfilter ;)
-- BOFH excuse #415:
Maintenance window broken
Eric Masson
"Cedric" == Cedric Blancher writes:
Cedric> Rien que le marquage des paquets (-j MARK) est une Cedric> fonctionnalité d'une puissance considérable, surtout si on Cedric> considère que cette marque peut être utilisée pour router et Cedric> faire de la QoS.
Iirc, itojun de KAME envisage de passer pf comme packet filter par défaut à cause justement de ses capacités de packet tagging (KAME intègre un packet filter pour déterminer les paquets devant subir une transformation ipsec).
L'intégration pf/AltQ dans Open est basée sur le même principe.
Eric Masson
-- je suis à la recherche d'un code d'acces pur un CD hard sex 2 les codes sont sur le minitel 3617 procode rubrique d'image code 007 si quelqu'un peut me rendre se petit service -+- OD in <http://www.le-gnu.net> : O tempora, O nanisme -+-
Cedric> Rien que le marquage des paquets (-j MARK) est une
Cedric> fonctionnalité d'une puissance considérable, surtout si on
Cedric> considère que cette marque peut être utilisée pour router et
Cedric> faire de la QoS.
Iirc, itojun de KAME envisage de passer pf comme packet filter par
défaut à cause justement de ses capacités de packet tagging (KAME
intègre un packet filter pour déterminer les paquets devant subir une
transformation ipsec).
L'intégration pf/AltQ dans Open est basée sur le même principe.
Eric Masson
--
je suis à la recherche d'un code d'acces pur un CD hard sex 2
les codes sont sur le minitel 3617 procode rubrique d'image code 007
si quelqu'un peut me rendre se petit service
-+- OD in <http://www.le-gnu.net> : O tempora, O nanisme -+-
Cedric> Rien que le marquage des paquets (-j MARK) est une Cedric> fonctionnalité d'une puissance considérable, surtout si on Cedric> considère que cette marque peut être utilisée pour router et Cedric> faire de la QoS.
Iirc, itojun de KAME envisage de passer pf comme packet filter par défaut à cause justement de ses capacités de packet tagging (KAME intègre un packet filter pour déterminer les paquets devant subir une transformation ipsec).
L'intégration pf/AltQ dans Open est basée sur le même principe.
Eric Masson
-- je suis à la recherche d'un code d'acces pur un CD hard sex 2 les codes sont sur le minitel 3617 procode rubrique d'image code 007 si quelqu'un peut me rendre se petit service -+- OD in <http://www.le-gnu.net> : O tempora, O nanisme -+-
Laurent Cheylus
Bonjour,
On Sat, 27 Sep 2003 12:22:10 +0200, Cedric Blancher wrote:
Oui, par exemple, mais pas que. Netfilter est structurellement plus extensible que pf, ce qui le rend de facto plus versatile. Rien que le marquage des paquets (-j MARK) est une fonctionnalité d'une puissance considérable, surtout si on considère que cette marque peut être utilisée pour router et faire de la QoS.
Le tagging des paquets IP a été ajouté récemment à PF sur OpenBSD et sera disponible dans la prochaine version 3.4 (sortie 1er novembre).
Voir les mots-clés "tag" et "tagged" dans la syntaxe PF : manpage pf.conf dispo ici http://www.openbsd.org/cgi-bin/man.cgi?query=pf.conf&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386
A++ Foxy
-- Laurent Cheylus OpenPGP ID 0x5B766EC2
Bonjour,
On Sat, 27 Sep 2003 12:22:10 +0200, Cedric Blancher wrote:
Oui, par exemple, mais pas que. Netfilter est structurellement plus
extensible que pf, ce qui le rend de facto plus versatile. Rien que le
marquage des paquets (-j MARK) est une fonctionnalité d'une puissance
considérable, surtout si on considère que cette marque peut être
utilisée pour router et faire de la QoS.
Le tagging des paquets IP a été ajouté récemment à PF sur OpenBSD et sera
disponible dans la prochaine version 3.4 (sortie 1er novembre).
Voir les mots-clés "tag" et "tagged" dans la syntaxe PF : manpage pf.conf
dispo ici
http://www.openbsd.org/cgi-bin/man.cgi?query=pf.conf&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386
A++ Foxy
--
Laurent Cheylus <foxy@free.fr> OpenPGP ID 0x5B766EC2
On Sat, 27 Sep 2003 12:22:10 +0200, Cedric Blancher wrote:
Oui, par exemple, mais pas que. Netfilter est structurellement plus extensible que pf, ce qui le rend de facto plus versatile. Rien que le marquage des paquets (-j MARK) est une fonctionnalité d'une puissance considérable, surtout si on considère que cette marque peut être utilisée pour router et faire de la QoS.
Le tagging des paquets IP a été ajouté récemment à PF sur OpenBSD et sera disponible dans la prochaine version 3.4 (sortie 1er novembre).
Voir les mots-clés "tag" et "tagged" dans la syntaxe PF : manpage pf.conf dispo ici http://www.openbsd.org/cgi-bin/man.cgi?query=pf.conf&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386
