Autor-Archive: Timur Özcan

Netzwerk-TAP vs. SPAN-Port

netzwerk-tap_vs_span-port

In meinem aktuellen Beitrag möchte ich auf das Thema Netzwerkzugriff mittels Netzwerk-TAP eingehen und Ihnen die Vorteile dieser Technik aufzeigen.

Netzwerke sind heutzutage das Kernelement für den Transport von Kommunikationsdaten und den Austausch von elektronischen Informationen. Die Zahl der netzwerkfähigen Produkte nimmt rapide zu und das Medium Internet ist längst zu einem festen Bestandteil unseres Lebens geworden.

Auch im Heimbereich setzen Hersteller mehr und mehr auf netzwerkfähige Elemente und ermöglichen dadurch den Anwendern einen ortsunabhängigen und komfortablen Zugriff (auf solche Geräte).

Ein Leben ohne Internet ist kaum noch denkbar und heutige Computer Netzwerke nehmen einen sehr großen Stellenwert ein.

Was aber, wenn das Netzwerk ausfällt
oder nicht in gewohnter Weise zur Verfügung steht?

Netzwerk-Monitoring mit Netzwerk-Taps oder SPAN-Port

Die Auswirkung eines Netzwerk Ausfalles kann gigantische finanzielle Folgen nach sich ziehen und durchaus ein weltweites Chaos auslösen.

Durch ein proaktives Monitoring System können Sie Ihre IT Dienstgüte kontinuierlich überwachen und somit das Risiko eines Ausfalles deutlich minimieren.

Eine permanente Überwachung Ihrer IT Infrastruktur hilft Ihnen auch bei Investitionsentscheidungen, da Sie über die gewonnenen Informationen detaillierte Analysen und Auswertungen erhalten und somit Tendenzen ableiten können. Gerade wenn es um Kapazitätsplanungen oder die Sicherstellung von QoS (Quality of Service) geht, ist ein umfangreiches Monitoring unumgänglich.

Ein Netzwerk Monitoring System ist kein Produkt von der Stange und in diesem Beitrag geht es um Netzwerk Monitoring durch das sogenannte „Packet Capture" Verfahren. Bei dieser Methode werden alle zu analysierenden Netzwerkdaten Byte für Byte ausgewertet. Dabei werden die übertragenen digitalen Informationen mittels Capturing aufgezeichnet und von dem Monitoring Tool analysiert.

Doch woher kommen diese Daten
und wie verlässlich sind diese Informationsquellen?

Am besten eignen sich für diese Messtechnik Netzwerk-TAPs. Was sind das für Geräte und wie werden diese eingesetzt?

Netzwerk-TAPs besitzen in der Regel vier physikalische Ports und werden transparent in die zu analysierende Netzwerkleitung eingeschleift. Dabei werden die auf den Netzwerk Ports übertragenen Informationen auf die Monitoring Interfaces gespiegelt.

Durch diese Technik bekommt man einen 100%’igen Einblick in das Netzwerk Geschehen und kann die Daten ohne Auswirkung auf die Netzwerk Performance analysieren. Da jedes einzelne übertragene Netzwerkpaket aus der Leitung herauskopiert wird, wäre man mit dieser Methode auch in der Lage, ein „Backup" seiner Netzwerkdaten anzulegen.

