Dieses Tool weiß alles über geöffnete Dateien und Netzwerkverbindungen und verrät, welcher Prozess gerade welche Files und Sockets nutzt. Dabei gibt sich Lsof recht gesprächig. Passende Parameter reduzieren die Informationsflut und qualifizieren das Werkzeug gar für die Sicherheitsanalyse.

Server gecrackt? Prozesse Amok gelaufen? Partitionen und USB-Sticks, die sich nicht aushängen lassen? Unerklärliche Verbindungen im Netz? In jedem Fall brauchen Admins Informationen darüber, was im Rechner gerade los ist. Getreu der Unix-Philosophie “Alles ist eine Datei” sind geöffnete Datei-Handles eine reichhaltige Informationsquelle. Lsof [1] gräbt nach diesen Daten und gibt sie umfassend und detailreich aus.

Besonders prekär ist die Lage bei vermuteten Einbrüchen. Nicht so sehr die Manipulation selbst, sondern das Unwissen, ob überhaupt einer vorliegt, bringt Admins in Verlegenheit. Erfahrene Vertreter ihres Standes schließen die Wissenslücke präventiv durch Intrusion-Detection-Systeme (IDS) wie Snort [2], Tripwire oder Aide [3]. Die fahnden in Dateisystem und Datenstrom nach verdächtigen Mustern.

Manchmal muss es eine Nummer kleiner sein. Linux bietet auf der Kommandozeile eine Vielzahl an Programmen, die Spuren im System offenlegen. Typische Kandidaten für die Server-Diagnose sind »ps«, »netstat«, »top«, »fuser« und einige weitere auskunftsfreudige Helfer. Ein ungerechtfertigtes Schattendasein hingegen führt das Schweizer Taschenmesser Lsof [4].

Es listet alle geöffneten Dateien (daher der Name “List Open Files”). Das mag zunächst wenig beeindrucken, jedoch umfasst es unter Unix-artigen Systemen sowohl reguläre Dateien als auch spezielle Blockdateien, ausführbare Programme, Bibliotheken, Verzeichnisse, rechnerinterne Datenströme (Unix Domain Sockets) und Netzwerkverbindungen. Lsof sammelt Informationen an zentraler Stelle, was sonst nur ein ganzes Bündel von Programmen vermag.

Beschaffungsfrage

Das Universaltalent läuft auf einer Vielzahl an Unix-Derivaten. Unter Linux sollte Lsof in jeder gängigen Distribution entweder zum Basissystem oder zum Standard-Repository gehören; in Debian zum Beispiel reicht zur Installation »apt-get install lsof«. Das schlanke Paket kennt keine Abhängigkeiten, nur die sowieso verpflichtende Libc 6.

Gegen die vorkompilierten Versionen sprechen aber zwei Aspekte: Systemkompatibilität und Sicherheit. Der Lsof-Entwickler Vic Abel weist in seiner FAQ [4] darauf hin, dass nur eine auf dem Zielrechner kompilierte und aktuelle Lsof-Version vollen Funktionsumfang und beste Stabilität garantiert, da Lsof tief in die Systemarchitektur und den Kernel blickt. Zudem empfiehlt es sich, ein solches Programm, das der präventiven oder forensischen Analyse dient, aus sicherer Quelle zu beziehen und nicht gemischt mit gewöhnlichen Tools im Systembereich zu installieren. Das beugt Manipulationen durch Rootkits vor.

Selbst übersetzen

Das Übersetzen der Lsof-Quellen ist schnell erledigt. Die Kommandos in Listing 1 holen die Quellen aus dem Netz, prüfen per Gnu PG die Signatur (Achtung: Der Key kommt im Beispiel auch aus unsicherer Quelle), konfigurieren die Quellen und übersetzen sie.

Während der Konfiguration muss der Anwender interaktiv Entscheidungen treffen. Die Antworten [y], [y], [y], [n], [n], [n] und [y] erzeugen eine typische Umgebung mit dem Blick auf Sicherheit. Wichtig sind die Optionen »HASSECURITY« und »HASNOSOCKSECURITY«: Wer es nur dem Root-Benutzer erlauben will, mit Lsof eine Liste aller offenen Dateien und Sockets aller User anzuzeigen, muss mit [y] und [n] antworten. Hier verwirrt leider die inkonsistente Namensgebung.

