Oftmals ist die Schere zwischen einerseits der Kapazität des aufzeichnenden Analysesystems und derMenge an ankommenden Daten so groß, dass ohne entsprechende zusätzliche Mechanismen das Analysesystem höchst-wahrscheinlich nicht in der Lage ist, alle einzelnen Pakete verlustfrei aufzuzeichnen.

Dies ist je nach Einsatzweck eben jenes Analysesystems ein großes Problem, da speziell im Cyber-Security-Umfeld jedes Paket zählt und man andernfalls nicht sicherstellen kann, sämtliche Angriffe und deren Auswirkungen zu erkennen.

Durch nicht rechtzeitig erkannte oder sogar komplett unsichtbar gebliebene Angriffe können den Unternehmen so Schäden in gewaltiger Höhe entstehen, sogar bis hin zu Regressansprüchen von etwaigen Versicherern, wenn diese feststellen sollten, dass deren Klienten nicht ihrer Sorgfaltspflicht nachkamen.

Doch wie entsteht solch eine Situation? Ganz schnell kann es passieren, dass Netze in den Unternehmen wachsen, oftmals parallel mit der geschäftlichen Entwicklung dieses Unternehmens, während die oftmals bereits vorhandenen Analyse- und Monitoringsysteme, bei der Beschaffung mit Reserven eingeplant, immer öfter und häufiger an das Ende ihrer Reserven stoßen.
Höhere Bandbreiten, immer mehr Dienste und Schnittstellen, welche im LAN eingesetzt werden, reduzieren die Kapazitäten, bis zu dem Punkt, an welchem die Systeme nicht mehr mithalten können und Pakete verwerfen müssen.

Ab diesem Moment ist es theoretisch möglich, dass ein Angreifer sich unentdeckt im lokalen Netz aufhält, da das Analysesystem hoffnungslos überlastet ist. Der Administrator ist nicht mehr in der Lage, zu erkennen, welche Parteien in seinem Netz miteinander sprechen, welche Protokolle sie nutzen und mit welchen Endpunkten außerhalb des LANs kommuniziert wird.

Oftmals sind jedoch nicht Kapazitätsprobleme der Auslöser für das Aktivieren von Packet Slicing, sondern vielmehr datenschutzrechtliche Gründe. Je nachdem, wo und welche Daten wann abgegriffen werden, kann es für das Unternehmen verpflichtend sein, dass nur solche Daten aufgezeichnet und ausgewertet werden, welche keinerlei personenbezogene bzw. leistungsbezogene Informationen beinhalten.

Während typischerweise der Paketkopf nur Verbindungsdaten enthält (WANN, WER, WIE, WO), finden sich in den Nutzdaten, obwohl meist verschlüsselt, eben jene inhaltlichen Daten, welche es theoretisch ermöglichen, die Leistung der einzelnen Anwender zu bemessen. Je nach Einsatzort ist dies jedoch oft weder gewollt oder erlaubt. Es muss daher sichergestellt werden, dass es dem Administrator nicht möglich ist, persönliche Informationen aus den aufgezeichneten Daten zu rekonstruieren.

Und genau an diesem Punkt kommt das Feature „Packet Slicing“ ins Spiel: mit diesem Verfahren ist es möglich, die ankommende Datenlast an Ihrem Analysesystem um bis zu 87% zu reduzieren (bei 1518 Bytes Paketgröße undPacket Slicing bei 192 Bytes), indem von jedem Paket die Nutzdaten einfach entfernt werden.

Viele Analyse- und Monitoring-Ansätze benötigen für ihre Auswertungen und Analysen nur die Informationen, welche im Paketheader gespeichert sind, sprich die Metadaten, während die Nutzdaten oftmals keine wichtigen oder verwertbaren Informationen enthalten, da diese sowieso meistens verschlüsselt sind und somit nicht für die Auswertung verwendet werden können.
Durch eben jenes Entfernen der Nutzdaten ist eine massive Entlastung der verarbeitenden Instanz zu erwarten und dieses ermöglicht teilweise sogar noch eine größere Abdeckung des LANs durch das Monitoring- und Analysegerät.

