vorheriges KapitelInhaltsverzeichnisStichwortverzeichnisnächstes Kapitel


25

Angriffsebenen

In diesem Kapitel wollen wir uns die unterschiedlichen Ebenen eines Angriffs ansehen. Ein Angriff ist jede unbefugte Aktion, die mit dem Ziel ausgeführt wird, Ihren Server zu behindern, zu schädigen, außer Gefecht zu setzen oder seine Sicherheit zu durchbrechen. Ein solcher Angriff kann von einem Versagen des Dienstes bis hin zur vollständigen Offenlegung und Zerstörung Ihres Servers führen. Welche Ebene eine erfolgreich gegen Ihr Netzwerk ausgeführte Attacke erreicht, hängt von den Sicherheitsvorkehrungen ab, die Sie getroffen haben.

25.1 Wann kann es zu einem Angriff kommen?

Ein Angriff kann jederzeit ausgeübt werden, solange Ihr Netzwerk mit dem Internet verbunden ist. Da die meisten Netzwerke 24 Stunden am Tag angebunden sind, bedeutet das, daß es jederzeit zu einem Angriff kommen kann. Es gibt jedoch einige Gepflogenheiten, nach denen sich die meisten Angreifer erwartungsgemäß verhalten.

Die Mehrzahl der Angriffe erfolgt (oder beginnt zumindest) spät nachts - bezogen auf die Zeitzone des Servers. D.h., wenn Sie in Los Angeles sind und Ihr Angreifer sich in London befindet, wird die Attacke vermutlich während der späten Nacht bis in die frühen Morgenstunden der Pazifik-Normalzeit erfolgen. Sie würden vielleicht vermuten, daß Cracker bevorzugt am Tag arbeiten, weil dann so viel Traffic herrscht, daß ihre Aktivitäten eher in der Menge untergehen. Es gibt jedoch einige Gründe, warum Cracker diese Zeiten meiden:

Die beliebtesten Ziele von Crackern sind daher Systeme, in denen sich niemand befindet. Ich verwendete eine Zeitlang eine Workstation in Japan, um meine Angriffe von dort aus zu starten, da nie jemand eingeloggt zu sein schien. Von diesem Rechner aus startete ich Telnet und verband mich zurück in die Vereinigten Staaten. Eine ähnliche Situation hatte ich einmal mit einem neuen ISP in Rom. (Mehr kann ich nicht erzählen, da sie sich ganz bestimmt an mich erinnern werden und mein Inkognito dann gelüftet wäre. Sie meinten tatsächlich, daß ich unbedingt bei ihnen vorbeischauen sollte, wenn ich mal wieder in Italien hacken würde!)

Über solche Rechner können Sie vorübergehend die Kontrolle übernehmen und sich alles nach Ihrem Geschmack einrichten. Außerdem haben Sie reichlich Zeit, die Log-Dateien zu ändern. Seien Sie also gewarnt: Die meisten dieser Aktivitäten erfolgen in der Nacht - bezogen auf Ihre geographische Lage.

Tip:

Wenn Sie sehr gründlich protokolliert haben und Ihnen nur begrenzte Zeit zur Analyse dieser Log-Dateien zur Verfügung steht, würde ich Ihnen raten, sich auf die Verbindungsanforderungen spät nachts zu konzentrieren. Diese Abschnitte beinhalten ganz bestimmt interessante und merkwürdige Informationen.

25.2 Welche Betriebssysteme verwenden Cracker?

Die von Crackern verwendeten Betriebssysteme variieren. Am wenigsten wahrscheinlich ist wohl die Macintosh-Plattform. Es gibt einfach nicht genügend Tools für MacOS, und die benötigten Tools zu portieren stellt einen zu großen Aufwand dar. Unix ist wahrscheinlich die am häufigsten verwendete Plattform, und davon wahrscheinlich FreeBSD und Linux.

Der offensichtlichste Grund dafür sind die Kosten. Für den Preis dieses Buchs bekommen Sie eine Linux-Distribution mit allen Tools, die Sie jemals benötigen: C, C++, Smalltalk, Perl, TCP/IP und vieles mehr. Außerdem erhalten Sie den vollständigen Quellcode des Betriebssystems.

Diese Frage der Kosten ist gar nicht so trivial. Sogar ältere Workstations können teuer sein. Sie erhalten mehr Rechen-Power, wenn Sie einen IBM-kompatiblen Rechner nehmen. Sie können heute für wenig Geld an einen 100-MHz-PC mit 8 Mbyte RAM kommen. Dann spielen Sie noch FreeBSD oder Linux auf den Rechner, und schon haben Sie eine leistungsfähige Workstation. Für ungefähr dasselbe Geld bekommen Sie dagegen nur eine 25-MHz- SPARCstation 1 mit Festplatte, Monitor und Tastatur. Oder eine ELC mit einer externen Platte und 16 Mbyte RAM. Die Kosten für die Software verschlimmern das Ganze noch. Wenn Sie eine alte Sun kaufen, erhalten Sie damit vielleicht auch SunOS 4.1.x. Dann ist ein C-Compiler (cc) dabei. Wenn Sie jedoch einen RS/6000 mit AIX 4.1.x kaufen, kommen Sie vielleicht billiger an die Maschine, aber einen C-Compiler haben Sie damit noch nicht. Das läuft wahrscheinlich darauf hinaus, daß Sie sich GCC aus dem Internet besorgen werden. Wie Sie sich denken können, ist ein C-Compiler ein absolutes Muß. Ohne ihn können Sie die Mehrheit der erhältlichen Tools nicht verwenden, da Sie diese zuerst kompilieren müssen. Das ist eine wichtige Überlegung und mit ein Grund dafür, warum Linux immer beliebter wird.

Hinweis:

Die Kompatibilität ist kein wirkliches Problem. Die meisten guten Tools sind in der Unix-Umgebung verfaßt worden, und diese können leicht auf die frei erhältlichen Unix-Plattformen portiert werden. In vielen Fällen existieren bereits Binaries für Linux und FreeBSD (obwohl ich zugeben muß, daß dies überwiegend für FreeBSD der Fall ist, da frühere Linux-Distributionen einen etwas eklektischen Quellbaum hatten, der wahrscheinlich eher AIX ähnelte als anderen herkömmlichen Systemen wie SunOS). Das ist zum Teil auch eine Kultfrage. Puristen bevorzugen im allgemeinen BSD.

25.2.1 Sun

Man sieht ziemlich häufig Cracker, die entweder SolarisX86 oder SCO als Plattform verwenden. Der Grund dafür ist, daß man an diese Produkte, obwohl es Lizenzprodukte sind, ziemlich leicht herankommen kann. Meistens sind Cracker, die diese Plattform verwenden, Studenten, oder sie kennen Studenten. Deshalb können sie sich die sehr viel billigeren Schulversionen besorgen. Außerdem sind diese Betriebssysteme auch deshalb eine preiswerte Alternative, weil sie auf PC-Architekturen laufen. (SolarisX86 2.4 wurde sehr populär, nachdem Unterstützung für normale IDE-Laufwerke und CD-ROM-Laufwerke integriert wurde. Vorher waren nur die teureren SCSI-Laufwerke unterstützt worden.) Seit kurzem verteilt Sun Microsystems gegen einen kleinen Unkostenbeitrag (Porto- und Mediumkosten) das Betriebssystem Solaris an Privatanwender mit kostenloser Lizenz, solange das System nicht kommerziell benutzt wird.

25.2.2 Andere Unix-Plattformen

Unix-Plattformen sind deshalb populär, weil sie normalerweise geringe Hardware-Anforderungen stellen. Ein Rechner mit Windows 95 und allem Zubehör benötigt eine Menge RAM. Linux oder FreeBSD können Sie dagegen auf einem armseligen 386er laufen lassen und eine gute Leistung erhalten (natürlich vorausgesetzt, daß Sie auf X verzichten). Das ist auch kein Problem, weil sogar Tools, die für die X-Umgebung geschrieben worden sind, normalerweise ebenfalls über eine Befehlszeilen-Schnittstelle verfügen (z.B. können Sie SATAN von der Kommandozeile ausführen).

25.2.3 Microsoft