Nach der Übersetzung gibt »./lsof -v« Auskunft darüber, mit welchen Optionen das Tool übersetzt wurde. Die Ausgabe »Only root can list all files« bedeutet, dass normale User das Programm nicht missbrauchen können, um systemkritische Informationen einzusehen. Das Sicherheitsmodell von Lsof ist in der Praxis jedoch eher kosmetischer Natur, da jeder Benutzer die Infos auch aus anderen Quellen (»ps«, »netstat« und mehr) zusammenstellen kann, wenn auch weit weniger bequem. Die in Distributionen vorkompilierten Versionen gehen unterschiedlich mit den Sicherheitsoptionen um: Debian erlaubt es normalen Benutzern, Lsof in vollem Umfang zu nutzen, während Red Hat Enterprise nur den eingeschränkten Modus bereitstellt.

Um Lsof an einem sicheren Ort aufzubewahren, genügt es, nach dem Kompilieren auf »make install« zu verzichten und die Binärdatei manuell auf einem schreibgeschützten Datenträger unterzubringen, etwa auf einer CD-ROM. Vorsicht: Ändert ein Eindringling den Kernel (etwa durch ein Kernel-Rootkit), dann ist auch den Ausgaben des unveränderten Lsof nicht mehr zu trauen.

Erkundung

Etliche Beispiele für die Systemerkundung führt Tabelle 1 auf. Wenn Lsof mit Sicherheitsoptionen konfiguriert ist, informieren die Befehle nur Root umfassend. Im sicheren Modus präsentiert es dem normalen Benutzer nur ihn betreffende Details. Selbst im unsicheren Modus sind die Angaben von Lsof ohne Root-Rechte unvollständig, da zum Beispiel nur Root auf alle Details in »/proc« zugreifen darf.

Tabellarisch

Lsof gibt die je nach Parameterliste gefilterten Informationen der offenen Dateien in einem tabellarischen Format aus. Es zeigt per Default folgende Spalten:

• Name des Prozesses: »COMMAND«
• Prozess-ID: »PID«
• Name des Systembenutzers, unter dem der Prozess läuft:
  »USER«
• Dateideskriptor: »FD«
• Typ der Datei: »TYPE«
• Gerät: »DEVICE«
• Größe: »SIZE«
• Verbindung: »NODE«
• Vollständiger Name: »NAME«

Die Ausgabe lässt sich über »lsof -F Felder« auch für die Übergabe an weiterverarbeitende Programme aufbereiten. Eine spezielle Formatierung sorgt dafür, dass die nachgeschalteten Tools einzelne Felder besser parsen können. Details dazu stehen in der Manpage-Sektion »Output for other programs«.

01 wget ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/lsof.tar.bz2
02 tar xjf lsof.tar.bz2
03 cd lsof_4.77
04 wget ftp://lsof.itap.purdue.edu/pub/Victor_A_Abell.gpg
05 gpg --import Victor_A_Abell.gpg
06 gpg --verify lsof_4.77_src.tar.sig lsof_4.77_src.tar
07 tar xf lsof_4.77_src.tar
08 cd lsof_4.77_src
09 ./Configure linux
10 make -s
11 ./lsof -v

Informationsflut

Ein Aufruf ohne Parameter liefert zu viele Informationen, um sie zu überschauen. Die Flut an Ausgaben verschreckt viele Anwender. Mit gezielt gewählten Aufrufparametern konzentriert sich Lsof auf die gerade gewünschten Daten. Bei der Kombination mehrerer Parameter verknüpft Lsof diese standardmäßig mit Oder-Logik. Wer will, dass alle Bedingungen erfüllt sind, muss zusätzlich »-a« angeben (letzte Zeile in Tabelle 1).

Ein bodenständiges Anwendungsbeispiel für Lsof ist das Identifizieren von Prozessen, die verhindern, dass der User einen Datenträger aushängt. Der Lsof-Aufruf mit der Option »-t Verzeichnis« liefert eine Liste numerischer Prozess-IDs, die auf die CD-ROM zugreifen:

$ umount /dev/cdrom
umount: /cdrom: device is busy
$ kill -9 `lsof -t /dev/cdrom`
$ umount /dev/cdrom
$ eject

Diese Methode ist ebenso drastisch wie wirkungsvoll. Unter [5] finden sich weitere Beispiele für die fortgeschrittene Nutzung bis hin zur Wiederherstellung gelöschter Dateien per Lsof und »cat«. Letzteres klappt, so lange irgend ein Prozess die Dateien noch geöffnet hält. Lsof ermittelt Datei und Prozess und je nachdem, auf welche Weise der Prozess die Datei geöffnet hat, ist ihr Inhalt an einer anderen Stelle im »/proc«-Dateisystem noch zugänglich.

