REJECT vs DROP bei Verwendung von Iptables

89

Gibt es einen Grund, warum ich haben möchte

iptables -A INPUT -j REJECT

Anstatt von

iptables -A INPUT -j DROP
Mike B
quelle

Antworten:

79

Verwenden Sie im Allgemeinen REJECT, wenn Sie möchten, dass das andere Ende weiß, dass der Port nicht erreichbar ist. Verwenden Sie DROP für Verbindungen zu Hosts, die die Benutzer nicht sehen sollen.

Normalerweise sollten alle Regeln für Verbindungen in Ihrem LAN REJECT verwenden. Im Internet werden Verbindungen aus dem Internet mit Ausnahme von ident auf bestimmten Servern normalerweise DROPPED.

Bei Verwendung von DROP wird die Verbindung anscheinend zu einer nicht besetzten IP-Adresse hergestellt. Scanner können festlegen, dass Adressen, die nicht belegt sind, nicht weiter durchsucht werden. Da NAT verwendet werden kann, um eine Verbindung auf der Firewall umzuleiten, weist das Vorhandensein eines bekannten Dienstes nicht unbedingt auf das Vorhandensein eines Servers auf einer Adresse hin.

Ident sollte an jede Adresse weitergegeben oder abgelehnt werden, die den SMTP-Dienst bereitstellt. Die Verwendung von Ident-Lookups durch SMTP-Serves wurde jedoch nicht mehr verwendet. Es gibt Chat-Protokolle, die sich auch auf einen funktionierenden Identitätsdienst stützen.

BEARBEITEN: Bei Verwendung von DROP-Regeln: - UDP-Pakete werden verworfen, und das Verhalten entspricht dem einer Verbindung mit einem nicht Firewall-fähigen Port ohne Dienst. - TCP-Pakete geben ein ACK / RST zurück. Dies entspricht der Antwort, mit der ein offener Port ohne Dienst antwortet. Einige Router antworten mit und ACK / RST im Namen von Servern, die außer Betrieb sind.

Bei Verwendung von REJECT-Regeln wird ein ICMP-Paket gesendet, das angibt, dass der Port nicht verfügbar ist.

BillThor
quelle
5
Das ist nicht wahr. Auch wenn die Regel "DROP" lautet, antwortet das System auf das eingehende Paket mit einem TCP-SYN / ACK, als wäre es offen. Um ein Paket wirklich zu verwerfen, muss das System mit einem TCP-RST / ACK antworten - für das es keine Firewall-Regel gibt. Das beste Firewall-Setup ist daher ein Setup, bei dem nur ausgewählte Ports weitergeleitet werden. Ihre DROP-Regel macht Werbung für Ihre Firewall, und Port-Scanner erkennen, dass Sie eine Firewall verwenden, und hämmern Sie weiter in der Hoffnung, dass Ihre Firewall nicht mehr funktioniert.
Dagelf
2
Mein Punkt ist, es ist von außen erkennbar, ob Sie eine Firewall verwenden oder nicht, da sich Ihr TCP-Stack bei DROP anders verhält als bei einem Dienst, der überhaupt nicht ausgeführt wird!
Dagelf
2
Ändert nichts an der Tatsache, dass es Botnets gibt, die den Unterschied ausnutzen und folglich Ihre Ports überwachen.
Dagelf
1
was auch immer du tust, sei konsequent. Wenn der Angreifer eine nicht verwendete Portnummer auswählt und versucht, eine Verbindung herzustellen, sollte er die gleiche Antwort erhalten, als hätte er eine ausgewählt, die Sie absichtlich blockieren. Eine andere Antwort sagt ihm, dass etwas da ist. Zum Beispiel kann er mit Hilfe von purtnumber eine andere Antwort geben, um zu bestimmen, welchen Datenbankserver Sie verwenden. Er kann die SQL-Injection an diesen Server
anpassen
5
@Dagelf Woher bekommst du die Information, dass DROP eine Antwort sendet? Das ist eine große Neuigkeit und widerspricht allem, was ich beobachtet und erfahren habe. Haben Sie einen Link zu der Dokumentation, die dieses Verhalten beschreibt?
Score_Under
27

Der Unterschied besteht darin, dass das REJECT-Ziel eine Ablehnungsantwort an die Quelle sendet, während das DROP-Ziel nichts sendet.

Dies kann zB für den Ident-Dienst hilfreich sein. Wenn Sie REJECT verwenden, müssen die Clients nicht auf eine Zeitüberschreitung warten.

Weitere Informationen hierzu: http://www.linuxtopia.org/Linux_Firewall_iptables/x4550.html

Zizzencs
quelle
2
Das DROP-Ziel sendet nichts. Überprüfe meinen Kommentar zu der akzeptierten Antwort und recherchiere das Thema selbst, wenn du an den Details interessiert bist!
Dagelf
8

