Cet article est un article miroir de traduction automatique, veuillez cliquer ici pour accéder à l’article original.

Vue: 11350|Répondre: 0

[Linux] Différence entre ABANDONNER et REJETER

[Copié le lien]
Publié sur 02/02/2016 10:33:58 | | |

Il existe deux types d’actions de politique dans le pare-feu : DROP et REJECT, et les différences sont les suivantes :
1. L’action DROP consiste simplement à rejeter directement les données sans retour de réponse. Si le client attend le délai d’attente, il peut facilement se retrouver bloqué par le pare-feu.
2. L’action REJECT retournera un paquet rejeté (terminé) (TCP FIN ou UDP-ICMP-PORT-UNREACHABLE) de manière plus polie, et rejettera explicitement l’action de connexion de l’autre partie. La connexion est immédiatement déconnectée, et le client pense que l’hôte accédé n’existe pas. REJECT possède certains paramètres de retour dans IPTABLES, tels que ICMP port-unreachable, ICMP echo-reply ou tcp-reset (ce paquet demandera à l’autre partie de couper la connexion).

Il n’est pas définitif qu’il soit approprié d’utiliser DROP ou REJECT, car les deux sont effectivement applicables. REJECT est un type plus conforme
et plus facile à diagnostiquer et à déboguer des problèmes de réseau/pare-feu dans un environnement réseau contrôlé ; Et DROP fournit
Sécurité du pare-feu plus élevée et légers gains d’efficacité, mais possiblement en raison de la gestion non standardisée (peu conforme aux spécifications de connexion TCP) de DROP
Cela peut entraîner des problèmes inattendus ou difficiles à diagnostiquer sur votre réseau. Car bien que DROP interrompe unilatéralement la connexion, il ne revient pas au bureau
Par conséquent, le client de connexion attendra passivement que la session TCP expire pour déterminer si la connexion est réussie, afin de faire progresser le réseau interne de l’entreprise
Certains programmes ou applications clients nécessitent la prise en charge du protocole IDENT (port TCP 113, RFC 1413) si vous l’empêchez
Si le pare-feu applique la règle DROP sans préavis, toutes les connexions similaires échoueront, et il sera difficile de déterminer si c’est dû au délai d’attente
Le problème vient du pare-feu ou de la défaillance du périphérique/ligne réseau.

Un peu d’expérience personnelle : lors du déploiement d’un pare-feu pour une entreprise interne (ou un réseau partiellement fiable), il vaut mieux utiliser un REJET plus gentleman
méthode, il en va de même pour les réseaux qui doivent fréquemment modifier ou déboguer les règles ; Pour les pare-feux pour Internet/extranets dangereux,
Il est nécessaire d’utiliser une méthode DROP plus brutale mais sûre, qui peut ralentir la progression (et la difficulté, du moins, DROP) de l’attaque de piratage dans une certaine mesure
peut les rendre plus longs dans le balayage des ports TCP-Connect).




Précédent:Cas d’attaque DOS basé sur le port UDP 80
Prochain:La méthode C# Process.Start() est expliquée en détail
Démenti:
Tous les logiciels, supports de programmation ou articles publiés par Code Farmer Network sont uniquement destinés à l’apprentissage et à la recherche ; Le contenu ci-dessus ne doit pas être utilisé à des fins commerciales ou illégales, sinon les utilisateurs assumeront toutes les conséquences. Les informations sur ce site proviennent d’Internet, et les litiges de droits d’auteur n’ont rien à voir avec ce site. Vous devez supprimer complètement le contenu ci-dessus de votre ordinateur dans les 24 heures suivant le téléchargement. Si vous aimez le programme, merci de soutenir un logiciel authentique, d’acheter l’immatriculation et d’obtenir de meilleurs services authentiques. En cas d’infraction, veuillez nous contacter par e-mail.

Mail To:help@itsvse.com