Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
de:security [2016/05/03 14:16]
127.0.0.1 external edit
de:security [2019/09/23 17:48] (current)
Thomas Lukaseder [Zero Trust Network Management]
Line 1: Line 1:
-====== Sicherheitskonzepte für Hochleistungsnetze ​======+====== Sicherheitskonzepte für Hochleistungsnetzwerke ​======
  
-Gleiche ​Sicherheit bei deutlich ​höherer Geschwindigkeit ​zu erreichen ist eines der Kernziele ​des ProjektesDas Institut für Verteilte Systeme fokussiert ​sich dabei besonders darauf, wie Intrusion Detection Systeme ​auf die neuen Anforderungen angepasst werden können. Sicherheit in und durch flexible ​Netze – realisiert durch Software Defined Networking (SDN) – ist ein weiterer ​zentraler Forschungsbereich ​bei dem sich das Institut ​für Verteilte Systeme einbringt+Die gleiche ​Sicherheit bei einem deutlich ​höheren Durchsatz ​zu erreichenist eines der Kernziele ​dieses ProjektsDieses Arbeitspacket beschäftigt ​sich insbesondere damit, wie Systeme getestet werden können, wie Intrusion Detection Systeme ​an die neuen Anforderungen angepasst ​werden können und wie DDoS-Angriffe effizient abgewehrt ​werden können. Sicherheit in und durch flexible ​Netzwerke ​– realisiert durch Software Defined Networking (SDN) – ist ein weiteres zentrales Forschungsgebiet,​ an dem wir beteiligt sind. 
 + 
 +===== Netzwerktests ===== 
 + 
 +{{:​en:​gpntf.png?​nolink&​400 |}} 
 + 
 +Geräte, Dienste, Protokolle und andere Netzwerkmechanismen müssen evaluiert werden, bevor sie in der Produktion eingesetzt werden können. Eine sehr gute Testinfrastruktur für ein neues Netzwerksystem ist das Produktionsnetzwerk,​ in dem es funktionieren muss. Allerdings haben Tests in einer solchen Infrastruktur ihre Nachteile. Zum einen ist es schwierig, Zugang zu diesen Systemen zu erhalten, da die üblichen Datenschutzbestimmungen und -richtlinien verständlicherweise den Einsatz von unerprobten und ungetesteten Geräten im Produktionsnetzwerk untersagen. Darüber hinaus kann die Infrastruktur nicht kontrolliert werden, was zu einem Mangel an Wiederholbarkeit und Zuverlässigkeit der Netzwerktests führt. Um dieses Problem zu umgehen, ist es üblich, Netzwerkaufzeichnungen zu erfassen, zu anonymisieren,​ wiederzuverwenden und – zumindest als Best Practice – diese Datensätze zusammen mit den Ergebnissen der Analyse zu veröffentlichen. Da es sich um Aufnahmen von echten Netzwerkverkehr handelt, ist sichergestellt,​ dass sie Merkmale des Netzwerkverkehrs genau wiedergeben,​ an die selbst die Tester vielleicht nicht gedacht haben. Die inhärente Einschränkung dieses Ansatzes besteht darin, dass diese Netzwerk-Traces nur die Eigenschaften von Netzwerken während ihrer Aufzeichnungszeit abbilden. Verkehrsmuster könnten möglicherweise nur innerhalb des zu beobachtenden Netzwerks vorhanden sein; vielleicht sogar nur zum Zeitpunkt der Aufzeichnung. Neuere Protokolle oder Änderungen im Benutzerverhalten führen zu einer schnellen Alterung dieser Netzwerk-Traces. Beispielsweise kann HTTP/2 oder das QUIC-Protokoll in älteren Datensätzen nicht gefunden werden. Da es schwierig ist, Zugang zu neueren Aufzeichnungen zu erhalten oder die Vergleichbarkeit mit älteren Tests zu gewährleisten,​ werden Systeme oft mit alten Datensätzen getestet, die keine aktuellen Netzwerkfunktionen repräsentieren,​ z.B. ist der DARPA Intrusion Detection Evaluation Datensatz von 1999 noch heute im Einsatz. Ein weiterer ​wichtiger Punkt bei Tests ist es, nicht nur in einer realistischen Umgebung zu testen, sondern auch Edge-Cases zu testen und das Netzwerksystem an seine Grenzen zu bringen. Dies ist in einem Produktionsnetzwerk oder bei Verkehrsaufzeichnungen nicht einfach möglich. Daher sind spezialisierte Systeme für Netzwerktests,​ die sowohl eine realistische als auch kontrollierbare Umgebung schaffen können, wichtig, um die Lebensfähigkeit neuer Netzwerksysteme nachzuweisen. Diese Systeme sollen nicht nur bestehende Verkehrsspuren wiederverwenden können, sondern auch neue Daten produzieren können. Im Rahmen dieses Projektes arbeiten wir daher daran, ein Framework für Netzwerktests zu erstellen (Prototyp siehe Bild) und selbst aufgezeichnete Netzwerkdaten zu veröffentlichen. 
 + 
 +===== Hardware-basierte IDS-Beschleunigung ===== 
 +Intrusion Detection Systems (IDS) sind für die Sicherheit in Netzwerken wichtig, um Angriffe zu erkennen. Die jüngsten Angriffe zeigen, wie Legacy-Systeme in Netzwerken eine Belastung darstellen können und wie Intrusion Detection dazu beitragen kann, das Ausmaß von Angriffen durch frühzeitige Erkennung zu mindern. Die Netzwerkbandbreite nimmt jedoch schnell zu; sie steigt viel schneller als die Rechenleistung von Hardwareplattformen. Gleichzeitig werden die Erkennungsmechanismen immer komplexer. Vom einfachen String-Matching über das komplexere Matching mit regulären Ausdrücken bis hin zur Metadatenanalyse und komplexen Machine Learning Algorithmen zur Erkennung von Anomalien ist die Intrusion Detection zunehmend ressourcenintensiver geworden. Der Kern eines modernen IDS ist die String Matching und die Regular Expression Matching Engine. Es ist der wichtigste und ressourcenintensivste Teil des Systems und bietet somit die größte Verbesserungsmöglichkeit. CPUs bieten eine mittlere Leistung für jede generische Berechnung. Spezialisierte Verarbeiter können jedoch auf den Anwendungsfall ihres Einsatzbereichs zugeschnitten und entsprechend optimiert werden. Ein hochgradig parallelisiertes Design eines anwendungsfall-spezifischen Prozessors kann daher theoretisch die Performance von IDS verbessern. In diesem Projekt analysieren wir drei grundlegende Konzepte für solche Prozessoren. Zum einen ein FPGA-basiertes System, ​bei dem die regulären Ausdrücke selbst übersetzt und in Hardware gegossen werden, und einen FPGA-basierten Co-Prozessor mit einer eigenen, auf regulären Ausdrücken basierenden Assemblersprache,​ die in ein ASIC übersetzt werden kann. Darüber hinaus befassen wir uns mit Grafikprozessoren (GPUs). GPUs sind für eine massive Parallelisierung optimiert. GPU-Kerne sind viel kleiner und weniger vielseitig als CPU-Kerne, aber für bestimmte Anwendungen,​ die die Hauptmerkmale der Grafikverarbeitung teilen, ermöglicht die Verschiebung der Berechnung von der CPU auf die GPU oft weitreichende Verbesserungen. 
 + 
 +===== DDoS-Abwehr ===== 
 +==== Konzept der DDoS-Abwehr ==== 
 + 
 + 
 +{{:​en:​environment.png?​nolink&​400 |}} 
 + 
 +Das System, das wir untersuchen,​ ist ein netzwerkbasiertes DDoS Abwehrsystem,​ das innerhalb der Netzwerkinfrastruktur eingerichtet wird. Potenzielle Ziele in der Netzwerkinfrastruktur sind den Verteidigern bekannt, stehen aber weder in Kontakt mit diesen noch werden sie von den Administratoren des DDoS-Abwehrsystems kontrolliert. Die Abbildung zeigt eine vereinfachte,​ schematische Darstellung der Umgebung, in der das Abwehrsystem eingerichtet ist. In rot ist das Abwehrsystem selbst dargestellt,​ während die grauen Teile die Teile der Netzwerkinfrastruktur darstellen, die direkt mit dem Abwehrsystem verbunden sind. Auf der linken Seite wird die Datenaggregation basierend auf Informationen der Kernrouter des Netzwerks dargestellt. Das Baden-Württemberg Extended Lan (BelWü) enthält unter anderem mehrere Core Router, die mit anderen ISPs (z.B. dem Schweizer Forschungsnetzwerk SWITCH) und Internet Exchange Points (IXPs, z.B. DE-CIX in Frankfurt) als Peering-Partner verbunden sind. Wir arbeiten hier mit dem Projekt [[https://​www.alwr-bw.de/​kooperationen/​bwnetflow/​|bwNetFlow]] zusammen, das ein weiteres vom Land Baden-Württemberg finanziertes Forschungsprojekt ist und sich auf die Realisierung einer Schnittstelle zwischen den Core-Routern konzentriert,​ um Strömungsinformationen zu sammeln, eine automatisierte Verarbeitungsplattform aufzubauen und Anomalien zu erkennen. Das Projekt exportiert die NetFlow-Daten der Core-Router,​ aggregiert die Daten, reichert die Daten mit zusätzlichen Informationen an und stellt die Daten den Teilnehmern zur Verfügung. Auf der rechten Seite ist das Abwehrsystem in der Nähe der Server, die wir verteidigen wollen – das Angriffsziel T – dargestellt. SDN-fähige Switches vor den Zielen bieten die notwendige Flexibilität,​ um eine effektive Abwehr zu realisieren. Ein SDN-Controller steuert den Switch und kann den Angriffsverkehr zur Analyse an den Observer weiterleiten oder den als Angriffsverkehr identifizierten Verkehr droppen. Ein CAPTCHA-Server kann verwendet werden, um legitime Clients während eines Angriffs auf die Whitelist zu setzen. 
 + 
 +==== Prototyp ==== 
 +{{:​en:​ddos-sketch.png?​nolink&​400 |}} 
 + 
 +Zu Testzwecken wurde ein lokaler Testaufbau implementiert,​ wie in der linken Abbildung dargestellt. Das System besteht aus dem lokalen Aufbau des Abwehrsystems ohne den NetFlow-Datenexport,​ der separat ausgewertet wird. Zusätzlich beinhaltet das System einen Webserver, der als Angriffsziel in Testläufen fungiert, eine Maschine, die Angriffe simuliert und eine Maschine, die reguläre Clients simuliert. 
 + 
 +===== Zero Trust Network Management ===== 
 + 
 +{{:​de:​architecture.png?​nolink&​400 |}} 
 + 
 +Im Rahmen der Verlängerung des Projekts (bwNET100G+ Extension) wird an einer Platform ​für das Management von Zero Trust Netzwerken gearbeitet. Das derzeit vorherrschende Perimeter-Sicherheitsmodell versagt immer häufiger dabei einen ausreichenden Schutz vor Angreifern zu bieten. In diesem Beitrag wird analysiert, inwieweit das in einigen kommerziellen Netzwerken beliebte Zero Trust Modell auch auf das offene und heterogene Forschungsnetzwerk einer deutschen Universität bzw. auf BelWü angewendet werden kann. Das hier vorgestellte Konzept zur Implementierung eines identitätsbasierten Netzwerkmodells konzentriert sich insbesondere auf die Komponenten,​ die für die Authentifizierung und Autorisierung notwendig sind. Die Machbarkeit des Modells wird durch einen selbst implementierten Prototyp demonstriert,​ der die Zugangskontrolle von Services durchführt.
de/security.1462277785.txt.gz · Last modified: 2016/05/03 14:16 by 127.0.0.1