UNIX - Hostsicherheit

Dem Titel kann man entnehmen, dass diese Seite der Sicherheit von Hosts in Netzwerken gewidmet ist. Ich habe mich entschieden über die Sicherheit von Unix-Hosts (und nicht Windows-Hosts) zu schreiben, da dies gerade für Leute die auf ihrem PC Linux laufen haben und viel bis sehr viel Zeit online verbringen interessant sein könnte zu wissen, welche Türen wem offen stehen und wie man den Rechner vielleicht nicht in eine Festung, jedoch in ein etwas schwerer einnehmbares Haus verwandeln kann.

Zugegebenermaßen ist die Gefahr für einen privaten PC der sich zwischen tausenden von mehr oder weniger anonymen DNS-Namen des Dialon-Pools eines grossen Providers verbrigt eher gering ist, einem Cracker in die Hände zu fallen, doch kann es nicht schaden etwas über das eigene System zu wissen und wenn man dann vielleicht später beruflich in diesem Bereich tätig werden will, kann es auch nicht verkehrt sein etwas über Sicherheit zu wissen und mit einfachen Methoden vertraut zu sein.
 
 
 
 

Inhalt

Ich möchte darauf hinweisen, dass diese Seite keinen Anspruch auf Vollständigkeit erhebt. Am Ende dieser Seite finden Sie Informationen über die Quellen die ich verwendet habe, sowie über weiterführende Literatur zu diesem Thema. Falls Sie sich mit dem Thema Sicherheit eingehender beschäftigen wollen, sollten Sie sich auf jeden Fall mit dem entsprechenden System (hier Unix) eingehend auseinandersetzen. In diesem Fall gibt es zwar viel Theorie, die man auch im Hinterkopf behalten sollte, doch ist auch die praktische Erfahrung nicht irrelevant! Für angehende Systemadministratoren empfiehlt es sich ein kleines LAN zu haben, in dem man mal etwas experimentieren kann. Dies ist vergleichbar mit der privaten Homepage mit der viele Webdesigner angefangen haben und sie nicht selten auch nebenbei weiterbetreiben. Es ist einfach etwas ungeschickt verschiedene Denial-of-Service Attacken wie beispielsweise die Socket-Bombe auf dem Zentralrechner der Firma auszuprobieren ;-)
 
 

Gefahren für einen Unix-Host

Ein Unix-Host ist an einigen Stellen verwundbar, das streitet niemand ab. Ich kann auch nicht versprechen hier alle aufzählen zu können, doch die bekanntesten dürften vertreten sein: Während die ersten beiden Attacken ohne direkten Zugriff auf den Host erfolgen können, benötigt der Angreifer für die weiteren Attacken einen gültigen Account (also Benutzername und Passwort) auf dem Host, der als Mittel des Angriffs fungieren soll. Um die Arbeit auf dem Host zu stören benötigt der Angreifer zwar nicht zwingend einen Account auf dem Host, doch ist dies häufiger der Fall.

Attacken, die den Host vom Netz trennen und/oder handlungsunfähig machen wird häufig als Denial-of-Service-Attacken (kurz DoS-Attacken) bezeichnet. Wie der Name schon andeutet, wird jemandem (nämlich den regulären Benutzern) ein Dienst (Service) verweigert. Dies kann entweder bei einem Webserver die Möglichkeit Seiten abzurufen sein, bei FTP-Servern die Möglichkeit Dateien up- oder downzuloaden, oder aber die Infrastruktur eines gesamten Netzes in Mitleidenschaft zu ziehen. Letzteres ist beispielsweise der Fall, wenn ein Router oder Proxy-Server ausser Gefecht gesetzt wird.

 Attacken, deren Ziel es ist den Host für andere Attacken zu verwenden sind dagegen schon etwas anspruchsvoller. Während für DoS-Attacken meist Programme exisieren, die nur noch die Angabe von einigen Parametern erfordern, benötigt ein Angreifer für die weiteren Attacken einen Zugang zu dem Host. Der am häufigsten verwendete Weg dürften die trojanischen Pferde sein, wobei auch Telnet-Accounts (durch leicht zu erratenden Passwörter oder durch Social Engineering ergattert) ein willkommenes Werkzeug sind.

 Wird Ihr Host für weitere Attacken eingesetzt, so kann es leicht vorkommen, dass Ihnen die Schuld dafür angelastet wird. Vor allem in Fällen, in denen Ihr Host zur Authentifikation bei anderen Systemen verwendet wird, wird man Ihnen schlechte Sicherheitsmassnahmen vorwerfen - der gute Ruf ist dann hinüber.

 Im den folgenden Kapiteln sollen die einzelnen Angriffstechniken erlätert werden. Falls jetzt jedem Administrator das Herz in die Hose rutschen sollte, weil hier die Methoden zum Angreifen von Rechnern, die zwar allgemein bekannt sind, aber trotzdem häufig für ungefährlich eingeschätzt werden, kann ich nur sagen: wenn jemand einen Host angreifen will, hat er viele Möglichkeiten an das Wissen dazu zu kommen. Die freundlichen Sprüche die "Bitte missbrauchen Sie dieses Wissen nicht" sind zwar nett, aber werden wohl kaum jemanden abschrecken. Gute und genaue Anleitungen und Erläuterungen der Methoden jedoch erlauben es sich besser dagegen zu schützen, und dieses Ziel ist auch der Sinn dieser Seite.
 
 