Ein wichtiger Aspekt beim Packet Slicing ist die Wiederherstellung der FCS-Prüfsumme eines jeden geänderten Pakets. Da durch das Wegschneiden der Nutzdaten in die Struktur und Länge des Paketes eingegriffen wird, ist die ursprünglich berechnete Prüfsumme, welche vom Absender errechnet und in das FCS-Feld des Paketkopfes eingetragen wurde, nicht mehr korrekt.

Sobald ein solches Paket auf dem Analysesystem ankommt, werden jene Pakete verworfen oder als fehlerhaft deklariert, da die Prüfsumme im FCS-Feld immer noch auf der ursprünglichen Paketlänge basiert. Um dem entgegen zu wirken, ist es essentiell, dass die FCS-Prüfsumme für jedes Paket, von welchem die Nutzdaten entfernt wurden, neu berechnet und auch eingetragen wird, da dies sonst die Analysesysteme zwingen würde, diese Pakete als fehlerhaft und/oder manipuliert einzustufen.

Generell gibt es mehrere Möglichkeiten, an welchen Stellen in der vom Kunden eingesetzten Visibility-Plattform das oben genannte Packet Slicing aktiviert werden kann. Dies ist einerseits eine Entscheidung von Fall zu Fall, andererseits auch eine technische.

Davon ausgehend, dass der Anwender mehrere Messpunkte in seinem Netzwerk verteilt gesetzt hat, wird oftmals ein Network Packet Broker eingesetzt. Dieses Gerät ist eine weitere Aggregationsebene und wird typischerweise als letzte Instanz direkt vor dem Monitoring-System eingesetzt. Ein Network Packet Broker ist optisch sehr nah an einem Switch und ermöglicht es dem Anwender, die Daten von multiplen Messpunkten (Netzwerk-TAPs oder SPAN-Ports) zentral zusammen- zuführen und aggregiert in einem oder mehreren Datenströmen an das zentrale Analysesystem zu senden.

Somit können z.B. die Daten von 10 verteilten Messpunkten, welche in 1Gigabit-Leitungen gesetzt wurden, an ein Analysesystem mit einem einzelnen 10Gigabit-Port gesendet werden, indem der Network Packet Broker diese 1Gigabit-Signale aggregiert und als ein einziges 10Gigabit-Signal wieder ausgibt.

An diesem Punkt erfährt der Anwender jedoch von einem Haken an der ganzen Thematik: Oftmals sind die Analysesysteme, obwohl sie mit einem 10Gigabit-Anschluss ausgestattet sind, nicht in der Lage, auch Bandbreiten von 10Gigabit/Sekunde zu verarbeiten.

Dies kann verschiedenste Gründe haben, welche jedoch nicht Thema dieses Blogeintrags sein sollen. Allerdings ist die Ausgangslage prädestiniert für den Einsatz von Packet Slicing; während man im Regelfall seine Monitoring-Infrastruktur mit immensen Kosten erweitern müsste, kann man mit dem Einschalten von Packet Slicing die ankommende Datenflut massiv verringern und somit weiterhin seine bestehenden Systeme nutzen, einzig und allein eine entsprechende Instanz mit eben jenem Feature wird benötigt, welche im Einkauf in aller Regel nur einen Bruchteil dessen kostet, was für ein Upgrade der Analysesysteme zu veranschlagen wäre.

Eine weitere Möglichkeit bietet sich dem Anwender auf den Analysesystemen selbst. Je nach Hersteller, Aufbau und eingesetzten Komponenten ist es möglich, auf den Systemen selbst direkt die Nutzdaten zu entfernen und die Prüfsumme neu zu berechnen, bevor die Pakete an die entsprechenden Analysemodule intern weitergereicht werden.

In den allermeisten Fällen wird hierfür eine FPGA-basierte Netzwerkkarte benötigt, da sichergestellt werden muss, dass keine CPU-basierte Ressource für die Änderung eines jeden einzelnen Pakets verwendet wird. Nur mittels reiner Hardware-Kapazitäten kann der Anwender sicher sein, dass auch wirklich jedes Paket entsprechend bearbeitet wird, eine andere Herangehensweise könnte wieder zu den eingangs angesprochenen Fehlern und Problemen führen.

