Arbeitet das Netzwerk nicht wie gewünscht, ist eine Analyse ohne genaue Daten schwer. Wer die Netzflüsse überwacht, erkennt Trends im Netzwerk, spürt Würmer und Viren auf und kann Aussagen über die Nutzung der Bandbreite treffen, die einen künftigen Ausbau des Netzwerks erleichtern.

Viele Administratoren interessieren sich nicht für den Verkehr in ihrem Netzwerk – solange alles funktioniert. Erst wenn\’s klemmt, suchen sie händeringend nach Möglichkeiten, die Verbindungen zu analysieren. Meist scheitert das Ansinnen dann an fehlenden Vergleichsdaten. Welche Verbindungen sind normal, welcher Verkehr ist ungewöhnlich? Diese Fragen kann der Systemverwalter nur beantworten, wenn er Aufzeichnungen besitzt, die das Netzwerk im Normalzustand beschreiben.

Doch nicht nur im offensichtlichen Fehlerfall sind detaillierte Protokolle des Netzwerkverkehrs interessant: Sie helfen auch dabei, falsch konfigurierte Rechner zu finden, den Ausbruch von Würmern oder Viren frühzeitig zu erkennen und zu lokalisieren und nach einem Einbruch die Ereignisse zu analysieren.

Darum ist es sinnvoll, über Aufzeichnungen sämtlicher Verbindungen im Netzwerk zu verfügen. Einfaches Mitschreiben der Netzwerk-Rohdaten ist nicht vernünftig: Einerseits benötigen diese Informationen zu viel Speicherplatz, andererseits ist dieser hohe Detailgrad unnötig. In den meisten Fällen reicht es aus, die Netzflüsse aufzuzeichnen.

Netzflüsse

Ein Netzfluss ist ein IP-Datenstrom, jede TCP-Verbindung ist zum Beispiel ein solcher Fluss. Bei der Überwachung der Flüsse schreiben die meisten Systeme die IP-Adressen, das Protokoll, Ports und die ausgetauschte Datenmenge ins Log. Vorreiter dieser Technik ist der Netzwerkgeräte-Hersteller Cisco: Er hat bereits vor Jahren solche Funktionen in seine Hardware eingebaut. Cisco-Router exportieren die beobachteten Verbindungen per UDP als so genannte Netflows, die eine Vielzahl von Softwareprodukten, zum Beispiel Ntop ([1], [6]), importieren und analysieren können.

Weitere Router-Hersteller haben ihre Geräte mit kompatiblen Funktionen ausgestattet. Zusätzlich gibt es auch eine Reihe von Netflow-Probe-Programmen, die an Stelle von Cisco-Routern laufen, zum Beispiel auf einem Linux-Router. Sie erzeugen Cisco-kompatible Netflow-Aufzeichnungen, die der Administrator anschließend wiederum mit Ntop & Co. verarbeitet. Ntop analysiert dabei ausführlicher als zum Beispiel MRTG [7], das nicht einzelne Flüsse untersucht, sondern lediglich über SNMP den gesamten Datendurchsatz anzeigt. Um Trends zu erkennen, ist MRTG meist ausreichend. Um sie auszuwerten, sind Programme nötig, die die Flüsse anzeigen und analysieren.

Alternative Argus

Eine Alternative zu diesen Programmen ist Argus [2]. Es besteht aus zwei Komponenten: Ein Daemon ermittelt die Flüsse und schreibt sie in eine Datei. Mehrere Clients helfen dem Administrator dann, die Flüsse zu analysieren. Das von Argus eingesetzte Format ist zwar nicht kompatibel zu Ciscos Netflow, bietet dafür aber mehr Funktionen. Während Netflow für jede Verbindung zwei Flüsse (für jede Richtung) protokolliert, fasst Argus diese Informationen in einem Fluss zusammen.

Leider hat sich auch das Argus-Format in den letzten Jahren geändert. Für ältere Versionen (bis 2.0.5) gibt es den Converter Canine [3], der mehrere Formate beherrscht, aber leider noch nicht das Format der hier vorgestellten Argus-Version 3.0, die sich derzeit noch in der Entwicklung befindet. Das dürfte sich aber ändern, wenn die Final-Version von Argus 3 erscheint.

Einrichten und anpassen

