Das Apache-Benchmark-Tool legt Server lahm

Abwehrverhalten

Das verbreitete Benchmarking-Tool Apachebench kann effiziente Denial-of-Server-Attacken starten, wenn man sich nicht dagegen schützt.
Wer sein System permanent überwacht, hat den Grundstein dafür gelegt Engpässe zu vermeiden und Fehler frühzeitig zu erkennen. Neben dem Platzhirsch Nagios ... (mehr)

Sie haben also viel Sorgfalt auf die Auswahl der neuen Hardware für den Webserver verwendet. Und Sie haben sich alle Mühe gegeben, die Datenbank zu tunen und zusammen mit Ihren Kollegen einige Wochen damit verbracht, eine brandneue, topaktuelle Website, basierend auf den leistungsfähigsten Technologien an den Start zu bringen. Jetzt wollen Sie sich zurücklehnen und einfach nur zuschauen, wie Tausende von Besuchern täglich von Ihrem neuen Webangebot Gebrauch machen. Sogar der Chef scheint ausnahmsweise einmal zufrieden.

Doch dann nimmt das Schicksal seinen Lauf: Eines schönen Tages startet in irgendeinem fremden Land jemand mit zu viel Zeit ein völlig legitimes und weitverbreitetes Tool und zwingt Ihren schönen Server damit in die Knie. Dazu braucht er noch nicht einmal eine schnelle Internet-Anbindung, er schickt einfach nur ein paar Bytes über eine kleine DSL-Leitung.

Diese Bedrohung ist sehr real. Selbst eine durchdachte, leistungsfähige Infrastruktur kann mit einem einfachen Angriff lahmgelegt werden.

Benchmarks

Das Angriffs-Tool, um das es hier geht, ist das für einen guten Zweck entwickelte Apache-Benchmarking-Programm »ab« (Apachebench) [1] . Wie die Apache-Dokumentation es ausdrückt, ist Apachebench dafür entworfen worden, sich einen Eindruck davon zu verschaffen, wie schnell die eigene Apache-Installation arbeitet. Insbesondere soll es verraten, wie viele Requests pro Sekunde der Webserver verarbeiten kann.

Das klingt sehr unschuldig, verschafft aber jedem Tunichtgut die Gelegenheit, mit etwas Cut-und-Paste großen Schaden anzurichten. Normalerweise ist es auf jeder Linux-Distribution verfügbar und erfordert außerdem keine Root-Rechte.

Abbildung 1 zeigt Apachebench beim Einsatz, wie es gerade 2500 Anfragen bei einer Rate von 300 gleichzeitigen Verbindungen verarbeitet – mehr als genug, um die meisten Webserver-Installationen auf einem einzigen Server in Schwierigkeiten zu bringen.

Abbildung 1: Apachebench auf der Kommandozeile.
Abbildung 2: Ergebnisse eines Apachebench-Durchlaufs.

Jeder, der den Apache-Server näher kennt, weiß um die Vielzahl an Konfigurationsoptionen und Module, die er unterstützt. Zweifellos gehört die Flexibilität, mit der sich ein solcher modularer Server einrichten lässt, zu den Gründen, warum Apache so populär ist. Mit Apachebench verhält es sich ähnlich: Es besitzt mehr als 20 Schalter, über die der Anwender genau bestimmen kann, wie es seine Performance-Tests absolviert. Die Ergebnisse eines solchen Durchlaufs sind in Abbildung 2 zu sehen.

In der unteren Hälfte ist der Abschnitt »Percentage of the requests served within a certain time (ms)« zu sehen, dem sich entnehmen lässt, ob der Webserver im Lauf der Testzeit langsamer wird. Die Tabelle zeigt die Länge der Requests in Millisekunden und welcher Anteil an Gesamt-Requests in diesem Intervall abgearbeitet wurde.

Gegenmaßnahme

