vorheriges KapitelInhaltsverzeichnisStichwortverzeichnisnächstes Kapitel


22

Wer ist verantwortlich?

Ich habe in diesem Buch immer wieder die Begriffe Root und Administrator verwendet. Nun kam mir der Gedanke, daß der Durchschnittsleser vielleicht gar nicht weiß, was diese Begriffe genau bedeuten. Deshalb möchte ich sie in diesem kurzen Kapitel näher erläutern.

22.1 Die allgemeine Vorstellung

Die meisten Benutzer arbeiten hauptsächlich an einer einzelnen Workstation. Ihre erste Erfahrung mit einem Rechner machen sie normalerweise zu Hause oder in der Schule. Selbst wenn der Rechner an ein Netzwerk angeschlossen wird, denkt der Benutzer vielleicht weiterhin, daß nur dieser Rechner für ihn relevant ist. D.h., er sieht seinen Rechner als separate Einheit, ohne die Existenz (oder mögliche Existenz) der anderen Rechner wahrzunehmen.

In der Mehrzahl der Fälle ist das auch richtig. Die meisten Workstations haben eine lokale Festplatte, und auf dieser Festplatte befindet sich lokale Software, nämlich ein Betriebssystem und verschiedene Anwendungen. Plattenlose Clients sieht man nur beim harten Kern der Netzwerke oder an Universitäten.

Hinweis:

Ein plattenloser Client ist ein Rechner, der keine lokale Festplatte hat und deswegen auf andere Weise gebootet werden muß. Eine Möglichkeit ist das Booten mit einer Diskette, von der die erforderlichen Treiber zur Ansprache der Ethernet-Karte des Rechners geladen werden. Die Netzkarte wird dann mit einer Broadcast-Anfrage auf dem Netzwerk nach der Identität des Rechners fragen und weitere Informationen und Programme aus dem Netz bekommen. Das ist z.B. bei Novell-NetWare-Netzwerken üblich. Dort benutzt man eine Diskette mit dem Ethernet-Treiber, der LAN-Adapter-Software und einer kleinen Shell. Eine andere Möglichkeit ist, daß die Workstation eine Firmware (oder andere auf einen Teil der Platine hardcodierte Software) hat, die eine Boot-Sitzung über ein Netzwerk via Ethernet oder ein anderes Protokoll initiieren kann. Dies ist bei Unix-Netzwerken üblicher; sie verwenden X-Terminals oder entfernte Boot-Dienste.

Die meisten Benutzer lernen durch ihre Computer zu Hause den Umgang mit Rechnern. Im Gegensatz zu den Rechnern am Arbeitsplatz, deren Verwendung auf ein einziges Programm beschränkt sein kann und die vielleicht auf einer veralteten Plattform laufen, haben die Benutzer auf ihren Rechnern zu Hause die alleinige Kontrolle. Sie können navigieren, Programme ausführen und Dateien löschen, wie es ihnen beliebt (leider oft zu ihrem Schaden). Der durchschnittliche Anwender hat oft wahrscheinlich nur eine vage Vorstellung davon, wie ein Netzwerk funktioniert. Und es gab - bis jetzt - ja auch noch gar keinen Grund dafür, sich mit Netzwerken auskennen zu müssen.

In einem Netzwerk muß es eine zentrale Kontrolle über die einzelnen Rechner geben. Nehmen Sie z.B. die Verwendung von Nameservern. Ein Name-Server hat die Aufgabe, Internet-Adressen von Hostnamen aufzulösen. Jedes richtige Netzwerk im Internet hat einen solchen Name-Server. Wenn ein Rechner im Netzwerk die Adresse des Name-Servers nicht kennt, kann dieser Rechner Internet-Hostnamen nicht in die zugehörigen IP-Adressen auflösen. Die Adresse des Name-Servers muß sich daher irgendwo auf der Festplatte befinden. Bei Unix-Netzwerken befindet sich diese Information im allgemeinen in der Datei /etc/ resolv.conf. Auf der Macintosh-Plattform wird sie in den MacTP- oder Open-Transport- Einstellungen gespeichert (die im allgemeinen über das Kontrollfeld-Menü zugänglich sind). Und auf der Microsoft-Windows-Plattform wird sie (zumindest für Einwähl- Accounts) in den einzelnen DFÜ-Netzwerk-Konfigurationen gespeichert. Das geschieht normalerweise über die TCP/IP-Einstellungen der Verbindung (siehe Abb. 22.1).


