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:

1. Que font les trois règles?

2. Cela fait-il une différence quand je mets DROPen place REJECT --reject-with? Si oui, quelle est la différence?

Que font les trois règles?

Ces 3 règles semblent assez explicites:

1. Rejeter les paquets UDP entrants avec un message ICMP "port inaccessible"
2. Rejeter les paquets TCP entrants avec "tcp reset"
3. 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é.