Die Microsoft-Plattform unterstützt viele legitime Sicherheitstools, die für Angriffe auf entfernte Hosts verwendet werden. Immer mehr Cracker verwenden Windows NT, da es eine sehr viel bessere Leistung bietet als Windows 95 und außerdem über fortschrittliche Netzwerk-Tools verfügt. Darüber hinaus ist Windows NT unter dem Aspekt der Sicherheit eine etwas ernster zu nehmende Plattform. Es verfügt auch über eine Zugriffskontrolle, so daß Cracker ihren Spezis bestimmte Dienste sicher anbieten können. Wenn sich diese »Freunde« einloggen und versuchen, das System zu zerstören, werden sie mit denselben Kontrollen konfrontiert wie bei einem Rechner, der Crackern nicht so freundlich gesinnt ist.

Außerdem wird Windows NT immer beliebter, weil Cracker wissen, daß sie lernen müssen, mit dieser Plattform umzugehen. Da Windows NT als Plattform für Internet-Server immer populärer wird (und das wird es, spätestens seit DEC mit Microsoft kooperiert, auf jeden Fall), müssen Cracker wissen, wie man dieses System knacken kann. Weiterhin werden Sicherheitsprofis auch Tools entwickeln, mit denen man die interne Sicherheit von Windows-NT-Systemen testen kann. Ein starker Anstieg der Verwendung von Windows NT als Cracker-Plattform ist also absehbar.

Hinweis:

Auch für Windows 95 werden immer mehr Tools entwickelt. Das wird dazu führen, daß sich die Cracker-Szene etwas verändert. Solche Tools haben im allgemeinen grafische Oberflächen und erfordern von ihrem Benutzer wenig Kenntnisse. Mit zunehmender Verbreitung dieser Tools wird es zu noch mehr Sicherheitsverletzungen im Internet kommen. Dennoch glaube ich nicht, daß Windows 95 als Cracker-Plattform jemals eine größere Rolle spielen wird.

25.3 Ausgangspunkte von Angriffen

Vor Jahren gingen viele Angriffe von Universitäten aus, da dort ein Internet-Zugang vorhanden war. Die meisten Cracker waren Jugendliche, die keine andere Möglichkeit hatten, ins Internet zu kommen. Das wirkte sich natürlich nicht nur auf den Ausgangspunkt der Attacke aus, sondern auch auf den Zeitpunkt des Angriffs. Außerdem war damals echtes TCP/IP von zu Hause aus noch nicht als Option verfügbar.

Heute ist die Situation ganz anders. Cracker können Ihr Netzwerk von zu Hause aus, ihrem Büro oder ihrem Wagen aus knacken. Es gibt jedoch auch einige konstante Größen. Zum Beispiel benutzen ernsthafte Cracker im allgemeinen keine Online-Dienste wie AOL oder CompuServe. (Offensichtliche Ausnahmen sind Cracker, die gestohlene Kreditkartennummern verwenden. In solchen Fällen sind Online-Dienste eine ausgezeichnete Wahl.) Ein Grund dafür ist, daß diese Online-Dienste einen Hacker oder Cracker schon beim geringsten Anlaß anzeigen. Der Verdächtige hat vielleicht noch nicht einmal etwas Schlimmes getan (kleinere ISPs lassen sie vielleicht einfach gehen). Die Ironie dabei ist, daß große Online- Dienste es den Versendern von Massenmailings durchaus erlauben, das Internet mit größtenteils unerwünschten Werbemails zu bombardieren. Können Sie sich denken, warum? Neugierde wird mißbilligt, aber purer Kommerz ist in Ordnung.

Ein weiterer Grund ist, daß diese Dienste keine Unix-Shell zusätzlich zum normalen PPP anbieten. Ein Shell-Account kann viele Aktionen erleichtern, die sonst schwierig durchzuführen sind. Verfügbare System-Tools bieten eine erweiterte Funktionalität, darunter verschiedene Shells, Perl, Awk, Sed, C, C++ und eine Handvoll Systembefehle (z.B. showmount und rusers).

Langsam vervollständigt sich unser Bild eines typischen Crackers: Es ist eine Person, die spät in der Nacht arbeitet, mit einem Unix- oder Windows-NT-Rechner und fortschrittlichen Tools ausgestattet ist und aller Wahrscheinlichkeit nach über einen lokalen Provider ins Internet gelangt.

25.4 Wie sieht der typische Cracker aus?

Der typische Cracker läßt sich wahrscheinlich durch die folgenden Eigenschaften beschreiben:

25.5 Wie sieht das typische Ziel aus?

Das typische Ziel ist schon schwerer zu definieren, da Cracker verschiedene Netzwerktypen aus unterschiedlichen Gründen angreifen. Ein beliebtes Ziel ist jedoch das kleine, private Netzwerk. Cracker sind sich Unternehmensgebaren und finanziellen Situationen durchaus bewußt. Da Firewalls in der Anschaffung und Wartung teuer sind, haben kleinere Netzwerke meistens keine oder verwenden minderwertige Produkte. Außerdem sind in kleinen Unternehmen selten Personen zu finden, die speziell damit betraut sind, sich mit der Abwehr von Crakkern zu beschäftigen (denken Sie nur an den Bericht aus Schweden, den ich in Kapitel 6, »Wer ist überhaupt anfällig für Attacken durch Cracker?«, erwähnt habe). Außerdem sind kleinere Netzwerke leichter offenzulegen, weil sie folgendes Profil haben:

Hinweis:

In ein solches Netzwerk einzudringen ist im allgemeinen einfacher, ebenso wie dort einen Rechner zu unterhalten. Cracker bezeichnen dies als »einen Rechner besitzen«. Sie sagen z.B.: »Ich habe kürzlich dieses Netzwerk geknackt, und jetzt besitze ich einen Rechner dort.« Dieses Besitzen bezieht sich auf eine Situation, in der der Cracker Root-, Supervisor- oder Administrator-Privilegien auf dem Rechner hat. Mit anderen Worten hat der Crakker die totale Kontrolle über den Rechner und könnte jederzeit das Netzwerk komplett lahmlegen oder zerstören.

Dieses Profil ist jedoch nicht auf alle Zeiten festgelegt. Viele Cracker bevorzugen ein Kopf- an-Kopf-Rennen, bei dem sie versuchen, ein neu entdecktes Sicherheitsloch auszunutzen, bevor der Systemadministrator es gestopft hat. In diesem Fall sucht ein Cracker meistens nur die sportliche Herausforderung.

Ein weiterer Punkt ist die Vertrautheit. Die meisten Cracker kennen zwei oder mehrere Betriebssysteme aus Anwendersicht sehr genau, aber meistens nur eins aus Cracker-Sicht. D.h. die meisten Cracker spezialisieren sich auf ein Betriebssystem. Es gibt nur wenige Cracker, die sich mit dem Knacken mehrerer Plattformen auskennen. Wenn jemand z.B. mit VAX/VMS sehr vertraut ist, aber wenig über SunOS weiß, wird er bevorzugt VAX-Stationen angreifen und schließlich durch seine so gewonnenen Erfahrungen vielleicht auch DEC Alphas.

Universitäten sind teilweise Hauptangriffsziele, weil sie über extreme Rechenleistungen verfügen. Eine Universität wäre z.B. ein ausgezeichneter Ausgangspunkt für eine ausgiebige Sitzung mit dem Ziel des Knackens von Paßwörtern. Die Arbeit kann auf mehrere Workstations verteilt werden und dadurch viel schneller durchgeführt werden, als es lokal machbar wäre. Ein weiterer Grund dafür, daß Universitäten Hauptangriffsziele sind, ist die Vielzahl an Benutzern. Selbst in relativ kleinen Netzwerk-Segmenten sind dies oft mehrere hundert. Die Administration derart großer Netzwerke ist eine sehr schwierige Aufgabe. Die Chancen stehen sehr gut, daß ein geknackter Account in der Menge übersehen wird.

