Author Archiv: Timur Özcan

Emotet Malware: E-Mail-Spoofer-Erwachen

Laut IBM X-Force hat sich die Emotet-Malware in letzter Zeit in Deutschland und Japan verbreitet und zielt immer aggressiver auf Unternehmen in dieser Region ab.

Emotet ist ein Banking-Trojaner, der sich über makrofähige E-Mail-Anhänge verbreitet, die Links zu bösartigen Websites enthalten. Er funktioniert in erster Linie als Downloader für andere Malware, nämlich den TrickBot-Trojaner und die Ryuk-Ransomware. Aufgrund seines polymorphen Charakters kann er traditionelle signaturbasierte Erkennungsmethoden umgehen, was seine Bekämpfung besonders schwierig macht. Sobald die Malware in ein System eingedrungen ist, infiziert sie laufende Prozesse und stellt eine Verbindung zu einem entfernten C&C-Server her, um Anweisungen zu erhalten, Downloads auszuführen und gestohlene Daten hochzuladen (us-cert.gov).

Traditionell hat Emotet die Rechnungsbenachrichtigungen von Unternehmen zur Tarnung verwendet und dabei oft das Branding seriöser Institutionen nachgeahmt, um sich selbst als legitim darzustellen. Diese Strategie ermöglichte es der Malware, Opfer in den USA (52 % aller Angriffe), Japan (22 %) und Ländern der EU (japan.zdnet.com) ins Visier zu nehmen. Ein Vorfall im Dezember 2019 veranlasste die Stadt Frankfurt, Sitz der Europäischen Zentralbank, ihr Netzwerk zu schließen (zdnet.com).

In Japan allerdings agiert die Malware im Vergleich zu den vergangenen Jahren mit viel größerer Aggressivität. Ende 2019 wurde eine erhöhte Aktivität gemeldet, und kürzlich, nach dem Ausbruch des Coronavirus in China, änderte Emotet seine Taktik und verbreitet sich nun in ganz Japan in Form von gefälschten Gesundheitswarnungen mit beunruhigenden Berichten über Coronavirus-Fälle in den Präfekturen Gifu, Osaka und Tottori (IBM X-Force Exchange).

Dies ist ein gutes Beispiel dafür, was diese Art von Malware so gefährlich macht – sie ist nicht nur resistent gegen die Erkennung durch signaturbasierte Methoden, sondern manipuliert auch grundlegende menschliche Emotionen, um sich selbst zu verbreiten.

Der Schutz vor Emotet erfordert daher komplexere Maßnahmen. Neben einer gut informierten Prävention besteht ein wirksamer Weg, damit umzugehen, darin, sich auf eine Verhaltensanalyse zu verlassen, die nach Indikatoren für Kompromisse (IoC) sucht. Im Fall von Flowmon nimmt dies die Form des InformationStealers Verhaltensmusters (BPattern) an, das als Standard-Erkennungsmethode in Flowmon ADS existiert und die Symptome der Präsenz von Emotet im Netzwerk beschreibt.

BPatterns kann man sich als eine Art Beschreibung dessen vorstellen, wie sich verschiedene bösartige Akteure im Netzwerk manifestieren. Sie ermöglichen es dem System, Bedrohungen durch andere Aktivitäten zu erkennen, während es den Datenverkehr überwacht und kritisch bewertet. Im Gegensatz zu traditionellen Signaturen suchen BPatterns nicht nach einem bestimmten Stück Code und behalten so ihre Fähigkeit, Bedrohungen zu erkennen, auch wenn sie sich verändern und sich im Laufe ihres Lebenszyklus weiterentwickeln.

Laut einer von Fortinet veröffentlichten Analyse verwendet Emotet 5 URLs zum Herunterladen von Nutzlast und 61 fest kodierte C&C-Server (fortinet.com/blog). Diese Informationen sind im BPattern enthalten und werden vom System verwendet, um die Infektion zu erkennen und einzudämmen, bevor sie sich ausbreiten kann. Für eine zusätzliche Schutzebene gibt es auch ein BPattern für TrickBot (TOR_Malware). Beide Muster werden regelmäßig aktualisiert, je nachdem, wie sich die Trojaner entwickeln, und werden den Benutzern im Rahmen regelmäßiger Updates zur Verfügung gestellt. Es war Flowmons Partner Orizon Systems, der uns auf die erhöhte Inzidenz der Emotet-Malware aufmerksam machte und die jüngste Aktualisierung veranlasste.