Technische Vorteile von Netzwerk-TAPs:

  • Netzwerk-TAPs beeinträchtigen die Funktion der aktiven Netzwerkleitung keinesfalls
  • 100% transparent und unsichtbar für Hacker und andere Angreifer
  • Netzwerk-TAPs sind passiv und verhalten sich wie eine Kabelbrücke (fail-closed) im Fehlerfall
  • Leiten die Netzwerkdaten vollständig aus
  • Die Integrität der Daten ist gewährleistet
  • Netzwerkpakete mit CRC Fehlern werden ebenso ausgeleitet
  • 100% rückwirkungsfrei durch galvanische Trennung (Datendioden-Funktion)
  • Nicht konforme Daten nach IEEE 802.3 werden herauskopiert
  • Arbeitet protokollunabhängig und unterstützt Jumbo Frames
  • Klassische Netzwerk-TAPs leiten die Daten im Voll-duplex Modus aus
  • Überbuchung der Ausgangsports ausgeschlossen
  • Keine lästige Konfiguration nötig, einmal installiert, liefert es die gewünschten Daten
  • Fehler durch falsche Paketreihenfolge ausgeschlossen
  • Konfigurationsfehler ausgeschlossen, da Inbetriebnahme durch Plug’n Play erfolgt
  • Medienkonvertierende Netzwerk-TAPs erhältlich für größtmögliche Einsatzgebiete

Netzwerk-TAP Anwendungsszenario - Lawful Interception

Haben Sie Performance Probleme im Netzwerk oder bereits einen Ausfall, ist meist schnelles Handeln angesagt. In solchen Situation hat man wenig Zeit, um SPAN-Ports zu konfigurieren und möchte sofort mit dem Troubleshooting loslegen.

Was aber, wenn zu diesem Zeitpunkt kein SPAN-Port zur Verfügung steht oder das Passwort zum Switch gerade nicht zur Hand ist? Aber es kann auch noch viel schlimmer kommen, nämlich, dass der Switch durch einen DDoS Angriff oder eine bandbreitenintensive Anwendung ausgelastet ist und aufgrund dessen eine Analyse am SPAN-Port quasi unmöglich ist. Auch könnte es passieren, dass der Switch durch einen böswilligen Angriff nicht in gewohnter Weise zur Verfügung steht.

Gerade aus Sicherheitsgründen oder um Wirtschaftsspionage zu ermitteln, sind Netzwerk-TAPs unerlässlich, da Sie auf physikalischer Ebene die Daten, gleichgültig was im Netzwerk passiert, ausleiten und somit stets eine zuverlässige Netzwerkanalyse und Monitoring erlauben.

Anwendungsbeispiele von Netzwerk-TAPs:

  • Proaktives Netzwerk-Monitoring
  • Kapazitätsplanung Fiber-Netzwerk-TAP
  • Base Lining (Trend Analyse)
  • Security und Forensik
  • Netzwerkanalyse und Troubleshooting
  • Netzwerk und Application Performance Analyse
  • Lawful Interception (gesetzeskonforme Überwachung)
  • SLA Monitoring
  • Compliance Monitoring
  • Database Monitoring
Netzwerk-TAP Anwendungsszenario - Intrusion Detection Systeme (IDS)

Fazit

Es gibt viele Gründe, Netzwerk-TAPs gegenüber dem SPAN-Port zu priorisieren und wir hoffen, dass wir Ihnen in diesem Artikel einen Überblick über die Vorzüge näherbringen konnten.

Latenzen in Schach halten – mittels dezentralisierter Messpunkte

Dezentralisierte-Messpunkte mittels Netzwerk-TAPs

Es ist noch nicht so lange her, dass Unternehmen ihre kritischen Geschäftsanwendungen ausschließlich in eigenen Netzwerken von Servern und Client-PCs untergebracht haben. Die Überwachung und Fehlerbehebung von Leistungsproblemen, wie zum Beispiel der Latenz, war einfach umzusetzen.

Obwohl sich Tools zur Netzwerküberwachung und Diagnose stark verbessert haben, hat die Einführung einer Vielzahl von miteinander verbundenen SaaS-Anwendungen und Cloud-gehosteten Diensten die typische Netzwerkkonfiguration stark verkompliziert, was negative Auswirkungen haben kann.

Da Unternehmen immer mehr Anwendungen und Datenhosting an externe Anbieter outsourcen, führt dies immer schwächere Links in das Netzwerk ein. SaaS-Dienste sind im Allgemeinen zuverlässig, aber ohne eine dedizierte Verbindung können sie nur so gut sein, wie die Internetverbindung, die sie verwenden.

