Tatort: Linux-Rechner

Auch wer seinen Rechner nach bestem Wissen und Gewissen absichert [1] ist nicht gefeit vor Einbrüchen und Einbruchsversuchen – es sei denn, man arbeitet ausschließlich offline. Der beste Rat lautet daher, nicht angsterstarrt wie das sprichwörtliche Kaninchen auf die Schlange zu starren, sondern sich offensiv für den Fall des Falles vorzubereiten. Dazu zählt unter anderem auch, sich mit den Methoden potentieller Angreifer vertraut zu machen.

Erste Schritte des Bösewichts

Wenn ein Einbrecher auf einem Rechner eingedrungen ist, hat er vordringlich drei Ziele: das Beseitigen der Sicherheitslücke, die Installation von Hintertüren und das Verwischen von Spuren. Im ersten Schritt wird er die Sicherheitslücke, die er selbst ausgenutzt hat, schließen, damit nicht ein weiterer Angreifer ihm den Rechner streitig macht. Böse Zungen behaupten, kompromittierte Rechner seien die am besten geschützten Rechner.

Im zweiten Schritt wird er Hintertüren und zusätzliche Software installieren. Hierbei handelt es sich zum Beispiel um weitere Angriffswerkzeuge oder Kennwortsniffer.

Anschließend folgt in der Regel der Versuch, Spuren zu verwischen und verräterische Anhaltspunkte in den Protokolldateien und im Dateisystem zu entfernen. Dem lässt sich vorbeugen, indem man die Protokolle zusätzlich auf einem zentralen Protokollserver sammelt und das Dateisystem überwacht.

Sicherheitskopien von Logdateien anderer Rechner erstellt von Haus aus bereits der klassische BSD-Syslogd, den die meisten Linux-Distributionen mitliefern, und zwar dann, wenn er auf dem zentralen Protokollserver mit dem Kommandozeilenparameter -r (für "remote", "entfernt") gestartet wird. Dieses "Flag" aktiviert die Fähigkeit, Protokollmeldungen über das Netzwerk entgegenzunehmen.

Bei den meisten Distributionen konfiguriert man die Startparameter der Systemdienste im /etc/sysconfig-Verzeichnis. Hier befindet sich meistens eine Datei syslog, in der der Anwender die Option hinzufügt. Bei Suse wird dabei aus der Zeile SYSLOGD_PARAMS=""

SYSLOGD_PARAMS="-r"

Nach einem Neustart des Syslogd (/etc/init.d/syslog restart) bietet der Daemon diese Funktion an. Bei anderen Distributionen wie Debian findet sich die zu ändernde Variable (hier: SYSLOGD) mit einem entsprechenden Hinweis direkt im Syslog-Startskript (bei Debian /etc/init.d/sysklogd):

# Options for start/restart the daemons
#   For remote UDP logging use SYSLOGD="-r"
SYSLOGD=""

Auf den Client-Rechnern, die ihre Protokolle an den zentralen Server schicken sollen, muss der Administrator die Syslog-Konfigurationsdatei /etc/syslog.conf anpassen. Zunächst entscheidet er, welche Meldungen er auf den Protokollserver schicken möchte. Wenn es sich um alle handelt, so genügt es, die folgende Zeile in der Datei einzufügen:

*.*     @centrallog

Den Platzhalter centrallog ersetzt man durch den Namen oder die IP-Adresse des Logservers. Nach dem Neustart des Syslogd auf dem Client schickt dieser nun alle Protokollmeldungen auch an den Server, und zwar mit dem UDP-Protokoll an Port 514.

Hat man nun bei Durchsicht der Logdateien [1] auf dem Client-Rechner das Gefühl, etwas könne nicht stimmen, kann man die dortigen Einträge mit denen in den entsprechenden Protokolldateien auf dem Logserver vergleichen – gibt es Unterschiede, liegt eine Manipulation vor. Alle Meldungen, die in der Datei /var/log/messages auf dem Logserver vom Rechner enterprise.linux-magazin.de (und nicht vom Logserver-Rechner selbst) stammen, findet man mit dem Befehl grep:

logserver # grep "enterprise.linux-magazin.de" /var/log/messages
May 21 18:37:40 enterprise.linux-magazin.de syslogd 1.4.1#11: restart.

… hier zum Beispiel den Beweis, dass der Syslogd neu gestartet wurde.

Änderungen unerwünscht

Um Manipulationen eines Einbrechers an normalerweise unveränderlichen Konfigurations- und Programmdateien auf die Spur zu kommen, überwacht man das Dateisystem am sinnvollsten mit als "System Integrity Verifier" (SIV) bezeichneten Werkzeugen wie Tripwire [2,3] und Aide [4,5]. Beide legen Informationen zu Dateien, die auf Veränderungen hin beobachtet werden sollen, in einer zentralen Datenbank ab. Durch regelmäßige Überprüfungen erkennen sie Modifikationen und alarmieren den Administrator. Dieser muss nun entscheiden, ob es sich um eine von ihm gewollte Änderung handelt oder ob ein Dritter am Werk war.

Da beide Anwendungen nach jedem Update und jeder Neuinstallation eines Pakets Änderungen melden, entsteht ein recht hoher Administrationsaufwand, der meist nur für die Überwachung von Servern im Internet betrieben wird. Für Desktop-Rechner kann zu einem gewissen Teil das Paketverwaltungssystem der Distribution einspringen.