Aber kein Schutz ist unfehlbar, und jedem wird empfohlen, mehrere Ebenen des Cyber-Schutzes an Ort und Stelle und auf dem neuesten Stand zu halten – einschließlich Antivirus, IoC-Erkennung auf Firewalls, Intrusion Detection Systems (IDS) und Verhaltensanalyse im Netzwerk. Da sich Emotet durch gefälschte E-Mails verbreitet, sollten Benutzer beim Öffnen von Anhängen Vorsicht walten lassen, insbesondere diejenigen, die täglich mit Rechnungen und Dokumenten von Dritten in Kontakt kommen, und verdächtige oder ungewöhnliche E-Mails an das Sicherheitsteam melden.

Um mehr über die Erkennung von Bedrohungen mit Flowmon ADS zu erfahren, kontaktieren Sie uns für weitere Informationen oder probieren Sie eine Demo aus.

Anwendungs-Risikomanagement

Die Einführung von DevOps und Agile hat den Lebenszyklus der Anwendungsentwicklung verkürzt und vereinfacht. Mit zunehmender Fokussierung auf die Schnelligkeit der Markteinführung steigt jedoch das Risiko, dass die Anwendung hinter ihren Zielen zurückbleibt. Dieses Risiko wird noch verstärkt, wenn die Anwendung – wie die meisten heute – von verteilten Netzwerken abhängig ist.

Vernetzte Anwendungen sind das Herzstück unseres Handelns. Von CRM bis Social Networking, von der Bestellung eines Taxis bis zum Geldtransfer haben sie unser Geschäfts- und Privatleben verändert. Militär, Gesundheitswesen und Rettungsdienste verlassen sich auf Apps, um Leben zu retten. Apps stärken unser persönliches, berufliches und öffentliches Leben, also müssen sie einfach funktionieren.

Application Risk Management (AppRM) ist ein neuer Prozess, der Softwarearchitekten, Entwicklern und Testern hilft, sicherzustellen, dass sie die Risiken während des gesamten Lebenszyklus der Anwendungsentwicklung und -bereitstellung richtig eingeschätzt und verwaltet haben. Es ist ein Prozess zur Identifizierung, Qualifizierung und Minderung potenzieller Fehler und Leistungsprobleme, von der Entwicklung bis zur Bereitstellung – vom Design bis zum Start der Anwendung.

AppRM ermöglicht es Entwicklern und Testern, alle mit der Anwendungsleistung verbundenen Risiken vorherzusagen und zu verwalten, wodurch Kosten und Markteinführungszeit durch frühzeitiges Erkennen von Schwachstellen und Risiken, insbesondere bei externen Faktoren, reduziert werden. So muss beispielsweise eine Anwendung, egal wie elegant sie gestaltet ist – egal wie gut sie in der Sicherheit und im Komfort des Prüflabors abschneidet – mit den Problemen des Betriebs über reale Netzwerke fertig werden, weshalb Systemarchitekten zunehmend einen neuen Ansatz für dieses spezielle Anwendungs-Risikomanagement verfolgen. Network Profiling und Virtual Test Networks sind eine leistungsstarke neue Art des Testens, die den intelligenten Weg bietet, die Risiken der Bereitstellung von Anwendungen in potenziell ungünstigen Netzwerkumgebungen zu managen.

Application Risk Management hat eine einfache Idee im Kern: Um die potenziellen Risiken zu beseitigen, indem man versteht, wie eine App in jeder Phase des Entwicklungsprozesses funktioniert, wie z.B. das Verständnis, wie sie in der realen vernetzten Umgebung funktioniert – Seine Anwender wissen, dass sie öffentliche Netzwerke nicht verbessern können, aber sie können die Toleranz und Widerstandsfähigkeit der App verbessern. Letztendlich müssen sie zunächst wissen, an welchem Punkt die App wahrscheinlich ausfällt.

