© Pavel Klimenko, 123RF

Mit Open Flow und entsprechenden Controllern lassen sich DDoS-Angriffe auch innerhalb des eigenen Netzwerks entdecken und bekämpfen. Das hilft Cloudanbietern und Hostern gleichermaßen.

Angriffe nach dem Muster Distributed Denial of Service (DDoS) sind leider gängige Praxis, um Schutzgeld zu erpressen oder unliebsame Dienste aus dem Netz zu fegen. Solche Angriffe erreichen aktuell Bandbreiten von 300 GBit/s und mehr. Admins wehren sich meist, indem sie die Außengrenzen des eigenen Netzwerks absichern und über die Gateways auf ungewöhnliche Traffic-Signaturen lauschen.

Mitunter bekämpfen sie Volumen-basierte Attacken sogar noch weiter außerhalb des Netzes – auf der Seite des Internetproviders. Dieser kann den Angriffsverkehr ableiten oder blockieren, bevor er die Leitung verstopft und die Dienste des Opfers lahmlegt.

Bei Anbietern von Cloudlösungen, aber auch bei traditionellen Hostern sitzen die Angreifer und ihre Opfer jedoch häufig im selben Netzwerk. Dank Virtualisierung teilen sie sich womöglich denselben Rechnerkern. Der Artikel zeigt, wie Admins mit SDN-Technologien auch solche Szenarien erkennen und abwehren.

Space Invaders bemerken

Will ein Admin derartige Angriffe automatisch erkennen, wertet er in der Regel die Daten zur Netzwerkauslastung aus. Dazu sammelt er über Analyseplattformen wie Arbors Peakflow [1] oder Flowmons Collector [2] per SNMP Daten jener Router, die als Gateways fungieren, oder er lässt sich die Informationen über das Netflow- oder IPFIX-Protokoll zusenden.

Die zweite Variante arbeitet genauer, da sie für jede Einzelverbindung Daten liefert, zu denen die Quell- und Ziel-IP-Adressen, Ports sowie IP-Protokoll-Informationen gehören. Auf diesem Weg erkennt der Admin auch Abweichungen in den Verbindungsmustern. Reine SNMP-Zähler bieten solche Möglichkeiten, abhängig von der verwendeten Management Information Base (MIB, [3]), nicht unbedingt an. Abbildung 1 zeigt, wie ein typisches Setup aussieht, mit dem der Admin böswillige Verbindungen identifiziert. Dabei muss er beachten, dass das Einsammeln und Bereitstellen der Daten CPU-Last auf den Routern erzeugt.

Abbildung 1: Die Analyseplattform holt Daten von den Routern im und am Rande des Netzwerks, um mögliche DDoS-Angriffe zu erkennen.

In den meisten Fällen schwankt die Auslastung einer Internetanbindung abhängig vom Wochentag, von der Tageszeit und auch von der Arbeitsweise der Firma, die dahinter sitzt. Das macht es schwierig, statische Erkennungsregeln aufzustellen, da diese entweder zu enge Grenzen setzen oder zu viel Raum bieten und so den Angriff durchlassen. Der bessere Ansatz besteht darin, den normalen Verkehr einer statischen Analyse zu unterwerfen, über einen längeren Zeitraum und unter normalen Betriebsbedingungen. Darauf beruhende Regeln kennen die regulären Leistungsspitzen, bemerken aber idealerweise auch Angriffe.

Gegenmaßnahmen

Die einfachste Abwehr gegen eine DoS-Attacke bestünde im Blockieren der Quell-IPs des eingehenden Verkehres. Im Falle eines DDoS-Angriffs ist dies nicht so einfach, denn das erste D steht für Distributed. Das heißt, die Angriffe kommen von vielen verschiedenen Quell-IPs. Bleiben noch zwei weitere Blockade-Optionen: Eine besteht darin, die Ziel-IPs zu blockieren. Die andere filtert auf den Zielport, wozu der Angriff aber entsprechend strukturiert sein muss.

Zielen die Angriffe nur darauf ab, die Leitung zu verstopfen, verwenden die Angreifer häufig so genannte Reflection Attacks. Dabei missbrauchen sie über Bande Dienste wie DNS oder NTP, indem sie kleine Anfragen senden, welche die Dienste mit einer überlangen Antwort würdigen. Für ihre Anfragen tragen die Angreifer die IP-Adresse des Opfers als Absende-IP-Adresse ein, sodass die überlangen Antworten die Verbindungen des Opfers fluten.

