Sicherheit in Netzen

Prof. Jürgen Plate
Dipl.-Ing. Jörg Holzmann

3 Gefahrenabwehr

3.1 Passwort-Sicherheit

Ist das Paßwort jetzt sicher? Keine Spur! Beim Einloggen in ein entferntes System per telnet, ftp, WWW oder rlogin wird Ihr Paßwort normalerweise im Klartext übertragen. Jeder, der die Übertragung (durch den Einsatz von "Schnüffel-Software" z. B. auf einem PC im Netz) mitlesen kann, kennt danach Ihr Paßwort. Benutzen Sie das Internet zur Übertragung Ihres Paßwortes, so wissen Sie nicht, welchen Weg Ihr Paßwort bei der Übertragung nimmt, und wer eventuell die Übertragung mitlesen kann.

Um das Problem der Paßwortübertragung über Netzwerke zu lösen, wurden in den letzten Jahren verschiedene Methoden entwickelt. Zwei sehr ähnliche Ansätze sind Secure Shell (ssh), SecureRPC von SUN und Kerberos vom MIT. Die Ansätze vermeiden die Klartextübertragung des Paßwortes durch asymmetische Verschlüsselung. Der ganze Mechanismus macht jedoch nur Sinn, wenn der Rechner, an dem man sitzt, über diesen Mechanismus verfügt. Muß man sich zuvor mit telnet oder rlogin auf einem anderen Rechner einloggen, so geht das Paßwort nach wie vor zwischen dem eigenen Arbeitsplatz und dem Rechner im Klartext übers Netz. Eine Public-Domain-Variante ist S/Key. Sie benutzt eine Serie von Einmal-Paßwörtern, die auf beiden Seiten aus dem geheimen Paßwort des Benutzers errechnet werden kann. Selbst die Neuinitialisierung der Einmal-Keys ist ohne die Gefahr des Abhörens möglich. Der Benutzer bleibt von diesem Mechanismus verschont, er benutzt nach wie vor ein Paßwort für verschiedene Systeme.

Gut für Eindringlinge sind Accounts mit Account-Namen als Passwort, Gast- und Demoaccounts ohne Passwort oder Accounts mit voreingestellten Passwörtern. Es sollte zudem verhindert werden, daß die Passwortdatei von Unbefugten gelesen werden kann.

Für die Auswahl eines Passworts gilt:

Der Zwang, regelmäßig das Passwort zu ändern, kann auch Unsicherheit zur Folge haben. Ein vierteljählicher Rhythmus führt beispielsweise zu "Frühling", "Sommer", "Herbst" und "Winter". Raten Sie mal, welche Begriffe bei monatlichem Wechsel vorkommen...

Gut sind Passworte mit einer Mischung aus Groß- und Kleinbuchstaben, die mindestens sechs Zeichen lang sind und aus einer zufälligen Auswahl von Ziffern und Buchstaben bestehen.

Notwendig ist eine entsprechende Systemunterstützung für sichere Passwörter, insbesondere auch für ihre beschränkte Gültigkeitsdauer. Wenn möglich, sollten Passwortdateien überprüft werden, ob die Passworte sicher sind und regelmäß geändert werden. Programme dafü sind crack, crahs oder cops. Änderungsfaule Benutzer erwischt man relativ einfach. Es wird eine Kopie von /etc/shadow angelegt und nach einem bestimmten Zeitraum mit der aktuellen Version der Datei verglichen.

Passwort-Cracker sind nichts anderes als Programme, die mittels der Kombination von Wörterbuch-Attaken und der Brute-Force-Methode versuchen, Paßwörter zu erhalten. Auf Basis eines umfangreichen Wörterbuches testen sie in sehr hoher Geschwindigkeit Wort für Wort, Zeichenkette für Zeichenkette auf Passwörter. Basierend auf einer umfangreichen Wörterbuchdatei wird jeder Wörterbucheintrag mit der vom Betriebssystem benutzten Verschlüsselung verschlüsselt und mit einem Zielpasswort verglichen. Wenn es zu einer Übereinstimmung kommt, ist das Passwort geknackt. Gute Passwort-Knacker gehen aber noch weiter, indem sie Regeln verwenden, z. B.:

Studien zeigten daß bis zu 30% aller Passwörter in einem UNIX-System erkannt werden können. Bekannte UNIX-Passwort-Cracker sind 'Crack' und 'John the Ripper', auf welche noch kurz eingegangen wird, 'Hades' (von Remote und Zabkar) oder 'CrackerJack' (von Jakal); für Windows NT sind 10phtCrack 2.0, ScanNT (von Midwestern Commerce Inc.) und NTCrack (von Somarsoft) die beliebtesten.

Crack wurde von Alec D. E. Muffet, einem Unix-Software-Ingenieur aus Wales, geschrieben. Crack automatisiert die Methode, einen sinnvollen Bereich des Suchraums zu bearbeiten. Das Programm benutzt eine Reihe von Wörterbüchern als Quelle von möglichen Paßwörtern zusammen mit einer Menge von Regeln, mit denen diese Wörter variiert werden können (z.B. Großschreiben des ersten Buchstaben oder Umdrehen des Wortes). Zusammen mit einer äußerst effizienten Implementierung der crypt()-Funktion und der Rechenleistung heutiger Maschinen läßt sich mit crack eine ziemlich ausführliche und erfolgversprechende Suche in wenigen Tagen oder gar Stunden durchführen.

Mit dem Befehl crack copy_of_password_file wird der Crack-Vorgang gestartet. Da das Cracken von Dateien mit mehreren hundert Einträgen den Rechner nicht unbeträchtlich belastet, bietet Crack ein sehr nützliches Feature: Der Crackversuch läßt sich auf mehrere Rechner aufteilen, so daß die Belastung der Resourcen verteilt werden kann.

John the Ripper vermag sogar mit verschiedenen Verschlüsselungsschemen umzugehen, u.a. mit DES, Blowfish, MD5 und WinNT LM Hashes. Weiter versteht er verschiedene Modi:

3.2 Rechnersicherheit

In der Betriebssystemsoftware (und auch der Anwendungssoftware) treten immer wieder Fehler auf, die unautorisierten Zugang für Hacker durch Ausnutzen von Sicherheitslöchern zuläßt. Eine hardwareunabhängige Sammlung dieser Fehler und die Initiative zur Behebung derselben unternehmen die CERTs (Computer Emergency Response Team). Wie viele Einrichtungen im Internet existieren CERTs auf mehreren Ebenen. Das deutsche CERT (DFN-CERT) ist an der Uni Hamburg lokalisiert. Die gesammelten Informationen des CERT werden auf einem FTP-Server zur Verfügung gestellt: (ftp.informatik.uni-hamburg.de, Directory: /pub/security). Nachrichten an das CERT können per E-Mail an dfncert@informatik.uni-hamburg.de gesendet werden.

Das Wichtigste ist jedoch die Prävention:

3.3 Abschottung von öffentlichen Datenbereichen

Für bestimmte Dienste wurden oder werden Sicherheitsmaßnahmen getroffen. So wird auf Unix-Servern für WWW oder ftp für den Abfragenden das Datenverzeichnis zum Wurzelverzeichnis. Auf diese Weise ist auch bei Sicherheitsmängeln im Serverprogramm niemals ein Zugriff auf Dateien außerhalb des reservierten Plattenbereichs möglich. Diese Methode kann man auch für den Betrieb einer Mailbox oder einen Gast-Login ohne Paßwort verwenden.

3.4 Überwachung von Protokolldateien und Benutzern

Jedes Betriebssystem legt Protokolle der wichtigsten Systemvorgänge an. Diese Protokolldateien sollten ständig auf Unregelmäßigkeiten untersucht werden, um so einen Eindringling aufzuspüren. Die Auswertung der Logdateien kann vielfach auch automatisch erfolgen. Typische Hinweise für einen Angriff sind unter anderem:

Viele Nutzer gehen auch mit ihrem Rechneraccount recht fahrlässig um. So werden aus Bequemlichkeit keine Paßworte verwendet oder der Account an einen Freund 'verborgt'. Hier helfen nur Aufklärung und bei wiederholten Verstößen Entzug der Rechenberechtigung. Wichtig ist es auch, festzulegen, wer neue Software in den Rechner einspielen darf. Denn auf diesem Weg gelangen Viren oder Trojanische Pferde ins System.

3.5 Sichern des Rechners

Keinen Zugang zum Server zulassen