In einem Umfeld, in dem das Risiko einer fehlgeschlagenen Anwendungseinführung oder -migration Einnahmen, Markenreputation, Arbeitsplätze oder sogar Leben kosten könnte, sollte die effektive Bewertung und Bewältigung dieses Risikos integraler Bestandteil jedes Entwicklungsprozesses sein und als solcher stärker in den Mittelpunkt gerückt werden.

 

Ethernet Pakete lügen nicht – nun ja, zumindest in den meisten Fällen.

Sie sagen die Wahrheit, sofern sie nicht falsch erfasst wurden. In diesen Fällen können Pakete in der Tat fett gedruckte Lügen erzählen.

Beim Durchsuchen von Trace-Dateien können wir in den Paketen auf Symptome stoßen, bei denen so mancher überrascht die Stirn runzeln würde. Dies sind Ereignisse, die auf der Oberfläche seltsam erscheinen und sogar unsere Fehlerbehebung für eine Zeit ablenken können. Einige dieser Probleme haben tatsächlich Netzwerk Analysten stundenlang irregeleitet, wenn nicht sogar Tage, wodurch sie Problemen und Ereignissen nachgejagt haben, die einfach nicht im Netzwerk existieren.

Die meisten dieser Beispiele können einfach vermieden werden, indem die Pakete von einem Netzwerk Test Access Point (TAP) aus erfasst werden, anstatt auf dem Rechner, auf dem der Verkehr erzeugt wird. Mit einem Netzwerk TAP können Sie die Netzwerkdaten transparent und unverfälscht erfassen und sehen was wirklich über die Leitung übertragen wird.

Sehr große Pakete

In den meisten Fällen sollten Pakete nicht größer als das Ethernet-Maximum von 1518 Bytes sein, oder das was für die Link-MTU festgelegt wurde. Dies gilt jedoch nur dann, wenn wir nicht mit 802. 1Q-Tags verwenden oder uns in einer Jumbo Frame Umgebung befinden.

Wie ist es möglich Pakete zu haben, die größer sind als das Ethernet-Maximum? Einfach ausgedrückt, wir erfassen sie, bevor sie von der NIC segmentiert werden. Viele TCP/IP-Stacks verwenden heutzutage TCP Segmentation Offload, welche die Last der Segmentierung von Paketen an die NIC delegiert. Der WinPcap- oder Libpcap-Treiber erfasst die Pakete, bevor dieser Vorgang stattfindet, sodass einige der Pakete viel zu groß erscheinen können, um legitim zu sein. Wenn die gleiche Aktivität auf dem Netzwerk erfasst wurde, würden diese großen Frames für den Transport in mehrere kleinere segmentiert.

Zero Delta Zeiten

Zero Delta Zeiten bedeutet, dass es keine gemessene Zeit zwischen den Paketen gibt. Wenn diese Pakete in das Erfassungsgerät gelangen, erhalten sie einen Zeitstempel und eine messbare Delta Zeit. Der Zeitstempel für den Eintritt auf dem Erfassungsgerät konnte nicht mit dem Paketaufkommen mithalten. Würden diese Pakete hingegen mit einem externen Tap-Server erfasst, könnten wir wahrscheinlich eine fehlerfreie Zeitstempelung erhalten.

Vorherige Pakete nicht erfasst

Diese Warnung wird angezeigt, weil Wireshark eine Lücke im TCP-Datenstrom bemerkt hat. Es kann anhand der sequenzierten Zahlen feststellen, dass ein Paket fehlt. Manchmal ist dies aufgrund des Upstream-Paketverlusts berechtigt. Allerdings kann es auch ein Symptom sein, dass der Analysator oder SPAN das Paket fallen gelassen hat, weil es nicht mit der Belastung mithalten konnte.

