Solution 1 :
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 aux 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 de l'identification sur certains serveurs, les connexions depuis Internet sont généralement ABANDONNÉES.
L'utilisation de DROP donne l'impression que la connexion se fait vers une adresse IP inoccupée. Les scanners peuvent choisir de ne pas continuer à scanner les adresses qui semblent inoccupées. Etant 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.
L'identificateur doit être transmis ou rejeté sur toute adresse fournissant un service SMTP. Cependant, l'utilisation des recherches d'identité par les serveurs SMTP est tombée en désuétude. Il existe des protocoles de chat qui reposent également sur un service d'identification fonctionnel.
EDIT :lors de l'utilisation des règles DROP :- les paquets UDP seront abandonnés et le comportement sera le même que pour la connexion à un port sans pare-feu sans service. - les paquets TCP renverront un ACK/RST qui est la même réponse qu'un port ouvert sans service sur elle répondra avec. Certains routeurs répondront avec et ACK/RST au nom des serveurs qui sont en panne.
Lors de l'utilisation des règles REJECT, un paquet ICMP est envoyé indiquant que le port n'est pas disponible.
Solution 2 :
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 ex. pour le service d'identification. Si vous utilisez REJECT, les clients n'ont pas besoin d'attendre le délai d'expiration.
En savoir plus :http://www.linuxtopia.org/Linux_Firewall_iptables/x4550.html
Solution 3 :
Habituellement, vous voulez ignorer les sondes des attaquants vers certains ports, ce qui signifie que vous ne voulez pas renvoyer une "connexion refusée". « Connexion refusée » signifie :« il y a un serveur ici », et donne peut-être plus d'informations, alors que le fait de laisser tomber un paquet ne donne pas d'indices sur les versions logicielles, les vulnérabilités possibles ou même 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.
Solution 4 :
Je vois beaucoup de réponses contradictoires ici et étant donné qu'il s'agit du premier article de Google avec les bons mots-clés; voici la bonne explication.
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'il laisse tomber le paquet sur le sol, c'est-à-dire qu'il ne fait rien avec le paquet.
REJECT diffère de DROP en ce qu'il renvoie un paquet, mais la réponse est comme si un serveur était situé sur l'IP, mais n'avait pas le port dans un état d'écoute. IPtables enverra un RST/ACK en cas de TCP ou avec UDP un port de destination ICMP inaccessible.
Solution 5 :
Si vous essayez de cacher entièrement l'existence de votre machine, -j DROP est approprié. Par exemple, vous pouvez l'utiliser pour implémenter une liste noire.
Si vous essayez de masquer le fait qu'un port est ouvert, vous devez 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 analyseur de port constate que quelques ports rejettent des paquets alors que la plupart les rejettent, il peut supposer que les paquets rejetés se trouvent sur des ports ouverts mais masqués.