Aus Sicht des Netzwerkmanagements besteht das sekundäre Problem bei extern gehosteten Apps und Services darin, dass das IT-Team weniger Kontrolle und Transparenz hat, was es schwieriger macht, dass Dienstleistungsanbieter im Rahmen ihrer Dienstleistungsvereinbarungen (SLAs) bleiben.

Die Überwachung des Netzwerkverkehrs und die Fehlerbehebung innerhalb der relativ kontrollierten Umgebung einer Unternehmenszentrale, ist für die meisten IT-Teams zu bewältigen.

Normal vs high Network Latency
Unterschied zwischen normaler und hoher Netzwerk-Latenz

Aber für Organisationen, die auf einem verteilten Geschäftsmodell beruhen, mit mehreren Zweigstellen oder Mitarbeitern an entfernten Standorten, führt die Verwendung dedizierter MPLS-Leitungen schnell zu hohen Kosten.

Wenn Sie bedenken, dass der Datenverkehr von Anwendungen wie Salesforce, Skype for Business, Office 365, Citrix und anderen, in der Regel den Hauptgeschäftssitz umgehen, ist es nicht verwunderlich, dass Latenz immer häufiger auftritt und immer schwieriger zu beheben ist.

Einer der ersten Opfer der Latenz ist die VoIP-Anrufqualität, die sich in unnatürlichen Verzögerungen bei Telefongesprächen manifestiert. Mit dem explosionsartigen Wachstum von VoIP und anderen UCaaS-Anwendungen wird dieses Problem jedoch weiter zunehmen.

Ein weiterer Bereich, in dem die Latenz ihren Tribut fordert, sind Datenübertragungsgeschwindigkeiten. Dies kann zu einer Reihe von Problemen führen, insbesondere wenn große Datendateien oder medizinische Aufzeichnungen von einem Ort zu einem anderen übertragen oder kopiert werden.

Auch bei großen Datentransaktionen, wie einer Datenbankreplikation, kann die Latenz ein Problem darstellen, da mehr Zeit für die Durchführung von Routineaktivitäten erforderlich ist.

Auswirkungen von dezentralisierten Netzwerken und SaaS

Bei so vielen Verbindungen zum Internet, von so vielen Standorten aus, macht es Sinn, dass die Leistungsüberwachung von Unternehmensnetzwerken aus dem Datenzentrum heraus erfolgt. Einer der besten Ansätze besteht darin, Tools zu finden, welche die Verbindungen an allen Remote-Standorten überwachen.

Die meisten von uns verwenden fast täglich Anwendungen wie Outlook, Word und Excel. Wenn wir Office 365 verwenden, sind diese Anwendungen wahrscheinlich so konfiguriert, dass sie sich mit Azure verbinden und nicht mit dem Unternehmensdatencenter.

Wenn das IT-Team die Netzwerkleistung nicht direkt in der Zweigstelle überwacht, verliert es die User Experience (UX) an diesem Standort vollständig aus den Augen. Sie denken vielleicht, dass das Netzwerk gut funktioniert, während die Benutzer tatsächlich wegen eines bislang nicht diagnostizierten Problems frustriert sind.

Wenn Datenverkehr von SaaS-Anbietern und anderen cloudbasierten Speicheranbietern von und zu einem Unternehmen weitergeleitet wird, kann dies durch Jitter, Trace-Route und manchmal auch Rechengeschwindigkeit negativ beeinträchtigt werden.

Dies bedeutet, dass Latenz für die Endbenutzer und Kunden zu einer sehr ernsthaften Einschränkung wird. Die Zusammenarbeit mit Anbietern, die sich in der Nähe der benötigten Daten befinden, ist eine Möglichkeit, um potenzielle Probleme aufgrund von Entfernungen zu minimieren. Aber selbst in einem parallelen Prozess haben Sie möglicherweise Tausende oder Millionen von Verbindungen, die versuchen auf einmal durchzukommen. Dies führt zwar zu einer eher geringen Verzögerung, jedoch bauen sie sich auf und werden über weite Distanzen immer größer.

