3 Gefahrenabwehr

3.1 Passwort-Sicherheit

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:

• keine Login-Namen
• keine anderen Namen
• keine Wörter oder Abkürzungen, die im Wörterbuch zu finden sind
• keine persönlichen Informationen (Geburtstag, Telefonnummer usw.)
• keine Variante der oben genannten schlechten Passwörter (z.B. rückwärts oder Großbuchstaben usw.)
• nicht nur Ziffern nutzen

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 ?ereinstimmung kommt, ist das Passwort geknackt. Gute Passwort-Knacker gehen aber noch weiter, indem sie Regeln verwenden, z. B.:

• jedes Wort auch rückwärts testen
• Groß- und Kleinschreibung kombinieren
• Wörter zusammenhängen (z. B. Wort vorwärts + Wort rückwärts)
• Einfügen von Zahlen am Anfang, Ende oder im Wort

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:

• Wortliste: Es wird versucht, das Passwort anhand einer Wortliste und optionaler Regeln zu entschlüsseln. Solche Regeln können Buchstabendreher, Kombinationen aus Groß- und Kleinschreibung, zusammen gesetzte Wörter usw. beinhalten. Die maximal zulässige Passwortlänge kann angegeben werden.
• Einfacher Modus: John überprüft das Passwort gegen das Nutzerkennzeichen, Informationen des GECOS-Feldes und "verbreitete" Passwörter (aus der Datei /var/lib/john/password.lst)
• Inkrementeller Modus: Alle erdenklichen Zeichenkombinationen werden getestet. Die Passwortlänge kann wiederum beschränkt werden. Mit dieser Methode kann jedes Passwort entschlüsselt werden - vorausgesetzt, man bringt die nötige Geduld mit;
• Externer Modus: Hierbei handelt es sich um eine Schnittstelle, die den Einsatz anderer Crackmethoden ermöglicht.

3.2 Rechnersicherheit

Das Wichtigste ist jedoch die Prävention:

• "Securing your system by breaking into it"
• Regelmäßig Informationen einholen
• Patches und Security-Fixes einspielen

3.3 Abschottung von öffentlichen Datenbereichen

3.4 Überwachung von Protokolldateien und Benutzern

• Logdateien sind das wichtigste Hilfsmittel zum Erkennen von Angriffen.
• Tatsächlichen Angriffen geht meist eine Analyse des Rechners durch den Hacker voraus (z.B.: Portscan).
• Günstigster Zeitraum für das Lesen der Logdateien: Montag morgen, da die meisten Hacks am Wochenende passieren.

• Uhrzeit: Ein falsches Login um 10:30 deutet weniger auf einen Hack-Versuch hin als desgleichen um 0:30.
• "refused connect"-Meldungen, insbesondere wenn sie von einem Benutzer root oder von entfernten Rechnern kommen. Beispiel:

  Aug  1 18:36:21 lx-lbs wu.ftpd[13430]:  
  

• Spezielle Meldungen von Portscanner-Logs, wie z.B.:

  Oct 12 17:27:07 lx-lbs scanlogd: From 141.39.253.200:20 to 141.39.253.196 
  ports 1476, 1477, 1478, 1479, 1480, 1481, 1482, 1483, 1484, ..., flags ??r??u, 
  TOS 00, TTL 255, started at 17:27:02 
  

• Typisch für eine Dial-of-Service-Attacke sind folgende Meldungen:

  Oct  3 00:20:30 lx-lbs inetd[119]: fork: Resource temporarily unavailable
  Oct  3 00:20:37 lx-lbs last message repeated 7 times       
  

  (kein Speicher mehr wegen zu vieler offener Prozesse)

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

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 ?erlastsicherungen 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

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  

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

• Alles ist erlaubt, bestimmte Dinge sind verboten.
• Alles ist verboten, bestimmte Dinge sind erlaubt.

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

