Netzwerkanalyse, Fehlersuche, Testberichte
Home / News
Netzwerkanalyse
Grundlagen
Verkabelung
Erste Schritte
Baselining
Let's sniff
Tools
Auswerten/Filtern
Typische Probleme 1
Typische Probleme 2
Sicherheit
Bücher
Tutorials
Cacti
DSL einrichten
DynDNS einrichten
m0n0wall | pfSense
Nmap
VirtualBox
Wireshark
FAQ
Know How
Testberichte
Hardware-DB
Netzwerklexikon
Links / Service
Suche
Kontakt
Impressum
Feedback
Sitemap
Netzwerkanalyse

Auswerten und Filtern

Es ist vollbracht. Die Daten wurden aufgezeichnet und wir haben ein mehr oder weniger großes Tracefile. Was nun?

Expertensysteme

Einige Hersteller statten ihre Werkzeuge mit Expertensystemen aus.

Sprich: Nur ein Experte kann das Teil bedienen!

Sicher liefern diese Systeme auch brauchbare Hinweise, aber man sollte ruhig einmal einen Network General Sniffer einen halben Tag in einem stabilen Produktionsnetz mitlaufen lassen. Wer dann noch Lust hat, allen Meldungen des Expertensystems auf den Grund zu gehen...

Wie fange ich an?

Um sich einen ersten Überblick über die aufgezeichneten Packete zu verschaffen, eignet sich die „Protocol Hierarchy Statistics“ von Ethereal sehr gut.

Screenshot von Ethereal

Protocol Hierarchy Statistics im Ethereal

In dieser Darstellung kann man die einzelnen Protokolle aufklappen und sich einen sehr guten Überblick über die Protokollverteilung machen.

Ähnliche Möglichkeiten bieten mir ntop und Etherape. Im Network General Sniffer kann man sich sehr komfortabel Darstellung zu Top Talkern und Verkehrsbeziehungen anzeigen lassen.

Wenn man sich so einen Überblick verschafft hat, kan man gezielt beginnen die Daten zu filtern.

Filter

Nur mit Hilfe von Filtern kann man die interessanten Daten aus der Masse lösen. Mit planlosem Scrollen kann man höchstens einen Trace aus einem Testnetz ohne Traffic auswerten. Typische Aufzeichnungen aus Produktionsnetzen haben innerhalb weniger Minuten viele Tausend Frames. Da hilft nur gezieltes Filtern.

Capturefilter

Capturefilter entscheiden welche Frames in einem Trace aufgezeichnet werden. Sie sollte man nur einsetzen, wenn man sich vollkommen sicher ist welche Frames man benötigt.

Gerade beim Filter auf bestimmte Adressen sollte man sehr vorsichtig sein. Oft werden hier die Broadcastframes und Multicastframes übersehen.

Ähnlich vorsichtig sollte man beim Verkürzen (Slicing, Limit) der Packete bei der Aufzeichnung sein. Dadurch erhält man zwar einen kleineren Trace, aber oft braucht man dann gerade die Bytes zur Auswertung, die man nicht mehr aufgezeichnet hat.

TIP: Beim Network General Sniffer sollte man trotzdem alle Filter als Capturefilter anlegen. Denn nur Capturefilter lassen sich sowohl als Capture- und Displayfilter einsetzen. Man kann ja weiterhin ohne aktiven Filter aufzeichnen.

Displayfilter

Displayfilter sind sicher das beliebteste Mittel zur Auswertung von Traces. Dabei unerscheidet man zwei Vorgehensweisen: Positiv- und Negativlisten.

Bei ersterem sucht man gezielt nach bestimmten Frames (z.B. ICMP). Bei der Negativliste filtert man nach und nach den uninteressanten Traffic raus. So kann man beispielsweise BPDU rausfiltern wenn man kein Spanning Tree-Problem sucht und so ein Protokoll nach dem anderen ausschließen.

Am Anfang sollte man auf jeden Fall stufenweise vorgehen und nicht versuchen einen Megafilter zu konstruieren der alle Probleme auf einen Schlag löst.

Tip: Beim Network General Sniffer auf keinen Fall den Default Filter modifizieren, sondern immer eigene Filter (Profile) erstellen. Denn spätestens nach einer Woche erinnert man sich nicht mehr an den veränderten Default Filter und sucht dann die fehlenden Frames.

Es gibt einige typische Filter die man parat haben sollte. In der folgenden Liste ist jeweils der Filtersyntax für Wireshark angegeben.

Layer 2 Broadcast – eth.dst == ff:ff:ff:ff:ff:ff

Einfach ansehen.

Spanning Tree Topology Change Notifications (TCN) - stp.type == 0x80

TCN sollten in einem stabilen LAN eigentlich nicht zu sehen sein.

DHCP und ARP – bootp or arp