Gründe für Netzwerk-Latenzen
Gründe für Netzwerk-Latenzen

Ist maschinelles Lernen die Antwort
auf eine hohe Netzwerklatenz?

Früher war es so, dass jedes IT-Team klare Netzwerkpfade zwischen seinem Unternehmen und Rechenzentrum definieren und überwachen konnte. Sie konnten Anwendungen steuern und regulieren, die auf internen Systemen ausgeführt wurden, da alle Daten lokal installiert und gehostet wurden, ohne auf die Cloud zuzugreifen.

Dieses Kontrollniveau ermöglichte einen besseren Einblick in Probleme wie Latenz und ermöglichte es ihnen eventuell auftretende Probleme schnell zu diagnostizieren und zu beheben.
Fast zehn Jahre später hat die Verbreitung von SaaS-Anwendungen und Clouddiensten nun die Leistungsdiagnostik von Netzwerken so kompliziert gemacht, dass neue Maßnahmen erforderlich sind.

Was ist die Ursache für diesen Trend? Die einfache Antwort ist eine zusätzliche Komplexität, Distanz und mangelnde Sichtbarkeit. Wenn ein Unternehmen seine Daten oder Anwendungen an einen externen Anbieter überträgt, anstatt sie lokal zu hosten, fügt dies effektiv eine dritte Partei in den Mix der Netzwerkvariablen ein.

Jeder dieser Punkte führt zu einer potenziellen Schwachstelle, die sich auf die Netzwerkleistung auswirken kann. Diese Dienste sind zwar größtenteils recht stabil und zuverlässig, aber Ausfälle bei einem oder mehrerer Dienste kommen selbst bei den Branchengrößten vor und können sich auf Millionen von Benutzern auswirken.

Tatsache ist, dass es viele Variablen in einer Netzwerklandschaft gibt, die von den IT-Teams der Unternehmen nicht mehr kontrolliert werden können.

/p>Eine Möglichkeit, mit der Unternehmen versuchen die Leistung sicherzustellen, besteht darin, einen dedizierten MPLS-Tunnel zu nutzen, welcher zur eigenen Unternehmenszentrale oder ins Datenzentrum führt. Aber dieser Ansatz ist teuer und die meisten Unternehmen nutzen diese Methode nicht für ihre Zweigstellen. Dies hat zur Folge, dass Daten aus Anwendungen wie Salesforce, Slack, Office 365 und Citrix nicht mehr durch das Rechenzentrum des Unternehmens übertragen werden, da sie dort nicht mehr gehostet werden.

Bis zu einem gewissen Grad kann die Latenz durch die Verwendung traditioneller Methoden zur Überwachung der Netzwerkleistung gemindert werden, aber eine Latenz ist naturgemäß nicht vorhersehbar und schwer zu verwalten.

Wie sieht es jedoch mit künstlicher Intelligenz aus? Wir alle haben Beispiele von Technologien gehört, die große Fortschritte machen, indem sie eine Form des maschinellen Lernens verwenden. Leider sind wir jedoch nicht an dem Punkt, an dem maschinelle Lernverfahren die Latenz signifikant minimieren können.

Wir können nicht genau vorhersagen, wann ein bestimmter Switch oder Router mit Datenverkehr überlastet wird. Das Gerät kann einen plötzlichen Datenburst erleben, der nur eine Verzögerung von einer Millisekunde oder sogar zehn Millisekunden verursacht. Tatsache ist, sobald diese Geräte überlastet sind, kann das maschinelle Lernen bei diesen plötzlichen Änderungen noch nicht helfen, Warteschleifen von Paketen, die auf eine Verarbeitung warten, zu verhindern.

