Wireshark

Über Wireshark (www.Wireshark.com) muss eigentlich nicht mehr viel gesagt werden. Wer bisher schon einzelner Pakete auf dem Netzwerk mitschneiden wollte, konnte dazu den Microsoft Netzwerkmonitor (Siehe NetMon) nutzen. Dieser ist als "Lite-Version" bei jedem Windows Server dabei und kann einfach über die Systemsteuerung als Netzwerkkomponente nachinstalliert werden. Leider ist diese Version derart beschränkt, dass er nur all die Pakete mitschneiden kann, die direkt das System betroffen haben. Paket zwischen zwei anderen Stationen können Sie nicht mitschneiden. Erst die "Vollversion" aus SMS kann auch andere Pakete mitschneiden, sofern ihnen nicht VLAN's oder ein Switch den Weg verbaut.

Netmon ist ein sehr leistungsfähiges und robustes Programm, welches ich generell auf allen Servern schon mal installiere. Aber zur Auswertung von solchen Mitschnitten ist Netmon in der "Liteversion" nur bedingt zu benutzen. Aber hier hilft Wireshark weiter. Ethereal kann ergänzend zu NetMon 3:

  • NetMon Trace-Dateien lesen
    Zusätzlich kann Wireshark auch TCPDUMP, Novell Lanalyser Sniffer und andere Dateien lesen.
  • Frames abhängig von Regeln farblich markieren
    Die Farbcodierungen können abgespeichert werden.
  • Viel mehr Protokolle analysieren und decodieren
    Dazu gehört auch die Analyse von RPC-Aufrufen bis zu MAPI!
  • Zusammengehörige Pakete am Stück anzeigen
    Genial um aus den einzelnen Paketen einer SMTP oder POP3-Verbindung die Nutzdaten zu extrahieren
  • Grafisch die Antwortzeiten von Verbindungen aufbereiten
  • Und vieles weitere mehr

Wer heute schon CAP-Dateien mit Netmon mitschneidet, sollte sich Wireshark auf jeden Fall herunterladen und genauer betrachten. Natürlich können Sie auch direkt mit Wireshark und dem Packettreiber für Windows WINPCAP Pakete mitschneiden. Allerdings wird nicht jeder WINPCAP auf produktiven Servern installieren wollen. Aber dies ist auch nicht notwendig.

GUI und Bedienung

Als Windows Administrator werden Sie Wireshark anfangs nicht sympathisch finden. Dies liegt primär sicher an der anderen grafischen Oberfläche, die sich eher an einer X.11-GuI orientiert. Die Bedienung ist aber problemlos möglich.

Nachdem Sie Daten mitgeschnitten oder eine geeignete Datei geöffnet haben, sehen Sie die decodierten Pakete.

Beispiel einer SMTP-Übertragung

Wenn Sie z.B.: eine SMTP-Übertragung mitschneiden, können Sie einfach ein Paket anklicken und "Follow TCP-Stream" machen um den Inhalt zu sehen. (Die Inhalte sind unkenntlich gemacht)

Obwohl die Kommunikation über mehrere Pakete verteilt ist, kopiert Wireshark die Nutzdaten brauchbar zusammen. Das gleiche funktioniert natürlich auch für POP3, IMAP4 und viele andere Protokolle. Spätestens jetzt sollten Sie erkennen, wie leicht es für Angreifer sein kann, Klartextkennworte zu erhalten.

Farbcodierungen

Auch damit ich meine Arbeit einfacher und schneller erledigen kann, habe ich mir ein einfaches Farbschemata angelegt:

Sie können dieses Template color herunterladen, im Wireshark Programmverzeichnis speichern und einbinden. Alternativ können Sie einfach diese Einstellungen in eine Textdatei kopieren.

# DO NOT EDIT THIS FILE! It was created by Wireshark
@TCP Basics@arp or icmp or rip or ospf@[65535,27524,27524][0,0,0]
@DNS-WINS-NTP@dns or (tcp.port == 42) or ntp or nbns@[43655,36682,65534][0,0,0]
@AD-Traffic@(tcp.port == 389) or (tcp.port == 3268) or (tcp.port == 636) or (tcp.port == 3269) or (tcp.port == 88)@[65534,53904,53082][0,0,0]
@VPN@(tcp.port==1723) or gre or ( udp.port == 500) or (ip.proto == 50) or ( ip.proto == 51)@[496,496,496][53485,55106,55106]
@InternetMail@nntp or smtp or pop or imap@[65533,65142,0][0,0,0]
@Exchange@mapi@[65535,65535,0][0,0,0]
@Surfen@http or ftp or (tcp.port==8080) or (tcp.port==8080) or (tcp.port==3128) or (tcp.port==443) @[5392,65532,6243][0,0,0]
@Filesharing@smb or ncp or nfs or nbss or (tcp.port == 445)@[44400,65534,40174][0,0,0]
@Terminal@x11 or telnet or ssh or (tcp.port==1494) or (tcp.port==3389)@[8638,65534,63637][0,0,0]
@IM@aim or icq @[54612,54612,54612][0,0,0]
@name@filter@[65535,65535,65535][0,0,0]
@SQL@(tcp.port == 1433)@[7952,13574,65534][0,0,0]

