Was Sie schon immer über das Innenleben Ihres Netzwerks wissen wollten, Ethereal bringt es ans Licht. Der Sniffer belauscht jeden Dialog im Netz und serviert ihn auf dem Präsentierteller.

Onkel Alfred hat eben keine Kinderstube, meint Tante Berta. Ihr Geburtstagspäckchen hat er erhalten, bedankt hat er sich nicht. Auf den Paketdienst kann er sich jedenfalls nicht herausreden: Denn dank Internet kann Berta den Weg des Päckchens auf http://privatpaketservice.hlg.de en Detail mitverfolgen. Das Internet selbst – auch eine Art Paketdienst, nämlich für Informationen – bietet für seine eigenen Sendungen, die Datenpakete, einen solchen Service leider nicht.

Macht aber nichts. Denn oft kann man sich selber helfen und den Datentransporteuren über die Schulter schauen, wenn man den Verdacht hegt, dass sie etwas verschusseln. Tools, die sich dafür eignen, heißen Netzwerk-Sniffer. Ethereal, das vielen Linux-Distributionen (beispielsweise auch Suse) beiliegt, ist ein ein talentierter Vertreter dieser Gattung. Es saugt eine einstellbare Zeit lang alle Daten vom einem Netzwerk-Interface ab, filtert die interessanten heraus und verwandelt deren Binärformat in eine leicht lesbare und anschauliche Darstellung.

Bis dahin läuft alles automatisch ab. Danach aber braucht es den Nutzer, der die Fundstücke begutachtet und aus ihnen zu lesen versucht, was die Ursache für Anwendungsprobleme in den oberen Etagen des Netzwerk-Stacks sein mag. Dafür reicht manchmal der gesunde Menschenverstand; oft braucht man Grundkenntnisse, nicht selten aber auch Fachwissen der Netzwerktechnik. Dieser Beitrag illustriert an einem einfachen Beispiel den Umgang mit dem Daten-Spürhund.

Streiken die Postler?

Kein Schwein ruft an – und schlimmer noch: Es schickt nicht mal einer E-Mails. Vielleicht streiken aber auch bloß die virtuellen Postbeamten? Möglicherweise weigert sich ja bereits der eigene Mail-Client, nach der Post zu sehen? Den könnte man eventuell durch Konfigurieren wieder auf die richtige Spur bringen – oder ihm notfalls verdeutlichen, dass jeder ersetzbar ist. Vielleicht aber müht sich der Mailer redlich und erreicht nur das nächste Postamt nicht. Ist die Adresse falsch, unter der er es sucht? Oder er schafft es bis zur Post, erhält die Korrespondenz aber nicht ausgehändigt, weil er sich nicht ausweisen kann. Oder das Problem ist doch ein soziales und kein technisches, das Fach also wirklich leer?

Das alles lässt sich mit Ethereal ziemlich einfach aufklären, wenn man den Datenverkehr unter die Lupe nimmt. Freilich hieße es mit Kanonen auf Spatzen zu schießen, brächte man bei einem solchen Problem immer sofort einen Sniffer in Stellung. Hier wären die Fehlermeldungen und das Log des Clients, ein Ping auf den Server oder ein Test via Telnet die erste Wahl. Dieser Beitrag überspringt diese Schritte.

Die erste Überlegung gilt dann der richtigen Zapfstelle. In einem geshareten LAN, dessen Teilnehmer untereinander über ein Hub verbunden sind, ist die Frage gegenstandslos: Jeder Teilnehmer kann hier auch die Pakete einfangen, die eigentlich für seine Nachbarn bestimmt sind. Dafür muss er nur sein Netzwerk-Interface in den so genannten Promiscuous Mode versetzen.

Anders in einem geswitchten LAN, in dem zwischen den Rechnern virtuelle Exklusivverbindungen geschaltet werden. Hier gibt es mehrere Möglichkeiten: Größere Switche haben oft einen speziellen Monitor-Port, der wie der Port eines Hub funktioniert. Gibt es den, verbindet man ihn mit dem Rechner, auf dem die Netzwerk-Analysesoftware läuft. Sogar bestimmte Hackertechniken wären prinzipiell verwendbar – etwa Man-in-the-Middle oder das erzwungene Umschalten des Switch auf Hub-Funktion mittels MAC-Flooding.

