[FONT="]
Die Absicherung eines Unix(artigen)-Systems kann sehr aufwendig sein, sofern Sie alle Pakete modifizieren, das Dateisystem härten, den Kernel patchen und vielleicht noch weitere Userspace-Absicherungen durchführen wollen. Um als Administrator um diese Aufgabe herumzukommen, können Sie zu einer speziellen, auf maximale Sicherheit getrimmte Linux-Distribution greifen. [/FONT]
[FONT="]Im Folgenden stellen wir Ihnen die wichtigsten Alternativen vor. Selbstverständlich verfügen alle Systeme über die wichtigsten Sicherheitsmerkmale, etwa Shadow-Passwörter. Auch unterstützt ein Großteil PAM, Kerberos, chroot/jailing, One-Time-Passwörter.[/FONT]
[FONT="]* OpenBSD gilt als extrem sicheres System. Die Entwickler bemühen sich, den Code des Systems regelmäßig unter die Lupe zu nehmen und zu verbessern. Das OpenBSD-Projekt pflegt eigene modifizierte Versionen diverser Software-Pakete, unter anderem des GNU C Compilers (gcc-local) und des Apache Webservers. Zudem gehören Stack-Protection und integrierter Support für kryptographische Hardware zum Lieferumfang. Außerdem unterstützt OpenBSD systrace-Policies und enthält das von NetBSD stammende Dateisystem-IDS mtree. Das OpenBSD-Projekt entwickelt übrigens auch OpenSSH, den SSH-Dienst jeder Linux-Distribution und der meisten kommerziellen Unix-Systeme sowie aller anderen BSD-Derivate.[/FONT]
[FONT="]* TrustetBSD basiert auf dem FreeBSD-System. Es implementiert Access Control Lists, zusätzliche Schutzattribute im UFS2-Dateisystem, einen Open-Source-Nachbau des BSM von Solaris (OpenBSM), das freie PAM »OpenPAM« sowie die BSD-Variante von SeLinux (für Mandatory Access Control Policies) namens »SeBSD«.
Wie der Name bereits verrät, handelt es sich hierbei um eine gehärtete Version der Gentoo-Distribution. [/FONT][FONT="]Hardened Gentoo enthält – wie OpenBSD – Pro-Police-Absicherung und Kernel-Patches wie SeLinux, Rule Set Based Access Control (RSBAC) sowie grsecurity inklusive PaX.[/FONT]
[FONT="]* Hardened Linux ist eine Eigenentwicklung. Die Distribution basierte ursprünglich auf Slackware-Linux. Das Projekt existiert seit September 2006 und befindet sich derzeit noch in der Entwicklungsphase. Hardened Linux enthält den grsecurity-Kernel-Patch (inklusive PaX), modifizierte (gehärtete) Pakete, die standardmäßig sicherer sind als die Originale, und Userspace-Hardening.[/FONT]
[FONT="]Benutzer verwalten[/FONT]
[FONT="]Linux ist von Haus aus mehrbenutzerfähig, was sich nicht zuletzt am vielschichtigen Benutzer- und Rechtesystem zeigt. Ein normaler Benutzer hat dabei in aller Regel keinen Vollzugriff auf das System – und das ist unter Sicherheitsgesichtspunkten auch gut so. Schließlich sind Schreibrechte nicht zwingend nötig, um Programme auszuführen. Auch ist es in der Regel so, dass normale Benutzer Geräte verwenden wollen, ohne neue Treiber für die Hardware-Komponenten zu konfigurieren. Zudem gehen einen User die Dateien der anderen Benutzer nichts an, es sei denn, der Zugriff wird explizit erlaubt.[/FONT]
[FONT="]Da der Eigentümer eine Eigenschaft des Prozesses ist, sollten Serverdienste im Kontext spezieller Benutzerkonten laufen. Der Grund liegt auf der Hand: Wird ein solcher Dienst durch einen Exploit dazu gebracht, Code eines Angreifers auszuführen, läuft dieser Code unter einem eingeschränkten Benutzerkonto. Wenn der Administrator nicht als root am System arbeitet und auch keine Dienste im Kontext dieses Benutzerkontos laufen lässt, ist eine gewisse Grundsicherheit gewährleistet.[/FONT]
[FONT="]Eine weitere sicherheitsrelevante Eigenschaft von Linux ist das Logging. Mit Logging lässt sich nachvollziehen, was auf dem System vor sich geht und welche Ereignisse bereits stattgefunden haben. Im Falle einer Systemkompromittierung lässt sich so ermitteln, wer sich wann und von welcher IP-Adresse aus eingeloggt hat. Bei Serverproblemen ist es dank der Protokollierung meist möglich herauszufinden, wo das Problem liegt und wie es sich beheben lässt.[/FONT]
[FONT="]Natürlich besteht der erste Schritt eines Angreifers in den meisten Fällen darin, die Logfiles zu manipulieren oder zu löschen. Kommt im Netzwerk aber ein zentraler Logging-Server zum Einsatz, wird dem Angreifer die Arbeit erschwert.[/FONT]
Nicht alle Netzwerkdienste sind sinnvoll
Bei einem schlüssigen Sicherheitskonzept spielen die installierten Netzwerkdienste ebenfalls eine große Rolle. Besonders wichtig ist es, keine unnötigen Services laufen zu lassen und sich stets für die sicherere Variante zu entscheiden. So ist etwa die Nutzung des SSH-Dienstes, der Verschlüsselungsalgorithmen nutzt, dem Einsatz des betagten Telnet-Services vorzuziehen. Auf vielen Systemen finden sich die folgenden Dienste, obwohl sie in der Praxis auf Serversystemen kaum eine Rolle spielen.
[FONT="]famd:[/FONT] Der file alteration monitor daemon überwacht die Veränderung von Dateien. Löschen Sie etwa auf der Konsole eine Datei, sorgt famd dafür, dass die Ansicht im Dateimanager unter KDE aktualisiert wird. Allerdings gibt es nur wenige Serverdienste, die diesen Dienst auch wirklich benötigen, so dass der Service de-installiert werden kann.
[FONT="]portmap:[/FONT] Setzten Sie auf dem Server weder NFS noch famd ein, können Sie portmap komplett de-installieren. Alternativ dazu ist es aber auch möglich, den Dienst so zu konfigurieren, dass er nur das Loopback-Device überwacht.
[FONT="]identd:[/FONT] Mittels dieses Dienstes lässt sich herausfinden, unter welchen Benutzerrechten ein Prozess läuft, der eine bestimmte TCP-Verbindung geöffnet hat. Ein großes Sicherheitsrisiko, das keinesfalls als Service laufen darf.
[FONT="]fingerd:[/FONT] Über fingerd kann man bekanntermaßen herausfinden, welche Benutzer gerade am System eingeloggt sind. Diese Information ist zwar nicht geheim, sollte dennoch nicht auf einem öffentlichen Server zur Verfügung gestellt werden.
Neben den vier exemplarisch vorgestellten Netzwerkdiensten gibt es eine Reihe weiterer Services, die Sie aus Sicherheitsgründen nicht installieren sollten.
[FONT="]Interessante Security-Funktionen[/FONT]
Firewall und Intrusion Detection sind beileibe nicht die einzigen Schutzmechanismen, die Linux Ihnen bietet. Auch mittels Restricted Shels und chroot können Sie die Sicherheit erhöhen.
[FONT="]Restricted Shell:[/FONT] Eine Restricted Shell ist eine Shell, die die Tätigkeiten eines Benutzers stark einschränkt. Solch eine Shell kann eingesetzt werden, wenn nicht allzu vertrauenswürdige Benutzer Zugriff auf ein System bekommen sollen. Eine Restricted Shell schränkt die Aktionen des Benutzers wie folgt ein: Das Arbeitsverzeichnis kann nicht gewechselt werden. Die Shellvariablen $SHELL, $ENV und $PATH können nicht geändert werden. Programmnamen können nicht über relative oder absolute Pfade gestartet werden, sie müssen sich im $PATH befinden. Die Ausgabeumlenkung kann nicht verwendet werden.
[FONT="]Chroot:[/FONT] Im Normalfall hat ein Angreifer nach einem erfolgreichen Overflow-Angriff auf einen Dienst, der unter dem Benutzer root ausgeführt wird, vollen Zugriff auf das System. Unter Unix gibt es allerdings einen Syscall, mit dem das Wurzelverzeichnis eines Programmes gewechselt werden kann. Wird ein Programm in einer solchen chroot-Umgebung gestartet, kann das Wurzelverzeichnis beispielsweise von / auf /secure geändert werden. Dadurch kann der Zugriff auf die Dateien im /etc-Verzeichnis und auf Dateien anderer Dienste oder Benutzer des Systems unterbunden werden.
Sicherheit beginnt bei der Installation
Um ein System abzusichern, sollten Sie sich als Erstes die Frage stellen, welche Komponenten unverzichtbar sind. Schließlich stellen unnütz installierte Programme und unnötig laufende Dienste potenzielle Sicherheitsrisiken dar. Problematisch ist, dass die Installation diverser Linux-Distributionen und BSD-Derivate nicht unbedingt als minimal zu bezeichnen ist. Davon abgesehen gibt es natürlich noch weitere Methoden, um ein System abzusichern.
Vor allem bei Serversystemen spielt diese Absicherung eine große Rolle. Dabei sollten Sie auf drei Einsatzgebiete achten.
[FONT="]Minimalität:[/FONT] Je nach Distribution und Derivat wählen Sie während der Installation mehr oder weniger detailliert aus, welche Komponenten eingespielt werden sollen. Aber auch nach der Installation sollten Sie die Relevanz der installierten Software-Pakete überprüfen. Beispielswiese bringt ein standardmäßig auf einem Webserver installierter Portscanner nur einem Angreifer einen Vorteil. Selbstverständlich kann der Administrator solche Software zu Testzwecken installieren. Jedoch sollten diese Tools anschließend wieder entfernt werden.
[FONT="]Laufende Dienste:[/FONT] So gering wie möglich soll auch die Anzahl der im Hintergrund laufenden Dienste sein. Ist auf einem Webserver etwa der Port 25 – samt dahinter laufendem Exim – offen, stellt dies einen Angriffspunkt für potenzielle Hacker dar. Welche Dienste nach einer Installation laufen, erfahren Sie etwa über einen ps-Output oder durch einen Portscan mittels nmap.
[FONT="]Security-Software und Patches:[/FONT] Ein weiterer Schritt auf dem Weg zum gehärteten System besteht in der Installation von dedizierter Sicherheits-Software und Security-Patches. Letztere sind meist speziell auf einen bestimmten Bereich abgestimmt. So gibt es etwa Kernel-Patches, die das Ausführen von Datenbereichen im Hauptspeicher verhindern. Zwar kann es vorkommen, dass einige Programme damit Probleme haben, in der Regel beugen solche Patches Buffer-Overflow-Angriffen vor.
[FONT="]Regelmäßige Updates sind wichtig[/FONT]
Eine Update-Policy ist für die Sicherheit der Serversysteme extrem wichtig. Zwar lässt sich ein Webserver durch Firewalls absichern, auf die grundlegende Funktionalität – eben den angebotenen Serverdienst – kann aber von außen nach wie vor zugegriffen werden. Und ist die dort laufende Software nicht mehr aktuell oder werden signifikante Sicherheitslücken bekannt, sind Dienst, Rechner und damit das gesamte Netzwerk angreifbar.
Never change a running system – diese Devise befolgen viele Administratoren. Allerdings vergessen sie, dass sich dieser Grundsatz auf die Hardware beschränkt. Im Zusammenhang mit dem Betriebssystem und Sicherheits-Updates ist das Gegenteil der Fall. Denn auch in Bezug auf Kommandozeilen-Tools kommt es bei Servern auf Minimalität und Aktualität an.
Bringt etwa ein Angreifer den Webserver, der als Benutzer httpd läuft, durch eine Sicherheitslücke dazu, eingeschleusten Code auszuführen, kann er eine Shell auf dem Serversystem starten. Diese Shell läuft nun unter den Rechten des Webservers – als httpd. Weil dies dem Angreifer aber keinen großen Spielraum gibt, wird er früher oder später nach lokalen Sicherheitslücken suchen – als Grundlage dienen alle Tools, die er auf dem Server findet. Nachinstallieren kann der Hacker zu diesem Zeitpunkt aber nichts, was ihm Root-Rechte verschaffen würde.
Problematisch bei Updates ist, dass hinterher die Gefahr besteht, dass etwas nicht funktioniert. Daher sollten Updates – zumindest im Sinne neuer Programmversionen – nicht automatisch installiert werden, auch wenn einige Linux-Distributionen so eine Funktion anbieten.
Niemals ohne Firewall
Der mit Abstand wichtigste Schutzmechanismus, der Desktop-Rechner und Serversysteme abschottet, ist die Firewall. Ganz gleich, ob Software oder Hardware – Sinn und Zweck einer Firewall ist es, den Zugriff auf ein Rechnersystem beziehungsweise ein ganzes Netzwerk zu beschränken.
In der Praxis hat sich gezeigt, dass es besser ist, die Firewall dahingehend zu konfigurieren, dass ausschließlich die vom Administrator genehmigten Zugriffe erlaubt sind. Alle anderen Zugriffe blockt die Firewall rigoros ab. Dieses Prinzip wird als "Default Deny" bezeichnet. Zwei verschiedene Funktionsweisen haben sich im Zusammenhang mit Firewalls durchgesetzt: Paketfilter- und Personal-Firewalls.
Der erstgenannte Firewalltyp filtert, wie es der Name schon sagt, die im Netzwerk übertragenen TCP/IP-Pakete. Dazu arbeitet die Paketfilter-Firewall typischerweise als Gateway und untersucht die weitergeleitete oder für sie selbst bestimmte Kommunikation nach bestimmten Regeln, dem so genannten Ruleset. Die Regeln (siehe Kasten "Grundlegende Firewall-Regeln") einer solchen Firewall sind typischerweise nach dem Default-Deny-Prinzip aufgebaut.
Personal-Firewalls sind das, was in der Windows-Welt als Desktop-Firewall bekannt ist. Der Anwender installiert ein Programm, dessen Konfigurationsmöglichkeiten sich – überspitzt ausgedrückt – in der Wahl der Sicherheitsstufe erschöpfen. Der wichtigste Unterschied zur Paketfilter-Firewall: Eine Personal-Firewall schützt einen einzelnen Rechner eines Netzwerks auf Applikationsebene.
Will eine Anwendung mit dem Internet oder dem Netzwerk Daten austauschen, weist die Software den Nutzer darauf hin und fragt, ob diese Kontaktaufnahme erlaubt werden soll. Dies zeigt, dass eine solche Firewall auf einer anderen OSI-Ebene arbeitet als die Paketfilter. Auch blocken viele Personal-Firewalls grundsätzlich alle eingehenden Verbindungen ohne Rückfrage, da eine Workstation in den seltensten Fällen als Server fungiert.
[FONT="]Grundlegende Firewall-Regeln[/FONT]
Wie bereits erwähnt, sind die Regeln einer Firewall nach dem Default-Deny-Prinzip – ähnlich dem folgenden Schema – aufgebaut:
[FONT="]State-Regel[/FONT]: Die so genannten stateful Firewalls können sich den Status bereits aufgebauter Verbindungen merken. Mit anderen Worten: Wurde ein Verbindungsaufbau bereits erlaubt, so kann die aufgebaute Verbindung (established connection) ohne weitere Beachtung durchgelassen werden. Oft wird eine solche Regel aber auch implizit angenommen und muss nicht extra definiert werden. Außerdem handelt es sich bei nahezu allen halbwegs modernen Paketfilter-Firewall-Systemen um stateful Firewalls.
[FONT="]Erlaubte Kommunikation[/FONT]: In den folgenden Regeln werden die freizuschaltenden Ports und Wege definiert, zum Beispiel: Erlaubt ist der komplette Traffic, der aus dem internen Netz kommt und auf Port 80 (http) gerichtet ist. Damit wird etwa den Mitarbeitern einer Firma das Surfen im Netz erlaubt. In der Praxis sinnvoll ist es, auch den E-Mail-Verkehr und FTP-Dienste freizuschalten. Wie das Konzept exakt aussieht, hängt natürlich von den individuellen Bedürfnissen des Firewall-Nutzers ab. Spätestens an dieser Stelle ist eine genaue Kenntnis der TCP/IP-Protokoll-Suite unerlässlich, da sich ansonsten keine sinnvollen Regeln definieren lassen.
[FONT="]Catch-all-Regel[/FONT]: In der letzten Regel wird jeglicher weiterer Traffic verboten.
Werden die Regeln nun von oben nach unten abgearbeitet, wird die Catch-all-Regel genau dann aktiv, wenn keine vorherige Regel zutreffend ist. Dieser Traffic ist also nicht explizit erlaubt und wird durch diese Regel »aufgefangen« und blockiert.
[FONT="]Firewall unter Linux: netfilter/iptables[/FONT]
Damit ein Betriebssystem eine Paketfilter-Firewall unterstützen kann, muss der Kernel über die entsprechenden Funktionen verfügen. Diese Schnittstellen sind unter Linux als netfilter bekannt. Das entsprechende Frontend für den Userspace ist iptables. Mit dem iptables-Tool werden im Userspace nach einem definierten Format die Firewallregeln festgelegt. Diese werden dann über das netfilter-Interface im Kernel aktiviert. Ein iptables-Aufruf setzt sich – vereinfacht ausgedrückt – aus folgenden Komponenten zusammen:
[FONT="]Tabelle[/FONT]: Zuerst muss angegeben werden, um was für eine Regel es sich handelt – eine Paketfilter- oder eine NAT-Regel.
[FONT="]Kette[/FONT]: Anschließend wird spezifiziert, auf welche Kette sich der folgende Regelausdruck bezieht und ob die folgende Regel einzufügen oder zu löschen ist.
Filterausdruck: Damit wird festgelegt, auf welche Pakete sich die Regel bezieht. Fehlt dieser Filterausdruck, geht die Firewall davon aus, dass alle Pakete der betreffenden Kette gefiltert werden sollen.
[FONT="]Ziel[/FONT]: Zuletzt ist anzugeben, was mit den Paketen, diese alle Kriterien erfüllen, geschehen soll.
Quelle:Dieser Artikel stammt auszugsweise aus Linux – Das distributionsunabhängige Handbuch
Die Absicherung eines Unix(artigen)-Systems kann sehr aufwendig sein, sofern Sie alle Pakete modifizieren, das Dateisystem härten, den Kernel patchen und vielleicht noch weitere Userspace-Absicherungen durchführen wollen. Um als Administrator um diese Aufgabe herumzukommen, können Sie zu einer speziellen, auf maximale Sicherheit getrimmte Linux-Distribution greifen. [/FONT]
[FONT="]Im Folgenden stellen wir Ihnen die wichtigsten Alternativen vor. Selbstverständlich verfügen alle Systeme über die wichtigsten Sicherheitsmerkmale, etwa Shadow-Passwörter. Auch unterstützt ein Großteil PAM, Kerberos, chroot/jailing, One-Time-Passwörter.[/FONT]
[FONT="]* OpenBSD gilt als extrem sicheres System. Die Entwickler bemühen sich, den Code des Systems regelmäßig unter die Lupe zu nehmen und zu verbessern. Das OpenBSD-Projekt pflegt eigene modifizierte Versionen diverser Software-Pakete, unter anderem des GNU C Compilers (gcc-local) und des Apache Webservers. Zudem gehören Stack-Protection und integrierter Support für kryptographische Hardware zum Lieferumfang. Außerdem unterstützt OpenBSD systrace-Policies und enthält das von NetBSD stammende Dateisystem-IDS mtree. Das OpenBSD-Projekt entwickelt übrigens auch OpenSSH, den SSH-Dienst jeder Linux-Distribution und der meisten kommerziellen Unix-Systeme sowie aller anderen BSD-Derivate.[/FONT]
[FONT="]* TrustetBSD basiert auf dem FreeBSD-System. Es implementiert Access Control Lists, zusätzliche Schutzattribute im UFS2-Dateisystem, einen Open-Source-Nachbau des BSM von Solaris (OpenBSM), das freie PAM »OpenPAM« sowie die BSD-Variante von SeLinux (für Mandatory Access Control Policies) namens »SeBSD«.
Wie der Name bereits verrät, handelt es sich hierbei um eine gehärtete Version der Gentoo-Distribution. [/FONT][FONT="]Hardened Gentoo enthält – wie OpenBSD – Pro-Police-Absicherung und Kernel-Patches wie SeLinux, Rule Set Based Access Control (RSBAC) sowie grsecurity inklusive PaX.[/FONT]
[FONT="]* Hardened Linux ist eine Eigenentwicklung. Die Distribution basierte ursprünglich auf Slackware-Linux. Das Projekt existiert seit September 2006 und befindet sich derzeit noch in der Entwicklungsphase. Hardened Linux enthält den grsecurity-Kernel-Patch (inklusive PaX), modifizierte (gehärtete) Pakete, die standardmäßig sicherer sind als die Originale, und Userspace-Hardening.[/FONT]
[FONT="]Benutzer verwalten[/FONT]
[FONT="]Linux ist von Haus aus mehrbenutzerfähig, was sich nicht zuletzt am vielschichtigen Benutzer- und Rechtesystem zeigt. Ein normaler Benutzer hat dabei in aller Regel keinen Vollzugriff auf das System – und das ist unter Sicherheitsgesichtspunkten auch gut so. Schließlich sind Schreibrechte nicht zwingend nötig, um Programme auszuführen. Auch ist es in der Regel so, dass normale Benutzer Geräte verwenden wollen, ohne neue Treiber für die Hardware-Komponenten zu konfigurieren. Zudem gehen einen User die Dateien der anderen Benutzer nichts an, es sei denn, der Zugriff wird explizit erlaubt.[/FONT]
[FONT="]Da der Eigentümer eine Eigenschaft des Prozesses ist, sollten Serverdienste im Kontext spezieller Benutzerkonten laufen. Der Grund liegt auf der Hand: Wird ein solcher Dienst durch einen Exploit dazu gebracht, Code eines Angreifers auszuführen, läuft dieser Code unter einem eingeschränkten Benutzerkonto. Wenn der Administrator nicht als root am System arbeitet und auch keine Dienste im Kontext dieses Benutzerkontos laufen lässt, ist eine gewisse Grundsicherheit gewährleistet.[/FONT]
[FONT="]Eine weitere sicherheitsrelevante Eigenschaft von Linux ist das Logging. Mit Logging lässt sich nachvollziehen, was auf dem System vor sich geht und welche Ereignisse bereits stattgefunden haben. Im Falle einer Systemkompromittierung lässt sich so ermitteln, wer sich wann und von welcher IP-Adresse aus eingeloggt hat. Bei Serverproblemen ist es dank der Protokollierung meist möglich herauszufinden, wo das Problem liegt und wie es sich beheben lässt.[/FONT]
[FONT="]Natürlich besteht der erste Schritt eines Angreifers in den meisten Fällen darin, die Logfiles zu manipulieren oder zu löschen. Kommt im Netzwerk aber ein zentraler Logging-Server zum Einsatz, wird dem Angreifer die Arbeit erschwert.[/FONT]
Nicht alle Netzwerkdienste sind sinnvoll
Bei einem schlüssigen Sicherheitskonzept spielen die installierten Netzwerkdienste ebenfalls eine große Rolle. Besonders wichtig ist es, keine unnötigen Services laufen zu lassen und sich stets für die sicherere Variante zu entscheiden. So ist etwa die Nutzung des SSH-Dienstes, der Verschlüsselungsalgorithmen nutzt, dem Einsatz des betagten Telnet-Services vorzuziehen. Auf vielen Systemen finden sich die folgenden Dienste, obwohl sie in der Praxis auf Serversystemen kaum eine Rolle spielen.
[FONT="]famd:[/FONT] Der file alteration monitor daemon überwacht die Veränderung von Dateien. Löschen Sie etwa auf der Konsole eine Datei, sorgt famd dafür, dass die Ansicht im Dateimanager unter KDE aktualisiert wird. Allerdings gibt es nur wenige Serverdienste, die diesen Dienst auch wirklich benötigen, so dass der Service de-installiert werden kann.
[FONT="]portmap:[/FONT] Setzten Sie auf dem Server weder NFS noch famd ein, können Sie portmap komplett de-installieren. Alternativ dazu ist es aber auch möglich, den Dienst so zu konfigurieren, dass er nur das Loopback-Device überwacht.
[FONT="]identd:[/FONT] Mittels dieses Dienstes lässt sich herausfinden, unter welchen Benutzerrechten ein Prozess läuft, der eine bestimmte TCP-Verbindung geöffnet hat. Ein großes Sicherheitsrisiko, das keinesfalls als Service laufen darf.
[FONT="]fingerd:[/FONT] Über fingerd kann man bekanntermaßen herausfinden, welche Benutzer gerade am System eingeloggt sind. Diese Information ist zwar nicht geheim, sollte dennoch nicht auf einem öffentlichen Server zur Verfügung gestellt werden.
Neben den vier exemplarisch vorgestellten Netzwerkdiensten gibt es eine Reihe weiterer Services, die Sie aus Sicherheitsgründen nicht installieren sollten.
[FONT="]Interessante Security-Funktionen[/FONT]
Firewall und Intrusion Detection sind beileibe nicht die einzigen Schutzmechanismen, die Linux Ihnen bietet. Auch mittels Restricted Shels und chroot können Sie die Sicherheit erhöhen.
[FONT="]Restricted Shell:[/FONT] Eine Restricted Shell ist eine Shell, die die Tätigkeiten eines Benutzers stark einschränkt. Solch eine Shell kann eingesetzt werden, wenn nicht allzu vertrauenswürdige Benutzer Zugriff auf ein System bekommen sollen. Eine Restricted Shell schränkt die Aktionen des Benutzers wie folgt ein: Das Arbeitsverzeichnis kann nicht gewechselt werden. Die Shellvariablen $SHELL, $ENV und $PATH können nicht geändert werden. Programmnamen können nicht über relative oder absolute Pfade gestartet werden, sie müssen sich im $PATH befinden. Die Ausgabeumlenkung kann nicht verwendet werden.
[FONT="]Chroot:[/FONT] Im Normalfall hat ein Angreifer nach einem erfolgreichen Overflow-Angriff auf einen Dienst, der unter dem Benutzer root ausgeführt wird, vollen Zugriff auf das System. Unter Unix gibt es allerdings einen Syscall, mit dem das Wurzelverzeichnis eines Programmes gewechselt werden kann. Wird ein Programm in einer solchen chroot-Umgebung gestartet, kann das Wurzelverzeichnis beispielsweise von / auf /secure geändert werden. Dadurch kann der Zugriff auf die Dateien im /etc-Verzeichnis und auf Dateien anderer Dienste oder Benutzer des Systems unterbunden werden.
Sicherheit beginnt bei der Installation
Um ein System abzusichern, sollten Sie sich als Erstes die Frage stellen, welche Komponenten unverzichtbar sind. Schließlich stellen unnütz installierte Programme und unnötig laufende Dienste potenzielle Sicherheitsrisiken dar. Problematisch ist, dass die Installation diverser Linux-Distributionen und BSD-Derivate nicht unbedingt als minimal zu bezeichnen ist. Davon abgesehen gibt es natürlich noch weitere Methoden, um ein System abzusichern.
Vor allem bei Serversystemen spielt diese Absicherung eine große Rolle. Dabei sollten Sie auf drei Einsatzgebiete achten.
[FONT="]Minimalität:[/FONT] Je nach Distribution und Derivat wählen Sie während der Installation mehr oder weniger detailliert aus, welche Komponenten eingespielt werden sollen. Aber auch nach der Installation sollten Sie die Relevanz der installierten Software-Pakete überprüfen. Beispielswiese bringt ein standardmäßig auf einem Webserver installierter Portscanner nur einem Angreifer einen Vorteil. Selbstverständlich kann der Administrator solche Software zu Testzwecken installieren. Jedoch sollten diese Tools anschließend wieder entfernt werden.
[FONT="]Laufende Dienste:[/FONT] So gering wie möglich soll auch die Anzahl der im Hintergrund laufenden Dienste sein. Ist auf einem Webserver etwa der Port 25 – samt dahinter laufendem Exim – offen, stellt dies einen Angriffspunkt für potenzielle Hacker dar. Welche Dienste nach einer Installation laufen, erfahren Sie etwa über einen ps-Output oder durch einen Portscan mittels nmap.
[FONT="]Security-Software und Patches:[/FONT] Ein weiterer Schritt auf dem Weg zum gehärteten System besteht in der Installation von dedizierter Sicherheits-Software und Security-Patches. Letztere sind meist speziell auf einen bestimmten Bereich abgestimmt. So gibt es etwa Kernel-Patches, die das Ausführen von Datenbereichen im Hauptspeicher verhindern. Zwar kann es vorkommen, dass einige Programme damit Probleme haben, in der Regel beugen solche Patches Buffer-Overflow-Angriffen vor.
[FONT="]Regelmäßige Updates sind wichtig[/FONT]
Eine Update-Policy ist für die Sicherheit der Serversysteme extrem wichtig. Zwar lässt sich ein Webserver durch Firewalls absichern, auf die grundlegende Funktionalität – eben den angebotenen Serverdienst – kann aber von außen nach wie vor zugegriffen werden. Und ist die dort laufende Software nicht mehr aktuell oder werden signifikante Sicherheitslücken bekannt, sind Dienst, Rechner und damit das gesamte Netzwerk angreifbar.
Never change a running system – diese Devise befolgen viele Administratoren. Allerdings vergessen sie, dass sich dieser Grundsatz auf die Hardware beschränkt. Im Zusammenhang mit dem Betriebssystem und Sicherheits-Updates ist das Gegenteil der Fall. Denn auch in Bezug auf Kommandozeilen-Tools kommt es bei Servern auf Minimalität und Aktualität an.
Bringt etwa ein Angreifer den Webserver, der als Benutzer httpd läuft, durch eine Sicherheitslücke dazu, eingeschleusten Code auszuführen, kann er eine Shell auf dem Serversystem starten. Diese Shell läuft nun unter den Rechten des Webservers – als httpd. Weil dies dem Angreifer aber keinen großen Spielraum gibt, wird er früher oder später nach lokalen Sicherheitslücken suchen – als Grundlage dienen alle Tools, die er auf dem Server findet. Nachinstallieren kann der Hacker zu diesem Zeitpunkt aber nichts, was ihm Root-Rechte verschaffen würde.
Problematisch bei Updates ist, dass hinterher die Gefahr besteht, dass etwas nicht funktioniert. Daher sollten Updates – zumindest im Sinne neuer Programmversionen – nicht automatisch installiert werden, auch wenn einige Linux-Distributionen so eine Funktion anbieten.
Niemals ohne Firewall
Der mit Abstand wichtigste Schutzmechanismus, der Desktop-Rechner und Serversysteme abschottet, ist die Firewall. Ganz gleich, ob Software oder Hardware – Sinn und Zweck einer Firewall ist es, den Zugriff auf ein Rechnersystem beziehungsweise ein ganzes Netzwerk zu beschränken.
In der Praxis hat sich gezeigt, dass es besser ist, die Firewall dahingehend zu konfigurieren, dass ausschließlich die vom Administrator genehmigten Zugriffe erlaubt sind. Alle anderen Zugriffe blockt die Firewall rigoros ab. Dieses Prinzip wird als "Default Deny" bezeichnet. Zwei verschiedene Funktionsweisen haben sich im Zusammenhang mit Firewalls durchgesetzt: Paketfilter- und Personal-Firewalls.
Der erstgenannte Firewalltyp filtert, wie es der Name schon sagt, die im Netzwerk übertragenen TCP/IP-Pakete. Dazu arbeitet die Paketfilter-Firewall typischerweise als Gateway und untersucht die weitergeleitete oder für sie selbst bestimmte Kommunikation nach bestimmten Regeln, dem so genannten Ruleset. Die Regeln (siehe Kasten "Grundlegende Firewall-Regeln") einer solchen Firewall sind typischerweise nach dem Default-Deny-Prinzip aufgebaut.
Personal-Firewalls sind das, was in der Windows-Welt als Desktop-Firewall bekannt ist. Der Anwender installiert ein Programm, dessen Konfigurationsmöglichkeiten sich – überspitzt ausgedrückt – in der Wahl der Sicherheitsstufe erschöpfen. Der wichtigste Unterschied zur Paketfilter-Firewall: Eine Personal-Firewall schützt einen einzelnen Rechner eines Netzwerks auf Applikationsebene.
Will eine Anwendung mit dem Internet oder dem Netzwerk Daten austauschen, weist die Software den Nutzer darauf hin und fragt, ob diese Kontaktaufnahme erlaubt werden soll. Dies zeigt, dass eine solche Firewall auf einer anderen OSI-Ebene arbeitet als die Paketfilter. Auch blocken viele Personal-Firewalls grundsätzlich alle eingehenden Verbindungen ohne Rückfrage, da eine Workstation in den seltensten Fällen als Server fungiert.
[FONT="]Grundlegende Firewall-Regeln[/FONT]
Wie bereits erwähnt, sind die Regeln einer Firewall nach dem Default-Deny-Prinzip – ähnlich dem folgenden Schema – aufgebaut:
[FONT="]State-Regel[/FONT]: Die so genannten stateful Firewalls können sich den Status bereits aufgebauter Verbindungen merken. Mit anderen Worten: Wurde ein Verbindungsaufbau bereits erlaubt, so kann die aufgebaute Verbindung (established connection) ohne weitere Beachtung durchgelassen werden. Oft wird eine solche Regel aber auch implizit angenommen und muss nicht extra definiert werden. Außerdem handelt es sich bei nahezu allen halbwegs modernen Paketfilter-Firewall-Systemen um stateful Firewalls.
[FONT="]Erlaubte Kommunikation[/FONT]: In den folgenden Regeln werden die freizuschaltenden Ports und Wege definiert, zum Beispiel: Erlaubt ist der komplette Traffic, der aus dem internen Netz kommt und auf Port 80 (http) gerichtet ist. Damit wird etwa den Mitarbeitern einer Firma das Surfen im Netz erlaubt. In der Praxis sinnvoll ist es, auch den E-Mail-Verkehr und FTP-Dienste freizuschalten. Wie das Konzept exakt aussieht, hängt natürlich von den individuellen Bedürfnissen des Firewall-Nutzers ab. Spätestens an dieser Stelle ist eine genaue Kenntnis der TCP/IP-Protokoll-Suite unerlässlich, da sich ansonsten keine sinnvollen Regeln definieren lassen.
[FONT="]Catch-all-Regel[/FONT]: In der letzten Regel wird jeglicher weiterer Traffic verboten.
Werden die Regeln nun von oben nach unten abgearbeitet, wird die Catch-all-Regel genau dann aktiv, wenn keine vorherige Regel zutreffend ist. Dieser Traffic ist also nicht explizit erlaubt und wird durch diese Regel »aufgefangen« und blockiert.
[FONT="]Firewall unter Linux: netfilter/iptables[/FONT]
Damit ein Betriebssystem eine Paketfilter-Firewall unterstützen kann, muss der Kernel über die entsprechenden Funktionen verfügen. Diese Schnittstellen sind unter Linux als netfilter bekannt. Das entsprechende Frontend für den Userspace ist iptables. Mit dem iptables-Tool werden im Userspace nach einem definierten Format die Firewallregeln festgelegt. Diese werden dann über das netfilter-Interface im Kernel aktiviert. Ein iptables-Aufruf setzt sich – vereinfacht ausgedrückt – aus folgenden Komponenten zusammen:
[FONT="]Tabelle[/FONT]: Zuerst muss angegeben werden, um was für eine Regel es sich handelt – eine Paketfilter- oder eine NAT-Regel.
[FONT="]Kette[/FONT]: Anschließend wird spezifiziert, auf welche Kette sich der folgende Regelausdruck bezieht und ob die folgende Regel einzufügen oder zu löschen ist.
Filterausdruck: Damit wird festgelegt, auf welche Pakete sich die Regel bezieht. Fehlt dieser Filterausdruck, geht die Firewall davon aus, dass alle Pakete der betreffenden Kette gefiltert werden sollen.
[FONT="]Ziel[/FONT]: Zuletzt ist anzugeben, was mit den Paketen, diese alle Kriterien erfüllen, geschehen soll.
Quelle:Dieser Artikel stammt auszugsweise aus Linux – Das distributionsunabhängige Handbuch