Um das Tool zu verwenden, installiert der Administrator zunächst den Argus-Daemon auf den Systemen, welche die Netzwerkflüsse überwachen und protokollieren sollen. Die Einrichtung des Release Candidate von Argus 3.0.0 beginnt mit dem Download des Pakets, dem Entpacken und der Übersetzung mit dem bekannten Dreisatz »./configure«, »make«, »make install«. Danach kopiert der Admin die Konfigurationsdatei nach »/etc« und passt die Rechte an:

cp ./support/Config/argus.conf /etc/argus.conf
chmod 600 /etc/argus.conf

Die Anpassungen in der Konfigurationsdatei sind selbsterklärend. Für den Anfang genügt es, die Variable »ARGUS_OUTPUT_FILE« richtig zu setzen und das Kommentarzeichen zu entfernen. Die Argus-Clients holen sich die Daten über das Netzwerk direkt vom Daemon, wenn dieser den Port freigeschaltet hat. In der Konfigurationsdatei ist der Default-Port 561 bereits aktiviert.

Aus Sicherheitsgründen sollte der Administrator nach einem ersten Test einen eigenen Benutzer für den Daemon anlegen und in der Konfigurationsdatei die Option »ARGUS_SETUSER_ID« einstellen. Das Quelltextpaket enthält ein Startskript »./support/Startup/argus« für den Daemon, das Red-Hat- und Fedora-Core-Anwender nach »/etc/init.d/« kopieren und aktivieren, andere Distributionen unterstützt es leider nicht.

Archivierung

Gegen unkontrolliertes Wachstum der Protokolldateien hilft regelmäßige Rotation. In Testumgebungen fallen täglich 2 bis 5 MByte Daten an, während produktive Netzwerke schnell bis zu 100 MByte am Tag ins Log schreiben. Für die Rotation enthält das Quelltextarchiv in »./support/Archive« das Skript »argusarchive«. Ein passender Cron-Eintrag sieht wie folgt aus:

0 1 * * *  /usr/local/bin/argusarchive >> /var/log/argus/archive.log 2>&1

Vor dem ersten Aufruf sind einige Variablen in den ersten Zeilen des Skripts anzupassen, darunter das Archivverzeichnis und der Ort der Protokolldatei. Die aktuelle Version des Skripts ist allerdings noch fehlerhaft, daher ist es zurzeit sinnvoller, Logrotate oder ein ähnliches Tool zu verwenden.

Datenanalyse

Mehrere Tools helfen bei der Datenanalyse, alle Kommandos beginnen mit »ra« (siehe Tabelle 1). Das wichtigste Werkzeug ist »racluster«: Interessiert sich der Admin etwa für die Top-Talker im Netzwerk, ruft er das Kommando mit dem Parameter »-m saddr« (Source IP Address) auf, es kombiniert dann alle Flüsse mit identischen Adressen (Abbildung 1). Netzflüsse speichern die Parameter aus Tabelle 2, von denen jeder für die Aggregation mit »racluster« wählbar ist.

Abbildung 1: Das Argus-Tool »racluster« aggregiert Verbindungen mit identischen Adressen (hier mit »-m saddr« die Quelladressen)

Die Option »-L0« veranlasst Argus eine Kopfzeile mit den Spaltennamen auszugeben. Einen Spaltentrenner fügt der Parameter »-c« hinzu (zum Beispiel »-c |«). Die Spalten in Abbildung 1 enthalten folgende Daten:

• Startzeit (»stime«)
• Protokoll (»proto«)
• Quell-IP-Adresse (»saddr«)
• Richtung (»dir«)
• Ziel-IP-Adresse (»daddr«)
• Anzahl der von der Quelle gesendeten IP-Pakete
  (»spkts«)
• Anzahl der von dem Ziel gesendeten IP-Pakete
  (»dpkts«)
• Anzahl der von der Quelle gesendeten Bytes
  (»sbytes«)
• Anzahl der von dem Ziel gesendeten Bytes
  (»dbytes«)
• Status der Verbindung (»status«)

Die Ausgabe lässt sich mit der Option »-s« anpassen: So zeigt beispielsweise »racluster -s stime dur saddr spkts« nur Zeit, Dauer, Quell-IP-Adresse und die gesendeten Pakete an.

Sicht der Dinge

