Linux et firewall

Le Thu, 06 Apr 2006 08:45:03 +0000, Eric Belhomme a écrit :

Sans tomber dans l'alarmisme, un routeur adsl devrait être _totalement_
muet vu depuis son interface externe, sauf cas particulier.

Bonjour.
Je crois que j'ai un cas particulier assez général :) : le ping.
Un petit retour sur icmp 8, au moins pour certaines adresses IP, même en
limitant le nombre de retours possibles sur une période est bien pratique
pour vérifier qu'au moins la bête est vivante et l'accès à la bête
possible.

Le drop des paquets c'est bien pour ralentir/emmerder un scanneur et
éviter de deviner l'OS qui est derrière mais sur un icmp reply le
fingerprinting n'est généralement pas terrible.

Eric.

Eric écrivait:
[..]

Le drop des paquets c'est bien pour ralentir/emmerder un scanneur et
éviter de deviner l'OS qui est derrière mais sur un icmp reply le
fingerprinting n'est généralement pas terrible.

Juste une petite précision, le fait de dropper un packet au lieu de
répondre (par un RST par exemple) ne change rien concernant la
détection de l'OS.
Ca peut faire un peu chier nmap, mais c'est tout.

Et puis, pour un vrai outil d'OS fingerprinting, qui ne nécessite
qu'un port TCP ouvert, même hautement filtré (stateful,
normalisation), il existe SinFP, et lui, c'est sûr, drop ou pas drop,
no difference.

http://www.gomor.org/cgi-bin/index.pl?mode=view;page=net_sinfp

--
^ ___ ___ http://www.GomoR.org/ <-+
| / __ |__/ Systems & Security Engineer |
| __/ | ---[ zsh$ alias psed='perl -pe ' ]--- |
+--> Net::Packet <=> http://search.cpan.org/~gomor/ <--+

Eric Razny <news_01@razny.net> wrote in news:pan.2006.04.06.08.54.54.989158
@razny.net:

Le Thu, 06 Apr 2006 08:45:03 +0000, Eric Belhomme a écrit :

Sans tomber dans l'alarmisme, un routeur adsl devrait être _totalement_
muet vu depuis son interface externe, sauf cas particulier.

Bonjour.
Je crois que j'ai un cas particulier assez général :) : le ping.
Un petit retour sur icmp 8, au moins pour certaines adresses IP, même en
limitant le nombre de retours possibles sur une période est bien pratique
pour vérifier qu'au moins la bête est vivante et l'accès à la bête
possible.

oui... en fait, par muet, je pensais services réseaux, genre http,

telnet...
Je sais, vous allez me répondre que icmp _est_ un service réseau... mais
bon vous m'avez compris ;)

--
Rico

Eric Razny wrote:

Le drop des paquets c'est bien pour ralentir/emmerder un scanneur

C'est surtout bien pour cacher le fait qu'il y a une machine branchée
derrière, lors de scans de larges plages d'adresses.

(Et le jour ou ipv6 sera une réalité (haha), ce sera encore plus vrai)

Xavier Roche n'était pas loin de dire :

Le drop des paquets c'est bien pour ralentir/emmerder un scanneur

Bof, ça ne marchera que si le scanner ne sait pas envoyer les paquets
en rafale[1], autrement il s'en moque un peu que la réponse ne vienne
pas, le ralentissement sera minime.

C'est surtout bien pour cacher le fait qu'il y a une machine branchée
derrière, lors de scans de larges plages d'adresses.

Le dernier routeur n'est pas supposé renvoyer un Host Unreachable dans
ce cas là ?
A mon sens, droper les paquets c'est surtout dire, "eh je suis là,
mais j'ai un firewall", et accessoirement, "et je suis probablement
sous Windows", vu que les firewalls personnels Windows ont la facheuse
manie d'opter pour le drop pour les règles de bloquage, sans laisser la
possibilité à l'utilisateur de renvoyer un message d'erreur ou un RST.