• Anmeldung als Superuser sollte nur von der Systemkonsole aus zulässig sein
• unnötige Software aus dem System entfernen
• Software regelmäßig warten und updaten
• sichere(re) Software und Serverprogramme verwenden
• Zugriffsrechte aus Systemdateien prüfen und ggfs. Zugriffsrechte so weit wie möglich beschränken
• unsichere Software sperren (Sniffer etc.)
• SUID-Programme prüfen, ob das SUID- oder SGID-Bit gesetzt sein muß

Systemsicherheit überprüfen

• Wo ist was konfiguriert? (/etc/inetd.conf)
• Wo ist was protokolliert? (/var/log/messages)
• Welche unterstützenden Systemkommandos gibt es? (ps, last)
• Wie sind die Informationen zu finden und zu filtern? (find, grep)

Installation von Alarmmechanismen

• Erzeugung zusätzlicher LOG-Dateien
• Erkennung von Hacks durch Suche nach bestimmten Einträgen in LOG-Dateien
• Oft automatisches Benachrichtigen des Administrators

• Watcher: Protokoll-Tool, Plattform Unix.
• Win-Log: Einfaches Rechnerüberwachungstool für Windows-NT. Hält unter anderem alle Login- und Logout-Vorgänge fest.

  

• scanlogd: Bestandteil vieler Linux-Distributionen. Hält Portscans in der messages-Datei fest.
• Courtney: Checkt den Rechner auf Satan-Scans. Plattform: Unix

Analyse bestehender Log-Dateien

• Logsurfer: Checkt die messages-Datei von Unix-Rechnern auf bestimmte Einträge und führt daraufhin bestimmte Aktionen durch.
• Logcheck: Einfaches Unix-Programm zum Überwachen der Logdateien.

Allgemeine Sicherhungsmaßnahmen

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 ?erschreiben 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

SSL

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:

• Das SSL Application Data Protocol wickelt die Datenübermittlung zwischen Anwendung und SSL ab.
• Das SSL Alert Protocol dient der Weiterleitung von Warn- und Fehlermeldungen.
• Das SSL Change Cipher Spec Protocol übernimmt die Initialisierung der festgelegten kryptographischen Verfahren.
• ?er das SSL Handshake Protocol handeln Server und Client das zu verwendende kryptographische Verfahren aus.
• Das SSL Record Protocol nimmt die Ver- bzw. Entschlüsselung sowie, falls verlangt, eine Komprimierung der Nutzdaten vor.

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. ?er 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

P₀ = f^N(s)

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

P₁ = f^N-1(s)

Die generelle Erzeugunsvorschrift lautet damit:

P_i = f^N-i(s)

bzw.

P_i = f(P_i+1)

Erlangt ein Unberufener Kenntnis von einem OTP P_i, kann er trotzdem nicht das nächste zu verwendende Paßwort P_i+1 ermitteln, da sich die Umkehrung f'(p_i) der sicheren Hash-Funktion nicht berechnen läßt. Der entfernte Host erhält zunächst das OTP P₀. 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 p_i+1. Der Host führt folgende Berechnung durch:

P_i = f(f^N-i-1l(s)) = f(P_i+1)

Stimmt der berechnete Wert nut dem gespeicherten überein, so ist der Nutzer authentifiziert. Daraufhin überschreibt der Host das alte OTP p_i mit dem soeben erhaltenen P_i+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)

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):

• Nachdem der Client eine erfolgreiche TCP/IP-Verbindung zum Server aufgebaut hat, tauschen beide Seiten ihre installierte Protokollversion aus. Falls die Versionen inkompatibel sind, wird die Kommunikation sofort abgebrochen.
• Andernfalls schalten Server und Client auf ein paketbasiertes Binär-Protokoll um.

  

