Immer wieder tauchen in den Medien Artikel auf, die von bösartigen Crackern berichten, welche irgendwelche vernetzten Computer-Systeme negativ beeinträchtigt haben. Gleichzeitig wird dadurch in Fachkreisen die Kontroverse entfacht, welches Betriebssystem denn nun vorteilshalber auf sicherheitskritischen Gebieten eingesetzt werden soll. Viele nicht versierte Linux-Administratoren wissen jedoch gar nicht, wo sie denn für die Erhöhung der Sicherheit des eigenen Systems ansetzen sollen. Dieser Text soll als kurze Einführung in die hochkomplexe Thematik der Sicherheit unter Linux dienen.

Die Installation

Schon bei der Installation des Betriebssystems muss an gewissen Regeln festgehalten werden, damit nicht unabsichtlich die Sicherheit des eigenen Systems untergraben wird. Bei Linux ist es üblich, mehrere Partitionen auf der lokalen Festplatte einzurichten, um eine strikte Kontrolle darüber zu haben, was wo gespeichert werden soll. Grundsätzlich sollten niemals root- und Benutzerdateisysteme in dieselbe Linux-Partition gelegt werden. Wird dieser Leitsatz ignoriert, so öffnet sich die Möglichkeit eines potentiell erfolgreichen Angriffs durch SUID-Programme. Minimal sollten das Wurzelverzeichnis (/), /var und /usr auf verschiedene Partitionen verteilt werden, um ein gewisses Maß an Sicherheit gewährleisten zu können.

Ganz wichtig für die Handhabung der Partitionen ist die Konfigurations-Datei /etc/fstab, welche das mount-Verhalten der einzelnen Dateisysteme beim Systemstart dirigiert. In dieser Text-Datei können spezifische mount-Optionen festgelegt werden, um zum Beispiel Nur-Lese-Zugriff oder kein SUID-Zugriff zu bestimmen. Ein nosuid-Mount sollte zum Beispiel überall dort erzwungen werden, wo lokale oder Remote-Benutzer nichts Gutes im Schilde führen könnten. Dazu zählen unumstritten die Home-Verzeichnisse der einzelnen User: Keiner von ihnen darf durch ein geschriebenes SUID-Bit lokale Daten eines anderen Anwenders beeinflussen können. Auch die Interpretation von Device-Files sollte mit dem nodevice-Schalter unterbunden werden, auch wenn kein anderer Benutzer als root solche Gerätedateien anlegen kann.

Linux kristallisiert sich vornehm als preiswertes und leistungsfähiges Server-Betriebssystem heraus. Bevor man jedoch wahllos Server-Anwendungen installiert, sollte man sich über die möglichen daraus entstehenden Gefahren bewusst werden. Eindringlinge versuchen sich in der Vorbereitungs-Phase stets mit Informationen über ihr Ziel einzudecken. Da kann durch einen laufender finger-Daemon oder gewährtem anonymen FTP-Zugang dem Angreifer unbewusst viel Arbeit abgenommen werden: Es ist nur eine Frage der Zeit, bis er über das zum Einsatz kommende Betriebssystem und die Software informiert ist. Gefährlicher wird es jedoch, wenn angebotene Dienste für das effektive Eindringen ausgenutzt werden können: Bufferoverflows für den meistgenutzten SMTP-Daemon Sendmail werden fast wöchentlich gesichtet und Exploits für die sich gern in Gebrauch befindlichen FTP-Server finden sich auf jeder gut sortierten Security-Seite im World Wide Web.

Doch nicht nur Daemonen und Server-Dienste können einem Benutzer erweiterte Rechte bescheren. So wurden auch schon Fehler in harmlos erscheinenden Utilities wie dem Datei-Manager Midnight Commander oder dem Text-Browser Lynx gesichtet. Wie so oft ist der Leitsatz "Weniger ist oft mehr" an dieser Stelle Gold wert.
 

Die Systemadministration

Der Grundgedanke des Multiuser-Betriebssystem Linux liegt darin, dass ein auserkorener Verwalter mit dem Pseudonym root die ganze administrative Macht besitzt: Es können mit diesem Account einzelne Benutzer, Gruppen oder Dateien kontrolliert werden. Als Administrator kommt man öfters in Versuchung, stets als Superuser im System zu verweilen: Man hat ja die komplette Kompetenz und braucht sich nicht um irgendwelche störenden Einschränkungen durch Permissions Sorgen zu machen. Diese Einstellung kristallisiert sich bei näherer Betrachtung als nicht zu unterschätzendes Gefahrenpotential heraus, denn schnell können versehentlich durch falsche Eingaben irreparable Schäden verursacht werden. Auch können korrupte Programme und Web-Applikationen systemwichtige Elemente korrumpieren.