Wenn aber einer der Kommunikationspartner unerreichbar in den Fernen des Internet residiert, helfen selbst diese Tricks nicht weiter. Es bleibt aber eine Möglichkeit, die noch dazu sehr einfach ist: Ethereal muss auf einem der Endpunkte der Verbindung laufen und dort den Dialog mitschneiden.

Scharf machen

Im Beispiel startet der Daten-Detektiv dazu das Sniffer-Programm parallel zum Mail-Client, und zwar als Root-User. Dessen Rechte benötigt die Software, um eine spezielle Schnittstelle zum Netzwerk einzurichten, einen so genannten Raw Socket, über den sie Pakete sammelt und eventuell auch verschickt. Nach erfolgreicher Initialisierung und einem kurzen Splash-Screen erscheint das Hauptfenster.

Abbildung 1: Hier lassen sich alle Optionen für das Datensammeln an einer Stelle konfigurieren. Flexible Filter sorgen dafür, dass nur die guten Pakete ins Körbchen wandern.

Danach wählen Sie aus dem Hauptmenü CaptureStart. Es erscheint ein Fenster für Voreinstellungen wie in Abbildung 1. In diesem Fenster stellen Sie ganz oben zunächst das Interface ein, das Pakete sammeln soll. Im Bild ist es die erste Ethernet-Karte eth0. Mit anderer Hardware könnte die Schnittstelle aber beispielsweise auch ppp0 oder wlan0 heißen. Außerdem ist ein Pseudo-Interface wählbar, das sich Pakete auf allen verfügbaren Netzwerkschnittstellen gleichzeitig greift.

Mit der Checkbox unter den Interface-Einstellungen lässt sich der schon erwähnte Promiscuous Mode aktivieren. Die Option Limit each packet beugt dem Überlaufen der Festplatte vor, indem von jedem Paket nur ein Teil gespeichert wird. Darauf folgt eine Eingabezeile für eine weitere sehr wichtige Einstellung, die Capture-Filter.

Gesichtskontrolle

Hinter den Capture-Filtern verbergen sich Datensiebe, die unmittelbar beim Sammeln wirken. Das unterscheidet sie von den ebenfalls verfügbaren Display-Filtern, die Pakete, die bereits ins Netz gegangen sind, lediglich von der Anzeige ausschließen. Dummerweise verwenden beide Filter eine unterschiedliche Syntax, was die Bedienfreundlichkeit nicht eben steigert.

Die Capture-Filter schränken Ethereals Sammelwut in jedem Fall ein – ohne Filter kommt jedes Paket ins Körbchen. Wer einen Filterausdruck konstruiert, kann dafür drei Gruppen von Schlüsselwörtern (Qualifier) verwenden: Typen, Richtungen und Protokolle.

Mögliche Typen sind host, net und port. Mit ihnen lassen sich Ausdrücke bilden, die nur Pakete durchlassen, die zu bestimmten Netzen, Rechnern oder Diensten gehören. So bewirkt im Beispiel host kirk and port 110, dass nur solche Daten eingefangen werden, die an den E-Mail-Dienst (POP3, Port 110) auf dem Rechner kirk gerichtet sind oder von ihm ausgehen.

Die gewünschte Richtung des Datenverkehrs kann mit den Ausdrücken dst für Destination (Ziel) oder src für Source (Quelle) vorgegeben werden. Der Ausdruck src my.mailserver.de etwa würde nur Pakete passieren lassen, die vom Mailserver stammen, nicht aber solche, die an ihn gerichtet sind.

Schließlich kann man den Suchraum noch weiter einschränken, indem man auch ein bestimmtes Protokoll verlangt. Dafür dient der Qualifier proto, dessen Parameter einen der folgenden Werte annehmen kann: ether, fddi, tr, wlan, ip, ip6, arp, rarp, decnet, tcp oder udp.

