Freitag, den 05. April 2013 00:25 Alter: 5 Monat(e)
Kategorie: Tuning
Submitting your vote...
Noch nicht bewertet!
Artikel bewerten.

DDOS-Angriff gegen TYPO3-Webseite abwehren

Mit wenig Handgriffen lässt sich ein Webserver mit dynamisch generierten Seiten für die Zeit des Angriffs so Umstellen, dass mit wenig Ressourcen auch sehr große Angriffe harmlos abprallen.


Einer der einfachsten Wege eine Webseite mit dynamisch generierten Inhalten lahmzulegen sind ganz einfache HTTP-Anfragen auf diese Webseite.
Eine solche Anfrage kostet wenig Ressourcen, ist für den Administrator schwer von den normalen Anfragen zu trennen und verursacht eine menge Rechenaufwand die angeforderten Seiten zu berechnen.

Kürzlich hatte ich das zweifelhafte vergnügen mit etwa 500 Anfragen pro Sekunde auf eine auf einem einzelnen Server gehosteten Webseite umgehen zu müssen.

1) Wenn herkömmliche Abwehrmechanismen fehlschlagen.

Die eleganteste Lösung einem Angriff zu begegnen wäre es keine Änderungen an der Software selbst vornehmen zu müssen.

Eine verbreitetet Ansatz ist es den Traffic auf Port 80 einzuschränken:

z.B.:

  1. iptables -A INPUT -p tcp --dport 80 -m state \
  2. --state NEW -m limit --limit 50/minute --limit-burst 200 -j ACCEPT

blog.bodhizazen.net/linux/prevent-dos-with-iptables/

Wenn viele Anfragen auf das System einprallen hat das jedoch zur Folge, dass normale Benutzer die Seite auch nicht mehr zu Gesicht bekommen, da sich der Server ständig am eingestellten Limit befindet.

Aus diesem Grund bevorzuge ich normalerweise ein vorgehen, bei dem Gute Anfragen vn Bösen getrennt werden und Anfragen von Bösen IPs für längere Zeit komplett blockiert werden.
Das vorgehen ist zum Beispiel unter
foobar.lamp-solutions.de/howtos/server-administration/server-sicherheit/3079/
beschrieben.

In dem geschilderten Fall hatte der Angreifer jedoch so viele IP-Adressen zur Verfügung, dass es längere gedauert hat diese per Script in die ACLs von Iptables zu schreiben als Anfragen von neuen IPs eingetroffen sind.

2) Anfragen statisch abarbeiten


Vor vielen Webseiten dürfte sich heutzutage ein Varnish-Cache als Reverse-Proxy befinden.
Drei einfache Zeilen in der Konfiguration genügen um alle Anfragen statisch aus dessen Cache ausliefern zu lassen:
in sub vcl_recv:

  1. unset req.http.Cookie;
  2. set req.ttl = 48h;
  3. return (lookup);

varnishstats

Bild:60000 Anfragen in 2 Minuten = 500 req/s


Diese einfache Änderung sorgt zwar dafür das dynamische, oder Benutzerspezifische Inhalte auf der Webseite nicht mehr in der erwarteten Form ausgeliefert werden, versetzt aber eine Einzelnen System in die Lage vergleichsweise problemlos 500 Anfragen pro Sekunde auszuliefern.
Der Code oben lässt sich verfeinern, dass es einzelnen IP-Adressen erlaubt wird zum Beispiel ein PURGE-Commando abzusetzen um Änderungen aktiv werden zu lassen.

3) Ausblick und Grenzen

Varnish spricht kein https. Wenn https-Inhalte angegriffen werden ist es entweder möglich für die Zeit des Angriffs diese einfach ein http-Umzuleiten, oder vor den Varnish noch einen weiteren Proxy für die Annahme der http-Anfrage zu nehmen und dann per http weiter nach hinten auf den Varnish zu leiten. Dafür eignet sich zum Beispiel nginx.

Natürlich sind 500 Anfragen pro Sekunde (die Bandbreite lag dabei etwa bei 20 Mbit/s) nicht die Grenze für einen großen DDOS-Angriff. Dabei stellt sich natürlich immer die Frage nach Kosten und Nutzen. Eine „Extra Large High-CPU On-Demand Instances“ kosten derzeit bei Amazon derzeit 58 Dollarcent die Stunde. Wenn wir von einer Grenze von 500 Anfragen pro Sekunde ausgehen (ich denke es geht auch mehr :-)) Dann werden in dieser Zeit 1,8 Millionen Anfragen verarbeitet.
Zu der Frage, ob ein Angreifer die 1,8 Millionen Anfragen zu diesem Preis einkaufen kann möchte ich keine Einschätzung wagen. Ich hoffe, dass es zumindest dauerhaft nicht so billig zu haben ist.

Leider beschränken sich Angriffe in der Regel nicht auf einfache http-Anfragen sondern werden zeitgleich mit syn-Floods oder anderen unangenehmen Aktivitäten. Was die Abwehr heutzutage erleichtert ist, dass sich bei Could-Anbietern wie Amazon mit wenigen Mausklicks sehr viel Rechenleistung rund um die Welt bereitstellen lässt. Je einfacher ein Setup dabei gestrickt ist, desto leichter und kostengünstiger lässt es sich skalieren.


keine Kommentare
Kommentar schreiben

* Bitte ausfüllen

*

*