© Sergej Trjapicyn, 123RF

Um DDoS-Angriffe abzuwehren, schlüpfen Websites und Dienste oft unter die Schutzschirme von Internetriesen. Auch Amazon verteilt solche an seine AWS-Kunden. Doch welche Alternativen gibt es?

DDoS-Angriffe (Distributed Denial of Service) sind eine ähnlich schlimme Plage wie die Ransomware-Attacken in letzter Zeit. Im Rahmen einer Erpressung, als gezielter Angriff oder als Form des virtuellen Vandalismus überflutet ein Schwarm von Angreifern eine Website mit massiven Anfragen, um sie außer Betrieb zu setzen.

Selbst Unternehmen mit großzügiger Internetanbindung im 10- bis 40-GBit/s-Bereich stehen mitunter Attacken mit mehreren 100 GBit/s machtlos gegenüber. Eine Internetsuche nach »Biggest DDoS« liefert regelmäßig neue Werte für die Bandbreite solcher Angriffe. Aktuell liegt die Spitze bei etwa 1 TBit/s.

In der Vergangenheit nutzten Angreifer häufig so genannte Reflection Attacks. Bei denen schickt ein Angreifer zahlreiche Pakete mit der IP-Adresse des Opfers als Absender an Server, die diese Anfragen mit langen Antworten würdigen. Dank der falschen IP-Adresse schicken sie diese großen Antworten allerdings an die Adresse des Opfers. Mit dem Internet der Dinge stehen den Angreifern nun noch wesentlich einfacher zu benutzende Plattformen zur Auswahl. Für die letzten Angriffe zeichneten deshalb gehackte Überwachungskameras, Kühlschränke und Billigrouter verantwortlich.

Die DDoS-Familie

Grob lassen sich drei Kategorien von DDoS-Angriffen unterscheiden. Die eben beschriebene heißt Flutung. Indem hier viele Rechner große und zahlreiche Datenpakete an ein Opfer schicken, erschöpfen sie dessen Bandbreite oder führen die Infrastruktur mit zu vielen Einzelpaketen an ihre Kapazitätsgrenze. Bei einer State Exhaustion halten Firewalls oder Load Balancer einen Zustand pro Verbindung, den sie zugleich in eine Tabelle eintragen. Viele offen gehaltene Verbindungsversuche füllen diese Tabelle zügig, wobei Linux randvolle Tabellen etwa mit der Meldung »nf_conntrack: table full, dropping packet« quittiert. Will ein Kunde in diesem Stadium auf den Webshop zugreifen, weist der ihn ab.

Dem Autor sind Fälle bekannt, in denen ein Angriff mit einer Bandbreite von 2 MBit/s genügte, um ein Netz hinter einer Firewall offline zu nehmen. Synflooding macht das Gleiche mit der TCP-Verbindungstabelle des Kernels. Im Zuge des Drei-Wege-Handshakes beim Verbindungsaufbau schickt der Angreifer nur das erste Paket. Das legt aber einen Eintrag für diese Verbindung an. Ist die Tabelle voll, erhalten alle folgenden Verbindungsaufbauten ein »Connection Refused« als Antwort.

Nicht zuletzt gibt es ausgefeilte Angriffe gegen Schwachstellen in Applikationen. Hier brauchen Angreifer oft nicht einmal das erste D in DDoS. Als Pentester stieß der Autor einst auf eine Suchfunktion in einem in Java implementierten Webportal, die für jede Suche einen GByte-großen Subthread startete. Ein Skript mit zehn Suchanfragen pro Sekunde legte die komplette Plattform lahm.

Deiche bauen

Als Standardmittel in der Netzwerk-Verteidigung gilt die Firewall. Die hilft aber nicht wirklich, da sie meist nur die Daten eines einzelnen Pakets als Kriterium für das Zulassen oder Abweisen von Verbindungen verwendet, nicht aber die Menge und Größe der Pakete. Bessere Firewalls bieten (genau wie der Linux-Kernel) Features zur Bandbreitenkontrolle pro Verbindung, aber diese bildet die CPU ab und nicht die Netzwerkhardware.