Nach dieser Warnung sollten Sie nach einer Reihe von doppelten ACK-Paketen suchen, anstatt eines defekten Pakets. Dies deutet darauf hin, dass ein Paket tatsächlich

verloren gegangen ist und erneut übertragen werden muss. Wenn Sie keine erneute Übertragung oder defekte Pakete sehen, konnte der Analyzer oder SPAN wahrscheinlich nicht mit dem Datenstrom mithalten. Das Paket war tatsächlich im Netzwerk, aber wir haben es nicht gesehen.

TCP ACKed unbemerkte Segmente

In diesem Fall wird eine Bestätigung für ein Datenpaket angezeigt, das nicht erfasst wurde. Das Datenpaket hat eventuell einen anderen Weg genommen, oder das Erfassungsgerät hat es einfach nicht wahrgenommen.

Vor Kurzem habe ich diese Ereignisse bei Trace-Dateien gesehen, die von Switches, Routern und Firewalls erfasst wurden. Da die Erfassung von Datenverkehr eine niedrigere Priorität als eine Weiterleitung hat (Gott sei Dank!), kann das Gerät schlichtweg einige der Frames im Datenstrom übersehen. Da wir die Bestätigung gesehen haben, wissen wir, dass das Paket es zu seinem Bestimmungsort geschafft hat.

Zum größten Teil sagen Pakete die Wahrheit. Sie können uns zur Hauptursache unserer Netzwerk- und Anwendungsprobleme führen. Da sie solche klaren und detaillierten Daten präsentieren, ist es sehr wichtig, dass wir sie so nah am Netzwerk wie möglich aufzeichnen. Das bedeutet, dass wir sie während der Übertragung erfassen müssen, und nicht auf dem Server selbst. Dies hilft uns dabei, keine Zeit mit falschen Negativwerten zu verschwenden.

Wenn Sie mehr über die Berücksichtigungen von Netzwerkvisualisierungen für Fachleute erfahren möchten, dann laden Sie unsere kostenlose Informationsschrift herunter, TAP vs SPAN.

https://www.garlandtechnology.com/tap_vs_span_lp

Wie Sie Einstellungsprobleme bei TCP-Verbindungen diagnostizieren können

Was kann bei einem TCP-Handshake schief gehen?

Hier ist der erster Artikel einer Serie, die alle Informationen enthält, die Sie zur Behebung von Leistungsproblemen von Anwendungen benötigen, welche auf dem TCP-Protokoll basieren.

Schauen wir uns an, wie TCP-Sessions aufgebaut werden … und was schief gehen kann!

Das TCP-Protokoll ist ein verbindungsorientiertes Protokoll, was bedeutet, dass eine Verbindung aufgebaut und aufrechterhalten wird, bis die Anwendungsprogramme an jedem Ende den Austausch von Nachrichten abgeschlossen haben. TCP arbeitet mit dem Internet Protocol (IP).

TCP bietet eine zuverlässige, geordnete und fehlerfreie Übertragung. Um dies zu tun, besitzt TCP einige Funktionen, wie zum Beispiel Handshake, Reset, Fin, Ack, Push-Pakete und andere Arten von Flags, um die Verbindung aufrechtzuerhalten und keine Informationen zu verlieren.

TCP wird mit vielen funktionellen Protokollen verwendet, wie beispielsweise HTTP. Daher ist es wichtig zu wissen, wie TCP-Probleme diagnostiziert werden können. In dieser Artikelserie werden wir diese TCP-Metainformationen erläutern und erklären, warum sie für eine Fehlerbehebung wichtig sind und wie sie mit PerformanceVision (PV) ganz leicht gemessen werden können.

Wie wird eine Session gestartet? TCP-Handshake und Verbindungszeit

Eine TCP-Verbindung, die auch als 3-Wege-Handshake bezeichnet wird, erfolgt über SYN, SYN + ACK und ACK-Pakete. Aus diesem Handshake können wir eine Leistungsmetrik mit dem Namen Connection Time (CT) ermitteln, die zusammenfasst, wie schnelle eine Session zwischen einem Client und einem Server über ein Netzwerk aufgebaut werden kann. Weitere Informationen finden Sie in diesem hervorragendem Artikel auf Wikipedia.

