Security-Schwachstellen bei Software-defined Networking (SDN)

Software-defined Networking erfreut sich derzeit großer Aufmerksamkeit. Die Netzwerksicherheit wird dabei oftmals zu selten ins Visier genommen.

Dieser Artikel behandelt

Netzwerk-Sicherheitsanalyse

Durch den inzwischen hinlänglich bekannt gewordenen Hang der National Security Agency (NSA), Hintertüren in bestimmte...

IT-Infrastruktur einzubauen, sieht Software-defined Networking (SDN) wie ein gefundenes Fressen für Spione und Cyberkriminelle aus.

Tatsächlich sollte die Branche einige Security-Probleme mit Software-defined Networking adressieren, um Netzwerk-Administratoren von der Integrität des grundlegenden SDN-Stacks zu überzeugen. Erst dann wird es möglich sein, die Technologie großflächig zu etablieren.

Nick Buraglio ist Networking-Profi und hat beruflich mit einem globalen Netzwerk zu tun hat. Er sagt: „Das NSA-Ding hat mir zu denken gegeben. Was bedeutet es, wenn die Forwarding- und Daten-Schicht zwei komplett unterschiedliche Geräte sind und die Kontroll-Ebene lediglich aus einer oder zwei Linux-Boxen besteht? Was passiert, wenn jemand diese Box kompromittiert? Die können Ihren Datenfluss dann wie sie wollen steuern.“

Open Networking Foundation identifiziert zwei grundlegende Security-Probleme mit SDN

Die SDN-Community ist sich des Problems sehr wohl bewusst. Die Open Networking Foundation (ONF) verwaltet das Protokoll OpenFlow und hat im Oktober2013  ein Whitepaper veröffentlicht, das sich mit zwei potenziellen Security-Problemen in Hinblick auf SDN befasst. Es handelt sich dabei um mögliche Angriffs-Vektoren, um die sich die Branche dringend kümmern muss:

  • Der mit SDN zentralisierte Controller ist demnach ein „potenzieller SpoF (Single Point of Failure) in Bezug auf Angriffe und Ausfälle.“
  • Das Southbound-Interface, wie zum Beispiel eben OpenFlow, zwischen Controller und den Data-Forwarding-Geräten sei „anfällig hinsichtlich Bedrohungen, die sich negativ auf Verfügbarkeit, Performance und Integrität des Netzwerks auswirken können“.

Matthew Palmer ist Mitgründer von SDNCentral.com und Partner bei der Consulting-Firma für SDN-Anbieter und Cloud-Service-Provider Wiretap Ventures. Seiner Aussage nach wären Sicherheitsbedenken auf Kundenseite das größte Hemmnis für die Implementation von Software-defined Networking.

Der zentralisierte SDN-Controller wird zum bevorzugten Angriffsziel

Der SDN-Controller ist das primäre Angriffsziel für Cyberkriminelle. Zum einen ist er der zentrale Knoten für den Datenfluss und zum anderen ein einzelner Ausfallpunkt.

„Passt jemand nicht auf den Controller auf, wird dieser zu einem sehr profitablen Ziel für einen Angreifer. Er könnte diesen relativ einfach kompromittieren, die Code-Basis modifizieren und die Kontrolle des Traffics übernehmen. In diesem Fall kann der böswillige Hacker Daten extrahieren oder an einer Stelle speichern, an der sich diese weiter analysieren lassen.“, so Dave Shackleford. Er ist Security-Consultant bei Voodoo Security und ein führendes Mitglied bei IANS.

„Ein Angreifer hat viele Möglichkeiten, das komplette Fundament des Netzwerkverhaltens zu verändern, und muss dafür lediglich den Controller modifizieren. In so einer Lage befanden wir uns noch niemals zuvor. Selbst herkömmliche Tools zum Netzwerkmanagement stellen nicht die Flexibilität zur Verfügung, das Verhalten eines Netzwerks auf einer Node-zu-Node-Basis zu verändern.“

Die Fähigkeit, SDN-Controller programmieren zu können, ist ein zweischneidiges Schwert. Administratoren können zwar Security-Applikationen am Northbound-Interface des Controllers implementieren, um damit neue Möglichkeiten zu schaffen, das Netzwerk mit Security-Policies zu versorgen. Diese Applikationen weisen den Controller dann an, die unter seiner Kontrolle befindlichen Switche und Router als Durchleitungspunkte zu verwenden.

