regles IPFW

Le Tue, 15 Mar 2005 08:47:39 +0000, patpro ~ Patrick Proniewski a
écrit :

je voudrais soumettre à votre sagacité un ensemble de règles IPFW. Voyez
vous des problèmes ou des améliorations à proposer ?

Si déjà on avait une idée de l'usage qui est réservé à la machine,
je pense que ça aiderait à commenter la qualité du ruleset :)


--
Quelqu'un peut me dire comment on fait pour creer un nouveaux groupe
Usenet? A qui faut-il s'adresse? Cela coute il de quoi?
-+- Moe in GNU - De quoi qu'est ce que ca coute-t-il combien ? -+-

In article <pan.2005.03.15.08.57.18.683298@cartel-securite.fr>,
Cedric Blancher <blancher@cartel-securite.fr> wrote:

Le Tue, 15 Mar 2005 08:47:39 +0000, patpro ~ Patrick Proniewski a
écrit :

je voudrais soumettre à votre sagacité un ensemble de règles IPFW. Voyez
vous des problèmes ou des améliorations à proposer ?

Si déjà on avait une idée de l'usage qui est réservé à la machine,
je pense que ça aiderait à commenter la qualité du ruleset :)

machine perso, branchée sur ADSL, et partageant l'accès entrant (en0)
sur l'interface en1. Elle dispose entre autre de serveurs httpd, sshd et
dns.


patpro

Bon, reprenons ... :)

In article <patpro-8B08ED.21461314032005@individual.net>,
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.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*

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

* pas d'anomalie ?

* est ce que les keep-state sont bien employés ou est ce que je dois en
mettre + ou - ? (machine perso, pas un firewall avec 3000 users derrière)

* est mieux de mettre "unreach port" ou "unreach host" ? (ou peut être
un autre unreach...)


merci !

patpro

patpro ~ Patrick Proniewski nous disait récement dans
fr.comp.securite <news:patpro-3736BF.09003716032005@individual.net>
:

Je connais mal IPFirewall et en plus je suis un peu rouillé, mais
voyons voir...

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.

00499 unreach port log tcp from any to any keep-state in

tu n'as pas plutôt la possibilité de renvoyer un RST ? Pour le TCP
c'est la méthode propre si je me souviens bien. Le /keep-state/ est de
trop ici.

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

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

Autant je comprends 600 et 610, mais pas les deux règles suivantes. Ca
donne l'impression que tu as copié un modèle sans le comprendre tout à
fait. Il n'y aurait pas aussi IPFilter sur ton Mac ? Ca au moins je
connais ;-)

* est ce que les keep-state sont bien employés ou est ce que je
dois en mettre + ou - ? (machine perso, pas un firewall avec 3000
users derrière)

Les /keep-state/ sont là pour permettre au filtre IP de gagner du
temps dans le filtrage, dès lors qu'une connexion[1] a été autorisée à
passer. Tu dois donc en mettre sur toute les règles autorisant la
connexion et tu ne dois pas en mettre sur les règles bloquantes.


[1]
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 ?

merci !

De rien.


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

In article <d19nkp.3vv3f4r.1@sc4x.org>,
Stephane Catteau <steph.nospam@sc4x.net> wrote:

Je connais mal IPFirewall et en plus je suis un peu rouillé, mais
voyons voir...

merci :)

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.

ok

00499 unreach port log tcp from any to any keep-state in

tu n'as pas plutôt la possibilité de renvoyer un RST ? Pour le TCP
c'est la méthode propre si je me souviens bien. Le /keep-state/ est de
trop ici.

j'ai plein de trucs à disposition, dont le reset, effectivement.

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

ip c'est tout : icmp/udp/tcp

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

Autant je comprends 600 et 610, mais pas les deux règles suivantes. Ca
donne l'impression que tu as copié un modèle sans le comprendre tout à
fait. Il n'y aurait pas aussi IPFilter sur ton Mac ? Ca au moins je
connais ;-)

en réalité, la 1000 est la derniere de mon jeu de regle, mais IPFW est
en default to allow, donc il ajoute a la fin la 65535.
Pour le reste, c'est pas si simple, en fait c'est un script de ma
fabrication qui crée le ruleset, et je pense qu'il manque un peu de
tunning. A la fin j'ai ça :

if [ "${NAT:=-NO-}" = "-YES-" ]; then
${IPFW} add 00600 divert natd ip from any to any out via ${ETHERNET}
${IPFW} add 00610 allow ip from any to any
fi
${IPFW} add 01000 deny log ip from any to any

dejà, je devrais passer IPFW en deny all par défaut, comme ça je peux
faire sauter la 01000, ensuite la 00610 est la surement parce qu'elle
est dans la trame dont je me suis inspiré.

http://freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-ipfw.html

Non, il n'y a pas ipfilter, ni même IPFW2 sur MacOS X. J'espere qu'IPFW2
arrivera avec Tiger.

* est ce que les keep-state sont bien employés ou est ce que je
dois en mettre + ou - ? (machine perso, pas un firewall avec 3000
users derrière)

Les /keep-state/ sont là pour permettre au filtre IP de gagner du
temps dans le filtrage, dès lors qu'une connexion[1] a été autorisée à
passer. Tu dois donc en mettre sur toute les règles autorisant la
connexion et tu ne dois pas en mettre sur les règles bloquantes.

ok, je pensais que je pouvais aussi accélérer les rejets comme ça, mais
effectivement à y regarder de plus prêt c'est pas vraiment possible ;)


merci,

patpro

patpro ~ Patrick Proniewski nous disait récement dans
fr.comp.securite <news:patpro-68CF84.17083716032005@individual.net>
:

Stephane Catteau <steph.nospam@sc4x.net> wrote:

00499 unreach port log tcp from any to any keep-state in
tu n'as pas plutôt la possibilité de renvoyer un RST ? Pour le

TCP c'est la méthode propre si je me souviens bien. [...]

j'ai plein de trucs à disposition, dont le reset, effectivement.

Donc sauf avis contraire, met un reset à cet endroit là.

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

ip c'est tout : icmp/udp/tcp

Mais comme les paquets TCP sont au pire ejectés par la règle
précédente, seuls les paquets UDP et les messages ICMP qui ont pu
arriver jusque là seront pris en compte. D'où mon commentaire.


[Snip]

dejà, je devrais passer IPFW en deny all par défaut,

Ce qui aurait dû être fait dès le départ. Un filtre IP doit ouvrir des
ports et non les fermer.

comme ça je peux faire sauter la 01000, [...]

Oui aussi.

Non, il n'y a pas ipfilter, ni même IPFW2 sur MacOS X. J'espere
qu'IPFW2 arrivera avec Tiger.

Quitte à espérer un autre filtre IP, c'est pour PacketFilter qu'il
faut croiser les doigts ;-)


[Keep-state]

ok, je pensais que je pouvais aussi accélérer les rejets comme ça,
mais effectivement à y regarder de plus prêt c'est pas vraiment
possible ;)

Disons que c'est possible mais inutile et qui plus est, ce serait
dangereux. Autant il est difficile de saturer la pile d'état avec les
connexions autorisées à passer, parce que le serveur situé derrière
saturera avant, autant il est facile de le faire sur un port fermé. Un
petit flood sur ce port, boum la table d'état et bonjour, au choix, la
faille ou le DoS. En prime, on peut mettre ce que l'on veut comme
adresse IP source, puisqu'il n'y a pas besoin de traiter les réponses.

merci,

De rien.


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

In article <d19sdh.3vv4usp.1@sc4x.org>,
Stephane Catteau <steph.nospam@sc4x.net> wrote:

00499 unreach port log tcp from any to any keep-state in
Donc sauf avis contraire, met un reset à cet endroit là.

ok, je m'y colle

ip c'est tout : icmp/udp/tcp

Mais comme les paquets TCP sont au pire ejectés par la règle
précédente, seuls les paquets UDP et les messages ICMP qui ont pu
arriver jusque là seront pris en compte. D'où mon commentaire.

ha oui, ok.

[Snip]

dejà, je devrais passer IPFW en deny all par défaut,

Ce qui aurait dû être fait dès le départ. Un filtre IP doit ouvrir des
ports et non les fermer.

ôh pôvre macounet... :)

Non, il n'y a pas ipfilter, ni même IPFW2 sur MacOS X. J'espere
qu'IPFW2 arrivera avec Tiger.

Quitte à espérer un autre filtre IP, c'est pour PacketFilter qu'il
faut croiser les doigts ;-)

ben MacOS X suit à peut prêt FreeBSD, donc ce sera IPFW2 si tout se
passe bien.
Je ne connais Packet Filter que de nom, mais je doute qu'il soit un jour
inclus à MacOS X.

[Keep-state]

ok, je pensais que je pouvais aussi accélérer les rejets comme ça,
mais effectivement à y regarder de plus prêt c'est pas vraiment
possible ;)

Disons que c'est possible mais inutile et qui plus est, ce serait
dangereux. Autant il est difficile de saturer la pile d'état avec les
connexions autorisées à passer, parce que le serveur situé derrière
saturera avant, autant il est facile de le faire sur un port fermé. Un
petit flood sur ce port, boum la table d'état et bonjour, au choix, la
faille ou le DoS. En prime, on peut mettre ce que l'on veut comme
adresse IP source, puisqu'il n'y a pas besoin de traiter les réponses.

oui, j'avais bien pensé à la saturation de la table, mais sans en faire
grand cas.
Je vais nettoyer ça !

Merci pour tes conseils en tout cas.

patpro

In article <d19sdh.3vv4usp.1@sc4x.org>,
Stephane Catteau <steph.nospam@sc4x.net> wrote:

[Snip]

dejà, je devrais passer IPFW en deny all par défaut,

Ce qui aurait dû être fait dès le départ. Un filtre IP doit ouvrir des
ports et non les fermer.

en fait non, c'est dans le kernel et y a pas de sysctl qui va bien pour
changer ce comportement.

patpro

[XPost fr.comp.securite & fr.comp.os.mac-os.x]
patpro ~ Patrick Proniewski nous disait récement dans
fr.comp.securite <news:patpro-6C64CA.19410316032005@individual.net> :

[IPFirewall en deny all par défaut]

en fait non, c'est dans le kernel et y a pas de sysctl qui va bien
pour changer ce comportement.

Il ne te reste donc que la recompilation du kernel, sur *BSD c'est
trivial, je ne sais pas ce que cela donne avec MacOS X.


Fu2 (suivi de la discussion sur) fr.comp.os.mac-os.x
--
"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-12227F.19023816032005@individual.net> :

Stephane Catteau <steph.nospam@sc4x.net> wrote:

Quitte à espérer un autre filtre IP, c'est pour PacketFilter
qu'il faut croiser les doigts ;-)

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

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.

Disons que c'est possible mais inutile et qui plus est, ce
serait dangereux. [...]

oui, j'avais bien pensé à la saturation de la table, mais sans en
faire grand cas.

En soit tu avais raison, un filtre IP sérieux doit tout simplement
oublier le /keep-state/ (ou équivalent) pour les dény. Mais personne
n'étant à l'abris d'une étourderie, il peut arriver que le filtre en
tienne compte, donc autant prendre les devants en évitant de tenter
Murphy.

Merci pour tes conseils en tout cas.

De rien, au contraire même, ça me force à me dérouiller un peu ;-)


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