1.9.3. Monitor-Funktion

Mit den in den vorhergehenden Abschnitten vorgestellten Diagnosehilfen (ping, netstat, ...) kann man schon viele interessante Informationen erhalten.

In manchen Fällen möchte man aber genau wissen, was auf einem Netz nun tatsächlich der Reihe nach abläuft. Dazu gibt es sogenannte Protokollanalysatoren, die man z.B. an ein Ethernet anschließen kann. Der Verkehr auf dem Ethernet wird dann in einer möglichst nutzerfreundlichen Form angezeigt (d.h. nicht einfach als Hexadezimal-Dump, sondern entsprechend den Protokoll-Formaten):

Solche Geräte sind nicht billig. Daher werden wir hier mit einer Softwarelösung tcpdump arbeiten, die (fast) dasselbe kann. Man braucht auch keinen separaten Rechner dazu:

Ein Problem sollte Ihnen jetzt auffallen, wenn Sie sich an die Erläuterungen zur Ethernet-Technologie (Abschnitt "ARP") erinnern.

Normalerweise läßt die Ethernet-Hardware empfangsseitig nur Rahmen mit der eigenen Ethernetadresse als Ziel (und Broadcasts/Multicasts) durch. Bei fast allen Ethernet-Karten läßt sich aber ein anderer Betriebsmodus einstellen, bei dem alle Rahmen durchgelassen werden ("promiscuous mode"). Diese Betriebsart wird von tcpdump verwendet.

Das entspricht einem "Abhören" des Netzes und fällt deswegen unter "Computerkriminalität", wenn es unautorisiert geschieht. Führen Sie deshalb derartige Experimente nur innerhalb des dafür vorgesehenen Laboraufbaus durch!
Die Einstellung des "promiscuous mode" ist zwar unter Linux nur dem Superuser (root) möglich, aber diese Hürde ist bei einer "privaten" Workstation nicht so hoch (und bei MS Windows 3.x/95 nicht existent).
Das entsprechende Kommando hat folgenden Aufbau:
  tcpdump Optionen Filterausdruck
Häufig gebrauchte Optionen sind:
-i Interface
Nutzung des angegebenen Interface. Wenn diese Angabe fehlt, wird das erste Interface nach lo verwendet.
-n
Adressen, Portnummern usw. numerisch ausgeben. Das ist oft sinnvoll, weil DNS nicht da ist oder nicht benutzt werden soll.
-x
Paketinhalt zusätzlich zu den sonstigen Angaben über das Paket hexadezimal anzeigen. Leider ist keine Ausgabe in einer meist leichter lesbaren ASCII-Darstellung vorgesehen (wie dies z.B. bei dem im Kapitel 2 öfters verwendeten Werkzeug snoop unter Solaris 2.x der Fall ist).
Mit dem Filterausdruck kann man die Auswertung auf bestimmte Adressen oder Netzanwendungen einschränken, z.B.
  host 192.168.7.1   - nur Verkehr von und zu Rechner 192.168.7.1
  net 192.168.7      - nur Verkehr von und zu Netz 192.168.7
  port www           - nur www-Verkehr anzeigen
Zusätzlich kann auch die Richtung des Verkehrs mit dst (destination) und src (source) angegeben werden. Die Einschränkung auf bestimmte Protokolle ist ebenfalls möglich (ether, ip, arp, rarp, tcp, udp, ...). Verknüpfungen können mit and/or/not vorgenommen werden, z.B.
  dst port finger    - nur finger-Anfragen anzeigen
  ip or arp          - IP- und ARP-Protokoll anzeigen
  not tcp            - gibt es hier Nicht-TCP-Anwendungen?
Weitere Informationen enthält die umfangreiche Handbuchseite (man tcpdump).

In einem ersten Anwendungsbeispiel habe ich zwei Rechner durch eine serielle Leitung verbunden:

Auf beta wurde tcpdump gestartet (ohne Parameter).

Um etwas Netzverkehr zu erzeugen, baute ich jetzt von beta aus eine Telnet-Verbindung zu alfa auf:

  # telnet 192.168.7.2
In dem konkreten Fall dauerte es mehrere Minuten, bis sich der andere Rechner meldete, und ich wollte herausfinden, woran das lag.
Auch Experten neigen in einer solchen Situation schnell zu der Behauptung, daß der Rechner zu schwach, das Betriebssystem zu lahm oder das Netz überlastet seien und raten zu Neubeschaffungen (das hätte hier überhaupt nichts gebracht, wie wir gleich sehen werden).