Eine eigene Klasse von Geräten filtert wie eine Firewall, macht dies aber abhängig von der Quantität der Pakete (insgesamt und auf Verbindungsebene). Dedizierte Asics oder FPGAs arbeiten das Regelwerk in Hardware ab. Dafür haben die Geräte auch einen stolzen Preis: Wer Angriffe mit 150 GBit/s abfangen möchte, zahlt einen gut sechsstelligen Betrag.

Leider nützen diese Ansätze wenig, wenn der Verteidiger des Netzes am dünnen Ende der Leitung sitzt. Bevor das Gerät überhaupt zum Filtern kommt, ist die Leitung verstopft. Zwar schützen die Maßnahmen die Infrastruktur, aber weder können die Internen ins Netz, noch ist die Firma von außen erreichbar.

Grundsätzlich muss die Abwehr in zwei Schritten erfolgen: Zunächst sollte der Admin einen Angriff als solchen erkennen, dann den Angriffs-Traffic ableiten. Erkennen kann er Angriffe an verschiedenen Parametern, zum Beispiel:

• an der Menge und Größe der Pakete pro Quell- und Zielport oder IP-Adresse,
• an der Menge und Größe der Pakete innerhalb einer Verbindung (besteht eine Verbindung üblicherweise nur aus einem Anfrage- und einem Antwortpaket, so sind 20 Anfragepakete bereits verdächtig),
• an den Summen über diesen Daten.

Daten zapfen

Die wenigsten Protokolle und Anwendungen folgen aber statischen Regeln. Sind im Webshop 100 Anfrage pro Stunde normal, so mag sich dies im Weihnachtsgeschäft oder nach Marketingaktionen schnell vervielfachen. Auch regelmäßige Bewegungen der Werte aufgrund der Tageszeit oder des Wochentags sind üblich. Hier müssen Statistikprogramme ran, die zunächst herausfinden, was überhaupt normal ist, und dies auch über eine Zeitachse darstellen. Treten dann Abweichungen von normal auf, lässt sich dies als Angriff einstufen.

Für das Erheben dieser Traffic-Daten gibt es zwei Ansätze: In Variante 1 wird ein Gerät inline gehängt, also an zwei Kabel, die als Brücke zwischen draußen und drinnen dienen. Es schneidet dann im Promiscuous Mode alle Daten mit und erhebt so die Statistiken.

In Variante 2 hängt der Admin ein solches Gerät an einen Spiegelport eines Switch, damit ein Ausfall nicht die Verbindung trennt. Oder er verwendet Netflow [1], S-Flow [2] oder Ipfix (Internet Protocol Flow Information Export, [3]). Diese Protokolle liefern (unterschiedlich detailliert) die gesuchten Verbindungsdaten. Netzwerk-Komponenten wie Router oder Switches schicken sie dann an einen Empfänger, der die statistische Auswertung und Alarmierung vornimmt.

Auf Abwehr schalten

Die Abwehrmaßnahmen bestehen aus dem Blocken des unerwünschten Traffic. Meist filtert der Admin dabei die angegriffene Ziel-IP-Adresse (oder den Netzblock) weg, und zwar vollständig. Dazu legt er entweder ACLs auf den Routern oder per BGP [4] eine Null-Route an. Dabei handelt es sich um einen Eintrag in der Routingtabelle, der alle Pakete, die zur angegriffenen IP-Adresse wollen, auf dem vorgelagerten Router verwirft. Das führt zwar dazu, dass der angegriffene Server trotzdem offline ist, aber der Rest der Leitung bleibt frei.

Chirurgischer geht die BGP-Erweiterung Flowspec [5] vor, die es erlaubt, ACLs über das BGP-Protokoll zu verteilen, die auch Zielports und Protokolle enthalten. Schickt eine NTP-Reflection-Attacke viele Pakete auf UDP-Port 123 an den Server, und blockiert der vorgelagerte Router nur diese, erreichen ihn Dritte noch über die Ports 80 und 443 (TCP). Das unterstützen aber nur wenige Routerhersteller.