Offene Ports

Der Begriff offene Ports verleitet häufig zu einer falschen Ansicht der Tatsachen. Falls man sich nun denkt, ein Host der einige Ports offen hat, kann leichter angegriffen werden als einer, der keine Ports offen hat, mag man zwar generell nicht unrecht haben, doch ist die Quantität nur bedingt ein Massstab zur Bewertung. Zuerst einmal: ein Port ist offen. Diese Aussage ist nicht präzise genug. Sie will ausdrücken, dass auf einem bestimmten Port ein Programm als Server-Prozess auf Anfragen von Aussen wartet. Daran gibt es im Prinzip nichts auszusetzen. Die Gefahr besteht darin, dass ein solches Programm Fehler enthalten kann, die der Angreifer auszunutzen weiss. Nach einigen Überlegungen scheint es auch einleuchtend, dass die Zahl der möglicherweise fehlerhaften Programme mit der Zahl der Programme steigt. Jedoch vergisst man häufig, dass es sehr wohl Programme geben kann, die keine Buffer Overflows (1) zulassen, keine Hintertüren haben und keinen direkten Zugriff auf das Sytem ermöglichen. Solche Programme auf Ports laufen zu haben ist nicht unverantwortlich, sondern der Sinn eines Servers! Wenn man aus Angst, dass der Webserver fehlerhaft sein könnte einen Host ins Internet stellt, der keine Ports offen hat, ist er nur Ballast (es sei denn, er fungiert als Router, Gateway oder dergleichen).

 Die Philosophie "je mehr Dienste laufen, desto mehr Dienste können gestört werden und desto weniger Dienste sind für Benutzer benutzbar" zeigt schon nach wenigen Augenblicken ein paar Ungereimtheiten: wenn ein Dienst gar nicht erst angeboten wird, kann er auch nicht verwendet werden.
Was ich zu verdeutlichen versuche ist, dass es der Sinn eines Servers ist, mit dem Benutzern zu interagieren und deren Wünsche zu erfüllen. Ob er auch die Wünsche des Angreifers erfüllt ist eine Frage der Programmierung des Servers, nicht der Tatsache dass er existiert!

 Langer Rede kurzer Sinn: alle nichtbenötigten Ports sollten geschlossen werden und die angebotenen Dienste sollten sorgfältig ausgewählt sein (sowohl die Art der Dienste als auch die Programme die diese Dienste erfüllen). Eine Selbstmordhost wüde zum Beispiel dem Benutzer den Dienst anbieten eigene PERL-Skripte für die CGI-Unterstützung einer Homepage auf dem Server laufen zu lassen. Dies ist der Dienst. An sich schon gefärlich, oder? Nun zum Programm: wie wäre es, wenn es sätliche Programme die der Benutzer uploaded ohne Bemerkung von wem sie sind oder woher sie kommen mit dem SUID-Bit versetzt und als Root laufen lassen würde. Blöde, oder? Sie sollten dafür sorgen, dass Dienste und Programme vor Inbetriebnahme genau durchdacht werden und nur mit den nötigen Rechen laufen. Die Regel zur Vergabe von Rechten: so wenig wie möglich und so viel wie nötig.

 Wie man Ports verschliesst lesen Sie unter Schutz gegen Angreifer.
 
 

Trojanische Pferde und fremder Code