Abbildung 22.1: TCP/IP-Einstellungen einer Verbindung: der Name-Server

Die Verwendung eines Name-Servers ist nur ein Beispiel für die Zentralisierung von Informationen, damit einfacher auf diese zugegriffen werden kann. Archie-Server können dazu verwendet werden, in der ganzen Welt nach Dateien zu suchen; Sie könnten z.B. nach einer bestimmten Datei suchen und herausfinden, daß sie nur im Iran existiert. Das Archie-System arbeitet jedoch anders, als Sie vielleicht denken. Es schwärmt nicht in der ganzen Welt aus und sucht jeden Rechner im Internet nach der gewünschten Datei ab. Statt dessen teilen die Administratoren von Netzwerken zentralen Archie-Servern den Inhalt ihrer Festplatten mit. Das ist deshalb sinnvoll, weil es natürlich einfacher ist, eine einzige Datenbank auf einem Archie-Server zu durchsuchen, als Verbindungen in die ganze Welt zu starten. Mit Hilfe von ganz einfachen Techniken können Archie-Server und -Gateways auf diese Weise etwas leisten, was wie ein modernes Wunder aussieht.

Auch ein kleines Netzwerk hat viele zentrale Ressourcen, wie z.B. Datei-Archive, Anwendungen oder Adreßdatenbanken. Die zentrale Verwaltung dieser Ressourcen sorgt dafür, daß das System reibungslos und effektiv läuft. Stellen Sie sich z.B. vor, daß jeder im Netzwerk seiner Workstation jede beliebige Ethernet- oder IP-Adresse zuweisen könnte. Woher sollten die anderen Rechner wissen, welche Adresse das ist? Das würde eine Menge Verwirrung stiften. In einer solchen Umgebung könnte von verläßlichem Datenaustausch wohl keine Rede mehr sein.

Moderne Netzwerke werden außerdem mit einem gewissen Grad an Ökonomie entworfen, nicht nur aus finanzieller Sicht, sondern auch aus praktischen Gründen. Z.B. muß nicht auf jeder Workstation ein C-Compiler installiert sein, solange es einen gibt, der allen Anwendern zur Verfügung steht. Diese gemeinsam genutzten Ressourcen können allen Benutzern dienen, müssen aber nur einmal installiert werden. (Das ist ein bißchen vereinfacht dargestellt; in manchen Fällen reicht ein einziger Interpreter oder Compiler vielleicht nicht aus.)

Irgendjemand muß die Kontrolle darüber haben, wo, wann und wie solche Ressourcen benutzt werden dürfen. Dieser Irgendjemand ist derjenige, den ich meine, wenn ich die Begriffe Root, Supervisor, Administrator und Operator verwende. Diese Person (oder eher, dieser Account) funktioniert auf allen Netzwerk-Betriebssytemen nahezu identisch. Dieser Account darf jede Datei auf der Platte lesen, schreiben, modifizieren, löschen, erzeugen, auflisten oder sonst etwas mit ihr tun. Der entsprechende Benutzer hat also sehr viel Macht über das System.

Obwohl diese Macht zur Wartung des Systems natürlich erforderlich ist, kann sie ziemlich gefährlich werden, wenn sie in unerfahrene Hände gerät. Das ist eine Lektion, die Benutzer schnell lernen müssen, wenn sie sich entschließen, von Microsoft Windows auf Unix umzusteigen. Zu diesem Zweck kaufen sich die meisten Benutzer ein Buch über Linux, dem eine CD-ROM beigefügt ist. Sie bewältigen den Installationsprozeß, loggen sich als root ein und erforschen dann die Festplatte und probieren unterschiedliche Anwendungen aus. Unweigerlich löschen oder verändern sie wesentliche Bestandteile des Systems, so daß es nicht mehr zu verwenden ist. Da sie noch nicht genügend Kenntnisse haben, um das Problem finden und beheben zu können, bleibt ihnen nur die Neuinstallation. Der durchschnittliche Linux-Neuling macht dies zwei- bis dreimal, bis er es richtig macht. (Es richtig machen bedeutet, nicht ohne Grund als root auf der Festplatte herumzuwerkeln. Statt dessen sollten Sie einen Benutzer- Account mit eingeschränkten Privilegien für sich anlegen, bis Sie etwas mehr über das System gelernt haben. Dieser Benutzer-Account erbt Berechtigungen, die Sie daran hindern werden, wesentliche und unverzichtbare Netzwerk-Ressourcen zu zerstören).