• Anschließend sendet der Server seine beiden öffentlichen RSA-Schlüssel e_H und e_S (Host- und Server-Key) sowie eine Auflistung der von ihm unterstützten symmetrischen Chiffren zum Klienten. Der Client verifiziert e_H mit Hilfe einer lokalen Datenbasis (bzw. "lernt" diesen Key, falls der Nutzer es zuläßt).
• Wurde e_H akzeptiert, generiert der Client einen zufälligen Sitzungsschlüssel, chiffriert diesen mittels der beiden RSA-Keys e_H und e_S. Dann sendet er das Resultat zusammen mit der Angabe des von ihn gewählten symmetrischen Verfahren an den Server.
• Ab diesem Zeitpunkt läuft die gesamte Kommunikation verschlüsselt ab. Der Client authentifiziert sich mit einem der unterstützen Verfahren (Username und Paßwort sind also schon verschlüsselt). Die Hostschlüssel dienen der Identifikation des Rechners und sind "langlebig", Serverschlüssel werden in regelmäßigen Abständen neu generiert (z. B. einmal pro Stunde).
• Nach erfolgreicher Authentifizierung wird für den Nutzer eine Arbeitsumgebung auf dem Server-Rechner hergestellt. Zusätzlich verschlüsselt ssh X11-Verbindungen, setzt dabei automatisch die Display-Variable und gestattet, beliebige TCP/IP-Verbindungen zu tunneln.

Eigenschaften von SSH im Überblick

• Gedacht als Ersatz für die Unix-R-Kommandos (rlogin, rsh, rcp), telnet
• Verschlüsselung der Verbindung
• Auch einsetzbar zur Sicherung von X-Window, telnet, ftp und POP durch Umleitung der Verbindung über einen gesicherten Kanal
• Automatische Umsetzung der Display-Variablen unter X
• Starke Host-Authentifizierung
• Unterstützte Plattformen:
  • nahezu alle Unix-Systeme
  • Windows 3.x, 95/98, NT
  • Macintosh

Mit der SSH besteht Schutz vor

• Abören von Passwörtern und Terminalverbindungen durch Sniffer
• DNS-Spoofing
• IP-Spoofing

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.

• ssh als Ersatz von telnet und rlogin:
  ssh [Userid@] Remote-Host
  Die Userid muß nur dann angegeben werden, wenn die Userids auf der Client-Workstation und dem Zielrechner unterschiedlich sind.
• ssh als Ersatz von rexec und rsh:
  ssh [Userid@] Remote-Host Befehl
  Wenn der Befehl Wildcards (?, * usw.) enthält, muß er in Hochkommata eingeschlossen werden, damit diese auch wirklich erst auf dem Zielrechner aufgelöst werden,
• scp als Ersatz von rcp und ftp:
  • Um eine Datei von der lokalen Workstation zu einem entfernten Zielrechner zu übertragen:
    scp Datei [Userid@] Remote-Host: [Datei | Directory]
  • Um eine Datei von einem entfernten Rechner auf die lokale Workstation zu kopieren:
    scp [Userid@] Remote-Host: Datei Datei | Directory
  Es ist möglich, durch die Angabe von Wildccards (z. B. *.txt) mit einem Befehl mehrere Dateien zu kopieren. In diesem Fall muß für das Zielsystem ein bereits existierendes Verzeichnis angegeben werden, in das die Dateien kopiert werden sollen. Die Angabe einer Zieldatei ist dann nicht möglich.
  Um ganze Verzeichnisse rekursiv zu kopieren, kann man die Option -r verwenden:
  scp -r Directory [Userid@] Remote-Host: [Directory]
  bzw. scp -r [Userid@] Remote-Host: Directory Directory
  

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

• Zugang mit Paßwort-Authentisierung
  Nach Absetzen eines der oben beschriebenen Befehle wird man nach dem Paßwort auf dem Zielrechner gefragt. Dieses wird verschlüsselt übertragen.
• Zugang mit RSA-Authentisierung
  ssh bietet zusätzlich die sogenannte RSA-Authentisierung. Diese Form der Validierung ist noch sicherer: Statt eines einzelnen Paßwortes kann ein ganzer Satz (Passphrase) als Zugangsvalidierung gewählt werden. Der private RSA-Schlüssel (Generierung s.u.) wird mit dieser Passphrase verschlüsselt, um ihn vor Mißbrauch zu schützen. D.h. selbst wenn der RSA-Schlüssel in unerlaubte Hände gerät, kann er nur dann genutzt werden, wenn auch die Passphrase bekannt ist. Wegen der erhöhten Sicherheit, wird empfohlen, möglichst diese Art der Validierung zu nutzen.

