Teil 2: Den Server absichern
Praxistipp
Ich verwende zur Administration ein Notebook mit einem DynDNS-Client. So hoffe ich, dass ich immer von der Domain notebook.dyndns.org mich beim Server einlogge. Vorsicht, hier sollte eine DNS-Abfrage möglich sein.
Sollte dies nicht möglich sein, versuche ich mit einen Hop über meinen Server in Koblenz, mich auf dem zu pflegenden Server einzuloggen - normalerweise mit der festen IP-Adresse meines Servers, auf dem ich mich zuvor eingeloggt habe.
In dem von mir verwendeten Firewall-Skript können Sie explizit einen Client eingeben, von dem aus ein SSH-Login möglich sein sollte.
Was macht eine Firewall überhaupt?
Es gibt mehrere Arten von Firewalls. Sollten Sie Linux auf Ihrem Server installiert haben, dann haben Sie bestimmt schon etwas von der bekanntesten und einfachsten Art einer Firewall gehört. Hierbei werden IP-Pakete gefiltert und dann entweder einfach weitergeleitet oder geroutet (ACCEPT), ohne ICMP-Meldung verworfen oder gedroppt (DROP) oder verworfen und eine ICMP-Mitteilung über den REJECT an den Absender des Paketes geschickt.
Hierbei werden zudem noch weitere Informationen benötigt. Wenn dem Absender eine ICMP-Meldung mitgeteilt werden soll, benötigt man auf jeden Fall die IP-Adresse des Absenders (-s für Source), außerdem die IP-Adresse des Empfängers des Paketes (-d für Destination), die Portnummer des Absenders (--sport) und die Portnummer des Empfängers (--dport).
Was bedeutet ipfwadm, ipchains oder iptables?
Bei Linux sind die Firewallfunktionaltäten tief im Kernel integriert. Dies verdankt Linux seinen Kernelentwicklern, die bereits dem 2.0er-Kernel eine Firewallfunktionalität mit auf den Weg gaben. Kernel 2.0.x verwendete damals ipfwadm.
Bei jeder neuen Hauptversion wurden weiterentwickelte Module in den Kernel implementiert. So wurde im Kernel 2.2 ipchains implementiert, in Kernel 2.4 wurde iptables eingeführt, das in Kernel 2.6 beibehalten wurde. Hierbei werden durch das Steuerprogramm iptables/ipchains drei verschiedene Zustände der Verarbeitung erkannt, auf deren Basis ein Filter aufgebaut werden kann.
- INPUT chain
- Ein Paket ist aus irgendeinem Netz an unseren Server adressiert. Es wird vom Kernel verarbeitet und an die Serversoftware weitergeleitet.
- OUTPUT chain
- Das Paket wurde auf unserem Server generiert und versucht über den Kernel, an das Netzwerkinterface zu gelangen. Von dort aus wird es weiter an den Empfänger geleitet.
- FORWARD chain
- Ein Paket kommt an unseren Rechner an, ist allerdings nicht für diesen bestimmt. Es soll geroutet werden. Hierzu nimmt der Kernel das Paket an und versendet es über ein Netzwerkinterface weiter.
Testen der Firewall
Nachdem wir uns die Grundlagen näher angesehen haben, wollen wir nun den Einsatz einer Firewall testen. Das hier verwendete Firewall-Skript finden Sie auf konabi.de zum Download.
Zunächst testen wir unseren Server mit einem Portscan. Die folgende Ausgabe zeigt, dass dort zahlreiche Dienste noch aktiv sind und auf den unterschiedlichsten Ports ihre Dienste anbieten.
schroedi@mobil:~$ nmap 192.168.178.24 PORT STATE SERVICE 22/tcp open ssh 111/tcp open rpcbind 113/tcp open auth 445/tcp filtered microsoft-ds 806/tcp open unknown 6667/tcp filtered irc
Nachdem wir die Firewall gestartet haben, werden die ICMP-Anfragen nicht mehr beantwortet.
Den Linux-Kernel härten
Security-Patches
Wenn Sie sich eingehender mit dem Thema Serversicherheit auf Linux-Systemen beschäftigen, dann haben Sie sicherlich mitbekommen, dass ab und zu Fehler im Kernel vorkommen. Das liegt teilweise an der Tatsache, dass Linux in der Programmiersprache C geschrieben wurde und damit durch fehlerhafte Programmierung sogennannte Pufferüberläufe entstehen können.
Meistens werden zu diesen Schwachstellen auch Exploits angeboten. Manchmal sind sie sehr hilfreiche Tools, um seinen Server auf diese Schwachstelle zu testen. Leider haben auch andere Menschen auf solche Exploits Zugriff und können damit auch fremde Server testen.
Kernelpatch grsecurity
Das Projekt grsecurity geht unter anderem auf die Ablehnung des Openwall »Non Executable Stack Patches« durch die Kernelentwickler zurück. Damals wurde der Patch durch Linus Torvalds abgelehnt, da dieser meinte, dass der Stackspeicher-Schutz nicht das wichtigste Problem bei Linux ist. Leider aber zumindest eines davon. Zurückzuführen ist die Problematik wiederum auf das Problem mit der Programmiersprache C, das wir schon beschrieben haben. Angreifer haben sich in der Vergangenheit hauptsächlich auf Pufferüberläufe konzentriert, da sie hier den meisten Erfolg erwarteten.
Sie hatten Recht. In der Regel ist ein Pufferüberlauf-Angriff erfolgreich - außer Sie haben ein paar der hier beschrieben Sicherheitsaspekte beherzigt. Das GRSecurity-Patchset wurde um die Speicherschutzerweiterung PAX und eine Openwall-Portierung für den Kernel 2.4.x erweitert. Damit ist es möglich, sich gegen die folgenden Angriffstypen zu schützen.
- Einschleusen und Ausführen von beliebigen Code
- Ausführen von vorhandem Code, allerdings in einer anderen Programmreihenfolge
- Ausführen von vorhandem Programmcode mit falschen Daten
Diese Angriffstypen umfassen jede Art von Speicherschutzverletzungen, die durch Pufferüberläufe begangen werden können. Eine Ergänzung des GRSecurity-Patchsets mit den folgenden Funktionen des RSBAC-Sets bietet eine enormen Schutz gegen eine Vielzahl von Angriffen.
Ihr Server ist nun etwas sicherer geworden. Absolute Sicherheit werden Sie nicht erreichen können. Sie können sich nur gegen eine Vielzahl von Angriffen schützen. Am Beispiel der Anschläge des 11. Septembers haben Sie gesehen, dass absolute Sicherheit nie gewährleistet sein kann.
RBAC - Role Based Access Control
Wie Sie wissen, kennt Linux normalerweise nur die Rechte Lesen, Schreiben und Ausführen.
Außerdem ist die Möglichkeit vorhanden, setuid-Bits zu setzen. Dies sind meist Serverprogramme, die unter einem User installiert werden und diesem gehören, allerdings Root-Rechte bei der Ausführung übertragen bekommen können. Das Problem hierbei ist eigentlich, dass diese Programme, wenn sie gekapert werden, dem Angreifer ermöglichen, Operationen mit Root-Rechten auszuführen. Das heißt, der Angreifer ist im Besitz des allmächtigen Root-Rechte und kann alles mit Ihrem Server anstellen, was er will.
Möchten Sie den gesamten Umfang von GRSecurity nutzen, dann sollten Sie sich unbegingt das Tool gradmin von der Projektseite herunterladen. Mit gradmin haben Sie die Möglichkeit, in den Lernmodus zu gehen und den Normalbetrieb aufzuzeichnen.
In Teil 3 werden wir uns ausführlicher mit Kernel-Patches beschäftigen und mit diesem Wissen einen neuen sichereren Kernel bauen.
Eine weitere Möglichkeit, das System sicherer zu machen, ist der Einsatz eines monolitischen Kernels. Das ist ein Kernel, der alle Funktionen fest im Kernel einkompiliert hat und keine Module nachlädt.
Sinn macht auf jeden Fall ein Kombination der hier vorgestellten Möglichkeiten, um größtmögliche Sicherheit zu erreichen. Aber auch für monolithische Kernel kann es Exploits geben.
