Warum es nicht egal ist, was über ein Netzwerk fließt Kein Troubleshooting ohne detailliertes Payload-Wissen

Anbieter zum Thema

sysob IT-Distribution GmbH & Co. KG

Arvato Systems

SEPPmail - Deutschland GmbH

SolarWinds EMEA Headquarters

Im Laufe der letzten Jahre wurden verschiedenste Anstrengungen unternommen, um dem Netzwerk mitzuteilen, was es eigentlich transportiert. Denn die Fähigkeit, zu verstehen, welche Daten genau durch das Netzwerk wandern, ist von enormer Wichtigkeit für ein Unternehmen. Doch warum eigentlich?

Tatsächlich bezeichnen sich viele Organisationen als „von Anwendungen angetrieben“ (Application driven Business), aber keine Einzige empfindet sich als „vom Netzwerk angetrieben“. Das ist natürlich nicht sehr weit gedacht, da ohne das Netzwerk keine Anwendung funktioniert, und daher auch kein Unternehmen.

Sobald es irgendwo zu einem Ausfall kommt, oder es auch nur etwas langsamer zugeht als üblich, verdächtigt der durchschnittliche Benutzer sofort das Netzwerk. Der Netzwerk-Admin weiß natürlich, dass es nicht an diesem liegt, und nutzt alle Werkzeuge, um schnell Tests für Verbindungen, Paketverluste und Antwortzeiten durchzuführen. Aber ohne ein Verständnis darüber, was genau transportiert wird, wird das Troubleshooting zu einer zeitraubenden Aufgabe.

Die wirklichen Vorteile: Anpassen an Veränderungen und Optimierung

Nach wie vor sind die meisten Anwendungen auf drei Stufen aufgeteilt (Frontend, Backend, Datenbank), mittlerweile aber deutlich verteilter als in der Vergangenheit. Das ist eine Nebenwirkung von „agilen“, hochverfügbaren und digitalisierten Unternehmen. Verteilte Anwendungen basieren auf vielen Micro Services, und noch mehr Variablen im Produktivbetrieb.

Die Anwendungsverwalter müssen eng mit dem Netzwerkadmin zusammenarbeiten, um den Datenfluss der Anwendungen zu gestalten und sicherzustellen, dass alles so funktioniert wie gedacht. Leider ist das keine einmalige Aufgabe, wie es früher einmal der Fall war, sondern ein permanenter Prozess. Und genau dieser erfordert ein Verständnis über die Art von Daten, die befördert werden. Ohne dieses hat der Netzwerkadmin kaum eine Chance, den Datenfluss zu optimieren.

Systeme zur Überwachung und Verwaltung der IT können die so gewonnenen Informationen über verschiedene Ebenen hinaus zusammenbringen und ein Bild von wirklich wichtigen Geschäftsprozessen zeichnen, anstatt nur dutzende von bedeutungslosen Metriken aufzuführen. Im Beispiel eines Unternehmens, das Urlaubsreisen anbietet, wäre vielleicht die Metrik „Buchungen pro Minute“ von Bedeutung, nicht aber die CPU-Zyklen des Core Switches.

Auch für die vielgesuchte Automation im Netzwerk sind Informationen über die Anwendungen sehr von Nutzen. Wenn die Inhalte der Pakete verstanden werden, können darauf automatische Prozesse wie das Verändern von Routen oder das Anpassen von QoS Richtlinien erstellt werden. Vielleicht sogar das Verändern von Routen ausgehend von veränderten QoS Richtlinien – Vollautomation!

Vorteile für die Sicherheit

Von großer Wichtigkeit ist das Thema auch für die Security. Den gesamten Datenverkehr zu einem Data Loss Prevention System zu leiten, ist zwar einfach eingerichtet, wird aber ebenso einfach sämtliche Kommunikation verlangsamen. Wäre es nicht zielführender, wenn automatisch nur die FTP Pakete zum DLP weitergeleitet werden? SDN und SDWAN wären ohne Anwendungsinformationen unmöglich.