Andere Dienste über SSH tunneln

ssh ohne Passwort

Wo ist denn da der Vorteil, wenn man sich zwar ohne Passwort einloggen kann, aber f?en Private Key doch wieder eine Passphrase braucht? Nun, zum einen kann man sich sp?r mit diesem einen Schl?l auf viele verschiedene Rechner einloggen und mu?sich nicht deren evtl. verschiedene Pa??r merken. Zum anderen gibt es den SSH Agent, der in der Lage ist, sich die Passphrase f?ie 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?chkeit, eine leere Passphrase zu verwenden - dann aber ist der Private Key ungesch?! Jetzt mu?man auf anderem Wege sicherstellen, da?niemand an den Schl?l herankommt, d.h. z.B. die Datei-Zugriffsrechte d?n nur dem Eigent? 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

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
...

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

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
...

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

Key MEIN-SSH-PUBLICKEY.pub

IdKey MEIN-SSH-PUBLICKEY

ssh-dss
AAAAB3NzaC1kc3MAAACBAIygQj1gQp+XTk9oaZdkI8FJoABaWjwJjTVxiXUdau7pIddAht3rmcAgrQEN
z6Cy4he7Dbdu
...
rpnVxyEKaHSYRmGDbB78810kugDeF5+lZs881MN7UnA3crygPs2PEXmpJIK+GfiztqJvf0UjzhaPofLI
sQ1O9Q== USER@HOST

---- 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:

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

• Der öffentliche Schlüssel wurde nicht auf dem Zielrechner abgelegt.
• Das Heimatverzeichnis des Benutzers auf dem Zielrechner hat zu viele Rechte. In der Standardkonfiguration erwartet ssh, daß Schreibrechte nur für den Owner gesetzt sind. Sobald sie auch für andere gesetzt sind, schaltet ssh auf Validierung über Paßwort zurück.
• Die Verwaltung der Benutzerdaten auf dem Zielrechner läuft über DCE. In diesem Fall hat man keine Möglichkeit, die RSA-Authentisierung zu nutzen.

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)

• den Einsatz verschiedener Verschlüsselungsalgorithmen
• verschiedene Sicherheitsdienste (Zugangskontrolle, Beglaubigung, Integrität, Vertraulichkeit)
• Kontrolle, wie detailliert die Sicherheitsdienste angewandt werden.

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:

• Im Transport-Mode wird der Inhalt des Paketes (also das UDP- oder TCP-Paket) in den kryptografischen Rucksack gepackt und mit dem identischen IP-Header auf die Reise geschickt.
• Im Tunnel-Mode wird das ganze Paket mit originalem IP-Header verschlüsselt und mit einem Klartext-IP-Header versehen. Der Tunnel-Mode erhöht zwar den Overhead, sorgt aber dafür, daß IP-Adressen nicht gefälscht werden können, da diese auch verschlüsselt übertragen und so am Zielsystem geprüft werden können.

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

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).

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.

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.

HBCI

