Keine Passwörter ins Wohnheimnetz!

Inhalt

Das Problem

Alles, was ein Rechner ins Netz schickt, kann prinzipiell von allen anderen Rechnern im gleichen Netzsegment gelesen werden. Das ergibt sich aus der Funktionsweise von Ethernet. Im Fall der Wohnheimnetze umfaßt das Netzsegment alle Rechner im HaDiKo. Selbstverständlich ist das Abhören fremder Daten per Benutzerordnung verboten, technisch verhindern läßt es sich aber mit der derzeit eingesetzten Netztechnik nicht.

Daher muß man sich bei der Benutzung von Netzdiensten Gedanken machen, welche Gefahren die Abhörbarkeit mit sich bringt. Besonders kritisch in dieser Hinsicht sind jede Art von Passwörtern: wer sich in den Besitz eines gültigen Accountname/Passwort-Paars bringt, kann damit auf fremden Rechnern beliebigen Unfug treiben, für den sich der legitime Inhaber des Accounts dann am Ende noch verantworten muß. Ein normales Telnet, FTP mit Passwort und andere Standarddienste übertragen immer Passwörter im Klartext und stellen damit ein beträchtliches Risiko dar.

Es sollte deswegen ein vorrangiges Ziel sein, niemals Passwörter im Klartext über das Netz zu senden. Dieses Ziel läßt sich mit passender Software erreichen. Grundsätzlich sind folgende Möglichkeiten dafür denkbar:

  1. Verwendung von Einmalpasswörtern;
  2. Authentifizierung mit Challenge-Response-Verfahren;
  3. Verschlüsselung des gesamten Datenverkehrs.
Methode (1) ist sehr unbequem zu benutzen und benötigt spezielle Login-Programme etc. Sie wird hier nicht weiter betrachtet.
(2) und (3) hängen eng zusammen, da teilweise die gleichen Verfahren verwendet werden. Verschlüsselung des gesamten Traffics ist allgemeiner und schützt auch gegen Ausspähen der Nutzdaten.
Ein spezieller, in letzter Zeit bekannt gewordener Angriff erlaubt es unter bestimmten Bedingungen, eine bestehende Verbindung (z.B. Telnet-Login) auf einen anderen Rechner umzuleiten. Diese Bedingungen sind im Wohnheimnetz erfüllbar. Dagegen schützt nur Methode (3).

Das Softwaresystem ssh (Secure Shell) implementiert die Methoden (2) und (3). Seine Verwendung ist auf allen Rechnern, wo die Software verfügbar ist (momentan Unix, OS/2, Amiga, Macintosh und Windows), dringend angeraten. Auf den Unix-Rechnern von Uni-Rechenzentrum und IRA ist ssh normalerweise standardmäßig installiert.

ssh bietet hinreichend allgemeine Möglichkeiten, um die meisten Netzdienste über verschlüsselte Kanäle ablaufen zu lasssen. Bei richtiger Konfiguration und konsequenter Anwendung ist es möglich, einen Rechner am Netz so zu betreiben, daß kein unverschlüsseltes Paket mehr den Rechner verläßt. (Abgesehen von nicht sicherheitsbedenklichen Daten wie Nameserveranfragen, etc.)

Beschreibung von ssh

ssh ist als "plug-in-compatible" zu den Standard-Unix-Programmen rsh und rlogin konzipiert. Mit diesen kann man sich auf anderen Rechnern einloggen oder direkt Programme starten. Dabei muß man kein Passwort eingeben, wenn auf dem Zielrechner konfiguriert ist, von welchen IP-Adressen Verbindungen angenommen werden. Das ist sehr bequem, aber IP-Adressen sind generell fälschbar und damit zur Authentifizierung nicht geeignet.

Daher bietet ssh eine Reihe von Sicherheitsmechanismen, mit denen diesem Problem abgeholfen wird. Neben der Verschlüsselung des gesamten Datenstroms mit Stromchiffren werden Hosts und User mit dem RSA-Verfahren durch public keys abgesichert.

Grundlegendes

(Hier muß noch was geschrieben werden...)

Authentifizierungsverfahren

ssh bietet mehrere Möglichkeiten, wie sich der Benutzer dem Server gegenüber authentifiziert. Relevant sind insbesondere die Methoden "PasswordAuthentication" und "RSAAuthentication".