Ein Server, der frei zugänglich ist, kann nicht sicher sein. Der Server ist der Kern eines jeden lokalen Netzes, es ist deshalb erforderlich, daß besonders viele Ressourcen zu dessen Schutz bereitgestellt werden. Der Schutz des Servers sollte Maßnahmen gegen unerwünschten physischen Zugang, Feuer, unregelmäßige Stromversorgung, Komponentenausfall (typischerweise in Speichermedien) und mangelhafte Kühlung umfassen. Für jedes Betriebssystem gibt es Tricks, wie man sich bei physikalischem Zugriff auf den Rechner unautorisiert Zugang verschaffen kann. Es ist außerdem auch schon vorgekommen, daß Rechner regelrecht ausgeschlachtet wurden und nur noch das Gehäuse mit Netzteil zurückblieb. Der Server wird in einen abgesperrten Raum gestellt, zu dem der Zugang sehr begrenzt ist. Nur der Systemverwalter und eventuelle Superuser und der Hardwareservice haben Zugang hierzu.
Es ist weiterhin zu empfehlen, für das Supervisor-Login nur einen bestimmten Arbeitsplätze zuzulassen. Sollte das Passwort des Systemverwalters kompromittiert werden, so ist es weiterhin nur möglich, das Login von dieser Maschine vorzunehmen.

Bei der Installation des lokalen Netzes und auch bei dessen laufendem Ausbau sollte bedacht werden, ob im Anschluß an den Serverraum ausreichende Ventilations- und Kühlungskapazität vorhanden ist, um ein vernünftige Arbeitsbedingungen für die zentralen Komponenten des lokalen Netzes zu sichern. Vorbeugende Maßnahmen bestehen in der Verwendung von feuerhemmendem oder feuerfestem Baumaterial. Der Serverraum sollte keine brennbaren Dinge enthalten, z. B. Druckerpapier, Handbücher, Verpackungen, Holzregale und -tische. Weiterhin wichtig sind Rauch- und Feuermelder, griffbereite Feuerlöscher und Training der Mitarbeiter für den Brandfall. Entscheidend für eine effektive Vorbeugung und Begrenzung von Wasserschäden ist, daß der Serverraum nicht unterhalb der Erdoberfläche eingerichtet wird. Der Serverraum darf auch nicht unter überführten Rohrleitungen, Abflüssen, Küchenbereichen und Badebereichen plaziert werden. Die Sicherung der Stromversorgung umfaßt Maßnahmen gegen Störungen und totalen Stromausfall. Ein Stromausfall kann durch unterbrochene Versorgungsleitungen, aber auch durch Ansprechen von Überlastsicherungen hervorgerufen werden. Um sich gegen Störungen oder Ausfall der Stromversorgung zu schützen, empfiehlt sich nachdrücklich die Anschaffung und Installation einer USV (unterbrechungsfreie Stromversorgung), die gerade mit diesen Verhältnissen fertig wird. Die USV muß eine Notstromversorgung (akkumulatorbasiert) in dem Umfang bieten können, wie es zur Durchführung eines kontrollierten Herunterfahrens des Servers erforderlich ist. Generelle Maßnahmen bezüglich Stromversorgung und lokales Netz

Nicht benötigte Dienste und Ports sperren

Windows NT
Bei Windows NT-Servern wählt man in der Systemsteuerung das Icon "Dienste" an.

Hier kann dann jeder nicht benötigte Dienst gesperrt (deaktiviert) werden.

Unix
Bei UNIX und Linux bearbeitet man mit einem Editor die Datei /etc/inetd.conf. Dienste werden deaktiviert, indem man die entsprechenden Zeilen mit einem # am Anfang auskommentiert. Hier ein Ausschnitt der Datei:

# <service_name> <sock_type> <proto> <flags> <user> <server_path> <args>
#
ftp     stream  tcp  nowait   root   /usr/sbin/tcpd  wu.ftpd -a
# ftp	stream  tcp  nowait   root   /usr/sbin/tcpd  in.ftpd
telnet  stream  tcp  nowait   root   /usr/sbin/tcpd  in.telnetd
# nntp  stream  tcp  nowait   news   /usr/sbin/tcpd  /usr/sbin/leafnode
shell   stream  tcp  nowait   root   /usr/sbin/tcpd  in.rshd -L
# shell stream  tcp  nowait   root   /usr/sbin/tcpd  in.rshd -aL
#
# login  stream  tcp  nowait  root  /usr/sbin/tcpd   in.rlogind
# login  stream  tcp  nowait  root  /usr/sbin/tcpd   in.rlogind -a
# exec   stream  tcp  nowait  root  /usr/sbin/tcpd   in.rexecd
# talk   dgram   udp  wait    root  /usr/sbin/tcpd   in.talkd
# ntalk  dgram   udp  wait    root  /usr/sbin/tcpd   in.talkd
#
pop3    stream  tcp     nowait  root    /usr/sbin/tcpd  /usr/sbin/popper -s  
Das Aktivieren der neuen Konfiguration erfolgt mit dem Kommando:
kill -HUP Prozess-ID von inetd. z. B.: (Eingaben fett gedruckt)
root@lx2-lbs# ps -aux | grep inetd
root       121  0.0  0.3   912   420  ?  S    13:07   0:00 /usr/sbin/inetd
root      1098  0.0  0.3   884   400  p2 S    16:36   0:00 grep inetd
root@lx2-lbs# kill -HUP 121  

Beschränkung des Zugriffs auf alle Dienste

Unter UNIX gibt es zwei Möglichkeiten der Einschränkung: Die zweite Variante ist sicherer! Gesteuert wird der Zugriff von außen durch zwei Dateien, /etc/hosts.deny und /etc/hosts.allow. Am einfachsten läßt sich die Steuerung des Zugriffs an einem Beispiel zeigen. Die Syntax lautet generell bei allen Einträgen: Dienst: Benutzerkreis.

/etc/hosts.deny/etc/hosts.allow
ALL:	    ALL
shd:        ALL 
in.telnetd: .xyz.mydomain.de 
wu.ftpd:    .xyz.mydomain.de

In obigem Beispiel ist also alles verboten, bis auf ssh von überall her, telnet und FTP nur innerhalb der Domain xyz.mydomain.de.

Unsichere Zugänge zum System entfernen

Systemsicherheit überprüfen

Die Aktivitäten auf dem Rechner und im Netz sollten regelmäig überprüft werden, um Probleme und Angriffe zu entdecken. Dazu ist es notwendig, daß die Administratoren ihre Systeme sehr gut kennenlernen:

Installation von Alarmmechanismen

Datensammlung Beispiele:

Analyse bestehender Log-Dateien

Siehe auch den Abschnitt über Intrusion Detection im nächsten Kapitel.

Allgemeine Sicherhungsmaßnahmen

Die Kabelführung in der Nähe von größeren Elektromotoren, Neonbeleuchtungen und anderen Quellen elektrischer Störungen muß vermieden werden. Vermeiden Sie auch, daß kritische Komponenten (Server, Hubs, Bridges, Router, etc.) an den gleichen Versorgungsstrang angeschlossen sind wie mögliche Störungsquellen (Kopiergeräte, Kühlschränke, Laserdrucker, usw). Am besten werden solche Komponenten separat abgesichert oder sie erhalten eine eigene USV - was kein Problem ist, wenn mehrere Komponenten zusammen mit der USV in einen Schaltschrank eingebaut werden. Wählen Sie eine Kabelführung und eine Netztopologie, die eine starke Trennung und einen großen Schutz der Netzkomponenten bietet. Lassen Sie die elektrischen Installationen von einem Fachmann mit Kenntnissen auf den Gebieten Stromversorgung und lokale Netze überprüfen.

Sicherung von Netzdruckern: Berichte, Projekte und andere Dokumente, die im Unternehmen ausgearbeitet werden, liegen früher oder später über die Netzdrucker in schriftlicher Form vor. Die meisten Mitarbeiter haben wahrscheinlich schon vertrauliches Material im Druckerraum gesehen, wenn sie dort gewesen sind, um ihre eigenen Ausdrucke abzuholen. Die Möglichkeit, daß ausgedrucktes Material in die falschen Hände gerät, ist deshalb offensichtlich. Das Risiko eines unsachgemäßen Zugangs zu vertraulicher Information wird durch eine oder mehrere der folgenden Maßnahmen verringert: Schaffen Sie lokale oder persönliche Drucker für Mitarbeiter oder Arbeitsgruppen an, die sich mit vertraulichen Informationen beschäftigen. Ein oder mehrere Drucker können auch in einen Raum verlegt werden, wo ein Sicherheitsmitarbeiter für die Verteilung ausgedruckten Materials sorgt.