Ein weiterer nennenswerter Aspekt ist die Erfüllung von rechtlichen Anforderungen. Insbesondere im Zusammenhang mit der DSGVO kann es erforderlich sein, die Nutzdaten zu entfernen, da oftmals für eine Analyse die Metadaten zur Auswertung ausreichen.

Beispielsweise, wenn man VoIP analysieren möchte, dann kann mittels Packet Slicing sichergestellt werden, dass nicht autorisierte Personen das Gespräch nicht abhören können, aber man technisch dennoch die Sprachübertragung auswerten und auf Quality-of-Service-Merkmale hin begutachten kann. Somit kann man Performance-Werte auswerten, die Privatsphäre schützen und die gesetzlichen Anforderungen wie eben die DSGVO erfüllen.

Wir sehen also, dass es in der Tat verschiedene Möglichkeiten gibt, wie man die finale Last auf den Analyse- und Monitoring-Systemen verteilen oder sogar, wie in diesem Beispiel, verkleinern kann, ohne dass die wichtigsten Informationen zur Erstellung von Performance Charts, Top Talkers und mehr verloren gehen. Packet Slicing stellt somit eine valide Lösung für den Anwender dar, welche sich in fast allen Fällen problemlos realisieren lässt und verwertbare Ergebnisse erzielt.

Auf der SuriCon 2019 präsentierten Eric Leblond und Peter Manev – beide wichtige Mitarbeiter der Suricata-Community – wichtige Testergebnisse und betonten die Auswirkungen von Paketverlusten. Lassen Sie uns ein wenig tiefer in die Bedeutung von Zero Packetloss bei einer IDS-Bereitstellung einsteigen.

Die Auswirkungen von Paketverlusten auf einer Vielzahl von Netzwerkanalysegeräten sind je nach Funktion des Analysegerätes sehr unterschiedlich. Die Messgenauigkeit von Geräten zur Überwachung der Netzwerk- und/oder Anwendungsleistung wird beeinträchtigt, wenn Pakete vom Netzwerksensor gedroppt werden. Im Falle eines Cybersicherheitsgeräts, wie z.B. eines Suricata-basierten Intrusion Detection Systems (IDS), werden verpasste Attacken direkt durch den Verlust von Paketen beeinflusst. Dies gilt auch für die Dateiextraktion.

Die Auswirkung von Paketverlusten auf die Generierung von Intrusion Alerts

Egal wie gut die IDS-Regel ist, wenn nicht alle Pakete für eine bestimmte Session an das IDS geliefert werden, können Alarme verpasst werden. Dies ist hauptsächlich darauf zurückzuführen, wie ein IDS eine Session verarbeitet. Die gegebenen Pakete, die innerhalb der Session verworfen werden, bestimmen, ob das IDS genug Daten hat, um einen Alarm zu generieren. In vielen Fällen verwirft das IDS die gesamte Sitzung, wenn Schlüsselpakete fehlen. Ein verpasster Alarm könnte bedeuten, dass ein Eindringversuch unentdeckt blieb.

Zur Messung der versäumten Alarme wurde die folgende Methodik angewandt:

• Traffic-Quelle ist eine PCAP-Datei, die den tatsächlichen Netzwerkverkehr mit böswilligen Aktivitäten enthält
• Die PCAP-Datei wird verarbeitet, um einen bestimmten zufälligen Paketverlust zu simulieren
• Suricata-Alarme werden für die originale PCAP-Datei mit einer modifizierten Datei verglichen

Beispielhafte Zahlen:

• 10% verpasste Alarme mit 3% Paketverlust
• 50% verpasste Alarme mit 25% Paketverlust

Die Auswirkung von Paketverlusten auf die IDS-Datei-Extraktion