Allerdings ist das programmierbare Northbound-Interface selbst eine potenzielle Schwachstelle. Diese Applikationen können das Netzwerk via Controller umprogrammieren. Genauso können böswillige Hacker Administratoren austricksen, damit diese kompromittierte Applikationen installieren. Mit genug Fachwissen über die gutartigen Applikationen, die auf dem Controller laufen, könnte ein Cyberkrimineller das Netzwerk etwas komplett Unerwartetes tun lassen. Dazu müsste er möglicherweise nur einen speziell modifizierten Paket-Stream an den Netzwerk-Manager senden.

„OpenFlow-Applikationen haben die Fähigkeit, sich gegenseitig zu widersprechen.“, erklärt Phil Porras. Er ist Programmleiter des gemeinnützigen Forschungs- und Innovations-Zentrums SRI International. „Sie haben die Möglichkeit, Regeln anzuwenden, und wenn diese kombiniert werden gibt es einige interessante Interaktionen, die keiner erwartet hätte oder haben möchte.“, fügt er hinzu.

SDN-Controllern fehlt in der Regel die Intelligenz, Security-Applikationen im Gegensatz zu anderen Anwendungen immer zu priorisieren. Selbst eine recht harmlose Applikation kann die Security-Policies aushebeln, wenn der Controller nicht versteht, wie er die Anfragen der Anwendungen behandeln soll, die sich gegenseitig widersprechen.

„Stellen Sie sich vor, dass eine OpenFlow-Security-Applikation eine interne Maschine als infiziert einstuft.“, so Porras weiter. „Die Security-Applikation steckt die Maschine in Quarantäne und verhindert, dass diese mit dem Netzwerk kommunizieren kann. Gleichzeitig entscheidet eine Load-Balancing-Applikation, dass diese Maschine derzeit im Netzwerk am wenigsten ausgelastet ist. Nun fängt die Load-Balancing-Applikation an, Datenverkehr auf die sich in Quarantäne befindliche Maschine umzuleiten.“

SE-Floodlight: Ein Modell für einen intelligenteren und sichereren Controller

„Wir arbeiten derzeit daran, SDN-Applikationen einschränken zu können. Somit soll sichergestellt sein, dass bestimmte Policies immer durchgesetzt werden.“, so Porras. „Diese OpenFlow-Apps müssen nicht zwingend bösartig sein. Möglicherweise sind sie nur einfach nicht im Bilde darüber, wie der aktuelle Stand der Security-Policies ist.“, fügt Porras an.

Porras hat SE-Floodlight entwickelt. Es handelt sich hier um eine modifizierte Version des unter einer Open-Source-Lizenz stehenden Controllers Floodlight. Damit soll die Integrität von Security-Applikationen sichergestellt sein.

„SE-Floodlight bringt den Gedanken mit ein, dass sich OpenFlow-Applikationen mit hierarchischen Rollen betreiben lassen. Diese Rollen werden wiederum mithilfe digitaler Authentifizierung zugewiesen.“, erklärt Porras.

Bei SE-Floodlight können Netzwerkadministratoren den Security-Applikationen eine höhere Priorität zuweisen als anderen Anwendungen. Sollte nun also eine Load-Balancing-Applikation eine so genannte Flow-Regel an den Controller schicken, die mit der Policy einer Security-Applikation in die Quere kommt, kann der Controller diese Regel abweisen. Er ist sogar in der Lage, der Load-Balancing-Applikation ein Feedback zu schicken. Diese ist dann darüber in Kenntnis gesetzt und muss andere Wege finden, um den Traffic zu  verteilen.

„Ich sehe unsere Arbeit in Bezug auf SE-Floodlight als Voraussetzung dafür, OpenFlow jemals zum Beispiel in Netzwerken von Finanz-Services, Gesundheitswesen oder öffentlicher Behörden einzusetzen. Wir brauchen ein starkes Security-Modell, um Netzwerke durch die Einführung von SDN nicht zu schwächen.“, so Porras. „Sowohl SDN-Anbieter als auch Standardisierungs-Gremien werden die Security-Architekturen von SDN noch sehr genau unter die Lupe nehmen. Ich habe bereits mit einigen Herstellern über dieses Themas gesprochen.“

Eher unwahrscheinlich: Ein Angriff auf das Southbound-Interface

