je voudrais soumettre à votre sagacité un ensemble de règles IPFW. Voyez
vous des problèmes ou des améliorations à proposer ?
00002 allow ip from any to any via en1
00003 allow ip from any to any via fw0
00004 allow ip from any to any via lo*
00010 divert 8668 ip from any to any in recv en0
00011 check-state
00200 skipto 600 ip from any to any keep-state out xmit en0
00300 deny ip from 192.168.0.0/16 to any in recv en0
00301 deny ip from 172.16.0.0/12 to any in recv en0
00302 deny ip from 10.0.0.0/8 to any in recv en0
00303 deny ip from 127.0.0.0/8 to any in recv en0
00304 deny ip from 0.0.0.0/8 to any in recv en0
00305 deny ip from 169.254.0.0/16 to any in recv en0
00306 deny ip from 192.0.2.0/24 to any in recv en0
00307 deny ip from 204.152.64.0/23 to any in recv en0
00308 deny ip from 224.0.0.0/3 to any in recv en0
00400 allow tcp from any to any 5014 keep-state in
00410 allow tcp from any to any 22 keep-state in
00420 allow tcp from 62.4.23.42 to any 113 keep-state in
00430 allow tcp from any to any 53 keep-state in
00440 allow udp from any to any 53 keep-state in
00450 allow tcp from any to any 80 keep-state in
00499 unreach port log tcp from any to any keep-state in
00500 deny log ip from any to any
00600 divert 8668 ip from any to any out xmit en0
00610 allow ip from any to any
01000 deny log ip from any to any
65535 allow ip from any to any
ben MacOS X suit à peut prêt FreeBSD, donc ce sera IPFW2 si tout se passe bien.
Oui mais non, s'il suivait vraiment FreeBSD, il proposerait IPFirewall, IPFirewall2, IPFilter et PacketFilter, puisque les quatres sont disponnibles sous FreeBSD. Il me semble d'ailleurs que c'est le seul OS à proposer ainsi quatre des cinq meilleurs filtres IP. Et puis ça va encore faire jaser vu qu'il y a plus de NetBSD et OpenBSD dans MacOS X qu'il n'y a de FreeBSD ;-)
historiquement c'est IPFW je pense, et seuls IPFW et IPFilter ont leur place dans le kernel (more /usr/src/sys/i386/conf/LINT sur une 4.10 qui passait par là)
Je ne connais Packet Filter que de nom, mais je doute qu'il soit un jour inclus à MacOS X.
C'est dommage parce qu'il n'y a rien de mieux pour l'instant. Cela dit, MacOS X est plus orienté poste de travail que serveur, donc ce n'est pas si pénalisant que cela.
voila
Merci pour tes conseils en tout cas.
De rien, au contraire même, ça me force à me dérouiller un peu ;-)
héhé ;)
patpro
In article <d1a4pf.3vv4n99.1@sc4x.org>,
Stephane Catteau <steph.nospam@sc4x.net> wrote:
ben MacOS X suit à peut prêt FreeBSD, donc ce sera IPFW2 si tout
se passe bien.
Oui mais non, s'il suivait vraiment FreeBSD, il proposerait
IPFirewall, IPFirewall2, IPFilter et PacketFilter, puisque les quatres
sont disponnibles sous FreeBSD. Il me semble d'ailleurs que c'est le
seul OS à proposer ainsi quatre des cinq meilleurs filtres IP.
Et puis ça va encore faire jaser vu qu'il y a plus de NetBSD et
OpenBSD dans MacOS X qu'il n'y a de FreeBSD ;-)
historiquement c'est IPFW je pense, et seuls IPFW et IPFilter ont leur
place dans le kernel (more /usr/src/sys/i386/conf/LINT sur une 4.10 qui
passait par là)
Je ne connais Packet Filter que de nom, mais je doute qu'il soit
un jour inclus à MacOS X.
C'est dommage parce qu'il n'y a rien de mieux pour l'instant. Cela
dit, MacOS X est plus orienté poste de travail que serveur, donc ce
n'est pas si pénalisant que cela.
voila
Merci pour tes conseils en tout cas.
De rien, au contraire même, ça me force à me dérouiller un peu ;-)
ben MacOS X suit à peut prêt FreeBSD, donc ce sera IPFW2 si tout se passe bien.
Oui mais non, s'il suivait vraiment FreeBSD, il proposerait IPFirewall, IPFirewall2, IPFilter et PacketFilter, puisque les quatres sont disponnibles sous FreeBSD. Il me semble d'ailleurs que c'est le seul OS à proposer ainsi quatre des cinq meilleurs filtres IP. Et puis ça va encore faire jaser vu qu'il y a plus de NetBSD et OpenBSD dans MacOS X qu'il n'y a de FreeBSD ;-)
historiquement c'est IPFW je pense, et seuls IPFW et IPFilter ont leur place dans le kernel (more /usr/src/sys/i386/conf/LINT sur une 4.10 qui passait par là)
Je ne connais Packet Filter que de nom, mais je doute qu'il soit un jour inclus à MacOS X.
C'est dommage parce qu'il n'y a rien de mieux pour l'instant. Cela dit, MacOS X est plus orienté poste de travail que serveur, donc ce n'est pas si pénalisant que cela.
voila
Merci pour tes conseils en tout cas.
De rien, au contraire même, ça me force à me dérouiller un peu ;-)
héhé ;)
patpro
patpro ~ patrick proniewski
In article , Stephane Catteau wrote:
00002 allow ip from any to any via en1 00003 allow ip from any to any via fw0 00004 allow ip from any to any via lo*
Tu gagneras à mettre un /keep-state/ sur celles-ci aussi.
en fait non, ça casse le nat :) si je mets des keep-state, les machines derrières ne peuvent plus sortir, de plus le keepstate sur lo* ça fait exploser(*) la table de rêgles temporaires avec tous les démons qui se parlent sur localhost.
patpro
(* ok j'exagère)
In article <d19nkp.3vv3f4r.1@sc4x.org>,
Stephane Catteau <steph.nospam@sc4x.net> wrote:
00002 allow ip from any to any via en1
00003 allow ip from any to any via fw0
00004 allow ip from any to any via lo*
Tu gagneras à mettre un /keep-state/ sur celles-ci aussi.
en fait non, ça casse le nat :)
si je mets des keep-state, les machines derrières ne peuvent plus
sortir, de plus le keepstate sur lo* ça fait exploser(*) la table de
rêgles temporaires avec tous les démons qui se parlent sur localhost.
00002 allow ip from any to any via en1 00003 allow ip from any to any via fw0 00004 allow ip from any to any via lo*
Tu gagneras à mettre un /keep-state/ sur celles-ci aussi.
en fait non, ça casse le nat :) si je mets des keep-state, les machines derrières ne peuvent plus sortir, de plus le keepstate sur lo* ça fait exploser(*) la table de rêgles temporaires avec tous les démons qui se parlent sur localhost.
patpro
(* ok j'exagère)
Stephane Catteau
patpro ~ patrick proniewski nous disait récement dans fr.comp.securite <news: :
Stephane Catteau wrote:
00002 allow ip from any to any via en1 00003 allow ip from any to any via fw0 00004 allow ip from any to any via lo* Tu gagneras à mettre un /keep-state/ sur celles-ci aussi.
en fait non, ça casse le nat :) si je mets des keep-state, les machines derrières ne peuvent plus sortir,
Surprenant :-/ Enfin, IPFW n'est pas IPF, donc c'est peut-être normal.
de plus le keepstate sur lo* ça fait exploser(*) la table de rêgles temporaires avec tous les démons qui se parlent sur localhost.
Exact, je n'avais pas pensé à ça, m'apprendra à avoir une passerelle filtrante qui ne fait rien tourner à par OpenSSH, je n'ai jamais eu ce genre de problèmes.
-- "En amour, on plaît plutôt par d'agréables défauts que par des qualités essentielles ; les grandes vertus sont des pièces d'or, dont on fait moins usage que de la monnaie" Ninon de Lenclos
patpro ~ patrick proniewski nous disait récement dans fr.comp.securite
<news:patpro-B0BDA2.21404516032005@individual.net> :
Stephane Catteau <steph.nospam@sc4x.net> wrote:
00002 allow ip from any to any via en1
00003 allow ip from any to any via fw0
00004 allow ip from any to any via lo*
Tu gagneras à mettre un /keep-state/ sur celles-ci aussi.
en fait non, ça casse le nat :)
si je mets des keep-state, les machines derrières ne peuvent plus
sortir,
Surprenant :-/ Enfin, IPFW n'est pas IPF, donc c'est peut-être normal.
de plus le keepstate sur lo* ça fait exploser(*) la table de
rêgles temporaires avec tous les démons qui se parlent sur localhost.
Exact, je n'avais pas pensé à ça, m'apprendra à avoir une passerelle
filtrante qui ne fait rien tourner à par OpenSSH, je n'ai jamais eu ce
genre de problèmes.
--
"En amour, on plaît plutôt par d'agréables défauts que par des qualités
essentielles ; les grandes vertus sont des pièces d'or, dont on fait
moins usage que de la monnaie"
Ninon de Lenclos
patpro ~ patrick proniewski nous disait récement dans fr.comp.securite <news: :
Stephane Catteau wrote:
00002 allow ip from any to any via en1 00003 allow ip from any to any via fw0 00004 allow ip from any to any via lo* Tu gagneras à mettre un /keep-state/ sur celles-ci aussi.
en fait non, ça casse le nat :) si je mets des keep-state, les machines derrières ne peuvent plus sortir,
Surprenant :-/ Enfin, IPFW n'est pas IPF, donc c'est peut-être normal.
de plus le keepstate sur lo* ça fait exploser(*) la table de rêgles temporaires avec tous les démons qui se parlent sur localhost.
Exact, je n'avais pas pensé à ça, m'apprendra à avoir une passerelle filtrante qui ne fait rien tourner à par OpenSSH, je n'ai jamais eu ce genre de problèmes.
-- "En amour, on plaît plutôt par d'agréables défauts que par des qualités essentielles ; les grandes vertus sont des pièces d'or, dont on fait moins usage que de la monnaie" Ninon de Lenclos
Stephane Catteau
patpro ~ Patrick Proniewski nous disait récement dans fr.comp.securite <news: :
historiquement c'est IPFW je pense,
Oui, c'est le filtre IP de FreeBSD, tout comme PacketFilter peut être considéré comme celui d'OpenBSD.
et seuls IPFW et IPFilter ont leur place dans le kernel (more /usr/src/sys/i386/conf/LINT sur une 4.10 qui passait par là)
J'avoue ne pas avoir encore pris le temps de regarder ça de prêt, je sais que le portage de PacketFilter est maintenant aussi parfait qu'il puisse l'être, mais je n'ai aucune idée de la façon dont il a été effectué.
-- "En amour, on plaît plutôt par d'agréables défauts que par des qualités essentielles ; les grandes vertus sont des pièces d'or, dont on fait moins usage que de la monnaie" Ninon de Lenclos
patpro ~ Patrick Proniewski nous disait récement dans
fr.comp.securite <news:patpro-33F382.21084716032005@individual.net> :
historiquement c'est IPFW je pense,
Oui, c'est le filtre IP de FreeBSD, tout comme PacketFilter peut être
considéré comme celui d'OpenBSD.
et seuls IPFW et IPFilter ont leur place dans le kernel (more
/usr/src/sys/i386/conf/LINT sur une 4.10 qui passait par là)
J'avoue ne pas avoir encore pris le temps de regarder ça de prêt, je
sais que le portage de PacketFilter est maintenant aussi parfait qu'il
puisse l'être, mais je n'ai aucune idée de la façon dont il a été
effectué.
--
"En amour, on plaît plutôt par d'agréables défauts que par des qualités
essentielles ; les grandes vertus sont des pièces d'or, dont on fait
moins usage que de la monnaie"
Ninon de Lenclos
patpro ~ Patrick Proniewski nous disait récement dans fr.comp.securite <news: :
historiquement c'est IPFW je pense,
Oui, c'est le filtre IP de FreeBSD, tout comme PacketFilter peut être considéré comme celui d'OpenBSD.
et seuls IPFW et IPFilter ont leur place dans le kernel (more /usr/src/sys/i386/conf/LINT sur une 4.10 qui passait par là)
J'avoue ne pas avoir encore pris le temps de regarder ça de prêt, je sais que le portage de PacketFilter est maintenant aussi parfait qu'il puisse l'être, mais je n'ai aucune idée de la façon dont il a été effectué.
-- "En amour, on plaît plutôt par d'agréables défauts que par des qualités essentielles ; les grandes vertus sont des pièces d'or, dont on fait moins usage que de la monnaie" Ninon de Lenclos
Adrien Huvier
Stephane Catteau wrote in news::
patpro ~ Patrick Proniewski nous disait récement dans fr.comp.securite <news: :
00500 deny log ip from any to any
Je suppose que c'est l'équivalent pour UDP/ICMP. C'est là que tu dois mettre le /unreach port/.
Pour UDP uniquement, non ? Si les deux machines se renvoient un port unreachable à chaque ICMP reçu, bonjour la partie de ping pong...
-- Adrien Huvier
Stephane Catteau <steph.nospam@sc4x.net> wrote in
news:d19nkp.3vv3f4r.1@sc4x.org:
patpro ~ Patrick Proniewski nous disait récement dans
fr.comp.securite <news:patpro-3736BF.09003716032005@individual.net> :
00500 deny log ip from any to any
Je suppose que c'est l'équivalent pour UDP/ICMP. C'est là que tu
dois mettre le /unreach port/.
Pour UDP uniquement, non ? Si les deux machines se renvoient un port
unreachable à chaque ICMP reçu, bonjour la partie de ping pong...
Le Thu, 17 Mar 2005 17:28:30 +0000, Adrien Huvier a écrit :
Pour UDP uniquement, non ? Si les deux machines se renvoient un port unreachable à chaque ICMP reçu, bonjour la partie de ping pong...
Ceci dit en passant, un Port Unreachable en réponse à un ICMP, ça fait un peu non-sens tout de même...
--
Bah lire les mails des users pour la prévention, Ça ne sait fait pas pour des raisons 1) de déontologie 2) de règlementation.
Le manque de temps, aussi :-)
-+- MB in Guide du Fmblien Assassin : "Ah, si j'avais le temps..." -+-
Adrien Huvier
Cedric Blancher wrote in news::
Ceci dit en passant, un Port Unreachable en réponse à un ICMP, ça fait un peu non-sens tout de même...
Clair, mais on aurait pu vouloir renvoyer "protocol unreachable" (si j'ai bien compris l'utilité de ce message-là, vu qu'il n'est pas trop décrit par la RFC 792)...
-- Adrien Huvier
Cedric Blancher <blancher@cartel-securite.fr> wrote in
news:pan.2005.03.17.17.29.36.11386@cartel-securite.fr:
Ceci dit en passant, un Port Unreachable en réponse à un ICMP, ça
fait un peu non-sens tout de même...
Clair, mais on aurait pu vouloir renvoyer "protocol unreachable" (si
j'ai bien compris l'utilité de ce message-là, vu qu'il n'est pas trop
décrit par la RFC 792)...
Ceci dit en passant, un Port Unreachable en réponse à un ICMP, ça fait un peu non-sens tout de même...
Clair, mais on aurait pu vouloir renvoyer "protocol unreachable" (si j'ai bien compris l'utilité de ce message-là, vu qu'il n'est pas trop décrit par la RFC 792)...
-- Adrien Huvier
Cedric Blancher
Le Thu, 17 Mar 2005 18:12:25 +0000, Adrien Huvier a écrit :
Clair, mais on aurait pu vouloir renvoyer "protocol unreachable"
Cela voudrait dire que tu ne supportes pas l'ICMP :))))
--
C'est décidément trop compliqué de rediriger vers les bons groupes :o( Facile, tu rediriges vers fr.comp.erwan.david. :))
-+- QL in Guide du Fmblien Assassin : "Et toc !" -+-
Le Thu, 17 Mar 2005 18:12:25 +0000, Adrien Huvier a écrit :
Clair, mais on aurait pu vouloir renvoyer "protocol unreachable"
Cela voudrait dire que tu ne supportes pas l'ICMP :))))
--
C'est décidément trop compliqué de rediriger vers les bons groupes :o(
Facile, tu rediriges vers fr.comp.erwan.david. :))
-+- QL in Guide du Fmblien Assassin : "Et toc !" -+-
Le Thu, 17 Mar 2005 18:12:25 +0000, Adrien Huvier a écrit :
Clair, mais on aurait pu vouloir renvoyer "protocol unreachable"
Cela voudrait dire que tu ne supportes pas l'ICMP :))))
--
C'est décidément trop compliqué de rediriger vers les bons groupes :o( Facile, tu rediriges vers fr.comp.erwan.david. :))
-+- QL in Guide du Fmblien Assassin : "Et toc !" -+-
Cedric Blancher
Le Thu, 17 Mar 2005 21:37:04 +0000, Patrick Lamaiziere a écrit :
J'ai des doutes sur le temps de filtrage avec les keep-states. Si ça peut faire gagner du temps sur les connexions établies, ça va pénaliser les non établies. Les règles dynamiques sont vérifiées lors du check-state, ou lors de la première règle contenant "limit" ou "keep-state".
Sauf qu'une grosse majorité des paquets échangés tombent justement dans la catégorie "établie". Ce document date, mais en fournit une bonne illustration :
http://www.benzedrine.cx/pf-paper.html
Conclusion :
The benchmarks show that the lower cost of state table lookups compared to the high cost of rule set evaluations justify creating state for performance reasons. Stateful filtering not only improves the quality of the filter decisions, it effectively improves filtering performance.
Ce qui en français donne grosso modo :
Le benchmark montre que le coût moindre des examens de la table d'états comparé au fort coût d'une évaluation de règles justifie l'utilisation des états pour des besoins de performance. Le filtrage à état améliore non seulement la qualité des décisions de filtrage, mais il améliore clairement les performances de filtrage.
-- BOFH excuse #361:
Communist revolutionaries taking over the server room and demanding all the computers in the building or they shoot the sysadmin. Poor misguided fools.
Le Thu, 17 Mar 2005 21:37:04 +0000, Patrick Lamaiziere a écrit :
J'ai des doutes sur le temps de filtrage avec les keep-states. Si ça
peut faire gagner du temps sur les connexions établies, ça va pénaliser
les non établies. Les règles dynamiques sont vérifiées lors du
check-state, ou lors de la première règle contenant "limit" ou
"keep-state".
Sauf qu'une grosse majorité des paquets échangés tombent justement dans
la catégorie "établie". Ce document date, mais en fournit une bonne
illustration :
http://www.benzedrine.cx/pf-paper.html
Conclusion :
The benchmarks show that the lower cost of state table lookups compared
to the high cost of rule set evaluations justify creating state for
performance reasons. Stateful filtering not only improves the quality of
the filter decisions, it effectively improves filtering performance.
Ce qui en français donne grosso modo :
Le benchmark montre que le coût moindre des examens de la table d'états
comparé au fort coût d'une évaluation de règles justifie
l'utilisation des états pour des besoins de performance. Le filtrage à
état améliore non seulement la qualité des décisions de filtrage,
mais il améliore clairement les performances de filtrage.
--
BOFH excuse #361:
Communist revolutionaries taking over the server room and demanding all the
computers in the building or they shoot the sysadmin. Poor misguided fools.
Le Thu, 17 Mar 2005 21:37:04 +0000, Patrick Lamaiziere a écrit :
J'ai des doutes sur le temps de filtrage avec les keep-states. Si ça peut faire gagner du temps sur les connexions établies, ça va pénaliser les non établies. Les règles dynamiques sont vérifiées lors du check-state, ou lors de la première règle contenant "limit" ou "keep-state".
Sauf qu'une grosse majorité des paquets échangés tombent justement dans la catégorie "établie". Ce document date, mais en fournit une bonne illustration :
http://www.benzedrine.cx/pf-paper.html
Conclusion :
The benchmarks show that the lower cost of state table lookups compared to the high cost of rule set evaluations justify creating state for performance reasons. Stateful filtering not only improves the quality of the filter decisions, it effectively improves filtering performance.
Ce qui en français donne grosso modo :
Le benchmark montre que le coût moindre des examens de la table d'états comparé au fort coût d'une évaluation de règles justifie l'utilisation des états pour des besoins de performance. Le filtrage à état améliore non seulement la qualité des décisions de filtrage, mais il améliore clairement les performances de filtrage.
-- BOFH excuse #361:
Communist revolutionaries taking over the server room and demanding all the computers in the building or they shoot the sysadmin. Poor misguided fools.
Cedric Blancher
Le Wed, 16 Mar 2005 15:43:11 +0000, Stephane Catteau a écrit :
A prendre au sens large puisque la notion de connexion n'existe pas pour UDP et ICMP, alors que le filtre IP arrive à la simuler pour en garder l'état. D'ailleurs à ce propos, est-ce vraiment fiable ça ?
Les notions d'état et de connexion dont deux choses très différentes et la confusion découle de l'abus d'usage du mot connexion.
La notion d'état existe pour UDP comme pour ICMP. Le filtre IP le gère exactement comme une pile IP normale traite ce type de paquets. Pour UDP, on utilise des timers, et pour ICMP, on utilise des mécanismes analogues pour les questions/réponses (ping par exemple) et la recherche d'état par examen de la citation ICMP pour les erreurs.
Bref, rien de magique là dedans, et c'est fiable, dans la mesure où ça fonctionne comme une pile IP normale.
-- BOFH excuse #276:
U.S. Postal Service
Le Wed, 16 Mar 2005 15:43:11 +0000, Stephane Catteau a écrit :
A prendre au sens large puisque la notion de connexion n'existe pas
pour UDP et ICMP, alors que le filtre IP arrive à la simuler pour en
garder l'état.
D'ailleurs à ce propos, est-ce vraiment fiable ça ?
Les notions d'état et de connexion dont deux choses très différentes et
la confusion découle de l'abus d'usage du mot connexion.
La notion d'état existe pour UDP comme pour ICMP. Le filtre IP le gère
exactement comme une pile IP normale traite ce type de paquets. Pour UDP,
on utilise des timers, et pour ICMP, on utilise des mécanismes analogues
pour les questions/réponses (ping par exemple) et la recherche d'état
par examen de la citation ICMP pour les erreurs.
Bref, rien de magique là dedans, et c'est fiable, dans la mesure où ça
fonctionne comme une pile IP normale.
Le Wed, 16 Mar 2005 15:43:11 +0000, Stephane Catteau a écrit :
A prendre au sens large puisque la notion de connexion n'existe pas pour UDP et ICMP, alors que le filtre IP arrive à la simuler pour en garder l'état. D'ailleurs à ce propos, est-ce vraiment fiable ça ?
Les notions d'état et de connexion dont deux choses très différentes et la confusion découle de l'abus d'usage du mot connexion.
La notion d'état existe pour UDP comme pour ICMP. Le filtre IP le gère exactement comme une pile IP normale traite ce type de paquets. Pour UDP, on utilise des timers, et pour ICMP, on utilise des mécanismes analogues pour les questions/réponses (ping par exemple) et la recherche d'état par examen de la citation ICMP pour les erreurs.
Bref, rien de magique là dedans, et c'est fiable, dans la mesure où ça fonctionne comme une pile IP normale.