Teil einer erfolgreichen IDS-Strategie ist es, auch die Dateiextraktion zu automatisieren. Die meisten IDS-Engines unterstützen die Protokolle HTTP, SMTP, FTP, NFS und SMB. Der Dateiextraktor läuft über den Protokoll-Parser, der das Dekomprimieren und Entpacken der Anfrage und/oder der Antwortdaten übernimmt, falls erforderlich. Der Verlust eines einzelnen Pakets für einen Stream, welcher eine bestimmte Datei beinhaltet, führt in den meisten Fällen zum Scheitern der Dateiextraktion.

Beispielhafte Zahlen:

• 10% fehlgeschlagene Dateiextraktion mit 4% Paketverlust
• 50% fehlgeschlagene Dateiextraktion mit 5,5% Paketverlust

Zusammenfassend zeigen die Testergebnisse, wie wichtig Zero Packetloss für einen erfolgreichen IDS-Einsatz sind. FPGA-SmartNIC-Funktionen wie On-Board-Burst-Pufferung, DMA und optimierte PCI-Express-Performance minimieren oder eliminieren den Paketverlust in einem serverbasierten Standard-IDS vollständig.

Leistungsresistenz ist die Fähigkeit, die Leistung Ihres kommerziellen oder selbstgebauten Geräts in jeder Rechenzentrumsumgebung zu gewährleisten. Mit anderen Worten, um sicherzustellen, dass Ihre Performance-Überwachung, Cybersicherheits- oder Forensik-Appliance widerstandsfähig gegen häufige Probleme im Rechenzentrum ist, wie z.B. schlecht konfigurierte Netzwerke, Unfähigkeit, den gewünschten Verbindungstyp anzugeben, Zeitsynchronisation, Leistung, Platz usw.

In diesem Blog werden wir uns mit der Deduplizierung befassen und wie die Unterstützung der Deduplizierung in Ihrer SmartNIC die Leistungsresistenz sicherstellt, wenn Rechenzentrumsumgebungen nicht richtig konfiguriert sind – speziell Router und Switch SPAN-Ports.

Nehmen wir das Schlimmste an

Bei der Entwicklung einer Appliance zur Analyse von Netzwerkdaten für die Überwachung von Leistung, Cybersicherheit oder Forensik ist es selbstverständlich anzunehmen, dass die Umgebungen, in denen Ihre Appliance eingesetzt wird, korrekt konfiguriert sind und den Best Practices entsprechen. Es ist auch anzunehmen, dass Sie den Zugang und die Konnektivität erhalten können, die Sie benötigen. Warum sollte sich jemand die Mühe machen, für ein kommerzielles Gerät zu bezahlen oder gar die Entwicklung eines Gerätes im eigenen Haus zu finanzieren, wenn er nicht auch dafür sorgen würde, dass die Umwelt den Mindestanforderungen entspricht?

Leider ist es nicht immer so, wie viele Veteranen der Geräte-Reihen Ihnen sagen werden. Denn nicht immer ist das für den Einsatz der Appliance verantwortliche Team das für den Betrieb des Rechenzentrums verantwortliche Team. Geräte sind nicht die erste Priorität. Was also in der Praxis passiert, ist, dass das Team, das die Appliance einsetzt, angewiesen wird, die Appliance an einem bestimmten Ort mit spezifischer Konnektivität zu installieren, und das ist alles. Möglicherweise bevorzugen Sie es, einen TAP zu verwenden, der jedoch möglicherweise nicht verfügbar ist, so dass Sie einen Switched Port Analyzer (SPAN)-Port von einem Switch oder Router für den Zugriff auf Netzwerkdaten verwenden müssen.

Während dies akzeptabel erscheinen mag, kann es zu einem unerwarteten und unerwünschten Verhalten führen, das für die grauen Haare auf den Köpfen von Veteranen verantwortlich ist! Ein Beispiel für dieses unerwünschte Verhalten sind doppelte Netzwerkpakete.

Wie entstehen doppelte Pakete?

Im Idealfall möchten Sie bei der Durchführung von Netzwerküberwachung und -analyse mit einem Fingertipp direkten Zugriff auf die Echtzeitdaten erhalten. Wie wir jedoch bereits erwähnt haben, kann man das nicht immer vorschreiben und muss sich manchmal mit der Konnektivität zu einem SPAN-Port begnügen.