Abb.1 – Wie TCP Handshakes analysiert werden

Die drei Schritte eines TCP-Handshakes sind:

1. Das ‘SYN’ ist das erste Paket, das von einem Client an einen Server gesendet wird, es verlangt buchstäblich von einem Server, eine Verbindung mit ihm aufzubauen.

2. Wenn es möglich ist, antwortet der Server mit einem "SYN + ACK", was bedeutet, "Ich haben Ihre ‘SYN’ erhalten und ich bin damit EINVERSTANDEN"

3. Schließlich sendet der Client ein ‘ACK’, um die Verbindung zu bestätigen.

Wie TCP-Verbindungsfehler diagnostiziert werden

1 – SYN ohne Verbindungen

Die erste Sache, die Sie mit PV leicht diagnostizieren können, lautet: "Können meine Clients eine Verbindung zu meinen Servern herstellen?" Gehen Sie im PV-Menü zu Applikation – → Clients, wählen die Registerkarte TCP und setzen den Filter mit dem Namen “Nur einseitigen Fluss". Dadurch sehen wir nur den Verkehr vom Client zum Server und keine Antwort vom Server.

Abb.2 – Nur auf einseitige Flows filtern

Dies bedeutet, dass Sie nur die Top-Client-IPs mit nur einem Fluss vom Client und ohne Antwort sehen möchten.

Für fortgeschrittene Benutzer von PerformanceVision

Wir haben den Filter so festgelegt, dass nur einseitige Flows zu sehen sind, wodurch größtenteils ‘SYN’ Probleme angezeigt werden, aber Sie könnten auch andere Arten von Flows erhalten. Um lediglich die ‘SYN’ ohne Verbindungen zu ermitteln, werden Sie einenbenutzerdefinierten Filter verwenden müssen:

syn.count > 0 and ct.count = 0

Abb.3 – PV hat einseitige Flows gefunden und diese sortiert

Wie Sie auf den obigen Ergebnissen sehen können, gibt es mehrere IPs, die eine Verbindung zu einem Server (SYN> 0) fordern, aber keine Verbindung zu ihnen herstellen können (Connections = 0).

Hier sind häufige Fehlerfälle:

  • Eine Firewall verweigert diese Verbindungen – Sie können dieselbe Anfrage auf Client Zones (im selben Menü) anwenden, um festzustellen, ob sich die IPs in derselben Zone befinden.
  • Der Server existiert nicht mehr oder ist nicht verfügbar – dies geschieht häufig, wenn eine Server-IP geändert wird, aber einige Clients auch weiterhin die alte IP anfragen.

2 – Schlechte Verbindungsraten

In einer perfekten Welt sollten Sie 1 ‘SYN’ pro TCP-Verbindung erhalten. PV stellt eine Metrik zur Verfügung, um diese Verbindungseffizienz zu sehen, was durch eine ‘SYN’ pro Verbindungsrate (dies entspricht der Anzahl der SYN-Pakete, die mit der Anzahl der TCP-Sitzungen verglichen werden, die eingerichtet wurden) dargestellt wird. Diese Metrik befindet sich in den "Details" Tabellen und kann über die Registerkarte "TCP" geöffnet werden. Sie können auch die zeitliche Entwicklung über Anwendung → benutzerdefinierte Diagramme grafisch darstellen.

Abb.4 – PV benutzerdefinierte SYN/Conn Tabellen

Eine schlechte “SYN”-Effizienz kann manchmal auch durch ein Netzwerkproblem ausgelöst werden. Somit wird die Fehlverbindung durch einen Paketverlust oder Kontingenz verursacht. Sie können diese Vermutung überprüfen, indem Sie die Verbindungszeit betrachten. Wenn diese niedrig bleibt und sich auf mehrere Hosts auswirkt, dann ist es wahrscheinlich ein Netzwerkproblem.