Maskenball

Für GUI-verwöhnte Anwender gibt es nur wenige grafische Lsof-Oberflächen. Recht jung ist das Libgnome-basierte Glsof [6], dessen Entwickler erfreulicherweise aktiv an seinem Tool arbeitet. Leider befindet es sich noch im Alphastadium. Aufgrund der kurzen Releasezyklen empfiehlt es sich, die neueste Version aus dem Subversion-Repository zu laden. Bei der Artikel-Recherche erwies sich dies sogar als notwendig. Auf der Glsof-Homepage finden sich passende Instruktionen, der Entwickler antwortet auch auf Anfragen per E-Mail.

In Glsof ist es möglich, Filter per Mausklick anzulegen (Abbildung 1) und sie zu speichern, um die gleiche Abfrage später wieder zu stellen. Für die Filter sind recht komplexe Regelwerke anlegbar, die sich über das Query-Debug-Fenster anzeigen und analysieren lassen. Glsof senkt damit die Einstiegshürde in Lsof erheblich. Interessant ist auch die Möglichkeit, in Glsof Dateimonitore anzulegen. Diese überwachen frei definierbare Ressourcen und informieren zeitnah über Zugriffe. Dahinter verbirgt sich aber nur ein zyklisch wiederholter Aufruf von Lsof, der die Zugriffe zum Zeitpunkt des jeweiligen Aufrufs listet. Weil er das System nicht ereignisbasiert überwacht, kann dieser Mechanismus kurzfristige Zugriffe übersehen.

Abbildung 1: Trotz der vielen Lsof-Optionen schafft es Glsof, dem Benutzer einen vergleichsweise einfachen Einstieg in die Filter-Erstellung zu geben.

Abbildung 2: Das viel versprechende und aktiv entwickelte Glsof ermöglicht auch komplexe Systemabfragen. Hier analysiert es eine Gaim-Sitzung.

Das etwas betagte, seit 2003 nicht mehr aktualisierte Java-Frontend Jlsof [7] hat zwar weniger Funktionen als Glsof, ist aber leichter zu installieren. Es genügt, das Archiv zu entpacken und in der Startdatei »jlsof« die Pfade zum Java-Interpreter und zu »lsof« anzupassen. Jlsof wirkt deutlich spartanischer als Glsof, zeigt aber bei der Filtererstellung die Übersetzung in Lsof-Aufrufparameter (Abbildung 3), was dem Verständnis der Regeln zugute kommt. Ein Speichern der Filter ist zwar nicht möglich, dafür exportiert Jlsof die Ausgabe (Abbildung 4) in ein XML-Dokument.

Abbildung 3: Bereits im Filter-Dialog verrät Jlsof die entsprechenden Lsof-Parameter. Was reine GUI-Anwender verwirrt, hilft den Konsolen-Freunden beim Wechsel auf die Kommandozeile.

Abbildung 4: Die Lsof-Ausgaben übersetzt das Java-basierte Jlsof in eine recht simple Tabelle, die genau so wenig Übersicht liefert wie die Konsolen-Darstellung von »lsof«.

Sogar Mac-Nutzer kommen in den Genuss einer auf ihr System angepassten Lsof-Oberfläche: Das in Objective C geschriebene Sloth [8] punktet mit seinem übersichtlich gestalteten Interface (Abbildung 5), das nach Ressourcen-Typen vordefinierte Filter anbietet und Prozesse direkt per Mausklick beendet (»kill«).

Abbildung 5: Auch unter Mac OS X steht mit Sloth eine native Lsof-Oberfläche zur Verfügung. Sie ist vorbildlich gestaltet.

Erwartungshaltung

Die in Tabelle 1 gezeigten Aufrufe entlocken einem System bereits präventiv, aber auch nach einem Einbruch wichtige Informationen. Zur Vorbereitung auf den Ernstfall ist es notwendig, den Normalzustand zu kennen und zu wissen, wo am ehesten verdächtige Einträge zu erwarten sind.

Als Standardbeispiel diene im Folgenden ein klassisches LAMP-System (Linux, Apache, MySQL, PHP). Der Admin bemerkt, dass die Netzwerklast enorm angestiegen ist, ohne dieses Symptom über die Seitenzugriffe erklären zu können. Er vermutet, dass ein Eindringling ein Programm eingeschleust hat, das Dateien übers Netzwerk kopiert, verteilte Netzattacken ausführt oder Spam-E-Mails verschickt.

