RootForum Community

Hallo,

ich kann mich einfach nicht entscheiden, welches die bessere Variante ist.

Hier wird geschrieben, dass man besser rejekten sollte. Einige der dort aufgeführten Argumente verstehe ich einfach nicht: Ich will sie nicht aufhalten, dass kann ich eh nicht - ich will sie möglich ressourcenschonend ignorieren.
Weshalb ich legitime Anfragen massiv ausbremse, wenn ich unerwünschte Pakete verwerfe, erschließt sich mir auch durch mehrmaliges Nachdenken nicht.


Nun die andere Seite, ein Befürworter von Deny:
Ja, das verstehe ich und es erscheint mir auch logisch.
Das auch.
Und auch das. Wobei das Verwerfen eines Paketes vielleicht auch auf einen Paketfilter hindeutet.

Nun steht es für mich 3:0 für DENY. Trotzdem hab ich Zweifel, weil man ständig hört und liest "rejecte!". Kann mir jemand weiterhelfen? Was ist denn nun besser?

_tomcat_ wrote:Weshalb ich legitime Anfragen massiv ausbremse, wenn ich unerwünschte Pakete verwerfe, erschließt sich mir auch durch mehrmaliges Nachdenken nicht.

Wenn kein REJECT kommt, wartet der Client i. d. R. bis zum Timeout, das je nach Dienst einige Minuten dauern kann.

_tomcat_ wrote:

Code: Select all

Durch eine Fehlermeldung wird der Datenverkehr auf dem Netz unnötig vergrößert. 

Ja, das verstehe ich und es erscheint mir auch logisch.

Der Mehrtraffic ist vernachlässigbar und ein REJECT technisch sauberer. Bei einer DDoS-Attacke spielt die Größe der Antwortpakete schon eine Rolle, aber dabei hast du eh ganz andere Probleme.

_tomcat_ wrote:

Code: Select all

Fehlermeldungen können als Teil einer Denial-of-Service-Attack Strategie eingesetzt werden. Wenn etwa ein Angreifer, der einen Rechner im Internet blockieren will, seine IP-Adresse auf die des zu blokierenden Rechners fälscht und anschließend tausende von bei Ihnen verbotenen Anfragen macht, dann wird Ihr Rechner tausende von Fehlermeldungen nicht an den Rechner des Angreifers, sondern an den zu blockierenden Rechner schicken.

HAHA, versuch mal einfach eine Source-IP-Adresse im Internet zu spoofen.

_tomcat_ wrote:

Code: Select all

Fehlermeldungen - und seien sie an sich noch so wenig aussagekräftig - können einem potenziellen Angreifer doch zumindestens Informationen geben, die er besser gar nicht hat. Etwa alleine die Existenz einer Firewall oder ähnliches. 

Ähm, der Angreifer weiß schon, dass da ein Server ist. Ansonsten könntest du auch einfach das Netzwerkkabel ziehen. Die "Firewall" (der Paketfilter) ist eher noch ein zusätzlicher Angriffsvektor.

_tomcat_ wrote:Nun steht es für mich 3:0 für DENY.

3:0 gegen den Einsatz eines Paketfilters...

PS: Der Quote-Tag ist für Zitate besser geeignet als der Code-Tag.

Einiges wird ja bereits in den hier nicht zitierten Stellen erklärt, daher hier nochmal der vollständige Absatz:

Admins, die sich über Script Kiddies ärgern, glauben oft, diese durch DENY aufhalten zu können. Dies ist jedoch falsch. Es ist problemlos möglich, viele tausend Scans gleichzeitig zu starten und so auf alle Timeout gleichzeitig zu warten. Ein Scanner wird so nicht gebremst. Andererseits bremst man mit DENY alle legitimen Nutzer und Server massiv aus. Das betrifft insbesondere die ident Anfragen.

Der erste Satz zielt wohl darauf ab, dass manche denken, Scans ausbremsen zu können, was wegen der Parallelisierung wenig nützt. Andere denken wohl auch, dass sie sich durch DENY "unsichtbar" für Scans machen können, was aber ebenso Quatsch ist.

Insbesondere Ident sollte nie per DENY abgewiesen werden. Darauf zielt hauptsätzlich das Ausbremsen legitimer Nutzer ab.