Passwort

Dieses Verfahren wird dann verwendet, wenn eine Authentifizierung mit anderen Methoden nicht klappt. Dabei fragt der ssh-Client das Userpasswort in konventioneller Weise ab, schickt es aber verschlüsselt zum Server. Der Server wiederum behandelt das Passwort in der gewohnten Weise. Damit ist das Verfahren genauso zu handhaben wie telnet, aber sicherer - kein Abhören möglich.

RSA

Wirklich interessant ist die RSA-Authentifizierung. Dabei wird der RSA-Public-Key-Algorithmus verwendet: der Benutzer besitzt einen geheimen Schlüssel und der Host, auf dem er sich einloggen will (Zielhost) den dazugehörigen öffentlichen Schlüssel. Wie bei der Verifikation einer PGP-Signatur kann der Server feststellen, ob der geheime Schlüssel stimmt, ohne daß direkt brauchbare Klartextdaten übertragen werden. Es ist möglich, mit einem geheimen Schlüssel Zugriff auf mehreren Accounts zu erlauben, indem man den öffentlichen Schlüssel kopiert. Das macht das Verfahren sehr bequem in der Handhabung - ein Passwort muß weder gemerkt noch eingegeben oder regelmäßig geändert werden, es sei denn der geheime Schlüssel ist selber passwortgesichert.

Die Handhabung erfolgt so: zuerst erzeugt man sich mit dem Programm ssh-keygen ein Schlüsselpaar. Das wird (auf Unix-Systemen) normalerweise in den Dateien ~/.ssh/identity und ~/.ssh/identity.pub gespeichert. Letzteres ist der öffentliche Schlüssel. Er hat die Form einer Textdatei, die aus einer langen Zeile besteht.

Auf jedem Zielhost kopiert man jetzt die identity.pub-Datei in ~/.ssh/authorized_keys. Ein Schlüssel muß genau eine Zeile sein, ggf. automatischen Zeilenumbruch im Editor deaktivieren. Der geheime Schlüssel darf natürlich nicht kopiert werden! Ein öffentlicher Schlüssel in authorized_keys bedeutet: Erlaube dem Inhaber des zugehörigen geheimen Schlüssels Zugriff auf diesen Account. Die Erlaubnis wird widerrufen, indem man die Zeile mit dem öffentlichen Schlüssel löscht.

Mit ssh-keygen kann der geheime Schlüssel zusätzlich passwortgeschützt werden. Dann muß man die hier definierte "Passphrase" bei jedem Zugriff auf den geheimen Schlüssel eingeben. Das ist wiederum unbequemer, aber schützt davor, daß der geheime Schlüssel in falsche Hände gerät.

Wenn ein geheimer Schlüssel unberechtigt kopiert wurde oder auch nur der Verdacht besteht, ist es - anders als bei PGP - ohne Umstände möglich, einen neuen anzulegen. Man muß nur darauf achten, daß man den alten öffentlichen Schlüssel aus allen authorized_keys-Files entfernt.

Filetransfer

ssh bietet das Kommando "scp" als plug-in-compatible zu rcp an. Damit lassen sich Files einfacher als mit FTP zwischen zwei Rechnern kopieren, wobei automatisch ssh verwendet wird. Anwendung wie in diesen Beispielen: 
scp -p *.html rzstud1:.public_html
scp s_newuser@studsun1.ira.uka.de:perl-examples.ps ./misc
Weitere Erläuterungen sind in der Manpage.

TCP-Portumlenkung

Gleichzeitig mit der Login-Funktion arbeitet ssh auch als TCP-Proxy. Beim Aufruf des ssh-Befehls kann man beliebig angeben, daß TCP-Verbindungen auf bestimmten Ports der einen Seite auf Verbindungen auf der anderen Seite umgelenkt werden sollen. Dabei kommt zwischen beiden wiederum ein verschlüsselter Kanal zum Einsatz.

Eine solche Umlenkung wird mit den Kommandozeilenoptionen -L bzw. -R im ssh-Aufruf aktiviert. Dann passiert folgendes:

-Lport1:host:port2
Verbindungen auf den Port port1 des Clients werden vom Server auf den Port port2 des Hosts host vorgenommen
-Rport1:host:port2
Verbindungen auf den Port port1 des Servers werden vom Client auf den Port port2 des Hosts host vorgenommen
Ein Beispiel: mit erreicht man folgendes: bei jedem Verbindungsaufbau auf Port 9876 des Client-Rechners wird rzstud1 eine Verbindung auf Port 25 (SMTP) des Mailhosts aufbauen und mit dem Client-Rechner koppeln. Das bedeutet, wer auf Port 9876 des Clients connected, bekommt eine SMTP-Verbindung zum Mailhost, die zwischen dem Client und rzstud1 verschlüsselt abläuft (zwischen rzstud1 und Mailhost dann unverschlüsselt). Dabei sieht der Mailhost allerdings nur rzstud1 als seinen Client. Weitere Anwendungsbeispiele finden sich unten.

X11 über ssh

Ein Sonderfall ist in ssh fest eingebaut, der die Bedienung sehr bequem macht: wenn man ssh aus einer X11-Session aufruft (DISPLAY ist gesetzt), dann wird eine Umlenkung für X11 aktiviert und gleichzeitig auf dem Zielhost DISPLAY und xauth passend gesetzt. Damit ist ohne weiteres Zutun der Aufruf von X11-Programmen sofort möglich, und das richtige Display wird benutzt.

Es ist zu empfehlen, X11-Verbindungen nur über ssh laufen zu lassen und niemals DISPLAY unbesehen umzusetzen, da das X11-Protokoll sehr unsicher ist. Niemals sollte man mit xhost Zugriff auf ein Display erlauben. X-Displays sollten immer so konfiguriert werden, daß sie mindestens "Magic Cookie"-Autorisierung verwenden. Das gilt auch außerhalb der Wohnheimnetze.

Konfiguration

Un*x-Client

In der Datei /etc/ssh_config finden sich Parameter für ssh. Das meiste, was standardmäßig eingestellt ist, funktioniert so. Man kann allerdings etwas optimieren. Ich verwende folgende Einstellungen: 
# Site-wide defaults for various options

Host *
 ForwardAgent no
 ForwardX11 yes
 RhostsAuthentication no
 RhostsRSAAuthentication no
 RSAAuthentication yes
 PasswordAuthentication yes
 FallBackToRsh no
 UseRsh no
 IdentityFile ~/.ssh/identity
 Port 22
 Cipher blowfish
 EscapeChar none
 KeepAlive no
Damit wird einiges, was ich nicht brauche, z.B. die rhosts-Authentikation, oder was ich unter keinen Umständen haben will (FallBackToRsh) gar nicht erst versucht. Als Verschlüsselung sollte man "blowfish" wählen, das ist am schnellsten. "arcfour" ist in neueren ssh-Versionen wegen eines potentiell die Sicherheit gefährdenden Fehlers deaktiviert.

Vor(!) dieser Defaulteinstellung können hostspezifische Optionen stehen, z.B. abgekürzte Hostnamen, Usernamen...: 

Host rzstud1
 HostName rzstud1.rz.uni-karlsruhe.de
 IdentityFile ~olaf/.ssh/identity
 User uknf
(wer das mit meinem Usernamen übernimmt, bekommt eins an die Löffel ;-)).

Ansonsten lese man sich die Manpage zu ssh durch, da ist eigentlich alles Notwendige zu finden.

Un*x-Server

Wer die Möglichkeit haben will, sich von außen (von anderen Rechnern im Netz oder auch aus der Uni) auf seinem eigenen Rechner einzuloggen, sollte den sshd aus einem der zahlreichen Initialisierungs-Skripts starten. Ich empfehle, ihn direkt nach dem inetd einzutragen, da paßt er systematisch hin.

Analog zum Client gibt es auch für den ssh-Server eine Konfigurationsdatei /etc/sshd_config. Die sieht bei mir so aus: 

# This is ssh server systemwide configuration file.