Da die Netzwerkadministration ein so heikles Thema ist, haben diejenigen, die mit einer solchen Aufgabe betraut werden, meist langjährige Erfahrung. Die meisten von ihnen können nicht nur das System effizient warten, sondern auch neue Software programmieren, um die inhärenten Mängel der Betriebssysteme zu beheben. Als Mindestanforderung muß Root sich damit auskennen, wie man die Zugriffskontrolle für Dateien und Verzeichnisse richtig verwaltet.

22.2 Über die Zugriffskontrolle

Zugriffskontrolle bezieht sich auf Methoden zur Kontrolle des Benutzerzugriffs auf Dateien, Verzeichnisse, Ports oder sogar Protokolle. Die modernen Formen der Zugriffskontrolle sind durch Bemühungen entstanden, sichere Systeme zu schaffen. Das Kriterium zur Messung der Sicherheit eines Systems beinhaltet naturgemäß die Zugriffskontrolle als einem festen Bestandteil. Die Möglichkeit, den Zugriff eines bestimmten Benutzers auf eine bestimmte Ressource einschränken zu können, sollte in jedem Netzwerk-Betriebssystem vorhanden sein. Die meisten vernetzten Systeme haben auch irgendeine Form der Zugriffskontrolle.

Die meisten Schemata für die Zugriffskontrolle beruhen auf einem System von Privilegien oder Berechtigungen. Dies können Lese-, Schreib- oder List-Berechtigungen oder sogar noch feiner abgestufte Berechtigungen sein. Von den Ebenen, denen diese Berechtigungen zugeordnet sind, hängt es sehr stark ab, ob die Zugriffskontrolle verwendet wird. Einige Arten der Zugriffskontrolle sind so restriktiv, daß sie dazu führen könnten, daß das Netzwerk nicht effizient funktionieren kann.

Auf jeden Fall entscheidet Root über die meisten dieser Berechtigungen. Einige Zugriffskontroll-Schemata sind in das System eingebettet. Z.B. ist bei vielen Betriebssystemen Root bzw. der Netzwerk-Systemadministrator der Eigentümer einer Reihe von Verzeichnissen oder Dateien. Also kann per Voreinstellung auch nur Root darauf zugreifen. Dies sind meistens Dateien zur Systemkonfiguration, die für den Betrieb des Netzwerks eine wesentliche Rolle spielen. In den falschen Händen könnten diese Dateien zu einem unautorisierten Zugriff und möglicherweise einer Offenlegung des Netzwerks führen.

Auf einem Unix-Netzwerk können Sie alle Berechtigungen auf einfache Weise einsehen, indem Sie sich eine Verzeichnisstruktur oder die Dateien innerhalb eines Verzeichnisses auflisten lassen. Ein Beispiel dafür, wie dies aussieht, finden Sie in Abb. 22.2.


Abbildung 22.2: Verzeichnis-Listing für das Verzeichnis / auf einer Sun-Sparcstation

Abb. 22.2, ein typisches Beispiel eines Listings des Wurzelverzeichnisses eines Unix-Rechners, zeigt mehrere Spalten mit Informationen über die aufgelistete Datei oder das Verzeichnis. In Abb. 22.3 sind diese Spalten in Informationskategorien aufgegliedert, die Attribute.


Abbildung 22.3: Vier Attribute einer Dateiliste eines Unix-Verzeichnisses

Ich möchte kurz auf diese Attribute eingehen. Sie sind nach ihrer Bedeutung für die Zugriffskontrolle geordnet, wobei mit dem unwichtigsten Attribut begonnen wird:

Attribut #1 ist für uns das wichtigste. Hier werden die Berechtigungen festgelegt, die drei Aspekte des Zugriffs wiedergeben. Lesen Sie Attribut #1 von links nach rechts:

Es ist immer entweder ein Buchstabe oder ein Strich zu sehen. Der Strich bedeutet, daß eine bestimmte Zugriffsberechtigung oder ein Privileg verweigert wird. Die Buchstaben (r, w und x) stehen für die einzelnen Berechtigungen read (Lesen), write (Schreiben) und execute (Ausführen).

Hinweis:

Wenn Sie sich die in Abb. 22.2 dargestellten Listings genauer ansehen, werden Sie feststellen, daß im ersten Feld (Attribut #1) ein d auftaucht. Das bedeutet, daß es sich um ein Verzeichnis (directory) und nicht um eine »normale« Datei handelt.

Die Struktur des Berechtigungsschemas ist von links nach rechts in aufsteigender Reihenfolge zu lesen. D.h. die ersten drei Buchstaben stehen für die Berechtigungen des Eigentümers und die nächsten drei für die Berechtigungen der Gruppe. Die letzten drei geben die Rechte für den Rest der Welt wieder.

Andere Netzwerk-Betriebssysteme haben eventuell eine andere Darstellungsweise als Unix. Bei Unix hat man die Möglichkeit, schnell (an einem Prompt) herauszufinden, wer auf was zugreifen kann. Ältere Novell-NetWare-Systeme haben ein Shell-Interface, in dem Sie diese Berechtigungen einsehen und setzen können. Microsoft Windows NT hat zwar eine grafische Benutzeroberfläche, aber Sie haben dennoch die Möglichkeit, erstaunlich viele Optionen der Zugriffskontrolle auch von einem Prompt aus festzulegen.

22.3 Wie wird man Root?

Aufgrund dieser Organisation der Zugriffskontrolle bei Unix ist es offensichtlich, worin die Aufgabe eines Crackers liegt: Root-Zugang zu erhalten. Da Unix das vorherrschende System auf Internet-Servern war (und wahrscheinlich noch immer ist), haben Cracker sich dieser Aufgabe seit über 20 Jahren angenommen. Der Grund ist klar: Wer Root-Zugang hat, legt die Berechtigungen fest; wer die Berechtigungen festlegt, hat die Kontrolle über das gesamte System. Wenn Sie root geworden sind, haben Sie die Kontrolle über den Rechner (und vielleicht das gesamte Netzwerk) übernommen.

22.3.1 Für und Wider des Berechtigungssystems

Das Berechtigungssystem hat viele Vorteile. Einer davon ist die Klassifizierung. Sie können eine hierarchische Struktur erzeugen, in der Sie die Privilegien basierend auf Klassen (von Gruppen, Benutzern usw.) weiter abstufen können. So können Sie schnell und effizient zumindest eine grundlegende Sicherheit implementieren. Dabei können Gruppen die organisatorische Struktur Ihres Unternehmens reflektieren. Natürlich erbt jedes Mitglied einer Gruppe die Berechtigungen von seiner Muttergruppe (d.h. ein bestimmtes Mitglied einer Gruppe erbt dieselben Dateiberechtigungen, die alle Mitglieder der Gruppe haben, unmittelbar nach dem Hinzufügen zu dieser Gruppe). So können Sie zumindest minimale Privilegien auf einfachste Weise zuordnen.

Nach der Festlegung der Gruppe (und nachdem der Eigentümer und die Benutzer der Gruppe die Berechtigungen der ihnen übergeordneten Gruppen geerbt haben), kann root mit der Feinabstimmung dieser Privilegien beginnen. D.h. root kann beginnen, für die Berechtigungen eines bestimmten Benutzers noch restriktivere Richtlinien zu implementieren. Ein gut organisierter Systemadministrator verwaltet die Berechtigungen und Privilegien von Hunderten oder sogar Tausenden Benutzern sehr effektiv. Das ist schon faszinierend.

Dennoch hat dieses System auch seine Nachteile. Denn schon die bloße Existenz von root ist aus mehreren Gründen ein Sicherheitsrisiko. Zum Beispiel gewährt jedes Programm, das als root laufen muß, nach einer erfolgreichen Attacke dem Angreifer root-Privilegien. Und wenn root erst einmal offengelegt ist, ist das ganze System nicht mehr sicher. Das ist besonders bei Multisegment-Netzwerken kritisch.

22.3.2 Den Root-Account knacken

Obwohl ich keine handfesten Beweise dafür habe, denke ich, daß der Prozentsatz an Crakkern, die dazu in der Lage sind, auf einem bestimmten Rechner Root zu erhalten, ziemlich hoch ist. Ich glaube, der Prozentsatz derer, die dies auf einem Unix-System können, ist ein mehr oder weniger statischer Wert. Über Unix ist viel bekannt, und die Berichte sind ziemlich informativ (dasselbe gilt für Novell NetWare). Die Anzahl derer, die NT knacken können, steigt dagegen rapide an. Ich schätze, daß dieser Prozentsatz innerhalb eines Jahres höher liegen wird als bei anderen Betriebssystemen.

Das Knacken von des Root-Accounts erfolgt (zumindest bei Unix) weit häufiger durch fortgeschrittene Programmiertechniken als durch Knacken der Datei /etc/passwd. Administratoren wissen über Sicherheit Bescheid und sorgen meistens dafür, daß ihr eigenes Paßwort extrem schwer zu knacken ist (und das sollten sie auch tun). Erfahrene Systemadministratoren haben meistens ihre eigene passwd-Datei mehrere Male geknackt. Sie werden wahrscheinlich ein Paßwort festlegen, bei dem man Wochen oder sogar Monate braucht, es zu knacken. Deshalb ist der Einsatz eines Paßwort-Knackers meist verschwendete Zeit.

Wenn dagegen auf der Festplatte befindliche Programme als Root-Prozesse laufen, können Sie den Root-Account möglicherweise schnell und einfach knacken. Es ist nicht notwendig, sich als Root einzuloggen, man muß nur an Root-Privilegien gelangen. Das erreicht man oft mit Hilfe eines Puffer-Überlaufs.

Tip:

Eine ausführlichere Behandlung von Puffer-Überläufen und anderen Programmierfehlern und -schwachstellen finden Sie in Kapitel 28, »Sprachen, Erweiterungen und Sicherheit«.

Exploits dieser Art werden regelmäßig in vielen Mailing-Listen und Newsgruppen gepostet. Wenn der Cracker weiß, wie man einen Compiler benutzt, kann er diese Postings mit minimalem Aufwand über die Zwischenablage in einen Text-Editor einfügen, kompilieren und ausführen. Nachdem er einen Testlauf auf einer ähnlichen Plattform durchgeführt hat (z.B. unter SolarisX86 zur Simulation eines möglichen Solaris-Sicherheitslochs, oder besser unter Solaris für Sparcs), ist er bereit. Der Angriff wird nur Sekunden dauern.

In den meisten Fällen muß ein Cracker noch nicht einmal auf dem neuesten Stand sein. Viele ältere Löcher funktionieren immer noch auf Systemen, die nicht angemessen gesichert sind. Leider verbringen die meisten Systemadministratoren ihre Zeit nicht damit, Mailing-Listen- Archive nach möglichen Sicherheitslöchern ihres Systems zu durchsuchen.

22.4 Root könnte bald der Vergangenheit angehören

Obwohl es vielleicht unglaublich scheint, könnte der Root-Account bald ein ausrangiertes Konzept sein. Viele der Sicherheitsprobleme, die im Internet zutage treten, beruhen auf der Existenz dieses privilegierten Zugangs. Deshalb wird eifrig nach Alternativen geforscht. Die Leute bei den Bell Labs haben bereits ein solches System implementiert, das sie Plan 9 genannt haben. In der öffentlich erhältlichen Dokumentation zu Plan 9 heißt es:

Plan 9 hat keinen Superuser. Jeder Server ist für seine eigene Sicherheit verantwortlich. Dabei wird meistens nur ein Zugriff über die Konsole erlaubt, die durch ein Paßwort geschützt ist. Z.B. haben die Fileserver einen einzigen für die Administration zuständigen Benutzer, der adm genannt wird. Dieser hat spezielle Privilegien, die nur für Befehle gelten, die direkt an der Konsole des Servers eingegeben werden. Diese Privilegien betreffen die tägliche Wartung des Servers, wie z.B. das Hinzufügen von neuen Benutzern und die Konfiguration von Festplatten und Netzwerken. Sie beinhalten keine Befugnis zum Ändern der Berechtigungen für Dateien. Wenn eine Datei von einem Benutzer mit einem Leseschutz versehen worden ist, kann nur dieser eine Benutzer anderen den Zugriff gewähren.

Wegweiser:

Der obige Abschnitt ist ein Auszug aus »Plan 9 from Bell Labs«, einem vom harten Kern des Plan-9-Teams verfaßten Dokument. Die Autoren sind Rob Pike, Dave Presotto, Sean Dorward, Bob Flandrena, Ken Thompson, Howard Trickey und Phil Winterbottom. Sie finden es online unter http:// plan9.bell-labs.com/plan9/doc/9.html.

Plan 9 ist ein interessanter Ansatz, der sicherlich einige der heutzutage mit dem Root- Account verbundenen Probleme beseitigen würde. Dennoch könnte auch dieses neue System mit Problemen verbunden sein. Eines davon dreht sich um die folgende Aussage (aus »Plan 9 from Bell Labs«):

Wenn eine Datei von einem Benutzer mit einem Leseschutz versehen worden ist, kann nur dieser eine Benutzer anderen Zugriff gewähren.

Wenn diese Vorgehensweise strikt erzwungen würde, stellten böswillige Benutzer ein Problem dar. Wenn die Dateien eines solchen Benutzers z.B. für den Rest der Welt mit einer Nur-Lese-Berechtigung versehen wären oder noch striktere Kontrollen auf den Zugriff auf diese Dateien angewendet würden, könnte es dazu kommen, daß man den Account dieses Benutzers sperren oder sogar zerstören müßte. Das wäre eine gleichermaßen einfache wie ärgerliche Lösung des Problems.

Trotzdem glaube ich, daß das Plan-9-Modell weitaus sicherer ist als die heutigen Systeme. Das liegt nicht nur an der Abschaffung von des Root-Accounts, sondern auch an der einzigartigen Methode, mit der es verteilte Datenverarbeitung implementiert. Der Benutzer wird mit einer Art Kreuzung zwischen einem X-Terminal und einem PC ausgestattet. Der Fileserver bleibt isoliert, fast alle Ressourcen werden verteilt, und die Berechtigungen auf diesem Fileserver werden automatisch und dynamisch gesetzt (z.B. wenn Dateien oder Prozesse erzeugt oder verändert werden). Deshalb stehen die Chancen gut, daß eine systemweite Offenlegung von Plan 9 unwahrscheinlich ist.

Es könnte bei Plan 9 jedoch zu anderen Sicherheitsproblemen kommen. Sie können z.B. eine Ressource von jeder Art Dateisystem, entfernt oder anderweitig, anzapfen und diese Ressourcen an lokale Verzeichnisse anhängen, so daß sie so funktionieren und aussehen, als wären sie lokal. Das könnte dazu führen, daß Plan 9 sich schließlich als ein Werkzeug herausstellt, mit dem man in der Lage ist, andere Betriebssysteme offenzulegen. Dies läßt sich jedoch schlecht voraussagen, da über Tests in dieser Richtung relativ wenig Dokumentation zur Verfügung steht. Ich habe noch keinen solchen Test durchgeführt.

22.5 Root auf anderen Betriebssystemen

Unix ist nicht das einzige System, das einen Superuser verwendet. Microsoft Windows NT verwendet ebenfalls eine Variante von Root, die Administrator genannt wird. Auch Novell hat etwas Ähnliches, den Supervisor. Bei allen sind die Rechte und Pflichten von Root dieselben: Sie betreffen die Systemverwaltung. Beide Systeme verfügen über fast identische Kontrollen für die Zugangsberechtigungen (NetWare ist meines Erachtens jedoch etwas umfassender).

22.6 Der Cracker mit Root-Berechtigung

Ich sollte an dieser Stelle vielleicht erläutern, daß es gar nicht so ungewöhnlich ist, Root- Zugang zu haben. Das können Sie schon für ein paar Mark haben. Sie können z.B. Linux oder FreeBSD auf einem PC installieren, und schon sind Sie root auf diesem einen Rechner. Einige Systemadministratoren spotten vielleicht darüber, da sie glauben, daß es einem Crakker kaum etwas nützen wird, einen Rechner zu installieren, auf dem er root ist. Dennoch gibt dies dem Cracker einige kleine Vorteile:

Es gibt noch einige unbedeutendere Vorteile. Der Cracker kann z.B. seinen eigenen Mail- und News-Server manipulieren und anderen Crackern Netzwerkdienste zur Verfügung stellen. Diese Vorteile sind jedoch aus pädagogischer Sicht zu vernachlässigen. Die einzige wirkliche Herausforderung hierbei ist es, Personen, die Zugang zu dem Rechner haben, daran zu hindern, ihn zu zerstören.

22.7 Vorsicht vor Root

Als Cracker müssen Sie aufpassen. Administratoren sind reizbare Wesen. Wenn sie Sie eines Vergehens verdächtigen, haben Sie Probleme. Das bringt uns zu einem wichtigen Punkt: Root ist immer ein Mensch. Wie dieser Mensch mit Ihnen umgeht, ist von Fall zu Fall unterschiedlich.

Cracker sehen sich automatisch als direkter Gegensatz zum Systemadministrator. Das ist auch tatsächlich so, aber das bedeutet nicht notwendigerweise, daß die beiden sich bekriegen. Viele Systemadministratoren ergötzen sich an Geschichten über geknackte Netzwerke. Solange das betroffene Netzwerk nicht ihr eigenes ist, sind solche Geschichten spannend und sehr informativ. Man hat manchmal fast das Gefühl, daß einige Systemadministratoren ein rezessives Cracker-Gen in sich tragen, das sie jedoch auf konstruktive Weise ausleben, indem sie die Sicherheit ihres eigenen Netzwerks auf die Probe stellen. Man könnte beinahe sagen, daß es für den Betrieb eines sicheren Netzwerks am besten ist, wenn man ein klein wenig von einem Cracker hat.

Im Gegensatz zur landläufigen Meinung sind Systemadministratoren oft ganz schön auf Zack. Ihre Position erfordert eine hohe Verantwortung, die in der Regel ganz auf ihren Schultern lastet. Deshalb leben sie in ihrer eigenen Welt, in der sie allmächtig sind (oder zumindest so erscheinen). Um ein guter Systemadministrator zu sein, benötigt man mehr als gute Programmierkenntnisse und eine solide Kenntnis des Betriebssystems. Ein wenig Menschlichkeit und ein gutes Urteilsvermögen sind ebenfalls vonnöten. Ich habe die Erfahrung gemacht, daß die meisten Administratoren ein bißchen Herumprobieren durchaus tolerieren, bevor sie dem abtrünnigen Benutzer den Zugang sperren. Das machen sie nicht, weil sie Cracker besonders mögen, sondern weil sie Sinn für Fair Play haben und es im Grunde schätzen, wenn jemand etwas über das System lernen will.

Bei einem Versuch, zu Root-Rechten zu kommen, sollten Sie jedoch vorsichtig sein. Ein Systemadministrator, dessen Netzwerk offengelegt wurde, kann sehr hartnäckig sein. Er könnte Sie über Kontinente hinweg verfolgen. In einem Fall bewegte ein 75-Cent-Fehler einen inzwischen berühmten Systemadministrator (Clifford Stoll) dazu, einen ganzen Spionagering mit Sitz in Deutschland aufzuspüren und auszuheben.

Hinweis:

Das Kuckucksei

Clifford Stoll, ein Astronom, war zu Forschungswecken im Lawrence Berkeley Laboratory (LBL) in Kalifornien. Während seiner Anstellung dort übernahm Stoll die Verantwortung für das Netzwerk (Stoll nutzte das Internet bereits seit 1975) und wurde damit beauftragt, den Grund für einen Buchhaltungsfehler von 75 Cent herauszufinden. Seine Untersuchungen ergaben schließlich, daß sich jemand unbefugt Zugang zu dem lokalen Netzwerk verschafft hatte. Statt dem unautorisierten Benutzer den Zugang sofort zu verweigern, ließ er den Cracker gewähren. Daraufhin fand Stoll heraus, daß der Cracker das LBL-Netzwerk als Ausgangspunkt zum Knacken von Systemen verwendete, die in der MILNET-Hierarchie angesiedelt waren (MILNET ist eine Gruppe militärischer Netzwerke in den USA). Stoll stellte fest, daß der Cracker - von Deutschland aus - wichtige verteidigungsrelevante Informationen stahl. Er holte sich schließlich Hilfe bei amerikanischen und deutschen Nachrichtendiensten (die anfangs gar nicht bereit waren, seinen Verdacht anzuhören). Es stellte sich heraus, daß der Cracker von östlichen Geheimdiensten dafür bezahlt wurde, US-Verteidigungsinformationen zu stehlen. Die Geschichte wurde zu einer Internet-Legende, nur noch übertroffen von dem Internet-Wurm. Weitere Informationen finden Sie in Stolls Buch The Cuckoo's Egg (Doubleday, 1989), das die Ereignisse peinlich genau beschreibt.

22.8 Zusammenfassung

Dieses Kapitel klärt einige Zusammenhänge in bezug auf Superuser-Privilegien auf Computersystemen. Das ist deshalb wichtig, weil ich in den folgenden Kapiteln verschiedene Arten beschreiben werde, wie man den Root-Account attackieren kann und wie man sich anderweitig Root-Zugang verschaffen kann. Folgende Dinge sollten Sie sich merken:



vorheriges KapitelInhaltsverzeichnisStichwortverzeichnisKapitelanfangnächstes Kapitel