Linux et firewall

Eric Belhomme devait dire quelque chose comme ceci :

car il s'agit d'un filtrage, du moins en entrée ! effectivement en sortie,
différentes actions sont possibles (flitrage, marquage, log, ...)

Je doute que ces actions ne soient pas possibles aussi en entrée, même
si elles peuvent te paraître moins utile, ce qui n'est pourtant pas le
cas.

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 ce que je constate aussi.

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 un "may", donc pas d'obligation.
Par contre dans RFC 1818 "Requirements for IPv4 routers", les
paragraphes 4.3.3.1 et 5.2.7.1 disent "MUST".

Pourquoi une classe réservée devrait-elle forcément être considérée
comme non routé/routable ?

Parce que ces adresses ne sont allouées à aucune machine accessible par
internet ?

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 encore. Certains FAI n'hésitent pas à utiliser des adresses privées
sur leur réseau. On se retrouve par exemple avec des 192.168.x.y dans la
sortie d'un traceroute fait depuis une connexion client, ou avec des
trous si on a bloqué ces adresses.

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

ipchains/iptables svp. ;-)

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.

Y a-t-il une personne sensée et informée qui souscrive à ce "précepte" ?
En ce qui me concerne, voir afficher en gros caractères rouges
clignotants avec des têtes de mort en feu (bon, j'exagère un peu) "vous
répondez au ping, vous courez un GRAVE danger !!!", ça ne m'incite pas à
le prendre au sérieux.

Il n'y a que quatre cas de figure possible :

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

Je suppose que tu veux dire un enregistrement DNS *connu* ?

[...]

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.

AMA avoir en même des ports ouverts avec des services en écoute et des
ports DROPés n'est pas très cohérent et ne peut qu'attirer la curiosité.
Il me semble que le seul cas où le DROP se justifie est quand *tout* est
DROPé en entrée afin que la machine apparaisse invisible.

Mais même dans le cas où on DROPe tout, la présence de la machine peut
être détectable indirectement. Par exemple, en IP/ADSL, si un traceroute
vers l'adresse cible bloque après un LNS au lieu d'un routeur core, ça
veut dire que la connexion est active sur ce LNS. Autre exemple, au sein
d'un réseau local, la machine se trahit en répondant aux requêtes ARP.

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 rejoint ce que je disais.

[...]

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.

Et en plus c'est plus poli. :-) En posant des limites pour ne pas trop
bouffer son upload sur une connexion à débit asymétrique en cas de flood
ou polluer des innocents en cas de spoofing.

Eric Belhomme devait dire quelque chose comme ceci :

car il s'agit d'un filtrage, du moins en entrée ! effectivement en sortie,
différentes actions sont possibles (flitrage, marquage, log, ...)

Je doute que ces actions ne soient pas possibles aussi en entrée, même
si elles peuvent te paraître moins utile, ce qui n'est pourtant pas le
cas.

Je pense qu'Eric ne parlait pas en terme de cheminement dans la pile IP
mais d'entrée et de sortie du processus de traitement par une règle :
- entrée = critères de correspondance du paquet = filtrage
- sortie = action (DROP, ACCEPT, LOG, MARK...)

Je ne vois pas comment interpréter son propos autrement.

Stephane Catteau wrote:

Pourquoi une classe réservée devrait-elle forcément être considérée
comme non routé/routable ?

Euh, ce que je voulais dire, c'est que les tables globales BGP n'ayant
aucune référence de cette méga-classe, un routeur normal devrait aussi
renvoyer un paquet ICMP explicite.

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

Et si l'attaquant se tape un scan en règle pour chaque IP, même celles
qui ne répondent pas aux pings. Cela ne résoud pas le problème, mais
cela limite le bruit de fond.

Par conséquent, le fait de DROPer les paquets ne protéges ta machine

Certes non. On parle bien de limiter la visibilité, pas de rendre plus
sûr la machine dans l'absolu.

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.

Pourquoi préférable ? Pour un utilisateur lambda, cela augmente la
visibilité, sans vraiment apporter de réals avantages.

"Stephane Catteau" <steph.nospam@sc4x.net> writes:

[...]

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.

Bin perso j'ai une IP fixe et je me faire rarement scanner brutalement sur tous
ports. J'ai souvent des HTTP/GET et des syn sur le port ssh mais c'est
tout. Rarement des connexions sur les autres ports (ftp, ftp-data, htts, *sql)
même ce bon vieux telnet n'a plus son succès.
(Les seuls trucs que je ne log plus les connexions sur les ports de partages
windows... beaucoup trop sollicités)

Donc l'argument ça sert à rien de drop-er si on a au moins un service ouvert est
valable mais je lui mettrais un bémol.

Il me semble que les maichants pirates de l'internet lancent leurs attaques sur
un port... si t'es là je te bourrine sur ce port, si t'es pas là je passe à un
autre. Bref ils semblent chercher du easykill plutôt qu'une machine à tout
prix. Drop ou pas drop dans ce cas là ça ne change rien. Mais cela ne concerne
qu'un type de pequenots.

FAb
(bémol)

FAb n'était pas loin de dire :

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.

Bin perso j'ai une IP fixe et je me faire rarement scanner brutalement sur
tous ports.

Pour ma part j'ai une adresse IP fixe et une adresse IP qui pendant
longtemps était peu tournante et, horreur, est situé chez un FAI
largement scanné, et j'ai au moins un scanne "brutal" par jour. Tous
les ports ne sont pas scannés (même si cela arrive), mais j'ai droit à
deux ou trois cents ports vérifiés.
Enfin, je dis ça, mais peut-être que cela a changé depuis que j'ai
fini par ne plus logger les requêtes faites sur les ports non
privilégiés.

(Les seuls trucs que je ne log plus les connexions sur les ports de
partages windows... beaucoup trop sollicités)

Vue que la moitié des vers en circulation doivent les cibler, c'est un
peu normal.

Il me semble que les maichants pirates de l'internet lancent leurs attaques
sur un port... si t'es là je te bourrine sur ce port, si t'es pas là je
passe à un autre. Bref ils semblent chercher du easykill plutôt qu'une
machine à tout prix. Drop ou pas drop dans ce cas là ça ne change rien.

Je serais tenté au contraire de dire que ton argument parle en faveur
d'une réponse au lieu d'un DROP. Ce genre de personnes à tendance à ne
pas savoir ce qu'elles font, donc lorsque leur magnifique outils de la
mort qui tue leur dit qu'il n'y a pas eu de réponse, ils recommencent
encore et encore, accusant qui leur incapable de FAI qui a perdu le
paquet, qui ce "logiciel de [beep] de chez [beep]" qui ne sait
décidément pas fonctionner correctement. A l'inverse, si le logiciel
leur dit "c'est fermé", ils passent à l'adresse suivante.

Mais cela ne concerne qu'un type de pequenots.

Certes, mais à la fois le plus chiant et le plus répandu.

Xavier Roche devait dire quelque chose comme ceci :

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

Et si l'attaquant se tape un scan en règle pour chaque IP, même celles
qui ne répondent pas aux pings. Cela ne résoud pas le problème, mais
cela limite le bruit de fond.

Combien de personnes savent réaliser un scan qui ne renverait pas
directement la réponse à leur machine à eux qu'ils ont ou, au pire, à
celle qu'ils utilisent comme relais parce qu'un torjan s'y trouvait
déjà ? Et parmis eux, combien font un scan en règle et en aveugle ?
Le fait de dropper le paquet ne changera rien au bruit de fond que tu
reçois, et dans moins de 1% des cas pourra éviter de déranger un
utilisateur lambda dont la machine est utilisée pour un scan (dont le
nom m'échappe toujours mais qui consiste à écouter une machine tiers
pour savoir si le port a renvoyé un RST ou un ACK). Reste le cas où le
kiddy utilise une machine compromise comme relais. Là, je serais tenté
de dire qu'au contraire il faut répondre, pour donner une chance au
propriétaire de constater que son débit à tendance à diminué, et ainsi
chercher et, qui sait, trouver la cause réel de son problème.

Par conséquent, le fait de DROPer les paquets ne protéges ta machine

Certes non. On parle bien de limiter la visibilité, pas de rendre plus
sûr la machine dans l'absolu.

Voir la réponse de Pascal Hambourg. Cela ne limite pas grand chose.
D'autant plus que la méthode étant devenue tellement répandue, il doit
y avoir longtemps que les vrais méchants, ceux qui peuvent vraiment te
faire du mal, ne se contentent plus d'un simple scan pour savoir si tu
es là ou non. D'ailleurs, je serais étonné qu'il n'y ait pas déjà un
programme permettant de scanner la liste des machines connectées sur un
NetBloc donné via un traceroute. C'est un brin plus long, mais
tellement plus fiable si le NetBloc est utilisé pour de l'IP/ADSL,
d'autant plus qu'au passage on peut profiter de la réponse des
différents points de passage, surtout les derniers, pour faire du
fingerprinting dessus et éventuellement trouver ainsi un équipement
vulnérable qui pourrait servir de relais vers la cible.

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.

Pourquoi préférable ? Pour un utilisateur lambda, cela augmente la
visibilité, sans vraiment apporter de réals avantages.

Quelle est l'avantage de se croire, à tort, invisible ? Et si tu ne
trouves que "dormir tranquille" comme réponse, n'oublie pas qu'une
baisse de vigilance est synonyme d'augmentation des risques.

Pascal Hambourg n'était pas loin de dire :


[De la réponse des routeurs si une adresse IP est injoignable/down]

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

C'est un "may", donc pas d'obligation.
Par contre dans RFC 1818 "Requirements for IPv4 routers", les
paragraphes 4.3.3.1 et 5.2.7.1 disent "MUST".

Ce qui n'est toujours pas un "SHOULD", donc autant pour mon "il me
semblait que".

Pourquoi une classe réservée devrait-elle forcément être considérée
comme non routé/routable ?

Parce que ces adresses ne sont allouées à aucune machine accessible par
internet ?

Il n'est pas dit que ce soit vraiment le cas, juste qu'elles ne sont
pas attribuables. De plus, le status est succeptible de changer un peu
n'importe quand, donc considérer ces adresses comme non routables
lorsque l'on configure un routeur revient à prendre un risque, même
s'il est minime ; l'on se retrouverait alors avec des paquets légitimes
à destination de 01/08 (pour garder la classe prise en exemple) qui se
retrouveraient droppé en cours de route par un routeur, embêtant non ?

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 encore. Certains FAI n'hésitent pas à utiliser des adresses privées
sur leur réseau. On se retrouve par exemple avec des 192.168.x.y

Ce fut notament le cas pour Wanadoo pendant plusieurs années, mais
apparament, soit leurs équipements sont devenus transparents, soit ils
ont corrigés le tir. Cependant, si je me souviens bien des tests que
j'avais fait à l'époque, les routeurs en bordure du réseau droppaient
ces paquets, ou tout du moins ceux qui étaient situés juste après les
point d'accès client.

[...] grand précepte de Gibson selon lequel pour devenir invisible
il ne faut surtout pas répondre.

Y a-t-il une personne sensée et informée qui souscrive à ce "précepte" ?

Pas à ma connaissance mais, et cela constitue un gros problème, de nos
jours n'importe quel personne ayant deux sous de notions en
informatique peut se faire passer pour un dieu de la sécurité
informatique auprès du grand public. Tant qu'il n'a pas en face de lui
quelqu'un ayant suffisement de connaissances pour le contrer, les
lecteurs boivent ses paroles, persuadés que, parce qu'il emploie des
termes qu'eux-mêmes ne comprennent pas, il sait forcément de quoi il
parle. Or, parmis ces gens, nombreux sont ceux qui s'abreuvent à la
sainte parole de Gibson, propageant de fait la plus part de ses
inepties.
Quoi que, à bien y réfléchir, je me demande ce qu'il en est du côté
des éditeurs de logiciels. Envoyer un RST ou un host unreachable au
lieu de dropper les paquets bloqués n'est pas bien compliqué et,
puisque tous les filtres IP Unix/Linux savent le faire, cela ne pose
pas de problèmes en terme de sécurité. Donc, pourquoi tous les
firewalls Windows, ou presque, persistent-ils dans cette voie ? :-/

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

Je suppose que tu veux dire un enregistrement DNS *connu* ?

Oui, mais il faut être un brin dépensier pour avoir un enregistrement
DNS pointant sur sa machine et ne jamais s'en être servi d'une façon ou
d'une autre ;-)


[Snip]

Il me semble que le seul cas où le DROP se justifie est quand *tout* est
DROPé en entrée afin que la machine apparaisse invisible.

Il se justifie aussi, beaucoup plus ponctuellement, dans le cas où ta
machine servirait dans un DDoS, par demande de connexion TCP sur un
port non ouvert ou ping multicast, tous deux envoyés avec en adresse IP
source celle de la victime ; pas tant pour préserver ta bande passante,
que pour ne pas impacter la victime.

Mais même dans le cas où on DROPe tout, la présence de la machine peut
être détectable indirectement. Par exemple, en IP/ADSL, si un traceroute
vers l'adresse cible bloque après un LNS au lieu d'un routeur core, ça
veut dire que la connexion est active sur ce LNS. Autre exemple, au sein
d'un réseau local, la machine se trahit en répondant aux requêtes ARP.

Tout à fait. Cela reste une invisibilité de façade, et clairement pas
la défense suprème qui est l'argument de vente de cette méthode.

Stephane Catteau wrote:

Quelle est l'avantage de se croire, à tort, invisible ? Et si tu ne
trouves que "dormir tranquille" comme réponse, n'oublie pas qu'une
baisse de vigilance est synonyme d'augmentation des risques.

L'avantage n'est pas de se croire invisible, mais de limiter les
attaques (et je confirme que passer une machine en mode "invisible",
cela fonctionne, après avoir testé plusieurs modes sur des machines
lambda - il me semble d'ailleurs logique qu'un scan en "brute force" sur
une classe entière d'IPs soit un peu plus rare que des tests ip par ip,
selon qu'il y a une machine active derrière), ce qui permet au contraire
de focaliser son attention sur les quelques scans restants qui eux,
peuvent éventuellement être intéressants à regarder.

C'est comme les techniques de filtrage de spam, ou de masquage d'adresse
email: la plupart peuvent être facilement contournées (par exemple le
greylist ou les divers hacks dans sendmail pour le filtrage, ou bien la
réécriture des email en "nospam" pour le masquage) mais dans la
pratique, peu de spammeurs s'en donnent la peine. Les quelques %
restants peuvent alors être étudiés avec un peu plus d'attention.

Bref ce n'est pas parce qu'un moyen de protection n'est pas infaillible
qu'il ne faut pas l'utiliser. Il faut juste garder à l'esprit que ce
n'est qu'un artifice qui ne peut que ralentir ou limiter les attaques.
Et limiter le bruit de fond améliore la sécurité, j'en suis persuadé.

"Stephane Catteau" <steph.nospam@sc4x.net> écrivait :

Quoi que, à bien y réfléchir, je me demande ce qu'il en est du côté
des éditeurs de logiciels. Envoyer un RST ou un host unreachable au
lieu de dropper les paquets bloqués n'est pas bien compliqué et,
puisque tous les filtres IP Unix/Linux savent le faire, cela ne pose
pas de problèmes en terme de sécurité. Donc, pourquoi tous les
firewalls Windows, ou presque, persistent-ils dans cette voie ? :-/

Pas que sous Windows : les politiques par défaut avec iptables sont
uniquement les target prédéfinies.

Donc ACCEPT ou DROP, mais *pas* REJECT...

En effet et c'est aussi bien ainsi, car un REJECT systématique ne se
justifierait pas (et avec quel type de réponse par défaut ?). Ça ne
change rien au fond. La politique par défaut DROP des chaînes de
filtrage ne devrait servir que de filet de sécurité en dernier ressort
en cas d'erreur dans le jeu de règles, et le sort de tout paquet devrait
normalement être déterminé explicitement par un règle.

[Erwan, par pitié pour vos lecteurs, relisez-vous avant d'appuyer sur
"envoyer" ou tapez un peu moins vite !]