[1]
Il en existe encore des comme ça ?

Stephane Catteau wrote:

C'est surtout bien pour cacher le fait qu'il y a une machine branchée
derrière, lors de scans de larges plages d'adresses.
Le dernier routeur n'est pas supposé renvoyer un Host Unreachable dans

ce cas là ?

Non, dans pas mal de cas rien ne passe. C'est le cas des IP dynamiques
des FAI que j'ai pu tester, et dont les machines correspondantes ne sont
pas allumées.

C'est aussi le cas sur des blocs clairement non rout(é|routable)s:

$ ping 1.2.3.4
(long silence intersidéral en attendant que le cosmos nous envoi un
signe...)

[ Je comprend qu'il n'existe aucune table de routage pour ce bloc, mais
dans ce cas je ne comprend pas bien qu'un routeur ne finisse pas par
dire "connais pas!" ]

"et je suis probablement sous Windows"

Euh, les DROP sont très massivement utilisés par ipchains/netfilter,
également.

(Et par les câbles mangés par les souris aussi, donc)

Le 06-04-2006, Eric Belhomme <{rico}+no/spam@ricospirit.net> a écrit :

* interprétation personnelle :

netfilter est l'infrastructure (des ancres de la couche réseau du kernel)
qui permet de placer des fonctions callback en fonction de ce qu'on
souhaite faire :
- filtrage de paquets ipv4 avec ip_tables - le module en kernel-land, et
iptables en userland)
- filtrage de paquets ipv6 avec ip6tables,
- filtrage arp avec arptables
- filtrage au niveau bridge avec brtables
- ...

Tu commences toutes des difinitions par "filtrage". Mais netfilter est

bien l'outil qui permet d'agir sur les pquets. Une action est le
filtrage. D'autres actions existent:
-marquage des paquets pour traitement ulterieur (par exemple avec iproute2)
-reperage seul, je pense au -j LOG qui fondamentalement ne change
rien a la vie du paquet.

--
Kevin

Kevin Denis <kevin@nowhere.invalid> wrote in
news:slrne3c7bp.2ss.kevin@zipslack.local.tux:

Tu commences toutes des difinitions par "filtrage". Mais netfilter est
bien l'outil qui permet d'agir sur les pquets. Une action est le
filtrage. D'autres actions existent:
-marquage des paquets pour traitement ulterieur (par exemple avec
iproute2) -reperage seul, je pense au -j LOG qui fondamentalement ne
change rien a la vie du paquet.

car il s'agit d'un filtrage, du moins en entrée ! effectivement en sortie,

différentes actions sont possibles (flitrage, marquage, log, ...)

--
Rico

Xavier Roche devait dire quelque chose comme ceci :

C'est surtout bien pour cacher le fait qu'il y a une machine branchée
derrière, lors de scans de larges plages d'adresses.
Le dernier routeur n'est pas supposé renvoyer un Host Unreachable dans

ce cas là ?

Non, dans pas mal de cas rien ne passe.

J'ai cherché très rapidement, donc j'ai pu passer à côté de quelque
chose, mais j'ai trouvé la RFC 792 :

|If, according to the information in the gateway's routing tables, the
|network specified in the internet destination field of a datagram is
|unreachable, e.g., the distance to the network is infinity, the gateway
|may send a destination unreachable message to the internet source host
|of the datagram.

C'est aussi le cas sur des blocs clairement non rout(é|routable)s:

$ ping 1.2.3.4

Pourquoi une classe réservée devrait-elle forcément être considérée
comme non routé/routable ? Je n'ai pas vraiment envie de trafiquer les
règles de ma passerelle, qui bloque les paquets à destination des
réseaux privés, mais quitte à faire un essais, autant prendre 10/8,
classe pour laquelle l'on connait avec une quasi certitude la politique
appliquée par les routeurs.

"et je suis probablement sous Windows"

Euh, les DROP sont très massivement utilisés par ipchains/netfilter,
également.

