Das Tempo der Digitalisierung und des technologischen Wandels nimmt exponentiell zu und verlangt von modernen IT-Infrastrukturen ein hohes Mass an Anpassungsfähigkeit, Zuverlässigkeit und Skalierbarkeit. Herkömmliche Netzwerkarchitekturen können ein limitierender Faktor sein, da sie sich möglicherweise nicht schnell genug an Veränderungen anpassen können. Software-Defined Networking (SDN) kann dazu beitragen, einige dieser Herausforderungen durch die Trennung der Netzwerksteuerung von der physischen Infrastruktur zu lösen, indem die Steuerungsebene von der Datenebene entkoppelt wird. Dies ermöglicht die zentrale Verwaltung und Steuerung von Netzwerken und macht die manuelle Konfiguration einzelner Netzwerkgeräte überflüssig, wodurch eine dynamische Netzwerkkonfiguration und -automatisierung ermöglicht wird. SDN wird daher häufig im Zusammenhang mit Zero-Trust-Architekturen erwähnt, insbesondere im Hinblick auf die Mikrosegmentierung. SDN kann dazu beitragen, eine granulare Segmentierung, die Durchsetzung von Richtlinien und eine verbesserte Flexibilität und Transparenz zu ermöglichen. In solchen Anwendungen, in denen SDN zur Unterstützung von Sicherheitszielen eingesetzt wird, ist die eigene Sicherheit von grösster Bedeutung.

Einführung zu Software-Defined Networking

Unternehmen setzen zunehmend auf Software-Defined Networking (SDN), um ihre Netzwerke neu zu definieren und dynamische Kontrolle, Programmierbarkeit und Flexibilität für die Netzwerkverwaltung zu bieten. Es ist ein Wechsel von den traditionellen statischen, hardwaregebundenen Netzwerken zu einem zentralisierten, softwaregesteuerten Ansatz. Diese Umstellung ist nicht nur eine Frage der Bequemlichkeit, sondern ein strategischer Imperativ im Zeitalter der digitalen Transformation. Doch aus grosser Macht folgt auch grosse Verantwortung. Wenn Unternehmen SDN zur Orchestrierung ihrer Netzwerke einsetzen, öffnen sie gleichzeitig die Türen zu einem neuen Spektrum von Herausforderungen, insbesondere im Bereich der Sicherheit.

Der fortschreitende Wandel der Netzinfrastruktur stellt ein dringendes Problem für die Netzsicherheit dar. Mit der Abkehr von der physischen Trennung und der eindeutigen physischen Identifizierung von Komponenten, die für verschiedene Funktionen wie Transport oder Sicherheit zuständig sind, wird der traditionelle Ansatz der Konfiguration mehrerer separater Komponenten obsolet. Bei unserem Streben nach den Vorteilen dieser Umstellung dürfen wir jedoch nicht die inhärenten Sicherheitsvorteile übersehen, die mit der physischen Konfiguration mehrerer Komponenten einhergehen. Diese Verlagerung hin zu einer zentralisierten Kontrolle im Software-Defined Networking kann ein zweischneidiges Schwert sein, das Effizienzvorteile, aber auch Schwachstellen bietet. Daher bleibt der Schutz vor Bedrohungen, insbesondere vor Distributed Denial of Service (DDoS)-Angriffen, in dieser sich entwickelnden Landschaft von grösster Bedeutung.

Sicherheitsherausforderungen

SDN bietet zwar zahlreiche Vorteile, bringt aber auch einzigartige Sicherheitsherausforderungen mit sich. Die beiden wichtigsten Sicherheitsherausforderungen sind DDoS-Angriffe, auf die wir uns in diesem Artikel konzentrieren werden, und die Sicherheit der Controller.

Der zentralisierte Controller in SDNs ist ein Hauptziel für Angreifer, und wenn er kompromittiert wird, kann dies zu schwerwiegenden Netzwerkunterbrechungen und unbefugtem Zugriff auf kritische Netzwerkressourcen führen. Im Gegensatz zu herkömmlichen Netzwerkgeräten sind Controller in SDNs stark gefährdet, da sie einen globalen Überblick über die Netzwerktopologie und ihre Richtlinien haben.