In einer LAMP-Umgebung ist die Schnittstelle von PHP zum System eines der Hauptangriffsziele, da PHP an etlichen konzeptionellen Schwächen leidet [9], auch schlampig geschriebene Skripte laden Angreifer ein. Wer den typischen Ablauf eines Einbruchs über PHP kennt, ahnt auch, nach welchen Informationen er mit Lsof suchen muss.

Der Apache-Webserver läuft standardmäßig als eigener Benutzer, etwa als »www-data« (Debian), »apache«, »httpd« oder in schlechten Fällen als »nobody« (dieser Account ist NFS vorbehalten). In der Regel laufen zusätzliche Prozesse als Root, um privilegierte Ports und die Logdateien zu öffnen. Die Datenkommunikation allerdings erledigen niedrig privilegierte Prozesse. Auf einem Webserver gibt es somit einen bestimmten Erwartungshorizont an Kombinationen aus Benutzern, auszuführenden Dateien und geöffneten Ports. So führt »www-data« unter Debian »/usr/sbin/apache2« aus.

Wer läuft wo

Der Aufruf »lsof -a -d txt -u www-data« darf in dieser Umgebung nur Prozesse listen, die »/usr/sbin/apache2« als Benutzer »www-data« ausführen. Die Option »-a« sorgt für Und-Verknüpfung, »-d txt« listet nur ausgeführte Dateien und »-u www-data« beschränkt die Ausgabe auf diesen Benutzer. Im Regelfall trifft das nur auf die Apache-Prozesse zu.

Ist es einem Angreifer gelungen, PHP oder PHP-Skripte zu manipulieren und Systembefehle und Programme auf dem Server auszuführen, laufen diese üblicherweise als derselbe Benutzer wie Apache – außer wenn der Eindringling über weitere Lücken Root-Rechte erlangt hat und die eigenen Spuren verschleiert. Wer Prozesse des Apache-Benutzers findet, die auf anderen Binärdateien basieren oder unerwartete Ports offenhalten, sollte die Alarmglocken läuten. Mit »lsof -p PID« untersucht er verdächtige Prozesse dann detailliert auf Netzwerkverbindungen, geladene Bibliotheken, geöffnete Dateien und mehr.

Da Cracker gerne ihre eigenen Server für FTP, IRC, Telnet oder SSH mitbringen, gehört zur Erstanalyse auch die Suche nach offenen Ports. Der Aufruf »lsof -a -i -u www-data | grep LISTEN« listet alle IP-Sockets (»-i«), die der Apache-User geöffnet hat (»-u www-data«) und die als Server auf Verbindungen warten (daher »grep LISTEN«). Alles abseits von 80 (HTTP) und 443 (HTTPS) ist verdächtig. Ähnliche Ergebnisse liefert zwar auch ein »netstat«-Aufruf, doch hilft Lsof auch bei der weiteren Analyse und spart somit einen Programmwechsel.

Harte Realität

Apache- und PHP-Cracks sind recht häufig anzutreffen. Die Listings 2a und 2b zeigen zwei Auszüge aus Lsof-Logs, die von tatsächlich gecrackten Servern stammen. Sie genügten dem Autor für eine Einbruchsdiagnose. Die Ausgaben stammen von einer Analyse der Prozesse des Benutzers »www-data«. Listing 3 zeigt ein weiteres gekürztes Beispiel, diesmal zusätzlich anonymisiert.

01 COMMAND   PID     USER   FD  TYPE  DEVICE   SIZE    NODE  NAME
02 bash    30334 www-data  cwd   DIR     3,8   4096 1571340  /home/user/public_html/w-agora/.m
03 bash    30334 www-data  txt   REG     3,8 496231 1571405  /home/user/public_html/w-agora/.m/bash
04 bash    30334 www-data    0w  REG     3,8    125 1571408  /home/user/public_html/w-agora/.m/LinkEvents
05 bash    30334 www-data    2u IPv4 4709341            TCP  server.de:40001->undernet.xs4all.nl:ircd ESTABLISHED)

