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.

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. 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 Rechner gehört also auf jeden Fall unter Verschluß.

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

Installation von Alarmmechanismen

Datensammlung Beispiele:

Analyse bestehender Log-Dateien

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)

ssh und scp ersetzen also die Internetdienste telnet, rexec, rlogin, rsh, rcp und ftp. Bei diesen Diensten werden Daten und insbesondere Passwörter unverschlüsselt über die Netze geschickt, während mit ssh alles verschlüsselt übertragen wird. Zusätzlich verschlüsselt ssh X11-Verbindungen, setzt dabei automatisch die Display-Variable und gestattet, beliebige TCP/IP-Verbindungen zu tunneln.

Eigenschaften

Mit der SSH besteht Schutz vor

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.

Funktionsweise

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

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.

Für Interessierte gibt es eine ausführliche Anleitung zur ssh.

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

Zum Inhaltsverzeichnis        Zum nächsten Abschnitt


Copyright © Prof. Jürgen Plate, Fachhochschule München