Port 22
ListenAddress 0.0.0.0
HostKey /etc/ssh_host_key
ServerKeyBits 768
LoginGraceTime 600
KeyRegenerationInterval 7200
PermitRootLogin yes
QuietMode no
FascistLogging no
PrintMotd yes
SyslogFacility AUTH
RhostsAuthentication no
RhostsRSAAuthentication yes
RSAAuthentication yes
PasswordAuthentication yes
Wichtig: RhostsAuthentication unbedingt auf "no" stellen. Außerdem im /etc/inetd.conf den telnetd, rlogind, rshd und rexecd (und auch den ftpd, es sei denn, man betreibt einen Anonymous-FTP-Server) auskommentieren. Diese nehmen Passwörter im Klartext über das Netz an.

Weitere Informationen gibt es auch im SSH-FAQ.

Andere Systeme

Anleitungen für andere Systeme finden sich auf den Seiten der HaDiNet-Benutzerbetreuung.

Verwendung von normalen Netzdiensten mit ssh

Sämtliche Netzdienste, die eine Benutzeridentifikation mit Passwort benötigen, sollten nur über eine ssh-Verbindung benutzt werden. Das ist gar nicht schwer, sobald man es verstanden hat.

POP

(Bitte diesen Abschnitt auch lesen, wenn man selber kein POP verwendet, da die grundlegende Technik der Portumlenkung an diesem Beispiel erläutert wird.)

Mail mit POP zu verarbeiten, ist bequem und daher recht beliebt (und in den Standard-Mailprogrammen mancher Systeme eingebaut), stellt aber ein erhebliches Sicherheitsproblem dar. POP verlangt die Angabe des eigenen Account-Passwortes, das im Klartext übertragen wird (abgesehen davon, daß die Mail selber ebenfalls im Klartext durchs Netz geht). POP arbeitet auf einer einzelnen TCP-Verbindung zu einem bekannten Port und ist dadurch sehr einfach mit ssh zu sichern, so daß dieses Problem nicht mehr auftritt. Mit folgendem Befehl:

wird eine Portumlenkung auf dem lokalen Rechner aktiviert. Der Parameter -La:b:c sagt dem ssh-Client, daß jede Verbindung auf den Port a der lokalen Maschine auf den Port c der Maschine b weitergeleitet werden soll. Im Beispiel bedeutet das also, daß der lokale Port 110 auf Port 110 (POP3) auf der Maschine poprzstud umgeleitet wird. Diese Weiterleitung benutzt einen verschlüsselten Kanal.

Da man jetzt den lokalen POP-Port so belegt hat, daß Zugriffe darauf auf den POP-Port der rzstud1 weitergeleitet werden, kann und sollte man localhost als POP-Server konfigurieren. Dann muß man allerdings immer den oben genannten ssh-Befehl laufen haben, während man seine Mail liest - wenn er beendet wird, wird auch die Portumlenkung beendet.

Das gleiche Verfahren funktioniert mit allen Diensten, die auf einer einzigen TCP-Verbindung zu einer bekannten Portnummer basieren, also allen, die prinzipiell auch mit "telnet host port" angesprochen werden können. Beispiele für diese Dienste sind SMTP, aber auch telnet (als Notnagel für Maschinen, die noch keinen sshd haben).

Da die Umlenkung über einen Uni-Rechner läuft, kann es sich dabei auch um Maschinen außerhalb der Uni handeln. Mehr zu diesem Thema weiter unten.

Nicht-anonymes FTP

FTP paßt leider nicht in das im letzten Absatz beschriebene Schema, da für einen FTP-Transfer mehrere Verbindungen auf vorher nicht bekannten Nummern geöffnet werden müssen. Anonymes FTP enthält genau wie normale WWW-Zugriffe per se erst einmal keine kritischen Daten; relevant wird das aber bei Zugriffen mit Passwort, wie beim Transfer von Daten zwischen lokalem Rechner und Uni-Account.

Hierzu ist die beste Methode, ganz auf FTP zu verzichten und scp aus dem ssh-Paket zu benutzen, wo immer möglich. Eine allgemeine Lösung für FTP gibt es leider nicht. Als Notnagel könnte man SOCKS über ssh benutzen (s.u.), dann aber auch innerhalb der Uni! Ein HTTP-Proxy sollte für diesen Zweck ebenfalls nicht verwendet werden: das Passwort ist Bestandteil der URL und wird mit dem Request im Klartext übertragen, außerdem kann es vom Proxy mitgeloggt werden.

Sonstige