• Multibankfähigkeit: Jede Zahlungsverkehrsoftware mit HBCI-Kernel soll in der Lage sein, mit jedem Kreditinstitut bzw. HBCI-Server zu kommunizieren. Erreicht werden soll dies über ein einheitliches Protokoll, fest definierte Kommunikationsdialoge und -Ports.
• Transportdienstunabhängigkeit: Das HBCI-Protokoll kann und soll mit jedem Transportdienst zurechtkommen und somit dem Kunden eine freie Wahl des Zugangs (Providerwahl) ermöglichen.
• Endgeräteunabhängigkeit: Neben dem PC und Notebook sollen auch mobile Geräte wie Handy und PDA als mögliche HBCI-Kommunikationsplattformen berücksichtigt werden.
• Offenheit: Durch frei zugängliche Spezifikationen und Entwicklungstools (APIs) soll nicht nur Vertrauen geschaffen, sondern auch die einfache Entwicklung von HBCI-Anwendungen vorangetrieben werden.
• Sicherheit: Die Sicherheitsmechanismen zum Schutz der übertragenen Daten, sowie die Authentifizierung soll auf den derzeit anerkannten und als sicher geltenden Standards beruhen und gegebenenfalls erweiterbar sein.
• Flexibilität: Die HBCI-Spezifikation soll möglichst modular (objektorientiert) aufgebaut ein um eigene Geschäftsvorfälle hinzufügen und parametrisieren zu können und um die Eigenentwicklung von HBCI-Anwendungen zu vereinfachen.
• Präsentationsdienstunabhängigkeit: Der HBCI-Kernel soll nur Rohdatenströme zur Verfügung stellen und die Kunde-zu-Bank-Kommunikation abwickeln. Die Visualisierung und Interaktion mit dem Kunden soll alleine Aufgabe der Homebanking-Anwendung sein.
• Anwendungssystem-Unabhängigkeit: Es soll möglich sein, HBCI-Anwendungen sowohl über fest installierte Software, als auch über dynamisch geladene Software-Module (JavaApplets, ActiveX, etc.) zu realisieren.
• Plattformunabhängigkeit: Die HBCI-Spezifikation soll keine Einschränkungen bezüglich des verwendeten Betriebsystems machen und als Entwicklungsumgebung (HBCI-Kernel) möglichst auch für alle Plattformen verfügbar sein.
• Online & Offline-Arbeiten soll möglich sein, um ?ertragungskapazitäten effektiver zu nutzen und um dem Kunden mehr Komfort zu bieten.

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:

• Starke Verschlüsselung der übertragenen Daten auf Basis eines Triple-DES Algorithmus. Es handelt sich hierbei um ein symmetrisches Blockchiffre-Verfahren, dass einen geheimen 168-Bit-Schlüssel nutzt.
• Sichere Authentifizierung des Kunden und der Bank sowie der übertragenen Dokumente durch digitale Signaturen. Hierbei sind derzeit zwei Verfahren standardisiert:
  • RSA-Signaturen (asymmetrisches Verfahren)
  • MAC-Signaturen (symmetrisches Verfahren, basiert auf DES)
• Passwortschutz zur Authentifizierung auf Kundenseite
• Signaturzähler zur Erkennung und Vermeidung von Doppeleinreichungen

3.7 Firewall-Rechner

3.8 Rechner geknackt, was nun?

Checkliste

• Maschine vom Netz trennen!
• Administrator verständigen. Alle weiteren Schritte nur im Beisein eines Experten durchführen.
• Andere Administratoren warnen. (Mailingliste)
• System untersuchen. Wenn möglich von einer Diskette booten, da Systemprogramme modifiziert sein könen.
• "Snapshot" vom System anlegen. (evtl. Beweismittel)
• Vergleich der Systemprogramme mit den Originalen (z.B. auf der Installations-CD). Häufig ausgetauschte Dateien bei Unix-Systemen sind: telnet, in.telnetd, login, su, ftp, ls, ps, netstat, ifconfig, find, du, df, libc, sync, inetd und syslogd
• Untersuchen der Dateien /etc/passwd und der /etc/shadow bei Unix-Systemen. Bei anderen Plattformen untersuchen der User-Datenbank über entsprechende Programme: Möglicherweise wurden Benutzer hinzugefügt oder Benutzerrechte geändert.
• Untersuchung der Daten. Je nach Verwendungszweck des Rechners sollten kritische Daten untersucht werden, wie z.B. Verzeichnisse von FTP-Servern, HTML-Seiten bei Web-Servern, Programm-Verzeichnisse bei File-Servern. Achtung: Oft werden Programme in einem Verzeichnis namens "..." installiert, das man leicht übersieht.
• Sind zusätzliche Programme installiert worden? (Trojanische Pferde Sniffer, etc.)
• Alle Systemlogfiles überprüfen, z. B.: messages, xferlog, wtmp, utmp, warn
• Nach Beendigung der Untersuchung: Platte neu formatieren und System neu installieren (Nötig bei Austausch der System-Programme durch den Hacker!)
• Alle anderen betreuten Maschinen untersuchen

