Immer wieder tauchen in den Medien Artikel auf, die von bösartigen Crackern berichten, die 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 gewisse 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 sollte das Wurzelverzeichnis (/), /var und /usr auf verschiedene Partitionen verteilt werden, um ein gewisses Mass 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 ein 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 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 korrekten Passworts mit dem Befehl "su" getätigt werden, welcher eine Shell mit differenter Benutzer- und Gruppen-ID zugänglich macht. 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, Verzeichnissen 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 mir potentiellen Sicherheitslücken ausfindig zu machen. Um solchen Attacken vorzubeugen, sollte man diejenigen 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 Authentizierung 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örtern 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 den codierten Passwörtern 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össtenteils 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 Durchforster 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 auszuschliessen, 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 kann ein TCP Wrapper dienen, der mit den Dateien host.deny und host.allow eine einfache und komfortable Netzwerk-Zugriffskontrolle realisiert.