Pare-feu REJECT vs DROP

[vv222]

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

Pas vraiment, mais j’ai l’impression que c’est le terme générique pour désigner ce genre de logiciel (nftables dans mon cas).

[PascalHambourg]

Je préfère dire "filtre de paquets", c'est à la fois plus précis (il existe d'autres types de pare-feu) et générique (ça peut servir à faire autre chose qu'un pare-feu).

[vv222]

Tu as raison, je vais essayer de prendre l’habitude d’utiliser ce terme plutôt que "pare-feu" qui semble plus ciblé.

[dezix]

Bonjour,

Si cela peut apporter un peu d'eau à vos moulins....

DROP offers no effective barrier to hostile forces
but can dramatically slow down applications run by legitimate users.
DROP should not normally be used.

que l'on peut traduire par :

DROP n'offre aucune protection efficace contre les forces hostiles,
mais peut ralentir considérablement les applications exécutées par des utilisateurs légitimes.
DROP ne devrait normalement pas être utilisé.

PS: la référence de la citation contient un lien vers : Drop versus Reject

[zargos]

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.

Bonjour,
L'occultation des machines est juste un élément de plus dans une globalité de sécurité. C'est utile mais insuffisant.
Je ne parle pas de l'occultation du code, qui n'a pas d'utilité (autre que de faire du propriétaire, mais c'est une autre discussion).
Préparer une attaque, c'est récolter toutes les informations nécessaires à cette attaque, dont l'identification des cibles. Dégrader les capacité de cette identification est toujours bonne à prendre, d'où l'utilité du DROP, ou du NAT, etc...

Le REJECT peut aussi être utilisé pour gérer les erreurs interne et éviter les timeout.
Un utilisateur qui se connecte sur un mauvais port par exemple sur un site web, genre http://lesite:8083 au lieu de http://lesite:8080.
Le DROP devrait être la règle sur l'extérieur.

[lol]

...
Préparer une attaque, c'est récolter toutes les informations nécessaires à cette attaque, dont l'identification des cibles. Dégrader les capacité de cette identification est toujours bonne à prendre, d'où l'utilité du DROP, ou du NAT, etc...
...

Je suis de plus en plus persuadé que DROP aide au flood des machines tout autant qu'il ne protège pas plus que REJECT.

Un serveur à toujours au moins un service à l'écoute sinon ça ne sert à rien.
Un DROP sur les les ports inutilisés apporte autant d'info qu'un REJECT.
Se croire invisible parce qu'on DROP les tentatives de connexion est un leurre.

[zargos]

Je suis de plus en plus persuadé que DROP aide au flood des machines tout autant qu'il ne protège pas plus que REJECT.

Pas plus. En fait, le DROP ne permet pas à l'attaquant de savoir s'il attaque une machine réelle ou non. REJECT lui permettra de savoir qu'il attaque bien une machine active.

Un serveur à toujours au moins un service à l'écoute sinon ça ne sert à rien.
Un DROP sur les les ports inutilisés apporte autant d'info qu'un REJECT.

En dehors de l'interface locale, un serveur ou une machine, peut très bien n'avoir aucun port d'ouvert en écoute vers l’extérieur du système. Ce sera une machine qui se connecte vers les autres, mais vers laquelle les autres ne se connecte pas.
C'est parfaitement possible. Il se trouve que j'en ai une.

Se croire invisible parce qu'on DROP les tentatives de connexion est un leurre.

Il ne s'agit pas d'"invisibilité mais d'offuscation (linguistiquement ce n'est pas la même chose.
Il ne s'agit pas d'être invisible mais simplement de limiter les informations disponibles à l'extérieur. Le DROP ne se suffit pas à lui-même. Le REJECT permet des informations que ne permet pas le DROP.
Le REJECT permet à minima d'identifier le fabricant de la carte réseau, voir de la carte mère.
Un exemple avec REJECT qui ne donne pas ce résultat avec un DROP:

Starting Nmap 7.92 ( https://nmap.org ) at 2023-07-09 14:51 Paris, Madrid (heure d’été)
NSE: Loaded 155 scripts for scanning.
NSE: Script Pre-scanning.
Initiating NSE at 14:51
Completed NSE at 14:51, 0.00s elapsed
Initiating NSE at 14:51
Completed NSE at 14:51, 0.00s elapsed
Initiating NSE at 14:51
Completed NSE at 14:51, 0.00s elapsed
Initiating ARP Ping Scan at 14:51
Scanning 192.168.1.105 [1 port]
Completed ARP Ping Scan at 14:51, 0.05s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 14:51
Completed Parallel DNS resolution of 1 host. at 14:51, 0.00s elapsed
Initiating SYN Stealth Scan at 14:51
Scanning machine01 (*.*.*.*) [1 port]
Completed SYN Stealth Scan at 14:51, 0.00s elapsed (1 total ports)
Initiating Service scan at 14:51
Initiating OS detection (try #1) against machine01 (*.*.*.*)
Retrying OS detection (try #2) against machine01 (*.*.*.*)
NSE: Script scanning *.*.*.*.
Initiating NSE at 14:51
Completed NSE at 14:51, 0.00s elapsed
Initiating NSE at 14:51
Completed NSE at 14:51, 0.00s elapsed
Initiating NSE at 14:51
Completed NSE at 14:51, 0.00s elapsed
Nmap scan report for machine01 (*.*.*.*)
Host is up (0.00040s latency).


PORT STATE SERVICE VERSION

65354/tcp closed unknown

MAC Address: A8:A1:59:*:*:*(ASRock Incorporation)
Too many fingerprints match this host to give specific OS details
Network Distance: 1 hop

TRACEROUTE
HOP RTT ADDRESS
1 0.40 ms machine01 (*.*.*.*)
NSE: Script Post-scanning.

Initiating NSE at 14:51
Completed NSE at 14:51, 0.00s elapsed
Initiating NSE at 14:51
Completed NSE at 14:51, 0.00s elapsed
Initiating NSE at 14:51
Completed NSE at 14:51, 0.00s elapsed
Read data files from: C:\Program Files (x86)\Nmap
OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .

Nmap done: 1 IP address (1 host up) scanned in 5.36 seconds
Raw packets sent: 26 (4.068KB) | Rcvd: 10 (880B)

[dezix]

Pour l'utilisateur lambda que je suis et qui n'y entend quasiment rien aux réseaux,
n'y a-t-il pas un moyen de réduire cette réponse à sa plus simple expression : xxxx-unreachable

.... p.ex.une simple option --silent à placer quelque part ?

[lol]

Pour l'utilisateur lambda que je suis et qui n'y entend quasiment rien aux réseaux,
n'y a-t-il pas un moyen de réduire cette réponse à sa plus simple expression : xxxx-unreachable

.... p.ex.une simple option --silent à placer quelque part ?

C'est ce que fait DROP

simply drops the packet silently

En dehors de l'interface locale, un serveur ou une machine, peut très bien n'avoir aucun port d'ouvert en écoute vers l’extérieur du système. Ce sera une machine qui se connecte vers les autres, mais vers laquelle les autres ne se connecte pas.
C'est parfaitement possible. Il se trouve que j'en ai une.

Ce n'est plus un serveur puisqu'il n'y a pas de services...
Un pare-feu est presque inutile puisqu'aucun service n'est à l'écoute.



Moi je continuerais à utiliser REJECT, c'est plus propre et je suis bien aise que mon adresse MAC soit dévoilée, il suffit d'ailleurs de faire un nmap sur le port 443 - qui est évidemment accessible (Sinon à quoi bon avoir un serveur).

And contrary to popular belief, DROP does not give better security than REJECT. It inconveniences legitimate users, and it's effectively no protection from malicious ones.

J'ai modifié tous mes pare-feux pour utiliser REJECT et je m'en porte très bien.
Et je n'ai pas plus de tentatives de connexion illégitimes qu'avant, elles sont même en baisse (Statistiques de la console Crowdsec)

Les tentatives auxquelles je suis confronté sont d'ailleurs très largement portées sur les applications WEB.
Et le pare-feu n'est pas d'une grande utilité (à part limiter le nombre de connexion à la minute).

[dezix]

C'est ce que fait DROP

simply drops the packet silently

... Enfin presque, puisqu'il ne renvoie rien,
et c'est bien cela le problème vis-à-vis des requêtes légitimes,
qui devraient être informées en un délais très court de leur rejet et de sa raison.

Pour me faire une idée,
si on configure SSHD pour être joint uniquement par 1 adresse IP déterminée et sur un port autre que 22,
pour autres ports et IP : DROP ou REJECT ?
Faudrait-il traiter le port 22 spécialement avec un REJECT port-unreachable ?

[vv222]

si on configure SSHD pour être joint uniquement par 1 adresse IP déterminée et sur un port autre que 22,
pour autres ports et IP : DROP ou REJECT ?

Si tu as déjà configuré sshd pour écouter sur un autre port que le 22, tu n’as rien à ajouter côté pare-feu vu que tu n’as de toutes façons rien en écoute sur le port 22.

Tu peux aussi décider de faire preuve d’humour en posant un endlessh en écoute sur le port 22, pour enquiquiner ceux qui viendraient essayer d’entrer par effraction sur ta machine.

[dezix]

Tu peux aussi décider de faire preuve d’humour en posant un endlessh en écoute sur le port 22, pour enquiquiner ceux qui viendraient essayer d’entrer par effraction sur ta machin

Excellent !

[piratebab]

Génial ce paquet endlessh!
Sur ma connexion, je suis surtout embêté par des bots basiques qui cherchent des cibles faciles. Un DROP me va très bien.
Évidement, face à un attaquant humain déterminé, DROP ou REJECT ne feront pas de différence.
Et je n'ai qu'un seul service ouvert sur l'extérieur: un ssh sur une des machines du réseau.
Je préfère blinder cet accès, car je m'en sert pour accéder aux services hébergés sur le réseau LAN (NAS, domotique, video surveillance), et aussi pour faire du ssh sur les autres machines.
Un VPN serait plus adapté, ce sera d'ailleurs la solution que je vais mettre en place à l'aide de mon futur routeur.
Je n'ai pas de politique "zéro trust" sur mon LAN, je dois donc bien bétonner ma connexion ssh externe, ou mon futur VPN.

[lol]

Génial ce paquet endlessh!

Pareil.


Edit: Par contre il faut que ce soit béton ce software faute de quoi on est tout nu...

[dezix]

Tant qu'on y est...

Quelqu'un pourrait-il préciser ce que fait :

Code : Tout sélectionner

ip protocol tcp reject with tcp reset

Je n'ai rien trouvé à ce propos, hormis des exemples sans plus de détails, p.ex :

Code : Tout sélectionner

ct state established accept
ct state invalid drop
tcp reject with tcp reset
reject

... qui doit être une bonne façon de l'utiliser => Après avoir donné une alternative.

Car pour ce que j'en déduis l'envoi d'un " TCP RST " met fin immédiatement à la connexion sans autre forme de procès.

C'est correct ou me gourre-je ?

[vv222]

Par contre il faut que ce soit béton ce software faute de quoi on est tout nu...

Aucun risque de ce côté, il n’implémente pas un vrai service SSH mais juste un faux serveur qui ne fait rien d’autre que de répondre par une bannière interminable. Contourner endlessh ne donnera pas pour autant accès au serveur SSH vu que ce dernier n’écoute de toutes façons pas sur le port 22.

[piratebab]

vv222, ce n'est pas parce qu'un service est minimaliste qu'il n'a pas un faille de sécurité ! Mais bon, je suppose qu'il ne tourne pas avec l'utilisateur root.

[zargos]

Ce n'est plus un serveur puisqu'il n'y a pas de services...
Un pare-feu est presque inutile puisqu'aucun service n'est à l'écoute.

Be si, un exemple: un proxy. Il n'est pas ouvert en accès de l'extérieur mais il accède à l'extérieur.
Autre exemple: un openvas, qui n'est utilisable qu'en console, qui n'a aucun port ouvert ni en interne ni en externe mais qui peut accéder aux deux.
IL y en a bine plus qu'on ne le pense

Quand aux connexions légitime, je ne vois pas en quoi elles poseraient problème avec un DROP plus qu'un RFEJECT étant donné que si elles sont légitimes, par définition, elles n'ont pas à être bloquées .

[zargos]

vv222, ce n'est pas parce qu'un service est minimaliste qu'il n'a pas un faille de sécurité ! Mais bon, je suppose qu'il ne tourne pas avec l'utilisateur root.

Il semble que si. Donc peut être pas si bien finalement

[lol]

vv222, ce n'est pas parce qu'un service est minimaliste qu'il n'a pas un faille de sécurité ! Mais bon, je suppose qu'il ne tourne pas avec l'utilisateur root.

Il semble que si. Donc peut être pas si bien finalement

Aucun problème après installation et test. Ce n'est pas le seul service qui tourne avec root sur une Debian (Spécialement ceux qui ont besoin d'accéder aux ports du serveur).
Même si endlessh tombe il n'y a pas de service ssh derrière, Il n'y a donc pas plus de risque avec que sans.

Be si, un exemple: un proxy. Il n'est pas ouvert en accès de l'extérieur mais il accède à l'extérieur.

Pare-feu inutile donc a moins de ne pas avoir confiance dans ton LAN
A moins que tu n’appelles pare-feu les règles NAT, ESTABLISHED et RELATED.

Quand aux connexions légitime, je ne vois pas en quoi elles poseraient problème avec un DROP plus qu'un RFEJECT étant donné que si elles sont légitimes, par définition, elles n'ont pas à être bloquées.

Je te retourne l'argument. En quoi REJECT poserait plus de problème que DROP sur une connexion légitime ? A part bien sur faire chier quand on a besoin de déboguer...