Bei der Industriespionage existiert der Begriff "trashing". Das läuft ganz einfach darauf hinaus, weggeworfenes schriftliches und elektronisches Material als Quelle zu Paßwörtern, Benutzer-IDs oder anderen wertvollen Informationen über das Unternehmens zu benutzen. Schriftliches Material können Ausdrucke, Handbücher, interne Memos, Berichte und anderes sein. Weggeworfene Disketten, CD-ROMS, Festplatten und Bänder können ebenfalls Daten enthalten, die nicht in die falschen Hände fallen sollten. Maßnahmen gegen trashing sind abgeschlossene Abfallbehälter und der Reißwolf sowie Zerstörung oder Überschreiben von ausgemusterten Datenträgern. Dazu gehören übrigens auch die Carbon-Farbbänder von Schreibmaschinen und die Transferfolien von Normalpapier-Faxgeräten und bestimmten Typen von Farbdruckern.

3.6 Sichere Protokolle

S-HTTP

Das Secure Hypertext Transfer Protocol nimmt nicht nur am Transferprotokoll Erweiterungen vor, sondern definiert auch neue Elemente für die HTML-Sprache. S-HTTP stellt einen Rahmen für die Anwendung verschiedener kryptografischer Standardmethoden dar. Jede Nachricht kann durch eine beliebige Kombination aus drei Mechanismen geschützt werden: digitale Unterschrift, Datenverschlüsselung und Authentifizierung. Eine S-HTTP-Nachricht besteht aus einer gekapselten HTTP-Nachricht und einigen vorangestellten Kopfzeilen, die das Format der gekapselten Daten beschreiben.
Beide Seiten können im Rahmen einer Verhandlung Angaben über die verwendbaren beziehungsweise geforderten Erweiterungen gegenüber HTTP machen. Dazu gehören: Nachrichtenformate, Typen der Zertifikate, Schlüsselaustauschmechanismus, Verfahren für digitale Unterschriften, Hash-Algorithmus für den digest sowie Verschlüsselungsverfahren für Kopf und Inhalt. Das könnte folgendermaßen aussehen: 'Dieser Client verschlüsselt alle Nachrichten mittels DES und vermag mit DES oder RC5 verschlüsselte Nachrichten zu empfangen.' Sowohl asymmetrische (öffentliche Schlüssel mit entsprechenden Zertifikaten) als auch symmetrischen Verfahren (Sender und Empfänger benutzen denselben Geheimschlüssel) sind aufgeführt. Im ersten Fall stehen auch digitale Unterschriften zur Verfügung, im zweiten kann der Austausch des Geheimschlüssels auf drei Wegen erfolgen: in-band (Schlüssel wird mit dem öffentlichen Schlüssel des Servers geschützt), out-band (ein vorher festgelegter Schlüssel) und Kerberos (Nutzung von Kerberos-Tickets). Mit dem Sitzungsschlüssel läßt sich ein Transaktionsschlüssel chiffrieren, der bei der Datenverschlüsselung Anwendung findet.
S-HTTP definiert einen neuen URL-Protokolltyp 'shttp', der auf die Fähigkeiten des Servers bezüglich S-HTTP hinweist. Der Client wird damit aufgefordert, bereits die Anforderung gekapselt zu senden. Die dazu notwendigen Informationen sind in neuen Attributen (DN, NONCE, CRYPTOPTS) des Ankers für diesen Link beziehungsweise dem neuen Sprachelement (tag) CERTS enthalten. Damit lassen sich beispielsweise die Informationen eines Formulars verschlüsseln.

SSL

Das zweite Protokoll mit kommerziellem Hintergrund erlangt seine Bedeutung durch die große Verbreitung des Web-Browsers Netscape Navigator. Dieser Client beherrscht ein Protokoll namens Secure Socket Laver (SSL). Wie der Name andeutet, ist es nicht nur für HTTP vorgesehen, sondern soll jedes zuverlässige Transportprotokoll (im Falle Netscape/SSLRef: TCP) um ein Konzept für einen sicheren Kanal (Vertraulichkeit, Authentifikation, Datenintegrität) erweitern.

Mit SSL (das Kürzel steht für Secure Sockets Layer) kommt früher oder später jeder Surfer in Berührung auch wenn er es unter Umständen gar nicht bemerkt. Eine gesicherte Verbindung über dieses Protokoll erkennt man im Browser daran, daß die dargestellte URL mit dem Kürzel "https://" beginnt; zusätzlich erscheint in der Statusleiste des Browsers ein eingerastetes Vorhängeschloß. SSL entstand ursprünglich 1994 als proprietäre Lösung von Netscape für ein verbindungsorientiertes Sicherungsprotokoll auf der Datenschicht. Schon ein Jahr später wurde es bei der IETF (Internet Engineering Task Force) zur Normung eingereicht, heute dient es in der Version 3.0 als Arbeitsbasis der "Transport Layer Security (TLS) Working Group" der IETF. Der ursprüngliche Zweck von SSL bestand lediglich in der Sicherung der Kommunikation zwischen Web-Server und Browser; inzwischen läßt es sich in diversen Varianten allerdings auch zusammen mit NNTP, POP3, SMTP oder Telnet einsetzen.

Im ISO/OSI-Schichtenmodell der Datenkommunikation residiert SSL zwischen der Transportschicht (TCP oder UDP) und der Anwendung. Dabei stellt der SSL-Layer für die Applikation statt der normalen Socket-Funktionen wie read oder write spezielle Methoden zur Eröffnung und Nutzung einer sicheren Uansportverbindung zur Verfügung. Die Anwendung reicht die Daten, anstatt sie direkt an die Transportschicht zu übergeben, also zunächst an SSL weiter. Dieses schützt Verbindung und Daten durch die Bearbeitung mit kryptographischen Verfahren und übermittelt erst anschließend die Daten an die Transportschicht.

Insgesamt kombiniert SSL fünf verschiedene Protokolle:

Die Organisation von SSL als Layer zwischen Applikations- und TransportSchicht erlaubt dabei, zusätzlich auf Anwendungsebene Sicherheitsprotokolle wie S-HTTP (Secure HTTP) oder SET (Secure Electronic Transactions) zu implementieren. Dadurch läßt sich die Gesamtsicherheit des Systems noch einmal steigern, wenn auch zu Lasten der Performance.

PortnummerArtProtokoll
443HTTP über SSLHTTPS
465SMTP über SSLSSMTP
563NNTP über SSLSNNPS
992Telnet über SSLLNETS
995POP3 über SSLSPOP3

Um über SSL eine gesicherte Verbindung aufzubauen, müssen die Kommunikationspartner sich zunächst einmal über die zu verwendenden kryptographischen Verfahren und Parameter einig werden. Grundsätzlich bietet SSL dabei Schlüssel-Austauschverfahren, eine symmetrische Verschlüsselung sowie die Berechnung einer kryptographischen Prüfsumme als Möglichkeit an. Für jede dieser Möglichkeiten lassen sich verschiedene Verfahren nutzen. etwa RSA oder Diffie-Hellmann für den Schlüsselaustausch, DES oder IDEA für die Verschlüsselung sowie MD5 und SHA für die Prüfsumme. Als kleiner Haken erweist sich dabei, daß die meisten SSL-relevanten Produkte aus den USA stammen und daß aufgrund der dort geltenden Exportbeschränkungen nur bestimmte Schlüssel-Längen genutzt werden können.

Vor der Übertragung der eigentlichen Daten arbeiten Client und Server ein Handshake-Protokoll ab, in dem der Sitzungsschlüssel ausgetauscht und die Authentifikation vorgenommen wird. Der Client eröffnet den Handshake mit einem Einmalwert (challange), der Liste der unterstützten Verschlüsselungsverfahren und sofern vorhanden - einer Session-ID aus einer früheren Sitzung. Der Server antwortet mit einer neuen Connection-ID. Wenn er im Cache die angegebene Session-ID findet, können beide Seiten einen früher vereinbarten Hauptschlüssel (master key) benutzen. Anderenfalls sendet der Server sein Zertifikat und eine Liste der verwendbaren Chiffren. Der Client generiert einen neuen Master-Key und sendet ihn mit dem Public-Key des Servers verschlüsselt an diesen. Aus dem Hauptschlüssel und verbindungsbezogenen Daten werden mittels einer Hash-Funktion (MD5) die Sitzungsschlüssel abgeleitet, die für die Datenverschlüsselung Anwendung finden. Für jede Richtung (Senden/Empfangen) wird dabei ein eigener Sitzungsschlüssel benutzt - der Hauptschlüssel selbst kommt bei der Datenverschlüsselung nie zum Einsatz. Abschließend schickt der Client die mit seinem Sendeschlüssel chiffrierte Connection-ID und der Server den mit seinem Sendeschlüssel verschlüsselten Einmalwert. Der Client überprüft unter Verwendung seines Empfangsschlüssels, ob der Einmalwert mit dem von ihm gesendeten übereinstimmt und kann damit sicher gehen, daß der Server als der tatsächliche Inhaber des Zertifikats authentisch ist. Denn anderenfalls konnte der Server den Hauptschlüssel nicht korrekt entschlüsseln und folglich keine Sitzungsschlüssel generieren.
Der Server hat ebenfalls die Möglichkeit, die Authentizität des Clients zu überprüfen. Die Aufforderung dazu enthält einen Einmalwert und eine Liste anwendbarer Verfahren zur Authentifikation. Der Client antwortet mit seinem Zertifikat und Authentifikationsinformationen. Für diese wird mit MD5 ein digest Über Sende- und Empfangsschlüssel, den Einmalwert und das Zertifikat des Servers erzeugt und mit dem privaten Schlüssel des Clients (entsprechend dem Zertifikat) verschlüsselt. Zum Abschluß schickt der Server dem Client verschüsselt die neue Session-ID.

