Question REJECT vs DROP lors de l'utilisation d'iptables


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

iptables -A INPUT -j REJECT

au lieu de

iptables -A INPUT -j DROP

80
2017-07-04 09:49


origine




Réponses:


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 des 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épondent avec et ACK / RST pour le compte de serveurs en panne.

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


72
2017-07-04 16:40



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 port sauront que vous faites pare-feu dans le pare-feu et continueront à vous marteler dans l’espoir d’attaquer votre pare-feu. - Dagelf
@Dagelf Voir mon édition. Le fichier RST / ACK n'indique pas aux scanneurs que vous parez pare-feu. Bien que certains pirates informatiques puissent continuer à sonder après cette réponse, cela devrait être basé sur la connaissance de vos services et non de la réponse du pare-feu. Il a définitivement perdu le nombre et la longueur des analyses que j'ai subies. - BillThor
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
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
@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


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


25
2017-07-04 09:59



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


Habituellement, vous voulez ignorer sondes des attaquants vers 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 de logiciel, les vulnérabilités possibles ou même sur le fait qu'un serveur écoute votre IP.

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


8
2017-07-04 13:09



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


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 de 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 TCP ou avec UDP un port de destination ICMP inaccessible.


6
2018-01-11 12:29



+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


Si vous essayez de cacher complètement l'existence de votre machine, -j DROPest 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 rejettent des paquets alors que la plupart les rejettent, il peut en déduire que les paquets rejetés se trouvent sur des ports ouverts mais masqués.


3
2017-08-13 01:29



Que faire si vous ouvrez quelques ports (c'est-à-dire 22, 25, 53, 80, 443), puis supprimez 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


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

Voici un court 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), DROP et REJECT (sans pour autant tcp-reset) donnera à l'intrus un "signal" indiquant qu'il y a un blocage (cela pourrait donc l'inciter à poursuivre "l'attaque" dans l'espoir de fournir les données requises à un moment donné)

0
2017-09-20 16:49





Oui, utiliser DROP est inutile. Utilisez REJECT.

Même lorsque la règle indique "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.

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 des connexions TCP / IP 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 feriez 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 plus souvent qu'autrement) obtiendra rapidement une réponse et les utilisateurs ou autres services ne seront plus obligés de se demander s'il y a une panne de réseau.


-3



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, car rien ne signifie évidemment que "ne pas vraiment laisser tomber 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
Pourriez-vous fournir une source pour l'allégation selon laquelle DROP émettra un SYN/ACK? Je n'ai jamais vu cela sur mes machines. - motobói
@Dagelf Votre article dit "DROP (aka DENY, BLACKHOLE) Interdit à un paquet de passer. N'envoie aucune réponse." - JeanT
Il n'envoie pas la réponse normale, mais il en envoie une comme expliqué, peu importe. - Dagelf
Le document auquel vous créez un lien dit "DROP ... N'envoie pas de réponse"et, autant que je sache, ne corrobore votre affirmation selon laquelle DROP renvoie un 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