Y a-t-il une raison pour laquelle je voudrais avoir
iptables -A INPUT -j REJECT
au lieu de
iptables -A INPUT -j DROP
Y a-t-il une raison pour laquelle je voudrais avoir
iptables -A INPUT -j REJECT
au lieu de
iptables -A INPUT -j DROP
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.
En général, toutes les règles pour les connexions à l'intérieur de votre réseau local devraient utiliser REJECT. Pour l'Internet, à l'exception de l'ident sur certains serveurs, les connexions provenant de l'Internet sont généralement DROPPED.
L'utilisation de DROP donne l'impression que la connexion est établie vers une adresse IP inoccupée. Les scanners peuvent choisir de ne pas continuer à scanner les adresses qui semblent inoccupées. Étant donné que le 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 accepté ou rejeté sur toute adresse fournissant un service SMTP. Cependant, l'utilisation des recherches d'identité par les services SMTP est tombée en désuétude. Il existe des protocoles de chat qui reposent également sur un service d'identification fonctionnel.
EDIT : En utilisant les règles DROP : - Les paquets UDP seront abandonnés et le comportement sera le même que celui d'une connexion à un port non câblé et sans service. - Les paquets TCP renverront un ACK/RST qui est la même réponse qu'un port ouvert sans service. Certains routeurs répondront par un ACK/RST au nom des serveurs qui sont hors service.
En utilisant les règles REJECT, un paquet ICMP est envoyé pour indiquer que le port est indisponible.
Ce n'est pas vrai. Même si la règle indique "DROP", le système répondra au paquet entrant par un TCP SYN/ACK comme s'il était ouvert. Pour vraiment abandonner un paquet, le système doit répondre par un TCP RST/ACK - pour lequel il n'existe pas de règle de pare-feu. Ainsi, la meilleure configuration de pare-feu est celle où seuls les ports sélectionnés sont transférés. Votre règle DROP fera la publicité de votre pare-feu et les scanners de ports sauront que vous faites un pare-feu et continueront à vous harceler dans l'espoir de faire tomber votre pare-feu.
@Dagelf Voir mon édition. Le RST/ACK n'indique pas aux scanners que vous faites un pare-feu. Bien que certains pirates puissent continuer à sonder après cette réponse, cela devrait être basé sur la connaissance de vos services et non sur la réponse du pare-feu. Cela a définitivement réduit le nombre et la durée des scans que je subis.
Ce que je veux dire, c'est qu'il est possible de détecter de l'extérieur si vous faites un pare-feu ou non, du simple fait que votre pile TCP se comporte différemment lorsque vous DROP et lorsque vous n'avez pas de service en cours d'exécution !
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 d'identification. Si vous utilisez REJECT, les clients n'ont pas besoin d'attendre le timeout.
Plus d'informations à ce sujet : http://www.linuxtopia.org/Linux_Firewall_iptables/x4550.html
Je vois beaucoup de réponses contradictoires ici et étant donné qu'il s'agit du premier article dans 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 transféré à un hôte, il ne reçoit pas de réponse. La page de manuel d'IPtables dit qu'il laisse tomber le paquet au sol, c'est-à-dire qu'il ne fait rien avec le paquet.
REJECT diffère de DROP en ce sens qu'il renvoie un paquet, mais la réponse est la même que si un serveur était situé sur l'IP, mais que le port n'était pas en état d'écoute. IPtables enverra un RST/ACK en cas de TCP ou avec UDP un ICMP destination port unreachable.
+1 de ma part, mais les réponses ne sont pas vraiment en désaccord. Elles sont toutes d'accord, d'après ce que je peux voir, sauf pour Dagelf - qui a tort.
Ok, voici une petite astuce pour vous alors : faites un "nmap localhost". Maintenant, choisissez n'importe quel port qui n'est pas "ouvert"... et ajoutez une règle qui "ne fait rien", par ex : "iptables -I INPUT -p tcp --dport 888 -j DROP". Maintenant "nmap localhost" à nouveau. Que voyez-vous ? ...
En général, vous voulez ignorer les sondes des attaquants sur certains ports, ce qui signifie que vous ne devez pas renvoyer le message "connexion refusée". Le message "Connexion refusée" signifie : "il y a un serveur ici", et donne éventuellement plus d'informations, alors que l'abandon d'un paquet ne donne pas d'indices sur les versions des logiciels, les vulnérabilités éventuelles 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.
Sans les règles d'iptables, un port fermé se voit attribuer par défaut la valeur REJECT. Si vous DROPez tous les ports, c'est une bonne alternative (votre hôte semble hors service), mais si vous DROPez seulement des ports spécifiques, vous leur donnez en fait plus d'informations que REJECT. Si quelqu'un utilise une sonde générale comme nmap, les ports spécifiques qui abandonnent des paquets apparaîtront comme "filtrés", ce qui signifie qu'il sait que vous avez un service caché.
Si vous essayez de cacher entièrement l'existence de votre machine, -j DROP
est approprié. Par exemple, vous pouvez l'utiliser pour mettre en place une liste noire.
Si vous essayez de cacher le fait qu'un port est ouvert, vous devez imiter le comportement qui se produirait si le port n'était pas ouvert :
-p tcp -j REJECT --reject-with tcp-reset
-p udp -j REJECT --reject-with icmp-port-unreachable
Si un scanner de port voit que quelques ports abandonnent des paquets alors que la plupart les rejettent, il peut assurer
Et si vous ouvriez quelques ports (22, 25, 53, 80, 443) et que vous supprimiez tout le reste ? Maintenant, que j'aie MySQL, PostgreSQL, SQLite ou Cassandra en cours d'exécution... l'analyseur ne peut pas le dire, n'est-ce pas ?
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.