Beim Distributed Denial-of-Service feuern Tausende von Rechnern so lange auf die eigenen Server, bis einer von beiden aufgibt – zumeist ist der lokale Server dabei der Verlierer. Solche gezielten Angriffe lassen sich zwar nicht verhindern, aber wirkungsvoll abschwächen. Dieser Artikel beleuchtet kostengünstige Ansätze, um die eigene Infrastruktur bestmöglich gegen den digitalen Massenansturm zu schützen.
Cyberangriffe kommen in vielen Formen daher: heimliches Ausspähen von Firmennetzen, Sabotage und Störaktionen. Bei einer Störaktion versucht der Angreifer, einen Server mit Anfragen zu überlasten, bis dieser seinen Dienst einstellt (Denial-of-Service; DoS). Das ist leichter gesagt als getan, denn Server haben in der Regel mehr Leistung in Reserve, als ein einzelner Client abrufen kann. Hier liegt die Idee nahe, denselben Server mit vielen Clients zu befeuern. Es entsteht eine verteilte Störaktion, das sogenannte Distributed Denial-of-Service (DDoS). Der Angreifer trommelt eine riesige Anzahl an Computern in Form eines Bot-Netzwerks zusammen.
Gegen einen DDoS-Angriff ist der IT-Verantwortliche nicht machtlos. Es ist jedoch wichtig, geeignete Maßnahmen im Vorfeld zu treffen. Denn während einer solchen Attacke ist die Internetleitung durch die Flut von Clientanfragen belegt und die Serverfarm reagiert nicht mehr. Die einfachste, wenn auch teuerste Maßnahme ist das Aufrüsten der eigenen Infrastruktur mit mehr Servern und mehr Bandbreite. Wenn das Budget diesen Ansatz zulässt, brauchen Sie nicht weiterzulesen. Für alle anderen beschreibt dieser Artikel verschiedene Möglichkeiten, die eigene Infrastruktur effizient zu schützen. Das Ziel ist hierbei nicht, sich gegen riesige Attacken zu schützen, die mit TBit/s einfchlagen, sondern die eigenen Server robuster zu machen.
Abgrenzung zum CDN
Viele Provider erwähnen DDoS und CDN (Content Delivery Network) im selben Zusammenhang. Ein CDN verteilt seine Server auf möglichst viele Rechenzentren überall auf der Welt. Das Ziel liegt darin, die Daten näher beim Kunden zu platzieren, um die Inhalte lokal auszuliefern und nicht um die halbe Welt zu schicken. Das spart dem Anbieter Bandbreite und macht die Dienste für den Kunden flüssiger.Gleichzeitig schützt das CDN ungewollt vor einem DDoS-Angriff, da der Angreifer es mit vielen Instanzen desselben Diensts zu tun hat. Gelingt es ihm, mit seiner verteilten Armee die Präsenz im Rechenzentrum A in Schach zu halten, kann der CDN-Provider einfach auf ein anderes RZ umschalten und seine Kunden von dort beliefern. Der Unterschied ist: DDoS ist der Angriff und CDN ist eine mögliche Verteidigung.
Betriebssysteme härten
Die erste Schutzebene erhalten die Server durch strengere Einstellungen im Betriebssystem. Diese reichen von kürzeren Timeouts, restriktiven Firewallregeln, allgemeinen Empfehlungen für Software und Bibliotheken bis hin zu konkreten Settings im Kernel. Eine einheitliche Richtlinie zum Aushärten des Betriebssystems gibt es nicht, jedoch eine Vielzahl von Empfehlungen [1].
Cyberangriffe kommen in vielen Formen daher: heimliches Ausspähen von Firmennetzen, Sabotage und Störaktionen. Bei einer Störaktion versucht der Angreifer, einen Server mit Anfragen zu überlasten, bis dieser seinen Dienst einstellt (Denial-of-Service; DoS). Das ist leichter gesagt als getan, denn Server haben in der Regel mehr Leistung in Reserve, als ein einzelner Client abrufen kann. Hier liegt die Idee nahe, denselben Server mit vielen Clients zu befeuern. Es entsteht eine verteilte Störaktion, das sogenannte Distributed Denial-of-Service (DDoS). Der Angreifer trommelt eine riesige Anzahl an Computern in Form eines Bot-Netzwerks zusammen.
Gegen einen DDoS-Angriff ist der IT-Verantwortliche nicht machtlos. Es ist jedoch wichtig, geeignete Maßnahmen im Vorfeld zu treffen. Denn während einer solchen Attacke ist die Internetleitung durch die Flut von Clientanfragen belegt und die Serverfarm reagiert nicht mehr. Die einfachste, wenn auch teuerste Maßnahme ist das Aufrüsten der eigenen Infrastruktur mit mehr Servern und mehr Bandbreite. Wenn das Budget diesen Ansatz zulässt, brauchen Sie nicht weiterzulesen. Für alle anderen beschreibt dieser Artikel verschiedene Möglichkeiten, die eigene Infrastruktur effizient zu schützen. Das Ziel ist hierbei nicht, sich gegen riesige Attacken zu schützen, die mit TBit/s einfchlagen, sondern die eigenen Server robuster zu machen.
Abgrenzung zum CDN
Viele Provider erwähnen DDoS und CDN (Content Delivery Network) im selben Zusammenhang. Ein CDN verteilt seine Server auf möglichst viele Rechenzentren überall auf der Welt. Das Ziel liegt darin, die Daten näher beim Kunden zu platzieren, um die Inhalte lokal auszuliefern und nicht um die halbe Welt zu schicken. Das spart dem Anbieter Bandbreite und macht die Dienste für den Kunden flüssiger.Gleichzeitig schützt das CDN ungewollt vor einem DDoS-Angriff, da der Angreifer es mit vielen Instanzen desselben Diensts zu tun hat. Gelingt es ihm, mit seiner verteilten Armee die Präsenz im Rechenzentrum A in Schach zu halten, kann der CDN-Provider einfach auf ein anderes RZ umschalten und seine Kunden von dort beliefern. Der Unterschied ist: DDoS ist der Angriff und CDN ist eine mögliche Verteidigung.
Betriebssysteme härten
Die erste Schutzebene erhalten die Server durch strengere Einstellungen im Betriebssystem. Diese reichen von kürzeren Timeouts, restriktiven Firewallregeln, allgemeinen Empfehlungen für Software und Bibliotheken bis hin zu konkreten Settings im Kernel. Eine einheitliche Richtlinie zum Aushärten des Betriebssystems gibt es nicht, jedoch eine Vielzahl von Empfehlungen [1].
Alle Best Practices zielen darauf ab, die Angriffsfläche so gering wie möglich zu halten. Wer keine Lust hat, die zahlreichen Schritte von Hand einzutippen, kann auf ein fertiges Skript [2] zurückgreifen. Allerdings nur, wenn die einzelnen Skriptzeilen bekannt sind und zur eigenen Sicherheitsrichtlinie passen. Das Ergebnis ist ein feuerfestes Betriebssystem, das sich nicht so einfach aufs Kreuz legen lässt.
Vertrauen ist gut, Kontrolle ist besser. Mit dieser Weisheit setzen Softwareauditoren an und überprüfen den lokalen Rechner auf unsichere Einstellungen und bekannte Schwachstellen. Wer nicht gerade OpenVAS auf seine Server abfeuern möchte, greift zum schlanken Lynis [3]. Das Tool ackert über zweihundert Tests durch und präsentiert nach wenigen Minuten seinen Report im Terminal oder als E-Mail. Alles, was verdächtig oder unsicher ist, erscheint in roter Schrift. Am Ende des Berichts verteilt das Tool konkrete Empfehlungen für eine sicherere Konfiguration.
Schutz auf den OSI-Ebenen 3 und 4
Den Schutzmantel auf den Ebenen 3 und 4 des OSI-Modells bezeichnen die großen Anbieter als Network Protection. Gemeint ist das Aussperren von Clients aufgrund ihrer IP-Adresse. Dazu können auch Geo-Blockaden gehören, die letztlich nur aus einer lange IP-Liste bestehen. Beispielsweise enthält die Sperrliste von FireHOL alle Adressen, die sich in der Vergangenheit ihren Platz auf einer schwarzen Liste gesichert haben [4].
Damit sind zwar die bekannten Störenfriede ausgeschlossen, aber die Liste berücksichtigt nicht die individuelle Angriffssituation. Hier greifen die dynamischen Blockaden von Fail2ban [5] unter die Arme (Bild 1). Das Tool geht davon aus, dass jede IP-Adresse gutwillig ist. Sobald eine Adresse mehrfach im Logbuch mit einem fehlgeschlagenen Anmeldeversuch auffällig wurde, gibt es einen Sperreintrag unter "iptables/nftables". Als Folge davon findet keine Kommunikation mehr mit dieser Adresse statt. Nach einer kurzen Wartezeit darf der Client hinter dieser Adresse wieder mitspielen und seine drei Versuche starten. Die Werte und Timeouts sind natürlich anpassbar und lassen sich bei aggressiven Bittstellern auf viele Stunden erhöhen.
Bild 1: Fail2ban notiert die IP-Adresse von fehlgeschlagenen Anmeldeversuchen und erstellt daraus eine Firewall-Blockade.
Einen Schritt weiter geht die Community mit CrowdSec [6]. Das Prinzip ähnelt Fail2ban, wobei sich alle Teilnehmer die Liste der ausgesperrten Adressen teilen. Wenn der unbekannte Angreifer anfängt und den ersten Server attackiert, informiert dieser Server die CrowdSec-Community und alle Teilnehmer verwandeln die IP-Adresse des Angreifers in eine Blockade. Eine Wörterbuch-Attacke auf den SSH-Dienst hat damit ein baldiges Ende. Umgekehrt sperren Sie so leider auch schnell die eigene IP-Adresse aus, wenn müde Finger tief in der Nacht das Passwort nicht richtig eintippen wollen.
Der Ansatz von Fail2ban und CrowdSec verhindert zwar wirksam das massenhafte Ausprobieren von User/Passwort-Kombinationen, hat aber zwei Schönheitsfehler. Zum einen steigt die CPU-Last, wenn der Server viele Anfragen erhält und Fail2ban große Logdateien parsen muss. Zum anderen blockiert Fail2ban mit einer IP-Adresse eventuell mehrere Clients, wenn diese sich eine öffentliche Adresse teilen – und das dürfte bei den meisten IPv4-Internetanschlüssen der Fall sein.
Geo-Blockaden einrichten
Wer ein internationales Publikum ansprechen will, muss auf seiner Webseite allen Ländern Zutritt gewähren. Umgekehrt gilt: Ohne Handelsbeziehung nach Asien und Afrika kann eine Geo-Blockade diese knapp einhundert Länder ausschließen. Ein Angreifer in Somalia erhält dann keinen SSH-Prompt, an dem er Passwortkombinationen ausprobieren kann.
Die Linux-Firewall steigt mit dem geoip-Modul und der kostenfreien Länder-IPListe von MaxMind ruckzuck zum Geo-Filter auf. Der Filterbefehl enthält als Quelle die Länderkennung statt einer IPAdresse. Die Blockade von Somalia realisiert iptables mit:
iptables -A INPUT -m state --state NEW -m geoip --source-country SO -j DROP
Je nach Infrastruktur oder Hosting-Angebot hängt vor dem Server noch eine Firewall mit Geo-Funktion. Diese ermöglicht eine komfortable Konfiguration der Sicherheitsrichtlinie per Web-GUI. In Bild 2 blockiert die Open-Source-Firewall OPNsense per Mausklick auf die Flaggensymbole den Zugang der einzelnen Länder.
Bild 2: Die freie Firewall OPNsense filtert Zugriffe nach Herkunftsland.
Webseiten absichern
Viele Webseiten bieten einen Bereich nur für Mitglieder an, der über ein Passwort zugänglich ist. Genau wie beim SSHDienst probiert der Angreifer gängige Kombinationen aus Benutzername und Passwort aus. Diese Methode führt irgendwann zum Erfolg, wenn nicht eine Form der "Website Protection" dem einen Riegel vorschiebt.
Der Webseiten-Beschützer arbeitet so: Er erteilt dem Webbrowser des Clients einen Arbeitsauftrag und zeigt die angefragten Webinhalte erst an, wenn die Aufgabe erledigt ist. Die Tätigkeit variiert von einer Checkbox "Ich bin kein Roboter" bis zu "Wähle alle Felder mit Ampeln aus". Andere Wächter verpacken die Aufgabe in JavaScript, das der Browser ohne menschliches Eingreifen abarbeitet (Proof of work). In allen Fällen wird der Zugang zum Webdienst einmalig ausgebremst, sodass ein DDoS-Angreifer deutlich weniger Anfragen pro Sekunde hinlegen kann. Der Trick beim Webschutz liegt darin, dass die große Last auf dem Client liegt und nicht beim Server. Der Client erhält die schwierige Aufgabe und der Server prüft lediglich, ob das Ergebnis stimmt.
Für diesen DDoS-Schutz müssen Sie nicht im vorhandenen HTML-Code herumschrauben. Der Webbeschützer arbeitet als gutartiger Man-in-the-Middle und schaltet seine Robot-Checks vor die eigentliche Webpräsenz. Technisch gestaltet sich das als Reverse-Proxy, der die Webanfragen aller Clients entgegennimmt und analysiert: Stammen von diesem Client auffällig viele Anfragen? Dann gibt es zunächst die Web-Challenge, die der menschliche Besucher beantworten muss.
Der Reverse-Proxy ist eine Software, die HTTP-Anfragen akzeptiert, aber selber keinen Inhalt hat. Für die Antwort greift der Reverse-Proxy auf einen anderen Webserver zu und liefert den HTML-Code stellvertretend (englisch "proxy") aus. Als Vermittler im Datenstrom kann der Proxy alles Mögliche in die HTML-Zeilen einschleusen, wie beispielsweise Captchas.
Captchas am Beispiel vDDoS
Neben kommerziellen Anbietern mit professionellem Webschutz tummeln sich entsprechende freie Anwendungen auf GitHub. So etwa die Software vDDoS [7], die ihren Clients Captchas ausspielt. Jeder Webbesucher ist vermutlich schon einmal über diese Miniaufgabe gestolpert und musste aus einer Auswahl von Fotos die richtigen anklicken (Bild 3). Diese Tätigkeit soll den menschlichen Besucher vom Skript unterscheiden.
Bild 3: Mithilfe eines Bilderrätsels in vDDoS prüft die Webseite, ob der Zugriff von einem Menschen stammt oder von einem Skript.
Das Tool lässt sich mit wenigen Zeilen unter Linux installieren:
Anschließend liegen alle Komponenten im lokalen Dateisystem unter "/vddos" bereit. In bester Open-Source-Manier coden die Entwickler von vDDoS nicht alles neu, sondern bedienen sich an vorhandener Software mit freier Lizenz: NGINX für den Webserver, Gunicorn als Web-Gateway und Flask als Python-Framework. Per Konfiguration beschreiben Sie Ihre Webseiten sowie die gewünschte Schutzmethode.
Im Listing unten zeigt sich vDDoS nach außen (Spalte "Listen") als HTTP/S-Server mit unterschiedlichem Schutzniveau (Spalte "Security"), der im Hintergrund (Spalte "Backend") mehrere Server anspricht. Den Startschuss gibt der Befehl: vddos start. Anschließend nimmt vddos Fahrt auf und bietet die konfigurierten Webseiten über seine eigene IP-Adresse an – mit eingebautem DDoS-Schutz.
default http://0.0.0.0:80 http://10.1.1.84:80 no 5s no no
www.example.net https://0.0.0.0:443 http://10.1.1.84:80 no 307 /vddos/ssl/example.key /vddos/ssl/example.crt
login.example.net https://0.0.0.0:443 http://10.1.1.85:80 no captcha /vddos/ssl/example.key /vddos/ssl/example.crt
Suchmaschinen und ihre Crawler
Für welchen DDoS-Schutz Sie sich auch entscheiden: Blockieren Sie nicht die Crawler der großen Suchmaschinen. Wenn der Schnüffel-Bot von Google, Microsoft oder DuckDuckGo auf ein Java-Script-Challenge stößt oder Fail2ban zuschlägt, ist es mit der Indizierung Ihrer Seite schlagartig vorbei. Glücklicherweise geben die Betreiber alle IP-Adressen an, unter denen ihre Bots das Internet kartografieren. Diese Adressen gehören auf die persönliche Ausnahmeliste, damit den Such-Bots nichts im Wege steht.
Sensor mit schwarzem Loch
Wer mehr als ein paar Server zu seinem Verwaltungsbereich zählt oder keine zusätzliche Software einbinden will, holt sich den DDoS-Schutz "aus dem Netz". Damit ist kein weiterer Anbieter im Sinne von As-a-Service gemeint, sondern ein Wächter, der an Switches und Routern ungewöhnlich hohe Verkehrsflüsse erkennt.
Router zählen durchfließende Pakete und melden diese im NetFlow-Format an einen zentralen NetFlow-Kollektor. Der Kollektor erhält die statistischen Informationen von allen Routern und gewinnt damit ein präzises Gesamtbild über die Auslastung der Leitungen. Bei Switches funktioniert es ähnlich: Sie schicken einen kleinen Prozentsatz der transportierten Pakete im sFlow-Format an den Kollektor, der aus den Stichproben auf die verwendete Bandbreite schließen kann.
Wenn die Anzahl der Pakete oder die übermittelten Byte pro Sekunde einen definierten Schwellenwert überschreiten, dann riecht es nach dem Beginn eines DDoS-Angriffs. Jetzt ist es Zeit zu handeln: Im einfachsten Fall gibt es eine Alarm-E-Mail. Automatisierte Systeme erkennen anhand der NetFlow/sFlow-Daten, welches Zielsystem angegriffen wird und informieren per Border Gateway Protocol (BGP) den Kundenrouter. Dieser leitet die Information umgehend an den Provider weiter. Die BGP-Router enthalten jetzt eine neue Host-Route, die den Traffic nicht mehr zum Zielserver leitet, sondern in den Bitmülleimer kippt. In der Routingtabelle entsteht für den angegriffenen Server ein schwarzes Loch. Sobald der Ansturm nachlässt, entfernt der Wächter die Host-Route und macht den Server wieder sichtbar. Das Konzept dahinter nennt sich "Remotely Triggered Black Hole" (RTBH).
Wer diese Form des DDoS-Schutzes kennenlernen möchte, dem sei die Community-Version von FastNetMon [8] empfohlen. Zu Testzwecken läuft FastNetMon auch ohne BGP-Interaktion und zündet bei einem DDoS-Alarm lediglich ein Bash-Skript. In dieser Phase lässt sich das eigene Netz beobachten und die Schwellenwerte einstellen. Sobald keine Fehlalarme mehr auftreten, darf der FastNet-Mon-Server BGP-Nachbar im eigenen autonomen System werden und Host-Routen verschicken.
Tools für Windows-Server
Die bisher vorgestellten Tools sind ausschließlich für Linux und Unix. Wer seinen Windows-Server über das Internet erreichbar machen möchte, kann die Windows-Firewall mit dem Zusatztool IPBan [9] oder EvlWatcher [10] zum DDoS-Schutz ausbauen. Beide Produkte arbeiten genau wie Fail2ban: Sie beobachten die Anmeldeversuche und blockieren die Quelladresse nach ein paar Fehlversuchen.
Die Einrichtung gestaltet sich bei IPBan besonders einfach: ZIP-Archiv von GitHub laden, entpacken und Executable starten. Im laufenden Programmfenster informiert IPBan, was es gerade macht und welche Logins es bemerkt. Den Wunsch nach Blockade gibt IPBan an die Windows-Firewall weiter. IPBan macht ein Windows-System damit nicht sicher, verringert aber die Angriffsfläche auf offene Dienste wie beispielsweise Remote Desktop oder VNC.
Kontrolle per DoS-Angriff
Alle Ihre Maßnahmen sollten Sie natürlich testen. Haben Sie aktuell kein Botnetz im Arsenal, sollten Sie zumindest einen einzelnen Client auf die nun geschützten Server loslassen. Für die nötigen Tools führt der Weg nicht ins Darknet, sondern erneut nach GitHub oder zur Linux-Distribution Kali. Vor dem ersten Angriff muss der rechtliche Rahmen abgesteckt sein: Der Kunde oder Arbeitgeber muss einer gewollten Attacke zustimmen. Außerdem ist es von Vorteil, die Angriffe nicht aus dem eigenen Netz zu starten, um nicht auf einer der oben genannten schwarzen Listen zu landen. Hier empfiehlt sich eine Wegwerf-VM bei einem Cloudanbieter. Da diese minutenweise bezahlt werden, ist der finanzielle Aufwand sehr überschaubar.
Eine einfache Belagerung macht der HTTP-Load-Tester "Siege", der in vielen Distributionen per Paketmanager zur Verfügung steht. Die Software erwartet als Argument die URL des Webservers und beginnt sogleich den Server mit GET-Anfragen zu bewerfen. Ohne DDoS-Schutz flitzen die Ergebnisse am Bildschirm rasend schnell vorbei. Mit aktiviertem Schutz ist nach wenigen HTTP-Zugriffen Schluss. Siege meldet dann nur noch kleinlaut: "Resource temporarily unavailable".
Wer seinen eigenen Angriff mit etwas mehr Feinschliff führen möchte, sollte MHDDoS [11] nutzen. Es bringt mehr als 50 Angriffsvektoren mit, die diverse kommerzielle DDoS-Abwehrsysteme austricksen und damit weit über eine simple Flut von GET- und POST-Requests hinausgehen. Über Kommandozeilenargumente legen Sie fest, wie viele Anfragen pro Sekunde den Server treffen sollen.
Kommerzieller DDoS-Schutz
Selbstverständlich gibt es auch zahlreiche kommerzielle Anbieter, die einen schlüsselfertigen DDoS-Schutz mit Support, Logging und Alerting anbieten. Diese reichen von cloudbasierten Ansätzen bis hin zu Hardware-Appliances, die meist als Erweiterung der Firewall ins RZ einziehen.
So bietet beispielsweise Branchenriese Cloudflare mit seinen "Application Services" einen DDoS-Webschutz an, der äußerlich genau wie vDDoS arbeitet: Unter der Haube nimmt ein Reverse-Proxy die Webzugriffe entgegen, untersucht sie und leitet den legitimen Traffic an den Server mit den Inhalten weiter. Damit das funktioniert, muss der DNS-Eintrag für die eigene Webpräsenz auf den Server von Cloudflare zeigen. Wichtig: Der eigene Webserver darf nur noch Anfragen von Cloudflare annehmen, sonst ist der DDoS-Schutz wirkungslos.
Der Vorteil liegt darin, dass Cloudflare und vergleichbare Angebote scheinbar mehr Bandbreite in Reserve haben, als die Angreifer (bisher) aufbringen konnten. Wer Attacken im mehrstelligen GBit/s-Bereich erwartet, der ist mit einem kommerziellen Anbieter gut beraten. Fun Fact: Dies klappt so gut, dass sich auch die bösen Buben mit ihren illegalen Webportalen entsprechend vor noch böseren Bösewichten schützen.
Fazit
Neben Ransomware-Angriffen stellen DDoS-Attacken Unternehmen vor große Herausforderungen. Unser Streifzug durch das Abwehrarsenal aus der Open-Source-Welt fördert einige Highlights zutage. Die Grundversorgung beginnt mit einem gehärteten Betriebssystem und anschließendem Securitycheck. Darauf folgen Wächter-Tools, die Logfiles im Auge behalten, fehlgeschlagene Login-Versuche erkennen und daraus automatisch Regeln für die lokale Firewall erstellen. Schließlich lassen sich Webseiten vor Anfragenschwemmen mit diversen Bilderrätseln in Form von Captchas schützen.
In größeren Umgebungen sitzt der DDoS-Sensor abseits der Serverfarm und erhält Verkehrsinformationen von Routern und Switches zugespielt. Sind die Durchsatzraten einzelner Clients ungewöhnlich hoch, geht die Blockade per BGP-Update an die Provider-Router und der Spuk ist vorbei. Sind diese Tools und Tricks zu viel Handarbeit oder überaus große DDoSAngriffe zu erwarten, stehen die gleichen Maßnahmen auch bei kommerziellen Anbietern im Regal.