Mail verschickt wird mit SMTP (Port 25). Jede Mail, die wirklich niemand mitlesen soll, sollte eigentlich mit PGP verschlüsselt werden. Zumindest innerhalb des Wohnheimnetzes läßt sich aber das Mitlesen auf dem Netz mit einer ssh-Umlenkung des SMTP-Ports auf den Uni-Mailserver (nicht den HaDiKo-Mailserver!) verhindern.

Manche per HTTP zu erreichenden Dienste brauchen die Eingabe eines Passworts oder sonstiger geheimer Daten. Dafür sollte man den betreffenden Host auf einen beliebigen lokalen Port umlenken und in der URL localhost:port statt des Original-Hosts verwenden:

An diesem Beispiel wird die Funktionsweise der Portumlenkung besonders deutlich, wenn man sie sich als Abbildung vorstellt: 
  http://                     www.foo.com : 80  /path/doc.html
                              |||||||||||   ||
  ssh             -L   8765 : www.foo.com : 80
                  ||   ||||
  http://  localhost : 8765                     /path/doc.html

Man sollte beachten, daß die Benutzung eines HTTP-Proxys für solche Dienste grundsätzlich nicht zu empfehlen ist, da der Proxy prinzipiell die Passwörter loggen kann.

Für https sind diese Verrenkungen nicht erforderlich, das Protokoll verschlüsselt selber. Man sollte darauf achten, keine älteren "Export"-Browser mehr zu verwenden, die nur 40-Bit-Schlüssel verwenden können.

Welche Dienste man sonst noch benutzt, bei denen Passwörter verwendet werden, sollte man selber wissen...

Anmerkungen

Selbstverständlich erlaubt ssh die Angabe von mehreren Portumlenkungen als -Lport:host:port-Argumente auf einer Kommandozeile. Das können ruhig viele sein, der zusätzliche Speicherbedarf fällt nicht ins Gewicht. Am einfachsten schreibt man sich den Aufruf in ein kleines Shellscript. Alternativ definiert man dafür im /etc/ssh_config eine Pseudosite und schreibt die zusätzlichen Argumente dort rein: 
Host relayer
 HostName rzstud1.rz.uni-karlsruhe.de
 IdentityFile ~foo/.ssh/identity
 User ufoo
 LocalForward 110 poprzstud.rz.uni-karlsruhe.de:110
 # und weitere LocalForwards. Syntax beachten: nur ein Doppelpunkt
Dann reicht ein "ssh relayer" als Aufruf.

Wenn auf der lokalen Seite Ports im "reservierten" Bereich (unterhalb von 1024) umgelenkt werden, muß man den ssh-Client als root aufrufen. Für jeden Port kann immer nur ein ssh-Prozess mit der Umlenkung aktiv sein, weitere ssh-Clients können aber ohne die -L-Parameter gestartet werden.

Bei neueren Versionen von ssh sind die lokal umgelenkten Ports nur von localhost aus erreichbar. Dies verhindert, daß andere Rechner im Netz die Umlenkung benutzen und damit ihre Identität hinter dem Inhaber der Umlenkung verstecken (und eventuellen Unfug ihm anlasten). Daher muß man z.B. als POP-Server localhost und nicht den eigentlichen Rechnernamen angeben. Wer mehrere Rechner hat und von allen diesen aus die Umlenkung nutzen will, muß ssh mit dem Parameter -g starten und unbedingt mittels entsprechender Firewall-Regeln dafür sorgen, daß die umgelenkten Ports aus dem restlichen Netz nicht erreichbar sind.

SOCKS und ssh

Funktion von SOCKS

SOCKS ist ein Protokoll, mit dem sich die Beschränkung auf das Uninetz überwinden läßt. Es benötigt zwar angepaßte Software, die ist aber leicht zu bekommen. Je nach Betriebssystem braucht man nur eine SOCKS-Library zu installieren oder maximal die Netzwerkprogramme unter Verwendung dieser Library neu zu compilieren, Änderungen am Programm sind in der Regel nicht erforderlich. Manche Programme haben SOCKS-Unterstützung auch gleich eingebaut. Es gibt zwei Versionen von SOCKS, 4 und 5. Vom RZ wird nur Version 5 unterstützt; es existiert ein SOCKS-Server auf rzstud1.