Die Angabe von »-M rmon« im Beispiel aus Abbildung 1 ist ein kleiner Trick: Normalerweise ist ein Netzwerkknoten sowohl Client als auch Server. Argus sieht den Knoten daher in einigen Flüssen als Quelle und in anderen als Ziel. Mit dieser Option rechnen die Tools alle Flüsse entsprechend um. Diese Funktion benötigt man sonst für die Aufbereitung der Daten für RMON-Applikationen. Das Remote-Monitoring (RFC 1757) ist noch eine weitere Alternative für die Überwachung des Netzwerks.

Der Befehl »racluster« sortiert seine Ausgabe nach dem angegebenen Aggregationsobjekt (im Beispiel »saddr«). Wer nicht nach der IP-Adresse, sondern nach den übertragenen Bytes sortieren möchte, verwendet zusätzlich den Befehl »rasort«. Für die Pipe erhält »racluster« die Extraoption »-w -«, es schreibt dann auf die Standardausgabe. Abbildung 2 zeigt, wie die sortierte Darstellung einen guten Überblick über das Datenaufkommen im Netzwerk und die verursachenden Systeme verschafft.

Abbildung 2: Der Befehl »rasort« sortiert die Ausgabe nach beliebigen Kriterien.

Welche Dienste werden genutzt?

Eine gängige Frage von Netzwerkverwaltern ist: Welche Dienste nutzen die Anwender in meinem Netzwerk und welche Datenmengen tauschen sie aus? So verbieten vielleicht die Unternehmensrichtlinien einige spezielle Dienste, eine Analyse kann dabei helfen, frühzeitig Gegenmaßnahmen zu treffen. Oft nutzen auch Trojaner ungewöhnliche Ports, die bei der Untersuchung auffallen. Um eine Liste der frequentierten Ports zu erhalten, kommt wieder »racluster« zum Einsatz:

racluster -M rmon -m proto sport -r /tmp/argus.out -w - - ip | rasort -m bytes proto sport -s stime dur proto sport spkts dpkts sbytes dbytes

Hier ist der Quellport (»sport«) das Aggregationsobjekt. Für die Aggregation der Ports ist es wichtig, nicht nur »-m sport«, sondern auch »proto« anzugeben: Die Angabe ist zwingend.

Berkeley-Packet-Filter

Alle Befehle unterstützen das Filtern der Pakete nach »tcpdump«-Manier. Jedoch unterscheidet sich der Argus-Filter davon in einigen Punkten; die Manpage zu »ra(1)« verrät Details. Jeder Befehl akzeptiert nach einem Minuszeichen »-« einen Berkeley-Packet-Filter, im letzten Beispiel ist das »ip«. Solche Filter schränken die Analyse auf Wunsch auch auf einen bestimmten Host oder ein Netzwerk ein, zum Beispiel: »ip and host 217.160.128.61«.

Ein weiterer Hinweis auf Trojaner im Netzwerk ist eine Änderung in der Protokollverteilung. Um die zu erkennen, sind zunächst Angaben über die normale Verteilung notwendig. Auch die ist mit Argus leicht zu ermitteln: Das Listing 1 zeigt dafür ein Beispiel. Über die Option »-s« erscheinen wieder nur die gewünschten Spalten.

01 $ racluster -m proto -r /tmp/argus.out -s proto trans pkts bytes
02     udp    926     2478     330500
03     tcp   1190  3550430 3538952906
04    igmp      1       10        540
05    icmp    147      272      25936
06     llc   1365     1365     155155
07  ipx/sp    455      455      50050
08     arp    733      874      44556

Für komplexe Aggregationen unterstützt »racluster« auch die Definition von Flussmodellen in einer Konfigurationsdatei (»racluster(5)«). Neben einigen Variablen, die das Verhalten von »racluster« modifizieren, stehen in dieser Datei auch Definitionen von Filtern und optionalen Modellen.

Ein Filter legt fest, welche Flüsse »racluster« analysiert, und ein Modell beschreibt, wie die Aggregation abläuft. Dabei entsprechen diese beiden Angaben den Berkeley-Packet-Filtern und der Option »-m« auf der Kommandozeile. Eine typische Konfigurationsdatei wäre:

filter="src net ( 10.0.0.0 mask 255.0.0.0 )" model="saddr/8 proto dport"
filter="dst net ( 10.0.0.0 mask 255.0.0.0 )" model="daddr/8 proto dport"