Bei DHCP und ARP kann man leider nicht speziell auf Fehler filtern. Auffällig sind viele DHCP Discover oder DHCP Requests ohne Antworten von DHCP-Servern. Nachdem ein Host eine IP-Adresse bekommen hat, sollte er mittels ARP-Request auf seine eigene Adresse deren Eindeutigkeit überprüfen.

Tip: Durch diese ARP-Requests auf die eigene Adresse beim Booten eines IP-Hosts kann man sehr leicht die IP-Adresse eines Gerätes ermitteln. Das ist beispielsweise interessant bei Printboxen, Switchen oder Routern die sich nur via IP konfigurieren lassen, aber man deren aktuelle Adresse man nicht (mehr) kennt.

ICMP - icmp.type != 0 and icmp.type != 8

ICMP wird zur Signalisierung von Fehlersituationen eingesetzt. Ein Filter auf alle ICMP-Frames bringt oft interessante Erkenntnisse. Der gezeigte Filter blendet vom Ping erzeugte Packete aus.

TFTP - tftp.opcode == 5

TFTP signalisiert Fehler mit dem Opcode 5. Die Fehlerursache steht dann im Errorcode.

TCP Syn – tcp.flags.syn == 1

Segmente mit gesetztem SNY-Bit markieren den Versuch eines Sessionaufbaus. In den SYN-Segmenten tauschen die Partner auch die MSS aus.

TCP Reset – tcp.flags.reset == 1

Ein gesetztes Reset-Bit deutet auf Verbindungsversuche auf nicht geöffnete Ports hin.

TCP Duplickate ACKs - tcp.analysis.duplicate_ack
TCP Retransmission - tcp.analysis.retransmission

Duplicate Acknowledgements sind ein Anzeichen für einen Packetverlust und sollen beim Sender zu einer Fast Retransmission führen. Einige Retransmissions während einer Übertragung sind normal.

DNS/Wins - dns.flags.rcode != 0 und
nbns.flags.rcode != 0