Generell erlaubt kaum ein Provider, dass Kunden auf diese Art Filterregeln auf seine Router verteilen. Besitzt der Provider eine leistungsfähige DDoS-Appliance, leitet er den infizierten Traffic des Kunden durch diese und schaltet passende Regeln, sodass nur noch die erwünschten Daten beim Opfer ankommen.

Die Abwehr gegen Flutung muss jedoch am dicken Ende der Leitung erfolgen, also beim Provider oder bei fremdgehosteten Webseiten im Rechenzentrum. Das wirft aber die Frage auf, mit welcher Bandbreite Letzteres am Internet hängt. Eine 40-GBit/s-Anbindung mag für den normalen Betrieb eines Rechenzentrums vollkommen ausreichen, gilt im DDoS-Umfeld aber eher als Kindergarten. So erlebte der Autor bei einem Kunden einen Angriff mit mehr als 200 GBit/s gegen einen einzelnen Server, ohne dass kommerzielle Interessen im Spiel waren.

Datenwäsche

Es gibt einzelne Provider wie etwa Ewe [6] in Norddeutschland, die ihren Kunden DDoS-Schutz gegen Bezahlung anbieten. Sie besorgen die teuren Geräte, die dies können, und vermieten sie dann an Kunden.

Üblicher ist aber die Variante Cloud Mitigation. Hier “wäscht” ein dedizierter Anbieter den Traffic. Dazu betreibt er in einem sehr breitbandig angebundenen Rechenzentrum eine Farm von Anti-DDoS-Appliances, in die er den Datenverkehr eines Opfers umleitet, um ihn zu säubern und dann über einen Tunnel zum eigentlichen Ziel zu leiten.

Es gibt zwei Möglichkeiten, den Verkehr umzuleiten. Dies kann zum einen auf DNS-Ebene passieren. Richtet sich der Angriff gegen »www.beispiel.de«, leitet der Admin den DNS-Eintrag auf eine IP in der Waschanlage um. Es dauert aber, bis der Rest des Internets von der Änderung Wind bekommt. Der Admin sollte die Time-to-Live der DNS-Anfragen niedrig halten, damit das Caching der Nameserver die Umleitung nicht verzögert.

Zum anderen können Routingprotokolle (meist BGP) den Traffic umleiten. Hierbei muss der Admin beachten, dass dies nicht mit einzelnen IPs, sondern nur mit ganzen Netzblöcken klappt. Der Vorteil ist, dass sich diese Pfadänderungen schneller im Netz herumsprechen.

Das dünne Ende

Die Verteidigung gegen State-Exhaustion-Angriffe kann auch am dünnen Ende der Leitung erfolgen. Kommt Netfilter als Firewall zum Einsatz, besteht der erste Schritt darin, den Systemparameter »net.netfilter.nf_conntrack_max« (oder »/proc/sys/net/netfilter/nf_conntrack_max«) zu überprüfen. Er gibt die maximale Anzahl von Einträgen für Verbindungen an. Der Standardwert variiert zwischen 32768 und 65536. Das füllt ein Angreifer relativ schnell.

Mittels »sysctl -w« setzt der Admin diesen Wert aber einfach auf bis zu 2 GByte (231-1) hoch. Allerdings sollte die Maschine über genügend physischen Speicher verfügen, um so viele Einträge vorzuhalten. Ein Eintrag verbraucht gut 300 Byte (im Detail ist es etwas komplizierter, [7] führt dies genauer aus), sodass für die gut zwei Milliarden Einträge mehr als 700 GByte RAM notwendig wären. Laut der zitierten Seite bekommt der Kernel mit rund 512 MByte 1,7 Millionen Einträge unter, was schon einige Größenordnungen höher ist als der Standardwert.

Gegen Synflooding kann der Kernel so genannte Syncookies verwenden. Der Server schickt dabei eine Antwort, legt aber keinen Eintrag in der Tabelle an. Bei Synflooding-Angriffen fehlt das dritte Paket. Trifft es doch ein, erkennt der Server dies und legt den Eintrag an. Um dies zu ermöglichen, konstruiert der Kernel die Sequenznummern so, dass er sie im ACK-Paket wiedererkennt.