Verwendet das Opfer die zum Angriff notwendigen Dienste (etwa NTP oder DNS) nicht oder nur intern, kann ein Filter die ungewollten Pakete blockieren. Beim Fluten per NTP würde ein Admin für den Filter beispielsweise »Any« als Quelladresse eintragen, als Ziel-IP-Adresse die des Opfers sowie den Quellport »123« und das IP-Protokoll »UDP« . Das würde die unerwünschten Pakete aussieben, ohne den Dienst des Opfers – etwa einen Webserver – zu behindern.

Das dicke Ende

Soweit die Theorie. In der Praxis erweist es sich meist als nutzlos, hinter einer 1- oder 10-GBit/s-Leitung einen Angriff mit einer 100-GBit/s-Bandbreite abzuwehren. Bis ein entsprechender Filter die interne Infrastruktur schützt, ist die Leitung schon dicht. Zwar trifft der Angriff die internen Server nicht, doch erreicht sie auch niemand mehr über das Internet – Angriff erfolgreich.

Eine wirkungsvolle Verteidigung postiert sich also am dicken Ende der Leitung. Hierfür gibt es mehrere Ansätze. Bei der so genannten Cloud Mitigation leitet der Internetprovider über das Border Gateway Protocol (BGP) den kompletten Verkehr über eine Art Internetwaschmaschine um, bevor er die Server des Angriffsopfers erreicht.

Die Waschmaschine reinigt den Traffic mit Hilfe spezieller Appliances, die im Gegensatz zu herkömmlichen Firewalls auf DDoS-Verteidigung optimiert sind, und leitet dann den unbedenklichen Traffic über einen Tunnel an die Server des Opfers weiter. Das fügt zwar etwas Latenz hinzu, die spürt der Anwender in den meisten Fällen aber kaum. Einzelne Provider bieten ihren Kunden diesen Schutz auch direkt an, sodass eine Umleitung gar nicht erst nötig wird.

Bei größeren Anbindungen, die auch intern das Border Gateway Protocol sprechen, ist es möglich, im Router eine Null-Route auf das Loopback-Device für die angegriffenen Ziele zu konfigurieren und diese nach außen zu propagieren, also an den Provider [4]. Der Nachteil: Nicht nur müssen die Internetprovider mitspielen, das Vorgehen fegt auch die komplette IP-Adresse aus dem Netz und alle über sie erreichbaren Dienste. In der Regel muss der Admin zudem weitaus größere Netzblöcke blockieren, da die BGP-Filter so kleine Routing-Einträge nicht akzeptieren.

Intracloud

In den bislang beschriebenen Szenarien gab es zudem stets ein Außen und ein Innen. Die im letzten Abschnitt beschriebenen Erkennungs- und Filtermethoden greifen nur an den Außengrenzen eines Netzwerks. Missbrauchen Angreifer hingegen Teile der eigenen Infrastruktur, lässt sich dies höchstens am ausgehenden Traffic erkennen, was aber nicht alle Lösungen untersuchen.

Für Betreiber einer Cloudumgebung stellt sich die Situation also unter Umständen etwas komplexer dar. Viele von den Kunden selbst betreute VMs erhalten bei einem Infrastructure-as-a-Service-Angebot nicht immer die neuesten Patches. Das macht sie verwundbar und zu potenziellen Quellen eines DDoS-Angriffs, etwa über NTP-Reflection-Attacken.

Für DDoS-Angreifer sind schnell angebundene Systeme in einem Rechenzentrum die Rosinen. Denn anders als mit Privatanschlüssen können sie hinter einer ADSL-Leitung auch mit hoher Bandbreite senden und brauchen so weniger verwundbare Systeme für einen wirkungsvollen Angriff.

Es ist also denkbar, dass Angreifer sich ihr Opfer in derselben Cloud suchen. Unter Umständen laufen die angreifende und die VM des Opfers gar auf demselben Host. In diesem Fall erreichen die Kunden den Dienst ebenfalls nicht mehr, aber keines der externen Netzwerkgeräte (Router oder Switches) misst eine erhöhte Netzlast. Lediglich bei einem Blick in die virtuelle Infrastruktur fällt dem Admin die Anomalie auf. Was also tun für die innere Sicherheit?