Les DROP sont massivement utilisés par les utilisateurs
d'ipchains/netfilter, ce qui n'est pas tout à fait pareil. Je ne suis
pas convaincu que tu trouves beaucoup de références disant "pour bloquer
il faut DROPer", dans les docs antérieures au grand précepte de Gibson
selon lequel pour devenir invisible il ne faut surtout pas répondre.
Maintenant c'est devenu vrai par la force des choses, puisque le réseau
doit ressembler à un amas de trous noirs, mais est-ce une bonne raison
pour DROPer au lieu de répondre proprement ?
Il n'y a que quatre cas de figure possible :

1) Tu as une adresse IP fixe et un enregistrement DNS (ou un DNS
dynamique) qui pointe dessus.

Si tu DROPes, tu seras dans l'un des trous noirs que j'ai mentionné,
mais on sait que ton ordinateur est allumé, sinon à quoi bon avoir un
enregistrement DNS ? On sait donc que tu as un firewall et que ce que
l'on voit n'est pas forcément la liste de tous les services qui
tournent. Il peut donc y avoir quelque chose à faire sur ta machine,
pourquoi ne pas tenter d'exploiter les failles connues des différents
firewalls ?
Si tu réponds aux requêtes avec un RST ou un Port Unreachable,
suivant la requête, tu simules le comportement de la pile IP.
L'attaquant ne sait pas si tu as un firewall ou non, donc il ne sait
pas s'il y a une possibilité pour que d'autres services tournent sur
ta machine. Il passera à autre chose.
Dans tous les cas il aura la possibilité d'attaquer directement les
serveurs que tu as ouvert vers l'extérieur.

2) Tu as une adresse IP fixe et c'est tout.

Si tu DROPes, l'attaquant pourra croire que tu n'es pas là et il
passera à autre chose, sauf si tu as au moins un service ouvert sur
l'extérieur, auquel cas il saura que tu as un firewall et on se
retrouve dans le même cas de figure que précédement.
Si tu réponds aux requêtes, tu trahis ta présence, mais pour le
reste rien ne change par rapport au cas 1.

3) Tu as une adresse IP dynamique.

Si tu DROPes, tu te retrouves dans les mêmes conditions que le cas 2.
Si tu réponds aux requêtes, tu te retrouves dans les mêmes
conditions que le cas 2, c'est-à-dire que tu ne fais que trahir ta
présence.

4) Tu as une adresse IP fixe ou dynamique, et l'attaquant sait que tu
es connecté (parce qu'il te parle sur IRC, en chat, joue avec toi en
ligne, autre).

Là, c'est la même chose que pour le premier cas.


Par conséquent, le fait de DROPer les paquets ne protéges ta machine
que si tu es déjà invisible, c'est-à-dire que l'attaquant ne sait pas
que tu es attaqué et qu'il n'y a aucun service qui tourne sur ta
machine. Autrement, cela trahi la présence de ton firewall. A l'inverse,
si tu réponds aux requêtes, tu trahis ta présence à toi, qui peut tout
aussi bien être trahie par autre chose, mais tu laisses l'attaquant dans
le flou en ce qui concerne les mesures de protection que tu as prises.

Conclusion, sauf si tu es un utilisateur vraiment lambda, ou que tu
n'as pas le choix, il est préférable de répondre aux requêtes.

Xavier Roche devait dire quelque chose comme ceci :

C'est surtout bien pour cacher le fait qu'il y a une machine branchée
derrière, lors de scans de larges plages d'adresses.
Le dernier routeur n'est pas supposé renvoyer un Host Unreachable dans

ce cas là ?

Non, dans pas mal de cas rien ne passe.

J'ai cherché très rapidement, donc j'ai pu passer à côté de quelque
chose, mais j'ai trouvé la RFC 792 :

If, according to the information in the gateway's routing tables, the
network specified in the internet destination field of a datagram is
unreachable, e.g., the distance to the network is infinity, the gateway
may send a destination unreachable message to the internet source host
of the datagram.