Die DDoS-Appliances beherrschen dies auch, bieten aber zusätzlich noch die Möglichkeit, als TCP-Proxy zu arbeiten. Das bedeutet, sie führen den Handshake erst einmal stellvertretend durch und reichen nur, wenn er zustande kommt, die Verbindung an den eigentlichen Server durch. Dies können auch die meisten modernen Firewall-Systeme.

Schwerere Angriffe wehren Angegriffene auf derselben Ebene ab. Bei Webanwendungen sollte ein Reverse Proxy, etwa ein Apache mit »mod_security«, einspringen. Das Modul erlaubt es, die Anzahl der Anfragen pro Quell-IP-Adresse mit Regeln zu versehen und zu begrenzen. Das muss der Admin aber pro URL in Handarbeit konfigurieren.

Abbildung 1: Amazon schützt seine Kunden in begrenztem Maße auch gegen DDoS-Angriffe. Wer mehr Schutz will, muss allerdings recht tief in die Tasche greifen.

Die DDoS-Appliances gestatten es auch hier, auf Transaktionsebene Limits zu setzen. Der Admin sollte aber vorher bei den Herstellern prüfen, welche Protokolle sie wie unterstützen. A10 Networks [8] bietet sogar an, beim Überschreiten eines Grenzwerts dynamisch Captchas in den Strom zu schalten, und erst dann weitere Anfragen der betroffenen Quelladresse zuzulassen, sobald sich ein Mensch am Captcha verifiziert hat.

Amazons Schild

Amazon bietet unter dem Namen AWS Shield [9] einen Schutz vor DDoS-Angriffen (Abbildung 1). Die Basic Protection steht jedem AWS-Kunden implizit zu. Das Produkt beinhaltet das Erfassen der Network-Flowdaten und eine automatische Mitigation gegen DDoS-Angriffe via Synflooding oder UDP-Reflection-Angriffe. Informationen über eine erfolgreiche Abwehr erhält der Nutzer dabei allerdings nicht. Greift er zum Produkt AWS Shield Advanced, erhält er für rund 2600 Euro im Monat zuzüglich Gebühren für den Datentransfer noch die folgenden zusätzlichen Funktionen:

• Neben Verbindungsdaten auf Netzwerkebene erhebt und analysiert Amazon Transaktionslogs auf Applikationsebene.
• Zugriff auf erweiterte Waschmaschinen-Kapazitäten.
• Benachrichtigung bei Angriffen auf den ISO-Schichten 3 und 4 sowie Daten zur Art des Angriffs.
• Reports für ISO-Schichten 3, 4 und 7.
• Incident Management durch Amazons DDoS-Response-Team.
• Gegebenenfalls manuelle Mitigation.
• Manuelle Analyse nach dem Angriff.
• Rückvergütung für die durch den Angriff entstandenen Kosten für die Dienste Cloudfront, Route53 und Elb.

Wichtig dabei ist, dass Amazon nur beschützt, was bei Amazon läuft. Es ist zwar möglich, den Datenverkehr auf eigene Server durch Dienste wie Cloudfront oder einen Reverse Proxy zu schützen und den Schutz auch für die eigene Leitung zu nutzen, doch zielgerichtete Angriffe wehrt ein Admin so nicht ab.

Arbor-Appliance

Arbor [10] stellt DDoS-Erkennungs- und -Abwehr-Systeme auf Basis eigener Hardware her. Die Firma bietet Traffic-Waschanlagen in Rechenzentren in den USA, Europa und Asien an. Der Service wehrt Angriffe aber nur ab, erkennen muss sie der Kunde selbst.

Die Lizenzierung richtet sich nach der Bandbreite des sauberen Verkehrs. Besitzt ein Kunde eine 1-GBit/s-Leitung, zahlt er für das 1-GBit-Paket. Daneben bietet Arbor ein Paket mit monatlicher Gebühr an sowie eines mit einer Verteidigung gegen zwölf Angriffe pro Jahr. Die Pakete enthalten jeweils den Schutz eines »/24«-Netzwerks inklusive fünf DNS-Namen und sind erweiterbar. Das Auslösen der Abwehr lässt sich bei Arbor an ihre Appliance koppeln. Die erkennt einen Angriff, löst die Cloudabwehr aus und liefert Reports für die Angriffe.

