lubux
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
kB schrieb: Naja, fast: Ich würde DROP nehmen, um den Verkehr durch unnütze Fehlermeldungen zu vermeiden.
Ich denke Fehlermeldungen wird es mit DROP geben und nicht mit REJECT, ... denn:
The DROP target does just what it says, it drops packets dead and will not carry out any further processing. A packet that matches a rule perfectly and is then Dropped will be blocked. Note that this action might in certain cases have an unwanted effect, since it could leave dead sockets around on either host. A better solution in cases where this is likely would be to use the REJECT target, especially when you want to block port scanners from getting too much information, such as on filtered ports and so on. Also note that if a packet has the DROP action taken on it in a subchain, the packet will not be processed in any of the main chains either in the present or in any other table. The packet is in other words totally dead. As we've seen previously, the target will not send any kind of information in either direction, nor to intermediaries such as routers.
Bearbeitet von sebix: Titel noch um bei DNS ergänzt.
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8627
Wohnort: Münster
|
lubux schrieb: […] Ich denke Fehlermeldungen wird es mit DROP geben und nicht mit REJECT, ... denn:
The DROP target […] could leave dead sockets around on either host. […]
DROP erzeugt kein ICMP-Paket mit Fehlermeldung. REJECT erzeugt aber ein ICMP-Paket mit Fehlermeldung, und somit von uns zu bezahlenden Netzwerk-Verkehr. Für den anfragenden DNS-Client ist eine Fehlermeldung „Du darfst diesen DNS-Server nicht benutzen.“ im Ergebnis genau wie ein Timeout, ggf. etwas schneller – aber wir wären hier höflich zu unserem Feind! Es ist völlig normal und zulässig, dass IP-Pakete im Internet verloren gehen. Wenn ein Host deshalb unter einem "dead socket" leidet, ist seine Software nicht spezifikationsgerecht und auch nicht praxistauglich. Eine Fehlermeldung wegen eines verlorenen UDP/IP-Paketes wäre jedenfalls völlig unaktzeptabel.
|
lubux
(Themenstarter)
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
kB schrieb:
Ja, aber DROP (ignorieren) kann zur Folge haben, dass eine 2. Anfrage und evtl. noch weitere Anfragen kommen und somit mehr Netzwerk-Verkehr verursachen/entsteht als das ICMP-Paket mit der "Fehlermeldung" verursacht. Das kann man mit tcpdump (oder gleichwertig) ja beobachten.
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8627
Wohnort: Münster
|
lubux schrieb: kB schrieb:
Ja, aber DROP (ignorieren) kann zur Folge haben, dass eine 2. Anfrage und evtl. noch weitere Anfragen kommen und somit mehr Netzwerk-Verkehr verursachen/entsteht als das ICMP-Paket mit der "Fehlermeldung" verursacht.
Zunächst einmal darf man in Deinem Satz das Wort „kann“ ruhig durch „wird“ ersetzen. Ja, der DNS-Client wird, wenn er keine Antwort erhält, seine Anfrage wiederholen. Üblicherweise fragt er bis zu 5 mal an, bevor er aufgibt. Es scheint also eine gute Idee zu sein, ihn durch eine Fehlermeldung zur Aufgabe zu bewegen. Leider sind diese Gesellen in der Regel nicht kooperativ. Der DNS-Client wird seine Anfragen erst beenden, wenn er vom DNS-Server – also auf Layer-5+ – eine positive oder negative Antwort erhält. Eine Fehlermeldung per ICMP auf Netzwerk-Layer-2 stoppt ihn nicht. Das meinte ich mit „unnütze“ Fehlermeldung. Es ist auch gar nicht sicher, ob die Fehlermeldung per ICMP den anfragenden Host überhaupt erreicht, da ICMP gerne mal auf Routern geblockt wird. Und schließlich ist unsicher, ob die in der Anfrage angegebene Absender-IP-Adresse überhaupt stimmt! Sie könnte gefälscht sein – beim Protokoll UDP ist das wegen des fehlenden Handshake völlig problemlos – und wäre dann vermutlich das Ziel eines DDoS-Angriffs, an dem wir uns dann naiverweise beteiligen, indem wir ein Paket losschicken. Meine Meinung: Auf UDP sollte man nur antworten, wenn man muss (wie bei DNS) oder den Kommunikationspartner authentifiziert hat.
|
lubux
(Themenstarter)
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
kB schrieb: Der DNS-Client wird seine Anfragen erst beenden, wenn er vom DNS-Server – also auf Layer-5+ – eine positive oder negative Antwort erhält.
Aber wenn die Anfrage mit DROP geblockt wird, bekommt der DNS-Client, weder eine positive noch eine negative Antwort vom DNS-Server (d. h. der DNS-Client bekommt nie eine Antwort). Der DNS-Client wird dann seine Anfragen erst bei "connection timed out" beenden.
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8627
Wohnort: Münster
|
lubux schrieb: kB schrieb: Der DNS-Client wird seine Anfragen erst beenden, wenn er vom DNS-Server – also auf Layer-5+ – eine positive oder negative Antwort erhält.
Aber wenn die Anfrage mit DROP geblockt wird, bekommt der DNS-Client, weder eine positive noch eine negative Antwort vom DNS-Server (d. h. der DNS-Client bekommt nie eine Antwort). Der DNS-Client wird dann seine Anfragen erst bei "connection timed out" beenden.
Was ist beim verbindungslosen Protokoll UDP "connection timed out", wenn es doch gar keine Verbindung gibt? Ein DNS-Client macht ungefähr das: 1. Anfrage – 1 Sekunde warten – 2. Anfrage – 1 Sekunde warten – 3. Anfrage – 2 Sekunden warten – 4. Anfrage – 4 Sekunden warten – 5. Anfrage – 2 Sekunden warten – Gib auf. Nach 10 Sekunden spätestens ist alles vorbei. (Und das passiert auf dem Rechner, der uns unberechtigt Anfragen schickt.) Wenn man Fehlermeldungen schicken würde, dauert es genau so lang.
|
kB
Supporter, Wikiteam
Anmeldungsdatum: 4. Oktober 2007
Beiträge: 8627
Wohnort: Münster
|
Das begrüße ich ausdrücklich. Zur Klarstellung jedoch: Es geht bei diesen Beiträgen nicht im allgemein um „iptables: DROP vs. REJECT“ sondern im Detail um „iptables: DROP vs. REJECT bei DNS“. Mein Plädoyer für DROP gilt nur für diesen Spezialfall. REJECT kann in anderen Situationen durchaus angemessen sein.
|
sebix
Moderator, Webteam
Anmeldungsdatum: 14. April 2009
Beiträge: 5349
|
kB schrieb: Hab ich noch ergänzt, danke.
|
Yoschi97
Anmeldungsdatum: 8. September 2017
Beiträge: Zähle...
|
Für meinen Anwendungsfall bevorzuge ich DROP, denn ich muss in erster Linie nicht Angriffe durch Hacker sondern automatisierte Angriffe abwehren. Und wenn der Angriffs-Server einfach keine Antwort bekommt finde ich das besser als wenn er mitbekommt, dass auf dem Port ein Dienst läuft, aber der Zugang verweigert wird. Das könnte dem Angreifer der den Server laufen hat dazu veranlassen manuell nach Sicherheitslücken zu suchen.
|
lubux
(Themenstarter)
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
Yoschi97 schrieb: ... sondern automatisierte Angriffe abwehren.
BTW: Hast Du schon mal auf einem border device (mit einer öffentlichen IPv4-Adresse) das nicht als DNS-Server öffentlich "bekannt" ist, über z. B. Monate hinweg, den Zugriff auf den _UDP_ Port _53_ geloggt? Yoschi97 schrieb: ... dazu veranlassen manuell nach Sicherheitslücken zu suchen.
Wie sucht der Angreifer _manuell_ nach Sicherheitslücken?
|
Yoschi97
Anmeldungsdatum: 8. September 2017
Beiträge: 11
|
lubux schrieb: Yoschi97 schrieb: ... sondern automatisierte Angriffe abwehren.
BTW: Hast Du schon mal auf einem border device (mit einer öffentlichen IPv4-Adresse) das nicht als DNS-Server öffentlich "bekannt" ist, über z. B. Monate hinweg, den Zugriff auf den _UDP_ Port _53_ geloggt?
Nein, ich beschäftige mich das erste Mal mit der Absicherung eines DNS-Servers.
Yoschi97 schrieb: ... dazu veranlassen manuell nach Sicherheitslücken zu suchen.
Wie sucht der Angreifer _manuell_ nach Sicherheitslücken?
Ich weiß nicht, der automatische Angriff scannt ja einfach nur alle IPs und Ports ab. Ein echter Mensch könnte ja noch weiter gehen als simpel zu prüfen ob er eine vernünftige Antwort oder ein REJECT/Timeout erhält.
|
lubux
(Themenstarter)
Anmeldungsdatum: 21. November 2012
Beiträge: 13938
|
Yoschi97 schrieb: ... ich beschäftige mich das erste Mal mit der Absicherung eines DNS-Servers.
Warum muss dein DNS-Server auch aus dem Internet erreichbar sein?
|