01 COMMAND   PID     USER   FD   TYPE    DEVICE SIZE NODE  NAME
02 a       10555 www-data  266u  IPv4      2808       TCP  *:https (LISTEN)
03 a       10555 www-data  267u  IPv4      2809       TCP  *:www (LISTEN)
04 a       10555 www-data  543u  IPv4 757852768       TCP  *:9713 (LISTEN)
05 psybnc  10615 www-data  266u  IPv4      2808       TCP  *:https (LISTEN)
06 psybnc  10615 www-data  267u  IPv4      2809       TCP  *:www (LISTEN)
07 psybnc  10615 www-data  543u  IPv4 757871322       TCP  *:ircd (LISTEN)
08 psybnc  10615 www-data  549u  IPv4 762054917       TCP  server.de:35614->oslo1.no.eu.undernet.org:ircd (ESTABLISHED)
09 bind    22004 www-data  543u  IPv4 696149859       TCP  *:1982 (LISTEN)

01 $ lsof -i TCP -n -P | awk '/LISTEN/ {print $1"/"$3"/"$8}' | sort -u
02 apache/root/*:443
03 apache/root/*:80
04 apache/www-data/*:443
05 apache/www-data/*:80
06 mysqld/mysql/127.0.0.1:3306
07 sshd/root/*:22

Im ersten Beispiel profitiert der Angreifer von einer veralteten W-Agora-Version (eine Onlineforum-Software) und einem Verzeichnis ohne Schreibschutz (Listing 2a, Zeile 2: »/home/user/public_html/w-agora/«). Der Eindringling hat ein neues Verzeichnis angelegt ».m«, das ihm als Arbeitsverzeichnis dient (Zeile 2, Spalte FD: Current Working Directory). In das Directory hat er C-Dateien hochgeladen, kompiliert und ausgeführt – das Ganze unter dem unverdächtig erscheinenden Namen »bash«.

Dass dieses Programm nicht so harmlos ist, wie sein Namen vermuten lässt, zeigt Zeile 5: Die Möchtegern-Bash hat eine Verbindung zu einem IRC-Server offen. Außerdem schreibt sie Daten in die Datei »LinkEvents«, erkennbar am File-Deskriptor »0w« (also Stdout, zum Schreiben geöffnet).

Dummdreist

Die Dreistigkeit, mit der ein Cyber-Gauner hier vorgeht, ist erstaunlich – jedoch weniger wegen seiner Selbstsicherheit als vielmehr wegen des mangelnden technischen Wissens, da er kaum Spuren verschleiert hat. Das Verzeichnis über einen vorangestellten Punkt verstecken und den Prozesses als »bash« bezeichnen – das sind Anfängertricks, die dem Admin sehr entgegenkommen.

Im zweiten Beispiel (Listing 2b) hat ein Saboteur eine ähnliche Lücke genutzt, um eine ganze Reihe von Anwendungen zu installieren. Auch er hat kaum bis keinen Wert auf Verschleierung gelegt: Der »www-data«-Account hält etliche Ports offen, unter anderem für den IRC-Proxy Psybnc. Der eindeutige Prozessname »psybnc« (Zeilen 5 bis 8) spricht Bände. Immerhin auch hier der Versuch, einen der Prozesse unter einem vertrauten Namen zu tarnen: als Nameserver »bind« in Zeile 9. Tatsächlich handelte es sich um einen gepatchten SSH-Server, der ohne Passwort Zugriff als »www-data« auf das System ermöglicht. Zudem läuft ein Serverprozess mit dem auffälligen Namen »a« (Zeilen 2 bis 4).

Kein Admin hat Lust und Zeit, selbst IDS zu spielen und fortwährend das gleiche Kommando abzusetzen, in Erwartung unerwarteter Resultate. Er benötigt daher ein Skript, das einen vordefinierten Systemzustand mit dem aktuellen Zustand vergleicht und bei Abweichungen nach vordefinierten Regeln reagiert – also eine Anomalie-Erkennung. Mit Lsof ist es zum Beispiel sinnvoll, eine Liste geöffneter Ports vorzuhalten, erweitert um Prozessnamen, Benutzernamen und das verwendete Interface.

Automatisierung

Der in Zeile 1 von Listing 3 gezeigte Einzeiler erledigt den ersten Teil der Aufgabe recht elegant. Er weist Lsof an Netzwerk-bezogene Dateien auszugeben (»-i«), ohne dabei Portnummern als Servicename auszuschreiben (»-P«) und ohne IP-Adressen in Hostnamen aufzulösen (»-n«). Awk fahndet in der Ausgabe nach Ports im »LISTEN«-Status und formatiert sie neu als: »Benutzername/Prozessname/IP:Port«, wobei die IP-Adresse »*« für Server steht, die auf allen Interfaces lauschen. Das abschließende »sort« ordnet die Ausgabe alphabetisch und sorgt dank »-u« dafür, dass jede User-Prozess-Dienst-Kombination nur einmal erscheint.

Die ab Zeile 2 in Listing 3 gezeigte Ausgabe stammt von einem Debian-Sarge-Server mit Apache 1.3, MySQL- und SSH-Daemon. In diesem Beispiel bindet sich MySQL nur an das lokale Interface (Zeile 6), während Apache und SSH auf allen Interfaces erreichbar sind. Interessant ist die typische Aufteilung der Apache-Prozesse in »root« und »www-data«, die aus der Abgabe der Root-Rechte nach Programmstart resultiert.

Das Lsof-Mini-IDS auf Basis von Listing 3 soll wie in Abbildung 6 skizziert arbeiten. Beim Start merkt sich das Skript in Listing 4 (Zeilen 4 bis 8) die aktuelle Port-Konfiguration. Alle 10 Sekunden (Zeile 10) holt es per Lsof die Liste der geöffneten Ports und vergleicht sie mit dem vorigen Status (Zeile 12). Hat sich etwas verändert, schickt das Skript eine E-Mail mit dem Vorher-Nachher-Status (Zeilen 14 bis 20) und nutzt den neuen Status als Basis für weitere Vergleiche (Zeile 22).

Abbildung 6: Das in Listing 4 gezeigte Skript alarmiert den Administrator, sobald es einen Wechsel der Portbelegung feststellt.

01 #!/bin/bash
02 MAILTO="root"
03 HOSTNAME=`hostname`
04 getports() {
05   lsof -i -n -P | awk '/LISTEN/ {print $1"/"$3"/"$8}' | sort -u
06 }
07 
08 OLD="$(getports)"
09 echo -e "Beginne mit folgender Port-Belegung:n$OLD"
10 while sleep 10 ; do
11   NEW="$(getports)"
12   if test "$OLD" != "$NEW" ; then
13     echo "Aenderung der Portbelegung! Informiere Administrator per E-Mail"
14     mail -s "Achtung: $HOSTNAME LISTEN-Status geaendert" $MAILTO <<EOF
15 Status vor der Aenderung:
16 $OLD
17 
18 Status nach der Aenderung:
19 $NEW
20 EOF
21   fi
22   OLD="$NEW"
23 done

Zum Testen der Anomalie-Erkennung im Selbstbau sollte der Admin temporär einen Port öffnen. Sehr einfach geht das mit Netcat. Ein Aufruf der Form »nc -l -p 12345« startet Netcat im »LISTEN«-Modus (Option »-l«) und hält den Port 12345 offen. Nach spätestens 10 Sekunden sollte das in seiner Schleife verharrende Shellskript die Zustandsänderung bemerken und mit einer entsprechenden Warn-E-Mail reagieren.

Falscher Alarm

Achtung: Manche Prozesse verändern ihre für Lsof sichtbare Portbelegung. Kandidaten dafür sind E-Mail-Server, die je nach dem Zustand der eingehenden Verbindungen zusätzliche Prozesse forken und sie unter anderen Namen laufen lassen. Unter Umständen lösen solche Prozesse falschen Alarm aus. Das ist durch kleine Anpassungen in der Abfragelogik an die spezifische Situation aber schnell zu unterbinden: Ein angehängtes »| grep -v Temporärer Dienst« in Zeile 5 sollte genügen.

Ein simples Shellskript wie das hier vorgestellte ersetzt zwar kein vollwertiges IDS, als Anregung für Eigenentwicklungen und als zusätzliche Verteidigungslinie in einem komplexeren Szenario taugt es aber auf jeden Fall. Sinnvolle Erweiterungen wären eine Kryptographie-gestützte Konfigurationsverwaltung à la Aide, die Kontrolle ausgeführter Dateien, Auswertung der UDP-Konfiguration und einiges mehr. Per wiederholtem Lsof-Aufruf erschließen sich auch neue Anwendungsgebiete, wie die File-Monitoring-Möglichkeit bei Glsof zeigt.

Gute Informationsquelle

Egal ob in einem Skript oder als schnelles, universelles Admin-Tool: Lsof leistet wertvolle Dienste. Bei Verdacht auf eine Server-Kompromittierung gilt bei Lsof aber wie bei allen anderen Diagnosewerkzeugen: Es lässt sich nie mit Sicherheit sagen, dass nicht eingebrochen wurde. Das Gegenteil schon. (fjl)

Copyright © 2002 Linux New Media AG