C'est aussi le cas sur des blocs clairement non rout(é|routable)s:

$ ping 1.2.3.4

Pourquoi une classe réservée devrait-elle forcément être considérée
comme non routé/routable ? Je n'ai pas vraiment envie de trafiquer les
règles de ma passerelle, qui bloque les paquets à destination des
réseaux privés, mais quitte à faire un essais, autant prendre 10/8,
classe pour laquelle l'on connait avec une quasi certitude la politique
appliquée par les routeurs.

"et je suis probablement sous Windows"

Euh, les DROP sont très massivement utilisés par ipchains/netfilter,
également.

Les DROP sont massivement utilisés par les utilisateurs
d'ipchains/netfilter, ce qui n'est pas tout à fait pareil. Je ne suis
pas convaincu que tu trouves beaucoup de références disant "pour bloquer
il faut DROPer", dans les docs antérieures au grand précepte de Gibson
selon lequel pour devenir invisible il ne faut surtout pas répondre.
Maintenant c'est devenu vrai par la force des choses, puisque le réseau
doit ressembler à un amas de trous noirs, mais est-ce une bonne raison
pour DROPer au lieu de répondre proprement ?
Il n'y a que quatre cas de figure possible :

1) Tu as un enregistrement DNS (ou un DNS dynamique) qui pointe sur
toi.

Si tu DROPes, tu seras dans l'un des trous noirs que j'ai mentionné,
mais on sait que ton ordinateur est allumé, sinon à quoi bon avoir un
enregistrement DNS ? On sait donc que tu as un firewall et que ce que
l'on voit n'est pas forcément la liste de tous les services qui
tournent. Il peut donc y avoir quelque chose à faire sur ta machine,
pourquoi ne pas tenter d'exploiter les failles connues des différents
firewalls ?
Si tu réponds aux requêtes avec un RST ou un Port Unreachable,
suivant la requête, tu simules le comportement de la pile IP.
L'attaquant ne sait pas si tu as un firewall ou non, donc il ne sait
pas s'il y a une possibilité pour que d'autres services tournent sur
ta machine. Il passera à autre chose.
Dans tous les cas il aura la possibilité d'attaquer directement les
serveurs que tu as ouvert vers l'extérieur.

2) Tu as une adresse IP fixe et c'est tout.

Si tu DROPes, l'attaquant pourra croire que tu n'es pas là et il
passera à autre chose, sauf si tu as au moins un service ouvert sur
l'extérieur, auquel cas il saura que tu as un firewall et on se
retrouve dans le même cas de figure que précédement.
Si tu réponds aux requêtes, tu trahis ta présence, mais pour le
reste rien ne change par rapport au cas 1.

3) Tu as une adresse IP dynamique.

Si tu DROPes, tu te retrouves dans les mêmes conditions que le cas 2.
Si tu réponds aux requêtes, tu te retrouves dans les mêmes
conditions que le cas 2, c'est-à-dire que tu ne fais que trahir ta
présence.

4) Tu as une adresse IP fixe ou dynamique, et l'attaquant sait que tu
es connecté (parce qu'il te parle sur IRC, en chat, joue avec toi en
ligne, autre).

Là, c'est la même chose que pour le premier cas.


Par conséquent, le fait de DROPer les paquets ne protéges ta machine
que si tu es déjà invisible, c'est-à-dire que l'attaquant ne sait pas
que tu es connecté et qu'il n'y a aucun service qui tourne sur ta
machine. Autrement, cela trahi la présence de ton firewall. A l'inverse,
si tu réponds aux requêtes, tu trahis ta présence à toi, qui peut tout
aussi bien être trahie par autre chose, mais tu laisses l'attaquant dans
le flou en ce qui concerne les mesures de protection que tu as prises.

Conclusion, sauf si tu es un utilisateur vraiment lambda, ou que tu
n'as pas le choix, il est préférable de répondre aux requêtes.