Aber woher kommen diese Informationen? Wenn man sich die beiden großen SDN Ökosysteme anschaut, sieht man, dass diese eine Mischung aus traditionellen Technologien wie Deep Packet Inspection und einem eher manuellen Ansatz nutzen. Glücklicherweise ist in diesem Fall der manuelle Ansatz tatsächlich eine einmalige Aufgabe.

Anwendungsprofile werden auf VM-Level erstellt und dann Interface-Richtlinien oder Portprofilen zugewiesen. In SDN ist ohnehin jeder Transport eingekapselt, um verschiedenste Informationen zusätzlich zur Payload zu tragen, und in diesem Fall werden die Anwendungsinformationen zu allen Netzwerkgeräten weitergetragen. Unabhängig davon, ob sie physisch oder virtuell sind. Das funktioniert ähnlich wie ein klassisches VLAN, und sobald die Profile zugewiesen sind, weiß das Netzwerk sehr gut, was damit zu tun ist.

In ACI existiert ein Konzept namens „contracts“ (Verträge), um Informationen auszutauschen. In NSX wird das komplett durch den Controller verwaltet, der bequemerweise eng mit dem vCenter zusammenarbeitet. Dort gibt es eine große Bibliothek mit „Application ID GUIs“, die auch weiteren Bereichen innerhalb des VMware-Systems zur Verfügung stehen, wie z.B. Load Balancern, Web Application Firewalls, und natürlich deren eigener SD-WAN Segmentierung.

So zumindest die perfekte Welt, in der jeder Zugriff auf die neueste Technologie hat und Budgets keine Grenzen kennen. Wie so oft sieht die Realität aber ein wenig anders aus, und die meisten Unternehmen müssen mit dem zurechtkommen, was bereits verfügbar ist.

Paketschnüffler sind überall

DPI identifiziert Anwendungen nach ihrer Payload und nutzt Signaturen für bekannte Applikationen, aber erlaubt auch das Einpflegen von benutzerdefinierten Signaturen. Die Technologie kommt in verschiedenen Geschmacksrichtungen und ist selbst für Unternehmen mit nicht allzu tiefen Taschen erschwinglich.

Wenngleich DPI aus dem Bereich Security kommt, wo Lösungen eher hochpreisig sind, existieren viele kostenlose Varianten. Tatsächlich ist das sehr populäre SNORT als Open Source verfügbar. Grundsätzlich kann jede Linux Box umfunktioniert werden, um Pakete zu sammeln und zu verarbeiten, und seit einer Weile klappt das dank Anwendungen wie nDPI, welche kostenlos unter LGPL Lizenz zur Verfügung steht, sogar mit Windows-Maschinen.

Auf der anderen Seite des Regenbogens finden sich selbstverständlich professionellere Varianten, die nicht ganz so günstig sind. Das sind Geräte, die problemlos mit großen Datenmengen zurechtkommen und schlüsselfertige Resultate statt Rohdaten liefern.

Im täglichen Umgang findet man DPI bereits in vielen Netzwerkgeräten aller Preisbereiche sowie in NFV-„Geräten“. Ebenso gibt es Anwendungen zum Überwachen und Verwalten des Netzwerkverkehrs – Grafik 1 zeigt ein Beispiel für DPI in einer solchen Anwendung.

Auf der rechten Seite ist der klassische 3-waz-Handshake einer TCP Verbindung zu sehen, links die Zeit, die eine beliebige Anwendung braucht, um angeforderte Daten zurückzuliefern. Der Unterschied zwischen den beiden Metriken deutet an, ob man es mit einem Netzwerk- oder Anwendungsproblem zu tun hat.

Der größte Vorteil von DPI ist die Unabhängigkeit von traditionellen Protokollen oder Ports. Dinge wie BT, welches dynamische Ports nutzt, werden genauso einfach identifiziert wie Port-0-Verkehr, wenn es keine verwertbare L4-Header-Informationen gibt. Seit einer Weile ist es sogar möglich, verschlüsselten Verkehr zu untersuchen. Manche Geräte spiegeln hierzu vor, der Endpunkt zu sein, um die Verbindung terminieren zu können, andere wiederum nutzen signierte Zertifikate, um die Kommunikation aufzubrechen. Aber das sind Technologien, die Regierungen nutzen, und damit eine ganz andere Geschichte.