Nach erfolgreicher Beendigung des Handshake-Protokolls sind beide Seiten zur Übertragung der Anwendungsdaten bereit. Diese werden im Rahmen eines Record-Protokolls nach dem vereinbarten Verfahren verschlüsselt und mit einem Message Authentication Code zur Gewährleistung der Datenintegrität versehen. Das SSL-Protokoll bietet einen sehr einfachen und effizienten Mechanismus zur Befriedigung der Sicherheitsbelange vieler Anwendungsprotokolle.

Neben der Verschlüsselung bietet SSL optional noch eine zweite Methode an, die Verbindung zu sichern: Die Authentisierung eines oder beider beteiligter Kommunikationspartner. Diese Variante stützt sich auf den Einsatz externer Certification Authorities (wie etwa Verisign), über die sich digitale Zertifikate ausstellen lassen. Die digitalen Unterschriften der wichtigsten Zertifizierungs-Instanzen bringen Internet Explorer und Navigator dabei schon mit, so daß zur Kommunikation mit diesen nicht noch extra Zertifikate angefordert werden müssen. Die verschiedenen SSL-Protokollversionen bieten bei der Authentifizierung unterschiedliche Möglichkeiten.

SSL-2 erfordertlediglich eine Zertifizierung des Servers, so daß der Kommunikationspartner vom Client aus einwandfrei identifizierbar ist. Dadurch lassen sich gängige Täuschungsmanöver wie IP-Spoofing (also das Vorgaukeln einer fremden IP-Adresse zum Abfangen der an diese gerichteten Daten) unterbinden. Beim Verbindungsaufbau erhält der Client vom Server das digitale Zertifikat der Site. Daraufhin generiert der Client einen Session Key, mit dem er die gesamte Kommunikation mit der Site verschlüsselt. Den Key selber verschlüsselt er mit dem Public Key des authentifizierten Servers, so daß nur dieser die Verbindungsdaten lesen kann.

SSL-3 setzt die Zertifizierung der Kommunikationspartner voraus. Dazu muß der Anwender bei einem Trust Center ein Client-Zertifikat anfordern, das meist kostenpflichtig ist (ca. 15 Dollar). In der Kombination von Server- und Client-Authentifizierung bietet SSL dann komplett abgesicherte Verbindungen via Internet.

Neben den "Standard"-Varianten von SSL existieren auch spezialisierte Varianten dieses Verfahrens. Die bekannteste davon ist Fortezza, welche von den US-Behörden zum Austausch sensitiver Daten benutzt wird. Sie setzt zur schnelleren Verschlüsselung auf Hardware und verwendet als Schlüssel-Austauschmechanismus KEA anstatt RSA. Über kurz oder lang wird SSL als Standard vermutlich von dem auf ihm basierenden TLS 1.0 - das bereits als IETF-Draft vorliegt ganz abgelöst werden.

Ausführliche Whitepapers zu Aufbau und Funktion des Secure Sockets Layer und den dazugehörigen Sicherheits-Zertifikaten finden Sie unter

http://directory.netscape.com/Computers/Security/Internet/SSL-TLS
http://directory.netscape.com/Camputers/Internet/Protocols/SSL-TLS