Weitere populäre Ziele sind die Netzwerke von Regierungsstellen. Hier tritt die anarchistische Veranlagung eines Crackers zum Vorschein: Er hat den Wunsch, Regierungsstellen zu blamieren. Eine solche Attacke kann, wenn sie erfolgreich durchgeführt wurde, dem Cracker innerhalb seiner Subkultur großes Ansehen verschaffen. Dabei spielt es keine Rolle, ob der Cracker erwischt worden ist; wichtig ist nur, daß er es geschafft hat, eine als sicher angesehene Site zu knacken. Die Kunstfertigkeit dieses Crackers wird sich unter den Crackern im Internet schnell herumsprechen.

25.6 Warum wollen Cracker ein System angreifen?

Es gibt eine Menge Gründe, warum Cracker daran interessiert sein könnten, Ihr System anzugreifen:

Das sind alles schlechte Gründe. Wenn Sie das Gesetz übertreten, sind Sie auf jeden Fall zu weit gegangen. Bei Gesetzesübertretungen spielt oft ein Gefühl eine Rolle, das die ganze Sache sehr aufregend und spannend werden läßt und Ihre Urteilsfähigkeit negativ beeinflussen könnte.

25.7 Über Angriffe

Ab welchem Ausmaß kann man von einem Angriff auf sein Netzwerk sprechen? Einige meinen, dies sei schon der Fall, sobald ein Cracker entweder in ihr Netzwerk eingedrungen ist oder einen Teil davon zeitweilig lahmgelegt hat. Aus juristischer Sicht könnten dies sicherlich auch gültige Anhaltspunkte sein, mit deren Hilfe man einen Angriff definieren kann (obwohl in einigen Gesetzgebungen auch die Absicht und nicht nur die erfolgreiche Durchführung einer Tat schon ausreicht).

Die juristische Definition eines Angriffs geht davon aus, daß dieser nur dann stattgefunden hat, wenn der Cracker in das Netzwerk gelangt ist. Meiner Meinung nach ist jedoch schon die Ausübung von Handlungen, die letztendlich zu einem Eindringen in ein Netzwerk führen werden, als Angriff zu bezeichnen. Ich denke, daß Sie schon angegriffen werden, sobald ein Cracker mit der Arbeit an dem Zielrechner beginnt.

Das Problem bei dieser Definition ist, daß ein Cracker manchmal, sei es aufgrund einer noch unausgereiften Vorbereitung oder einfach mangelnder Gelegenheit, einige Zeit benötigt, um einen Angriff schließlich auszuführen. Er könnte z.B. wochenlang weitere Informationen über Ihr System sammeln, und diese Sitzungen könnte man kaum als Angriffe bezeichnen, da sie damit nicht viel zu tun haben. Wenn ein Cracker weiß, daß Sie Log-Dateien zur Protokollierung der Vorgänge auf Ihrem Rechner einsetzen, wählt er vielleicht diese langsame Vorgehensweise. Der Grad der Paranoia von Systemadministratoren ist unterschiedlich, und diesen kann ein Cracker nur herausfinden, indem er irgend etwas unternimmt (z.B. könnte er einen Scheinangriff von einer temporären Adresse aus starten und auf die Antwort, ein Echo oder irgendwelche Aktivitäten des Systemadministrators warten). Die meisten Administratoren gehen allerdings nicht aufgrund einer einzigen Anweisung aus dem Nichts in die Luft, es sei denn, diese ist eine offensichtliche Attacke.

Ein Beispiel für eine offensichtliche Attacke ist, wenn die Log-Datei den Versuch eines alten sendmail-Exploits preisgibt. Dabei führt der Cracker zwei oder drei Befehlszeilen an Port 25 aus. Diese Befehle dienen stets dazu, den Server dazu zu bringen, eine Kopie der Datei /etc/ passwd an den Cracker zurückzusenden. Wenn ein Systemadministrator das sieht, ist er höchstwahrscheinlich beunruhigt. Anders ist das z.B. bei showmount. Ein Systemadministrator weiß wahrscheinlich, daß die Ausführung der showmount-Anweisung ein verdächtiges Zeichen ist, aber er wird dies nie als ein versuchtes Eindringen werten. Daraus kann man höchstens ableiten, daß jemand ein Eindringen in Erwägung zieht, wenn überhaupt.

Diese Techniken der allmählichen Sammlung von Informationen haben ihre Vor- und Nachteile. Zum Beispiel kann ein Cracker zu unterschiedlichen Zeiten von unterschiedlichen Adressen aus unauffällig an den Türen eines Netzwerks klopfen (und die Fenster überprüfen). Spärliche Protokolle dieser Vorfälle, von unterschiedlichen Adressen aus, lassen den normalen Systemadministrator wahrscheinlich noch nicht hellhörig werden. Eine rabiatere Vorgehensweise (z.B. ein schwerer Scan) wird den Systemadministrator dagegen sofort auf das Problem aufmerksam machen. Wenn ein Cracker nicht ausreichend sicher ist, daß eine bekannte Sicherheitslücke auf einem Rechner existiert, wird er kaum eine kompromißlose Scan-Attacke durchführen (jedenfalls nicht, wenn er clever ist).

Wenn Sie sich noch nicht lange mit der Sicherheit beschäftigen, ist es wichtig, daß Sie sich mit dem Verhalten von Crackern vertraut machen. Sicherheitstechniker spielen die Bedeutung dieses Punkts oft herunter, weil sie Cracker nur Geringschätzung entgegenbringen. Trotzdem gelingt es Crackern immer wieder, die Sicherheit von vorgeblich sicheren, mit den neuesten und besten Sicherheitstechnologien ausgestatteten Servern zu durchbrechen.

Die meisten Cracker sind keine Genies. Sie verwenden oft erprobte und zuverlässige Techniken, die in der Szene weit verbreitet sind. Wenn ein Cracker sich seine Tools nicht selbst schreibt, muß er auf die vorhandenen zurückgreifen. Jedes Tool hat Einschränkungen, die auf seiner speziellen Konzeption beruhen. Deshalb sehen für die Opfer alle Angriffe, bei denen die gleichen Tools verwendet werden, im Grunde gleich aus. Angriffe von Crackern, die strobe verwenden, sehen wahrscheinlich immer identisch aus, solange das Zielsystem z.B. immer eine SPARC mit SunOS 4.1.3 ist. Diese Signaturen erkennen zu können, ist eine wichtige Fertigkeit, die Sie sich aneignen sollten. Das Studium von Verhaltensmustern geht jedoch noch ein bißchen weiter.

Die meisten Cracker lernen ihre Techniken (zumindest die Grundlagen) von ihren Vorgängern. Obwohl es auch Pioniere unter den Crackern gibt, treten die meisten Cracker einfach in die Fußstapfen derer, die vor ihnen da waren. Diese Techniken sind in von Crackern verfaßten Online-Dokumenten ausführlich beschrieben, und solche Dokumente findet man zu Hunderten im Internet. Dort wird an äußerst detaillierten Beispielen erläutert, wie man einen bestimmten Angriff durchführt.

Der Cracker-Neuling befolgt diese Anweisungen meistens sehr genau. Allerdings ist dies oft ungünstig, da einige Angriffsmethoden inzwischen mehr als veraltet sind (und Abwehrlösungen entwickelt worden sind, so daß der Cracker nur seine Zeit vergeudet). Wenn Sie einen solchen Angriff in Ihren Log-Dateien finden, sieht er wahrscheinlich fast genauso aus wie in den Logs, die Sicherheitsprofis in verschiedenen technischen Publikationen veröffentlicht haben, um Beispiele für Einbruchversuche zu illustrieren.

Tip:

Es kommt jedoch der Zeitpunkt, an dem ein Cracker genügend Erfahrungen gesammelt hat, um selbst spezielle Methoden der Umsetzung von Angriffen entwickeln zu können. Bei dieser Art von Angriffen, Hybridangriffe genannt, werden zwei oder mehrere Techniken kombiniert verwendet, um das gewünschte Ziel zu erreichen. (Ein Beispiel dafür ist die bereits beschriebene DoS-Attacke, die eigentlich eine Phase einer Spoofing-Attacke ist.) Es soll tatsächlich noch Cracker geben, die immer noch die herkömmliche Technik verwenden, einen Befehl nach dem anderen einzutippen. In diesem Fall erhalten Sie alle möglichen Arten interessanter Logging-Meldungen.