Statt Zehntausende von Euro in eine Lösung zu investieren, die Sicherheit gegen Denial-of-Service-Angriffe verschafft, können Sie auch eine selbst gestrickte Lösung versuchen, die in den meisten Fällen ausreichend ist. Sie erfordert nur einen Linux-Rechner, auf der die altbekannte Firewall-Software IPTables läuft.

Mit etwas grundlegenden IPTables-Kenntnissen lässt sich der Regelsatz in Listing 1 leicht entziffern. Neben dem Standard-Modul »ip_tables« sind zusätzlich die Kernel-Module »state« und »multiport« nötig, die beispielsweise unter Ubuntu unter den Namen »xt_multiport« und »xt_state« zur Verfügung stehen. Alternativ zum hier vorgestellten Weg gibt es ähnliche Ansätze, die auf dem IPTables-Modul »recent« basieren.

Listing 1

IPTables-Regeln

01 iptables -A INPUT -p tcp -m multiport --dport 80,443 -m state --state NEW -m limit --limit 100/minute --limit-burst 300 -j ACCEPT
02 iptables -A INPUT -p tcp -m multiport --dport 80,443 -m state --state NEW -m limit --limit 100/minute --limit-burst 300 -j LOG --log-level info --log-prefix NEW-CONNECTION-DROP:
03 iptables -A INPUT -p tcp -m multiport --dport 80,443 -m state --state RELATED,ESTABLISHED -m limit --limit 100/second --limit-burst 100 -j ACCEPT
04 iptables -A INPUT -p tcp -m multiport --dport 80,443 -m state --state RELATED,ESTABLISHED -m limit --limit 100/second --limit-burst 100 -j LOG --log-level info --log-prefix ESTABLISHED-CONNECTION-DROP:
05 iptables -A INPUT -p tcp -m multiport --dport 80,443 -j DROP

Die Befehle in Listing 1 berücksichtigen Flooding-Angriffe gleichermaßen auf Port 80 (HTTP) wie Port 443 (HTTPS) und neue wie bereits aufgebaute Verbindungen. Dieser Ansatz bremst einen Angriff recht effektiv aus. Eine einfachere Lösung könnte sich ausschließlich auf neue Verbindungen konzentrieren, wäre aber eher für Syn-Flodding-Attacken geeignet. In unserem Fall funktioniert das nicht, weil der Apache-Server in der Standard-Konfiguration per Keep-Alive Verbindungen geöffnet lässt, um darüber mehrere Anfragen zu verarbeiten. Also muss man auch bereits geöffnete Verbindungen berücksichtigen.

Beim Testen kann man einen Einblick in das Verhältnis neuer zu bereits geöffneten Verbindungen und den damit verbundenen Traffic-Beschränkungen durch die Firewall-Regeln gewinnen, wenn man das Syslog im Auge behält. Grundsätzlich ist der Sinn dieser Regeln, Angreifer auszubremsen, die ein bestimmtes Muster verfolgen, aber regulären Website-Besuchern weiterhin die Nutzung der Site zu erlauben. Im Test hat das gut funktioniert, auch wenn der Server letztlich etwas langsamer wurde.

In der ersten Zeile von Listing 1 findet sich die Option »--limit 100/minute« , die festlegt, dass die Firewall alle Pakete eines Rechners verwirft, der auf den Ports 80 und 443 Anfragen mit mehr als 100 Paketen pro Minute stellt. Die Option »--limit-burst« ist etwas schwieriger zu verstehen. Im Prinzip sind erst einmal 300 Pakete erlaubt, bevor das eben beschriebene Limit von 100 Paketen/min zum Tragen kommt. Die Idee dahinter ist, dass bei legitimer Nutzung der Website, sich zu Beginn ein höheres Datenaufkommen ergibt.

Bei Experimenten mit den Werten für die beiden Limits zeigte sich, dass man recht leicht viel zu viel Traffic ausschließt. Auch die im Beispiel von Listing 1 abgedruckten Werte können für Ihre Webserver-Konfiguration noch zu restriktiv sein. Sie sollten also damit experimentieren und sie gegebenenfalls erhöhen.

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023