Nicht aufgelöste Hostnamen führen in der Regel zu Problemen. Ein Filter auf „Name Error“ sollte man ruhig `mal auf den Trace legen. Hier tauchen dann auch alle Installationen von Spyware in internen Netzen auf, da sie ihre Hosts nicht auflösen können.

HTTP - http.response and ((http[9:1] == 34) or (http[9:1] == 35))

Webserver melden Probleme mit einem HTTP-Statuscode ab 400.

FTP - ftp.response.code >= 400

Response Codes ab 400 deuten auf Probleme beim FTP hin.

SMB - smb.nt_status != 0x0

Typische Probleme im Windowsumfeld sind Zugriffe auf nicht vorhandene Shares und Files und Zugriffe ohne ausreichende Rechte. Diese Situationen kan man recht gut aus SMB-Frames filtern.

Novell NDS - ncp.ndsreplyerror != 0x0

NDS sollte im Normalfall eine Null zurückgeben.

Novell NCP - ncp.completion_code != 0x0

Das Netware Core Protocol gibt bei Erfolg eine Null zurück. Completition Codes ungleich Null zeigen Fehler, wie z.B. unzureichende Rechte, an.

Tip: Im Ethereal lassen sich sehr einfach Filter erstellen. Im Decode auf das zu untersuchenden Protokollfeld mit der rechten Maustaste klicken und dann im Menü „Match“ oder „Prepare“ die gewünschte Option auswählen.

Mit einem Displayfilter sieht man natürlich nur noch die selektierten Frames. Das eigentlich interessante Umfeld ist verschwunden. Da hilft dann nur noch zwischen dem gefiltertem und dem vollständigen View zu springen.

In Ethereal gibt es die Möglichkeit durch Filter bestimmte Frames im Trace farbig hervorzuheben. Damit kann man dann sehr gut das Umfeld der entsprechenden Frames analysieren. In einigen Decodes kann man über das Feld „Response to“ sehr gut den Auslöser für einen Fehler lokalisieren.

Offline filtern mit tethereal

Bei sehr großen Datenmengen ist es recht praktisch die Daten vor dem eigentlichen Auswerten grob zu filtern.

Mit tethereal könnte das so aussehen:

tethereal -r bigtrace.cap -w out_tns.cap -R 'tns'

Das Kommando liest die Datei bigtrace.cap und filtert mit dem Ausdruck „tns“. Als Filterausdruck kann jeder gültige Displayfilter angegeben werden. Die Treffer werden in die Datei out_tns.cap geschrieben.

Mit dem Kommando

tethereal -r server-baseline.pcap -R 'tcp.analysis.retransmission'

bekommt man beispielsweise alle TCP-Retransmissions im Tracefile „server-baseline.pcap“ angezeigt. Lesen Sie auch das Tutorial Langzeitaufzeichnungen mit tethereal.

Auch tcpdump bietet entsprechenden Möglichkeiten, um große Datenmengen von der Kommandozeile aus vorzuselektieren.

Die TCP-Tools von Ethereal

Die Auswertung von Problemen mit TCP-Verbindungen gerät mit einem normalen Analyser leicht zum Geduldsspiel. Die Übertragungsrate kann man nur für die komplette Verbindung bestimmen. Zeitweise Einbrüche der Performance erkennt man nicht, Retransmissions erkennt man nur als Einzelereignisse, Probleme mit der Window Size sind nur schwer zu finden.

Ethereal bietet eine Reihe von Tool zu Analyse von TCP-Verbindungen. Man findet sie im Tools-Menü unter dem Punkt TCP Stream Analysis.

Wir wollen uns den Verlauf einer Dateiübertragung genauer ansehen. In den folgenden Beispielen sieht man auf der linken Seite jeweils eine problemlose Kommunikation und auf der rechten Seite eine Problemsituation.

Time-Sequence Graph (Stevens)

Dieser Graph bildet den Verlauf der Sequencenummer über die Zeit ab. Man kann also sehr gut die übertragenen Bytes pro Zeiteinheit ablesen. Aus einer Veränderung des Anstiegswinkel lässt sich eine veränderte Übertragungsrate ableiten.

So sollte es aussehen. Die Sequencenummer steigt linear an und es gibt keine Aussetzer. Pro Zeiteinheit wird also immer die gleiche Datenmenge übertragen.
Mit der Leertaste kann man übrigens ein Fadenkreuz aktivieren.


Hier gibt es gleich mehrere Symptome. An Position 1 gibt es eine Unterbrechung von ca. 20 Sekunden. Hier steigt die Sequencenummer nicht an.

Ab der Sekunde 100 (Position 2) wird der Anstieg des Graphen deutlich flacher. Die Übertragungsrate der Verbindung bricht ein. An der Position 3 ab Sekunde 180 gibt es dann weitere Aussetzer und die Übertragungsrate sinkt noch weiter.

Time-Sequence Graph (Stevens) gezoomt

In der gezoomten Darstellung werden manche Probleme erst richtig sichtbar.

Mit der mittleren Maustaste kann in die Grafik hinein gezoomt werden. Auch in dieser Darstellung sollte ein linearer Anstieg zu erkennen sein.


Hier erkennt man in der gezoomten Ansicht ganz deutlich ein Treppenmuster. Nach jedem Datenblock folgt eine Wartezeit ohne Datenübertragung. Auslöser kann entweder eine zu kleine TCP-Windowsize sein oder der Einsatz eines Stop-and-Wait-Protokols wie CIFS/SMB.

Throughput Graph

Dieses Diagramm zeigt die Übertragungsrate über die Zeit an.

So sieht eine typische Übertragung über das Internet aus.


Hier finden wir die Probleme aus dem ersten Bild wieder. Die Übertragung bricht immer wieder ab und die Performance sinkt zum Ende hin.

Round Trip Time Graph

Typisches Bild beim Kopieren einer Datei. Die RTT pendelt zwischen 20 ms und 40 ms.

Hier wurde durch einige Peaks die Skalierung etwas unglücklich gewählt. Zum Ende hin steigt die RTT deutlich an.


Die gezeigten Auswertungen eigenen sich nur für die kontinuierliche Übertragung von Daten. Bei interaktiven Anwendendungen wie Telnet sind die Grafen nicht sehr hilfreich.

Filtern auf TCP.Analysis im Ethereal

Ethereal bietet eine Reihe von Funktionen zur Analyse von TCP-Sessions. Um diese zu nutzen ist unter Edit/Preferences/Protocols/TCP die Option „Analyze TCP sequence numbers“ zu aktivieren. Dann kann man folgende Ausdrücke zum Filtern und Colorieren einsetzen:

Ausdruck

Was wird untersucht

tcp.flags.[name des flags]== 1

Prüfung auf einzelne Flags im TCP-Header

tcp.analysis.duplicate_ack

Doppelte Acknowledgements

tcp.analysis.retransmission

Wiederholte Übertragung von Daten

tcp.analysis.ack_rtt > 0.2

Zeit bis zum ACK, der Wert wird in Sekunden angegeben

 

Network General Sniffer Visual Filter

Im Sniffer gibt es einen sehr informative Matrix-Darstellung der Verkehrsbeziehungen.

Screenshot vom Sniffer

Sniffer Visual Filter

In dieser Darstellung kann man durch Anklicken der Adressen (mit gedrückter STRG-Taste) und Auswahl des „Visual Filter“-Icons sehr einfach einen Filter auf die Adressen legen. Das ist gerade für ad-hoc-Auswertungen sehr nützlich.

 

<-- Tools Inhalt Typische Probleme Teil 1 -->

 

 
© 2004-2023, network lab - we make your net work - Netzwerkforum
aktualisiert am 22.03.2012