Auf jeden Fall ist es sehr lehrreich, das Verhalten von Crackern in echten Cracking-Situationen zu studieren. Es gibt Dokumente dieses Inhalts im Internet, von denen Sie sich mindestens zwei oder drei besorgen sollten. Eines der außergewöhnlichsten wurde von Bill Cheswick, damals AT&T Laboratories, geschrieben. Cheswick beginnt diesen Klassiker wie folgt:

Am 7. Januar 1991 versuchte ein Cracker, der glaubte, die berühmte sendmail- DEBUG-Sicherheitslücke in unserem Internet-Gateway-System gefunden zu haben, an eine Kopie unserer Paßwortdatei zu gelangen. Ich schickte ihm eine.

Cheswick leitete die passwd-Datei an den Cracker und erlaubte ihm, in eine geschützte Umgebung einzudringen. Dort beobachtete er den Cracker dabei, wie er unterschiedliche Methoden ausprobierte, um privilegierten Zugriff zu erhalten und schließlich alle Dateien zu löschen. Der Angriff schien von der Stanford University auszugehen, aber später stellte man fest, daß der Angreifer aus den Niederlanden kam. Damals waren solche Aktivitäten in den Niederlanden noch nicht ungesetzlich. Deshalb konnte man nichts unternehmen, obwohl der Cracker schließlich aufgespürt wurde. Jedenfalls versuchte der Cracker, mit einer Reihe plumper Attacken einen bestimmten Rechner zu knacken. Ab hier ist die Geschichte, die Cheswick erzählt, wirklich faszinierend. Cheswick und seine Kollegen schafften eine spezielle, geschützte (chroot-)Umgebung, in der der Cracker nach Herzenslust knacken durfte. Auf diese Weise konnte man ihn ganz genau beobachten. Das Dokument enthält viele Log- Protokolle, und es ist wirklich eine Pflichtlektüre.

Wegweiser:

Sie finden »An Evening With Berferd In Which a Cracker is Lured, Endured and Studied« online unter ftp://research.att.com/dist/internet_security/berferd.ps .

Hinweis:

Tsutomu Shimomura und Wietse Venema waren auch an dieser Aktion beteiligt, die über einen recht langen Zeitraum lief. Shimomura fing Berichten zufolge den Netzwerkverkehr ab, während Venema den Cracker (und seine Gefährten) in den Niederlanden überwachte. Cheswick berichtete außerdem, daß Steve Bellovin den Köder-Rechner konstruierte, den sie für solche Fälle vorgesehen hatten. Sie glaubten, daß ein solcher Rechner eine bessere Umgebung darstellen würde, um einen Cracker bei der Arbeit zu beobachten, da dieser ruhig auch auf Root-Ebene offengelegt werden könnte (und eventuell sogar das Dateisystem zerstört werden könnte). Sie plazierten den Rechner einfach in einem Netzwerksegment, in dem auch ein Sniffer installiert werden konnte. Wenn der Cracker also das Dateisystem des Köders zerstören würde, könnten sie dennoch Nutzen aus den Log-Dateien ziehen. Dieses Dokument ist wirklich hervorragend. Es ist humorvoll, unterhaltsam und unglaublich lehrreich.

Hinweis:

Wie es nun einmal so ist, hatte Steve Bellovin einen Rechner als Köder präpariert, der später zum Vorbild für andere derartige Rechner wurde. In dem oben erwähnten Dokument wird ausführlich beschrieben, wie man ein solches System einrichtet, in das die Leute bei Bell den Cracker gelockt hatten.

Es gibt noch weitere Berichte dieser Art. Ein besonders vernichtender stammt von Tsutomu Shimomura, der einen Cracker beobachtete, der dem oben erwähnten sehr ähnlich war. Die Person gab vor, der Mitnik Liberation Front anzugehören (der Name sagt wohl schon alles). Auf jeden Fall legte dieser Cracker ein Ködersystem bloß, das dem von Bellovin präparierten ähnelte. Shimomuras Kommentare wechseln sich ab mit Beschreibungen erfolgloser Versuche des Crackers, mehr zu erreichen. Auch Protokolle dieser Sitzungen sind in dem Dokument enthalten. Es ist eine interessante Studie.

Wegweiser:

Shimomuras Bericht finden Sie unter http://www.takedown.com/evidence/ anklebiters/mlf/index.html.

Eine weitere fesselnde Beschreibung stammt von Leendert van Dorn von der Universität Vrije in den Niederlanden. Sie trägt den Titel »Computer Break-ins: A Case Study« (21. Januar 1993). Dieses Dokument beschäftigt sich mit unterschiedlichen Arten von Angriffen. Die Techniken wurden aus tatsächlich gegen die Universität Vrije ausgeführten Angriffen zusammengestellt. Einige der Angriffe waren ziemlich ausgeklügelt.

Wegweiser:

Van Dorns Bericht finden Sie online unter http://www.alw.nih.gov/Security/FIRST/papers/general/holland.ps .

Ein bekannteres Dokument ist vielleicht »Security Breaches: Five Recent Incidents at Columbia University«. Da ich dieses Dokument an anderer Stelle in diesem Buch analysiere, werde ich hier davon absehen. Es ist jedenfalls eine ausgezeichnete Studie, die viel Licht ins Dunkel des Verhaltens von Crackern bei der Umsetzung von Angriffen bringt.

Wegweiser:

»Security Breaches: Five Recent Incidents at Columbia University« finden Sie unter http://www.alw.nih.gov/Security/FIRST/papers/general/ fuat.ps.

Gordon R. Meyer hat eine sehr interessante Magisterarbeit an der Northern Illinois University verfaßt, mit dem Titel »The Social Organization of the Computer Underground«. Darin analysierte Meyer die Computer-Untergrundszene aus soziologischer Sicht und sammelte einige sehr aufschlußreiche Informationen. Die Arbeit ist zwar schon recht alt, enthält aber heute noch interessante Auszüge von Radio- und Fernsehinterviews, Zeitschriften und anderen Publikationen. Obwohl Meyers Arbeit nicht wie die oben erwähnten Dokumente spezielle Vorgehensweisen im Detail enthüllt, beschreibt sie doch sehr klar und deutlich die sozialen Aspekte des Knackens von Computersystemen.

Wegweiser:

Meyers Arbeit, aus dem August 1989, finden Sie online unter http:// www.alw.nih.gov/Security/FIRST/papers/general/hacker.txt.

25.8 Der Sensibilitätsindex der Crack-Ebenen

Abb. 25.1 zeigt sechs Ebenen Ihres Netzwerks. Ich werde diese Ebenen als Ebenen der Sensibilität bezeichnen. In den Kästchen sind die mit den jeweiligen Cracking-Techniken verbundenen Risiken beschrieben.


Abbildung 25.1: Der Sensibilitätsindex der Crack-Ebenen

25.8.1 Ebenen der Sensibilität

Die Ebenen der Sensibilität sind in allen Netzwerken ziemlich ähnlich (abgesehen von denen mit sicheren Netzwerkbetriebssystemen). Die üblichen Risiken lassen sich in einer Liste zusammenfassen, die sich seit 10 Jahren nicht grundlegend verändert hat. Änderungen kommen selten vor, außer bei der Einführung von neuen Technologien wie ActiveX, die die Ausführung beliebiger Binaries über das Internet ermöglichen.

Die Mehrheit der Cracker nutzt die Sicherheitslücken aus, von denen wir täglich in Sicherheits-Newsgruppen hören. Wenn Sie diese Gruppen häufiger aufsuchen (oder eine Mailingliste), haben Sie die folgenden Worte wahrscheinlich schon tausendmal gelesen:

25.8.2 Ebene eins

In Ebene eins angesiedelte Attacken sind im Grunde unwichtig. Diese Attacken beinhalten DoS-Attacken und Mailbomben. Es erfordert bestenfalls 30 Minuten Zeit, diese Dinge zu korrigieren. Die einzige Absicht solcher Angriffe ist es, Ihnen auf die Nerven zu gehen. In den meisten Fällen können Sie diese Probleme stoppen, indem Sie ein Ausschlußverfahren anwenden, wie in dem von der Universität Pittsburgh herausgegebenen Sicherheits-Advisory 95-13 (SATAN Update) beschrieben:

Denial-of-Service-Attacken sind immer möglich. Die beste Art damit umzugehen ist, die Quell-Hosts/Netzwerke der Angreifer auf die DENY-Listen in der inetd.sec zu setzen. Es gibt keine andere Möglichkeit, diese Angriffe zu verhindern, außer den Netzwerkbetrieb ganz einzustellen.

Tip:

Wenn Sie Anzeichen für eine DoS-Attacke entdecken, sollten Sie im ganzen System nach Zeichen eines Einbruchs suchen. Flooding- und DoS-Attacken sind oft Vorboten oder sogar Wegbereiter einer Spoofing-Attacke. Wenn Sie an einem bestimmten Port eines Rechners deutliches Flooding entdecken, notieren Sie sich den Port und was dieser macht. Prüfen Sie, welcher Dienst an ihn gebunden ist. Wenn dieser Dienst ein Bestandteil Ihres internen Systems ist - wobei andere Rechner ihn benutzen und die Kommunikation auf einer Adreß-Authentifizierung beruht - sollten Sie auf der Hut sein. Was wie eine DoS-Attacke aussieht, könnte in Wirklichkeit der Anfang eines Einbruchversuchs in Ihr Netzwerk sein. Meistens sind DoS-Attacken, die über längere Zeit andauern, jedoch nur das, wonach sie aussehen: ein Ärgernis.

Es gibt einige Fälle, in denen eine Denial-of-Service-Attacke ernstere Auswirkungen haben kann. Bestimmte obskure Konfigurationen Ihres Netzwerks könnten bedrohlichere Zustände begünstigen. Christopher Klaus von Internet Security Systems hat in einem Beitrag zu DoS- Attacken einige derartige Konfigurationen definiert. Klaus schrieb:

Durch das Aussenden eines UDP-Pakets mit fehlerhaften Informationen im Header kann man bei einigen Unix-Rechnern mit Sun-OS 4.1.3 einen Reboot herbeiführen. Dieses Problem trifft man häufig bei Firewalls an, die auf einem Sun-OS-Rechner aufsetzen. Es könnte eine sehr riskante Sicherheitslücke sein, wenn Ihre Firewall immer wieder ausfällt.

Klaus spricht noch weitere DoS-Attacken an. Ich würde Ihnen empfehlen, sich den Beitrag einmal anzusehen. Er enthält Informationen zu Schwachstellen von Windows NT, Novell, Linux und Unix im allgemeinen.

Wegweiser:

Sie finden Klaus' Beitrag online unter http://www.geek-girl.com/bugtraq/ 1996_2/0052.html.

Wenn es sich bei einem Angriff um eine syn_flood-Attacke handelt, gibt es einige Möglichkeiten, den Cracker zu identifizieren. Augenblicklich sind im Internet vier maßgebliche syn_flooding-Utilities im Umlauf. Mindestens zwei davon enthalten einen grundlegenden Fehler, der die Identität des Angreifers offenlegt, wenn auch indirekt. Diese Tools haben in ihrem Code Vorkehrungen für eine Reihe von PING-Anweisungen. Diese PING-Anweisungen führen die IP-Adresse des Rechners mit, von dem sie ausgegeben worden sind. Wenn der Cracker also eines dieser Utilities benutzt, teilt er Ihnen bei jedem PING-Befehl seine IP-Adresse mit. Obwohl Sie dadurch nicht an die E-Mail-Adresse gelangen, können Sie mit Hilfe der früher in diesem Buch beschriebenen Methoden den Cracker zu seiner Quelle zurückverfolgen. (Wie bereits erwähnt, wird traceroute das Netzwerk preisgeben, von dem der Cracker kommt. Das ist im allgemeinen der vorletzte Eintrag der umgekehrten traceroute -Suche.) Das Problem dabei ist jedoch, daß Sie gründliches Logging einsetzen müssen, um allen Traffic zwischen Ihnen und dem Cracker abzufangen. Um diese IP-Adresse zu finden, müssen Sie schon ganz schön tief graben. Auf jeden Fall haben Sie aber eine 50%ige Chance, wenn der Cracker solch ein fehlerhaftes Utility verwendet.

Hinweis:

Die anderen beiden Utilities für syn_flooding haben diesen PING-Fehler nicht. Die Entwickler dieser Tools waren ein bißchen schlauer. Sie haben eine Vorkehrung eingebaut, die eine per Zufallsgenerator erzeugte IP- Adresse vortäuscht. Das macht die Situation für das Opfer natürlich nicht einfacher. Sogar eine Low-Level-Analyse der erhaltenen Pakete ist verschwendete Zeit. Den unerfahrenen Systemadministrator könnte das ganz schön verwirren. Raffiniert, oder?

Die meisten Denial-of-Service-Attacken stellen ein relativ geringes Risiko dar. Sogar Attakken, die einen Reboot erzwingen können, sind nur vorübergehende Probleme. Diese Art von Angriffen unterscheidet sich stark von solchen, bei denen sich jemand die Kontrolle über Ihr Netzwerk verschafft. Das einzig wirklich Irritierende bei DoS-Attacken ist, daß sie zwar ein geringes Risiko darstellen, aber dafür die Wahrscheinlichkeit eines solchen Angriffs sehr groß ist. Ein Crakker muß nur über wenig Erfahrung und Können verfügen, um eine DoS- Attacke implementieren zu können. Diese Angriffe sind daher sehr verbreitet, wenn auch nicht ganz so verbreitet wie Mailbombings.

Bei Mailbombings sind die Übeltäter meistens leicht aufzuspüren. Außerdem kann man diesen Angriffen durch Bozo-Filter und Ausschlußschemata den Wind aus den Segeln nehmen (sie schaden im Endeffekt dem Angreifer mehr als irgend jemandem sonst). Die einzige wirkliche Ausnahme ist ein Mailbombing, das so konsequent und in einem solchen Ausmaß durchgeführt wird, daß es einen MailServer lahmlegt.

Andere Angriffe der Ebene eins sind z.B. Idioten, die Telnet-Sitzungen zu Ihrem Mail- oder News-Server einleiten und versuchen, freigegebene Verzeichnisse oder sonstige Dinge zu ermitteln. Solange Sie Ihr Netzwerk ordentlich gesichert haben, sind solche Aktivitäten keine Gefahr. Wenn Sie die Freigaben nicht richtig konfiguriert haben oder die r-Utilities laufen lassen (oder andere Dinge, die Sie nicht laufen lassen sollten), können einige dieser durchschnittlichen Techniken der Ebene eins sich zu richtigem Ärger auswachsen.

25.8.3 Die Ebenen zwei und drei

Die Ebenen zwei und drei beinhalten Dinge wie lokale Benutzer, die sich Lese- und Schreibberechtigung zu Dateien (oder Verzeichnissen) verschaffen, die ihnen eigentlich verboten sind. Ob das zu einem Problem wird, hängt stark von dem Wesen dieser Datei(en) ab. Sicherlich kann jeder lokale Benutzer, der auf das Verzeichnis /tmp zugreifen kann, zu einer kritischen Gefahr werden. Dies könnte ihm den Weg zu einem Angriff der Ebene drei (der nächsten Stufe) bereiten, bei dem der Benutzer auch Schreibzugriff erhalten (und damit in Ebene vier vordringen) könnte. Von diesem Problem sind hauptsächlich Unix- und Windows-NT-Administratoren betroffen.

Lokale Angriffe sind ein bißchen anders. Der Begriff lokaler Benutzer ist relativ. In Netzwerken bezieht sich lokaler Benutzer auf jeden, der momentan an einem Rechner innerhalb des Netzwerks eingeloggt ist. Eine bessere Definition ist vielleicht, daß ein lokaler Benutzer jemand ist, der ein Paßwort für einen Rechner innerhalb Ihres Netzwerks hat und deshalb über ein Verzeichnis auf einer Ihrer Festplatten verfügt.