Die Schlüsselwörter lassen sich mittels and, or oder not kombinieren. Auf die Paketgröße kann man sich mit less oder greater beziehen. Darüber hinaus gibt es noch ein paar Feinheiten mehr, die sich bei Bedarf anwenden lassen. Eine ausführliche Darstellung der Filter-Syntax bietet die Manpage des ebenfalls häufig installierten Kommandozeilen-Sniffers Tcpdump, der auf dieselbe Capture-Bibliothek (Libpcap) wie Ethereal zurückgreift.

Abbildung 2: Nach dem Start läuft ein Paketezähler, der online auch eine erste Übersicht über die gefundenen Protokolle bietet. Sehr ausführliche Statistiken bietet offline das gleichnamige Menü.

Das Netz auswerfen

Ist alles präpariert, können Sie das Datensammeln starten. Anschließend lassen Sie den Mail-Client nach der Post sehen und halten dann das Capturing wieder an. Das Hauptfenster sieht nun so ähnlich aus wie in Abbildung 3. Im oberen Teil findet sich eine nummerierte Liste der gesammelten Pakete. Das Paket, das aktuell inspiziert wird (hier Nr. 4) ist blau hinterlegt. Seine Innereien werden in den folgenden beiden Fensterdritteln seziert.

So findet sich ganz unten eine ASCII-Darstellung des kompletten Pakets, in der man besonders Text sehr schnell erkennt, der eventuell in der Nutzlast enthalten ist. Die Header studiert man dagegen bequemer in der Darstellung des mittleren Fensterteils, die schematisch die ineinander verschachtelten Elemente des Päckchens zeigt. Auf diese Ansicht kann sich allerdings nur einen Reim machen, wer sich ein ganz klein wenig in der Theorie auskennt.

Abbildung 3: Der Fang unter der Lupe: Gesammelte Datenpakete einerPOP3-Verbindung.

Daten-Matroschkas

Für ihre Reise durch das Netz kleiden sich die Pakete nach dem Zwiebelprinzip. Die eigentliche Nachricht ist in mehrere Lagen Protokollinformationen eingewickelt. Das kommt – etwas vereinfacht – so: Der Mail-Client, der der Anwendungsschicht (Abbildung 4) zuzurechnen ist, generiert eine Anfrage an den Mailserver nach den Regeln des POP3-Protokolls.

Diese Nachricht übergibt er dem Kernel zum Versand. So gelangt sie in den Netzwerk-Stack und in ein TCP-Paket, auf dem die Adresse des gewünschten Dienstes auf dem Zielrechner steht. In diesem Fall also: Zielport 110. Außerdem enthält das Etikett des TCP-Pakets eine so genannte Sequenznummer, die es dem Empfänger ermöglicht, eintreffende Pakete der Reihe nach zu ordnen, falls sie unterwegs durcheinander geraten sind. Andere Markierungen (Flags) kennzeichnen beispielsweise den Status oder die Dringlichkeit. Ist alles ausgefüllt, wird das Paket nach unten weitergereicht.

So erreicht es die Internet-Schicht, die das TCP-Paket in ein IP-Datagramm verpackt, das als Anschrift die IP-Adresse des Mailservers trägt. Das ist die Voraussetzung dafür, dass die Daten, ihren Weg durch das Internet finden und alle Zwischenstationen das Paket wieder in die richtige Richtung weiter schicken (routen) können. Die Vermittlungsrechner, auf die es unterwegs trifft, entpacken nämlich nicht an sie selbst adressierte Pakete wieder solange, bis sie auf die IP-Adresse stoßen. Anhand dieser Adresse ermitteln sie Zielnetzwerk und weitere Reiseroute.

Die IP-Adresse markiert sozusagen das strategische Ziel der Reise, das nächste Etappenziel dagegen wird über eine physikalische Adresse angesteuert, eine 48 Bit lange Nummer, die fest zu einem angepeilten Netzwerkadapter des Zielrechners gehört. Dieses Interface muss sich immer in demselben Netz befinden wie der Startort der Etappe, nur Router, die mit mehreren Netzen verbunden sind, erlauben den Paketen in ihrem Innern den Adapter und damit das Netz zu wechseln. Die Netzzugangsschicht ermittelt anhand der IP-Adresse mit Hilfe einer ARP-Anfrage die zugehörige Ethernet-Adresse, packt das IP-Datagramm in einen Ethernet-Frame, notiert darauf die Ethernet-Adresse und schickt ihn über das Netzwerkkabel auf die Reise.