Virtuell ist besser

Glücklicherweise bieten virtuelle Switches wie Open Vswitch (OVS, [5]) im Umfeld von KVM, Xen oder Open Stack, aber auch die Distributed Switches von VMware die Möglichkeit, Netflow-Daten zu exportieren. Will ein Admin den OVS namens »testswitch« dazu bringen, Flow-Daten an die IP-Adresse »10.1.1.1:3000« zu senden, verwendet er folgendes Kommando:

ovs-vsctl -- set Bridge testswitch netflow=@nf -- --id=@nf create NetFlow  targets=\"10.1.1.1:3000\" active-timeout=30

Kommt zum Verwalten vieler VMs auf vielen Hosts ein Framework wie Open Stack zum Einsatz, ist diese Funktion aber leider noch nicht integriert. Der Admin muss sie auf den einzelnen Compute Nodes manuell eingeben.

VMware splittet die Konfiguration in zwei Teile. Unter den Netzwerk-Einstellungen stellt der Netzverwalter pro verteiltem Switch (Distributed Vswitch) einen Netflow-Collector ein (Abbildung 2). Pro verteilter Portgruppe entscheidet der Admin dann, ob er Daten schicken möchte oder nicht (Abbildung 3).

Abbildung 2: VMwares Netflow-Einstellungen im Distributed Vswitch.

Abbildung 3: Auch die Portgruppe konfiguriert der Admin unter VMware separat.

Software Defined Networking

Im Falle von Open Vswitch blockiert der virtuelle Switch bei Bedarf auch die Angriffspakete. Hier kommt nun das Linux-Magazin-Titelthema “SDN-Technologie” zum Zuge. Open Vswitch versteht das Open-Flow-Protokoll (siehe Kasten “Open Flow”). Es ist in der Lage, Pakete nach bestimmten Kriterien zu verwerfen. Per Kommandozeile generiert der Admin solche Filter mit Hilfe des Tools »ovs-ofctl« . Ein Beispiel, das alle Pakete in Richtung IP-Adresse »10.1.1.2« und auf den UDP-Zielport »1234« verwirft, sieht so aus:

ovs-ofctl add-flow testswitch ip,nw_dst= 10.1.1.2,udp,udp_dst=1234,actions=drop

Als Clou muss sich der Admin in SDN-Umgebungen nicht auf jedem Gerät einzeln einloggen. Vielmehr übernimmt eine zentrale Stelle im Netz das Steuer. Ein Controller verwaltete die Flows aus einer Hand und verteilt sie auf alle relevanten Geräte, der Admin agiert quasi aus der Vogelperspektive.

Flusskontrolle

Einer der bekanntesten Controller heißt Open Daylight [7]. Er kommuniziert über verschiedene Protokolle mit den verwalteten Geräten, darunter auch über das Open-Flow-Protokoll. Für die Anwender stellt der Controller ein Restful-API bereit, das die Konfiguration der Geräte erlaubt. Restful-Schnittstellen spiegeln in der URL das Objekt wider, das der Anwender gerade bearbeitet, während die HTTP-Methode die darauf anwendbaren Aktionen abbildet.

Auf logischer Ebene bedeutet dies, bildlich gesprochen, dass der Zugriff

DELETE http://server/auto/tür/linksvorne/fensterscheibe

das Fenster in der linken vorderen Tür entfernt. Beim Übermitteln der Daten, im Beispiel beschreiben sie eine Tür, übergibt das REST-API die Parameter des Objekts entweder in Json-Notation oder in Form von XML.

Das API, mit dem ein Admin Flows in Open Daylight verwaltet, liegt unterhalb eines Node. Ein Node ist im Open-Flow-Kontext von Open Daylight nichts anderes als ein (virtueller) Switch. Open Daylight unterscheidet zudem zwei Präfixe: Mit einem manipuliert es Objekte, mit dem anderen fragt es die Datenbank der existierenden Objekte ab. Typischerweise lauscht der Controller auf Port 8181. Das URL-Präfix zum Verändern der Objekte lautet »http://server:8181/restconf/config« , das zum Auslesen »http://server:8181/restfonf/operational« .