Die Bedrohung durch lokale Benutzer steht in direktem Zusammenhang mit der Art des Netzwerks, das Sie unterhalten. Wenn Sie ein ISP sind, haben Sie wahrscheinlich 90 Prozent Ihrer lokalen Benutzer noch nie gesehen oder gesprochen. Solange die Abbuchungen von ihrer Kreditkarte jeden Monat problemlos erfolgen, haben Sie mit diesen Leuten wahrscheinlich noch nicht mal per E-Mail sehr viel Kontakt (die monatliche Abrechnung zählt nicht so recht). Es gibt keinen Grund, warum diese anonymen Personen keine Cracker sein sollten. Jeder außer Ihren engsten Mitarbeitern ist ein potentieller Verdächtiger.

Hinweis:

Microsoft Windows 95 hat keine abgestufte Zugriffskontrolle. Deshalb sind Windows-95-Netzwerke absolut unsicher, wenn keine Zugriffskontrolle von Drittanbietern installiert wird. Aus diesem Grund sind Angriffe der Ebene zwei dort kritisch und können sich innerhalb von Sekunden leicht zu Angriffen der Ebenen drei, vier, fünf und sechs ausweiten. Wenn Sie ein solches Netzwerk betreiben, sollten Sie sich sofort irgendeine Art der Zugriffskontrolle besorgen. Wenn Sie das nicht tun, kann jeder (jederzeit) ein oder mehrere kritische Dateien löschen. Viele Programme in der Windows-95-Umgebung beruhen auf Datei-Abhängigkeiten. Wenn Sie ein mit dem Internet verbundenes Windows-95-Netzwerk betreiben (ohne Zugriffskontrolle oder Beseitigung der Sicherheitslücken im Internet Explorer), ist es nur eine Frage der Zeit, bis jemand Ihr Netzwerk in Stücke reißt. Ein Cracker muß nur wenige Dateien auf einem Windows-95-Netzwerk löschen, um es dauerhaft außer Betrieb zu setzen. Wenn Sie die Möglichkeit haben, sollten Sie allen Traffic zu den Ports 137-139 überwachen, an denen die gemeinsamen Nutzungen geschehen. Außerdem würde ich den Benutzern innerhalb dieses Netzwerks strengstens verbieten, Web- oder FTP-Server zu installieren. Wenn Sie schon die Microsoft-Plattform benutzen und der Außenwelt zugängliche Server bereitstellen wollen (wovon ich Ihnen dringend abraten möchte), besorgen Sie sich wenigstens NT.

Ein durch einen lokalen Benutzer initiierter Angriff kann jämmerlich schlecht oder extrem ausgereift sein; er wird grundsätzlich über Telnet erfolgen. Ich habe bereits erwähnt, daß es für einen ISP eine ausgezeichnete Idee ist, alle Shell-Accounts auf einem einzigen Rechner zu isolieren. D.h. Logins sollten nur auf dem Rechner (oder Rechnern) akzeptiert werden, die Sie für den Shell-Zugang vorgesehen haben. Das vereinfacht die Verwaltung von Protokollen, Zugriffskontrollen und anderen Sicherheitsaspekten.

Tip:

Sie sollten außerdem generell alle Systemrechner isolieren, auf denen von Benutzern erzeugte CGI-Programme untergebracht werden.

Diese Rechner sollten ein eigenes Netzwerksegment zugeteilt bekommen. D.h. sie sollten entweder durch Router oder Switches umgeben sein, je nachdem, wie Ihr Netzwerk konfiguriert ist. Die Topologie sollte sicherstellen, daß bizarre Arten des Hardware-Adreß-Spoofings nicht hinter dieses bestimmte Segment durchsickern können. Das beinhaltet einige mit Vertrauen zusammenhängende Dinge, die ich später in diesem Buch noch ansprechen werde.

Es gibt nur zwei Arten von Angriffen, denen Sie begegnen werden. Die weniger ernste ist der umherstreifende Benutzer. Das sind Cracker, die sich erst einmal umsehen (solche Leute leiten z.B. die passwd-Datei an STDOUT, um zu sehen, ob sie privilegierte Dateien lesen können). Im Gegensatz dazu könnten Sie allerdings auch auf einen organisierten und gut durchdachten Angriff treffen. In diesem Fall kennt der Angreifer Ihre Systemkonfiguration bereits gut. Vielleicht hat er sie zuvor schon von einem Account eines anderen Providers aus untersucht (wenn Ihr System der Außenwelt Informationen preisgibt, ist dies definitiv eine Möglichkeit).

Wenn Sie Umgebungen mit aktivierter Zugriffskontrolle verwenden, gibt es zwei Hauptprobleme in bezug auf Berechtigungen. Beide können beeinflussen, ob ein Problem der Ebene zwei zu einem Problem der Ebene drei, vier oder fünf eskaliert. Diese Probleme sind:

Zu der ersten Möglichkeit kann es kommen, wenn Sie das Berechtigungsschema nicht richtig verstanden haben. Das ist kein Verbrechen. Ich habe bemerkt, daß nicht jeder Unix- oder NT-Administrator ein Guru ist (obwohl die wenigsten dies zugeben würden). Es braucht Zeit, sich ein tiefergehendes Wissen des Systems anzueignen. Nur weil Sie ein Informatikstudium oder eine vergleichbare Ausbildung abgeschlossen haben, heißt das noch lange nicht, daß Ihr System sicher sein muß. Es gibt Tools, mit denen man prüfen kann, ob man bei der Konfiguration Fehler gemacht hat, und ich gebe in diesem Buch einige davon an. Wenn Sie auch nur den geringsten Verdacht haben, daß die Berechtigungen falsch gesetzt sein könnten, besorgen Sie sich diese Tools und prüfen Sie es genau nach.

Tip:

Viele Sicherheitstools beinhalten Tutorials zu Sicherheitslücken. SATAN ist ein großartiges Beispiel dafür. Die mit SATAN gelieferten Tutorials sind sehr wertvoll und helfen einem, viele Schwachstellen des Systems zu verstehen, sogar wenn man kein Unix-System hat. Zum Beispiel, wenn Sie Journalist sind und mehr über die Unix-Sicherheit erfahren wollen. Sie brauchen kein Unix-System, um die HTML-Tutorials verstehen zu können, die bei SATAN mitgeliefert werden.

Die zweite Möglichkeit kommt häufiger vor, als Sie denken. Solche Fehler tauchen immer wieder auf. So heißt es z.B. im CERT-Advisory »Vulnerability in IRIX csetup« (Januar 1997):

Das CERT Coordination Center hat Informationen über eine Sicherheitslücke in dem Programm csetup unter den IRIX-Versionen 5.x, 6.0, 6.0.1, 6.1 und 6.2 erhalten. Unter IRIX 6.3 und 6.4 ist csetup nicht verfügbar. Durch Ausnutzen dieser Sicherheitslücke können lokale Benutzer beliebige Dateien auf dem System erzeugen oder überschreiben. Mit diesen Möglichkeiten können sie sich schließlich Root-Privilegien aneignen.

Wegweiser:

Dieses Advisory finden Sie online unter http://www.safesuite.com/lists/ gen1/1421.html.

Sie sollten sich dieses Advisory gut ansehen. Beachten Sie das Datum - dies ist nicht irgendein altes Advisory aus den 80er Jahren, sondern von 1997. Diese Arten von Problemen können bei keinem Unternehmen ausgeschlossen werden. Sicherheitslöcher werden routinemäßig in Programmen jeder Art von Betriebssystem gefunden, wie in dem CERT-Advisory »Vulnerability in Solaris admintool« (August 1996) beschrieben ist:

AUSCERT hat einen Bericht über eine Sicherheitslücke in der Solaris-2.x-Distribution von Sun Microsystems erhalten, die auf das Programm admintool zurückzuführen ist. Dieses Programm wird verwendet, um eine grafische Benutzeroberfläche für zahlreiche Aufgaben der Systemadministration zur Verfügung zu stellen. Die Sicherheitslücke kann es einem lokalen Benutzer ermöglichen, Root-Privilegien zu erhalten... bei Solaris 2.5 ist das admintool per Voreinstellung set-user-id-root. D.h. alle Dateizugriffe werden mit der UID von root ausgeführt. Eine Auswirkung davon ist, daß diese Schwachstelle den Zugriff auf alle Dateien des Systems erlaubt. Wenn dies ausgenutzt wird, indem versucht wird, eine Datei zu erzeugen, die bereits existiert, wird der Inhalt dieser Datei gelöscht. Wenn die Datei noch nicht existiert, wird sie mit Root als Eigentümer erzeugt und ist somit für alle Welt schreibbar.