Normalerweise möchten Sie Sonden von Angreifern zu bestimmten Ports ignorieren , mit denen Sie "Verbindung abgelehnt" nicht zurücksenden möchten. "Verbindung abgelehnt" bedeutet: "Es ist ein Server hier" und möglicherweise werden mehr Informationen preisgegeben, wohingegen das Verwerfen eines Pakets keine Hinweise auf Softwareversionen, mögliche Schwachstellen oder sogar die Tatsache gibt, dass ein Server Ihre IP abhört.

Dies ist einer der Hauptgründe für die Verwendung von DROP anstelle von REJECT.

wzzrd
quelle
6
Ohne iptables-Regeln ist ein geschlossener Port standardmäßig REJECT. Wenn Sie jeden Port FALLEN lassen, ist dies eine gute Alternative (Ihr Host scheint nicht erreichbar zu sein). Wenn Sie jedoch nur bestimmte Ports FALLEN lassen, geben Sie ihnen tatsächlich mehr Informationen als REJECT. Wenn jemand eine Blanket-Sonde wie nmap verwendet, werden bestimmte Ports, über die Pakete verworfen werden, als "gefiltert" angezeigt. Dies bedeutet, dass er weiß, dass Sie dort einen Dienst haben, den Sie verstecken.
Raptor007
7

Ich sehe hier viele widersprüchliche Antworten und dies ist der erste Artikel in Google mit den richtigen Keywords. Hier ist die richtige Erklärung.
Es ist ganz einfach:

DROP macht gar nichts mit dem Paket. Es wird nicht an einen Host weitergeleitet, es wird nicht beantwortet. Die Manpage von IPtables sagt, dass es das Paket auf den Boden fallen lässt, dh es macht nichts mit dem Paket.

REJECT unterscheidet sich von DROP dadurch, dass es ein Paket zurücksendet, die Antwort jedoch so ist, als ob sich ein Server auf der IP befindet, der Port jedoch nicht empfangsbereit ist. IPtables sendet ein RST / ACK, wenn TCP oder UDP einen nicht erreichbaren ICMP-Zielport hat.

Ecko
quelle
2
+1 von mir, aber die Antworten stimmen nicht wirklich überein. Soweit ich sehen kann, sind sich alle einig, mit Ausnahme von Dagelf, der sich irrt.
MadHatter
Okay, hier ist ein kleiner Trick für Sie: Machen Sie einen "nmap localhost". Wählen Sie nun einen Port, der nicht "offen" ist, und fügen Sie eine Regel hinzu, die "nichts tut", z. B .: "iptables -I INPUT -p tcp --dport 888 -j DROP". Nun wieder "nmap localhost". Was siehst du? ...
Dagelf
4

Wenn Sie versuchen, die Existenz Ihrer Maschine vollständig zu verbergen, -j DROPist dies angemessen. Sie können dies beispielsweise verwenden, um eine Blacklist zu implementieren.

Wenn Sie versuchen, die Tatsache zu verbergen, dass ein Port geöffnet ist, sollten Sie das Verhalten nachahmen, das auftreten würde, wenn der Port nicht geöffnet wäre:

  • TCP: -p tcp -j REJECT --reject-with tcp-reset
  • UDP: -p udp -j REJECT --reject-with icmp-port-unreachable

Wenn ein Port-Scanner feststellt, dass einige Ports Pakete verwerfen, die meisten jedoch ablehnen, kann er davon ausgehen, dass sich die verworfenen Pakete an offenen, aber versteckten Ports befinden.

Raptor007
quelle
Was ist, wenn Sie ein paar Ports öffnen (dh 22, 25, 53, 80, 443) und dann alles andere fallen lassen? Nun, ob MySQL, PostgreSQL, SQLite oder Cassandra ausgeführt wird, kann der Scanner nicht erkennen, oder?
Alexis Wilke
@AlexisWilke In diesem Fall besteht die einzige zusätzliche Information, die Sie dem Port-Scanner geben, darin, dass eine Art Firewall mit einer Standard-DROP-Richtlinie vorhanden ist.
Raptor007
0

Trotz vieler richtiger Antworten nur meine zwei Cent:

Hier ist ein kurzer PoC FW.IDS-DROP-vs-REJECT von mir zu dem Thema bezüglich der Regeln für Ban-Systeme (Firewall, IDS, etc).

Kurz:

  • DROP kann für wiederkehrende Eindringlinge verwendet werden, wenn alle Ports gesperrt sind (so sieht es aus, als wäre der Server auf der Eindringlingseite ausgefallen)
  • REJECT --reject-with tcp-reset ist die beste Wahl für das Sperren mehrerer Ports, da es sich anscheinend wie ein wirklich geschlossener Port verhält
  • Wenn einige Ports antworten (der Eindringling weiß, dass der Host am Leben ist) DROPund REJECT(ohne tcp-reset) dem Eindringling ein "Signal" geben, dass etwas Blockierendes vorhanden ist (was ihn dazu anregen könnte, den "Angriff" fortzusetzen, in der Hoffnung, die erforderlichen Daten bereitzustellen) irgendwann)
sebres
quelle
-5

Ja, die Verwendung von DROP ist sinnlos. Verwende REJECT.