SOCKS funktioniert so: jeder Versuch, eine Netzwerkverbindung (außerhalb des uni-internen Bereichs) zu öffnen, wird nicht vom Betriebssystem direkt ausgeführt, sondern die SOCKS-Library öffnet zuerst eine Verbindung (Kontrollverbindung) zum SOCKS-Server und authentifiziert sich bei diesem. Dann schickt die Library den Verbindungswunsch an den SOCKS-Server, der den Verbindungsaufbau vornimmt. Anschließend kann die Kontrollverbindung als Datenverbindung benutzt werden.

Es handelt sich also um einen TCP-Proxy ähnlich der Portumlenkung von ssh. Allerdings ist SOCKS allgemeiner: es erlaubt auch passive Verbindungen und Verbindungen auf nicht von vornherein bekannte Ports. Damit sind auch Protokolle wie FTP möglich. SOCKS 5 erlaubt mit Einschränkungen auch das Weiterleiten von UDP-Paketen.

SOCKS verlangt nach einer Benutzeridentifikation mit Username und Passwort, die im Klartext über die Kontrollverbindung gehen. Daher ist von der direkten Verwendung von SOCKS im Wohnheimnetz dringend abzuraten.

SOCKS über ssh

Wie oben am Beispiel POP geschildert, läßt sich eine SOCKS-Verbindung aber ohne weiteres über eine ssh-Portumlenkung betreiben: die Kontrollverbindung geht auf einen festen Host (rzstud1) und Port (1080). Nach dem Aufruf einer Portumlenkung wie mit kann wiederum localhost als SOCKS-Server fungieren.

libsocks-Konfiguration

Un*x

Verwendet man unter Un*x die NWSL-libsocks von NEC (die gleiche Software, mit der der RZ-SOCKS-Server betrieben wird), dann wird diese in einer Datei /etc/libsocks5.conf konfiguriert. Dafür sind folgende Einträge zu empfehlen: 
# type  prot    dest-addr       dest-port       userlist        proxy
socks5  -       -               21              -               127.0.0.1
noproxy -       129.13.         -               -               -
socks5  -       -               -               -               127.0.0.1
Die Bedeutung dieser drei Zeilen (die erste ist Kommentar): lasse alles ins Uninetz bis auf FTP direkt, außerhalb und für FTP (wegen der Passwörter) nimm localhost (127.0.0.1) als SOCKS-Server. Achtung: ein FTP innerhalb des Wohnheimnetzes ist auch mit dieser Konfiguration unsicher: die Verbindung geht zwar verschlüsselt zum RZ, von dort aus aber unverschlüsselt wieder ins Wohnheimnetz.

Außerdem müssen für SOCKS-Programme folgende Environment-Variablen gesetzt werden:

SOCKS5_USER
Username auf dem SOCKS-Server (also rzstud1)
SOCKS5_PASSWD
dazu passendes Passwort
SOCKS5_UDPBIND
Flag, daß UDP benutzt werden soll (siehe unten)
SOCKS5_LOG_SYSLOG
wenn gesetzt, logge Messages auf Syslog
SOCKS5_LOG_STDERR
wenn gesetzt, logge auf stderr - das sollte man unbedingt setzen, dann werden Fehlermeldungen verständlicher
SOCKS5_DEBUG
Debuglevel, nur bei Problemen auf Zahl größer 0 setzen

Sonstige

Mit SOCKS-Libraries und -Anwendungen auf anderen Betriebssystemen kenne ich mich leider nicht aus, nur so viel: wenn man keinen Usernamen/Passwort angeben kann, handelt es sich um SOCKS4 und funktioniert hier (mangels sinnvoller Authentikationsmöglichkeit) nicht.

Einschränkungen

Ein mitunter lästiges Problem tritt bei dieser Methode allerdings auf: Wenn die ssh-Umlenkung aktiv ist, funktioniert UDP über SOCKS nicht. Das liegt am SOCKS-Protokoll. Eine Lösung dafür in Gestalt eines alternativen SOCKS-Servers ist verfügbar, siehe die Infoseite dazu.

Anhang

Referenzen

Bezugsquellen

Siehe ftp://ftp.hadiko.de/pub/systems/.

Fehler etc. bitte an mich mailen.

Olaf Titz
2001-04-04