Kapitel 18. Systemsicherheit
Zurück | 18.3 Weitere Möglichkeiten | Weiter

## 18.3 Weitere Möglichkeiten

Im Folgenden finden Sie einige Gedanken dazu, wie das bisher Gesagte weiterhin umgesetzt werden kann.

Das PAM-System ist durch den modularen Aufbau in der Lage, die verschiedensten Medien zur Authentifizierung zu nutzen. Wie wäre es mit einem Scanner für Fingerabdrücke oder einem Iris-Scanner?

Alle bisherigen Logdaten wurden auch in Dateien geschrieben. Diese können von einem Angreifer natürlich verändert oder gelöscht werden, auch wenn diese auf anderen Rechnern gespeichert werden. Logfiles, die auf einem Drucker mit Endlospapier ausgegeben werden, können nicht gelöscht werden!

Um das Löschen oder das Verändern von Dateien zu verhindern, kann ein komplettes System einmalig konfiguriert werden und dann auf eine bootfähige CD-ROM geschrieben werden. Natürlich sind so noch Angriffe auf das System möglich; es können aber keine Daten verändert oder zusätzliche Programme installiert werden. Für ein Firewall-System ist dies beispielsweise eine sinnvolle Möglichkeit, das System zu schützen.

Wenn möglich sollten alle Kernel-Treiber nicht als Module übersetzt werden. Dann kann die Möglichkeit, Kernel-Module zu laden, komplett deaktiviert werden. So können viele Angriffe abgewehrt werden. Auch hier gilt: Nicht benutzte Funktionen sind abzuschalten.

### 18.3.1 Nach einem Einbruch...

Nach einem Einbruch gibt es nicht viel zu tun. Das System ist sofort vom Netz zu nehmen und komplett neu zu installieren. Einfach, nicht wahr? Natürlich gilt es herauszufinden, wie der Eindringling in das System eingedrungen ist. Dies geschieht in einer abgeschotteten Umgebung, also ohne Netzzugang für das betroffene System. Es sind zur späteren weiteren Analyse alle Daten auf einem geeigneten Medium zu sichern. Gegebenenfalls ist eine Meldung an ein CERT (Computer Emergency Response Team, in Deutschland beispielsweise das DFN-CERT http://www.cert.dfn.de/) zu erstellen und dort der Einbruch zu melden. Ist eine Strafverfolgung des Einbruchs vorgesehen oder geplant, so sollten Sie ggf. auf professionelle Unterstützung zurückgreifen.

Weiterhin sind auf dem neuen System alle notwendigen, vorab beschriebenen Sicherheitsvorkehrungen zu treffen.

### 18.3.2 Erkennen von Rootkits

Nach einem Einbruch auf einem System, beispielsweise durch ein über das Netzwerk gesnifftes Passwort, werden häufig so genannte „Rootkits“ installiert, die dem Angreifer einen Zugang mit Rechten des Administrators (root) erlauben. Es ist dabei über eine Sicherheitslücke, die dem Angreifer zunächst lediglich normale Benutzerrechte erlaubt, möglich, mittels bekannter Lücken weitere Zugriffsrechte zu erlangen.

Ein Rootkit wird dabei, wie der Name schon sagt, als „Bausatz“ in Form von Skripten geliefert. Rootkits sind in den verschiedensten Varianten im Internet verfügbar. Der Angreifer muss nicht zwingend über weit reichende Systemkenntnisse verfügen, ein erschlichener Benutzer-Account ist oft ausreichend, um ein Rootkit zu installieren. Angreifer, die solche Rootkits einsetzen, werden daher aufgrund des fehlenden Know-hows auch als „Script-Kiddies“ bezeichnet.

Rootkits haben dabei die (unangenehme) Eigenschaft, viele Arbeitsschritte bei einem Einbruch in ein System zu automatisieren. Es werden dabei zunächst Programme installiert und ausgetauscht, um Aktivitäten auf dem System zu verbergen. Dabei ist es beispielsweise üblich, zunächst `/bin/login` gegen eine modifizierte Variante auszutauschen. Die neue Version erlaubt Logins eines bestimmten Benutzers ohne oder mit einem bekannten Passwort. Natürlich erscheinen diese Logins in keinem Logfile. Weiterhin werden Programme, die Aufschlüsse über die Aktivität von Benutzern erlauben, durch veränderte Versionen ersetzt. Dies betrifft meist Programme wie `ls` (Anzeigen von Dateien und Zugriffsrechten) oder auch `ps` (Anzeigen von Prozessen eines Benutzers). Mit diesen neuen Programmen werden Aktivitäten des Angreifers verschleiert oder komplett verborgen.

Um ein solches Rootkit zu erkennen, können Sie das Paket `chkrootkit` (Check Rootkit) verwenden. Dieses kann ab der Debian-Version 3.1 direkt via APT installiert werden.

Der Aufruf dieses Programms erfolgt wie üblich auf der Kommandozeile, es kann dabei die Option `-q` angegeben werden, um die Informationen über die durchgeführten Tests zu unterdrücken. Leider neigt `chkrootkit` dazu, mitunter Alarm zu schlagen, auch wenn kein Rootkit installiert ist. Bekannt ist dies bei Netzwerkinterfaces, die im Promiscous-Modus laufen (wenn beispielsweise `tcpdump` eingesetzt wird). Bekannt ist dieses Fehlverhalten auch bei Kerneln mit NPTL-Patch (ab Kernel 2.6 immer enthalten); dabei wird ein „LKM-Trojaner“ gemeldet. Weiterhin werden solche falsch-positiven Ergebnisse auch auf sehr langsamen Rechnern gemeldet.

### 18.3.3 Suckit Detection Tool

Das Paket `skdetect` ist ein auf das „Suckit“-Rootkit spezialisiertes Programm. Einige Tests wurden hier genauer implementiert, die Erkennung ist aber nicht so umfassend.

Zurück | Nach oben | Weiter
18.2 Securing Debian HOWTO | Zum Anfang | Kapitel 19. Modellbahnen

© 1999-2006 Frank Ronneburg - Dieser Inhalt ist unter einem Creative Commons Namensnennung - Nicht-kommerziell - Keine Bearbeitung Lizenzvertrag lizenziert (creativecommons.org/licenses/by-nc-nd/2.0/de/legalcode).