DE102014110151A1 - Verfahren zur realitätsnahen Funktionsüberprüfung von Netzwerkkomponenten - Google Patents

Verfahren zur realitätsnahen Funktionsüberprüfung von Netzwerkkomponenten Download PDF

Info

Publication number
DE102014110151A1
DE102014110151A1 DE102014110151.0A DE102014110151A DE102014110151A1 DE 102014110151 A1 DE102014110151 A1 DE 102014110151A1 DE 102014110151 A DE102014110151 A DE 102014110151A DE 102014110151 A1 DE102014110151 A1 DE 102014110151A1
Authority
DE
Germany
Prior art keywords
traffic
network
network component
test
supplied
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
DE102014110151.0A
Other languages
English (en)
Other versions
DE102014110151B4 (de
Inventor
Wolfram Seidel
Gabriel Bertram
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Deutsche Telekom AG
Original Assignee
Deutsche Telekom AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Deutsche Telekom AG filed Critical Deutsche Telekom AG
Priority to DE102014110151.0A priority Critical patent/DE102014110151B4/de
Publication of DE102014110151A1 publication Critical patent/DE102014110151A1/de
Application granted granted Critical
Publication of DE102014110151B4 publication Critical patent/DE102014110151B4/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/50Testing arrangements

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zur Überprüfung der Funktion mindestens einer Netzwerkkomponente für ein Netzwerk, wobei ein Test-Verkehr erzeugt und der Netzwerkkomponente zugeführt und von dieser verarbeitet wird, und wobei der von der Netzwerkkomponente verarbeitete Test-Verkehr mit dem der Netzwerkkomponente zugeführten Test-Verkehr verglichen wird, wobei zur Erzeugung des Test-Verkehrs der Verkehr in dem Netzwerk mitgeschnitten wird, und wobei der mitgeschnittene Verkehr anonymisiert wird um daraus den Test-Verkehr zu erzeugen.

Description

  • Die vorliegende Erfindung betrifft ein neuartiges Verfahren zur realitätsnahen Funktionsüberprüfung von Netzwerkkomponenten. Insbesondere aber nicht ausschließlich beschreibt die vorliegende Erfindung eine Möglichkeit zur realitätsnahen Funktionsüberprüfung von Netzwerkgeräten, die eine Deep Packet Inspection durchführen. Der Einsatz ist besonders geeignet aber nicht beschränkt auf die Möglichkeit zur Überprüfung von Netzwerkgeräten, welche in Carrier/Provider Netzwerken eingesetzt werden.
  • Die Kommunikation unter Komponenten über ein Datennetz erfolgt mittels Protokollen. Protokolle umfassen dabei eine feste Anzahl an Vereinbarungen beziehungsweise eine eindeutig festgelegte Menge von Regeln. Sie legen einen allgemeinen Kommunikationsstandard zum Datenaustausch zwischen Einheiten fest. Protokolle umfassen also die Methoden, mit denen Kommunikation über eine Datenverbindung durchgeführt wird und legen die Abstimmung und Synchronisierung der Netzwerksysteme fest. Zur Beherrschung der Komplexität der Kommunikation, vor allem in offenen Systemen (Internet), wurden Protokollhierarchien eingeführt. Jede Ebene besitzt hierbei einen klar umrissenen Satz von Schnittstellen für die jeweils höhere Schicht (ISO/OSI Modell). TCP/IP beschreibt die für den Datenaustausch im Internet und Intranet notwendigen Protokollhierarchien.
  • Mit zunehmender Beliebtheit des Internets, Fortschritten in diversen Technikbereichen und Datenkommunikationsverfahren wurden und werden zunehmend neue Nutzungs- und Anwendungsarten entwickelt. Neben der stetig zunehmenden Anzahl an divergierenden Anwendungen und der damit einhergehenden Zunahme an benötigten und eingesetzten Protokollen, verlangen komplexere Anwendungsbereiche ebenso komplexe Protokolle.
  • Bevor Netzwerkgeräte in einem Produktionsnetz eingesetzt werden, werden Überprüfungen im Bezug auf Funktionalität, Interoperabilität etc. durchgeführt. Unter Zuhilfenahme von Lastgeneratoren werden hierfür im Labor künstliche Verkehrcharakteristiken erzeugt und zum Testen der Netzwerkgeräte verwendet. Diese synthetisch erzeugten Verkehrcharakteristiken haben den Anspruch realitätsnah zu sein. Nur unter dieser Vorraussetzung können Netzwerkgeräte vor dem produktiven Einsatz sinnvoll überprüft werden.
  • Folgende Faktoren sind unter dem Kriterium der Realitätsnähe zu nennen:
    • – Verhältnis von fragmentierten Paketen zu nicht fragmentierte Paketen
    • – Implementierungsfreiheiten in Protokollspezifikationen und Protokollstandards
    • – Verkehrsmix (welche Protokolle zu welchen prozentualen Anteilen)
    • – Anomalien in Headerfeldern
    • – Korrupte Pakete
    • – Paketwiederholungen
    • – Standardkonformes und nicht standardkonformes Verhalten von Netzwerkstacks
    • – Verhältnis von Paketgrößen
    • – Vorhandensein von Tunnelkonstrukten und verschlüsselten Paketen
    • – Verkettung, Verschachtelung von Protokollen und optionalen Erweiterungsheadern.
  • Im Rahmen der Absicherung von Netzwerken, insbesondere Carrier Netzwerken werden Netzwerkkomponenten eingesetzt, welche die in Anzahl und Komplexität zunehmenden Protokolle in ihrer gesamtheitlichen Komplexität untersuchen. Dies betrifft insbesondere aber nicht ausschließlich Firewalls, Intrusion Detection Systeme, Intrusion Prevention Systeme oder Loadbalancer.
  • Mit zunehmender Verarbeitungstiefe von Verkehren durch Netzwerkgeräte steigen die Anforderungen an Testverfahren für diese Netzwerkgeräte. Die Testverfahren verlangen, dass die in Umfang und Komplexität steigenden Verkehrscharakteristiken in modernen Datennetzen in vollem Umfang zu Testzwecken durch Lastgeneratoren synthetisiert werden können.
  • Aktuelle Lastgeneratoren sind nicht in der Lage Verkehre zu erzeugen, die dem Anspruch der Realitätsnähe genügen. Neben der grundsätzlichen Fähigkeit der Generierung aller benötigten Protokolle stellt insbesondere die Konfiguration der Lastgeneratoren ein Hindernis dar. Die Konfiguration der Lastgeneratoren durch den Anwender/Tester verlangt zwingend vollumfängliches Wissen über die im Produktionsnetz vorherrschenden Protokolle und Protokollvarianten. Dies umschließt die zuvor unter dem Kriterium der Realitätsnähe genannten Punkte. Dieses Wissen ist meist nicht in benötigter Vollständigkeit vorhanden. Aufgrund der Vielzahl an Parametern und Variationsmöglichkeiten ist eine naturgetreue Ermittlung und Nachbildung der Verkehrscharakteristik kaum möglich.
  • Da zunehmend Netzwerkgeräte eingesetzt werden, die die komplexen Verkehrcharakteristiken im Detail bis auf Anwendungsebene untersuchen, können Lastgeneratoren nur begrenzt verwendet werden, um moderne Netzwerkgeräte unter realitätsnahen Bedingungen zu testen.
  • Die Idee der vorliegenden Erfindung verwendet einen grundsätzlich neuen Ansatz, um Netzwerkgeräte im Labor unter Bedingungen zu testen, die den zuvor genannten Bedingungen der Realitätsnahe gerecht werden.
  • Hierzu wird Produktivverkehr im Produktionsnetz mitgeschnitten, unter Berücksichtigung der gegenwärtigen Datenschutzbestimmungen anonymisiert, an die gegebenen Laborbedingungen angepasst sowie aufbereitet, ausgespielt und die Verarbeitung des zu testenden Netzwerkgeräts verifiziert. Produktivverkehr ist der beim regulären Betrieb des Netzwerks tatsächlich im Netzwerk anfallende Netzwerksverkehr.
  • Die Verwendung von Produktivverkehr impliziert, dass alle Verkehrcharakteristiken, die ein Netzwerksystem im Produktionsnetz aktuell begegnen würde, im Mitschnitt und damit zu Testzwecken vorhanden sind.
  • Die Durchführung der erfindungsgemäßen Testmethode verlangt eine mehrschrittige Vorgehensweise deren Reihenfolge nicht festgelegt ist. Auch können die im Folgenden genannten logischen Schritte an verschiedenen Zeitpunkten in geeigneter Weise miteinander kombiniert werden:
    • – Mitschnitt des Verkehrs im Produktionsnetz,
    • – Anonymisierung des Verkehrs,
    • – Anpassung des Verkehrs an gegebene Laborbedingungen,
    • – Aufbereitung des Verkehrs zur Realisierung einer spezifischen Teststellung,
    • – Widerspielen des aufbereiteten und anonymisierten Verkehrs,
    • – Verifikation der Verarbeitung durch das zu testende Gerät.
  • Im Folgenden werden die genannten logischen Abschnitte detaillierter beschrieben.
  • – Mitschnitt des Verkehrs im Produktionsnetz:
  • Alle im Produktivverkehr enthaltenen Netzwerkpakete sind unabhängig von Protokoll, Aufbau und Beschaffenheit in ihrer Gesamtheit und konkreten Reihenfolge unverändert und vollständig mitzuschneiden. Die Speicherung der Daten muss den gegebenen Datenschutzbestimmungen entsprechen. Für jedes Datenpaket muss ein Zeitstempel gespeichert werden (Absolutwert oder Deltawert). Die Speicherung der Daten verlangt ein geeignetes Datenformat zur weiteren Verarbeitung der Daten.
  • – Anonymisierung des Verkehrs
  • Da der Mitschnitt des Netzwerksverkehrs Daten von Nutzern (beispielsweise Kunden) dieses Datennetzes enthält, müssen geeignete (Teil-)Anonymisierungsmaßnahmen durchgeführt werden.
  • Die (Teil-)Anonymisierung der Daten stellt einen zentralen und elementaren Bestandteil des Verfahrens dar. Die (Teil-)Anonymisierung des Verkehrs muss unter Berücksichtigung der Funktionsweise des zu testenden Netzwerkgerätes erfolgen. Insbesondere aber nicht ausschließlich muss bekannt und berücksichtigt werden, welche Protokolle in welcher Tiefe, d.h. welche Headerfelder in welcher Form untersucht werden. Die Verarbeitungsweise des zu testenden Netzwerkgerätes muss bei der (Teil-)Anonymisierung berücksichtigt werden, um die exakte Verarbeitung des Verkehrs durch das Testgerät entsprechend der potentiellen Verarbeitung im Produktionsnetz zu gewährleisten.
  • Für jedes der im Mitschnitt enthaltenen Protokolle muss eine geeignete (Teil-)Anonymisierung geschaffen werden, vorausgesetzt personenbezogene oder in einer anderen Art und Weise als sensibel einzustufende Daten nach vorherrschendem Datenschutzrecht sind enthalten. Diese Informationen sind mittels einer Einwegfunktion zu entfernen, um die Wiederherstellung der Daten zu verhindern.
  • Die Anonymisierung schließt fehlerhafte und korrupte Pakete ein. Insbesondere muss bei der (Teil-)Anonymisierung beachtet werden, dass korrupte und fehlerhafte Pakete auch nach der Anonymisierung in exakt gleicher Weise fehlerhaft oder korrupt bleiben.
  • Generell dürfen durch die Anonymisierung des Verkehrs keine Veränderungen der Pakete erfolgen, welche die Verarbeitung der zu testenden Netzwerkgeräte in irgendeiner Form beeinflussen.
  • – Anpassung des Verkehrs an gegebene Laborbedingungen
  • Die Anpassung des Verkehrs dient verschiedenen Zwecken, welche im Folgenden beschrieben werden. Zum einen wird in diesem logischen Schritt die benötigte Anpassung des Verkehrs an die konkrete Testumgebung im Labor durchgeführt. Dies ist notwendig, da der mitgeschnittene Verkehr in der Regel aus einer physikalisch zur Testumgebung unterschiedlichen Umgebung stammt. Unter der genannten Bedingungen ist es zwingend erforderlich, unter Berücksichtigung der Testumgebung die Adressinformationen des Data Link Layers anzupassen. Eine Adaption weiterer Adressinformation auf höheren Schichten ist abhängig vom Testaufbau durchzuführen.
  • Adressinformationen lassen sich in diesem Schritt ebenfalls nutzen, um eine Klassifizierung beziehungsweise Aufteilung des Verkehrs vorzunehmen. Dies ist beispielsweise notwendig, um Netzwerkgeräte zu testen, die eine statusbehaftete Verarbeitung (stateful inspection) durchführen. In diesen und anderen Fällen kann der mitgeschnittene Verkehr nicht aus einem einzelnen Interface ausgespielt werden, sondern muss entsprechend der Verkehrsrichtung des ursprünglichen Verkehrs an verschiedenen Schnittstellen an das zu testende Gerät gesendet werden. Dies lässt sich unter Anderem realisieren, indem der auszuspielende Verkehr anhand von Adressinformationen separiert wird. Es entstehen durch diese Verfahrensweise verschiedene, logische Mitschnitte, die jeweils an unterschiedlichen physikalischen Netzwerkschnittstellen wiedergegeben werden.
  • – Aufbereitung des Verkehrs zur Realisierung einer spezifischen Teststellung
  • Unter dem Aspekt der Aufbereitung des aufgezeichneten Verkehrs lassen sich verschiedene Aufgabenstellungen und Testanforderungen realisieren. Beispielsweise lässt sich durch eine Analyse der Paketflüsse, Verbindungsaufbauphasen von zustandsbasierten Protokollen wie dem Session Initiation Protocol (SIP) extrahieren. In Kombination mit einer Manipulation des enthaltenen Timestamps jedes relevanten Pakets lässt sich eine Parallelisierung von Verbindungen realisieren. Auf diese und andere Weise können besondere Lastsituationen im Labor auf Basis von realitätsnahem Verkehr erzeugt oder reproduziert werden.
  • Andere Analysen der Paketflüsse sind anwendbar, wodurch sich verschiedene Verkehrcharakteristiken und damit verschiedene an die Testanforderungen angepasste Überprüfungen von Netzwerkgeräten durchführen lassen.
  • – Widerspielen des aufbereiteten und anonymisierten Verkehrs
  • Das Wiedergeben des mitgeschnittenen Verkehrs muss den Bedingungen des Produktionsnetzes entsprechen. Die im vorherigen Schritt aufbereiteten Verkehre müssen unter exakter Berücksichtigung der Paketreihenfolge und des Timings geschehen. Hierzu müssen die im ursprünglichen Mitschnitt enthaltenen Timinginformationen (absolute Zeitstempel, Deltawerte) berücksichtigt werden.
  • – Verifikation der Verarbeitung durch das zu testende Gerät
  • Die Verifikation der Funktionalität des zu testenden Netzwerkgerätes verlangt eine abschließende Analyse. Konkret muss der ausgespielte Verkehr mit dem Verkehr nach der Verarbeitung durch das zu testende Netzwerkgerät verglichen werden. Hierzu muss der Verkehr nach der Bearbeitung durch das zu testende Netzwerkgerät unter Berücksichtigung der zum Mitschnitt des Verkehrs im Produktionsnetz genannten Aspekte erneut aufgezeichnet werden. Beide Mitschnitte, der bearbeitete Mitschnitt aus dem Produktionsnetz sowie der erzeugte Mitschnitt nach der Verarbeitung des aufbereiteten Mitschnitts durch das zu testende Gerät muss in geeigneter Form miteinander verglichen werden. Dies kann durch eine automatisierte Analyse oder manuell erfolgen. Auf diese Art und Weise können Paketverluste, Paketmanipulationen oder sonstige Veränderungen des Verkehrs durch die Verarbeitung des bearbeiteten Mitschnitts des Produktionsnetzes durch das zu testende Netzwerkgerät erkannt werden. Ferner lassen sich durch den Vergleich der Mitschnitte weitere Informationen über die interne Verarbeitung oder die Architektur des zu testenden Netzwerkgerätes gewinnen. Beispielsweise lässt sich die interne Verarbeitungsdauer unterschiedlicher Protokolle gegenüberstellen, woraus Rückschlüsse auf das Lastverhalten sowie die interne Implementierung der Protokolle im Netzwerkgerät möglich sind.
  • Die Anwendungsgebiete der beschriebenen Erfindung unterliegen keiner Beschränkung auf bestimmte Netzwerkgeräte, Netzwerktopologien oder Netzwerktechniken. Die Testmöglichkeit umfasst jegliche Komponenten die Datenaustausch betreiben, das heißt in einer Kommunikationsbeziehung zu mindestens einem weiteren Teilnehmer eines beliebigen Netzwerks stehen. Sind die zuvor beschriebenen Anforderungen (Mitschnitt des Verkehrs im Produktionsnetz, Anonymisierung des Verkehrs, Anpassung des Verkehrs an gegebene Laborbedingungen, Aufbereitung des Verkehrs zur Realisierung einer spezifischen Teststellung, Widerspielen des aufbereiteten und anonymisierten Verkehrs, Verifikation der Verarbeitung durch das zu testende Gerät) in geeigneter Weise erfüllt, kann die beschriebenen Methode somit grundsätzlich verwendet werden, um eine Verifikation von Netzwerkkomponenten durchzuführen. Im Folgenden werden einige Anwendungsgebiete beispielhaft angegeben.
  • Mit steigender Verarbeitungskomplexität durch Netzwerkkomponenten ergeben sich besondere Vorteile bei einer Funktionsüberprüfung mittels der hier beschriebenen Methode. Gerade im Rahmen der Absicherung von Netzwerken, insbesondere Carrier Netzwerken werden Netzwerkkomponenten eingesetzt, welche die in Anzahl und Komplexität zunehmenden Protokolle in ihrer gesamtheitlichen Komplexität untersuchen (Deep Packet Inspection). Dies betrifft insbesondere aber nicht ausschließlich Firewalls, Intrusion Detection Systeme, Intrusion Prevention Systeme, Loadbalancer oder Content-Caching Systeme (beispielsweise Proxy-Server).
  • Es ist zu beachten, dass Netzwerkkomponenten keine dedizierten Systeme darstellen müssen sondern ebenfalls als reine Funktionalität (Software/Programme) auf einer beliebigen Hardware realisiert werden können. Somit ergeben sich weitere Funktionalitäten, die mittels des genannten Verfahrens überprüft werden können. Hierzu zählen beispielsweise Anti-Spam, Anti-Malware oder Anti-Virus Funktionen.
  • Insbesondere in modernen Datennetzen ergeben sich zusätzliche Anwendungsgebiete, beispielsweise in den Bereichen Bandbreitenmanagement und Quality of Service. Da diese Funktionalitäten in der Regel mit Hilfe einer tiefgreifenden Verkehrsanalyse wie Pattern-Matching, Verhaltensanalyse (Paketgrößen, Paketraten etc.) und statistischer Auswertung realisiert werden, ist bei einer Überprüfung dieser Funktionen ein realitätsnaher Verkehrsmix zwingend notwendig. Dies lässt sich mit der spezifizierten Verfahrensweise der vorliegenden Erfindung realisieren.
  • Ein konkretes Beispiel soll im Folgenden dienen, um die Schwierigkeiten der synthetischen Paketerzeugung und die Vorteile der hier beschriebenen Testmethode konkret verdeutlichen: Als Beispiel dient die Deep Packet Inspection eins Session Initiation Protocol Register Pakets. Ein einfaches Netzwerkpaket dieses Typs hat im Beispiel eine Länge von 508 Byte (4064 Bit). Diese Länge ergibt sich aus Ethernet Header (14 Byte), Vlan Header (4 Byte), IPv6 Header (40 Byte) sowie SIP Header (hier 446 Byte). Ein Paket dieser Länge ermöglicht 24064 (2 hoch 4064) verschiedene Bitkombinationen und damit Paketkonstellationen. Da nicht bekannt ist, welche der möglichen Paketkonstellationen in der Realität auftreten ist für eine umfassende Verifikation des zu testenden Geräts eine Generierung aller möglichen Bitkombinationen nötig. Zusätzlich ist zu beachten, dass es in der Regel nicht ausreichend ist die Verifikation eines Netzwerkgerätes unter Verwendung nur eines Pakettypen durchzuführen. Es sind meist verschiedene Pakettypen nötig, was die Synthetisierung der möglichen Paketkonstellationen entsprechend erschwert.
  • Wird ein Netzwerkgerät nun mit Hilfe der in dieser Erfindung beschriebenen Methodik getestet, so werden aus den möglichen Paketkonstellationen nur die Pakete verwendet, die tatsächlich im der Realität auftreten. So kann das zu testende Gerät effektiv unter realen Bedingungen getestet werden.
  • Mit der Durchführung der zuvor genannten Schritte der vorliegenden Erfindung eröffnet sich erstmals die Möglichkeit, moderne Netzwerkgeräte mit der benötigten Realitätsnähe zu testen. Es lassen sich erst durch die Anwendung der Verfahren dieser Erfindung verlässliche Aussagen über die Funktionalität eines modernen Netzwerkgerätes machen und somit über den Einsatz eines Netzwerkgerätes im Produktionsnetz oder einem anderen Wirknetz entscheiden.
  • Die Relevanz der beschriebenen Methode wird zukünftig weiter steigen. Der Trend zu neuen, komplexen Anwendungen geht einher mit einer zunehmenden Komplexität von (Netzwerk-)Protokollen. Ebenso werden immer mehr Netzwerkgeräte mit Funktionalitäten wie „Deep Packet Inspection“ ausgestattet, die diese Protokolle bis zur Applikationsschicht analysieren, ausgestattet. Dies erfordert den Einsatz geeigneter Testverfahren – wie dem hier beschriebenen –, um die korrekten Funktionen dieser Netzwerkgeräte zu überprüfen.

Claims (10)

  1. Verfahren zur Überprüfung der Funktion mindestens einer Netzwerkkomponente für ein Netzwerk, wobei ein Test-Verkehr erzeugt und der Netzwerkkomponente zugeführt und von dieser verarbeitet wird, und wobei der von der Netzwerkkomponente verarbeitete Test-Verkehr mit dem der Netzwerkkomponente zugeführten Test-Verkehr verglichen wird, dadurch gekennzeichnet, dass zur Erzeugung des Test-Verkehrs der Verkehr in dem Netzwerk mitgeschnitten wird, und dass der mitgeschnittene Verkehr anonymisiert wird um daraus den Test-Verkehr zu erzeugen.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der anonymisierte Mitschnitt des Verkehrs vor der Zuführung an die zu überprüfende Netzwerkkomponente an vorgegebene Test-Bedingungen angepasst wird.
  3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass der anonymisierte Mitschnitt des Verkehrs vor der Zuführung an die zu überprüfende Netzwerkkomponente aufbereitet wird.
  4. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass die im Verkehr enthaltenen Netzwerkpakete jeweils mit einem Zeitstempel versehen und gespeichert werden.
  5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass die Netzwerkpakete nach der Anonymisierung und der gegebenenfalls erfolgten Anpassung und/oder Aufbereitung unter Berücksichtigung der gespeicherten Zeitstempel in der ursprünglichen Reihenfolge der Netzwerkkomponente zugeführt werden.
  6. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass die Netzwerkpakete nach der Anonymisierung und der gegebenenfalls erfolgten Anpassung und/oder Aufbereitung mit einem an vorgegebene Test-Bedingungen angepassten Timing der Netzwerkkomponente zugeführt werden.
  7. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass in dem Verkehr enthaltene Fehler der Netzwerkpakete bei der Anonymisierung und der gegebenenfalls erfolgenden Anpassung und/oder Aufbereitung erhalten bleiben.
  8. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass der Vergleich des von der Netzwerkkomponente verarbeiteten Test-Verkehrs mit dem der Netzwerkkomponente zugeführten Test-Verkehr durch eine automatisierte Analyse erfolgt.
  9. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass zur Überprüfung der Funktion der Netzwerkkomponente bei dem Vergleich aufgefundene Verluste, Manipulationen oder sonstige Veränderungen der Netzwerkpakete erfasst werden.
  10. Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, dass die mindestens eine zu überprüfende Netzwerkkomponente durch eine auf einer virtualisierten Hardware programmierte Funktionalität realisiert wird.
DE102014110151.0A 2014-05-30 2014-07-18 Verfahren zur realitätsnahen Funktionsüberprüfung von Netzwerkkomponenten Active DE102014110151B4 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE102014110151.0A DE102014110151B4 (de) 2014-05-30 2014-07-18 Verfahren zur realitätsnahen Funktionsüberprüfung von Netzwerkkomponenten

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE102014007738 2014-05-30
DE102014007738.1 2014-05-30
DE102014110151.0A DE102014110151B4 (de) 2014-05-30 2014-07-18 Verfahren zur realitätsnahen Funktionsüberprüfung von Netzwerkkomponenten

Publications (2)

Publication Number Publication Date
DE102014110151A1 true DE102014110151A1 (de) 2015-12-03
DE102014110151B4 DE102014110151B4 (de) 2016-12-08

Family

ID=54481193

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102014110151.0A Active DE102014110151B4 (de) 2014-05-30 2014-07-18 Verfahren zur realitätsnahen Funktionsüberprüfung von Netzwerkkomponenten

Country Status (1)

Country Link
DE (1) DE102014110151B4 (de)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE602004010865T2 (de) * 2003-05-21 2008-12-18 Ixia, Calabasas Automatische Charakterisierung von Netzwerkverkehr
US20110310768A1 (en) * 2010-06-18 2011-12-22 Electronics And Telecommunications Research Institute Method and apparatus for modeling network traffic
US20140101767A1 (en) * 2012-10-10 2014-04-10 Matthew Cohen Systems and methods for testing and managing defensive network devices

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE602004010865T2 (de) * 2003-05-21 2008-12-18 Ixia, Calabasas Automatische Charakterisierung von Netzwerkverkehr
US20110310768A1 (en) * 2010-06-18 2011-12-22 Electronics And Telecommunications Research Institute Method and apparatus for modeling network traffic
US20140101767A1 (en) * 2012-10-10 2014-04-10 Matthew Cohen Systems and methods for testing and managing defensive network devices

Also Published As

Publication number Publication date
DE102014110151B4 (de) 2016-12-08

Similar Documents

Publication Publication Date Title
EP3925192B1 (de) Verfahren und wiedergabeeinheit zur wiedergabe von gesicherten nachrichten
DE102006012614B4 (de) Verfahren und Vorrichtung für den Durchlauf von Paketen durch eine Einrichtung zur Netzwerkadressenübersetzung
DE102005016033A1 (de) Verfahren und Systeme zum Analysieren von Netzwerkübertragungsereignissen
DE112013000387B4 (de) Dynamisches Abtasten einer Webanwendung durch Verwendung von Webdatenverkehrs- Informationen
DE112011101831B4 (de) Schutz vor websiteübergreifenden Scripting-Attacken
DE112017003502T5 (de) Verfahren, Systeme und computerlesbare Medien zum Testen von Netzwerkvorrichtungen unter Verwendung von variablen Verkehr-Burstprofilen
DE102008015576A1 (de) Datensammel-System und -Verfahren für IP-Netzwerke
DE102015003363A1 (de) Verfahren und system zum testen cloud-basierter anwendungen in einer produktionsumgebung unter verwendung hergestellter benutzer-daten
EP2490393A1 (de) Verfahren und Vorrichtung zur Analyse von Datenpaketen
DE102015216190A1 (de) Verfahren und System zum Bereitstellen einer optimierten Ethernetkommunikation für ein Fahrzeug
EP3251012B1 (de) Prüfsystem zur prüfung eines computers eines computersystems in einem prüfnetzwerk
DE102020124426A1 (de) Verfahren, Systeme und computerlesbare Medien für die Bedrohungssimulation und Empfehlungen für die Bedrohungsminderung
DE102020114730A1 (de) Verfahren, systeme und computerlesbare medien zum konfigurieren eines testsystems unter verwendung von quellcode einer zu testenden vorrichtung
DE102012218699A1 (de) Passives überwachen virtueller systeme mittels agentenlosem offline-indexieren
EP3222002B1 (de) Analysevorrichtung zur analyse und manipulation einer kommunikationssequenz
AT514215B1 (de) Verfahren zur Feststellung von Abweichungen von einem vorgegebenen Normalzustand
DE112021005651B4 (de) Informationsverarbeitungsvorrichtung, Informationsverarbeitungsverfahren und Programm
DE102014110151B4 (de) Verfahren zur realitätsnahen Funktionsüberprüfung von Netzwerkkomponenten
EP3353956A1 (de) Verfahren und vorrichtung zur überwachung von steuerungssystemen
DE102007054648A1 (de) Fehler-Identifikation in einem rechner-basierten Netzwerk
EP4136863A1 (de) Verfahren und wiedergabeeinheit zur wiedergabe von gesicherten nachrichten
EP3641231A1 (de) Verfahren und vorrichtung zur überwachung einer datenkommunikation
EP2672660B1 (de) Verfahren zur Beeinflussung der Buskommunikation eines Steuergeräts
WO2022128829A1 (de) Gateway, speziell für ot-netzwerke
DE102016112314B4 (de) Verfahren zum Bestimmen wenigstens eines Dienstgüte-Parameters einer paketbasierten Datenübertragung

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R016 Response to examination communication
R016 Response to examination communication
R016 Response to examination communication
R016 Response to examination communication
R018 Grant decision by examination section/examining division
R020 Patent grant now final
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04L0012260000

Ipc: H04L0043000000