| 

.NET C# Java Javascript Exception

10

Gestern bin ich Zeuge einer möglichen DDoS-Attake auf eine Website eines Kunden geworden. Die Website reagierte mit einer Fehlerseite. Der Grund des Fehlers war ein Connection Timeout der Datenbank. Es dauerte eine Weile, bis wir raus hatten, was eigentlich los war.

Zwischen 3 Uhr und 9 Uhr morgens wurden mit 1.7 Millionen Requests über ein Terrabyte an Daten abgerufen, nur mit dem permanenten Aufruf der Startseite. Da machte dann irgendwann die Datenbank (Azure SQL DB) schlapp. Die Azure Web-App hätte vielleicht noch liefern können:

image

Erst ein Blick in die Webserver-Logs brachte Klarheit über den Grund des DB-Ausfalls. Das Log war voll mit Anfragen aus der ganzen Welt, mit einer Gemeinsamkeit: Alle Anfragen hatten den User-Agent WordPress/<version>;+<domain>

Nach etwas Recherche erfuhren wir, dass es einen Kritischen Bug in älteren WordPress und Drupal Versionen gibt, mit denen ein Aufruf einer anderen Website ausgelöst werden kann:

Also irgendwer oder irgendwas hat über ungepatchte WordPress Installationen Anfragen auf diese Website abgefeuert. Die Anfragen kamen wahrscheinlich von echten WordPress Installationen aus der ganzen Welt, denn die IP-Adresse in der Log-Datei war identisch mit der Adresse der Domain im User-Agent.

Nun musste ein Weg gefunden werden diese Anfragen zu blocken. Zuerst blockten wir über eine Eintrag in der Web.Config alle IP-Adressen, außer unsere eigenen, um die Server zu entlasten:

<ipSecurity allowUnlisted="false" denyAction="AbortRequest">
    <add allowed="true" ipAddress="[Unsere IP-Adresse 1]"/>
    <add allowed="true" ipAddress="[Unsere IP-Adresse 2]"/>
</ipSecurity>

Anschließend blockierten wir zu schnelle Anfragen von gleichen IP-Adressen:

<dynamicIpSecurity>
    <denyByConcurrentRequests enabled="true" maxConcurrentRequests="10"/>
    <denyByRequestRate enabled="true" maxRequests="100" requestIntervalInMilliseconds="7000" />
</dynamicIpSecurity>

Beide Einträge müssen unter </system.webServer></security> vorgenommen werden. Den ersten Eintrag <ipSecurity> kann man auch nutzen um bekannte IP-Adressen zu sperren. Da die Adressen in diesem Fall aber alle verschieden waren und auch nicht einer Region zugeordnet werden konnten, ist dieser Eintrag aber unbrauchbar für einen DDoS-Schutz

Der zweite Eintrag dämpft die Last einer solchen Attacke eventuell etwas, macht bei einer Verteilten-Attacke aber wohl eher wenig aus.

Ein Hinweis in der MSDN, solche Anfragen per URL-Rewrite zu lösen brachte dann die Lösung. Es ist über das IIS Url-Rewrite möglich eingehende Anfragen anhand der Header zu identifizieren und umzuleiten oder gar zu blocken. Wir mussten also alle Anfragen, deren User-Agent-Header mit WordPress* starten blocken:

<rule name="Block WordPress DOS" patternSyntax="Wildcard" stopProcessing="true">
  <match url="*" />
  <conditions>
    <add input="{HTTP_USER_AGENT}" pattern="WordPress*" ignoreCase="true" negate="false" />
  </conditions>
  <action type="AbortRequest" />
</rule>

Dieser Eintrag muss in der web.config ganz oben an erster Stelle unter <system.webServer><rewrite><rules>, da die erste Rule als erste abgearbeitet wird.

Später kann dann die Liste der Conditions beliebig erweitert werden.

Alle Anfragen die auf diese Art identifiziert werden, werden komplett blockiert. Es wird nicht mal mehr ein Eintrag im Log des Webservers geschrieben.

Ich hoffe das dieser Beitrag auch anderen hilft, schnell auf so eine Attacke zu reagieren.

azure iis azure-website ddos web.config
Weitere News:
Schreibe einen Kommentar:
Themen:
web.config ddos azure-website iis azure
Entweder einloggen... ...oder ohne Wartezeit registrieren
Benutzername
Passwort
Passwort wiederholen
E-Mail