Trojanische Pferde gibt es auch für Unix! Natürlich denkt man bei dem Begriff trojanische Pferde zuerst an Back Orifice, NetBus oder die T-Online Power Tools. Sie zielen auf Windows-Rechner, weil hier die Rechtevergabe es in der Regel jedem erlauben die Startdateien zu manipulieren und daher der fremde Code bei jedem Booten ausgeführt wird. Unter Unix kann nur Root die Startdateien manipulieren, aber das ist ja insofern nicht so schlimm, als das viele Programme als Root ausgeführt oder installiert werden müssen. So ist es zum Beispiel nicht schwer für ein Makefile unter dem Target "install" rechlich Unfug anzustellen. Vom offensichtlichen Kernel überschreiben bis hin zum Austauschen des Telnet-Servers gegen ein eigenes Exemplar, das eine Hintertür hat die dem Benutzer Root-Rechte beschafft - vieles ist denkbar. Zusätzliche Programme fallen hierbei eher auf, da sie unbekannt sind und ein Systemadministrator in der Regel weiss welche Dienste laufen. Nach einem netstat -a wird er sehen ob da etwas lauscht das dies nicht soll. Falls aber reguläre Programme einfach ausgetauscht werden, fällt dies weniger auf. Hierzu gibt es Programme, die Checksummen erstellen und feststellen, ob sich Dateien verändert haben. Mehr zu diesen Programme finden Sie unter Schutz gegen Angreifer.

 Fremder Code ist ein schwammiger Begriff. Trojanische Pferde fallen darunter, aber auch Viren bzw. durch Sicherheitslücken ausgeführte "Benutzerdaten". Dies kann entweder direkt geschehen, indem ein Perl-Script zum Beispiel mit Systemaufrufen eine Datenbank durchsucht (z.B. mit grep) und die Benutzerdaten Sonderzeichen enthalten, die von der Shell interpretiert werden (beispielsweise | oder &&). Andere Sicherheitslücken entstehen durch Buffer Overflows (1). Hierbei wird ein Puffer mit mehr Daten beschrieben, als hineinpassen. Wenn der Angreifer den Quelltext des Programmes das er damit angreift zur Verfügung hat, kann er Angriffe ersinnen, die dies zu seinem Nutzen tun. Buffer Overflows hingegen sind vermeidbare Programmierfehler und werden bei Programmen für Unix zum Teil schnell entdeckt, sofern der Quelltext frei verfügbar ist.
 
 

Denial-of-Service Attacken

Das Ziel der Denial-of-Service Attacken ist wie der Name schon sagt das Behindern des Hosts an der Erfüllung von Diensten. Dies kann auf mehreren Ebenen erfolgen. Entweder wird der ganze Host vom Netz getrennt (zum Beispiel durch Ping-flooding), oder aber er wird durch einen Fehler im Betriebssystem oder einer Anwendung gecrasht (zum Beispiel mit teardrop, bonk oder land). Die dritte Möglichkeit besteht darin einen Dienst gezielt zu stören (zum Beispiel Webserver durch SYN-flooding). In jedem dieser Fälle ist das Ziel anderen die Arbeit mit dem Host zu erschweren oder sie ganz zu unterbinden. Bei Systemcrashs werden auch lokale Dienste gestört und es kann Datenverlust auftreten, wenn ungeschriebene Caches verloren gehen. Ein Beispiel für einen lokalen Fehler der bei Linux-Systemen zu grossen Problemen (kernel panic) führen kann ist die Socket-Bombe. Der Fehler der hier ausgenutzt wird ist in der garbage-collection des Netzwerksubsystems. Kurz: es werden mehr sockets erstellt als erstellt werden können. Den Quelltext hierzu findet man bei Suchmaschinen mit den Stichworten "socket-bomb", "garbage.c" oder "garbage collection".

 Für Denial-of-Service Attacken benötigt der Angreifer in der Regel keinen Account auf dem Host den er angreifen will, sondern nur die IP-Adresse. Anders bei Denial-of-Service Angriffen, die wie die Socket Bombe lokal sind, hierzu ist selbstverständlich ein gültiger Benutzername und Passwort notwendig.

 Über DoS und DDoS (Distributed DoS) Attacken gibt es schon sehr viele Texte, interessante Informationen finden Sie auch in (2).
 
 

Bandbreite und Probleme damit