Die tcpdump-Ausgabe sieht so aus:

  13:15:08.086072 192.168.7.1.1098 > 192.168.7.2.telnet: S 3399556255:3399556255(0) win 512 
  13:15:08.156073 192.168.7.2.telnet > 192.168.7.1.1098: S 3381682384:3381682384(0) ack 3399556256 win 14335 
  13:15:08.156073 192.168.7.1.1098 > 192.168.7.2.telnet: . ack 1 win 30639
  13:15:08.186074 192.168.7.1.1098 > 192.168.7.2.telnet: P 1:28(27) ack 1 win 30719
  13:15:08.246075 192.168.7.2.telnet > 192.168.7.1.1098: . ack 28 win 14308
  13:15:09.186091 192.168.7.2.1049 > 134.109.2.2.domain: 1+ (42)
  13:15:14.206175 192.168.7.2.1050 > 134.109.2.2.domain: 1+ (42)
  13:15:24.226343 192.168.7.2.1051 > 134.109.2.2.domain: 1+ (42)
  13:15:44.246678 192.168.7.2.1052 > 134.109.2.2.domain: 1+ (42)
  13:16:25.107363 192.168.7.2.1053 > 134.109.2.2.domain: 1+ (42)
  13:16:30.127447 192.168.7.2.1054 > 134.109.2.2.domain: 1+ (42)
  13:16:40.147615 192.168.7.2.1055 > 134.109.2.2.domain: 1+ (42)
  13:17:00.167951 192.168.7.2.1056 > 134.109.2.2.domain: 1+ (42)
  13:17:40.168621 192.168.7.2.telnet > 192.168.7.1.1098: P 1:4(3) ack 28 win 14308
  13:17:40.168621 192.168.7.1.1098 > 192.168.7.2.telnet: . ack 4 win 30716
  ...
Jedes Paket wird durch eine Zeile beschrieben. Die erste Spalte ist ein Zeitstempel, um auch zeitliche Relationen erkennen zu können.
Dann folgen Quelle und Ziel, wobei nach den IP-Adressen die Portnummer (bzw. der Name der Anwendung) angegeben sind.
Die weiteren Angaben beziehen sich auf die Transportschicht. Damit werden wir uns erst im Kapitel 2 beschäftigen.

Wir sehen in der ersten Zeile, daß ein Paket vom Telnet-Klienten auf Rechner 192.168.7.1, Port 1098 an den Telnet-Server auf 192.168.7.2 geschickt wird. Der Telnet-Server hat eine feste Portnummer, deshalb erscheint hier die symbolische Bezeichnung telnet.

In der 2. Zeile kommt eine Antwort. Dann werden noch einige Pakete ausgetauscht.

Das 6. Paket kommt von dem Rechner mit dem Telnet-Server. Die Portnummer 1049 deutet aber auf eine Klientenfunktion hin. Das Ziel ist der domain-Server auf dem Rechner 134.109.2.2, d.h. ein Nameserver.

Da dieses Experiment von der "Außenwelt" abgeschnitten war, kommt natürlich keine Antwort vom Nameserver. Wir sehen, daß der Rechner 192.168.7.2 im Verlaufe der nächsten drei Minuten 8 Versuche startet. Erst dann gibt er auf und fährt im normalen Telnet-Protokoll fort.

Bei der Suche nach der Ursache der minutenlangen Login-Verzögerung haben wir also eine "heiße Spur" gefunden. Zunächst müssen wir überlegen, was der Rechner 192.168.7.2 überhaupt von einem Nameserver will.
Der Telnet-Server möchte (wohl aus Höflichkeit ;-) den Klienten mit seinem Namen begrüßen (und in die Logfiles eintragen). Daher fragt er beim Nameserver an, welcher Name zur IP-Adresse 192.168.7.1 gehört.

Der Domain Name Service auf Rechner 192.168.7.2 ist offenbar falsch konfiguriert, denn er "kennt" den Nameserver 134.109.2.2, den es in dem aufgebauten Versuchgsnetz gar nicht gibt.
Wenn wir diesen Nameservereintrag entfernen, würde der Telnet-Server vermutlich nicht auf die Idee kommen, den Domain Name Service zu bemühen.

Schließlich gibt es noch eine Eigenart in der Konfigurierung von 192.168.7.2, die dazu führt, daß wir die Nameserver-Anfrage überhaupt in 192.168.7.1 sehen. Wahrscheinlich ist in 192.168.7.2 die default-Route auf die serielle Leitung eingestellt.
Alle Pakete gelangen daher nach 192.168.7.1, was sicher nicht besonders sinnvoll ist (in diesem Fall aber ein Vorteil, weil es uns zu einer schnellen Diagnose verhilft).


© Uwe Hübner, 27.3.98