Linux hat mittlerweile eine beachtliche Durchdringung des professionellen
Marktes erreicht. Gerade dort ist jedoch oft der Kostenfaktor zweitrangig
im Verhältnis zu Sicherheit und Verfügbarkeit der Daten und angebotenen
Dienste. In diesem Beitrag soll untersucht werden, in welchem Maße Linux
diesen erhöhten Anforderungen standhalten kann und auf welchen Gebieten
welche Maßnahmen getroffen werden müssen, um sie zu erreichen. Der
Artikel richtet sich sowohl explizit an Entscheider, die vor der
Überlegung stehen, Linux in ihre betrieblichen Prozesse einzubinden,
als auch an Systemmanager, die solche Entscheidungen umsetzen sollen.
Inhalt
Einleitung
Aspekte von Sicherheit
Vertraulichkeit von Daten
Vertraulichkeit der Datenübermittlung
Authentifikationsmechanismen und Zugangskontrolle
Integrität
Verfügbarkeit, Verlässlichkeit, Stabilität
Nachvollziehbarkeit, Accounting, Logging
Entscheidungskriterien für Linux als sicheres System
Zusammenfassung
Linux scheint erwachsen geworden zu sein und ist in aller Munde. Immer häufiger wird Linux als Alternative zu proprietären Lösungen gesehen, wo vor kurzer Zeit noch Skepsis herrschte. Linux hatte schon immer den Vorteil, kostengünstig zu sein; Installationsmedien konnte man für wenig mehr als die Herstellungskosten einer CD-ROM erstehen oder sogar selbst aus dem Internet downloaden. Doch gibt es Bereiche, in denen die reinen Anschaffungskosten der Software eine eher untergeordnete Rolle spielen. Die "Total Cost of Ownership" ist zum Schlagwort geworden; ein Versuch, sowohl die versteckten Anforderungen, als auch ihren Preis zu erfassen. Im Mission-Critical-Bereich - und das ist in einem kommerziellen Umfeld heutzutage fast jeder Bereich - kommen noch andere Anforderungen zum Zuge, die erfüllt werden sollen, damit der Einsatz von Linux tatsächlich "sicher" für das Einsatzfeld ist.
In diesem Beitrag soll untersucht werden, in welchen Bereichen Linux heute schon "sicher einsetzbar" ist, welche Einschränkungen eventuell noch in Kauf genommen werden müssen, und was schon realisierbar ist. Wir gehen explizit nicht zu sehr in technische Details, untersuchen nicht einzelne Programme oder Systemkomponenten auf ihre Fehlerhaftigkeit oder Fehlerfreiheit, sondern wollen versuchen, einen Überblick zu vermitteln, und verweisen bei technischen Erörterungen auf die jeweiligen Quellen.
Wir setzen voraus, dass der Leser ein Grundverständnis von den Methoden und Modellierungen von Datensicherheit hat. Weiterhin gehen wir von einem Überblick zu Betriebsystem- und Netzwerkarchitekturen aus. Das bedeutet, dass Basiskonzepte wie das Unix-Dateisystem oder Sinn und Zweck eines Firewalls nicht detailliert in Aufbau und Funktionsweise besprochen werden, sehr wohl jedoch deren Bedeutung für die Sicherheit einer solchen Komponente unter Linux. Es sind keine expliziten Detailkenntnisse in einem der angesprochenen Bereiche notwendig, es wird mehr Wert auf die konzeptionelle Bedeutung der einzelnen Komponenten gelegt und vermittelt, so dass dieser Beitrag als Entscheidungsgrundlage und -vorbereitung zum Einsatz eines sicheren Linux-Systems sowohl bei Systemmanagement als auch bei Entscheidern genutzt werden kann.
Ein Hinweis: In diesem Beitrag werden einige Software-Pakete vorgestellt, aber nicht alle sind zwangsläufig "freie Software", die für einen beliebigen Einsatz kostenlos kopiert werden kann. Unter Umständen sind gewisse Lizenzbedingungen bei bestimmten Nutzungsarten zu beachten.
Unter einer "sicheren Arbeitsumgebung" wird im konkreten Einzelfall sicherlich subjektiv jeweils etwas anderes verstanden. Es gibt jedoch eine Reihe von Gemeinsamkeiten dieser Vorstellung, die mal stärker, mal schwächer ausgeprägt sein werden. Wir untersuchen im Folgenden diese Aspekte daraufhin, wie man sie gemeinhin in Computersystemen umsetzt, und was Linux dabei bieten kann.
Die "Vertraulichkeit" von Daten fordert, dass nur dazu berechtigte Subjekte, also Benutzer oder auch automatisch oder entfernt angestoßene Programme auf Daten zugreifen können, zu denen diese Subjekte auch geeignete Berechtigungen haben. Können solche Zugriffsberechtigungen umgangen werden, ist die Vertraulichkeit nicht mehr gewährleistet.
In den meisten Betriebssystemen werden die Objekte, auf die zugegriffen werden soll, durch mehr oder weniger detaillierte Zugriffsberechtigungen geschützt. Eine solche Zugriffsberechtigung setzt sich also aus
zusammen. Linux setzt hier vollständig das im Unix-Umfeld etablierte Modell um, das sich auf Dateiberechtigungen stützt und als Zugriffsarten hauptsächlich "lesen", "schreiben" und "ausführen" unterstützt. Darüber hinaus werden vom häufig unter Linux verwendeten ext2-Filesystem prinzipiell noch darüber hinausgehende Verfeinerungen dieser Zugriffsmöglichkeiten angeboten, so dass beispielsweise der Schreibzugriff auf eine Log-Datei mit dem Befehl
# chattr +a demo.log
auf den allein anhängenden Schreibzugriff eingeschränkt werden kann. Auf diese Weise können noch eine Reihe weiterer Attribute zugewiesen werden (u.a. sicheres Löschen, Unveränderlichkeit, Ausnahme vom Backup).
Einige Betriebssysteme bieten feingranularere Abstufungen der Zugriffsarten und der Zuordnung von Subjekt und Objekt; oft wird dies über "Access Control Lists" (ACL) umgesetzt, wo explizit für jedes Objekt vermerkt wird, welches Subjekt wie auf es zugreifen darf. Das Unix-Paradigma fasst hier einige Subjekte zusammen, hier können nur die Berechtigungen des "Besitzers", einer ausgewiesenen "Gruppe" von anderen Subjekten oder allen sonstigen Subjekten der Zugriff gewährt oder verweigert werden (siehe chmod(1)). Diese Funktionalität {?} kann Linux von Haus aus nicht bieten und selbst bei denkbarer Unterstützung durch das Betriebssystem müssten Applikationen diesen Schritt auch geeignet unterstützen.
Es stellt sich allerdings die Frage, ob damit wirkliche Funktionalität fehlt, oder ob ACLs mehr als ein rein zusätzlicher Komfort in der Rechtevergabe anzusehen sind. Der erhöhte Komfort hat nämlich auch seine trügerischen Seiten: Um so komplexer die unterstützten Zugriffsarten sind, desto komplexer und weniger durchschaubar werden deren Zusammenhänge. Darüber hinaus ist natürlich ein Berechtigungssystem immer nur so gut, wie es umgesetzt wird. Sind kritische Bereiche eines Betriebssystems (z.B. Verzeichnisse, in denen Systembibliotheken abgelegt werden) freigegeben zur Modifikation durch beliebige Benutzer, so stellt sich zwangsläufig die Sinnfrage nach den weitergehenden vorhandenen Mitteln.
Zusammenfassend kann gesagt werden, dass durch den langen Einsatz von Unix-Systemen in diesem Bereich durch einen erfahrenen Systemadministrator eine für die meisten Standard-Anforderungen hinreichende Vertraulichkeit der Daten erreicht werden kann.
In hochsensitiven Umgebungen wird als Kritikpunkt am Unix-Berechtigungssystem oft die "Allmacht" des Superusers ins Feld geführt, der alle Dateien lesen, löschen und modifizieren kann. Auch für diesen Bereich gibt es jedoch für Linux bereits Lösungen, indem die Benutzer ihre Dateien selbst mit einem nur ihnen bekannten Schlüssel chiffrieren. Das Crypto-Filesystem CFS bietet eine sehr bequeme Möglichkeit, die für den Benutzer auf Filesystemebene transparent ist und dennoch die Dateien mit starker Verschlüsselung ablegt. Ausgehend von der Unversehrtheit der entsprechenden Utilities von Modifikationen durch den Administrator kann so selbst dieser ohne entsprechenden Schlüssel nicht mehr die Inhalte der Dateien einsehen. Dies zeigt einmal mehr die prinzipiellen Probleme, die ein absoluter Account einer auf Systemtools basierenden Umgebung einbringen kann, da alle Bibliotheken, Programme und Utilities unter der Kontrolle dieses Superusers sind. Wir machen jedoch trotzdem die Annahme vom "integeren Administrator", da der (übrigens betriebssystemunabhänige) organisatorische Mehrauswand für die meisten, wenn auch nicht alle Anwendungsszenarien nicht gerechtfertigt ist.
Alle genannten Maßnahmen zur Vertraulichkeit stützen sich natürlich auf die Existenz einer vertrauenswürdigen "höheren Instanz", hier dem Betriebssystemkern. Gerade hier hat Linux wegen seines Open-Source-Characters wohl unbestrittene Vorteile gegenüber Alternativen, wo dieser Code nicht eingesehen werden kann. Abgesehen davon, dass echte Fehler im Betriebssystemkern selbst über die vergangenen Jahre eher selten auftraten, sind sie bei Entdeckung jeweils sehr schnell (teilweise im Stundenbereich) behoben worden.
Was Linux gegenwärtig noch fehlt, ist eine offizielle Zertifizierung, beispielsweise nach dem amerikanischen "Orange Book" oder nach dem europäischen ITSEC. Auf der anderen Seite zeigt sich, dass die "Funktionalität" in weitesten Sinne bei solchen Systemen, die eine solche Zertifizierung erfahren haben, für bestimmte Aufgaben stark eingeschränkt ist. Es gibt sicherlich Anwendungsfälle, wo dieses ganz bewusst in Kauf genommen werden muss, z.B. im Bankbereich oder beim Militär. Zumindest haben einzelne Linux-Zusammenstellungen schon eine POSIX-Zertifizierung erhalten, die allerdings genaugenommen mehr eine Funktionalität als solche bestätigt, nicht deren Sicherheit an sich.
Da heute fast jeder Rechner Verbindung zu einem wie auch immer gearteten Netzwerk hat, ist neben der Vertraulichkeit von Daten auch die Vertraulichkeit der Datenübermittlung zu betrachten.
Der Datenaustausch zwischen zwei Rechnern findet heute in den meisten Fällen über ein Protokoll statt, das im weitesten Sinne auf dem TCP/IP-Stack basiert. zwar gibt es noch einige proprietäre Protokollschichten, deren Bedeutung jedoch tendenziell eher abnimmt (IPX, Appletalk, usw.). Linux unterstützt heute alle diese Übertragungsprotokolle; in den höheren Protokollschichten existiert noch eine breitere Auswahl an anwendungsbezogenen Protokollen, die je nach Verfügbarkeit entsprechender Utilities unterstützt werden (als willkürliche Auswahl seien SMB oder ICQ genannt).
Aufgrund der Fülle an unterschiedlichen Protokollen können wir in diesem Beitrag nicht jedes Protokoll einzeln auf seine Sicherheit hin untersuchen, zwei Aspekte haben jedoch grundsätzliche Bedeutung für fast alle Protokolle: Der prinzipielle Protokollaufbau und die für die Sicherheit der Übertragung gemachten Annahmen, sowie Fragen der Verschlüsselung und die dafür verwendeten Methoden.
Als Unix hat Linux den Vorteil, dass die meisten implementierten Übertragungsprotokolle offene Standards sind, deren Spezifikation z.B. in RFCs festgeschrieben und offengelegt sind. Diese Offenlegung hat große Wichtigkeit für die nachvollziehbare Vertraulichkeit: Es wird mehr Arbeit investiert, das System zu brechen, und wenn das trotz der großen Anstrengungen nicht gelingt, kann man hoffen, dass es sonst auch niemand schafft. Bei der Datenübertragung spielt das Protokoll die Rolle der vertrauenswürdigen Instanz. So wurden beispielsweise diverse strukturelle Sicherheitsmängel beim mühsamen Clean-Room-Reengeneering des nicht offenen SMB-Protokolls für das unter Linux verfügbare Samba-Paket entdeckt.
Die rein funktionale Umsetzung der Standard-Protokolle rund um den TCP/IP-Stack in Bezug auf Vertraulichkeit im Rahmen der dazu von den Protokollen bereitgestellten Mitteln ist heute nach unserem Ermessen bei den verfügbaren Linux-Implementationen gegeben. Das schließt natürlich Fehler (z.B. Pufferüberläufe, implizite Annahmen über Paketgrößen oder -nummern) in einzelnen Implementationen nicht aus. So liegt auch hier keine offizielle Zertifizierung vor, jedoch lässt sich anhand der wenigen entdeckten Fehler bezüglich der spezifizierten Funktionalität auf ein vernünftiges Sicherheitsniveau der Protokolle schließen. Hierzu trägt sicherlich die hohe Installationsbasis und die nicht durch Firmenpolitik eingeschränkte Entwickler- und Anwendergemeinde maßgeblich bei.
Viele der offenen Protokolle aus allen Netzwerkschichten sind noch in einer Zeit entstanden, als noch andere Maßstäbe an Vertraulichkeit angelegt wurden. So enthalten viele Protokolle aus heutiger Sicht nur rudimentäre Mittel zur Gewährleistung der Vertraulichkeit. Fast alle in dieser Zeit entstandenen Protokolle von TCP über Telnet, FTP oder SMTP bis hin zum X11-Protokoll oder HTTP übertragen ihre Daten unverschlüsselt.
Man versucht heute dieses Problem durch zwei alternative Ansätze zu überwinden: Der Einsatz von starker Kryptographie in den Übertragungs- und Transportschichten (z.B. IPSec oder SSL/TLS) ist ein generischer Ansatz und steht für alle darüberliegenden Protokollschichten zur Verfügung, wobei dann Fragen nach der Verwaltung und Integration der Schlüssel und Zertifikate entstehen. Der zweite Ansatz ist die anwendungsspezifische Verwendung von kryptographischen Verfahren wie PGP oder S/MIME für E-Mail oder s-http für das WWW.
Unter Linux stehen für beide Ansätze eine ganze Reihe von solchen Produkten zur Verfügung:
SSH ist fast schon eine Produktfamilie, die auf unterschiedlicheste Weise verschlüsselte Übertragungen ermöglicht und diverse bekannte Applikationen mit diesem Feature ausstattet. Insbesondere gibt es für fast jedes r-Utility mittlerweile ein zugehöriges s-Utility (ssh für einen sicheren, entfernten Programmaufruf, slogin für ein sicheres interaktives Login usw.). SSH kann aber auch das X11-Protokoll verschlüsselt übertragen und weitere Dienste quasi-transparent "tunneln", z.B. ist ein sicherer Zugriff auf eine POP3-Mailbox so realisierbar. SSH zeichnet sich darüber hinaus dadurch aus, dass es unterschiedliche Kryptoverfahren (u.a. IDEA, Blowfish, Triple-DES) unterstützt, die explizit ausgewählt werden können.
SSLeay bzw. OpenSSL sind eine freie Implementierungen für SSL, das "Secure Socket Layer", die hauptsächlich im WWW-Umfeld verwendet wird und auch in Deutschland verfügbar, weil es außerhalb der USA entwickelt wurde.
Netscape besitzt bereits gewisse eingebaute Security-Funktionalität, um sichere Verbindungen zu unterstützen. Leider ist der allgemein erhältliche Communicator diversen US-Exportbeschränkungen unterworfen, so dass dessen Sicherheitsstufe als nicht mehr ausreichend erachtet wird. Das Paket Fortify modifiziert den Communicator jedoch in der Weise, dass die sicheren Schlüssellängen wieder unterstützt werden.
Es gibt mehrere WWW-Server (u.a. Apache und Roxen Challenger), die durch Zertifikate abgesicherte Dokumente verwalten können. Dazu arbeiten sie z.B. mit dem SSLeay-Paket zusammen.
IPSec ist der Ansatz, Sicherheit schon auf den unteren Protokollschichten anzubieten. Der IPSec-Support, der im geistigen Umfeld von IPv6 entstanden ist, kann alleine deshalb maximal als experimentell gelten, da noch nicht alle Standardisierungsabläufe beendet sind. Mit IPSec kann man u.a. auch VPNs (Virtual Private Networks) realisieren.
PGP bzw. die freie Variante GnuPG bieten Tools zur asymmetrischen Verschlüsselung und Signierung von Dokumenten, insbesondere von E-Mail. Darüber hinaus existieren eine Reihe von Client- als auch Serverprogrammen zur Schlüsselverwaltung.
Insgesamt kann wohl gesagt werden, dass für Linux in diesem Bereich eine sehr breite Palette an Produkten bereitsteht, jedoch oft viel Expertenwissen notwendig ist, um die richtigen Tools und Methoden aus dem Angebot herauszusuchen und den jeweiligen Anforderungen anzupassen. Auf der anderen Seite ist dies jedoch ein sicherheitsimmanentes Problem: Out-of-the-Box-Lösungen haben oft zu starke Annahmen über die lokalen Gegebenheiten, die dann nur unzureichend die eigenen Sicherheitsanforderungen befriedigen. Den Linuxbenutzern und -entwicklern wird im Gegensatz zu Nutzern und Anbietern kommerzieller Standardlösungen eine erhöhte Sensibilität im Bereich von Sicherheitsfragen nachgesagt, was sich deutlich in der Art und Geschwindigkeit manifestiert, wie auftretende Probleme aufgespürt, verbreitet und behoben werden. Insgesamt spürt man das in der Produktqualität.
Die vergangenen Abschnitte haben gezeigt, dass Linux von den Angeboten seiner Architektur und den verfügbaren Programmen her eine hinreichende bzw. zum Teil anderen Betriebssystemen überlegene Vertraulichkeit bieten kann. Letztlich müssen wir jedoch auch beachten, dass ein System immer nur so gut sein kann, wie seine Konfiguration und Wartung. Die zur Verfügung stehenden Möglichkeiten wie z.B. sinnvolle Zugriffsbeschränkungen oder das Deaktivieren nicht benötigter Services müssen auch genutzt werden. Leider gibt es bei vielen Linux-Distributionen in diesem Bereich noch Nachholbedarf. Darüber hinaus besteht eine gewisse Uneinheitlichkeit zwischen ihnen, so dass ein nicht ganz unerheblicher manueller Konfigurationsaufwand nötig ist. Wer diesen nicht zu unterschätzenden Preis zu zahlen bereit ist, wird mit einem vertraulichkeitsbewahrenden System belohnt.
Um dem Rechner gegenüber überhaupt eine Identität zu erlangen muss sich ein Benutzer üblicherweise bekanntmachen, und zwar so, dass diese Bekanntmachung auch "authentisch" ist. Die Vergabe von Passwörtern ist ein verbreitetes Verfahren zur Authentifikation unter Unix-artigen Betriebsystemen, das auch von Linux unterstützt wird. Da das traditionelle Unix-Passwortsystem im wesentlichen auf einem DES-Durchgang mit geringer Schlüssellänge beruhte, und die verschlüsselten Passwörter frei zugänglich waren, öffnete sich mit dem Aufkommen leistungsfähiger Rechenanlagen die Möglichkeit, durch Brute-Force-Methoden diese Passwörter durch vollständiges Ausprobieren zu brechen.
Daher gibt es unter Linux schon lange die Möglichkeit, die verschlüsselten Passwörter mit einer größeren Länge zu versehen und an einer nichtöffentlichen Stelle im System zu speichern. Das Shadow-Password-Paket ist heute Teil des noch darüber hinausgehenden Authentifikationsmechanismus PAM (pluggable authentification modules), der regelbasiert für unterschiedliche Benutzer zu unterschiedlichen Zeiten unterschiedliche Authentifikationsmethoden benutzbar macht. Auf diese Weise können z.B. auch Chipkartenleser oder biometrische Verfahren unmittelbar in den Linux-Authentifikationsmechanismus eingebunden werden, wenngleich es noch nicht viele "schlüsselfertige" Lösungen dafür gibt.
Ein anderer Bereich der Zugangskontrolle sind Firewalls, mittels derer der Zugriff auf ein System oder ein Teilnetz aus einem anderen Netzbereich heraus nach unterschiedlichsten Kriterien eingechränkt werden soll. Die Anforderungen an einen Firewall können sehr unterschiedlich sein, so dass dieses Thema hier nur sehr knapp besprochen werden kann.
Der Linux-Kern selbst besitzt gewisse Firewall-Funktionalität, die mit dem Paket ipfwadm bzw. seit der Kernel-Version 2.2 mit dem Paket ipchains gesteuert werden kann. Mit letzterem können schon komplexere Filterregeln auf Paketebene formuliert werden, die insbesondere wie an einer Kette miteinander verknüpft werden können (daher der Name). Letztlich sind jedoch neben der reinen Kern-Funktionalität auch noch andere Aspekte eines Firewalls wichtig. Dazu zählen unter anderem eine übersichtliche Konfigurierbarkeit, eine lesbare Darstellung der Ereignisse am Firewall und unter Umständen eine dynamische Reaktion auf entdeckte Angriffsversuche. Darüber sollte eine Firewall Sicherheit nicht nur auf den unteren Netzwerkschichten durch Packet-Filtering bieten, sondern auch die Applikationsprotokolle überprüfen können. Nicht zuletzt sind noch Fragen der Performanz, Skalierbarkeit und der Integration verschlüsselter Übertragung relevant.
Obwohl gerade in letzter Zeit eine große Anzahl von Tools zu diesem Zweck in ersten Versionen vorgestellt wurden, so werden wohl dedizierte Firewall-Lösungen auf autonomen Rechnern (z.B. Drawbridge oder Firewall-1) für Bereiche mit sehr hohen Sicherheitsanforderungen noch vorgezogen. In mäßig sensitiven Bereichen kann ein Linux-basierter Firewall bereits heute ein guter Schutz vor "lästigem Ärger" durch Nachwuchs-Cracker sein.
In einer sicheren Umgebung ist es wichtig zu wissen, dass die zugegriffenen oder übertragenen Daten nicht durch Dritte modifiziert oder kompromittiert wurden. Viele der beschriebenen Maßnahmen zur Gewährleistung der Vertraulichkeit sichern auch die Integrität von Daten. Mit PGP können E-Mail-Nachrichten nicht nur verschlüsselt, sondern auch in der Weise signiert werden, dass selbst die kleinste Modifikation an der Nachricht auffallen würde.
Darüber hinaus gibt es eine Reihe von Hilfsmitteln, die die Integrität überwachen und deren Kompromittierung anzeigen. Das Tool tripwire legt beispielsweise Prüfsummen für alle Systemkomponenten an und überprüft regelmäßig, ob sich diese Werte noch immer mit dem Zustand auf der Festplatte übereinstimmen. Es sind noch eine Reihe ähnlicher Tests denkbar, von denen viele durch einzelne kleine Programme verifiziert werden. Gegenwärtig fehlen noch auf dem Markt etablierte integrierte Intrusion Detection Systems (IDS), die diese Einzelfunktionalitäten bündeln und handhabbarer machen, jedoch sind auch hier bereits erste Produkte, teilweise in Vorabreleases vorgestellt worden.
Auf unterster Ebene des Netzwerkstacks hat Linux gerade bei den neusten Kernelversionen seit V2.1 bzw. V2.2 einen großen Schritt nach vorne getan. Es wurden eine Reihe von zusätzlichen Überprüfungen eingeführt, die es schwieriger machen, Verbindungen zu übernehmen oder durch konstruierte Pakete Puffer zu überschreiben, um so andere Daten auszulesen oder zu modifizieren. Nichtsdestotrotz ist gerade das Netzwerk-Subsystem ein sehr komplexes Stück an Code, das nur wenige Experten (auch in der recht großen Linux-Entwicklergemeinde) komplett überblicken. So kann es - ebenso wie bei fast jedem Netzwerkstack - doch immer wieder einmal zu Exploits auf diesem Gebiet kommen.
Für viele Unternehmenskritische Bereiche ist es unabdingbar, dass gewisse Dienstleistungen auf zuverlässige Weise angeboten werden und auch jederzeit zur Verfügung stehen. Für einen Internet-Service-Provider, der seinen Web-Space mit dem Ziel verkauft, dass die entsprechenden Sites der Werbekunden möglichst häufig besucht werden, kann ein Ausfall eines Servers bares Geld bedeuten, vom Image-Verlust des Werbepartners einmal ganz zu Schweigen. Im folgenden Abschnitt untersuchen wir, inwiefern Linux diesen Anforderungen gerecht wird.
In einem konsolidierten Linux-System, das konfiguriert und freigegeben wurde, sind Systemabstürze, die durch die Software verursacht wurden, so gut wie nie zu beobachten. Um dies zu gewährleisten, darf ein Produktionssystem natürlich nicht für "Experimente" wie einen Hardwareausbau oder das Erneuern von wichtigen Systemkomponenten verwendet werden. In diesem Kontext können wir nicht auf die weitreichenden Konsequenzen von Hardwareeinflüssen eingehen und gehen daher im folgenden davon aus, dass Probleme im Sinne einer gegenseitigen pathologischen Beeinflussung von Komponenten vor der Freigabe für den Regelbetrieb gelöst wurden. Es ist keine Ausnahme, wenn ein solchermaßen konfiguriertes System über mehrere Monate, wenn nicht sogar Jahre ohne Neustart läuft.
Softwareseitig bietet unter Unix und somit auch unter Linux das Betriebssystem schon einen echten Speicherschutz auf Prozess-Ebene an, d.h. ein einzelnes fehlerhaftes oder böswillig manipuliertes Programm kann maximal den Abbruch des eigenen Prozesses bewirken, andere Prozesse werden davon nicht in Mitleidenschaft gezogen. An dieser Stelle muss einmal betont werden, dass das Konzept des Speicherschutzes wahrlich keine technologische Innovation darstellt, da es schon vor Jahrzehnten entworfen wurde. Erwähnenswert ist es nur insofern, als dass die Umsetzung auch funktioniert, was (unbegreiflicherweise) längst nicht bei jedem Betriebssystem der Fall ist.
An Hochverfügbarkeitslösungen für Linux, die auch einen Ausfall von Komponenten durch Verschleiß oder sonstige äußere Einflüsse berücksichtigen, wird von verschiedenen Herstellern und Projekten gearbeitet, aber es sind heute erst wenige Produktionssysteme wirklich verfügbar. In Teilbereichen kann man sich jedoch schon gegen eine ganze Reihe von Problemen absichern: Es sind sowohl Software- als auch Hardware-RAID-Lösungen für Linux verfügbar, die redundante und/oder fehlerkorrigierende Festplattenzugriffe und unter Umständen sogar das Wechseln der Festplatten im Betrieb ermöglichen. Es wird an einem transaktionsorietierten Dateisystem für Linux gearbeitet (dtfs), das sich aber noch im Entwicklungsstadium befindet. Weiterhin gibt es noch einige kleine Utilities, die bestimmte Hardwarekomponenten überwachen (z.B. Temperaturfühler oder Lüfter) oder den Systemzustand an einen Überwachungsrechner melden (Watchdog-Device).
Eine weitere Bedrohnung für die Verfügbarkeit eines Systems sind Denial-of-Service-Attacken, also der Versuch von außerhalb ein System so zu manipulieren oder zu belasten, dass es seine eigentlichen Dienste nicht mehr anbieten kann. Die meisten bekanntgewordenen DoS-Attacken, die tatsächlich zu Systemabstürzen geführt haben, sind wiederum innerhalb kürzester Zeit durch Patches unschädlich gemacht worden, was die Wichtigkeit des Mitverfolgens der einschlägigen Informationsforen zur Computer-Sicherheit unterstreicht. Im Weiteren ist es oft schwierig zu entscheiden, was tatsächlich als Kriterium für eine Denial-of-Service-Attacke gelten kann. Wird die Funktionsweise eines WWW-Servers durch Unmengen von Client-Anfragen beeinträchtigt, so muss individuell entschieden werden, ob ein Hardwareausbau notwendig ist oder ob beispielsweise geeignete Limitierungen für gewisse Clients eine bessere Wirkung zeigen. Für beide Punkte bietet Linux nach unserem Verständnis hinreichende Möglichkeiten.
Ein letzter Aspekt der Sicherheit eines Computersystems, der hier untersucht werden soll, ist die Frage, ob es ausreichende Möglichkeiten vom Betriebssystem gibt, die das Nachvollziehen von Ereignissen unterstützen, nachdem sie geschehen sind. Der Nutzen solcher Maßnahmen ist vielfältig: Zum einen können Ergebnisse von Ereignisprotokollen zur Fehlersuche und -behebung dienen, zum anderen können sie (soweit sie unverändert sind; siehe den Abschnitt über Integrität) beim Aufspüren von Eindringlingen helfen oder aber überhaupt erst eine quantitative Auswertung und Inrechnungstellung in Anspruch genommenener Resourcen bieten.
Um Systemereignisse festzuhalten, melden viele Services unter Linux diese an eine zentrale Instanz, den syslogd, der sie an geeigneter Stelle auf der Festplatte protokolliert oder direkt auf einer Konsole oder einem Benutzer ausgibt. Darüber hinaus führen bestimmte abgeschlossene Systeme wie z.B. WWW-Server oft ihre eigenen Logfiles. In Umgebungen mit besonders hohen Sicherheitsanforderungen kann es sinnvoll sein, auf Protokolldateien nur anhängenenden Zugriff zu erlauben, zum Beispiel durch die bereits beschriebenen erweiterten Dateisystem-Attribute oder durch einen Protokoll-Drucker, der jedes Ereignis sofort zu Papier bringt. Logfiles bringen natürlich nur dann etwas, wenn sie auch gelesen werden und in besonderen Situationen möglichst umgehend die notwendigen Schritte eingeleitet werden können. Es sind eine Reihe von Tools (z.B. logsurfer) auch unter Linux verfügbar, die regelbasiert unterschiedliche Protokolldateien auslesen und abhängig von Ereignis und Vorgeschichte unterschiedliche Aktionen (z.B. das sichere Herunterfahren des Rechners, die Deaktivierung von bestimmten Diensten oder das aktive Informationssammeln über den Grund des Ereignisses) und Alarme (Hinweis an angemeldete Benutzer, Versenden von Nachrichten per E-Mail oder Absetzen einer SMS-Nachricht an ein Mobiltelefon) auslösen können.
Für bestimmte Systembereiche wie die Nutzung von Festplattenkapazitäten oder von Netzwerkbandbreite gibt es darüber hinaus auch eine direkte Unterstützung aus dem Linux-Kern. Mittels des quota-Paketes kann die Belegung der Festplatten auf Benutzerbasis überprüft und gegebenenfals auch limitiert werden. Ein Netzwerkaccounting ist als Teil des schon erwähnten ipchains-Paketes verfügbar, sogar auf Benutzerbasis. Die Belegung von CPU- und Hauptspeicherressourcen kann schließlich mittels Prozess-Accounting ausgewertet werden.
Linux stellt somit weitreichende Möglichkeiten zur Protokollierung und Nachvollziehbarkeit von Systemereignissen zur Verfügung. Insgesamt muss bei der Konfiguration solcher Subsysteme darauf geachtet werden, dass einerseits zwar alle relevanten Ereignisse erfasst werden, aber auch z.B. die schützenswerten Interessen einzelner Benutzer gewahrt bleiben. Hier sind die einschlägigen Datenschutzgesetze zu beachten.
Nachdem in den letzten Abschnitten untersucht wurde, welche technischen Voraussetzungen Linux erfüllen muss, um es als sichere Umgebung einzusetzen, so wollen wir abschließend betrachten, welche konkrete Konsequenzen die Entscheidung für das freie Betriebssystem mit sich bringt.
Die reinen Anschaffungskosten für das Betriebssystem selbst und auch für zusätzliche Software sind in oft fast vernachlässigbar gering. Für die meisten der aufgeführten Anwendungsfälle ist freie Software verfügbar, in einigen Fällen sind natürlich normale Lizenzen zu erwerben:
Neben den in vielen Fällen günstigen Softwarekosten, erscheint auch die eingesetzte Hardware günstig beschaffbar zu sein. Durch die gute Ressourcenausnutzung von Linux erfüllt oft ein eigentlichen schon ausgemusterter Rechner noch eine Aufgabe, für die ansonsten ein Vielfaches hätte bezahlt werden müssen. Wenn jedoch Stabilität und Sicherheit eine große Rolle spielen, sollte man besser von "experimentellen Lösungen" absehen, da deren Wartung und Ersatz bei Ausfall auf Dauer kostenintensiver sind, als eine stabile Lösung von Anfang an. Das Gleiche gilt auch bei sehr spezieller Hardware, die noch nicht weit verbreitet ist: Die aufgewendeten Ressourcen, solche Komponenten sinnvoll zu integrieren, stehen oftmals in keinem guten Verhältnis mit ihrem wirklichen Mehrnutzen gegenüber Standard-Komponenten.
Neben den reinen Anschaffungskosten für Soft- und Hardware sind jedoch auch noch andere Faktoren zu berücksichtigen. Es bietet sich beispielsweise an, bereits beim Kauf einer Distribution über einen Support-Vertrag nachzudenken, wenn man keine eigenen Ressourcen dafür aufbringen kann. Support gibt es bereits als direktes Angebot von einigen Distributoren oder von unabhängigen Dienstleistern, die sowohl Installation und Konfiguration vornehmen können. Wenn man zwar auch hier leicht sparen kann, ist doch zu überlegen, inwiefern sich auf Dauer nicht die sicherlich teurere Beauftragung einer professionell agierenden Beratungsfirma lohnt, die dann auch langfristig und mit entsprechendem Know-How bei unerwarteten Problemen helfen kann.
Alternativ oder ergänzend sind auch eigene Mitarbeiter im Umgang und mit der Wartung des Linux-Systems zu schulen. Bei vielen der angebotenene Schulungen im Bereich von System- oder Netzwerkmanagement wird bei heterogenen Umgebungen heute schon auf Linux eingegangen; explizit für Linux ausgelegte Schulungen werden zwar vereinzelt bereits angeboten, sind aber noch relativ selten. Ebenfalls in den Kinderschuhen stecken die Bemühungen, ein Curriculum für ein Zertifikat abzustecken, das gewisse Kenntnisse im Umgang mit Linux bescheinigen soll.
Unserer Meinung nach ist Linux insbesondere im Bereich von kleinen oder mittelständischen Unternehmen, bis hin zu Abteilungs- und Spezialaufgaben in Großunternehmen ein sehr guter Kompromiss zwischen Sicherheit und aufzuwendenen Kosten. Nach unten hin sind insbesondere MS-Windows-Umgebungen heute doch noch einfacher zu warten, bieten aber auf der anderen Seite keinen wirklich nennenswerten Schutz vor Bedrohungen der Vertraulichkeit, Integrität und Verfügbarkeit. Diese Umgebungen kann man zwar auch durch geeignete Maßnahmen absichern, jedoch ist dann der genannte Vorsprung in einfacher Administration sehr schnell aufgebraucht, und es müssen teilweise absurde Einschnitte hinsichtlich der Funktionalität in Kauf genommen werden, so ist für MS-Windows NT beispielsweise eine C2-Zertifizierung zu erhalten - allerdings nur für Rechner, die an keinerlei Netzwerk angeschlossen sind!
Auf der anderen Seite gibt es eine Reihe von Speziallösungen, die explizit auf erhöhte Sicherheitsanforderungen ausgelegt sind und dementsprechend redundante Hardwareauslegung, erweiterte Schutzmechanismen oder bestimmte Zertifizierungen aufweisen können. Dies trifft auf eine Reihe von kommerziellen Unices wie Solaris, HP/UX oder Digital Unix zu. Vordergründig erscheint die Unterstützung oder Qualität in einzelnen Aspekten bei diesen Betriebssystemen besser zu sein, andererseits können die wenigsten dieser Produkte mit der Flexibilität und schnellen Reaktion im Linux-Bereich wirklich mithalten. Eine echte Alternative zu Linux sind dagegen die freien *BSD-Varianten.
So zeigt sich abschließend, dass Linux durchaus nach Abwägung der Einsatzziele und der dafür zur Verfügung stehenden Mittel dazu geeignet ist, Sicherheitsanforderungen zu entsprechen.