Um diese einzigartige Herausforderung zu meistern, müssen SDN-Controller mit starken Authentifizierungs- und Autorisierungsmechanismen abgesichert werden. Logging und Auditing sollten so konfiguriert sein, dass sie bei verdächtigen Zugriffen oder Vorgängen die notwendigen Informationen für die Generierung von Warnungen liefern. Die Kommunikation auf der Steuerungsebene muss durch Verschlüsselung geschützt werden, und es sollten regelmässige Sicherheitsaudits und -aktualisierungen durchgeführt werden. Die Zugriffskontrollrichtlinien müssen so abgestimmt sein, dass der Zugriff nur auf das erforderliche Minimum beschränkt ist.

Auch DDoS-Angriffe stellen aufgrund ihrer Grösse und Anpassungsfähigkeit eine erhebliche Bedrohung für SDNs dar. Im Gegensatz zu herkömmlichen Netzwerkarchitekturen wird bei SDNs die Kontrolle in einem softwarebasierten Controller zentralisiert, was sie anfällig für massive Verkehrsfluten macht. Dies macht SDNs zu besonders attraktiven Zielen für Angreifer.

Um dieser Herausforderung in SDNs zu begegnen, müssen spezialisierte Lösungen zur DDoS-Abwehr eingesetzt werden. Diese Lösungen umfassen häufig eine Echtzeit-Verkehrsanalyse und Mechanismen zur Erkennung von Anomalien, die den bösartigen Verkehr vom Ziel wegleiten können. In diesem Artikel schlagen wir eine Möglichkeit vor, einen DDoS-Angriff mithilfe eines Intrusion Detection Systems zu erkennen und zu entschärfen.

Mininet

Mininet ist ein Open-Source-Netzwerkemulator, der für die Erstellung simulierter Netzwerkumgebungen verwendet wird. Mit ihm können Benutzer komplexe Netzwerktopologien auf einem einzigen Rechner nachbilden, was ihn zu einem unschätzbaren Werkzeug für das Testen und Entwickeln von SDN-Lösungen macht. Er ermöglicht eine kosteneffiziente Netzwerksimulation und bietet eine präzise Kontrolle über Netzwerktopologien und Datenverkehr. Es ist wichtig zu beachten, dass Mininet zwar hervorragend zum Testen geeignet ist, aber auch einige Einschränkungen aufweist. Die wichtigsten Einschränkungen sind, dass erstens die Leistung des simulierten Netzwerks nicht immer der realen Hardware entspricht. Zweitens verwendet Mininet vereinfachte Switch-Modelle, die die Komplexität von SDN-Switches für Unternehmen möglicherweise nicht vollständig wiedergeben.

Ziel des Tests

Für diesen Artikel haben wir einen DDoS-Angriff von innerhalb einer SDN-Umgebung auf einen Webdienst ausserhalb des Netzwerks simuliert. Dies geschah in der Absicht, ein einfaches, aber realistisches Netzwerk zu replizieren. Der Hauptfokus dieses Artikels ist es, eine Methode und Strategie zur effektiven Erkennung und Abschwächung von DDoS-Angriffen innerhalb einer SDN-Umgebung zu beschreiben und die Bedeutung von fortschrittlichen Sicherheitsmassnahmen in SDN-Infrastrukturen zu verdeutlichen.

Simulation von DDoS-Angriffen auf Ihre SDN-Umgebung

Die Simulation von DDoS-Angriffen in einer SDN-Umgebung bietet Unternehmen einen proaktiven Ansatz zur Verbesserung der Netzwerksicherheit. Es hilft dabei, die Bereitschaft der SDN-Infrastruktur für die Erkennung und Eindämmung von DDoS-Angriffen zu bewerten und gleichzeitig die Reaktionsstrategien zu optimieren, um Ausfallzeiten und Auswirkungen auf die Kunden zu reduzieren. Dieser Ansatz erhöht die Sicherheit, spart Kosten und bereitet die Teams auf einen effektiven Umgang mit DDoS vor.

Eine virtualisierte Testumgebung ermöglicht kosteneffiziente Schulungen für IT- und Sicherheitsteams und bietet gleichzeitig Flexibilität für schnelle Anpassungen. Sie reduziert die Risiken für das Live-Netzwerk und ermöglicht es den Teams, Sicherheitsmassnahmen effizient zu validieren. Darüber hinaus ermöglicht sie eine schnelle Rekonstruktion mit geeigneten Tools und minimiert die manuelle Arbeit.

Setup

Für die Zwecke dieser Demonstration gehen wir von folgendem, vereinfachten Setup aus:

Auf der virtuellen Machine VM1 befinden sich ein OpendayLight Controller und Snort als IDS-Lösung, auf der zweiten VM befindet sich Mininet, das ein Netzwerk mit drei Hosts und einem OpenFlow vSwitch emuliert, der softwarebasiert ist und den OpenFlow-Protokoll-Client-Teil ausführt. Auf der dritten VM simulieren wir einen Webservice, der als Opfer fungiert. Die Verbindungen zwischen den verschiedenen Komponenten:

• Die bidirektionale Verbindung (a) zwischen dem OpenFlow-Switch und dem SDN-Controller, die den Steuerverkehr zwischen der Daten- und der Steuerungsebene austauscht – die Southbound-API.
• Die unidirektionale Verbindung (b) zwischen OpenFlow-Switch und IDS, die es dem Switch ermöglicht, den gesamten gespiegelten Verkehr zur weiteren Analyse an das IDS zu senden.
• Die unidirektionale Verbindung (c), die es Snort ermöglicht, den SDN-Controller über einen laufenden DDoS-Angriff durch Alarm-Pakete über den Unix Domain Socket zu informieren.
• Bidirektionale Verbindung (d), die die lokale Netzwerkdomäne mit einem Remote-Dienst verbindet.

Angriff Simulation

Der DDoS-Angriff wird mit dem Dienstprogramm hping3 durchgeführt. Die folgenden Parameter können für einen solchen Test besonders nützlich sein:

• --flood Sendet Pakete so schnell wie möglich, ohne die eingehenden Antworten zu berücksichtigen.
• -i Gibt das zu verwendende Interface an
• -1 Verwendet den ICMP-Modus
• -a Setzt eine gefälschte IP-Adresse
• -d Legt die Grösse der einzelnen Pakete fest

In diesem Fall werden wir die folgenden Szenarien in Betracht ziehen:

Vor dem Testen sollten wir uns zunächst einen Überblick verschaffen, wie sich das System unter normalen Umständen verhält. Mininet bietet genauso einen Befehl; mit dem pingall Programm kann man eine einfache Interaktion zwischen allen Systemen simulieren, die mit der Mininet-Instanz verbunden sind. In diesem Fall werden die Quality of Service Metriken wie der Prozentsatz der Paketverluste und die durchschnittliche Round Trip Time (RTT) in Milisekunden (ms) ausgewertet. Eine typische Systemleistung bei normaler Nutzung könnte wie folgt aussehen:

Das durch einen DDoS-Angriff erzeugte Verkehrsaufkommen, wenn das vorgeschlagene Verteidigungssystem deaktiviert ist, sieht wie folgt aus:

Daraus kann man erkennen, dass nach 50 Sekunden ein signifikanter Anstieg des Datenverkehrs zu verzeichnen war, der durch den DDoS-Angriff ausgelöst wurde. Im Maximum erreichte der Angriff etwa 43’000 Pakete pro Sekunde. Nach der Festlegung der Baseline folgen nun die entsprechenden Szenarien zur Eindämmung der Angriffe.

Szenario 1

Das erste Szenario simuliert einen DDoS-Angriff, der sowohl von H1 als auch von H2 ausgeht, während H3 seinen “guten” Zugang zum Remote-Server beibehält. In diesem Szenario wurde hping3 im ICMP-Modus verwendet, wobei Pakete so schnell wie möglich an das Opfer (192.168.1.100) geflutet wurden. Die Durchflussmenge von H3 während des Angriffs ist wie folgt:

Es ist zu erkennen, dass die Durchflussrate im Laufe der Zeit schwankt. Dies ist das Ergebnis der Netzwerküberlastung und des Ressourcenmangels auf dem Opfercomputer, die beide durch den DDoS-Angriff verursacht werden. Bei diesem Aufbau erfolgt die Erkennung des Angriffs über das IDS, in diesem Fall Snort. Glücklicherweise bietet Snort bereits einige vorgefertigte Erkennungsregeln, wie die für DDoS-Angriffe:

alert icmp 10.0.0.0/8 any → 192.168.1.100 any (msg: "odl block"; detection_filter:track by_src, count 10, seconds 1, sid:1000001)

Nach dieser Regel wird ein Alarm generiert, wenn Snort mehr als 10 Pakete innerhalb einer Sekunde von einer beliebigen Quell-IP innerhalb des 10.0.0.0/8-Netzwerks erfasst, die für 192.168.1.100 (d. h. den Opfercomputer) bestimmt sind und beliebige Transport-Ports verwenden. Wenn dieser Alarm an den OpenDaylight Controller gesendet wird, kann er automatisch Flow-Rules an den lokalen Switch übertragen, der wiederum die Quellen blockiert, von denen der Angriff ausgehen soll. Man kann die Flow-Tabelle des vSwitch in Mininet überprüfen (mit dem eingebauten ovs-ofctl dump-flows Dienstprogramm), um die Flow-Regeln zu verifizieren:

Die obersten Einträge sollten nun besagen, dass ICMP-Pakete von den bösartigen Hosts automatisch vom Switch verworfen werden. Das Diagramm für Pakete im Zeitverlauf sieht nun wie folgt aus:

Gemäss dem Szenario startet Host 1 den Angriff nach 59 Sekunden und erreicht einen Spitzenwert von etwa 3700 Paketen pro Sekunde. Als nächstes startet Host 2 den Angriff und simuliert den Anriff. Der Angriff wurde nach 68 Sekunden nahezu entschärft. Von da an stabilisiert sich das Netz auf seinen normalen Betriebsstatus. Diese Daten können aus dem Wireshark-I/O-Diagramm entnommen werden. Wenn der Opfercomputer kontinuierlich von Host 3 aus angepingt wird, kann man auch Rückschlüsse auf die Leistung des Netzes in Bezug auf RTT und Paketverlust ziehen:

Diese Lösung benötigt im Durchschnitt etwa fünf Sekunden, um den Angriff zu erkennen und abzuwehren. Die Leistung des Netzes, zumindest aus der Sicht von Host 3, wurde nicht beeinträchtigt.

Szenario 2

Im zweiten Szenario wird der DoS-Angriff nun mit einer gefälschten IP-Adresse durchgeführt. Dazu wurde ebenfalls das Dienstprogramm hping3 im ICMP-Modus verwendet, wobei immer noch so schnell wie möglich Pakete geflutet wurden, aber diesmal mit einer gefälschten IP-Adresse (d. h. 10.0.0.100). Ohne irgendetwas an den Konfigurationen von Szenario 1 zu ändern, zeigt eine schnelle Überprüfung der Flow-Rules:

Genau die gleiche Konfiguration funktioniert auch für dieses Szenario! Die Leistungsergebnisse dieses Mal:

Schlussfolgerungen

In diesem Artikel haben wir eine kurze Einführung in das Software-Defined Networking (SDN) und seine Sicherheitsherausforderungen gegeben und schliesslich ein Sicherheitssystem für eine SDN-Umgebung vorgestellt, welches auf einem IDS basiert, um den “normalen Betrieb” während eines DDoS-Angriffs sicherzustellen. Dieser Ansatz mildert die negativen Folgen der weitreichenden Auswirkungen auf potenzielle Opfer. Das System war in der Lage, beide Arten von DDoS-Angriffen, den Angriff ausgehend von H1 und H2 sowie den Angriff ausgehend von einer gefälschten IP-Adresse in 4,4s bzw. 4,6s zu erkennen und zu entschärfen und dabei eine normale Round Trip Time und keinen Paketverlust zu gewährleisten:

Trotz des vereinfachten Set-ups konnte ein Potenzial demonstriert werden, wie DDoS-Angriffe in einer SDN-Umgebung effizient automatisiert erkannt und abgeschwächt werden können.

Dieser Artikel wurde als gemeinsames Projekt der Hochschule Luzern und der scip AG verfasst.

Über die Autoren

Tom Looser ist ausgebildeter Informatiker und Cyber-Security-Enthusiast. Er studiert zum Zeitpunkt der Veröffentlichung dieses Artikels den Bachelor in Information & Cyber Security an der Hochschule Luzern.

Tomaso Vasella hat seinen Master in Organic Chemistry an der ETH Zürich abgeschlossen und ist seit 1999 im Bereich Cybersecurity aktiv. Positionen als Berater, Engineer, Auditor und Business Developer zählen zu seinen Erfahrungen. (ORCID 0000-0002-0216-1268)

Rocco Gagliardi ist seit den 1980er Jahren im Bereich der Informationstechnologie tätig. In den 1990er Jahren hat er sich ganz der Informationssicherheit verschrieben. Die Schwerpunkte seiner Arbeit liegen im Bereich Security Frameworks, Routing, Firewalling und Log Management.

Hanno Wiese ist Dozent in Teilzeit der Information & Cyber Security an der Hochschule Luzern und Geschäftsführer der InfraStrat GmbH mit Fokus auf Anlagen-Cybersicherheit. Hanno hat einen Hintergrund im Bauingenieurwesen und der Systemintegration kritischer Infrastrukturen.

Links

• https://www.hslu.ch
• https://www.opendaylight.org/
• https://www.scip.ch
• https://www.snort.org/
• https://www.snort.org/downloads#rules