REJECT vs DROP lors de l'utilisation d'iptables


89

Y a-t-il une raison pour laquelle je voudrais avoir

iptables -A INPUT -j REJECT

au lieu de

iptables -A INPUT -j DROP

Réponses:


79

En règle générale, utilisez REJECT lorsque vous voulez que l'autre extrémité sache que le port est inaccessible. Utilisez DROP pour les connexions à des hôtes que vous ne voulez pas que les gens voient.

Habituellement, toutes les règles pour les connexions à l'intérieur de votre réseau local doivent utiliser REJECT. Pour Internet, à l’exception d’ident sur certains serveurs, les connexions à partir d’Internet sont généralement abandonnées.

L'utilisation de DROP donne l'impression que la connexion est établie avec une adresse IP inoccupée. Les scanneurs peuvent choisir de ne pas continuer à numériser les adresses qui semblent inoccupées. Étant donné que NAT peut être utilisé pour rediriger une connexion sur le pare-feu, l’existence d’un service bien connu n’indique pas nécessairement l’existence d’un serveur sur une adresse.

Ident doit être transmis ou rejeté pour toute adresse fournissant un service SMTP. Toutefois, l’utilisation des services de recherche d’identité par les serveurs SMTP est devenue inutilisable. Il existe des protocoles de discussion qui reposent également sur un service ident qui fonctionne.

EDIT: Lors de l’utilisation de règles DROP: - Les paquets UDP seront supprimés et le comportement sera identique à la connexion à un port sans pare-feu sans service. - Les paquets TCP renverront un ACK / RST qui correspond à la réponse à laquelle répondra un port ouvert sans service. Certains routeurs répondront avec et ACK / RST pour le compte de serveurs en panne.

Lorsque vous utilisez les règles REJECT, un paquet ICMP est envoyé pour indiquer que le port n'est pas disponible.


5
Ce n'est pas vrai. Même lorsque la règle indique "DROP", le système répondra toujours au paquet entrant avec un TCP / ACK comme s'il était ouvert. Pour réellement supprimer un paquet, le système doit répondre avec un protocole TCP RST / ACK - pour lequel il n'existe pas de règle de pare-feu. En tant que tel, la meilleure configuration de pare-feu est celle où seuls les ports sélectionnés sont transférés. Votre règle DROP annoncera votre pare-feu et les scanneurs de ports sauront que vous faites pare-feu dans le pare-feu et continueront de vous marteler dans l’espoir d’attaquer votre pare-feu.
Dagelf

2
Ce que je veux dire, c’est détectable de l’extérieur si vous utilisez un pare-feu ou non dans le pare-feu, simplement parce que votre pile TCP se comporte différemment lorsque vous utilisez DROP par rapport à lorsque vous n’avez pas de service en cours d’exécution!
Dagelf

2
Cela ne change rien au fait qu'il existe des réseaux de zombies capitalisant sur la différence et surveillant vos ports en conséquence.
Dagelf

1
Quoi que vous fassiez, soyez cohérent. si l'attaquant sélectionne un numéro de port inutilisé et tente de se connecter, il devrait obtenir la même réponse que s'il en avait choisi un que vous bloquez volontairement. donner une réponse différente lui dit qu'il y a quelque chose. Par exemple, s'il peut utiliser purtnumber qui donne une réponse différente pour déterminer le serveur de base de données que vous utilisez, il peut adapter l'injection SQL à ce serveur ...
user313114

5
@Dagelf, où obtenez-vous les informations auxquelles DROP envoie une réponse? C'est une grande nouvelle et va à l'encontre de tout ce que j'ai observé et entendu dire. Avez-vous un lien vers la documentation décrivant ce comportement?
Score_Under

27

La différence est que la cible REJECT envoie une réponse de rejet à la source, tandis que la cible DROP n’envoie rien.

Cela peut être utile, par exemple, pour le service ident. Si vous utilisez REJECT, les clients n'ont pas besoin d'attendre le délai d'attente.

Plus à ce sujet: http://www.linuxtopia.org/Linux_Firewall_iptables/x4550.html


2
La cible DROP n'envoie rien. Vérifiez mon commentaire sur la réponse acceptée et allez rechercher le sujet vous-même si les détails vous intéressent!
Dagelf

8