Die zur Zeit effektivste Lösung besteht darin, die Latenz dort zu bekämpfen, wo sie die Benutzer am meisten beeinflusst – so nah wie möglich an ihrem physischen Standort.

In der Vergangenheit nutzten die Techniker Netflow und/oder eine Vielzahl von Überwachungsinstrumenten im Rechenzentrum, da sie genau wussten, dass der Großteil des Datenverkehrs zu ihrem Server gelangte und dann zu ihren Kunden zurückkehrte. Bei einer so viel größeren Datenverteilung gelangt heute nur ein kleiner Teil der Daten zu den Servern, was eine Überwachung des eigenen Datenzentrums weit weniger effizient macht.

Anstatt sich ausschließlich auf ein solches zentralisiertes Netzwerküberwachungsmodell zu verlassen, sollten IT-Teams ihre herkömmlichen Tools ergänzen, indem sie die Datenverbindungen an jedem Remote-Standort oder in jeder Zweigstelle überwachen. Im Vergleich zu heutigen Praktiken ist dies eine veränderte Denkweise, aber sie macht Sinn: Wenn die Daten verteilt werden, muss auch die Netzwerküberwachung verteilt werden.

Anwendungen wie Office 365 und Citrix sind gute Beispiele, da die meisten von uns regelmäßig Produktivitäts- und Unified Communications Tools verwenden. Diese Anwendungen werden wahrscheinlich eher mit Azure, AWS, Google oder anderen verbunden, als mit dem eigenen Unternehmensdatencenter. Wenn das IT-Team diese Zweigstelle nicht aktiv überwacht, verliert es die User Experience an diesem Standort vollständig aus den Augen.

Wählen Sie einen umfassenden und geeigneten Ansatz

Trotz aller Vorteile von SaaS-Lösungen wird die Latenz auch weiterhin eine Herausforderung bleiben, falls IT-Teams von Unternehmen ihre Herangehensweise an das Netzwerkmanagement nicht überdenken.
Kurz gesagt, sie müssen einen umfassenden, dezentralisierten Ansatz für die Netzwerküberwachung verfolgen, der das gesamte Netzwerk und all seine Zweigstellen umfasst. Es müssen ebenfalls bessere Möglichkeiten gefunden werden, die User Experience zu überwachen und bei Bedarf zu verbessern.

Fokussieren Sie sich auf die User Experience

Es besteht kein Zweifel, dass die Verbreitung von SaaS-Tools und Cloud-Ressourcen für die meisten Unternehmen ein Segen war. Die Herausforderung für die IT-Teams besteht jetzt jedoch darin, den Ansatz des Netzwerkmanagements in einem dezentralisierten Netzwerk zu überdenken. Ein wichtiges Thema ist sicherlich die Fähigkeit, effektiv zu überwachen, dass SLAs (Dienstleistungsvereinbarungen) eingehalten werden. Noch wichtiger ist jedoch die Möglichkeit, die Servicequalität für alle Endbenutzer sicherzustellen.

Um das zu erreichen, müssen IT-Experten genau sehen, was die Nutzer in Echtzeit erleben.
Dieser Übergang zu einem proaktiveren Überwachungs- und Fehlerbehebungsstil hilft IT-Fachleuten bei der Behebung von Netzwerk- oder Anwendungsengpässen jeglicher Art, bevor sie für Mitarbeiter oder Kunden problematisch werden.

Fazit

Ergo, um möglichst niedrige Latenzen und eine damit einhergehende optimale User Experience sicherzustellen reicht ein auf zentralen Messpunkten basierendes Monitoring heutzutage meist nicht mehr aus.
Während das Monitoring nach wie vor zentralisiert bleiben kann müssen die Messpunkte zunehmend dezentralisiert werden.

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.

Ethernet-Pakete-luegen-nicht

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 kontaktieren Sie uns doch einfach – wir sind gerne für Sie da.

Thank you for your upload

Zum Inhalt springen