3.9 Erkennung trojanischer Pferde bei Windows

Viren- oder Trojanerscanner verwenden

Autorun-Einträge überprüfen

• Autostart-Ordner
  Diese Möglichkeit wird von Trojanern sehr selten genutzt. Grund: Die Entdeckungsgefahr ist zu hoch. Den Autostart-Ordner finden Sie z. B. wie folgt: Windows-Start -> Suchen -> Dateien/Ordner. Num "Autostart" eingeben, worauf der Ordner angezeigt wird.

• Datei WIN.INI
  Eine vor allem früher sehr häufig anzutreffende Methode ist die Eintragung in die Win.ini unter den Parametern "Load=" oder "Run=". Vorsicht! Manche Trojanische Pferde tragen sich nicht direkt hinter der Parameter-Bezeichnung ein, sondern nach zahlreichen Leerzeichen, damit dieses nicht sofort erkannt wird. Scrollen Sie also mit dem unteren Balken einfach mal nach rechts. Den besten Zugriff auf diese Datei (und SYSTEM.INI, Autoexec.bat, Config.sys) hat man über das Programm SYSEDIT. (Start -> Ausführen -> sysedit.exe eingeben).

• Datei SYSTEM.INI
  Eine Eintragung erfolgt unter dem Paramter "shell=". Vorsicht: Hier ist schon eine Eintragung Namens "Explorer.exe" enthalten, die nicht gelöscht werden darf. Es könnten jedoch noch weitere Eintragungen vorhanden sein.

• Datei Autoexec.bat
  Trojaner nutzen diese Möglichkeit so gut wie gar nicht. Da jedoch diese Möglichkeit ebenfalls gegeben ist, wird sie hier mit angeführt.

• Datei Config.sys
  Einige, wenige Trojaner tarnen sich auch als Gerätetreiber auf Windows-95/98/ME-Systemen. Diese Trojaner lassen sich jedoch schwer realisieren und sind daher zum Glück noch recht selten.

• Datei Winstart.bat
  Wenn hier eine Eintragung erkennbar ist, bedeutet dieses in der Regel folgendes: Eine Befehlzeile veranlasst das Kopieren einer Datei, welche vor dem letzten Systemstart gelöscht wurde. Bisher sind kaum Trojaner bekannt, die diesen Weg nutzen.

• Datei Wininit.ini
  Nicht zu verwechseln mit der Datei WIN.INI! Die Datei Wininit.ini muß sich im übrigen auch nicht auf jedem System befinden. Jedoch kann hier einmalig zwecks Autorun (also Ausführung einer Datei bzw. eines Trojaners) ein Eintrag erfolgen, welcher danach sogar gelöscht wird. Im übrigen heißt die Datei "Wininit.ini" im ausgeführten (geladenen) Windows-System dann "Winit.bak". Normalerweise wird diese Datei für das Fortsetzen von Installationsprogrammen nach einem Neustart verwendet. Sie wird aber auch mitunter von Virenscannern zur Entfernung von Trojanern oder Viren genutzt.

• Datei progman.ini
  Das ist die Stuerdatei des "Program-Managers" - ein Relikt aus Windows-3.1. Sie wird aber immer noch beim Start verarbeitet.

• Datei control.ini
  Auch hier ist es theoretisch möglich, einen Eintrag unterzubringen. Bisher ist jedoch noch kein Fall bekannt, wo sich eine Trojaner hier eingetragen hat.