Der Admin verlängert die URLs entsprechend, um in den funktionalen Baum des Controllers einzutauchen. Ein URL-Pfad zum Anlegen eines Flow kann dann so aussehen:

http://server:8181/resconf/config/opendaylight-inventory:nodes/node/openflow:12345/table/0/flow/2

Dabei bildet »opendaylight-inventory:nodes« den Einstiegspunkt zu allen Objekten vom Typ »node« . Konkret ist der Node vom Typ »openflow« und trägt die ID »12345« . Tragen sich weitere Protokolle in diese Tabelle ein, könnten sie das Präfix »openflow« vor der ID des Node ersetzen.

Der Switch hat einen Namen, ihm folgt der Begriff »table« , dann der Index der Tabelle. Ein Admin sollte bedenken, dass Open Flow ab Version 1.3 mehrere Tabellen mit Flows verwaltet. Der Flow kann also in eine andere Tabelle springen und dort weitermachen. Am Ende der URL wartet der Eintrag »flow« mit einer eindeutigen ID.

Flussbett

Über die Methode »PUT« erzeugt der Admin einen neuen Flow. Was der Flow filtern und welche Aktion er im Erfolgsfall starten soll, definiert er im Json- oder XML-Format. Die Open-Flow-Implementierung auf dem ausführenden Gerät setzt die Grenzen der Filtermöglichkeiten. Je nach Open-Flow-Version kann der Admin hier auf alles Mögliche filtern, von der Ethernet-Ebene bis hin zu Flags im TCP-Header.

Will er einen DDoS-Angriff abwehren, sollten Filter für IPv4- und IPv6-Adressen, das IP-Protokoll und der Zielport genügen. Auch einige Aktionen lassen sich starten. Mit Open Flow kann er nicht nur Pakete verwerfen, sondern auch Adressen und VLANs verändern und den Ausgabeport festlegen – und das sind nur einige der vielen Optionen.

Interessant für eine DDoS-Abwehr wäre auch das Rate Limiting, das zu den erwähnten Meters gehört. Leider unterstützt Open Vswitch es nicht, weshalb für diesen Anwendungsfall nur die Aktion »DROP« bleibt. In der Logik von Open Flow ist das Verwerfen eines Pakets ein Filter ohne Aktion, die Json-Syntax dazu zeigt das Beispiel in Listing 1.

01 {
02     "flow": {
03         "id": "5", "match": {
04             "ethernet-match": {
05                 "ethernet-type": {
06                     "type": "0x0800"
07                 }
08             }, "ip-match": {
09                 "ip-protocol": 17
10             }, "ipv4-destination": "10.1.1.2\/32", "udp-destination-port": 1234
11         }, "table_id": 0, "priority": 10
12     }
13 }

Diese Flow-Definition bewirkt das Gleiche wie das weiter oben gezeigte Beispiel mit »ovs-ofctl« . Was der Admin beachten sollte: Um IP-Pakete zu klassifizieren, muss die Definition den entsprechenden Ethernet-Typ enthalten (bei IPv6 wäre dies »0x86dd« ). Um UDP-Pakete zu beschreiben, muss er das IP-Protokoll nennen. Es würde zwar Sinn ergeben, dass sich der Controller den Rest denkt, falls er nur die Port-Definition eintippt, leider ist dem nicht so.

Auch wichtig ist, dass der Flow-Verwalter IP-Adressen mit der Maske »/32« angibt, wenn es sich um eine einzelne Adresse handelt. Eine weitere Eigenheit sind die Felder »id« und »table_id« , sie müssen zu dem Pfad in der URL passen. Andernfalls akzeptiert der Controller den Flow zwar ohne Murren, aber er legt ihn nicht an. Das bedeutet, dass dieser Flow für den Open-Flow-Node »1« ausschließlich unter folgender URL funktioniert:

http://server:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:1/table/0/flow/5.

Ein letztes wichtiges Feld ist die Priorität, nach der Open-Flow-fähige Switches die auf ihnen angelegten Flows sortieren. Je höher sie ist, desto wichtiger der Flow. Gewöhnlich gibt der Admin den OVS-Switches einen Flow mit der Aktion »NORMAL« . Das bedeutet: “Benimm dich wie ein Switch mit Priorität 1.” Wollen Filter dieses Verhalten überschreiben, benötigen sie eine höhere Priorität.