Link11

Link11 [11] ist ein deutscher Anbieter auf dem Markt der DDoS-Verteidigung. Auch er offeriert den Schutz per BGP, DNS-Umleitungen sowie die Möglichkeit, Rechenzentren von Hostern direkt anzuschließen. Die Lizenzierung unterscheidet sich in der DNS- und der BGP-Variante. Beiden gemeinsam ist, dass sie als sauberen Traffic 95 Percentil des normalen Traffic (ohne Angriffe) zugrunde legen.

Bei DNS zählt Link11, wie viele IP-Adressen es auf den Originalsystemen schützt. Dazu kommen Staffelungen des sauberen Traffic von 25, 50, 100, 150 sowie 250 MBit/s. Im BGP-Fall zählt die Größe in Form der Netzmaske als ein Parameter, wobei die Zählung von einem »/24«-Netz aufwärts geht. Der zweite ist wieder die geschützte Bandbreite (Link11 unterscheidet zwischen symmetrischem und asymmetrischem Routing), Staffeln sind hier 250, 500 und 1000 MBit/s.

Akamai

Akamai [12] betreibt eines der größten Content-Delivery-Netzwerke (CDN) weltweit. Es nutzt sein Netzwerk auch, um DDoS-Schutz in der Cloud zu offerieren. Akamai verkauft neben den DNS- und BGP-Varianten auch einen Proxy-Schutz, mit dem Admins einzelne Applikationen (etwa Ports auf IP-Adressen) unter Akamais Schutz stellen.

Abbildung 2: Auch Akamai, bekannt durch sein weltweites CDN, bietet Kunden gegen bar Schutz vor Angriffen.

Wie auch Link11 bietet das Prolexic-Connect-Produkt Rechenzentren die Option, unter die Fittiche des CDN zu schlüpfen (Abbildung 2). Das Abrechnungsmodell strukturiert Akamai wie auch Link11 als Abonnement und zieht 95 Percentil des sauberen oder normalen eingehenden Traffic zur Preisberechnung heran. In der BGP-Variante spielen noch die Menge der »/24«-er-Netze sowie die Menge der geschützten Standorte eine Rolle.

Fazit

Betreibt der Admin die eigene Infrastruktur bei AWS, dürfte er den dabei mitgelieferten Basisschutz dankbar annehmen. Der Preis für den fortgeschrittenen Schutz ist stolz. Admins sollten abwägen, ob die Amazon-Präsenz so geschäftsrelevant ist, dass sie den Aufschlag von mehr als 2600 Euro pro Monat rechtfertigt. Die Option, pro Angriff zu zahlen, kann sich wiederum schnell gegen den Geldbeutel der Opfer wenden.

Wer komplett von Amazon weg möchte, muss sich auch in Sachen DDoS-Schutz nach einem anderen Anbieter umschauen. Die hier vorgestellten Alternativen betreiben aber auch Rechenzentren in Europa, was schon aus Gründen der Latenz eine wichtige Rolle spielt.

Eine Universallösung kann der Artikel zwar nicht präsentieren, wohl aber ein paar Ratschläge. Da sich die Tarifstrukturen der Anbieter stark unterscheiden, sollte der Admin zunächst die eigene Bedrohungslage genau analysieren. Gab es bereits Angriffe oder Androhungen von Angriffen? Wenn ja, wurde die ganze Firma bedroht oder nur ein Angebot? Im letzten Fall kann sogar eine Umleitung über Amazon sinnvoll sein, gerade wenn das Volumen des regulären Traffic nicht so hoch ist. Link11 und Arbor bieten auf ihren Webseiten zumindest Links für den Fall eines konkreten Angriffs.

Aber auch wenn der Admin nicht mit konkreten Maßnahmen gegen DDoS-Attacken vorsorgt, sollte er zumindest einen Notfallplan in der Tasche haben und sich im Vorfeld genau über die möglichen Angebote in diesem Bereich informieren. Für im Orkan Stehende gilt es nämlich, keine Zeit zu verlieren.