Habituellement, vous voulez ignorer les sondes des attaquants sur certains ports, ce qui signifie que vous ne voulez pas renvoyer «connexion refusée». 'Connexion refusée' signifie: 'il y a un serveur ici' et donne éventuellement plus d'informations, tandis que laisser tomber un paquet ne donne aucune indication sur les versions du logiciel, les vulnérabilités possibles ou même sur le fait qu'un serveur vous écoute sur IP.

Ce qui précède est l’une des principales raisons d’utiliser DROP au lieu de REJECT.


6
Sans règles iptables, la valeur par défaut du port fermé est REJECT. Si vous abandonnez tous les ports, c'est une excellente solution (votre hôte apparaît en bas), mais si vous abandonnez uniquement des ports spécifiques, vous leur donnez plus d'informations que REJECT. Si quelqu'un utilise une sonde globale telle que nmap, des ports spécifiques rejetant des paquets apparaîtront comme "filtrés", ce qui signifie qu'ils savent que vous avez un service que vous cachez.
Raptor007

7

Je vois beaucoup de réponses contradictoires ici et étant donné que c'est le premier article de Google avec les bons mots clés; voici l'explication correcte.
C'est simple:

DROP ne fait rien du tout avec le paquet. Il n'est pas transmis à un hôte, il ne reçoit pas de réponse. La page de manuel d'IPtables indique qu'elle laisse tomber le paquet sur le sol, c'est-à-dire qu'elle ne fait rien avec le paquet.

REJECT diffère de DROP par le fait qu’il renvoie un paquet, mais la réponse est comme si un serveur était situé sur l’IP, mais que le port n’était pas à l’écoute. IPtables enverra un RST / ACK en cas de protocole TCP ou avec UDP un port de destination ICMP inaccessible.


2
+1 de moi, mais les réponses ne sont pas vraiment en désaccord. Autant que je sache, ils sont tous d'accord, à l'exception de Dagelf - qui a tort.
MadHatter

Ok, voici un petit truc pour vous alors: faites un "nmap localhost". Choisissez maintenant un port qui n'est pas "ouvert" ... et ajoutez une règle qui "ne fait rien", par exemple: "iptables -I INPUT -p tcp --dport 888 -j DROP". Maintenant, "nmap localhost" à nouveau. Que vois-tu? ...
Dagelf

4

Si vous essayez de cacher totalement l'existence de votre machine, -j DROPc'est approprié. Par exemple, vous pouvez utiliser ceci pour mettre en place une liste noire.

Si vous essayez de cacher le fait qu'un port est ouvert, vous devriez imiter le comportement qui se produirait si le port n'était pas ouvert:

  • TCP: -p tcp -j REJECT --reject-with tcp-reset
  • UDP: -p udp -j REJECT --reject-with icmp-port-unreachable

Si un scanner de ports constate que quelques ports éliminent des paquets alors que la plupart les rejettent, il peut en déduire que les paquets supprimés se trouvent sur des ports ouverts mais masqués.


Que se passe-t-il si vous ouvrez quelques ports (22, 25, 53, 80, 443) et que vous renversez tout le reste? Maintenant si MySQL, PostgreSQL, SQLite ou Cassandra sont en cours d'exécution ... le scanner ne peut pas le dire, n'est-ce pas?
Alexis Wilke

@AlexisWilke Dans ce cas, la seule information supplémentaire que vous fournissez au scanner de port est que vous avez mis en place une sorte de pare-feu avec une stratégie DROP par défaut.
Raptor007

0

Malgré de nombreuses réponses correctes, juste mes deux centimes:

Voici une courte PoC FW.IDS-DROP-vs-REJECT de moi au sujet en ce qui concerne les règles pour ban-système (pare-feu, IDS, etc.).

Prochainement:

  • DROP peut être utilisé pour les intrus récidivants, si tous les ports sont interdits (on dirait que le serveur est en panne du côté intrus)
  • REJECT --reject-with tcp-reset est le meilleur choix pour l'interdiction multi-ports, car il semble se comporter comme un véritable port fermé
  • si certains ports répondent (l'intrus sait que l'hôte est en vie), DROPet REJECT(sans tcp-reset) donnera à l'intrus un "signal" indiquant qu'il y a un blocage (ce qui pourrait l'inciter à poursuivre "l'attaque" dans l'espoir de fournir les données requises à un moment donné)

-5

Oui, utiliser DROP est inutile. Utilisez REJECT.

Même lorsque la règle dit "DROP", le système répond toujours à un SYN entrant avec un TCP RST / ACK - qui est le comportement par défaut pour les ports sans service en cours d'exécution. (tcpdump et al n'enregistrent pas cela.)

