So einfach sich Netzwerke in der Theorie verhalten - schließlich müssen sich ja alle Teilnehmer an Standards halten - so komplex ist mitunter die Praxis. Das Problem beginnt bei wild gewordenen Clients und führt über Hacker-Einbruchsversuche und heimlich ausgenutzte Sicherheits-lücken sowie nicht korrekt oder vollständig implementierte RFCs (haben Sie sich schon einmal die Implementation Ihres NNTP-Server richtig angesehen?) bis hin zu echten Hardwarefehlern.
Wohl dem, der vorgesorgt hat und den gesamten Netzwerkverkehr mit Hilfe spezieller Tools intelligent und damit vor allem automatisiert ständig im Auge behält. Oft genug kündigt sich ein Problem bereits vorab an, so daß man entsprechend pro-aktiv loslegen kann. Sind die ersten Pakete bereits im Datennirvana verschwunden, so helfen immerhin die entsprechenden Log-Dateien, sofern der Administrator entsprechend vorgearbeitet hat. Auf der anderen Seite muß er natürlich bei einer solchen Überwachung die gesetzlichen Bestimmungen und firmeninternen Regeln zum Datenschutz genau beachten, denn schließlich handelt es sich um ein höchst sensitives Themen-gebiet.
Das Anforderungsspektrum an ein Verwaltungswerkzeug ist sehr breit gefächert. Manchmal überschneiden sich auch die bekannten Bereiche des Netzwerkmanagements mit alltäglichen Aufgaben wie Abrechnung von Traffic aufgesplittet nach Service und Abteilung. Praktisch wäre es auch oft, einen bereits erfolgten Hacker-Angriff, für eine Nachbearbeitung vorsorglich mitgeschnitten, durch ein geeignetes Analyseprogramm nachträglich Schritt für Schritt durchzugehen, um die Systeme für die Zukunft zu schützen. Und noch nützlicher wäre es, den ständig neuen Angriffstechniken durch eine gezielte Überwachung zu begegnen, ohne hierzu Eingriffe im System vornehmen zu müssen.
Preiswerte Alternative
Neben kostenpflichtigen Werkzeugen kommerzieller Hersteller steht mit dem "Network Flight Recorder" (NFR) des amerikanischen Unternehmens NFR Software eine interessante Alternative zur Verfügung: Anwender können das Programm kostenlos nutzen, solange sie hierfür keine externe Hilfe in Anspruch nehmen (siehe Kasten: Die NFR-Lizenz).
Das Tool läßt sich auf diversen Unix-Derivaten installieren und nutzt den Zugang zu allen übertragenen Netzwerkdaten über eine im "promiscuous"-Mode betriebene Netzwerkkarte. Dies ist nicht neu; auch andere Pakete wie "tcpdump" beherrschen diese Funktion. Der große Unterschied liegt darin, was der NFR dann mit den Daten anstellen kann: Anstatt sie einfach zur Nachbearbeitung auf die Festplatte zu schreiben, entscheidet eine programmierbare "Decision Engine" in Echtzeit, ob sie in ein Logfile wandern, einen Alarm auslösen oder "on-the-fly" durch angehängte (und ebenfalls frei programmierbare) Analysewerkzeuge intensiver unter die Lupe zu nehmen sind.
Scripting-Sprache "N"
NFR ist als Basis für ein umfassendes Netzwerkverwaltungs- und Analyse-Tool gut geeignet. Dabei kann der Anwender frei entscheiden, welche Daten interessant sind und wie das Tool auf Ereignisse reagieren soll. Hierzu läßt sich NFR durch eine eigene Scripting-Sprache namens "N" programmieren sowie durch Module beliebig erweitern. Gewählte Ereignisse oder Stati lösen E-Mails oder SMS-Nachrichten aus oder initiieren einen Serverneustart. Da das gesamte System im C-Quelltext vorliegt, steht der Zugang bis in die "heiligen" IP-Interna offen.
Bild 1 zeigt den prinzipiellen Aufbau des NFR. Direkt am Netz hängen Datenkollektoren, sogenannte "Pa-cket Sucker", die zur Steigerung der Performance auch in einem kleinen Rudel auftreten dürfen. Die "Datensauger" basieren auf der bekannten Bibliothek libpcap der Network Research Group, die zum Lawrence Berkeley National Laboratory gehört und von der amerikanischen Regierung finanziert wird. Diese C-Bibliothek ist dank ihrer portablen Schnittstelle bei Systemadministratoren und in Hackerkreisen zugleich sehr beliebt und gilt als Standard-Programmierschnittstelle zu einem Netzwerk auf unterster Ebene.
Big Brother in Echtzeit
Da der NFR die Datenpakete gleich weiterverarbeiten muß und deshalb eine vergleichsweise hohe CPU-Belastung erzeugt, mußte der Hersteller die libpcap-Bibliotkek etwas anpassen, um keine Pakete zu verlieren. Derzeit arbeitet der NFR auf der Basis der nicht mehr aktuellen (aber getesteten) libpcap-Version 0.3.1a2. Die aktuelle Version 0.4a2 hat die NFR-Weihe noch nicht hinter sich. Auch nach der Performance-Optimierung sollte die NFR-Testmaschine zu der schnelleren Kategorie gehören und möglichst als dediziertes System ohne weitere Aufgaben fungieren.
Bild 2 zeigt, wie der Datenfluß innerhalb des NFR abläuft. Nachdem die Packet Sucker die Daten aufgenommen haben, wandern sie zur zentralen "Engine", dem "NFRD". Von hier gelangen die Pakete über ein API zur Entscheidungsmaschine. Diese gleicht über programmierbare Filter (der sogenannte N-Code wird zur Ausführung in Byte-Codes kompiliert) den Datenstrom in Echtzeit mit gewünschten Vorbedingungen ab. Hierzu verwaltet das System die Pakete in einer "Reassembly Table", so daß eine komplette TCP-Verbindung auch logisch zu untersuchen ist. Je nach Status verwirft der NFRD die eingegangenen Datenpakete, leitet sie zur Weiterbearbeitung an Backend-Prozessoren weiter oder gibt einen Alarm aus.
Der logische Mitschnitt einer Verbindung ist zwar ein riesiger Ressourcenkiller, aber erst damit läßt sich eine komplexere Überwachung realisieren. Tritt ein bestimmtes Ereignis ein, so kann die Historie der entsprechenden Verbindung sehr wichtig sein. Dies trifft insbesondere auf typische Einbruchsversuche zu, die aus einer Folge genau abgestimmter Kommando-Sets bestehen und sich erst nach einer Weile "verraten". Erst wenn die Verbindung mit größter Sicherheit abgeschlossen ist, gilt die Überwachung der Verbindung als beendet. Hierzu wartet der Filter nach dem offiziellen Abschluß per FIN-Paket zur Sicherheit noch eine Weile ab, unter anderem um bekannten Hacks einen Riegel vorzuschieben. Die logische Analyse des Datenstroms erleichtert es auch, Übertragungsfehler wie verlorene Pakete oder "Retransmissions" festzustellen. So kann ein Administrator der Ursache für erhöhten Datenverkehr auf den Grund gehen.
Datenflut reduzieren
Die Programmiersprache "N" bindet einen Filter an Ereignisse oder Datenpakete. Diese müssen die Daten dann entsprechend weiterverarbeiten, denn im Eingangsbereich muß der NFRD schnellstens Platz für neue Pakete schaffen. Um dieses Weiterverarbeiten zu vereinfachen, steht eine Reihe spezialisierter Funktionen zur Verfügung, die bei der Interpretation der raw-Datenpakete helfen. Die Daten gelangen dann zu einem "Backend". Dieser Prozeß hat zur Aufgabe, die übermittelten Datensätze aufzubereiten, anzuzeigen oder Aktionen auszulösen.
Die Backends übernehmen in Kombination mit dem großen Aufräumer, "Spaceman" genannt, die Aufgabe, die Datenflut auf das notwendige Maß zu reduzieren. Solange die Festplattenkapazität endlich ist, muß der Spaceman den ihm zugewiesenen Platz (etwa per quota) verwalten und ältere Daten archivieren beziehungsweise löschen. Bevor der Spaceman-Dämon sie unwiederbringlich löscht, kann man die Daten in eine Datenbank übernehmen, als "tar"-Datei auf Band speichern oder auf einen anderen Server kopieren. Der Zugriff darauf zu Analysezwekken erfolgt per Java-Browser, ist also von der Echtzeit-Datenanalyse entkoppelt.
Frei progammierbar
Die Sprache N basiert auf einer Stack-Maschine, bietet atomare Datentypen wie IP-Adresse und arbeitet sehr effizient. Darauf aufbauende Funktionen wie tcp.hdr oder ip.src erleichtern den Zugang zu spezifischen Datenfeldern eines Paketes. Intern arbeitet eine Reihe unterschiedlicher NFR-Engines an der Aufbereitung. Basisprotokolle wie IP IC, TCP und UDP sowie die "raw"-Ethernet-Frames stehen im Zugriff.
Bei Bedarf kann der Sysadmin eigene Unterprogramme im N-Code schreiben, die spezifische Felder innerhalb eines Datenpaketes zurückliefern. Damit ist es beispielsweise möglich, alle übergeordneten Services wie FTP, POP oder NFS genauer unter die Lupe zu nehmen. Kombiniert man die aufbereiteten Daten, so lassen sich schnell sehr leistungsfähige Software-Trigger erstellen. Hierzu stellt N auch vorprogrammierte Filter-Events zur Verfügung, die allgemein übliche Datenfelder wie beispielsweise "Source", "Destination", "Destination Port" oder einen beliebigen Such-String in den Nutzdaten eines Paketes überwachen. Taucht der Event auf, so ruft N die entsprechende Filter-Routine auf, die beispielsweise das Logging übernimmt:
Filter server tcp (client, port: 25, start: "kilroy was here", stop: "and me")
{
record ip.src, ip.dst, tcp.sport,
tcp.dport, tcp.bytes to virus_log;
}
Im obigen Fall wacht der Event-Filter darüber, wann der NutzdatenString "kilroy was here" in Kombination mit "and me" bei einer SMTP-Übertragung (Port 25) auftaucht. Dies kann beispielsweise dann wichtig sein, wenn der Verwalter genau weiß, daß diese beiden Strings in einem Makrovirus vorkommen. Ist das String-Pärchen identifiziert, startet die Filter-Routine, um die wichtigen IP-Daten der verdächtigen Sendung abzuspeichern.
Eine weitere Anwendung wäre die Überwachung typischer Kommandosequenzen beziehungsweise Datenpatterns "on the fly", durch die sich Trojanische Pferde wie "Back Orifice" oder "Netbus" aufspüren lassen.
Standardpakete vordefiniert
Im Standardprogramm des NFR befinden sich bereits einige sogenannte Backend-Pakete. Sie fassen die Aufgaben typischer Backend-Anwendungen in einem Code-Paket zusammen. Da die einzelnen Backends gleiche Codeteile innerhalb eines "Packages" gemeinsam nutzen, macht das die Arbeit effizienter. Folgende Pakete stehen bereit:
- Mail (interessant für Spam-Filter),
- Netzwerk-Datenverkehr (ideal zur Netzwerkplanung),
- Netzwerk-Services (FTP- und RSH-Analyse) sowie
- WWW-Server (Aufspüren inoffizieller Server et cetera):
Die Backends zeichnen die überwachten Netzwerkaktivitäten entweder in einfachen Tabellen (Histogramm) auf, die als Zusammen- fassung dienen (wie oft wurde eine URL aufgerufen?) oder in Listen, die jeden interessanten Event zeilenweise dokumentieren (wer, wann, wo). Im Idealfall ist ein Backend in vier Dateien unterteilt:
- Kurzbeschreibung (knappe Erklärung, die das GUI anzeigt),
- Konfigurationsdatei,
- N-Code sowie
- Output-Mapping.
Die Kurzbeschreibung ist zwar nicht zwingend erforderlich, erleichtert aber die Übersicht. Das Output-Mapping definiert, wie die Daten später im GUI aussehen sollen (Farben et cetera). Die Konfigurationsdatei bestimmt, welche der aufgezeichneten Daten in welchen Daten- feldern abzulegen sind und wie das Query-GUI die Daten später präsentieren soll. Eine typische Konfigurationsdatei für einen NNTP-Backend könnte wie folgt aussehen:
enabled=true
# das soll das GUI ausgeben
title=NNTP: Count NNTP Activity by User
# GUI soll Daten in Histogrammform zeigen
gui=histogram
# muss so sein
cfversion=1
# data type information
num_columns=3
# primaere Datentypen
column_1_type=p_nntp_user
column_2_type=p_src_ip
column_3_type=p_dst_ip
# Die entsprechende Label hierzu
column_1_label=user
column_2_label=source NNTP host
column_3_label=destination NNTP host
# Histogramm-Intervalle in Sekunden beziehungsweise Byte
rollover=1800
rollover_size=DO
rollover_size_val=1000000
rollover_time=DO
rollover_time_val=1800
# Datenverzeichnis
archive_path=data/%p/%b/%y/%m%d
Damit der Verwalter beim Programmieren nicht von "ganz unten" beginnen muß, definiert das System bereits wichtige Datentypen in Form sogenannter "primärer Datentypen". Hierzu filtert die Software aus dem TCP/IP-Datenstrom die gebräuchlichsten Datenfelder heraus, auf die der Benutzer ohne zusätzlichen Programmieraufwand gleich zugreifen kann. Zu diesen Feldern gehören unter anderem:
- Source Port,
- Source-IP,
- Destination Port,
- Destination-IP,
- FTP-Username,
- E-Mail-Variablen (From, To, et cetera),
- Telnet-User,
- Rlogin-User,
- URL oder der
- WWW-User.
Darauf aufbauend bietet der NFR auch "sekundäre Datentypen" an, die einfach eine Art logischer Zusammenfassung der primären Datentypen sind. Dieser praktische Datensatz läßt sich durch eigene Routinen beliebig erweitern, um bestimmte Protokolle direkt zu unterstützten.
Im Zentrum des NFR werkelt ein Programminterpreter vor sich hin, der die Sprache N und damit das gesamte System zum Leben erweckt. Diese Sprache bietet die gewohnten Funktionen, hat aber den unschätzbaren Vorteil, daß der Programmierer gleich auf netzwerkspezifische Datentypen zurückgreifen kann, ohne sich vorher lange in Fachliteratur beziehungsweise den RFCs tummeln zu müssen. Der Interpreter selbst arbeitet als einzelner Thread, der auf einem integrierten yacc-Parser aufbaut. Externe Programme greifen auf den Interpreter mittels vordefinierter Kommandos zu. Prinzipiell verknüpft man folgende Teile zu einem System: Interpreter, N-Programm sowie den Datenstrom (Device oder Testdatenfile).
Insbesondere die Möglichkeit, bereits in einer Datei abgespeicherte Testdaten zur Programmentwicklung nutzen zu können, erweist sich in der Praxis als überaus nützlich. Damit sich der Administrator dabei nicht im Kreise dreht, konvertiert eine Utility die bekannten tcpdump-Dateien in nutzbare Rohdaten. Folgende Datentypen stehen zur Auswahl:
- blob: Octetgruppe;
- ethmac: Ethernet-MAC-Adresse bestehend aus sechs Octets;
- error: beschreibt einen Laufzeitfehler;
- int, int32: Integerwert (ohne Overflow-Schutz);
- ipv4Host: Hostadresse im IP Version 4-Format;
- ipv4Net: Subnetzbereich im IP-Version-4-Format;
- list: eine Kollektion bestehend aus anderen Datentypen;
- pattern: Suchpattern;
- recorder: Ziel für die Datenausgabe sowie
- string: String nach C-Notation.
Um den Programmablauf steuern zu können, stehen fundamentale Ausdrücke wie +, -, *, /, % (modulo) oder die Vergleichsoperatoren sowie Statements wie foreach, if oder while zur Verfügung. Codesequenzen lassen sich in Unterprogrammen zusammenfassen. Wichtige Netzwerkaktivitäten können "Trigger" auslösen. Möchte man beispielsweise beim Auftreten eines "UDP"-Paketes (UDP = User Datagram Protocol) eine gesonderte Aktion in Gang setzen, so läßt sich diese in einer Triggerroutine abhandeln:
On = udp() call udp_paket_check
Hierzu steht die sogenannte "Trigger-Family" zur Verfügung. Derzeit unterstützt NFR folgende Pakete mit einem Trigger:
- packet,
- ip,
- udp und
- tcp.
ICMP-Pakete (ICMP = Internet Control Management Protocol) sollen in Kürze folgen. Der Trigger alleine bestimmt, welches generelle Protokoll zu einem Aufruf der Trigger-Routine führen soll. Hat man das Protokoll definiert, so lassen sich be- stimmte Voraussetzungen wie IP-Quelle oder -Ziel definieren. Möchte man beispielsweise alle UDP-Aktivitäten des Hosts "122.12.34.4" gesondert überwachen, so reicht folgender Aufruf:
udp ( host : 122.12.34.4 )
Eine Reihe vordefinierter Funktionen (String-Verarbeitung, Pattern-Matching, Listenverwaltung et cetera) erleichtert die Arbeit.
NFR als IDS-Werkzeug
Eigentlich entstand der NFR nicht explizit als IDS-Tool (Intrusion Detection System). Dennoch eignet sich dieses Paket ob der vielfältigen eingebauten und vom Anwender ausbau- fähigen Funktionen auch dazu, unerlaubte Eindringversuche in einem externen Netzwerk oder aus dem lokalen Netzwerk heraus festzustellen und entsprechend Alarm zu schlagen. Um den Einsatz als IDS-Werkzeug etwas zu fördern, entwickelte die in Sicherheitskreisen bekannte "L0pht"-Gruppe eine Reihe interessanter IDS-Erweiterungen in der N-ScriptingSprache für den NFR. L0pht ist eine Gemeinschaft von Top-Hackern in den USA und hat sich der Netzwerksicherheit verschrieben. Künftig will die Gruppe auf dem Gebiet der Intrusion Detection stärker mit NFR Software zusammenarbeiten.
Die Erweiterungen basieren auf den Erfahrungen der häufigsten Systemangriffe und sollen als Beispiel dienen, die zeigen, wie man typische Angriffsversuche feststellen und darauf reagieren kann. Die entsprechenden Programmodule (http://www. l0pht.com/NFR/) bieten folgende Funktionen:
- badweb,
- finger watcher,
- arp requests,
- externe Zugriffe,
- Land-Attacken,
- zwei RIP-Watcher,
- DoS-Watcher,
- X-Window-Watcher,
Kaum waren diese Routinen verfügbar, fühlte sich ein weiteres L0pht-Mitglied herausgefordert und entwickelte weitere Routinen:
- Back-Orifice-Detector,
- Big-Packet-Detector,
- Exploit-Logger für DNS-Iquery, lockd/NFS,
- Winnuke-Detektor,
- statd-Explot-Watcher und einen
- rpc.ttdbserverd-Exploit-Detektor.
Damit stehen dem Systemadministrator bereits eine Reihe interessanter Beispiele zur Verfügung, die zeigen, wie man den NFR sowohl als universelles Netzwerkmanagement-Tool wie auch als Sicherheitszentrale zugleich einsetzen kann. Der Zugang zu den NFR-Daten erfolgt unter anderem über einen ab der Version 2.x fest eingebauten Web-Server und spezielle Java-Applets, die als "Fenster" in die NFR-Datenwelt von einem beliebigen Browser aus fungieren.
Zwar unterstützt der NFR eine breite Palette unterschiedlicher Betriebssysteme, jedoch ist nicht jedes System ein idealer Ausgangspunkt. Nutzt man Intel-Hardware, so sollte man auf BSD-Systeme setzen, da diese im Vergleich zu Linux auf ein leistungsfähigeres Netzwerksubsystem (BPF, Berkeley Packet Filter) aufbauen. So sind Paketverluste unter Linux häufiger als unter BSD. Der Hersteller macht zudem auf einen Fehler im Linux-System aufmerksam, der es Hackern ermöglicht, auf die NFR-Daten zuzugreifen beziehungsweise den NFR-Sniffer zu entdecken. Damit wäre ein wichtiger Aspekt verloren: unerkannt zu bleiben. Seit kurzem steht aber eine potentielle Alternative für Linux-Fans zur Verfügung (siehe Kasten "Linux-Abhilfe", Seite 58).
Die Web-Site des Herstellers bietet einen Zugang zum Archiv der NFR-Mailingliste, deren Abo sich in jedem Fall lohnt. Hier tauschen sich NFR-Anwender untereinander aus, und auch die Techniker des Herstellers sind mit Lösungsvorschlägen präsent. Neue NFR-Module werden hier ebenfalls angekündigt.
Gerade in der Praxis zeigt sich die Stärke des NFR. Nachdem man sich intensiv in das Tool eingearbeitet hat (ein schneller Einstieg ist ob der Komplexität fast unmöglich), avanciert es rasch zum "Schweizer Messer" für alle Fälle des Netzwerkadministrators. Wichtig ist etwas Geduld am Anfang und vor allem eine besonders schnelle Maschine, die mit dem Datenverkehr im Netzwerk mithalten kann. (cep)