Wenn hingegen die Verbindungszeit hoch ist, aber das Problem beim Server liegt, ist dieser überlastet und kann nicht auf alle Clientanfragen antworten. Wenn schließlich die ‘SYN’-Rate sehr groß ist, dann könnten Sie Sicherheitsprobleme haben, wie zum Beispiel einen DDOS-Angriff.

Fortgeschrittene Funktionen von PerformanceVision

Die Netzwerklatenz – RTT (Round Trip Time) – dies kann Ihnen einen weiteren Hinweis dafür geben, dass das Problem auf der Netzwerkseite liegt. PV stellt das RTT in der Metrik der Netzwerkleistung zur Verfügung.

Abb.5 – Eine Fehlerdiagnose von Verbindungen durch Verbindungszeiten und SYN-Raten

Fazit

In diesem ersten Artikel sahen wir eine kurze Darstellung der TCP-Leistungsmetriken und wie das TCP-Protokoll die Verbindungen mit SYN/SYN + ACK/ACK-Paketen verarbeitet. Wir sehen auch einige häufige Fehlerfälle, die leicht mit PerformanceVision diagnostiziert werden können.

Um diese Art von Problemen zu beheben, verwendeten wir die Page Top Clients, Top Client Zones und Custom Charts. Um einen Schritt weiter zu gehen, haben wir "Advanced Filter: Unilateral Flows" verwendet, um Flows ohne Antworten zu filtern.Wir haben zudem mehrere Metriken vorgestellt: die Anzahl der ‘SYN’ und ‘Handshakes’ (Verbindungen), die SYN-Effizienz und die Verbindungszeit. In nächsten Artikel werden wir einen Blick darauf werfen, wie Sie eine Verbindung mit Reset- und Fin-Paketen beenden können.

In der Zwischenzeit; falls Sie es ausprobieren möchten, können Sie einfach unsere Evaluation Virtual Appliance herunterladen:

Wie Sie Microbursts mit Savvius Omnipeek analysieren können

Ein Microburst ist eine lokale und plötzlich auftretende Fallbö (Downdraft) innerhalb eines Gewitters, die in der Regel einen Durchmesser von 4 km besitzt, was meistens jedoch viel geringer ist. Mikrobrüche können zu erheblichen Schäden an der Oberfläche führen und in einigen Fällen sogar lebensbedrohlich sein.

In Computernetzwerken wird ein Microburst als kurzzeitiger Andrang von Daten definiert, der typischerweise nur Millisekunden dauert, was jedoch die Verbindung überlastet (Ethernet, Gigabit, 10 Gigabit usw.). Ein Mikroburst ist ein ernsthaftes Bedenken für jedes Netzwerk, denn auch eine kurzfristige Überlastung des Netzwerks bedeutet, dass einige Benutzer keinen Zugriff auf das Netzwerk haben werden. Da der Industriestandard für die Messung der Netzwerknutzung in Bit pro Sekunde (bps) angezeigt wird, bleiben Mikrobursts oft unentdeckt, weil sie im Verlauf der Messung ausgeglichen werden. In den meisten Fällen melden herkömmliche Netzwerküberwachungssysteme eine solche Überlastung nicht, weil diese nicht mehr als eine volle Sekunde vorhanden sind. Die Erfahrung des Endbenutzers kann deutlich eingeschränkt werden, wenn zu viel Netzwerkverkehr aufkommt oder Leistungsengpässe entstehen, die durch einen langsamen Datendurchlauf oder Verbindungsausfall verursacht wurden.

Um einen Microburst zu identifizieren, ist eine genaue Messung des Netzwerkverkehrs auf einem Link mit einer Mikrosekunden-Granularität sowie eine Visualisierung in Millisekunden erforderlich. Hier ist ein praktisches Beispiel für die Identifizierung eines Microbursts.