Wegweiser:

Dieses Advisory finden Sie online unter http://www.dice.ucl.ac.be/crypto/olivier/cq/msgs3/msg00010.html .

Dabei macht es keinen Unterschied, welches System Sie haben. Für fast alle Betriebssysteme werden Bugs gepostet. Die meisten Netzwerksysteme sehen sich jeden Monat mit mindestens einem Advisory dieser Art konfrontiert (mit dieser Art meine ich solche, die zu privilegiertem oder sogar Root-Zugriff führen können). Es gibt keine unmittelbare Lösung für dieses Problem, weil die meisten dieser Sicherheitslöcher nicht bekannt waren, als die Software ausgeliefert wurde. Die einzige Möglichkeit ist, alle Mailing-Listen zu abonnieren, die Bugs, Sicherheitslöcher und Ihr System betreffen. In dieser Hinsicht ist Sicherheit ein immerwährender Lernprozeß.

Es gibt einige Techniken, die Sie anwenden können, um auf der Höhe der Zeit zu bleiben. Wenn Sie Mailing-Listen abonnieren, werden Sie mit E-Mails zugeschüttet. Einige Listen erzeugen bis zu 50 Nachrichten pro Tag. Auf Unix-Plattformen ist das kein großes Problem, da Sie kontrollieren können, wie diese Nachrichten auf die Platte geschrieben werden, während sie ankommen (durch Abfangen der Adresse und Umleitung der Mail in ein bestimmtes Verzeichnis und so weiter). In einer Microsoft-Windows-Umgebung kann diese Menge an Mails jedoch überwältigend für jemanden sein, der mit anderen Aufgaben beschäftigt ist. Wenn Sie der Systemadministrator eines NT-Netzwerks sind, gibt es verschiedene Möglichkeiten. Eine ist, unterschiedliche Listen an unterschiedliche Accounts zu leiten. Das macht die Handhabung der eingehenden Mail ein bißchen einfacher (es gibt zu diesem Zweck auch Programme). Unabhängig davon, welche Plattform Sie verwenden, sollten Sie Scripts schreiben, um diese Mail zu analysieren, bevor Sie sie lesen. Ich würde Perl installieren (das auch für NT erhältlich ist) und es verwenden, um die Nachrichten nach einer Zeichenfolge zu durchsuchen, die eine Nachricht für Ihre spezielle Konfiguration interessant macht. Mit ein bißchen Aufwand können Sie sogar ein Script schreiben, das diese Treffer nach Priorität auflistet.

25.8.4 Ebene vier

Probleme der Ebene vier sind im allgemeinen mit Außenstehenden verbunden, die in der Lage sind, auf interne Dateien zuzugreifen. Dieser Zugriff kann unterschiedlicher Natur sein. Sie könnten eventuell nur in der Lage sein, die Existenz bestimmter Dateien zu überprüfen, aber sie könnten auch in der Lage sein, diese Dateien zu lesen. In Ebene vier angesiedelte Probleme beinhalten auch solche Sicherheitslücken, bei denen entfernte Benutzer - ohne gültigen Account - eine begrenzte Anzahl von Befehlen auf Ihrem Server ausführen können.

Der größte Teil dieser Sicherheitslücken entsteht durch eine fehlerhafte Konfiguration Ihres Servers, schlechtes CGI und Überlauf-Probleme.

25.8.5 Die Ebenen fünf und sechs

In den Ebenen fünf und sechs liegen Bedingungen vor, unter denen Dinge möglich sind, die niemals vorkommen dürften. Jedes Sicherheitsloch in Ebene fünf und sechs ist fatal. In dieser Ebene können entfernte Benutzer Dateien lesen, schreiben und ausführen (normalerweise haben sie mehrere Methoden kombiniert, um so weit zu kommen). Zum Glück ist es, wenn Sie schon die Ebenen zwei, drei und vier gesichert haben, fast unmöglich, daß Sie jemals mit einer Krise der Ebenen fünf oder sechs konfrontiert werden. Wenn Sie die kleineren Möglichkeiten des Eindringens vereitelt haben, beruht eine Sicherheitslücke der Ebene sechs höchstwahrscheinlich auf fehlerhafter Software.

25.8.6 Reaktionsebenen

Wie sollte man reagieren, wenn man entdeckt, daß ein Angriff im Gange ist? Das hängt ganz von der Situation ab.

Reaktion auf Angriffe der Ebene eins

Angriffe der Ebene eins können so behandelt werden, wie ich es bereits beschrieben habe. Filtern Sie die ankommende Adresse und kontaktieren Sie den Service Provider des Angreifers. Dies sind kleinere Unannehmlichkeiten. Nur wenn die DoS-Attacke in Zusammenhang mit irgendeiner anderen Attacke zu stehen scheint (vielleicht einer höheren Ebene), oder wenn sie einige Zeit andauert (wie im Fall Panix.com), sollten Sie sich die Mühe machen, mehr zu tun, als nur den ankommenden Traffic auszusperren. Wenn Sie jedoch in einer Situation wie bei Panix sind, sollten Sie erwägen, CERT oder andere Behörden zu informieren.

Reaktion auf Angriffe der Ebene zwei

Angriffe der Ebene zwei können intern behandelt werden. Es gibt keinen Grund, durchsikkern zu lassen, daß lokale Benutzer auf Dinge zugreifen können, auf die sie nicht zugreifen sollten. Sperren oder löschen Sie den Account des Benutzers. Wenn es Beschwerden gibt, überlassen Sie die Sache Ihrem Anwalt. Wenn Sie die Person zur Einsicht bewegen wollen, wird dies nicht viel nützen. Innerhalb eines Monats wird alles wieder beim alten sein. Das ist kein Spiel. Niemand garantiert Ihnen, daß dieser interne Benutzer nur ein unschuldiger, neugieriger Mensch ist. Einen Rat habe ich noch für Sie: Sperren Sie den Account auf jeden Fall ohne Vorwarnung. Auf diese Weise können Sie Beweise sicherstellen, die ansonsten gelöscht werden könnten.

Hinweis:

In Fällen, in denen Sie sich nicht ganz von dem Benutzer trennen können (vielleicht, weil es ein Angestellter ist), können Sie ihn warnen und die Position des Benutzers davon abhängig machen, ob er sich daran hält. Dokumentieren Sie den Vorfall sorgfältig, damit der Benutzer Sie nicht wegen einer unbegründeten Entlassung verklagen kann, wenn Sie ihn aufgrund weiterhin auftretender Probleme schließlich doch feuern müssen.

Reaktion auf Angriffe der Ebenen drei, vier und fünf

Wenn Sie einem Angriff oberhalb der Ebene zwei ausgesetzt sind, haben Sie ein echtes Problem. Sie müssen dann folgende Dinge tun:

Sie haben es mit einem Kriminellen zu tun. Wenn Sie ihn schnappen, brauchen Sie Beweise. Diese Beweise zu erbringen, wird einige Zeit dauern.

Wann ein Eindringen zur kriminellen Tat wird, ist nach der Internet-Rechtsprechung nicht immer eindeutig zu bestimmen. Auf jeden Fall reicht es nicht aus, daß jemand versucht, über sendmail an Ihre Datei /etc/passwd zu gelangen. Auch der Beweis einer Handvoll showmount -Anforderungen wird nicht genügen. Um wirklich etwas gegen den Eindringling in der Hand zu haben, müssen Sie konkrete Beweise dafür haben, daß er sich in Ihrem Netzwerk aufgehalten hat, bzw. daß er derjenige war, der Ihr Netzwerk mit Hilfe einer DoS-Attacke lahmgelegt hat. Um diese Beweise zu erhalten, müssen Sie die volle Wucht des Angriffs ertragen (es sei denn, Sie können einige Schutzmaßnahmen errichten, die sicherstellen, daß Ihr Netzwerk durch den Angriff keinen Schaden nehmen wird).

