Pare-feu REJECT vs DROP

07 févr. 2023, 13:59

Salut,

Depuis toujours j'utilise la commande DROP dans mes pare-feux (Hier iptables - Aujourd'hui nftables).

J'ai toujours cru qu'il fallait donner le minimum d'informations aux vilains, mais je ne suis plus trop sûr que mon choix est le plus intelligent.
Je me demande aujourd'hui si REJECT n'est pas plus "propre".

Je me demande aussi si nftables traite de la même façon qu'iptables les deux commandes ?
Je me demande ensuite si le traitement des réponses sera la même quelque soit le type de paquet (ICMP, TCP/UDP) ?

Merci d'avance à ceux qui prendrons la peine de de répondre.

diesel · 07 févr. 2023, 19:08

Ben..., DROP, il jette le paquet. Point barre.

REJECT, il envoie à l'émetteur un paquet ICMP pour lui dire pourquoi il a refusé le paquet. Tu peux spécifier le type d'ICMP renvoyé.

Après, ça dépend à qui tu as affaire et pourquoi tu ne veux pas accepter le paquet.

Sur mon parefeu, je n'utilise que DROP. Le parefeu ne doit recevoir QUE du trafic qu'il a lui-même initialisé et de la part de serveurs parfaitement identifiés. TOUT le reste n'a rien à faire là ; donc DROP.

Je te recommande de mettre ça de côté : https://wiki.nftables.org/wiki-nftables ... 10_minutes

Amicalement.

Jean-Marie

08 févr. 2023, 14:15

Salut @Diesel,
Merci pour ta réponse.

diesel a écrit : 07 févr. 2023, 19:08 ...
Le parefeu ne doit recevoir QUE du trafic qu'il a lui-même initialisé
...

Sur une passerelle à la maison c'est vrai (Et encore si tu ne t'auto-héberge pas), mais sur un serveur public c'est faux.
Ce n'est pas pour une machine faisant office de pare-feu mais pour un serveur doté d'un pare-feu.

Le DROP est très pénible car il conduit à un timed-out
Un REJECT indique clairement que la tentative de connexion est refusée, c'est finalement à mon sens plus propre car finalement c'est un signe fort pour celui qui le reçoit.

J'ai remplacé DROP par REJECT sur un de mes serveurs, je comparerai dans quelque temps les conséquences sur le trafic indésirable.

diesel · 08 févr. 2023, 14:42

C'est bien ce que je t'ai écrit : "ça dépend à qui tu as affaire et pourquoi tu ne veux pas accepter le paquet".

Si ce n'est pas pour traiter de l'indésirable, voire du toxique, alors REJECT est mieux que DROP.

Amicalement.

Jean-Marie

08 févr. 2023, 16:36

Re,

diesel a écrit : 08 févr. 2023, 14:42Si ce n'est pas pour traiter de l'indésirable, voire du toxique, alors REJECT est mieux que DROP.

Si, c'est pour traiter de l'indesirable comme je le disais.
C'est ce qui se fait le plus, probablement, mais est- ce le mieux ? Plus aussi certain qu'avant...

diesel · 08 févr. 2023, 18:05

Ben..., si l'indésirable vient de l'extérieur, les problèmes de time-out vont se retrouver chez celui qui a émis le paquet. Donc tu t'en fous.

Parce que ton parefeu, dès qu'il a rencontré une directive DROP, pour lui c'est instantanément et définitivement fini. Et pour les machines qui sont derrière, ça n'a même jamais commencé.

Amicalement.

Jean-Marie

08 févr. 2023, 20:50

Pour un serveur, je préfère REJECT à DROP. C'est plus poli, et il peut y avoir des raisons légitimes d'envoyer un paquet à un port fermé et d'attendre une réponse, pour du débug réseau notamment.
Pour un paquet TCP, renvoyer plutôt un TCP RST.
Il ne faut pas renvoyer de réponse aux types ICMP d'erreur (destination unreachable, time exceeded...) car ça pourrait créer une boucle, je ne sais plus si REJECT le fait implicitement.

09 févr. 2023, 08:08

Bonjour,

Merci pour vos réponses.
J'ai mis en place via Crowdsec un REJECT (nftables) et ça coupe le ping
Je ne pense donc pas qu'il y ait de réponse

Code : Tout sélectionner