Die Bandbreite ist der Durchsatz der Verbindung zum Internet. Probleme können auftreten, wenn ein oder mehrere Angreifer dafür sorgen, dass Ihnen diese Bandbreite ausgeht. Gemeint ist Ping-flooding bzw. SYN-flooding. Diese Begriffe gehüren zwar in den DoS bzw. DDoS-Bereich, doch haben sie gerade in letzter Zeit für Aufsehen gesorgt (amazon, e-bay, yahoo). Der Sachverhalt beim Ping-flooding ist ganz einfach: ein Ping (ein ICMP-Paket das zur Diagnose von Netzwerkproblemen abgeschickt wird) wird von dem Zielhost mit einem Antwortpaket gleicher Grösse beantwortet. Wenn nun mehr Pings eingehen, als der Host beantworten kann, kann er sich nicht mehr um die anderen Dienste, die seinen eigentlichen Sinn ausmachen, kümmern. Hierbei hat natürlich nur der Angreifer eine Chance, der über eine grössere Bandbreite verfügt, als der Angegriffene. Da dies oft etwas schwierig zu bewerkstelligen ist, haben sich Angreifer das Verfahren der DDoS Attacke zu Nutze gemacht: sie installieren auf vielen Rechnern mit geringerer Bandbreite trojanische Pferde, die auf Befehl an eine Adresse pings senden. Hat man nun ein Ziel mit 10 MBit/s und 200 Angreifer mit ISDN, so kommt man auf mehr Bandbreite (nänlich rund 12,5 MBit/s) und kann dieses Ziel lahmlegen. Na und, 200 Angreifer sind viel meinen Sie? Und was ist, wenn ein Angreifer Ihr System kompromitiert und dazu missbraucht? Wenn eine Firma eine Netzanbindung von 10 MBit/s hat und der oder die Angreifer entsprechend koordiniert 20 dieser Verbindungen auf ein Ziel ansetzen können - schon geht es um Grössenordnungen von 200 MBit/s. Und das beste (für die Angreifer): die Pakete gehen von den missbrauchten Hosts aus und auf sie fällt zuerst der Verdacht.

 Mit SYN-Floodern verhält es sich nun recht ähnlich. Zuerst ein kleiner Ausflug zum Netzwerkprotokoll TCP: eine Verbindung wird nach dem three-way-handshake aufgebaut:

Das SYN-Paket ist der erste Schritt: es fragt nach einer Verbindung. Nun gibt es Programme, die viele dieser Pakete (und nur diese Pakete) losschicken. Das Ziel denkt nun, dass sich viele Clients verbinden wollen - und da ist der Trugschluss! Sie warten also brav bis zum timeout auf die weiteren Schritte und blockieren damit die Verbindung für andere, reguläre Clients. Diese Angriffe können ebenfalls auf mehrere Angreifer verteilt werden.
 
 

Passwortsicherheit

Das Kapitel Passwortsicherheit lässt sich mit wenigen Worten abfertigen: Passwärter sind nur sicher, solange sie geheim bleiben. Wählt man nun zu einfache Passwörter (z.B. die Vornamen der Benutzer) so können diese mit wenig Aufwand geknackt werden - der Host steht dem Angreifer für weitere Angriffe offen. Die Annahme, ein Host auf dem Telnet laufen würde wäre unsicherer als einer auf dem kein Telnet läft, ist zwar insofern nicht falsch, als dass nur durch die Möglichkeit sich einzuloggen auch die Möglichkeit erratene Passw¨rter zu verwenden gegeben ist. Aber: wenn niemand die Passwörter kennt und der Server frei von Fehlern ist (Buffer Overflows etc.) ist nichts dagegen einzuwenden. Viel richtiger ist also: ein Host auf dem "schlechte" Passw¨rter verwendet werden ist zusammen mit einem Telnet-Dienst unsicher.
Über das Ausdenken guter Passwörter sind ebenfalls schon viele Dokumente verfasst worden - schauen Sie einfach mal am Ende dieser Seite nach.
 
 

Fortgeschrittene Techniken

Zu den fortgeschrittenen Techniken gehören IP-spoofing, IP-Hijacking und das Ausnutzen von Vertrauensbeziehungen von Hosts untereinander. Diese Techniken erfordern meist gut Kenntnisse der Ziele und der Zielbetriebssysteme. Es gibt ausser den hier genannten Techniken noch zahlreiche weitere Techniken, die als fortgeschritten bezeichnet werden sollten, doch werde ich mich diesen dreien zuwenden, um den Rahmen des Textes nicht zu überstrapazieren.

 Das IP-spoofing ist vom Prinzip her noch einfach: die Quell-IP-Adressen eines Paketes wird vera¨ndert, so dass das Ziel annimmt, es käme von einem anderen Host. Der Nachteil dabei, wenn man nur die Quell-IP-Adresse des Paketes ändert ist, dass man keine Antwort bekommen wird (da dass Paket an den scheinbaren Sender aber wirklichen Besitzer der IP-Adresse reroutet wird). Will man eine E-Mail mit einem gefälschteb Absender verschicken, kann man sich dieses Verfahren zu Nutze machen, indem man "errät", was der Zielhost (genauer: der Mail-Dienst des Zielhosts) als nächstes hören will. Man geht dann davon aus, dass alles erfolgreich verläft und handelt als hätte man eine entsprechende Rückmeldung des Hosts bekommen. Dies geht natürlich nur, wenn es keinen Host gibt, der auf die Pakete antwortet. Hierzu stehen die DoS-Attacken zur Verfügung. Wenn der Host, dem die Adresse wirklich gehört, gerade beim neustarten ist, kann er nicht antworten. Und wenn er nicht da ist, die Pakete aber trotzdem geroutet werden, kommt erst nach einiger Zeit der timeout zum Tragen und der Vorgang würde abgebrochen werden - doch ist bis dahin die E-Mail schon längst mit falscher Herkunft verschickt.