Administrative Aufgaben können nach der Eingabe des Befehls su - erledigt werden. Nach der Eingabe des root-Passwortes steht eine Shell mit allen Rechten zur Verfügung. (Diese erkennt man bei des meisten Distributionen daran, dass das $ im Prompt durch ein # ersetzt wird.) Sobald als möglich sollte diese root-Shell mit exit wieder verlassen werden. Zusätzlich können mit dem Kommando sudo und der damit zusammenhängen Konfigurationsdatei /etc/sudoers auch normale Benutzer Befehle mit Root-Rechten ausführen. (*)

Als angehender Systemadministrator sollte man sich zusätzlich mit Zugriffsrechten für Devices, Verzeichnisse und Dateien auseinandersetzen. Die sogenannten Permissions werden mit den Kommandos chmod und chown definiert und können elementare passive Einflüsse auf die Systemsicherheit haben. So könnten böswillige Benutzer durch die Eingabe von "find / -perm +4000" nach Dateien mit gesetztem SUID-Bit suchen, um Programme mit potentiellen Sicherheitslücken ausfindig zu machen. Um solchen Attacken vorzubeugen, sollte man denjenigen Programmen SUID gewähren, welche diese Option auch unbedingt benötigen. Sind dies mehrere Programme, so ist das explizite Einrichten einer gesonderten Gruppe mit modifizierten Rechten von schätzenswertem Vorteil. Alle Programme, die kein SUID benötigen, sollen dieses Flag auch nicht gesetzt bekommen. Optimal sind gar keine SUID-Dateien schreibbar und unbenötigte SUID-Programme deinstalliert man am besten gleich.

Das Passwortsystem

Die Passwörter der Benutzer werden bei Linux in der ASCII-Datei /etc/passwd abgelegt. Diese Datei muss für alle lesbar sein, um verschiedene Account-Funktionen während des Betriebs gewährleisten zu können. Dank diesem Umstand kann jeder Benutzer durch die Eingabe von "cat /etc/passwd" die Informationen einsehen. Die Passwörter werden in einer fortschrittlichen chiffrierten Form gespeichert, welche der von IBM entwickelte symmetrische blockweise arbeitende Verschlüsselungs-Algorithmus DES (Data Encryption Standart) ermöglicht. Der Vorteil des zum Einsatz kommenden Verfahrens ist die sogenannte Falltürfunktion: Dabei wird aus dem eingegebenen Passwort ein eindeutiger Wert errechnet, der gespeichert wird. Will sich der Benutzer einloggen, wird nach der Eingabe des Passwortes die gleiche Prozedur vollzogen, um eine Authentifizierung durchzuführen: Ist der Schlusswert identisch, öffnen sich für den User mit seinen spezifischen Rechten die Pforten zum System.

In den meisten Fällen werden Angriffe auf die Passwort-Architektur gefahren. Solche Angriffe sind auf der populärsten Ebene sehr primitiv und lassen sich daher auch leicht mit wenigen Handgriffen und spärlichem Hintergrundwissen automatisieren. Die einfachste Form sind Brute-Force-Attacken, die durch die gesonderte Variante der Wörterbuch-Angriffe seit jeher einen hohen Stellenwert bei Crackern haben. Bei diesen werden durch bekannte Programme wie "Crack" oder "John the Ripper" Login-Versuche unternommen, wobei als Passwörter jeweils die Einträge aus Wörterbüchern zum Tragen kommen. Die Erfolgsquote ist erstaunlich hoch und lässt sich nur durch Einschränkungen bei der Passwortwahl durch eine automatische proaktive Überprüfung der Eingaben degenerieren. Es sollten bestmöglich keine Informationen aus dem persönlichen Umfeld oder Einträge in Wörterbüchern als Passwörter genutzt werden. Ein wahlloses Durcheinander an Nummerischen-, Alphanummerischen- und Sonderzeichen lässt die Laufzeit eines Passwort-Crackers zum eigenen Vorteil exponentiell in die Höhe schnellen.

Um dem Gefahrenpotential von Account-Übernahmen durch leicht zu durchschauende Passwörter den Wind aus den Segeln zu nehmen, kommt auf sehr vielen Systemen Passwort-Shadowing zum Einsatz. Bei dieser Technik bleibt zwar /etc/passwd lesbar, doch enthält sie statt der codierten Passwörter nur karge Platzhalter. Stattdessen werden die Benutzer-Passwörter in /etc/shadow gespeichert, die sehr starken Restriktionen unterliegt. Durch das Passwort-Shadowing lassen sich auch Definitionen für das Ablaufen gültiger Passwörter und Accounts einrichten. Wird zum Beispiel in einer Periode das Passwort vom Benutzer nicht wie vorgeschrieben stark geändert, so erfolgt eine automatische Sperrung des Zugriffs. Trotzdem ist Shadowing nicht das Wundermittel, denn es wurden in der Vergangenheit Bugs publiziert, die unter Umständen Zugriffe auf /etc/shadow dank erweiterten Rechten, Sym-Links, Race-Conditions oder Core-Dumps möglich machten.

Die Netzanbindung

Grundsätzlich sollte man externen Benutzern so wenige Ressourcen wie möglich anvertrauen. Unbenötigte Dienste in /etc/inetd sollten noch vor dem Anschluss an ein Netzwerk deaktiviert oder gar ganz deinstalliert werden.

Shell-Zugriffe durch Telnet oder die r-Utilities unterbindet man bestmöglich ganz. Ist das entfernte Arbeiten doch von Nöten, so sollte man wenigstens auf die verschlüsselte Verbindung durch SSH zurückgreifen. Auch FTP-Zugriffe, vor allem anonymer Natur, eröffnen Angreifern ein neues Potential. Unsinnige Samba- und NFS-Freigaben rücken eventuell Daten und Informationen heraus, die die Sicherheit des Systems negativ beeinträchtigen könnten. Ganz besonders sollte man auf SMTP in Form von Sendmail verzichten und Alternativen wie QMail nutzen, denn nicht umsonst konnte sich der wohl beliebteste Mail-Server den Titel "the buggiest daemon on earth" einheimsen.

Möchte man Daten per HTTP zugänglich machen, so empfiehlt sich wie immer das Gewinnen des Wissens um eine durchdachte Konfiguration: Neben klug vergebenen Permissions sollte man eine virtuelle chroot-Umgebung nicht missen. Zusätzlich sollte gegebenenfalls auf sichere Webentwicklung geachtet werden. Nicht selten wurden in der Vergangenheit Webserver durch ausnutzbare, schlecht programmierte CGI-Skripte kompromittiert.

Nicht nur Bufferoverflows und DOS-Attacken (Denial of Service) werden bei vernetzten Systemen zum Problem, sondern auch das unerlaubte Mitprotokollieren des Datenverkehrs durch Dritte. Relativ schnell können da bei ungeschützten Kommunikationen wie Telnet, FTP oder HTTP Passwörter oder sensible Informationen anfallen. Solchen Sniffer-Attacken kann nur sehr schwer das Handwerk gelegt werden, und der erfahrene Administrator ist aufgrund seines Wissens klar im Vorteil. Verschlüsselte Datenanbindungen durch SSH, SHTTP und SSLftp werden glücklicherweise größtenteils Sniffer-Attacken im Sande verlaufen lassen.

Es empfiehlt sich zusätzlich auf dem lokalen System oder extern ein Firewall-Element miteinzubeziehen, welches den Datenverkehr regulieren und protokollieren kann. Dadurch können ungewollte Informationslecks verhindert oder wenigstens frühzeitig erkannt werden. Das Durchforsten der Firewall-Logs nach auffälligen Ereignissen sollte unter keinen Umständen vernachlässigt werden, denn nur so können oft ausgeklügelte Angriffe erkannt, eingedämmt und abgewehrt werden. Eine Manipulation der Log-Files durch den Angreifer ist jedoch nicht auszuschließen, und so sollten zum Anfang Vorkehrungen getroffen werden, um die Glaubhaftigkeit der besagten Dateien zu gewährleisten. Dies kann durch redundante Auslagerung oder Checksummen ermöglicht werden.

Als Alternative zum Firewall-Dschungel könnte ein TCP Wrapper dienen, der mit den Dateien host.deny und host.allow eine einfache und komfortable Netzwerk-Zugriffskontrolle realisiert. Dies kann aber nicht annähernd eine Firewall ersetzen. Schließlich regelt der Wrapper nur, wer (hosts.deny, host.allow) welche Dienste nutzen darf. Auf welchen Ports Verbindungen angefordert werden dürfen bzw. NAT, MASQ, DOS per Fragmenten abwehren etc. geht alles nicht. (*)
 

(*) Aktualisiert:   Jörg Hopfe / Omega-X   1.12.2001