Der größte Nachteil andererseits ist, dass DPI nur eine Technologie und kein vereinheitlichtes Protokoll ist. Das bedeutet, dass unter Umständen bereits dutzende von Paketsniffern in einer Organisation in Betrieb sind, diese aber unterschiedliche Sprachen sprechen und es keine Möglichkeit zum Vergleich oder Austausch der Daten gibt.

Also hat man mit DPI zwar die Option, dem Netzwerk Anwendungen nahe zu bringen, aber die Reichweite ist oft begrenzt, nennen wir es situationsbezogen. Oder aber, man befindet sich schnell in einem unerschwinglichen Preisbereich, wenn man sich bspw. ein verteiltes Hardware-System anschaut, welches Satelliten im ganzen Netzwerk oder gar an verschiedenen Standorten betreibt.

Keine Chance? Keine Sorge! Es gibt ja noch Netflow

Als Cisco Netflow entwickelt hat, hat das Protokoll die folgenden Metriken gesammelt und Statistiken zu einem Collector zur Weiterverarbeitung gesendet:

• Quell- und Zieladresse

• Quell- und Zielport

• Protokoll (UDP, TCP etc.)

• Informationen über die Richtung und die Schnittstelle (Tx und Rx)

Da Netflow nur als proprietäres Protokoll am Markt verfügbar war, haben andere Hersteller von Netzwerkhardware ihre eigenen Versionen von der im Grunde genommen gleichen Technologie entwickelt, und all diese sind bis zum heutigen Tag noch in Betrieb, weil sie einfach zu verstehen und sehr bekannt sind.

Spätere Versionen wie 9 oder 10 erlauben das Sammeln von benutzerdefinierten Metriken bzw. Feldern, um spezifische Informationen zu sammeln, aber generell sind Flussprotokolle nicht raffiniert genug, um mit moderner Kommunikation mitzuhalten. Viele Anwendungen nutzen standardisierte Ports, wodurch sie nicht auseinanderzuhalten sind. TCP 443 ist immer Web-Verkehr, oder nicht? Keineswegs.

Manche Netflow- oder IPFIX-Sammler erlauben es, verschiedene Informationen in einen Topf zu werfen, um höhere Treffsicherheit beim Identifizieren von Anwendungen zu bieten – siehe Grafik 2.

Auch hat Netflow bei weitem noch nicht ausgedient. Es ist nach wie vor schnell eingesetzt und benötigt keine große Investition in Hard- oder Software. Gerade auf Samples basierende Varianten wie sFlow sind immer noch hervorragend für Umgebungen mit hohem Verkehrsaufkommen geeignet, wie z.B. einem Datenzentrum, und erlauben es Administratoren, einen Einblick in die Daten zu bekommen.

Fazit

Es gibt viele kreative Einsatzszenarien für Flussprotokolle. Vielleicht existiert eine bestimmte Verbindung zwischen zwei Servern, die Kapazität ist immer mit ungefähr 80% auf TCP 1433 ausgelastet und beim Überwachen sieht man einen konstanten Datenfluss. Plötzlich ist dieser spezielle Datenfluss auf nur noch 20% gefallen und eine Überwachungslösung kann auf die Veränderung des Verhaltens hin warnen.

Wenn man dann sicherstellen kann, dass im Transport alles funktioniert wie gewünscht und im grünen Bereich ist, das Routing unverändert arbeitet und es keine zusätzlichen Hops gibt, dann weiß der Netzwerkadmin, dass das Problem wirklich nicht im Netzwerk liegt. Und darauf kommt es schließlich an.

Über den Autor

Von Sascha Giese ist Head Geek bei SolarWinds.

(ID:46850129)