Low bandwidth attacking – slowloris for the win!

Veröffentlicht: 26. Oktober 2012 in IT-Security, Netzwerke

Slowloris ist kein neues Instrument, um ein Ziel vom Netz zu schießen. Mittels einem angepassten Script
habe ich verschiedene von mir betreute NAS-Systeme einem Stresstest unterzogen. Die erschreckende
Erkenntnis ist, dass Anbieter solcher (teils Business) NAS-Lösungen zwar mit vielen Features werben,
aber offenbar die Aspekte aus Sicht der Sicherheit konsequent ignorieren.

Beispiel ein NAS mit aktivierem Webserver. Angebunden an einer 100MBit-Leitung und erreichbar
über DynDns.

my personal slowloris

my personal slowloris – klicken zur Volldarstellung

Nach einem forcierten low bandwidth Angriff (mit nur einem Rechner) ist der kleine Home-Webserver nach
knapp 40 Sekunden nicht mehr erreichbar. Der Dienst für httpd macht dicht, da zuviele offene Anfragen
gestellt wurden und der Apache-Server diese praktisch nicht mehr zeitnah abgearbeitet bekommt.
Die HTTP-Anfragen werden in Threads immer wieder an den Server gestellt, um die Sockets am schließen
zu hindern. Der Angreifer gewinnt – früher, oder später…

Bandbreite

Bandbreite

Nun wird dies vielleicht nur als kleines „Ärgernis“ betrachtet, wenn die Homepage mal für gewisse Zeit ausfällt.
Was aber, wenn darauf Seiten gehostet werden, die Sie bares Geld kosten können?

Eine Seite, die Waren für 1 Euro anbietet und dann diesen Preis durch Gebote der User automatisch steigen
lässt, hätte an dieser Stelle bereits ein ernst zu nehmendes Problem! Und zwar dann, wenn ein Angreifer
das letzte (natürlich sehr niedrige) Gebot abgibt und dann die Seite vom Netz schießt, bis der Counter
für möglich andere (höhere) Gebote abgelaufen ist.

CPU-last

CPU-last

Voila, das neue iPhone für 5,00 Euro bekommen. Das ist doch mal nett. Nur nicht für den Betreiber der Plattform…

Auch, kann solch eine Attacke als gezielte Ablenkung für ganz andere Aktivitäten dienen. Während der Admin noch
mit httpd, syslogs und Port 80 rum hühnert, ist unser Angreifer bereits dabei die Daten der SQL-Injection auszuwerten…

Was also tun, sprach Zeus?

Mögliche Optionen sind:

  • maximale Anzahl gleichzeitiger Verbindungen des Webservers anpassen
  • maximale Anzahl von Zugriffen ein und der selben IP begrenzen
  • Timeout für Verbindungsanfragen runter setzen
  • spezielle Module für Apache installieren (moq_noloris, mod_security etc.)

Leider sind die genannten Optionen zum Teil auch immer etwas Kontraproduktiv.
Ein Angreifer, der es wirklich darauf anlegt wird seine Scripte so anpassen, dass z.B.
der Angriff über TOR unter Verwendung von NEWNYM (cycle identity) erfolgt und somit die IP wechselt.
Das runtersetzen des Timeout hingegen kann an anderer Stelle zu ungewünschten Sessionabbrüchen führen…

Advertisements

Eigenen Senf dazu geben

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s