In diesem Beispiel befindet sich der Messpunkt auf einem TAP, der in einen 10-Gbit/s Link einer Rechenzentrumsverbindung eingefügt wird. Wir haben 45 Sekunden des Netzwerkverkehrs mit einem Savvius Omnipliance TL gemessen. Das Expertensystem von Omnipeek alarmiert sofort auf Unregelmäßigkeiten auf den OSI-Schichten 2 bis 7. Diese Warnungen können auf der Basis einer der verfügbaren Spalten sortiert werden, z. B. durch Anzahl, Schichten usw. In diesem Fall sortieren wir nach Anzahl und sind dadurch in der Lage TCP-Wiederübertragungen, "Nicht reagierende" Peer Alerts, langsame Bestätigungen usw.

Abbildung 1: Omnipeek Expertensystem mit Strömungen, kategorisiert nach Protokollen/Anwendungen und Expertenereignissen, die nach Anzahl der Vorkommen sortiert wurden.

Abbildung 2: Eine Grafik der Gesamtauslastung mit sekundengenauer Auflösung zusammen mit den meistgenutzten Anwendungen.

Wenn die Netzwerkauslastung unter Verwendung der typischen bps dargestellt wird, wie dies in Bild 2 der Fall ist, dann beträgt die maximale Vollduplex Spitze 2,54 Gbit/s, was bei einer Verbindung mit 10-Gbit/s und einer Vollduplexkapazität von 20 Gbps als nicht besorgniserregend gilt (senden und empfangen – 10 Gbit/s in jede Richtung).

Eine Sache, die wir in der Zusammenfassung des Compass Expert Events bemerkt haben, ist, dass es eine ziemlich große Anzahl von Ereignissen gibt, die mit langsamen Netzwerkproblemen in Verbindung stehen, insbesondere bei einer Messung von 45 Sekunden. Compass kann das Auftreten von Expert Events grafisch darstellen, wodurch deutlich wird, dass es eine Gemeinsamkeit in dem Neigungsverhältnis zwischen Expert Events und der gesamten Netzwerkauslastung gibt:

Abbildung 3: Die Compass-Funktion von Omnipeek kann das Vorkommen von Expert Events darstellen.

Da die Anzahl von langsamen Netzwerkereignissen recht umfangreich ist, lassen Sie uns zurück zum Nutzungsdiagramm gehen, um die Spitzen etwas näher zu untersuchen. Wir können eine tiefer gehende Analyse durchführen, um dadurch eine Detailgenauigkeit in Millisekunden zu sehen, wobei wir mehrere Spitzen mit bis zu 9.845 Mbit pro Millisekunde feststellen konnten. Umgerechnet auf Sekunden (einfach multipliziert mit 1000), wäre dies 9.845 Gbps, und sollte dies in eine Richtung verlaufen, dann wird dies unseren 10 Gig Link vollständig auslasten.

Abbildung 4: Netzauslastung in Millisekunden-Granularität mit mehreren Spitzen von bis zu 10 Mbit pro Millisekunde

Interessanterweise wurde in Abbildung 4 das obere Protokoll in CIFS umgewandelt. Was ist also passiert?

Abbildung 5: Die übliche Ausnutzung durch TCP-Verkehr ist in Lila dargestellt, wohingegen die CIFS-Spitzen braun gekennzeichnet wurden.

Bei einer normalen Ausnutzung von bis zu 6 Mbit pro Millisekunde an TCP-Verkehr, können CIFS-Spitzen von bis zu 6 Mbit pro Millisekunde die Ausnutzung sogar auf 12 Mbit pro Millisekunde steigern, was die Kapazität eines 10 Gbit/s Links in eine Richtung gänzlich übersteigt. In einer solchen Situation sind die Switches nicht mehr in der Lage den Datenverkehr zu puffern, bis die Bursts verschwunden sind, was dazu führt, dass Pakete verloren gehen und letztendlich TCP-Neuübertragungen verursacht werden, was die Expert Events eindeutig darlegen. Savvius Omnipeek bietet eine sehr intuitive und kostengünstige Möglichkeit, um zu überprüfen, ob tatsächlich Mikrobursts in Ihrem Netzwerk auftreten, aber auch wann, wo und wie sehr die Netzwerkleistung darunter leidet. Wenn Sie noch heute eine kostenlose und 30-tägige Testversion von Omnipeek ausprobieren möchten, dann besuchen Sie einfach unsere Webseite.