Est-il préférable de définir -j REJECT ou -j DROP dans iptables?

Il y a un exemple de règles iptables sur archlinux wiki:

# Generated by iptables-save v1.4.18 on Sun Mar 17 14:21:12 2013
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:TCP - [0:0]
:UDP - [0:0]
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -p icmp -m icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -p udp -m conntrack --ctstate NEW -j UDP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j TCP
-A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p tcp -j REJECT --reject-with tcp-reset
-A INPUT -j REJECT --reject-with icmp-proto-unreachable
COMMIT
# Completed on Sun Mar 17 14:21:12 2013

Il y a quelques jours, mon ami m'a demandé pourquoi il y a REJECTtrois règles. Il m'a dit qu'il devrait y en avoir à la DROPplace, et il a parlé de l'amélioration de la sécurité en cas de DROP.

Donc, j'ai deux questions:

Que font les trois règles?
Cela fait-il une différence quand je mets DROPen place REJECT --reject-with? Si oui, quelle est la différence?

— Mikhail Morfikov
source

Question similaire sur la sécurité de l'information : rejeter les paquets IP avec une erreur ICMP, ou simplement les supprimer?

— Gilles 'SO- arrête d'être méchant'

Que font les trois règles?

Ces 3 règles semblent assez explicites:

Rejeter les paquets UDP entrants avec un message ICMP "port inaccessible"
Rejeter les paquets TCP entrants avec "tcp reset"
Rejeter les paquets entrants (de tout autre protocole) avec le message ICMP "protocole inaccessible"

Si vous recherchez plus de détails (sur les paquets UDP / TCP, ICMP), vous devez vous plonger dans les documents de réseau, et peut-être man iptablesaussi.

Est-ce que cela fait une différence quand je mets là DROP en place REJECT --reject-with? Si oui, quelqu'un pourrait-il m'expliquer la différence, je l'apprécierai vraiment.

Cela fait une différence. Et contrairement à la croyance populaire, DROPne donne pas une meilleure sécurité que REJECT. Cela dérange les utilisateurs légitimes, et en réalité, il ne protège pas des utilisateurs malveillants. Cet article explique le raisonnement en détail:

http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject

Une raison commune d'utiliser DROP plutôt que REJECT est d'éviter de divulguer des informations sur les ports ouverts. Cependant, le fait de supprimer des paquets indique exactement autant d'informations que le rejet.

Avec REJECT, vous effectuez votre analyse et catégorisez les résultats en "connexion établie" et "connexion rejetée".

Avec DROP, vous catégorisez les résultats en "connexion établie" et "connexion expirée".

Le scanner le plus trivial utilisera l'appel "connect" du système d'exploitation et attendra qu'une tentative de connexion soit terminée avant de commencer la suivante. Ce type de scanner sera considérablement ralenti par le rejet de paquets. Toutefois, si l'attaque fixe un délai d'expiration de 5 secondes par tentative de connexion, il est possible d'analyser chaque port réservé (1..1023) sur une machine en à peine 1,5 heure. Les analyses sont toujours automatisées, et un attaquant ne se soucie pas de savoir que le résultat n'est pas immédiat.

Un scanner plus sophistiqué enverra les paquets lui-même plutôt que de compter sur la mise en œuvre TCP du système d'exploitation. De tels scanners sont rapides, efficaces et indifférents au choix de REJECT ou DROP.

CONCLUSION

DROP n'offre aucune barrière efficace aux forces hostiles, mais peut considérablement ralentir les applications exécutées par des utilisateurs légitimes. DROP ne devrait normalement pas être utilisé.

— Arrêtez le mal en cours à Monica
source

@janos - pourriez-vous en dire un peu plus sur ce qui se passe réellement lorsqu'un paquet atteint chacune des trois règles?

— Mikhail Morfikov

@ Kiwy - Lisez le lien et essayez vous-même. DROP ne donne pas une meilleure sécurité que REJECT. Cela dérange les utilisateurs légitimes, et en réalité, il ne protège pas des utilisateurs malveillants. En effet, les utilisateurs légitimes souffrent d'une connexion lente en attendant l'expiration du délai de connexion et les pirates informatiques configurent simplement leurs outils pour ne pas attendre un délai d'expiration. le fait que la connexion soit lente (en raison de l'attente d'un délai d'attente) indique que votre serveur est présent et doté d'un pare-feu.

— Panther

Je ne vais pas avec cette conclusion. Reject génère une réponse ICMP pouvant être analysée. Sur la base de cette analyse, de bons moteurs d’attaque peuvent déduire le système d’exploitation utilisé. Donc, sur un système où tous les ports sont connus, drop pourrait être mieux. Cela s'applique aux serveurs dans un environnement de production.

— Nils

Un pare-feu qui ne transmet que certains ports est encore mieux. DROP un REJECT ne signifie pas qu’aucun service n’exécute la première place. De nombreux scanners de ports désignent votre hôte comme une cible potentielle pour les analyses futures, dans l’espoir d’attraper votre pare-feu s’ils y trouvent des REJETS ou des DROPS, car les deux peuvent être détectés de l’extérieur. chiark.greenend.org.uk/~peterb/network/drop-vs-reject

— Dagelf

Notez que le texte cité contient un paragraphe supplémentaire, une mise à jour, qui indique que DROP est préférable si vous avez une attaque par DDoS, ce qui est relativement rare, mais lorsque cela se produit, il est probablement bon de l’avoir ... qu’en pensez-vous?

— Alexis Wilke