Ist es besser, -j REJECT oder -j DROP in iptables zu setzen?

Es gibt ein Beispiel für Iptables-Regeln im 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

Vor ein paar Tagen hat mich mein Freund gefragt, warum es REJECTin den letzten drei Regeln so ist. Er sagte mir, dass es DROPstattdessen etwas geben sollte , und er erwähnte etwas über eine bessere Sicherheit im Falle von DROP.

Ich habe also zwei Fragen:

1. Was machen die drei Regeln?

2. Macht es einen Unterschied, wenn ich es dort DROPanbringe REJECT --reject-with? Wenn ja, was ist der Unterschied?

Was machen die drei Regeln?

Diese drei Regeln scheinen ziemlich selbsterklärend zu sein:

1. Eingehende UDP-Pakete mit der ICMP-Meldung "Port nicht erreichbar" ablehnen
2. Eingehende TCP-Pakete mit "tcp reset" ablehnen
3. Eingehende Pakete (eines anderen Protokolls) mit ICMP-Meldung "Protokoll nicht erreichbar" ablehnen

Wenn Sie mehr Details (über UDP / TCP-Pakete, ICMP) suchen, müssen Sie sich mit Netzwerkdokumenten befassen, und vielleicht man iptablesauch mit diesen.

Macht es einen Unterschied, wenn ich dort DROP in place REJECT --reject-with setze? Wenn ja, könnte mir jemand den Unterschied erklären, ich werde es wirklich zu schätzen wissen.

Es macht einen Unterschied. Und entgegen der landläufigen Meinung DROPgibt es keine bessere Sicherheit als REJECT. Es stört legitime Benutzer und schützt effektiv nicht vor böswilligen Benutzern. Dieser Beitrag erklärt die Argumentation im Detail:

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

Ein häufiger Grund für die Verwendung von DROP anstelle von REJECT besteht darin, zu vermeiden, Informationen darüber preiszugeben, welche Ports offen sind. Wenn Sie jedoch Pakete verwerfen, erhalten Sie genau so viele Informationen wie bei der Zurückweisung.

Mit REJECT scannen Sie und kategorisieren die Ergebnisse in "Verbindung hergestellt" und "Verbindung abgelehnt".

Mit DROP kategorisieren Sie die Ergebnisse in "Verbindung hergestellt" und "Zeitüberschreitung der Verbindung".

Der einfachste Scanner verwendet den "Connect" -Aufruf des Betriebssystems und wartet, bis ein Verbindungsversuch abgeschlossen ist, bevor der nächste gestartet wird. Diese Art von Scanner wird durch das Verwerfen von Paketen erheblich verlangsamt. Wenn der Angriff jedoch eine Zeitüberschreitung von 5 Sekunden pro Verbindungsversuch festlegt, ist es möglich, jeden reservierten Port (1..1023) auf einem Computer in nur 1,5 Stunden zu scannen. Scans sind immer automatisiert und ein Angreifer kümmert sich nicht darum, dass das Ergebnis nicht sofort angezeigt wird.

Ein ausgefeilterer Scanner sendet Pakete selbst, anstatt sich auf die TCP-Implementierung des Betriebssystems zu verlassen. Solche Scanner sind schnell, effizient und bei der Wahl von REJECT oder DROP gleichgültig.

FAZIT

DROP bietet keine effektive Barriere gegen feindliche Kräfte, kann jedoch die Ausführung von Anwendungen durch legitime Benutzer drastisch verlangsamen. DROP sollte normalerweise nicht verwendet werden.