Weg damit

Um diese Definition hochzuladen, stehen dem Admin mehrere Wege offen. Er kann ein Programm in seiner Lieblings-Programmiersprache nutzen. Aufgrund der einfachen Struktur benötigt er nicht einmal eine REST-Bibliothek, sondern lediglich eine, die HTTP unterstützt. Um einzelne Requests zu testen, eignet sich ein REST-Client als Browser-Plugin. Postman für Chrome [8] ist eine sehr leistungsfähige Variante (Abbildung 4). Auch Curl eignet sich zum Hochladen von Daten (Listing 2).

01 curl    -u admin:admin
02         -H "Accept: application/xml"
03         -H "Content-Type: application/json"
04         -X PUT
05         -d @drop.json http://ODL:8181/restconf/config/opendaylight-inventory:nodes/node/openflow:1/table/0/flow/5

Der Aufruf führt zum Erfolg, wenn die Json-Definition des Flow in der Datei »drop.json« liegt. Dank der Option »-d« akzeptiert Curl entweder einen String mit Daten oder es liest die Daten aus der Datei, die dem »@« folgt. Dem Parameter »-X« übergibt der Admin die HTTP-Methode, »-u username:password« erledigt die Autorisierung. Über die Option »-H “Content-Type: application/json”« teilt er dem Server mit, dass er die Daten im Json-Format übertragen will.

Alles zusammenbauen

Die Puzzleteile zum Erkennen und Unterbinden der Angriffe in der Cloudinfrastruktur sind nun alle vorhanden, jetzt muss der Admin sie zusammenfügen. Der kommerzielle Flowmon Collector [2] der tschechischen Firma Flowmon (ehemals Invea) wertet Netflow-Daten aus und baut daraus aussagekräftige Reports. Unter der Haube arbeiten mit »nfdump« und »nfsen« zwei Open-Source-Tools. Auf die gesammelte Datenbasis stürzen sich dann weitere Applikationen, um sie nach speziellen Kriterien auszuwerten. Eine dieser Flowmon-Applikationen heißt DDoS-Defender.

Abbildung 4: Mit Chromes Postman lädt der Admin eine Konfigurationsdatei hoch.

Für Subnetze, die der Admin auf DDoS-Aktivitäten überwachen will, definiert er eine Trainingsperiode. Ist sie abgelaufen, bestimmt eine Regel, wann die Software Aktionen auslöst. Dies kann etwa geschehen, wenn ein bestimmter Wert um mehr als 300 Prozent steigt. Zu den auslösbaren Aktionen gehört es, E-Mails zu schreiben, SNMP-Traps und Syslog-Nachrichten anzulegen und Umleitungen per Border Gateway Protocol und Shellskript einzurichten. Bei der letztgenannten Möglichkeit lässt sich wiederum ein Skript starten, das den Open-Daylight-Controller dazu anweist, filternde Flows zu schalten.

DDoS-Defender kann die Aktion auslösen, sobald er einen Angriff erkennt oder nachdem er Daten über den Angriff gesammelt hat, sodass bekannt ist, welche IP-Adressen und Ports bei diesem Angriff eine Rolle spielen. Ein Skript liest anschließend die gewonnenen Daten aus dem ihm übergebenen Environment aus. Auf dessen Basis und je nach dem gewünschten Verhalten baut es sich einen Filter und verteilt diesen selbstständig auf die passenden virtuellen Switches.

Fazit

Als SDN-Technologie steuert Open Flow Verkehrsströme [9]. Auch wenn es als Protokoll auf Netzwerkhardware (noch) nicht weit verbreitet ist – sieht man von Whitelabel-Betriebssystemen wie Picos [10] oder den Switches von Corsa [11] ab –, dient es in Umgebungen mit Open Vswitch als Standard.

Wie der Artikel zeigt, lässt sich die Technologie auch für Sicherheitsfunktionen einsetzen. Anstatt Pakete zu verwerfen, wäre es auch möglich, sie per Open-Flow-Flow über eine Art Waschmaschine ins Netz zu leiten, die gutartigen von bösartigem Verkehr trennt. Zugleich macht Open Flow mögliche Angriffe, die zwischen virtuellen Hosts stattfinden, sichtbar. Diese würden dem Administrator andernfalls wahrscheinlich verborgen bleiben.