Hier aggregiert Argus zunächst jene Flüsse, bei denen das Netzwerk 10.0.0.0/8 als Source auftritt, entsprechend den Source-Adressen, des Protokolls und des Zielports. Anschließend geschieht das Gleiche für Flüsse, bei denen das Netzwerk als Ziel auftritt, diesmal analog mit einer Aggregation entsprechend der Zieladresse und des Zielports.

Arbeitet Argus mit Protokollrotation, ist der Zeitraum der Auswertung bereits eingeschränkt. Alle Befehle unterstützen aber auch über die Option »-t Timerange« die Angabe des auszuwertenden Zeitraums. »rasplit« extrahiert die entsprechenden Daten und speichert sie in einer eigenen Datei, zusätzlich sind dabei auch die übrigen Filter nutzbar.

Live-Analyse

Auch wenn der Administrator nicht mit Protokolldateien hantieren, sondern aktuelle Daten nutzen will, ist das kein Problem: Der Argus-Daemon muss in diesem Fall nur seine Daten über einen TCP-Port anbieten, die »ra*«-Werkzeuge holen die Daten direkt beim Daemon ab, wenn sie über die Option »-S« dessen IP-Adresse erhalten.

Mit »ratop« ist auch eine Live-Analyse der Daten möglich, das Kommando benötigt dazu nur ein einziges Argument: »ratop -S Remote-Host«. Es baut eine Verbindung zum Daemon-Rechner auf, liest dessen gesammelte Daten aus und zeigt sie an. »ratop« sortiert die Verbindungen automatisch nach der Anzahl der übertragenen Pakete, es sind aber auch andere Sortierungen einstellbar. Ein Aufruf der Hilfe mit der Taste [H] (Abbildung 3) zeigt die Tastaturkürzel, die »ratop« akzeptiert.

Grafische Auswertung

Eine grafische Auswertung der Daten ist ebenfalls möglich: So erlaubt zum Beispiel der Befehl

ragraph bytes dport -nn -M 1m -r argus.out -w ./ports.png

eine grafische Analyse der eingesetzten Ports. Aus Platzgründen fehlt in Abbildung 4 die Legende. Die blauen Linien zeigen HTTP- und die grauen HTTPS-Verbindungen an. Dabei erscheinen empfangene Daten im positiven Bereich der y-Achse und versendete Daten im negativen.

Abbildung 4: »ragraph« stellt die Flussdaten grafisch dar. Die Portanalyse zeigt die Nutzung der Netzwerkdienste, hier HTTP und HTTPS.

Die Analyse der verwendeten Protokolle aus dem Listing 1 lässt sich mit »ragraph« ebenfalls grafisch darstellen (Abbildung 5):

ragraph pkts proto -M 1m -r argus.out -w ./proto.png

Abbildung 5: Bringt eine Analyse der Protokolle eine Zunahme der ICMP- oder IPv6-Verbindungen ans Tageslicht, könnte ein illegaler Tunnel der Grund sein.

Eine Zunahme des ICMP-oder IPv6-Verkehrs wäre damit leicht zu erkennen. Sie sollte für Misstrauen sorgen, denn ungewöhnlich viel Verkehr könnte auf einen Tunnel oder einen Angriff hinweisen – die beiden Protokolle eignen sich dazu, Daten versteckt zu übertragen [5]. Mit weiteren Analysen berechnet der Administrator die Round-Trip-Time von TCP-Verbindungen (»tcprtt«) sowie Paketverluste (»sloss«, »dloss«).

Während viele Funktionen wie die grafische Auswertung mit Werkzeugen wie Ntop und MRTG ausführbar sind, bietet Argus durch die detailreiche Speicherung der Flussdaten die Möglichkeit, bei Verdacht einen genaueren Blick auf die Informationen zu werfen. Ntop oder MRTG stellen diese Ausgangsdaten für Detailanalysen nicht bereit. (hge)

Der Autor
Ralf Spenneberg arbeitet als freier Unix-/Linux-Trainer, Berater und Autor. Mit seinem Unternehmen Open Source Training Ralf Spenneberg führt er Schulungen und Beratungen durch. Er veröffentlichte bereits mehrere Bücher zu den Themen Intrusion Detection und Virtuelle Private Netzwerke. Vor wenigen Monaten ist sein neues Buch “Linux Firewalls mit Iptables & Co.” erschienen.