$ ping forum-debian.fr
PING forum-debian.fr (95.216.2.96) 56(84) bytes of data.
...
64 bytes from mail.isalo.org (95.216.2.96): icmp_seq=8 ttl=53 time=254 ms
64 bytes from mail.isalo.org (95.216.2.96): icmp_seq=119 ttl=53 time=254 ms
...
--- forum-debian.fr ping statistics ---
123 packets transmitted, 13 received, 89.4309% packet loss, time 124608ms
rtt min/avg/max/mdev = 253.327/253.820/254.665/0.320 ms

Par contre étonnamment j'arrive à faire un netcat mais je n'accède pas au port ensuite...

$ nc -zv forum-debian.fr 443
Connection to forum-debian.fr (95.216.2.96) 443 port [tcp/https] succeeded!

elinks fofo.jpg

Voici les règles ajoutées par Crowdsec:

Code : Tout sélectionner

# nft list ruleset | grep reject
		reject with icmpx type admin-prohibited
		ip6 daddr { ::/96, ::ffff:0.0.0.0/96, 2002::/24, 2002:a00::/24, 2002:7f00::/24, 2002:a9fe::/32, 2002:ac10::/28, 2002:c0a8::/32, 2002:e000::/19 } reject with icmpv6 type addr-unreachable
		reject with icmpx type admin-prohibited
		ip6 daddr { ::/96, ::ffff:0.0.0.0/96, 2002::/24, 2002:a00::/24, 2002:7f00::/24, 2002:a9fe::/32, 2002:ac10::/28, 2002:c0a8::/32, 2002:e000::/19 } reject with icmpv6 type addr-unreachable
		ip saddr @crowdsec-blacklists counter packets 39877 bytes 2420681 log prefix "CrowdSec REJECT: " reject
		ip6 saddr @crowdsec6-blacklists counter packets 2684 bytes 232740 log prefix "CrowdSec REJECT: " reject with icmpv6 type addr-unreachable

Je ne sais pas trop pourquoi sur l'IPv6 in envoie une réponse de type icmpv6 type addr-unreachable
A ton avis @Pascalhambourg, il faut enlever ?

Merci.

diesel · 09 févr. 2023, 14:42

Sans avoir l'ensemble des règles, difficile de se prononcer.

Amicalement.

Jean-Marie

09 févr. 2023, 16:30

diesel a écrit : 09 févr. 2023, 14:42 Sans avoir l'ensemble des règles, difficile de se prononcer.

Amicalement.

Jean-Marie

La question porte sur le réponse de nftables:
en IPv4 c'est juste reject
en IPv6 c'est reject with icmpv6 type addr-unreachable

diesel · 09 févr. 2023, 18:25

Mes règles nftables, je me les suis faites tout seul à la main. Je sais exactement ce qu'il y a dedans et comment ça fonctionne. Et crois-moi, dans mon fichier de règles, il y a presque autant de lignes de commentaires que de directives nftables.