Der Unterschied zwischen einem TAP und einem SPAN-Port besteht darin, dass ein TAP eine physikalische Vorrichtung ist, die in der Mitte der Kommunikationsverbindung installiert ist, so dass der gesamte Datenverkehr durch den TAP läuft und auf das Gerät kopiert wird. Umgekehrt empfängt ein SPAN-Port an einem Switch oder Router Kopien aller Daten, die den Switch passieren, die dann über den SPAN-Port dem Gerät zur Verfügung gestellt werden können.

Bei richtiger Konfiguration funktioniert ein SPAN-Port einwandfrei. Moderne Router und Switches sind besser geworden, um sicherzustellen, dass die von den SPAN-Ports bereitgestellten Daten zuverlässig sind. SPAN-Ports können jedoch so konfiguriert werden, dass sie zu doppelten Paketen führen. In einigen Fällen, in denen SPAN-Ports falsch konfiguriert sind, können bis zu 50% der vom SPAN-Port bereitgestellten Pakete Duplikate sein.

Also, wie passiert das? Was Sie in Bezug auf SPAN-Ports verstehen müssen, ist, dass, wenn ein Paket in den Switch an einem Eingangsport eintritt, eine Kopie erstellt wird – und wenn es den Switch an einem Ausgangsport verlässt, wird eine weitere Kopie erstellt. In diesem Fall sind Duplikate unvermeidlich. Es ist jedoch möglich, den SPAN so zu konfigurieren, dass er nur Kopien beim Eintritt oder Austritt aus dem Switch erstellt, um Duplikate zu vermeiden.

Dennoch ist es nicht ungewöhnlich, in einer Rechenzentrumsumgebung anzukommen, in der SPAN-Ports falsch konfiguriert sind und niemand die Berechtigung hat, die Konfiguration am Switch oder Router zu ändern. Mit anderen Worten, es wird Duplikate geben und man muss damit leben!

Was sind die Auswirkungen von Duplikaten?

Duplikate können viele Probleme verursachen. Das offensichtliche Problem ist, dass die doppelte Datenmenge die doppelte Menge an Rechenleistung, Speicher, Leistung usw. erfordert. Das Hauptproblem sind jedoch False Positives: Fehler, die nicht wirklich Fehler sind, oder Bedrohungen, die nicht wirklich Bedrohungen sind. Eine gängige Art und Weise, wie Duplikate die Analyse beeinflussen, ist eine Zunahme von TCP-Out-of-Order- oder Retransmissionswarnungen. Das Debuggen dieser Probleme nimmt viel Zeit in Anspruch, in der Regel Zeit, die ein überlastetes, unterbesetztes Netzwerkbetriebs- oder Sicherheitsteam nicht hat. Darüber hinaus ist jede Analyse, die auf der Grundlage dieser Informationen durchgeführt wird, wahrscheinlich nicht zuverlässig, so dass dies das Problem nur verschärft.

Wie man Resilienz erreicht

Mit der über eine SmartNIC in die Appliance integrierten Deduplizierung ist es möglich, bis zu 99,99% der von SPAN-Ports erzeugten doppelten Pakete zu erkennen. Ähnliche Funktionen sind bei Packet Brokern verfügbar, jedoch gegen eine beträchtliche zusätzliche Lizenzgebühr. Bei Napatech SmartNICs ist dies nur eine von mehreren leistungsstarken Funktionen, die ohne Aufpreis angeboten werden.

Die Lösung ist ideal für Situationen, in denen das Gerät direkt an einen SPAN-Anschluss angeschlossen wird, wodurch die Anzahl der Schäden, die durch Duplikate entstehen können, drastisch reduziert wird. Es bedeutet aber auch, dass die Appliance widerstandsfähig gegen SPAN-Fehlkonfigurationen oder andere Probleme der Netzwerkarchitektur ist, die zu Duplikaten führen können – ohne sich auf andere kostspielige Lösungen, wie z.B. Packet Broker, zu verlassen, um die notwendige Funktionalität zur Verfügung zu stellen und die Lösung zu komplettieren.