Typische Beispiele für Certification Authorities bieten Verisign (http://www.verisign.com) und Globalsign (http://www.globalsign.com).

Dort erhalten Sie sowohl Server- als auch Client-Zertifikate. Von letzteren offerieren beide Anbieter auch kostenlose, jedoch zeitbeschränkte Versionen. Eine umfassende Darstellung des neuen IETF-Standards TLS 1.0 direkt aus erster Hand bietet der RFC 2246.

S/Key

Die Idee zum wahrscheinlich am weitesten verbreiteten Programm zur Nutzung von Einmalpaßwörtem (OTP: orte time password) stammt bereits aus dem Jahre 1981. Aber erst ein knappes Jahrzehnt später wurde sie in den Bellcore Labs aufgegriffen und nahm als S/Key Gestalt an. Der zugrundeliegende Mechanismus ist verblüffend einfach: Aus einem geheimen Paßwort s wird durch N-fache Anwendung einer sicheren Hash-Funktion (MD4) ein OTP erzeugt:

P0 = fN(s)

Das nächste OTP erhält man durch (N -1)-maliges Anwenden des Hash:

P1 = fN-1(s)

Die generelle Erzeugunsvorschrift lautet damit:

Pi = fN-i(s)

bzw.

Pi = f(Pi+1)

Erlangt ein Unberufener Kenntnis von einem OTP Pi, kann er trotzdem nicht das nächste zu verwendende Paßwort Pi+1 ermitteln, da sich die Umkehrung f'(pi) der sicheren Hash-Funktion nicht berechnen läßt. Der entfernte Host erhält zunächst das OTP P0. Wenn sich ein Benutzer anmelden will, schickt der Host ihm die Sequenznummer i des letzten gespeicherten Paßworts. Der Benutzer antwortet daraufhin mit dem nächsten Paßwort pi+1. Der Host führt folgende Berechnung durch:

Pi = f(fN-i-1l(s)) = f(Pi+1)

Stimmt der berechnete Wert nut dem gespeicherten überein, so ist der Nutzer authentifiziert. Daraufhin überschreibt der Host das alte OTP pi mit dem soeben erhaltenen Pi+1. Somit muß der Host das geheime Paßwort gar nicht kennen.Da mit jedem Gebrauch und somit zunehmenden i die Anzahl der Iterationen der Hash-Funktion abnimmt, muß zu einem bestimmten Zeitpunkt eine Reinitialisierung (Neuberechnung der OTPs) vorgenommen werden.
S/Key erweitert diesen Grundalgorithmus dahingehend, daß das Paßwort eine Verkettung aus dem eigentlichen Paßwort s und einem Initialwert (seed) darstellt. Der Initialwert wird vom entfernten Host gemeinsam mit der Sequenznummer gesendet. Damit läßt sich ein geheimes Paßwort, das der Nutzer sich merkt, für verschiedene Hosts und auch für die Reinitialisierung verwenden.
Zum Berechnen der OTPs stehen Clientprogramme für Unix-, Macintosh-, DOS- und Windows-Systerne zur Verfügung. Der Nutzer braucht nur die Sequenznummer, den Initialwert und sein geheimes Paßwort einzugeben. Alternativ kann er sich auch eine Liste von OTPs im voraus berechnen lassen, um sie beispielsweise auf Reisen mit sich zu führen. Auf der Hostseite werden das 'login'- und das 'su'-Programm sowie der ftp-Server modifiziert. Diese Änderungen laufen unter allen gebräuchlichen Unix-Systemen.
S/Key ist auf ftp.thumper.bellcore.com/pub/nmh/ verfügbar. Die Navy Research Labs haben das Programmpaket unter der Bezeichnung OPIE 2.0 (one-time passwords in everything) weiterenwickelt: ftp.rirl.navy.mil/pub/security/nrl-opie/.

Secure Shell (ssh und scp)

Unter "SSH" versteht man einerseits ein Programm, die Secure Shell, andererseits aber eine Protokoll-Schnittstelle, über die auch Dateien kopiert oder andere Protokolle getunnelt werden können. Das SHH-Protokoll wurde von Tatu Ylönen an der TU Helsinki in Finnland entwickelt. Dieses Protokoll wurde erstmalige im Juni 1995 als lizenzfreie Version 1.0 freigegeben. Von da an wurden stets Weiterentwicklungen unternommen, an denen hauptsächlich die von Ylönen gegründete Firma SSH Communications Security Ltd. beteiligt war und ist. Derzeit befindet sich eine Version 2.0 auf dem Markt, die jedoch nicht mehr kommerziell vertrieben wird, sondern lizenzpflichtig ist. Des weiteren gibt es eine Reihe freier Implementierungen, wie z.b. OpenSSH, die auf das Protokoll 1.X aufsetzen und daher frei verfügbar sind (http://www.openssh.org).
Die Secure Shell ermöglicht das Einloggen auf einem anderen Rechner über das Netz, um Programme auf dem Remote- Rechner auszuführen oder Dateien über das Netz zu kopieren. Einerseits unterstützt sie dabei die zuverlässige gegenseitige Authentifizierung der Partner. Andererseits bietet sie sicheren Schutz vor dem Abhören der Kommunikation (Unterbindung von "Man in the middle attack", "IP-Spoofing", "Hijacking", etc.) und zuverlässige Integritätsüberwachung. Dabei kommt es vor allem an auf starke Verschlüsselung des Datenverkehrs, X11 Forwarding, Port Forwarding, sichere Authentifzierung, Agent Forwarding und Datenkompression. Von SSH werden ausschließlich symmetrische Verschlüsselungsalgorithmen zum Austausch der übermittelten Daten unterstützt: IDEA, DES, 3DES, Blowfish, TwofishArcfour.

OpenSSH verwendet beispielsweise die symmetrischen Verschlüsselungsalgorithmen Triple-DES, Blowfish und IDEA. Sie sind alle drei patentfrei. Man kann davon ausgehen, daß diese Verfahren sicher sind, da sie offen gelegt und keine gravierenden Sicherheitslücken bekannt sind. Das symmetrische Verfahren beruht darauf, daß der gesamte Datenverkehr mit nur einem geheimen Schlüssel verschlüsselt ist und dieser sowohl beim Sender als auch Empfänger zum Ver- bzw. Entschlüsseln benutzt wird. Da dieser geheime Schlüssel den beiden an der Sitzung teilnehmenden Personen zur Kommunikation bekannt sein muß, muß ein Schlüsselaustausch stattfinden. Dazu verwendet SSH den RSA-Algorithmus. Prinzipiell läuft ein Login folgendermaßen ab (Es wird vorausgesetzt, daß auf dem Zielrechner der ssh-Server und auf der Client-Workstation, von der aus man eine Verbindung zum Zielrechner herstellen will, der ssh-Client installiert ist):

Eigenschaften von SSH im Überblick

Mit der SSH besteht Schutz vor

In der Grundversion unterstützt die Secure Shell vier Verfahren zur Authentifizierung des Clients, wobei die Nutzung der einzelnen Verfahren durch Kommandozeilen-Argumente bzw. Einträge in den entsprechenden Konfigurationsdateien gezielt vom Server zugelassen bzw. unterdrückt werden können:

  1. Host-Based-Authentifizierung
    Bei diesem Verfahren basiert die Authentifizierung auf dem Hostnamen des Client. Sie entspricht der Authentifizierung bei rlogin und rsh unter UNIX. Hierbei werden die bekannten Hosts beim Server durch einen Eintrag in der Datei etc/hosts.equiv oder /etc/shosts.equiv bzw. $HOME/.rhosts oder $HOME/.shosts. verwaltet. Dieses Verfahren ist nicht gegen Spoofing-Attacken gefeit.
  2. Host-Based-RSA-Authentifizierung
    Dieses Verfahren stellt eine Kombination aus der "Host-Base-Authentifizierung" mit einer RSA-basierten Authentifizierung des Clients dar. Dabei werden die public Keys der Clients in den Dateien $HOME/.ssh/known_hosts und /etc/ssh_known_hosts des Servers abgelegt. Bei der Authentifizierung muß der Client in einem "Challenge-Response-Dialog" nachweisen, daß er den zugehörigen privaten Schlüssel kennt.
  3. Paßwort-Authentifizierung
    Hierbei erfolgt die Authentifizierung durch die Angabe eines Benutzerpassworts. Dabei wird die Verschlüsselung bei Übertragung des Passworts durch den Sitzungsschlüssel gewährleistet. Das Sicherheitsrisiko hängt dabei von der Stärke des Passwortes ab.
  4. Reine RSA Authentifizierung
    Diese Methode gilt als flexibel und potentiell sicherste Methode zur Client Authentifizierung. Hierbei muss der Client über einen "Challenge-Response-Dialog" nachweisen, das er den zum public-key gehörigen private-key kennt. Dieses Challenge-Response-Verfahren läßt sich dabei automatisch durch den SSH-Agenten abwickeln. Die zur Authentifizierung notwendigen öffentlichen Schlüssel stehen dabei im Serververzeichnis $HOME/.ssh/authorized_keys. Das notwendige Schlüsselpaar des Nutzers wird beim Client in deiner Datei namens $HOME/.ssh/identity gespeichert.

Gibt man die Userid nicht explizit an, wird diejenige genommen, unter der das scp-Kommando auf der lokalen Workstation abgesetzt wird. Alternativ kann in einer lokalen ssh-Konfigurationsdatei $HOME/.ssh/config für jeden Zielrechner eine Userid definiert werden, die defaultmäßig genommen wird.

Zugangsvalidierung

Bei der Zugangsvalidierung über ssh gibt es im wesentlichen zwei Möglichkeiten:

Andere Dienste über SSH tunneln

Es ist möglich, E-Mail, ftp, etc. über eine ssh-Verbindung zu tunneln.
Unverschlüsselte Verbindung

Verschlüsselte Verbindung

TSAP=Transport Service Access Point

ssh ohne Passwort

Public Key Authentication dient dazu, sich per SSH auf einem anderen Rechner einzuloggen oder Dateien zu übertragen, ohne sich jedes Mal mit einem Paßwort authentifizieren zu müssen. Technisch geschieht dies so, daß zwei zueinander passende Schlüssel-Dateien erzeugt werden - in der einen steht der Private Key, in der anderen der Public Key. Der Private Key bleibt beim Benutzer und muß vor fremdem Zugriff geschützt werden; der Public Key hingegen wird auf dem Server hinterlegt. Wenn der Benutzer sich nun anmelden möchte, überprüft der Server, ob er im Besitz eines zum hinterlegten Public Key passenden Private Keys ist, und gewährt nur dann den Zugang auch ohne Paßwort. Wenn man Public Key Authentication benutzt, dann ist ab sofort der Private Key dem normalen Paßwort gleichgestellt. So wie man sein Paßwort vor fremdem Zugriff schützen muß (z.B. in dem man es nicht aufschreibt und dann den Zettel rumliegen läßt - in einen Tresor gepackt, wäre ein solcher Zettel aber o.k.), so muß man jetzt den Private Key vor fremdem Zugriff schützen. Deswegen besteht die Möglichkeit, den Private Key wiederum mit einer Passphrase zu schützen - im Prinzip wie ein Paßwort für den Private Key, nur ohne Längenbeschränkung.

Wo ist denn da der Vorteil, wenn man sich zwar ohne Passwort einloggen kann, aber für den Private Key doch wieder eine Passphrase braucht? Nun, zum einen kann man sich später mit diesem einen Schlüssel auf viele verschiedene Rechner einloggen und muß sich nicht deren evtl. verschiedene Paßwörter merken. Zum anderen gibt es den SSH Agent, der in der Lage ist, sich die Passphrase für die Dauer ein Sitzung zu merken, so daß man sie nur einmal eingeben muß und bei allen weiteren Logins und Datei-Transfers nicht mehr gefragt wird.

Es besteht auch die Möglichkeit, eine leere Passphrase zu verwenden - dann aber ist der Private Key ungeschützt! Jetzt muß man auf anderem Wege sicherstellen, daß niemand an den Schlüssel herankommt, d.h. z.B. die Datei-Zugriffsrechte dürfen nur dem Eigentümer den Zugriff erlauben.

Zu einer passwortlosen Authentifizierung muß zuerst ein Schlüsselpaar generiert werden und zwar auf dem Rechner von dem aus man ssh ohne Passwort verwenden möchte. Wenn man nicht weiß welchen Typ Schlüssel man braucht, generiert man einfach alle. Dabei wird man jedesmal nach einem Passwort gefragt. Das ist nicht das Login-Passwort, sondern ein beliebiges neues Passwort, das nur dazu dient, seinen Privaten Schlüssel zu erzeugen.

plate@atlas:~ > cd .ssh

plate@atlas:~/.ssh > ssh-keygen ; ssh-keygen -t rsa ; ssh-keygen -t dsa
Generating public/private rsa1 key pair.
Enter file in which to save the key (/home/plate/.ssh/identity):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/plate/.ssh/identity.
Your public key has been saved in /home/plate/.ssh/identity.pub.
The key fingerprint is:
ff:49:ac:41:86:40:a9:be:ea:13:59:48:ba:6b:0f:36 plate@atlas
Generating public/private rsa key pair.
Enter file in which to save the key (/home/plate/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/plate/.ssh/id_rsa.
Your public key has been saved in /home/plate/.ssh/id_rsa.pub.
The key fingerprint is:
6e:8f:94:d2:bb:d6:68:37:fb:98:7c:1c:01:8c:de:0b plate@atlas
Generating public/private dsa key pair.
Enter file in which to save the key (/home/plate/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/plate/.ssh/id_dsa.
Your public key has been saved in /home/plate/.ssh/id_dsa.pub.
The key fingerprint is:
c1:32:0a:68:57:e9:d4:77:b5:01:6a:05:ae:8c:b6:24 plate@atlas

plate@atlas:~/.ssh > ls
id_dsa        id_rsa        identity      known_hosts
id_dsa.pub    id_rsa.pub    identity.pub  random_seed
Es wird jeweils ein privater Schlül und ein öffentlicher Schlüssel generiert.

Als nächstes muß der generierte Public Key (Dateiendung ".pub") in die Datei /$HOME/.ssh/authorized_keys bzw. .../authorized_keys2 auf der Gegenseite (der Rechner, auf dem man sich ohne Passwort einloggen möchte) eingetragen werden. Der Public Key und auch die authorized_keys*-Datei sind Textdateien. Die Zeile aus der id_*-Datei muß an die authorized_*-Datei angehängt werden, z.B. via Cut&Paste oder durch Kopieren der Datei (mit Passwort-Login) und Anhängen. Anschließend werden diese Authentifizierungsdaten verwenden:

plate@atlas:~/.ssh > scp identity.pub tralala:/home/plate/.ssh/
plate@tralala's password: 
identity.pub 100% |*****************************|   526  00:00    
plate@atlas:~/.ssh ssh tralala
plate@tralala's password: passwort
Last login: Sat Jan  4 10:23:12 2003 from atlas
...
Je nach ssh-Version muß auch einer der anderen Keys verwendet werden, z.B. id_dsa.pub nach authorized_keys2. Es existieren drei Arten von Keys, die auch in unterschiedlichen Dateien abgespeichert werde. Zu beachten ist, dass hier die diversen Implementierungen (F-Secure ssh, OpenSSH) divergieren.
RSA1 (alt, SSH Protokoll 1)
Erzeugen: ssh-keygen
Dateien: $HOME/.ssh/identity, $HOME/.ssh/identity.pub
DSA (SSH Protokoll 2)
Erzeugen: ssh-keygen -t dsa
Dateien: $HOME/.ssh/id_dsa, $HOME/.ssh/id_dsa.pub
RSA (SSH Protokoll 2)
Erzeugen: ssh-keygen -t rsa
Dateien: $HOME/.ssh/id_rsa, $HOME/.ssh/id_rsa.pub
Falls die Dateien authorized_* schon existieren, müssen die Keys an die Dateien angehängt werden.

Auf jeden Fall sind noch die Zugriffsrechte zu setzen:

chmod 600 ~/.ssh/authorized_*

Anschließend kann nochmals ein neuer Versuch gemacht werden, sich ohne Passwort anzumelden:

plate@atlas:~/.ssh ssh tralala
Last login: Sat Jan  4 11:18:38 2003 from atlas
...
Troubleshooting mit ssh -v, Zugriffsrechte aller Dateien auf go-rwx setzen, gegebenenfalls einen eigenen sshd mit Debugging auf einem nicht-privilegiertem Port starten.

Bei OpenSSH braucht man den Public Key einfach nur in der Datei ~/.ssh2/authorization eintragen mit der Zeile:

Key MEIN-SSH-PUBLICKEY.pub
In Verzeichnis ~/.ssh2/ sollte sich natürlich die Datei MEIN-SSH-PUBLICKEY.pub befinden. Jetzt loggt man sich wieder aus und richtet den auf dem lokalen Rechner verbliebenen Private Key zur Authentifizierung ein, indem die Zeile
IdKey MEIN-SSH-PUBLICKEY
in ~/.ssh2/identification einträgt.
Wenn nicht vorhanden, dann muss man den OpenSSH Public-Key in das SSH2-Format bringen. authorized_keys2 enthält eine Zeile ohne Zeilenumbruch:
ssh-dss
AAAAB3NzaC1kc3MAAACBAIygQj1gQp+XTk9oaZdkI8FJoABaWjwJjTVxiXUdau7pIddAht3rmcAgrQEN
z6Cy4he7Dbdu
...
rpnVxyEKaHSYRmGDbB78810kugDeF5+lZs881MN7UnA3crygPs2PEXmpJIK+GfiztqJvf0UjzhaPofLI
sQ1O9Q== USER@HOST
Wird umgewandelt in die Datei ident-ssh2.pub geschrieben:
---- BEGIN SSH2 PUBLIC KEY ----
Subject: root
Comment: "1024-bit dsa, root@atlas, Wed Jan 23 2002 12:04:22"
AAAAB3NzaC1kc3MAAACBAIygQj1gQp+XTk9oaZdkI8FJoABaWjwJjTVxiXUdau7pIddAht
...
f0UjzhaPofLIsQ1O9Q==
---- END SSH2 PUBLIC KEY ----

Fragen und Antworten:

Informationen über den ssh-Verbindungsaufbau
Mit der Option -v wird ssh/scp im 'Verbose Mode' aufgerufen. Hierdurch werden Informationen ausgegeben, die zur Problemanalyse hilfreich sein können.

Wieso fragt ssh nach dem Paßwort auf dem Zielrechner statt nach der RSA-Passphrase?
Es gibt drei Gründe:

Man erhält die Warnung "Host key not found from the list of known hosts."
Man sollte sicherstellen, daß die Datei /etc/ssh_known_hosts existiert und auf dem aktuellen Stand ist. Beim ssh-Zugang zu einem anderen Rechner muß man beim ersten Login über ssh darauf vertrauen, daß der HostKey, den der Zielrechner anbietet, korrekt ist. In jedem Fall kann der Login-Prozeß mit yes fortgesetzt werden. Der HostKey wird dann automatisch in die Datei $HOME/.ssh/known_hosts eingetragen, und die Meldung sollte beim nächsten Login über ssh nicht mehr erscheinen. Außerdem sollte man darauf achten, daß man den Zielrechner immer in derselben Form anspricht, da der Name zusammen mit dem HostKey in $HOME/.ssh/known_hosts eingetragen wird und der HostKey anschließend nur für diesen Namen bekannt ist.

Man erhält die Warnung "HOST IDENTIFICATION HAS CHANGED! ..."
Man sollte die Verbindung durch die Eingabe von no zunächst einmal abbrechen. Erkundigen Sie sich bitte beim jeweiligen Administrator, ob der HostKey wirklich geändert wurde. Ist dies der Fall, sollten Sie den bestehenden Eintrag für die Maschine aus der Datei $HOME/.ssh/known_hosts löschen, damit der aktuelle HostKey beim nächsten Login an die Datei angefügt werden kann.

IP Security (IPSec)

IPSec (Internet Protocol Security) stellt nicht ein einziges Protokoll dar, sondern eine Architektur zum Aufbau verschlüsselter Kommunikationsbeziehungen.Es wurde in den RFCs 1825 bis 1829 festgeschrieben. Es erfolgt eine Authentisierung und/oder Verschlüsselung von Datenpaketen auf der IP-Paket-Ebene, also noch bevor UDP- oder TCP-Pakete in IP-Pakete eingepackt und über die Leitung verschickt werden. Dieser Vorgang ist auf Ebene drei (Net-work-Layer) des ISO-7-Schichtmodells angesiedelt. je nach Zweck wird zu dem IP-Header (der ja die Quell- und die Zieladresse des Datenpakets trägt) ein Authentication Header (kurz AH) eingefügt, oder die verschlüsselten Daten werden verpackt (ESP = Encapsulating Security Payload). Mit dieser Sicherheitserweiterung kann demnach jedes einzelne Datenpaket vor Verfälschung geschützt und verschlüsselt werden. Damit würden einige Protokolle auf übergeordneten Schichten, wie z. B. SSL, bei bestimmten An wendungen überflüssig werden, denn je nach verwendetem Schlüssel lassen sich Pakete auch verbindungsorientiert sichern. Anwendungsbezogene Sicherheitsfunktionen, wie beispielsweise digitale Signaturen, werden weiterhin erforderlich sein, da IPSEC die Pakete nur auf dem Weg zwischen zwei Instanzen schützt. IPSEC ermöglicht

IPSEC ermöglicht den Aufbau von verschlüsselten Kanälen zwischen Routern oder von Clients zu Routern und ist damit eine Schlüsseltechnologie für den Aufbau von VPNs (Virtual Private Networks). IPSEC besteht im wesentlichen aus zwei Teilen:

  1. Protokolle zur Implemenation der Sicherheitsdienste: AH (Authentication Header) und ESP (Encapsulating Security Payload)
  2. Schlüsselmanagement: ISAKMP Protokoll (Internet Security Association and Key Management Protocol)

Beim Verschlüsseln kann zwischen zwei Modi unterschieden werden:

IPSEC läßt beliebige Schlüsselmanagement-Verfahren zu und erlaubt auch, starke Algorithmen und SmartCards zu verwenden. Das SKIP-Verfahren (Simple Key Management for Internet Protocol) beispielsweise ist auf DES (für ESP) und MD5 (für AH) definiert und beruht auf dem Diffie-Hellman-Keymanagement.

SET

Bei SET (Secure Electronic Transactions) handelt es sich um eine reine Anwendung, die ausschließlich zur sicheren Abwicklung von Zahlungsvorgängen dient. Ziel der maßgeblich von Mastercard und Visa getragenen Initiative ist es, einen Standard für das sichere Bezahlen mit Kreditkarten in unsicheren Netze, wie z. B. das Internet, zu schaffen. Für den nur zögernd anlaufenden Electronic Commerce wird von diesem Standard erwartet, daß er die notwendige Sicherheit und damit auch Akzeptanz auf Seiten der Nutzer realisiert. Darüber hinaus gewährleistet SET, daß es zu keinem Medienbruch bei der Abwicklung von Bestell- und Zahlungsvorgängen kommt. SET wurde auf der Basis von sieben sogenannten Business-Requirements entwickelt, die die Anforderungen an diesen Standard wie folgt spezifizieren:
  1. Zahlungs- und Orderinformationen sollen vertraulich behandelt werden.
  2. Die Integrität der im Rahmen des Zahlungsvorgangs übermittelten Daten soll gewährleistet sein.
  3. Der Kartenbenutzer muß sich als Karteninhaber authentisieren.
  4. Der Händler muß sich gegenüber dem Karteninhaber authentisieren.
  5. Es sollen die besten kryptografischen Verfahren verwendet werden.
  6. Das Protokoll soll nicht von sicheren Transportmechanismen auf unteren Schichten abhängen, dessen Benutzung aber nicht verbieten.
  7. Das Protokoll soll auf verschiedenen Hard- und Software-Plattformen lauffähig sein (Interoperabilität).
Weiterhin unterscheidet SET sieben an der Transaktion beteiligte Parteien: Karteninhaber, Händler, Kartenherausgeber (für Karteninhaber), Akquisiteur (für Händler), Zahlungs-Gateway, Kreditkarten-Institut diverse Zertifizierungsstellen (Karteninhaber-Zertifizierungsstelle, Zahlungs-GatewayZertifizierungsstelle). Die Transaktion zwischen Kunde und Händler hat folgenden formalen Ablauf:
  1. Der Karteninhaber wählt Waren und Dienstleistungen per Internet aus.
  2. Der Karteninhaber trägt seine Auswahl in ein elektronisches Bestellformular ein.
  3. Der Karteninhaber wählt die Art der Bezahlung aus (derzeit nur die Bezahlung per Kreditkarte).
  4. Der Karteninhaber versendet die Daten (Bestellung/Zahlungsinstruktionen) an den Händler (Kartenmarke, Kartennummer usw.).
  5. Der Händler läßt sich die Zahlung durch die Finanzinstitution des Karteninhabers bestätigen (Zahlungs-Authorisierungsanfrage).
  6. Der Händler sendet nach einer positiven Antwort eine Auftragsbestätigung an den Kunden.
  7. Der Händler liefert die Ware aus.
  8. Der Händler fordert von der Finanzinstitution des Karteninhabers die Bezahlung.
SET beschäftigt sich vor allem mit den unter Punkt 4, 5, 6 und 8 genannten Transaktionen. Als kryptografische Methoden werden symmetrische Verfahren (DES zur Verschlüsselung der Daten) sowie asymmetrische Ver-fah-ren (RSA) und Hashfunktionen (SHA1 für digitale Signaturen zur Authentisierung und Integritätsprüfung) genutzt. Mit der Einführung sogenannter dualer Signaturen hat das SET-Verfahren eine sehr interessante Lösung für die selektive Geheimhaltung von Transaktionen zwischen Kunde, Händler und Bank entwickelt. Diese Lösung stellt sicher, daß der Händler nicht in den Besitz der Kreditkarteninformationen gelangt und das Finanzinstitut des Kunden nicht in den Besitz der Bestellinformationen. Beide können aber prüfen, ob diese Informationen korrekt sind (Integrität) und von wem sie gesendet wurden (Authentisierung). Der Ablauf ist wie folgt:
  1. Der Kunde errechnet je einen Hashwert für die Bestellung und die Kreditkarteninformationen. Beide Hashwerte werden miteinander verbunden und darüber ein weiterer Hashwert errechnet.
  2. Dieser Hashwert wird vom Kunden mit seinem privaten Schlüssel signiert (duale Signatur).
  3. Der Benutzer sendet die duale Signatur, den Hashwert der Kreditkarteninformationen und die verschlüsselten Bestellinformationen (HybridVerfahren) an den Händler.
  4. Der Händler entschlüsselt die Bestellinformation, errechnet darüber einen Hashwert, verbindet diesen Wert mit dem Hashwert der Kreditkarteninformationen und errechnet über das Ergebnis einen Hash. Diesen Wert vergleicht er mit dem vom Kunden zugeschickten signierten Wert. Stimmen beide Werte überein, ist der Kunde authentisiert und die Integrität der Informationen sichergestellt.
Analog dazu erfolgt die Transaktion des Kunden mit seiner Finanzinstitution, wobei die Bank die ver-schlüs-selten Kreditkarteninformationen erhält die duale Signatur und den Hashwert der Bestellung. Der wesentliche Vorteil ist, daß dieses Verfahren auch vor nicht vertrauenswürdigen Händlern schützt denn Kreditkarteninformationen gelangen niemals in die Hände eines Händlers. Ein Nachteil des SET-Verfahrens ist der relativ große Aufwand. Der Kunde muß sich zunächst eine mehrere MB umfassende Software aus dem Netz laden (Wallet-Software), bevor er seine Buchungen absichern kann. Auch auf Banken und Händler kommt ein hoher Aufwand an Supportleistungen zu. Mit dem SET-Verfahren zur Sicherung von Kreditkartenzahlungen im Internet konkurrieren deshalb derzeit auch andere Verschlüsselungssysteme, insbesondere auf der Basis von SSL.

HBCI

Im August 1995 veröffentlichte der Zentrale Kreditausschuss (ZKA) das "Homebanking Computer Interface" (HBCI), das als standardisierte Schnittstelle zwischen Kunde und Bank, die bis dato gewachsenen, inkompatiblen Homebankingsysteme ablösen und vereinheitlichen sollte. Bis heute wurde die HBCI-Spezifikation mehrfach überarbeitet (aktuell: Version 2.2) und scheint sich zunehmend als europäischer Standard für "Homebanking" durchzusetzen. Im Hinblick auf zukünftige Erweiterungen stellte man zahlreiche Anforderungen an den neuen HBCI-Standard.

Die genannten Anforderungen wurden inzwischen alle in die HBCI-Spezifikation aufgenommen und führten zu einer breiten Akzeptanz des neuen Standards bei den deutschen und europäischen Kreditinstituten. Trotz der nach wie vor weiten Verbreitung von proprietären Homebanking-Systemen, vor allem in Form von "Java-Banking-Applets" im Internet, scheinen immer mehr Banken zumindest prinzipiell auf den neuen HBCI-Standard zu setzen. Homebanking auf Basis des HBCI-Standards gilt als sehr sicher, da eine Vielzahl von Sicherungsverfahren eingesetzt werden:

In der Praxis unterstützen Programme wie Quicken oder StarMoney den neuen HBCI-Standard und ermöglichen so den sicheren und einfachen Zugang. Voraussetzung neben einer geeigneten Homebanking-Software ist natürlich, dass die Hausbank HBCI-Banking anbietet und ein geeigneter Chipkartenleser für die HBCI-Chipkarten vorhanden ist. Derzeit existiert zwar noch ein zweites Verfahren auf Basis von RSA-Disketten, dieses wird aber sicherlich in naher Zukunft durch das weitaus sichere Chipkarten-System abgelöst werden. Die HBCI-Chipkarten enthalten die, für die HBCI-Kommunikation notwendigen, geheimen Schlüssel zur Signierung und Chiff-rierung der ausgetauschten Daten und wickeln alle sicherheitsrelevanten Prozesse (Hashwert-bildung, Signierung, Verschlüsselung, etc.) ab. Vorteil der Chipkarten: die geheimen Schlüssel verlassen nie die Karte, sie sind einfach zu handhaben und machen unter anderem die umständ-lichen TAN-Listen überflüssig. Damit das hohe Sicherheitsniveau bei der Nutzung von HBCI-Chipkarten auch gewahrt bleibt, sollte man vor allem bei dem benötigten Chipkartenleser nicht sparen. Derzeit gibt es drei Klassen von Chipkartenterminals, die sich hauptsächlich in ihren Sicherheitsmerkmalen unterscheiden. Die einfachen Chipkartenleser werden der "Klasse 1" zugeordnet und eignen sich nur eingeschränkt für sicherheitsrelevante Anwendungen, da sie von eingeschleuster Software (Trojaner) durchaus manipuliert werden können. Besser geeignet sind daher Chipkartenterminals der "Klasse 2", die nicht nur die sichere PIN-Eingabe mittels einer eigenen Tastatur ermöglichen, sondern auf einem kleinen LC-Display auch alle Transaktionen/Vorgänge zur Kontrolle und Bestä tigung anzeigen. Das höchste Sicherheitsniveau bieten jedoch Chipkartenterminals der "Klasse 3", wobei derzeit nur KOBIL solche Geräte liefern kann. Diese Chipkartenterminals verfügen über eine Zulassung des ZKA und ermöglichen zusätzlich die Verwaltung von Signa-turen, das sichere Bezahlen mit der Geldkarte im Internet, sowie das Aufladen der Geldkarte (geplant für HBCI v3.0). Die HBCI - Spezifikation und FAQ des ZKA findet man unter http://www.hbci.de.

3.7 Firewall-Rechner

Als Schutz vor Einbruchsversuchen in lokale Netze, die über einen Anschluß an öffentliche Netze verfügen (z. B. Internet, aber auch ISDN), haben sich Firewall-Rechner, kurz 'Firewalls' bewährt. Ähnlich der Zugbrücke einer Burg erlauben sie den Zugang nur an einer definierten Stelle. Damit läßt sich der Datenverkehr von und nach außen kontrollieren. Normalerweise sind zahlreiche Rechner des Unternehmens, die unter diversen Betriebssystemen laufen, direkt aus dem öffentlichen Netz erreichbar. Mehr darüber im nächten Kapitel.

3.8 Rechner geknackt, was nun?

Checkliste


3.9 Erkennung trojanischer Pferde bei Windows

Viren- oder Trojanerscanner verwenden

Zunächst sollten Sie sich einen Virenscanner kaufen oder aus dem Internet herunterladen. Sehr viele Hersteller bieten eine in den Funktionen uneingeschränkte Testversion zum ausprobieren an. Nachdem die Software installiert wurde, sollte unbedingt ein Update per Internet durchgeführt werden. Bevor Sie zum ersten mal Ihr System nach Viren und Trojanern durchsuchen lassen, sind noch ein paar wichtige Einstellungen an der Antivirensoftware zu tätigen. Das Programm ist dahingehend zu konfigurieren, daß beim Scan alle Dateien untersucht werden. Außerdem sollte das Programm in keinem Fall bei einer festgestellten Infektion sofort eine Säuberung oder Entfernung der infizierten Dateien vornehmen. Das ist sehr wichtig, da einige Trojaner den Virenscannern erhebliche Probleme bei der Entfernung bereiten bzw. diese sehr fehlerhaft entfernt werden. Das kann schnell zur Folge haben, daß ein System nicht mehr nutzbar und/oder unter Umständen kaum noch reparabel ist. Das Trojaner-Programm "SubSeven" in neueren Version bereitet hier z. B. sehr oft erhebliche Probleme. Sollte die AntiViren Software keine Infektionen feststellen, so heißt das jedoch noch lange nicht, daß ein System auch wirklich trojanerfrei ist.

Autorun-Einträge überprüfen

In der Regel macht ein Trojaner nur dann Sinn, wenn er sich auf dem System so installiert, daß er bei jedem Systemstart ausgeführt wird. Das bedeutet: Der Trojaner läuft ständig im Hintergrund des Systemes mit und wartet, bis der User eine Onlineverbindung aufbaut. DIe Start-Quellen bei Windows sind leider äußerst vielfältig:

Laufende Prozesse überprüfen

Häufig kommt man einem Trojaner schon auf die Schliche, indem man die laufenden Prozesse überprüft. Betätigen Sie die Tasten: AltGr + Strg + Entf. Nun erscheint eine Box, welche laufende Prozesse anzeigt, die man auch entsprechend beenden kann. Allerdings ist diese Methode überhaupt nicht sicher, da die meisten trojanischen Pferde es verstehen, sich vor diesem "Taskmanager" zu verstecken.

Windows liefert aber von Haus aus ein gutes Werkzeug zur Überprüfung aller laufenden Prozesse mit. Das Programm heißt "Dr. Watson" (Start -> Ausführen -> drwatson eingeben). Gehen Sie auf den Menüpunkt "Ansicht" und wählen Sie die Option "Erweiterte Ansicht". Für Anfänger ist Dr. Watson jedoch erwas schwierig, da das Programm wirklich alles anzeigt, was Windows so treibt.

Überprüfung der Ports mittels Netstat

Da wie weiter oben beschrieben, die meisten Trojaner im Hintergrund auf eine Onlineverbindung "warten", belegen diese einen TCP-Port. Die Ports kann man mittels des Programms "netstat" überprüfen. Rufen Sie die DOS-Eingabeaufforderung auf und geben Sie folgenden Befehl ein: netstat -a. Eine Online-Verbindung darf dabei nicht bestehen. Die Ausgabe könnte so aussehen:
Aktive Verbindungen

Proto Lokale Addresse   Remote-Addresse   Status
TCP   _:27374           0.0.0.0:45178    LISTENING
UDP   _:27374           *:*
Wie man sieht, wird der Port 27374 "belegt". Anhand der Portliste könnte man daraus schliessen, daß ein System mit dem Trojaner "SubSeven" neuerer Version infiziert ist. Zumindest ist es ein recht sicheres Anzeichen dafür.

Die Überprüfung mit einer einzigen der oben genannten Methoden ist nicht unbedingt aussagekräftig. Gehen Sie jedoch alle Methoden nacheinander durch, werden Sie dem Trojaner sicherlich auf die Schliche kommen können.

3.10 Vertrauen?

Eine verblÜffende Erkenntnis ist, daß trojanische Pferde, Viren, Trap-Doors etc. von jemanden mit Zugriff auf den Source-Cxxle praktigch unsichtbar gemacht werden können. Nehmen wir an, ein Systementwickler hat auf einem Rechner eine Spezialversion des Login-Programms erstellt, das bei der Eingabe von "tralala" sofort ohne Abfrage eines Paßwortes eine Super-User-Kennung bereitstellt. Damit kann er auf jedem Rechner auf dem dieses Programm installiert ist, sofort Super-User werden (Trap-Door). Allerding würde diese Abfrage nach "tralala" im Source-Code des Login-Programms stehen und kann leicht entdeckt und entfernt werden. Nach einer Neuübersetzung ist dieses 'Spezialfeature' wieder verschwunden.

Also geht er trickreicher vor und ändert den Compiler, so daß er beim Übersetzen des Login-Programms, die Abfrage nach "tralala" in das Login-Program einbaut. Damit hat er das Problem aber nur verschoben. Im Source-Code des Login-Programms ist nichts mehr zu sehen, dafür aber in der Source des C-Compilers.

Nun geht er einen Schritt weiter und ändert den C-Compiler so, daß er zusätzlich beim Übersetzen des C-Compilers die entsprechende Anderung in den C-Compiler einbaut. Er übersetzt den C-Compiler mit dieser Anderung. Damit hat er den C-Compiler trainiert, er kann die &aAuml;nderung im Source-Code des Compiles wieder rückgängig machen. Bei jeder Ü0bersetzung des Compilers wird die Änderung ja wieder eingebaut.

Damit ist die Modifikation des Login-Programms nirgends mehr in Source-Form zu sehen. Jede Spur dieser Sicherheitslücke ist verschwunden. Man kann das Betriebssystem komplett neu übersetzen und die Sicherheitslücke ist immer noch drin. In einem gewissen Sinn hat das System die Information über das "tralala"-Feature gelernt und sie braucht nicht mehr im Source-Code repräsentiert zu werden.

Dieses Verfahren funktioniert natürlich nicht nur mit dem C-Compiler sondern mit jedem Programm, das andere Programme transformiert: Compiler anderer Sprachen, Assembler, Skript-Interpreter, Linker, selbst Compiler für Microcode können betroffen sein. Selbst die genaue Durchsicht der Sourcen kann in manchen Fällen nicht verhindern, daß man Software benutzt, die seltsame Dinge tut.

Zum vorhergehenden Abschnitt Zum Inhaltsverzeichnis Zum nächsten Abschnitt


Copyright © FH München, FB 04, Prof. Jürgen Plate