• Windows-Registrierung
  Um hier zu forschen, muß der Registry-Editor aufgerufen werden (Start -> Ausführen -> regedit eingeben). Ein Programm mit scheinbar unendlichen Eintragungen/Ordnern öffnet sich. Hier interessieren nur einige, wenige Pfade:

  HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServices\
  HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce\
  HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run\
  HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce\
  
  HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\
  HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce\
  HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunServices\
  

• Die sogenannten Unknown-Methoden
  Auch hier wird die Windows-Registrierung für den Autostart genutzt. Unter diesen Pfaden sind folgende Einträge zu finden:

  HKEY_CLASSES_ROOT\exefile\shell\open\command\ @="%1" %*"
  HKEY_CLASSES_ROOT\comfile\shell\open\command\ @="\"%1\" %*"
  HKEY_CLASSES_ROOT\batfile\shell\open\command\ @="\"%1\" %*"
  HKEY_CLASSES_ROOT\htafile\Shell\Open\Command\ @="\"%1\" %*"
  HKEY_CLASSES_ROOT\piffile\shell\open\command\ @="\"%1\" %*"
  
  HKEY_LOCAL_MACHINE\Software\CLASSES\batfile\shell\open\command\ @="\"%1\" %*"
  HKEY_LOCAL_MACHINE\Software\CLASSES\comfile\shell\open\command\ @="\"%1\" %*"
  HKEY_LOCAL_MACHINE\Software\CLASSES\exefile\shell\open\command\ @="\"%1\" %*"
  HKEY_LOCAL_MACHINE\Software\CLASSES\htafile\Shell\Open\Command\ @="\"%1\" %*"
  HKEY_LOCAL_MACHINE\Software\CLASSES\piffile\shell\open\command\ @="\"%1\" %*"
  

  Vor der Zeichenkette "%1" %* könnte noch ein Programm eingetragen worden sein. Normalerweise ist jedoch nur die oben gezeigte Eintragung vorhanden. Sollte hier somit noch eine ausführbare Datei (exe, com etc.) enthalten sein, so könnte sich dahinter ein trojanisches Pferd verbergen. Bei Trojanerverdacht in keinem Fall den gesamten Eintrag entfernen, sondern nur das Programm!

• Tarnung als Gerätetreiber
  Ein Trojanisches Pferd kann sich auch als Gerätetreiber tarnen, was jedoch noch verhältnismässig selten der Fall ist. Auch erweist sich die genaue Identifizierung als nicht gerade einfach. Schließlich kann sich hinter einem Eintrag auch ein harmloser Gerätetreiber verbergen, dessen Löschung mehr Schaden als Nutzen bringt. Auch für Treiber erfolgt eine Eintragung in der Registrierung - jedoch unter einem "ungewohntem" Pfad:

  HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\INTLD
  

  Zur Identifizierung sollte jedoch zumindest ein Process-Viewer zur Hilfe genommen werden, der unter Umständen eine der im o. g. Pfad Eintragung als laufenden Prozess anzeigt. Windows liefert von Haus aus ein sehr brauchbares Programm namens "Dr. Watson" mit.

• über "Explorer.exe" auf Laufwerk C:\
  Aufgrund eines Bugs in Windows, wird immer zunächst die erste aufzufindende Datei "explorer.exe" ausgeführt (also in Verzeichnis C:\), bevor die eigentliche Datei "c:\windows\explorer.exe gestartet wird. Erstere bewirkt, daß ein Trojaner dieses Namens zunächst geladen werden kann, der dann seinerseits die "richtige" Datei startet.

• Ersetzen der Datei runonce.exe
  Die Original-Windows-Datei "runonce.exe" wird durch ein modifizierte Datei ersetzt, die damit einen Autostart ermöglicht.

Laufende Prozesse überprüfen

Windows liefert aber von Haus aus ein gutes Werkzeug zur ?erprü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

Aktive Verbindungen

Proto Lokale Addresse   Remote-Addresse   Status
TCP   _:27374           0.0.0.0:45178    LISTENING
UDP   _:27374           *:*

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?

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.

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