Auch wenn die Regel "DROP" lautet, antwortet das System auf eine eingehende SYN mit einem TCP-RST / ACK. Dies ist das Standardverhalten für Ports, an denen keine Dienste ausgeführt werden. (tcpdump et al. protokollieren dies nicht.)

Wenn ein Dienst ausgeführt wird, wird die SYN mit TCP SYN / ACK erfüllt.

Da der DROP nicht wie gewohnt mit einem TCP-SYN / ACK reagiert, sondern mit einem RST / ACK, wird Ihre DROP-Regel für Ihre Firewall werben, und Port-Scanner werden wissen, dass Sie eine Firewall verwenden, und Sie werden möglicherweise weiterhin in die Hoffnung getrieben Ihre Firewall zu fangen.

Dies ist nun nmap kann zum Beispiel "gefiltert" anstatt "geschlossen" melden:

$ nmap localhost

Starting Nmap 6.40 ( http://nmap.org ) at 2018-03-14 00:21 SAST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0000060s latency).
Not shown: 986 closed ports
PORT     STATE SERVICE
21/tcp   open  ftp
53/tcp   open  domain
80/tcp   open  http

Nmap done: 1 IP address (1 host up) scanned in 1.60 seconds

$ iptables -I INPUT -p tcp --dport 1111 -j DROP
$ nmap localhost

Starting Nmap 6.40 ( http://nmap.org ) at 2018-03-14 00:21 SAST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0000060s latency).
Not shown: 986 closed ports
PORT     STATE SERVICE
21/tcp   open  ftp
53/tcp   open  domain
80/tcp   open  http
1111/tcp filtered lmsocialserver

Nmap done: 1 IP address (1 host up) scanned in 1.60 seconds

$ iptables -D INPUT 1

Daher ist die einzige "unsichtbare" Firewall-Konfiguration eine, bei der sich ein dediziertes Gerät zwischen Ihren Geräten befindet und Ports nur selektiv weiterleitet.

Wenn Sie sich wirklich mit den grundlegenden Scannern herumschlagen möchten, können Sie TCP-Verbindungen TARPITIEREN, wodurch das TCP-Fenster auf 0 gesetzt wird, sodass keine Daten übertragen werden können, nachdem die Verbindung geöffnet wurde. Dabei werden Anforderungen zum Schließen der Verbindung ignoriert, sodass der Scanner warten muss für die Verbindung Timeout auftreten, wenn es sicher sein will. Für einen Angreifer ist es jedoch trivial, dies zu erkennen und seine Auszeit zu verkürzen.

Alles in allem ist es wahrscheinlich das Beste, wenn Sie REJECT verwenden - oder ein dediziertes Port-Weiterleitungsgerät zwischen Ihrem Server und dem Internet einrichten.

Oder führen Sie einfach Dienste auf Ihren mit dem Internet verbundenen Computern aus, für die keine Firewall erforderlich ist.

Im Allgemeinen ist REJECT für Webserver am besten geeignet, da jeder Dienst, der versucht, darauf zuzugreifen (wahrscheinlich meistens auch Sie), schnell eine Antwort erhält und Benutzer oder andere Dienste nicht darauf warten müssen, sich zu fragen, ob ein Netzwerkausfall vorliegt.

Dagelf
quelle
5
Diese Antwort ist falsch. Mit tcpdump kann leicht gezeigt werden, dass die DROP-Regel dazu führt, dass das System keine Antwort sendet - wie erwartet. Und Ihre Aussage "Um ein Paket wirklich fallen zu lassen, muss das System mit einem TCP-RST / ACK antworten" ist nicht sinnvoll, da die Beantwortung einer Frage offensichtlich nicht "wirklich ein Paket fallen lassen" bedeutet. Wenn Sie ein Paket "wirklich fallen lassen", antworten Sie einfach nicht und dies ist nachweislich der Effekt der DROP-Regel.
Juliane Holzt
3
Könnten Sie eine Quelle für die Behauptung angeben, DROPdie eine ausstellen wird SYN/ACK? Ich habe das nie auf meinen Maschinen gesehen.
Motobói
2
@Dagelf In Ihrem Artikel heißt es: "DROP (aka DENY, BLACKHOLE) Verhindert die Weitergabe eines Pakets. Senden Sie keine Antwort."
JeanT
Es sendet nicht die normale Antwort, aber es sendet eine wie erklärt, unabhängig davon.
Dagelf
3
In dem Dokument, auf das Sie verweisen, heißt es " DROP ... Send no response " ( TROPFEN ... Keine Antwort senden). Soweit ich sehen kann, wird Ihre Behauptung, dass DROPa zurückgegeben wird, nicht unterstützt SYN/ACK. Auch ich habe dieses Verhalten unter keiner Version von gesehen iptables. Wenn Sie eine Quelle haben, die Ihre Behauptung unterstützt, wäre es am nützlichsten, sie zu sehen. Mit Sicherheit stützen die Paket-Dumps, die ich gerade gemacht habe, Ihren Anspruch nicht.
MadHatter