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
Cedric Blancher nous disait récement dans fr.comp.securite <news: :
Bref, rien de magique là dedans, et c'est fiable, dans la mesure où ça fonctionne comme une pile IP normale.
Vip, en fait, mon doute était une connerie...
J'étais parti sur le fonctionnement pour TCP, et la possibilité éventuelle de se glisser dans la connexion pour envoyer des données corrompues à partir d'une adresse forcément spoofée. Mais comme cela nécessiterait d'arriver à prédire le numéro de séquence, j'ai glissé sur la même possibilité en UDP, qui lui permettrait ce type d'insertion au sein d'un flux valide. Seulement j'ai oublié un détail, puisqu'il n'y a pas de connexion en UDP, il suffit tout simplement d'envoyer le paquet... S'il correspond à une entrée de la table d'état, il correspondra aussi obligatoirement à une règle autorisant le passage.
-- "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
Cedric Blancher nous disait récement dans fr.comp.securite
<news:pan.2005.03.17.21.47.03.736819@cartel-securite.fr> :
Bref, rien de magique là dedans, et c'est fiable, dans la mesure
où ça fonctionne comme une pile IP normale.
Vip, en fait, mon doute était une connerie...
J'étais parti sur le fonctionnement pour TCP, et la possibilité
éventuelle de se glisser dans la connexion pour envoyer des données
corrompues à partir d'une adresse forcément spoofée. Mais comme cela
nécessiterait d'arriver à prédire le numéro de séquence, j'ai glissé
sur la même possibilité en UDP, qui lui permettrait ce type d'insertion
au sein d'un flux valide.
Seulement j'ai oublié un détail, puisqu'il n'y a pas de connexion en
UDP, il suffit tout simplement d'envoyer le paquet... S'il correspond à
une entrée de la table d'état, il correspondra aussi obligatoirement à
une règle autorisant le passage.
--
"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
Cedric Blancher nous disait récement dans fr.comp.securite <news: :
Bref, rien de magique là dedans, et c'est fiable, dans la mesure où ça fonctionne comme une pile IP normale.
Vip, en fait, mon doute était une connerie...
J'étais parti sur le fonctionnement pour TCP, et la possibilité éventuelle de se glisser dans la connexion pour envoyer des données corrompues à partir d'une adresse forcément spoofée. Mais comme cela nécessiterait d'arriver à prédire le numéro de séquence, j'ai glissé sur la même possibilité en UDP, qui lui permettrait ce type d'insertion au sein d'un flux valide. Seulement j'ai oublié un détail, puisqu'il n'y a pas de connexion en UDP, il suffit tout simplement d'envoyer le paquet... S'il correspond à une entrée de la table d'état, il correspondra aussi obligatoirement à une règle autorisant le passage.
-- "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
Cedric Blancher nous disait récement dans fr.comp.securite <news: :
Ceci dit en passant, un Port Unreachable en réponse à un ICMP, ça fait un peu non-sens tout de même...
Je suis parfois bourin dans mon genre, et me met à suivre les docs sérieuses[1] sans chercher à réfléchir. Surtout lorsque ça m'obligerait à faire chauffer le dico d'anglais ;-) Mais bon Adrien et toi avez raison, c'est une abération.
[1] Ici l'IPFilter How-To, qui lui-même renvoi au "TCP/IP Illustrated" de Stevens. -- "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
Cedric Blancher nous disait récement dans fr.comp.securite
<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...
Je suis parfois bourin dans mon genre, et me met à suivre les docs
sérieuses[1] sans chercher à réfléchir. Surtout lorsque ça m'obligerait
à faire chauffer le dico d'anglais ;-)
Mais bon Adrien et toi avez raison, c'est une abération.
[1]
Ici l'IPFilter How-To, qui lui-même renvoi au "TCP/IP Illustrated" de
Stevens.
--
"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
Cedric Blancher nous disait récement dans fr.comp.securite <news: :
Ceci dit en passant, un Port Unreachable en réponse à un ICMP, ça fait un peu non-sens tout de même...
Je suis parfois bourin dans mon genre, et me met à suivre les docs sérieuses[1] sans chercher à réfléchir. Surtout lorsque ça m'obligerait à faire chauffer le dico d'anglais ;-) Mais bon Adrien et toi avez raison, c'est une abération.
[1] Ici l'IPFilter How-To, qui lui-même renvoi au "TCP/IP Illustrated" de Stevens. -- "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
Patrick Lamaiziere nous disait récement dans fr.comp.securite <news: :
Stephane Catteau écrivait :
Il faudrait ausi savoir comment sont faites les règles dynamiques. S'il y a une règle avec l'adresse IP destination/port IP source/port pour chaque connexion établie (comme le suggère la page de man); ça va même pénaliser puisque qu'il va falloir qu'il examine un certain nombre de règles dynamiques avant de tomber sur la bonne. Alors qu'avec les règles statiques c'est bien déterminé.
Oui mais non, parce que tu oublies qu'une règle, toute optimisée qu'elle puisse être une fois en mémoire, doit être interprétée, alors qu'avec la table d'état il suffit d'une série de comparaisons binaire.
Dans la mesure où une adresse IP est valide de 0.0.0.0 à 255.255.255.255, il n'est pas possible de définir une adresse bidon à laquelle on attribuerait la valeur /any/. De même, un filtrage sur 192.168.2.0/24 ne peut pas s'écrire, en mémoire, 192.168.2.0 (définissant ainsi 0 comme "tout accepter"), car il y aurait confusion avec l'adresse IP elle-même. Le problème est le même pour le port et le protocole. A l'inverse, la table d'état présente l'avantage de ne concerner qu'une seule connexion, et donc une seule adresse IP source, une seule adresse IP destination, un seul protocole et un seul port de destination. Du coup, en assembleur x86 vite fait et en considérant qu'il n'y a que ces quatres critères à prendre en compte, ce qui n'est pas tout à fait exact, le filtrage à partir de la table d'état ressemblerait à ceci :
mov EDX, emplacement du /protocole/ dans l'en-tête du paquet mov ECX, nombre d'entrée dans la table d'état mov EDI, première entrée de la table d'état @loop: push EDX mov AL, [EDI] cmp [EDX], AL jnz next [pas le bon protocole] add EDX, 3 [pointer sur l'adresse IP source] inc EDI [idem] mov EAX, [EDI] cmp [EDX], EAX jnz next [pas la bonne adresse IP source] add EDX, 4 [pointer sur l'adresse IP destination] add EDI, 4 [idem] mov EAX, [EDI] cmp [EDX], EAX jnz next [pas la bonne adresse IP destination] add EDX, X [pointer sur le port de destination] add EDI, 4 [idem] mov AX, [EDI] cmp [EDX], AX jz go [tout correspond, on agit] @next: pop EDX dec ECX jnz loop [encore au moins une entrée dans la table] jmp Chercher dans les règles @go: pop EDX [faisont ça proprement ;-)] Laisser passer ou interdire
Crois-tu encore que, en ne tenant compte que des contraintes que j'ai citées plus haut, le contrôle des règles puisse être aussi rapide ? Sauf à considérer que la table d'état contienne plusieurs centaines d'entrées, la réponse est non. Et encore, une table d'état contenant plusieurs centaines d'entrées gère un gros réseau et le fichier de règles doit lui-même avoir un bon paquet de lignes.
-- "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
Patrick Lamaiziere nous disait récement dans fr.comp.securite
<news:XnsD4EDE179C3D17plam@nulle.invalid> :
Stephane Catteau écrivait :
Il faudrait ausi savoir comment sont faites les règles dynamiques.
S'il y a une règle avec l'adresse IP destination/port IP
source/port pour chaque connexion établie (comme le suggère la
page de man); ça va même pénaliser puisque qu'il va falloir qu'il
examine un certain nombre de règles dynamiques avant de tomber sur
la bonne. Alors qu'avec les règles statiques c'est bien déterminé.
Oui mais non, parce que tu oublies qu'une règle, toute optimisée
qu'elle puisse être une fois en mémoire, doit être interprétée, alors
qu'avec la table d'état il suffit d'une série de comparaisons binaire.
Dans la mesure où une adresse IP est valide de 0.0.0.0 à
255.255.255.255, il n'est pas possible de définir une adresse bidon à
laquelle on attribuerait la valeur /any/. De même, un filtrage sur
192.168.2.0/24 ne peut pas s'écrire, en mémoire, 192.168.2.0
(définissant ainsi 0 comme "tout accepter"), car il y aurait confusion
avec l'adresse IP elle-même. Le problème est le même pour le port et le
protocole.
A l'inverse, la table d'état présente l'avantage de ne concerner
qu'une seule connexion, et donc une seule adresse IP source, une seule
adresse IP destination, un seul protocole et un seul port de
destination. Du coup, en assembleur x86 vite fait et en considérant
qu'il n'y a que ces quatres critères à prendre en compte, ce qui n'est
pas tout à fait exact, le filtrage à partir de la table d'état
ressemblerait à ceci :
mov EDX, emplacement du /protocole/ dans l'en-tête du paquet
mov ECX, nombre d'entrée dans la table d'état
mov EDI, première entrée de la table d'état
@loop: push EDX
mov AL, [EDI]
cmp [EDX], AL
jnz next [pas le bon protocole]
add EDX, 3 [pointer sur l'adresse IP source]
inc EDI [idem]
mov EAX, [EDI]
cmp [EDX], EAX
jnz next [pas la bonne adresse IP source]
add EDX, 4 [pointer sur l'adresse IP destination]
add EDI, 4 [idem]
mov EAX, [EDI]
cmp [EDX], EAX
jnz next [pas la bonne adresse IP destination]
add EDX, X [pointer sur le port de destination]
add EDI, 4 [idem]
mov AX, [EDI]
cmp [EDX], AX
jz go [tout correspond, on agit]
@next: pop EDX
dec ECX
jnz loop [encore au moins une entrée dans la table]
jmp Chercher dans les règles
@go: pop EDX [faisont ça proprement ;-)]
Laisser passer ou interdire
Crois-tu encore que, en ne tenant compte que des contraintes que j'ai
citées plus haut, le contrôle des règles puisse être aussi rapide ?
Sauf à considérer que la table d'état contienne plusieurs centaines
d'entrées, la réponse est non. Et encore, une table d'état contenant
plusieurs centaines d'entrées gère un gros réseau et le fichier de
règles doit lui-même avoir un bon paquet de lignes.
--
"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
Patrick Lamaiziere nous disait récement dans fr.comp.securite <news: :
Stephane Catteau écrivait :
Il faudrait ausi savoir comment sont faites les règles dynamiques. S'il y a une règle avec l'adresse IP destination/port IP source/port pour chaque connexion établie (comme le suggère la page de man); ça va même pénaliser puisque qu'il va falloir qu'il examine un certain nombre de règles dynamiques avant de tomber sur la bonne. Alors qu'avec les règles statiques c'est bien déterminé.
Oui mais non, parce que tu oublies qu'une règle, toute optimisée qu'elle puisse être une fois en mémoire, doit être interprétée, alors qu'avec la table d'état il suffit d'une série de comparaisons binaire.
Dans la mesure où une adresse IP est valide de 0.0.0.0 à 255.255.255.255, il n'est pas possible de définir une adresse bidon à laquelle on attribuerait la valeur /any/. De même, un filtrage sur 192.168.2.0/24 ne peut pas s'écrire, en mémoire, 192.168.2.0 (définissant ainsi 0 comme "tout accepter"), car il y aurait confusion avec l'adresse IP elle-même. Le problème est le même pour le port et le protocole. A l'inverse, la table d'état présente l'avantage de ne concerner qu'une seule connexion, et donc une seule adresse IP source, une seule adresse IP destination, un seul protocole et un seul port de destination. Du coup, en assembleur x86 vite fait et en considérant qu'il n'y a que ces quatres critères à prendre en compte, ce qui n'est pas tout à fait exact, le filtrage à partir de la table d'état ressemblerait à ceci :
mov EDX, emplacement du /protocole/ dans l'en-tête du paquet mov ECX, nombre d'entrée dans la table d'état mov EDI, première entrée de la table d'état @loop: push EDX mov AL, [EDI] cmp [EDX], AL jnz next [pas le bon protocole] add EDX, 3 [pointer sur l'adresse IP source] inc EDI [idem] mov EAX, [EDI] cmp [EDX], EAX jnz next [pas la bonne adresse IP source] add EDX, 4 [pointer sur l'adresse IP destination] add EDI, 4 [idem] mov EAX, [EDI] cmp [EDX], EAX jnz next [pas la bonne adresse IP destination] add EDX, X [pointer sur le port de destination] add EDI, 4 [idem] mov AX, [EDI] cmp [EDX], AX jz go [tout correspond, on agit] @next: pop EDX dec ECX jnz loop [encore au moins une entrée dans la table] jmp Chercher dans les règles @go: pop EDX [faisont ça proprement ;-)] Laisser passer ou interdire
Crois-tu encore que, en ne tenant compte que des contraintes que j'ai citées plus haut, le contrôle des règles puisse être aussi rapide ? Sauf à considérer que la table d'état contienne plusieurs centaines d'entrées, la réponse est non. Et encore, une table d'état contenant plusieurs centaines d'entrées gère un gros réseau et le fichier de règles doit lui-même avoir un bon paquet de lignes.
-- "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
Eric Lalitte
"Adrien Huvier" wrote in message news:
Pour UDP uniquement, non ? Si les deux machines se renvoient un port unreachable à chaque ICMP reçu, bonjour la partie de ping pong...
Un message d'erreur ICMP ne peut pas générer de message d'erreur ICMP. Ceci notamment pour éviter la partie de ping-pong. Donc ça n'arrive jamais, à moins d'avoir mal implémenté le protocole ICMP.
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"Adrien Huvier" <nabok@nerim.net> wrote in message
news:Xns961CAEE1E5F80nabok@127.0.0.1
Pour UDP uniquement, non ? Si les deux machines se renvoient un port
unreachable à chaque ICMP reçu, bonjour la partie de ping pong...
Un message d'erreur ICMP ne peut pas générer de message d'erreur ICMP.
Ceci notamment pour éviter la partie de ping-pong. Donc ça n'arrive
jamais, à moins d'avoir mal implémenté le protocole ICMP.
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Pour UDP uniquement, non ? Si les deux machines se renvoient un port unreachable à chaque ICMP reçu, bonjour la partie de ping pong...
Un message d'erreur ICMP ne peut pas générer de message d'erreur ICMP. Ceci notamment pour éviter la partie de ping-pong. Donc ça n'arrive jamais, à moins d'avoir mal implémenté le protocole ICMP.
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Adrien Huvier
"Eric Lalitte" wrote in news::
Un message d'erreur ICMP ne peut pas générer de message d'erreur ICMP. Ceci notamment pour éviter la partie de ping-pong. Donc ça n'arrive jamais, à moins d'avoir mal implémenté le protocole ICMP.
Oui, mais là il est justement question de le faire "manuellement" dans la configuration du firewall... ce qu'on pourrait appeler une mauvaise implémentation :)
-- Adrien Huvier
"Eric Lalitte" <bibi@antionline.org> wrote in
news:5c311e74eab1db684aa04dfc692300be_28089@mygate.mailgate.org:
Un message d'erreur ICMP ne peut pas générer de message d'erreur
ICMP. Ceci notamment pour éviter la partie de ping-pong. Donc ça
n'arrive jamais, à moins d'avoir mal implémenté le protocole ICMP.
Oui, mais là il est justement question de le faire "manuellement" dans
la configuration du firewall... ce qu'on pourrait appeler une mauvaise
implémentation :)
Un message d'erreur ICMP ne peut pas générer de message d'erreur ICMP. Ceci notamment pour éviter la partie de ping-pong. Donc ça n'arrive jamais, à moins d'avoir mal implémenté le protocole ICMP.
Oui, mais là il est justement question de le faire "manuellement" dans la configuration du firewall... ce qu'on pourrait appeler une mauvaise implémentation :)
-- Adrien Huvier
Nicob
On Fri, 18 Mar 2005 18:45:06 +0000, Adrien Huvier wrote:
Oui, mais là il est justement question de le faire "manuellement" dans la configuration du firewall... ce qu'on pourrait appeler une mauvaise implémentation :)
Et ce serait donc *très* stupide. A peu près du même niveau que le blackistage automatique des machines faisant du SYN ou du UDP scan ...
Nicob
On Fri, 18 Mar 2005 18:45:06 +0000, Adrien Huvier wrote:
Oui, mais là il est justement question de le faire "manuellement" dans la
configuration du firewall... ce qu'on pourrait appeler une mauvaise
implémentation :)
Et ce serait donc *très* stupide. A peu près du même niveau que le
blackistage automatique des machines faisant du SYN ou du UDP scan ...
On Fri, 18 Mar 2005 18:45:06 +0000, Adrien Huvier wrote:
Oui, mais là il est justement question de le faire "manuellement" dans la configuration du firewall... ce qu'on pourrait appeler une mauvaise implémentation :)
Et ce serait donc *très* stupide. A peu près du même niveau que le blackistage automatique des machines faisant du SYN ou du UDP scan ...
Nicob
Stephane Catteau
Patrick Lamaiziere nous disait récement dans fr.comp.securite <news: :
Le filtre fait des trucs en plus qu'une simple comparaison binaire, il vérifie les numéro de séquence TCP (d'après le lien http://www.benzedrine.cx/pf-paper.html). [Snip]
Enfin bref c'est plus compliqué qu'une simple comparaison binaire.
Oui et non. Pour les quatre critères pris en compte dans l'exemple, c'est aussi simple que cela, c'est la suite qui se complique. Or, à partir du moment où tu peux faire une partie des controles beaucoup plus rapidement en t'appuyant sur la table d'état que sur les règles elles-mêmes, cela te laisse plus de temps pour faire les autres contrôles. Et comme ils seraient de toute façon effectué, tu gagnes forcément du temps, fut-il relatif puisqu'exprimé en millisecondes.
-- "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
Patrick Lamaiziere nous disait récement dans fr.comp.securite
<news:Xns21EB71071834Fplam@nulle.invalid> :
Le filtre fait des trucs en plus qu'une simple comparaison
binaire, il vérifie les numéro de séquence TCP (d'après le lien
http://www.benzedrine.cx/pf-paper.html).
[Snip]
Enfin bref c'est plus compliqué qu'une simple comparaison binaire.
Oui et non. Pour les quatre critères pris en compte dans l'exemple,
c'est aussi simple que cela, c'est la suite qui se complique. Or, à
partir du moment où tu peux faire une partie des controles beaucoup
plus rapidement en t'appuyant sur la table d'état que sur les règles
elles-mêmes, cela te laisse plus de temps pour faire les autres
contrôles. Et comme ils seraient de toute façon effectué, tu gagnes
forcément du temps, fut-il relatif puisqu'exprimé en millisecondes.
--
"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
Patrick Lamaiziere nous disait récement dans fr.comp.securite <news: :
Le filtre fait des trucs en plus qu'une simple comparaison binaire, il vérifie les numéro de séquence TCP (d'après le lien http://www.benzedrine.cx/pf-paper.html). [Snip]
Enfin bref c'est plus compliqué qu'une simple comparaison binaire.
Oui et non. Pour les quatre critères pris en compte dans l'exemple, c'est aussi simple que cela, c'est la suite qui se complique. Or, à partir du moment où tu peux faire une partie des controles beaucoup plus rapidement en t'appuyant sur la table d'état que sur les règles elles-mêmes, cela te laisse plus de temps pour faire les autres contrôles. Et comme ils seraient de toute façon effectué, tu gagnes forcément du temps, fut-il relatif puisqu'exprimé en millisecondes.
-- "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