Abbildung 4: Das Modell eines Netzwerkstacks. Alle Pakete durchlaufen von der Anwendung zum Kabel und zurück diese Schichten.

Am Ziel angekommen nimmt das Paket den umgekehrten Weg durch den Stack: Der Frame gelangt vom Kabel in die Netzzungangsschicht, die das IP-Datagramm auspackt und nach oben in die Internet-Schicht weiterreicht. Die entnimmt das TCP-Paket und gibt es an die End-zu-End-Schicht weiter. Dort wird die POP3-Nachricht extrahiert und dem Mailserver in der Anwendungsschicht zugestellt.

Jede der Protokoll-Schalen um den eigentlichen Nachrichtenkern stellt Ethereal im mittleren Teil des Hauptfensters als aufklappbare Liste sehr übersichtlich dar. Ein häufiger Fehler, den man hier entdecken kann, wäre etwa eine falsche IP-Adresse, die durch eine fehlerhafte Konfiguration auf das Paket gelangt sein kann. In diesem Fall landet es entweder nirgendwo oder bei einem Rechner, der damit nichts anzufangen weiß und es auf einer Müllhalde des Internet entsorgt.

Klartext

Unser Beispielpaket enthält offenbar nur einen kleinen Ausschnitt der Kommunikation zwischen Mail-Client und -Server. Ein Weg, die gesamte Unterhaltung mitzuverfolgen bestünde darin, jedes gesendete oder empfangene Paket unseres Beispiels anzuklicken und der Ascii-Darstellung den enthaltenen Text zu entnehmen. Diese nicht besonders schöpferische Arbeit nimmt einem Ethereal allerdings dankenswerter Weise ab. Dazu markiert man das erste Paket und wählt dann AnalyzeFollow TCP Stream. Das Ergebnis zeigt Abb. 5: Der komplette Dialog, gut lesbar formatiert.

Bezogen auf unser Mailproblem wissen wir jetzt: Der Client trägt keine Schuld, er wird auftragsgemäß tätig. Auch hat er offenbar die richtigen Informationen und kann den Mailserver erreichen. Der kennt ihn als Benutzer und akzeptiert auch das übermittelte Passwort. Das Kommando LIST zeigt, dass der Herr des Postfachs gesellige Zeiten gekannt haben muss – mehr als dreieinhalbtausend Mails lagern dort. Wenn Alfred und Berta heute nicht mehr miteinander reden, hat es also zumindest keine technischen Gründe.

Abbildung 5: Die Unterhaltung mit dem Mailserver im Klartext: Ein Filter sammelt alle Texte des Stream.

Zahlensalat

Neben der gezeigten Analyse von Ascii-Protokollen, die in vielen anderen Fällen – etwa für SMTP, NTP oder HTTP – ähnlich ablaufen wird, sind oft auch die Statistiken interessant, die Ethereal aus den gesammelten Paketen generiert: Wer hat mit wem wie ausführlich gesprochen? Welche Datenmenge ist in welcher Richtung durch die Leitung gegangen? Welche Protokolle wurden in welchem Umfang benutzt? Die Antwort auf alle diese Fragen ist nur einen Klick in das Menu Statistik entfernt. Auch sehr spezielle Auswertungen werden dort angeboten – etwa TCP-Stream-Graphen – für deren sinnvolle Interpretation man aber eine gehörige Portion Fachwissen benötigt.

Ethereal ist ein sehr mächtiges Tool für die Netzwerkstatt, das tiefe Einblicke in das Räderwerk des Internet gewährt. Mit dem nötigen Know how lässt ein Netz-Dialog bis auf das letzte Bit verfolgen. Aber auch dem Netzwerk-Eleven ist Ethereal nützlich, und sei es nur dadurch, dass es die graue Theorie mit anschaulichen Beispielen illustriert.