Bitte haben Sie Verständnis dafür, dass ich hier keine vollständige Abhandlung von Wireshark und dem Lesen von Netzwerktraces geben kann. Nur sollten Sie wissen, wenn Sie auf ihren Server per POP3, OWA, OMA oder andere unsicherer Verfahren zugreifen, dann kann mit solch einem Programm die Nachricht und das Kennwort mitgelesen werden.

Wireshark und SSL

Wireshark kann wie NETMON auch SSL-verschlüsselte Verbindungen mitschneiden und wenn man den privaten Schlüssel z. B. des Webservers vorliegen hat, kann Wireshark die Daten sogar decodieren.

Wichtiges Update:
Seit Wireshark 1.10 (?) kann er direkt PFX-Dateien einlesen und den SSL-Datenstrom decodieren.
Edit - Preferences - Protocol - SSL - Add RSA-Key

Den privaten Schlüssel eines Windows Webservers erhält man am einfachsten indem man:

  1. Zertifikat als PFX-Datei exportieren
  2. PFX-Datei mit OpenSSL in eine PEM-Datei konvertieren
  3. PEM-Datei mit Notepad bearbeiten, dass nur der private Key enthalten ist
  4. PEM-Datei- in Wireshark einbinden

Die Konvertierung der PFX-Datei mit OpenSSL in eine PEM-Datei kann man sich sparen und in der GuI ist dieser alte Weg mittlerweile auch abgekündigt:

Hier die Links zu Seiten, die das ausführlicher und aktueller beschreiben.

Wireshark und WiFi

Normalerweise kann man mit Wireshark und anderen Tools nur Netzwerkkarten nutzen, die den "Promiscuous Mode" unterstützen. Das ist bei WiFi nicht so einfach, da ein normaler Clients sich mit einem AccessPoint verbindet und damit nur einen Teil der Frequenzen nutze. Andere Kommunikation bleibt ungesehen. Auch kann es sein, dass ein Teilnehmer quasi "auf der anderen" Seite des AP steht und Sie daher vielleicht die Pakete vom AP zum Teilnehmer aber nicht mehr dessen Pakete zum AP sehen können.

Es gibt kommerzielle Adapter, die auch im WiFi mitschneiden können, aber diese sind dann doch sehr teuer. Ich nutze dann lieber zwei APs oder einen Switch und schneide dort mir, was ein bestimmter Client dann ins "Drahtgebundene LAN" sendet. Natürlich entgeht mir damit der Verkehr zwischen WLAN-Geräten untereinander. Vielleicht haben Sie ja aber Glück und ihre WLAN-Adapter unterstützt den "Promiscuous Mode".

Ansonsten können Sie es immer noch mit NetMon 3 versuchen.

WiFi und Offloading

Wireshark kann über die NPCAP-Schnittstelle nur auf dem Netzwerktreiber aufsetzen. Er lauscht vereinfacht also zwischen Netzwerktreiber und Protokoll-Stack mit. Wireshark kann daher nicht genau erkennen, was nun real über das Kabel geht. Wenn Sie nun die Eigenschaften einer modernen Netzwerkkarte anschauen, dann sehen Sie schon die verschiedenen Optimierungen, mit denen der kleine Computer auf dem Ethernet-Chip dem Hauptrechner die Arbeit abnehmen kann.

Am Beispiel meiner Intel-Netzwerkkarte im Notebook habe ich exemplarisch ein paar Einstellungen beschrieben:

  • Large Send Offload V2
    Auf einem Ethernet können normal nur 1514 Byte große Pakete übertragen werden (Siehe auch Maximum Transmission Unit (MTU)). Größere Pakete müssen aufgeteilt werden. Bei TCP/IP macht das normal der Protokollstack (Siehe IP Fragmentation). Diese Funktion kann aber auch der Netzwerktreiber machen.
  • TCP Checksum Offload/UDP Checksum Offload
    Wenn auch diese Prüfung und ggfls. Neuanforderung nicht vom TCP/IP-Stack sondern schon auf der Netzwerkkarte durchgeführt wird, dann sehen Sie in Wireshark natürlich weder die Ergebnisse der CRC-Prüfung noch die Retransmits

Auch die anderen Einstellungen wie "IPv4 Checksum Offload" oder "Protocol ARP Offload" etc. verhindern, dass Wireshark die echten Daten sieht. Bei einer generellen Protokollanalyse ist dies nicht weiter kritisch aber wenn Sie Paketverlusten, schlechten Kabeln oder Verbindungen nachspüren, dann stört dies Optimierung. Auch in virtuellen Maschinen (VMs) gibt es entsprechende optimierte Treiber, mit der der Protokoll-Stack den Datenstrom schnell zur realen Netzwerkkarte durchreichen kann, die sich dann um Prüfsummen etc. kümmert.

Weitere Links