Je ne connais pas Crowdsec "the most accurate CTI in the world" ('tain, ça fait peur !) et donc, je ne sais pas comment il est codé et quel jeu de règles il génère. Alors, difficile pour moi de te répondre. Cela dit, il faut savoir que l'ICMP ipv4 est beaucoup moins riche que l'ICMP ipv6 et que la réponse par défaut de l'ICMP ipv4 suffit probablement dans tous les cas, alors qu'en ipv6 il est nécessaire de préciser que message ICMP il faut renvoyer. Quoi que..., après vérification, c'est la même chose en ipv4 et ipv6. Ça doit donc probablement vouloir dire que la génération de la directive REJECT a été codée différemment pour ipv4 et ipv6 dans crowdsec.

Après, ce n'est pas ça qui explique que tu ne peux pas faire de ping. Tu dois avoir quelque part une règle qui rejette explicitement ce type de trafic.

Et il y a une truc bizarre dans l'extrait de règles que tu nous as fourni. La première ligne contient seulement : "reject with icmpx type admin-prohibited" Normalement, il devrait y avoir quelque chose avant. Ou alors, c'est la dernière règle d'un sous-ensemble qui a accepté juste ce qu'il fallait comme trafic (mais on ne sait pas lequel) et qui jette tout ce qui n'a pas été accepté avant.

Amicalement.

Jean-Marie

10 févr. 2023, 00:26

Personnellement, j'évite de donner des infos à ceux qui scannent les ports de l'ordi.
Si tu es poli et que tu rejettes le paquet, la malveillant à déjà une info intéressante: il y a une machine au bout, et elle répond!
Si c'est un bot basique, il ne va pas insister, mais si il est évolué, il va creuser un peu plus pour voir si cette machine identifiée n'aurait pas un port peu courant d'ouvert, et qu'est ce qu'il y aurait derrière en écoute.

10 févr. 2023, 13:22

La sécurité par l'occultation n'en est pas!

Je pense que ça ne protège que des "scripts kiddies".

Avoir changé mon DROP en REJECT n'a pas augmenté, pour l'instant, le nombre de tentatives.
Et DROP ou REJECT votre pare feu est quasiment autant sollicité...

Je verrais dans quelques semaines avec le recul.

diesel · 10 févr. 2023, 13:40

lol a écrit : 10 févr. 2023, 13:22 La sécurité par l'occultation n'en est pas!

Ben..., si.

Mais il ne faut pas s'en tenir qu'à ça. La sécurité des systèmes d'information, c'est tout un ensemble de mesures (dont ne pas être trop visible, notamment pour un attaquant en phase de découverte de cibles potentielles) et qui incluent ce qu'il y a entre les deux oreilles de celui qui est derrière le clavier.

Amicalement.

Jean-Marie

10 févr. 2023, 14:24

diesel a écrit : 10 févr. 2023, 13:40
lol a écrit : 10 févr. 2023, 13:22 La sécurité par l'occultation n'en est pas!
Ben..., si.

Ben ... non.
Je ne suis pas d'accord avec toi évidemment.

D'ailleurs c'est ce qui rend l'Open source si fiable par rapport aux systèmes propriétaires.

Croire que cacher le code va permettre d'éviter les faille de sécurité (ou du moins leur exploitation) est évidemment une insulte à l'intelligence.

diesel · 10 févr. 2023, 18:00

lol a écrit : 10 févr. 2023, 14:24Croire que cacher le code va permettre d'éviter les faille de sécurité (ou du moins leur exploitation) est évidemment une insulte à l'intelligence.

Là je suis entièrement d'accord avec toi (encore que..., publier en open source un code pourri, bourré de failles est quand-même le meilleur moyen de se faire trouer), mais ce n'est pas le même sujet.

Amicalement.

Jean-Marie

Grhim · 10 févr. 2023, 18:06

Super sujet !

Je viens de terminer le stage sur Nmap Pentest , j'ai appris entre autre, que beaucoup d'entreprises interdisent de nos jours les scans ICMP... , se serait aussi peut être une soluce ?

10 févr. 2023, 19:42

Il ne s'agit pas de cacher du code, mais des infos qui pourrait faciliter l'identification de failles potentielles. C'est comme ne pas laisser apparaître la version de son serveur apache sur un page publique, ou ne pas laisser un mode débug en prod.
Ca ne protège effectivement pas d'un attaquant déterminé, mais ça détourne ceux qui sont à la recherche d'une cible facile, et ils sont nombreux.

vv222 · 12 févr. 2023, 11:44

lol a écrit : 08 févr. 2023, 14:15 Le DROP est très pénible car il conduit à un timed-out
Un REJECT indique clairement que la tentative de connexion est refusée, c'est finalement à mon sens plus propre car finalement c'est un signe fort pour celui qui le reçoit.

PascalHambourg a écrit : 08 févr. 2023, 20:50 Pour un serveur, je préfère REJECT à DROP. C'est plus poli, et il peut y avoir des raisons légitimes d'envoyer un paquet à un port fermé et d'attendre une réponse, pour du débug réseau notamment.

Mon pare-feu ne rejette absolument aucune requête, son rôle étant uniquement de mettre en place un NAT IPv4 entre la machine hôte et des conteneurs tournant dessus (vivement qu’IPv4 soit vraiment mise à la retraite au profit d’IPv6…). Mais si je devais mettre en place des règles bloquant l’accès à certains ports, ce serait sans aucun doute via du REJECT.

Je configure mes services pour une utilisation idéale par des personnes honnêtes, et non pas comme beaucoup en priorisant les utilisations malhonnêtes. Pas de captcha sur mes services Web par exemple, ni de ban des adresses e-mail en fonction du TLD, ni de blocage des IPs par origine géographique, etc.

21 févr. 2023, 11:00

vv222 a écrit : 12 févr. 2023, 11:44 Mon pare-feu ne rejette absolument aucune requête, son rôle étant uniquement de mettre en place un NAT

Alors mérite-t-il l'appellation "pare-feu" ?