Mein Rat in einer solchen Situation wäre, nicht nur die Polizei einzuschalten, sondern mindestens ein qualifiziertes Sicherheitsunternehmen, das Ihnen helfen kann, den Angreifer zu schnappen. Das wichtigste bei einer solchen Operation sind die Log-Dateien und natürlich die Lokalisierung des Eindringlings. Die Logs können Sie selbst erzeugen. Das Auffinden des Eindringlings gestaltet sich schon etwas schwieriger. Sie könnten mit einem einfachen traceroute beginnen, und vielleicht setzen Sie ein Dutzend unterschiedliche Methoden ein, nur um am Ende feststellen zu müssen, daß das Netzwerk, von dem der Eindringling stammt, selbst ein Opfer ist oder eine bösartige Site. Im schlimmsten Fall ist es ein Netzwerk, das in einem Land liegt, in dem die deutsche Justiz keinen Einfluß mehr nehmen kann. In solchen Fällen können Sie wenig anderes tun, als Ihr Netzwerk abzusichern und wieder zur Tagesordnung überzugehen. Alles andere könnte sehr kostspielig werden und sich am Ende doch als Zeitverschwendung herausstellen.

25.9 Zusammenfassung

In diesem Kapitel haben Sie etwas über die unterschiedlichen Ebenen von Angriffen erfahren. Diese Ebenen sind durchnumeriert, wobei Ebene eins die harmloseste und Ebene sechs die schlimmste Art eines Angriffs ist. Sie haben erfahren, wie Sie auf die unterschiedlichen Angriffe reagieren sollten und welche Tools Sie verwenden können, um sie erfolgreich zu bekämpfen.

25.10 Informationsquellen

UNIX Incident Guide How to Detect an Intrusion. http://ciac.llnl.gov/ciac/documents/ CIAC-2305_UNIX_Incident_Guide_How_to_Detect_an_Intrusion.pdf

Securing Internet Information Servers. CIAC-2308. http://ciac.llnl.gov/ciac/documents/CIAC-2308_Securing_Internet_ Information_Servers.pdf

Threat Assessment of Malicious Code and Human Computer Threats. L. E. Bassham und T. W. Polk. National Institute of Standards and Technology. Report to the U.S. Army Vulnerability/Survivability Study Team, NISTIR 4939. Oktober 1992. http://bilbo.isu.edu/security/isl/threat.html

Hackers in the Mist. R. Blake. Northwestern University, Independent study in anthropology. 2. Dezember 1994. http://www.eff.org/pub/Privacy/Security/ Hacking_cracking_phreaking/Net_culture_and_hacking/Hackers/ hackers_in_the_mist.article

Computer Break-ins: A Case Study. Leendert van Dorn. Vrije University. 21. Januar 1993. http://www.alw.nih.gov/Security/FIRST/papers/general/holland.ps

Concerning Hackers Who Break into Computer Systems. Vorgestellt auf der 13. National Computer Security Conference. 1. Oktober 1990. http://www.cpsr.org/ftp/cpsr/ computer_crime/denning_defense_hackers.txt

Selling Security: Security Policies Are Key to a Strong Defense, But Top Management Must First Be Brought on Board. C. Waltner. InfoWorld. http://www.infoworld.com/cgi-bin/ displayArchives.pl?dt_iwe52-96_82.htm

The United States vs. Craig Neidorf: A Debate on Electronic Publishing Constitutional Rights and Hacking. D. E. Denning. Communications of the ACM. März 1991. http:// www.aracnet.com/~gtr/archive/intrusions.html

An Evening With Berferd In Which a Cracker is Lured, Endured and Studied. B. Cheswick. AT&T Bell Labs. ftp://research.att.com/dist/internet_security/berferd.ps

Recombinant Culture: Crime in the Digital Network. C. E. A. Karnow. Vorgestellt auf der Defcon II. Juli 1994. http://www.cpsr.org/cpsr/computer_crime/net.crime.karnow.txt

The Baudy World of the Byte Bandit: A Postmodernist Interpretation of the Computer Underground. G. Meyer und J. Thomas. Department of Sociology, Northern Illinois University. 5. März 1990. http://ei.cs.vt.edu/~cs6704/papers/meyer.txt

25.10.1 Erkennen von Eindringlingen (Intrusion Detection)

An Introduction to Intrusion Detection. Aurobindo Sundaram. http://www.techmanager.com/nov96/intrus.html

Intrusion Detection for Network Infrastructures. S. Cheung, K. N. Levitt und C. Ko. 1995 IEEE Symposium on Security and Privacy, Oakland, CA. Mai 1995. http:// seclab.cs.ucdavis.edu/papers/clk95.ps

Fraud and Intrusion Detection in Financial Information Systems. S. Stolfo, P. Chan, D. Wei, W. Lee und A. Prodromidis. 4th ACM Computer and Communications Security Conference. 1997. http://www.cs.columbia.edu/~sal/hpapers/acmpaper.ps.gz

Detecting Unusual Program Behavior Using the Statistical Component of the Next-Generation Intrusion Detection Expert System (NIDES). Debra Anderson, Teresa F. Lunt, Harold Javitz, Ann Tamaru und Alfonso Valdes. SRI-CSL-95-06. Mai 1995. (Nur in gedruckter Fassung erhältlich.) Zusammenfassung: http://www.csl.sri.com/tr-abstracts.html#csl9506

Intrusion Detection Systems (IDS): A Survey of Existing Systems and a Proposed Distributed IDS Architecture. S. R. Snapp, J. Brentano, G. V. Dias, T. L. Goan, T. Grance, L. T. Heberlein, C. Ho, K. N. Levitt, B. Mukherjee, D. L. Mansur, K. L. Pon und S. E. Smaha. Technical Report CSE-91-7, Division of Computer Science, University of California, Davis. Februar 1991. http://seclab.cs.ucdavis.edu/papers/bd96.ps

A Methodology for Testing Intrusion Detection Systems. N. F. Puketza, K. Zhang, M. Chung, B. Mukherjee und R. A. Olsson. IEEE Transactions on Software Engineering, Vol. 22, No. 10. Oktober 1996. http://seclab.cs.ucdavis.edu/papers/tse96.ps

GrIDS - A Graph-Based Intrusion Detection System for Large Networks. S. Staniford-Chen, S. Cheung, R. Crawford, M. Dilger, J. Frank, J. Hoagland, K. Levitt, C. Wee, R. Yip und D. Zerkle. The 19th National Information Systems Security Conference. http:// seclab.cs.ucdavis.edu/papers/nissc96.ps

NetKuang - A Multi-Host Configuration Vulnerability Checker. D. Zerkle und K. Levitt. Proceedings of the 6th Usenix Security Symposium. San Jose, CA. 1996. http:// seclab.cs.ucdavis.edu/papers/zl96.ps

Simulating Concurrent Intrusions for Testing Intrusion Detection Systems: Parallelizing Intrusions. M. Chung, N. Puketza, R. A. Olsson und B. Mukherjee. Proceedings of the 1995 National Information Systems Security Conference. Baltimore, MD. 1995. http:// seclab.cs.ucdavis.edu/papers/cpo95.ps

Holding Intruders Accountable on the Internet. S. Staniford-Chen und L.T. Heberlein. Proceedings of the 1995 IEEE Symposium on Security and Privacy, Oakland, CA. 8-10, Mai 1995. http://seclab.cs.ucdavis.edu/~stanifor/papers.html

Machine Learning and Intrusion Detection: Current and Future Directions. J. Frank. Proceedings of the 17th National Computer Security Conference, Oktober 1994. http:// seclab.cs.ucdavis.edu/~frank/mlid.html

Another Intrusion Detection Bibliography. http://doe-is.llnl.gov/nitb/refs/bibs/ bib1.html

Intrusion Detection Bibliography. http://www.cs.purdue.edu/coast/intrusion-detection/ ids_bib.html

Bibliography on Intrusion Detection. The Collection of Computer Science Bibliographies. http://src.doc.ic.ac.uk/computing/bibliographies/Karlsruhe/Misc/intrusion.detection.html



vorheriges KapitelInhaltsverzeichnisStichwortverzeichnisKapitelanfangnächstes Kapitel