Die ONF hat auch die so genannte Southbound-Kommunikation zwischen Controller und Daten-Forwarding-Geräte als Schwachstelle identifiziert. Southbound-Interface-Protokolle wie OpenFlow bringen grundsätzlich eine Authentifizierungstechnologie mit sich. Somit sollen böswillige Hacker davon abgehalten werden, gefälschte Flow-Befehle von einem Controller zu einem Switch zu schicken. Allerdings sollten sich Netzwerkadministratoren beim jeweiligen SDN-Anbieter versichern, dass die Authentifizierungs-Zertifikate zwischen Controller und SDN-Switchen auch ordnungsgemäß implementiert sind, empfiehlt Palmer.

Aller Wahrscheinlichkeit nach werden Cyberkriminelle das Southbound-Interface allerdings weniger häufig ins Visier nehmen, weil es einfachere Möglichkeiten für eine Störung gibt. Böswillige Hacker haben es wohl eher auf Controller, Switche oder virtuelle Switche abgesehen, um diese mit DoS-Angriffen (Denial-of-Service) zu stören.

„Irgendjemand könnte die Kontroll-Ebene beschäftigen oder die Schnittstelle zwischen Kontroll- und Daten-Ebene ausgelastet halten.“, erklärt Porras. „Damit würde sich das komplette Netzwerk verlangsamen. Wir sehen auch andere Angriffsmuster, bei denen der Angreifer nicht versucht, das Netzwerk komplett in die Knie zu zwingen. Allerdings würden die Cyberkriminellen Paket-Folgen so modifizieren, dass die Interaktionen zwischen Daten- und Kontroll-Ebene verstopfen.“

So stellen Sie auch bei Software-defined Networking die Netzwerk-Security sicher

Netzwerkadministratoren sollten sich wegen der Sicherheitsbedenken nicht gleich von SDN abwenden. In jeder Umgebung gibt es eine andere Risiko-Toleranz. Bei den meisten SDN-Einsatzgebieten in der heutigen Zeit handelt es sich um Pilot-Projekte oder um Machbarkeits-Studien. Netzwerktechniker können aber natürlich auch eigene Schritte einleiten, wenn sie mit Blick auf ihr Projekt Sicherheitsbedenken bezüglich des SDN-Stacks haben.

„Sichern Sie den Controller so gut wie möglich ab.“, empfiehlt Buraglio. „Lassen Sie nichts rein oder raus, das nicht unbedingt rein oder raus muss. Halten Sie den Controller immer auf dem aktuellen Stand. Legen Sie eine Basis fest. Behalten Sie die Aufzeichnung in Bezug auf CPU-Niveau, Arbeitsspeicher-Auslastung und Interface-Statistiken. Sammeln Sie all diese Daten und anhand dieser Daten setzen Sie Schwellenwerte und Benachrichtigungen.“

Netzwerkadministratoren sollten den SDN-Controllern dasselbe Sicherheitsniveau spendieren, das sie auch für sensible Daten an den Tag legen.

„Sie müssen sich mit Themen wie Integritäts-Monitoring, Logging und Multi-Faktor-Authentifizierung für Zugriffe beschäftigen.“, meint Shackleford. „Sie müssen sicherstellen, dass diese Bereiche abgestufte und schichtweise Zugriffe vorhalten.“, erklärt er weiter.

Der großflächige Einsatz von SDN wird so lange nicht erfolgen, bis Sicherheit und Integrität dieser Technologie als Gut befunden wird, meint Palmer. Gerade Hersteller und Anbieter von Controllern müssen dies ihren potenziellen Kunden unter Beweis stellen.

„Es ist kein Security-Problem.“, ist sich Palmer sicher. „Es ist ein Compliance-Problem. Solange man das für die Unternehmens-Compliance zuständige Team nicht überzeugen kann, dass Software-defined Networking so sicher wie etablierte Netzwerke ist, werden Sie kein grünes Licht für einen Einsatz geben.“

Palmer geht davon aus, dass die ersten Anbieter im Jahre 2015 nach und nach anfangen werden, die Sicherheit des SDN-Stacks unter Beweis zu stellen. „2014 ist das Jahr der Machbarkeits-Studien. Menschen probieren nun mal  erst aus. Ich glaube, dass die kritischen Security-Funktionen immer stärker ins Rampenlicht wandern werden. Es wird allerdings noch 12 bis 18 Monate dauern, bis diese Security-Funktionen in die Controller und alle anderen SDN-Produkte einfließen werden.“

Folgen Sie SearchNetworking.de auch auf Facebook, Twitter und Google+!

Artikel wurde zuletzt im Juli 2014 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Netzwerk-Sicherheitsanalyse

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchDataCenter.de

SearchEnterpriseSoftware.de

Close