Frage Wie verteidige ich am besten gegen einen DOS-Angriff "slowloris" gegen einen Apache-Webserver?


Vor kurzem hat ein Skript namens "Slowloris" Aufmerksamkeit erregt. Das grundlegende Konzept dessen, was Slowloris tut, ist kein neuer Angriff, aber angesichts der jüngsten Aufmerksamkeit habe ich eine kleine Zunahme von Angriffen auf einige unserer Apache-Websites gesehen.

Im Moment scheint es keine hundertprozentige Verteidigung dagegen zu geben.

Die beste Lösung, die wir bisher ermittelt haben, ist die Erhöhung von MaxClients.

Dies erhöht natürlich nicht nur die Anforderungen an den Computer des Angreifers und schützt den Server nicht wirklich zu 100%.

Ein anderer Bericht zeigt an, dass die Verwendung eines Reverseproxys (wie Perlbal) vor dem Apache-Server dazu beitragen kann, den Angriff zu verhindern.

Wenn Sie mod_evasive verwenden, um die Anzahl der Verbindungen von einem Host zu begrenzen und mod_security zu verwenden, um Anfragen abzulehnen, die aussehen, als ob sie von SlowLoris ausgegeben würden, dann scheinen sie die beste Verteidigung zu sein.

Hat jemand auf ServerFault solche Angriffe erlebt? Wenn ja, welche Maßnahmen haben Sie ergriffen, um sie zu verteidigen / zu verhindern?

Hinweis: diese Frage gilt für Apache-Server, da ich weiß, dass Windows IIS-Server nicht betroffen sind.


30
2018-06-26 18:03


Ursprung




Antworten:


Ich habe einen solchen Angriff erlebt ... mitten im Hochsommer (23. Juni), wo man auf dem Land sein und Bier trinken sollte:>

Ich habe meinen Apache zurückgelassen Lack, die nicht nur vor langsamen, sondern auch vor beschleunigten Web-Anfragen geschützt sind.

Ebenfalls, iptables half mir:

iptables -I INPUT -p tcp --dport 80 \
         -m connlimit --connlimit-above 20 --connlimit-mask 40 -j DROP

Diese Regel begrenzt einen Host auf 20 Verbindungen zu Port 80, was nicht böswillige Benutzer nicht beeinträchtigen sollte, würde aber slowloris von einem Host unbrauchbar machen.


21
2018-06-26 21:18



+1 für die iptables-Regel. - Tim
Nur ein Kopf hoch. "Out of the Box", Lack speichert keine Seiten, wenn er Cookies erhalten hat. Sie müssen einige benutzerdefinierte Konfiguration vornehmen, um dies zu umgehen. Beispiele sind auf ihrer Website verfügbar und einfach zu implementieren. - David
Varnish ist ziemlich programmierbar, also können Sie es vielleicht konfigurieren, um zu sehen, was passiert und damit umgehen. Ich glaube jedoch, dass Sie das Problem einfach vom Webserver auf den Proxy verschieben, indem Sie einen Proxy vor den Apache stellen. Das Problem ist immer noch da, nur an einem anderen Ort. Verbindungen / Ports werden noch aufgebraucht. Ich würde mit der aufgeführten iptables-Regel (oder der Entsprechung für Ihre Firewall) beginnen und dann auf einen Proxy schauen. - David
Das Problem mit dem Sloworis-Angriff beschränkt sich auf das Multi-Threading-Modell von Apache (und mehrere andere Webserver, die ein ähnliches Modell verwenden). Varnish sollte das überleben. - Cian


mod_antiloris, so einfach ist das.


4
2018-06-30 18:00





Wenn alle Apache-Module threadsicher sind, kann SlowLoris einfach durch Umschalten auf Event- oder Worker-MPMs besiegt werden. Ref: Hier


3
2017-07-13 18:45





Im Moment scheint es, dass es nichts mehr zu tun gibt, was die maximale Anzahl gleichzeitiger Verbindungen pro IP auf dem Server begrenzt.


0
2018-06-26 19:07





Es gibt einen Benutzer-Patch, den Sie ausprobieren können. Es ändert das Zeitlimit basierend auf der Auslastung des Servers, aber unter Berücksichtigung seines Status möchten Sie es möglicherweise nicht ohne ernsthafte Tests auf einer Produktionsmaschine verwenden. Schau mal Hier.


0
2018-06-26 19:10





Iptable basierte Firewall sollte Sie vor mehreren Verbindungen von 1 IP schützen.


0
2018-06-26 20:16





Wenn dies anderen hilft, können Sie dieses Problem manchmal mit Apache 2.2.15 oder höher mit der folgenden Konfiguration beheben:

LoadModule reqtimeout_module modules/mod_reqtimeout.so
RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500

Mehr Infos hier: https://httpd.apache.org/docs/2.2/mod/mod_reqtimeout.html


0
2017-10-16 15:44