Si un service est en cours d'exécution, le SYN est rencontré avec TCP SYN / ACK.

Parce que DROP ne répond pas comme d'habitude avec un TCP / ACK TCP, mais avec un RST / ACK, votre règle DROP annoncera votre pare-feu et les scanners de ports sauront que vous utilisez un pare-feu et risquent de continuer à vous marteler dans l'espoir. d'attraper votre pare-feu vers le bas.

C'est maintenant que nmap peut signaler "filtré" au lieu de "fermé", par exemple:

$ nmap localhost

Starting Nmap 6.40 ( http://nmap.org ) at 2018-03-14 00:21 SAST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0000060s latency).
Not shown: 986 closed ports
PORT     STATE SERVICE
21/tcp   open  ftp
53/tcp   open  domain
80/tcp   open  http

Nmap done: 1 IP address (1 host up) scanned in 1.60 seconds

$ iptables -I INPUT -p tcp --dport 1111 -j DROP
$ nmap localhost

Starting Nmap 6.40 ( http://nmap.org ) at 2018-03-14 00:21 SAST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0000060s latency).
Not shown: 986 closed ports
PORT     STATE SERVICE
21/tcp   open  ftp
53/tcp   open  domain
80/tcp   open  http
1111/tcp filtered lmsocialserver

Nmap done: 1 IP address (1 host up) scanned in 1.60 seconds

$ iptables -D INPUT 1

En tant que tel, la seule configuration de pare-feu "invisible" est celle dans laquelle un périphérique dédié se place entre vos périphériques et transmet uniquement les ports de manière sélective.

Si vous voulez vraiment bousiller les scanners de base, vous pouvez utiliser les connexions TCP de TARPIT, ce qui définit la fenêtre TCP sur 0 afin qu'aucune donnée ne puisse être transférée après l'ouverture de la connexion, en ignorant les demandes de fermeture, ce qui signifie que le scanneur doit attendre pour que le délai de connexion soit dépassé, s'il veut en être sûr. Mais il est facile pour un attaquant de détecter cela et de faire en sorte que son délai d'attente soit très court.

Tout bien considéré, vous ferez probablement mieux d'utiliser simplement REJECT - ou de mettre un périphérique de transfert de port dédié entre votre serveur et Internet.

Vous pouvez également exécuter des services sur vos ordinateurs connectés à Internet ne nécessitant pas de pare-feu.

En règle générale, REJECT est préférable pour les serveurs Web, car le service qui essaie d'y accéder (probablement le plus souvent, vous obtiendrez rapidement une réponse) et les utilisateurs ou les autres services ne seront plus obligés de se demander s'il y a une panne de réseau.


5
Cette réponse est incorrecte. Avec tcpdump, il est facile de montrer que la règle DROP aura pour conséquence que le système n’enverra AUCUNE réponse - comme on pourrait s’y attendre. Et votre déclaration "Pour vraiment abandonner un paquet, le système doit répondre avec un TCP RST / ACK" n'a pas de sens, toute réponse n’est évidemment pas "abandonner réellement un paquet". Si vous "abandonnez vraiment" un paquet, vous ne répondez pas et c'est manifestement l'effet de la règle DROP.
Juliane Holzt

3
Pourriez-vous fournir une source pour l'allégation qui DROPémettra un SYN/ACK? Je n'ai jamais vu cela sur mes machines.
motobói

2
@Dagelf Votre article dit "DROP (aka DENY, BLACKHOLE) Empêche le passage d'un paquet. N'envoie pas de réponse."
JeanT

Il n'envoie pas la réponse normale, mais il en envoie une comme expliqué, peu importe.
Dagelf

3
Le document auquel vous créez un lien indique " DROP ... N'envoyez pas de réponse " et ne permet pas, autant que je sache, d'appuyer votre réclamation DROPrenvoyant a SYN/ACK. Moi aussi, je n'ai jamais vu ce comportement sous aucune version de iptables. Si votre source soutient votre demande, il serait très utile de la voir. certes, les vidages de paquets que je viens de faire ne corroborent pas votre demande.
MadHatter
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.