Eine weitere Möglichkeit ist Hostnamen zu spoofen, indem man einen ganzen DNS-Server ersetzt ...

Das IP-Hijacking ist dagegen schon erheblich komplizierter. Das Ziel dabei ist es, eine bestehende Verbindung zu übernehmen (to hijack, engl: entführen). Dies wird versucht, wenn beispielsweise eine Athentifizierung stattgefunden hat (z.B. durch ein Passwort) und die Verbindung somit schon ohne weitere Abfragen direkten Zugriff auf das Zielsystem verspricht. Hierbei gibt es allerdings einige Probleme: die IP-Sequenznummer muss erraten werden. Hierbei handelt es sich um eine 32 bittige Zahl, die bei jedem Paket um einen bestimmten Betrag erhöht wird (meist 50 oder 100). Der Gedanke dabei ist, dass die Pakete nicht verwechselt werden können, denn angenommen unser Host versendet 100 Pakete pro Sekunde, so ist die Zahl erst nach etwa 5 Tagen wieder auf etwa gleicher Höhe - so lange schwirrt kein Paket herum, egal wie schlecht es geroutet wird. Nun, hat man die Sequenz erraten, muss man noch wie beim IP-Spoofing die "original"-Quelle aus dem Weg schaffen. Wie man sieht erfordert IP-Hijacking gute Kenntnisse der Systeme, doch sind die Effekte auch nicht zu unterschätzen!

 Das Ausnutzen von Vertrauensbeziehungen kann entweder bei Authenifizierung durch die IP-Nummer durch IP-Spoofing erreicht werden, oder aber bei direktem Zugriff auf das eine "Opfer"-System durch den Effekt den man vom Proxy-Server kennt: 

/-----------\         /--------\                /--------\
| Angreifer | ----- > | Host A | -------------> | Host B |
\-----------/         \--------/                \--------/
Der Angreifer tut so als wäre er regulärer Benutzer von Host A, in Wahrheit hat sich der Angreifer einfach nur auf Host A eingeloggt und operiert von dort aus.
 
 

Schutz gegen Angreifer

Der Schutz gegen Angreifer ist ein wichtiges Kapitel. Ich werde hier zu jeder beschriebenen Attacke eine Schutzmöglichkeit sofern vorhanden aufzeigen. Sie sollten auf jeden Fall unter "weiterführende Literatur" am Ende der Seite die Texte bei rootshell durchlesen, falls Sie die Aufgabe haben ein System effektiv zu sichern. Es ist zwar viel Lesestoff, aber erstklassiger Natur.

 Zu den Möglichkeiten sich zu schützen:

Offene Ports

Trojanische Pferde und fremder Code Denial-of-Service Attacken Bandbreite und Probleme damit Passwortsicherheit Fortgeschrittene Techniken Noch ein guter Tipp: immer auf dem neuesten Stand bleiben ist enorm wichtig. Hierzu kann ich nochmals nur Foren oder Mailinglisten ans Herz legen.
 
 

Quellen und weiterführende Literatur

(1) "Buffer Overflows - eine Einführung". Dieser Text stammt ebenfalls von mir und ist auf meiner Homepage zu finden

(2) "hacker's guide" von anonymous. Dieses Buch informiert recht gründlich über das Internet und die verschiedenen Aspekte (Protokolle, Entstehung, etc.) sowie über einige Aspekte des Hackens inklusive einiger Grundtechniken. ISBN 3-8272-5460-4.

 (3) http://rootshell.com/beta/documentation.html

 (4) http://www.securityfocus.com/

 (5) http://www.cert.org/

 (6) http://phrack.infonexus.com/

Letztes Update: 19. Oktober 2K
Maverick <maverick@dragonriders.de>