![[Photo of the Author]](../../common/images/Georges-Tarbouriech.jpg)
original in en Georges Tarbouriech
en to de Katja Socher
Georges ist ein langjähriger Unixbenutzer (kommerzielles
und freies). Er interessiert sich sehr für Sicherheit und
dankt der freien Softwaregemeinde für die großartige
Arbeit, die sie auf diesem Gebiet geleistet hat.
SSH, die Sicherheitsshell ist
ein sehr gutes kommerzielles Produkt. Es gibt jedoch verschiedene
großartige freie Implementationen von ssh Clients oder
Servern, die für Unix (kommerziel oder frei) oder für
verschiedene andere Betriebssysteme verfügbar sind.
Die bekannteste ist OpenSSH, verfügbar unter http://www.openssh.org. Auf dieser
Webseite kann man Alternativen für Unixsysteme, Windos, Mac...
finden. Für einige Produkte wie Windos gibt es nur freie
Clients.
In diesem Artikel präsentieren wir ein paar Beispiele, wie man
ssh zum Tunneln von Daten von/zu externen Applikationen benutzen
kann. VPN (Virtual Private Network) basiert auf ssh. Ein VPN ist
jedoch viel komplexer als, was wir hier vorstellen. Eine weitere ,
sehr weit entwickelte Lösung, ist, VTun .
Laßt uns diesen Tunnel hier einfach als einen Weg zum
Verschlüsseln von Daten in einem heterogenen Netzwerk
betrachten, um es davor zu bewahren, ausgeschnüffelt zu
werden. Natürlich ist dies sowohl auf, lokale als auch auf
remote Netzwerke anwendbar. Erinnere dich jedoch, ssh
verschlüsselt Daten nur, es macht dein Netzwerk nicht von
selbst sicher...
Du wurdest gewarnt!
SSH ist ein Ersatz für telnet oder rsh, rlogin, wie schon
in einem früheren Artikel erwähnt. Auch
wenn kürzlich einige Sicherheitsprobleme in ssh gefunden
wurden, bleibt es ein gutes Sicherheitswerkzeug für
Datenverschlüsselung. Wo wir schon dabei sind, das oben
erwähnte Sicherheitsproblem betraf Paßwörter: es
wird stärkstens empfohlen, stattdessen Paßsätze zu
benutzen und natürlich RSA Schlüssel! Das Benutzen von
ssh hindert dich nicht daran, viele andere Sicherheitswerkzeuge zu
benutzen, wie z.B. tcpwrapper.
Es ist ganz einfach, mit Standardwerkzeugen wie tcpdump oder snoop
Daten auszuschnüffeln, die durch ein Netzwerk zirkulieren. Du
kannst das auf einem Netzwerk testen, auf dem zwei Maschinen Daten
austauschen und z.B. telnet benutzen. Von einer dritten Maschine,
auf der z.B. Linux läuft, laß tcpdump laufen (als root,
natürlich) und schau, was passiert. Du kannst alle Daten
lesen! (Anmerkung des Editors: Um das zu testen müssen die
drei Rechner über einen Hub verbunden sein. Es funktioniert
nicht bei einem Switch. Der Punkt des Authors ist aber trotzdem
gültig.)
Natürlich ist die Ausgabe zu schnell, um am Bildschirm gelesen
zu werden, aber nichts hält dich davon ab, die Ausgabe in eine
Datei umzuleiten und sie dann lesen zu können, während du
Kaffee trinkst. Wenn das für Daten wahr ist, ist es auch
für das Paßwort wahr: das bedeutet, die Tür steht
für die Cracker weit offen. Du gibst ihnen den Schlüssel,
um in dein Haus zu kommen.
Stell dir einfach mal vor, die zirkulierenden Daten sind
vertraulich... Wenn du der Sysadmin bist, fürchte ich, wird
dein Boss dich bitten, dir einen anderen Job zu suchen.
Die remote Befehle, rsh, rcp, rlogin sind ebenfalls sehr
gefährlich, da die Daten auch nicht verschlüsselt sind.
ssh/slogin ist ein guter Ersatz für rsh/rlogin und mit scp hat
man einen guten Ersatz für rcp. Das bedeutet, du brauchst
keine weiteren remote Befehl oder telnet, wenn du ssh benutzt,
zumindest solltest du sie nicht benutzen.
Wie man ssh installiert, wie man geheime und öffentliche
Schlüssel generiert... ist nicht innerhalb der Reichweite
dieses Artikels. Du wirst alles, was du brauchst, innerhalb des ssh
Archives, das du herunterlädst, finden oder lies z.B. die zu
dem Thema verfügbare Dokumentation vom Linux Documentation Project.
Da einen Computer zu benutzen heutzutage fast immer Transferieren
von Daten auf die eine oder andere Art bedeutet, sollte ssh Pflicht
sein... nun, es liegt an dir. ssh kann jedoch viel mehr sein, als
nur telnet oder die remote Befehle zu ersetzen.
Es kann benutzt werden, um Daten, die zwischen externen
Applikationen und natürlich zwischen verschiedenen
Betriebssystemen übertragen werden, zu verschlüsseln. Es
kann diese Daten auch komprimieren. Es wird oft mit Protokollen wie
pop, ftp, http... benutzt, entweder für die Kompression oder
die Verschlüsselung. Dies ist sehr nützlich, wenn du
Systemadministrator bist, z.B. um dich von zu Hause zu deinem
Arbeitplatz zu verbinden oder umgekehrt.
Da es eine Client/Server Applikation ist, braucht ssh
natürlich beide: du brauchst eine Maschine, die einen ssh
Server laufen hat und eine Maschine, die einen ssh client laufen
hat (ich hoffe, du hast bemerkt, wie klug ich bin!) Warum
erwähne ich auf dieser offensichtlichen Tatsache? Weil, da wir
über freie Software sprechen, abgesehen von Unix, viele
Betriebssysteme keine freien Server haben. Das heißt,
manchmal wirst du nicht in der Lage sein, das Offensichtliche zu
tun, du mußt das Problem umdrehen: der Schlüssel
heißt forwarding. Mehr dazu später. Das bedeutet,
Benutzen von Betriebssystemen wie Mac OS oder Windos, z.B.,
impliziert, daß du keinen freien Server hast. Du mußt
dann mit einem Client-Programm auskommen. Laßt uns ein paar
wirkliche Beispiele anschauen.
Wenn du VNC nicht kennst, verpaßt du eines der
großartigsten Werkzeuge, die es jemals gab. Du kannst es dir
dort anschauen, um mehr
darüber zu lernen.
Wenn du auf die VNC Webseite auf http://www.uk.research.att.com/vnc/docs.html
gehst, wirst du eine Menge an Dokumentation finden, die das
betrifft, worüber wir hier reden. Z.B. findet man, wie man VNC
durch ssh benutzt, von einem Windos ssh client zu einem Unix ssh
server. Deshalb werde ich Frank Stajanos großartige Arbeit
nicht noch einmal schreiben, da es viel besser ist als das, was ich
tun könnte.
Deshalb, laßt uns untersuchen wie es funktioniert:
Zuerst mußt du einen freien Windosclient wählen.
Für dieses Beispiel benutzen wir Teraterm Pro mit seinen Ttssh
Erweiterungen. Du kannst es unter http://hp.vector.co.jp/authors/VA002416/teraterm.html
finden. Es wird Ttssf genannt, da es eine in Frankreich erlaubte
Version ist (die Dinge ändern sich, aber sei dir bewußt,
daß viele Länder Verschlüsselung noch nicht
erlauben. Checke diese URL, um zu sehen, wie die
Verschlüsselungssituation in deinem eigenen Land ist : http://www2.epic.org/reports/crypto2000/countries.html.)
Jetzt laßt uns sagen, du hast einen ssh Server auf einer
Unixmaschine gestartet. Auf derselben Maschine, nehmen wir an,
kannst du einen vncserver laufen lassen. Laufen einmal beide
Server, verbindest du z.B. eine NT Maschine zu diesem Unixserver
unter Benutzung von Ttssh. Das bedeutet, du hast jetzt eine
verschlüsselte Verbindung zwischen den beiden Maschinen. Aber
dies erlaubt es dir nicht, ein verschlüsseltes vncviewer
protocol (vncclient) von dieser NT Maschine laufen zu lassen. Um
das zu machen, mußt du ssh anweisen, den richtigen Port zu
forwarden (da sind wir wieder!).
Die Unixmaschine, die den vncserver laufen hat, wird "bandit"
genannt und benutzt den Port 5901, weil es die Displaynummer 1 hat,
der default X display für diese Maschine ist 0. Der normale
Gebrauch würde sein, einen Befehl "vncviewer bandit:1" zu
schicken. Dies funktioniert natürlich, aber ohne, daß
die Daten verschlüsselt werden. Stattdessen, bei Benutzen der
NT "shell" (d.h, die DOS Schnittstelle...) , sende den Befehl
"/ssh-L5902:bandit:5901" ohne Leerzeichen. Das bedeutet, du
erzeugst einen lokalen Port 5902. Jetzt läßt ein Befehl
wie "vncviewer localhost:2" eine verschlüsselte Verbindung des
VNC protocols auf deiner NT Maschine laufen. Dies kann ohne
Benutzen der Kommandozeile gemacht werden, weil Ttssh eine
grafische Schnittstelle hat. Diese Syntax ist Ttssh spezifisch.
Unter Unix wäre das "ssh -L 5902:bandit:5901 bandit".
Dies ist natürlich ein einfaches Beispiel: man kann viel
komplexere Sachen machen. Ließ die auf der VNC Webseite
verfügbare Dokumentation, besonders die von Frank Stajano.
MySQL ist wahrscheinlich
eines der am meisten benutzen DBMS, besonders im Internet.
Wiederum, Sichern von MySQL ist außerhalb der Reichweite
dieses Artikels. Jedoch macht das Verschlüsseln der Daten, die
zwischen einem MySQLserver und einem MySQLclient zirkulieren, die
Verbindung sicherer. SSH erlaubt es, dies zu tun, genauso wie es
das mit VNC tat, d.h. port forwarding.
Nehmen wir ein Beispiel aus dem Intranet. Der MySQL server ist eine
Linuxkiste und die meisten der Clients sind NT Maschinen. Wiederum
benutzen wir den Ttssh client auf den Windosmaschinen.
Die defaut MySQL portnummer ist 3306. Dann forwarden wir denselben
port (3306).
Man kann entweder ein lokales oder ein remote forward machen.
Ein lokales forward würde so "/ssh-L3306:localhost:3306" auf
der NT Maschine aussehen oder so "ssh -L 3306:localhost:3306" auf
einer Unixmaschine. Benutzen von "localhost" erlaubt das Senden der
Daten durch das loopback interface anstelle des host interface.
Ein remote forward würde "/ssh-R3306:bandit:3306" für NT
und "ssh -R 3306:bandit:3306" für Unix sein.
Dies betrifft nur die Verbindung selbst. Um sich in den DBM
einzuloggen, mußt du natürlich deinen hostnamen und
deinen Benutzernamen für den MySQL server, der wahrscheinlich
von deinem login Benutzernamen für deine Maschine verschieden
ist, setzen. Mehr dazu findest du in den ssh man pages unter der
option "-l".
Natürlich funktioniert das nur, wenn du einen MySQLclient auf
deiner NT Maschine hast.
Wenn nicht, mußt du eine ODBC Applikation benutzen, z.B.
Sybase. Das bedeutet, du mußt diese Applikation starten.
Benutze deinen ODBC Treiber, um ihn zu MySQL zu linken. Du kannst
dich jetzt mit dem localhost, nicht zum MySQLserver host,
verbinden, um Zugang zum MySQL server zu haben. Die zwischen dem
Server und dem Client zirkulierenden Daten sind jetzt
verschlüsselt. Du kannst es mit snoop oder tcpdump
überprüfen.
Dies ist Besipiel für ein lokales Netzwerk. Wenn du soetwas
auf einem WAN machen möchtest, wird es ein bißchen
komplexer, z.B., wenn du hinter einer Firewall bist. Dies kann ein
Weg sein, um etwas remote Administration von zu Hause aus zu
machen, wenn du der Sysadmin bist, aber du kannst nicht erwarten,
diese Methode benutzen zu können, um auf einem DBM von einer
Webseite aus zuzugreifen. Du mußt dann eine etwas komplexere
Lösung wählen z.B. VPN.
Nun gut, glaube nicht, daß dies genug ist, um einen sicheren
DBMserver aufzusetzen, der vertrauliche Daten wie
Kreditkartennummern überträgt! Und, wo wir schon dabei
sind, wer glaubt wirklich jemandem, der sagt, er hat einen sehr
sicheren Server, der in der Lage ist, diese Art von Daten ohne
irgendein Risiko zu übertragen? Persönlich tue ich das
nicht!!!
Was bedeutet das, wo wir doch schon Terminalemulation
benutzen?
Laßt uns sagen, du hast eine alte Cobolapplikation auf einem
Unixserver laufen. Die Clients sind wieder NT Maschinen. Um sich an
die Cobol application anzbinden, brauchen sie eine höher
entwickelte Terminalemulation als vt100, vt220 oder vt320, weil sie
eine saubere Benutzerschnittstelle bekommen müssen. Das
bedeutet Umlaute, Tabellen... Eine Standard- (vt100, vt220...)
Terminalemulation einfach auf 8bit setzen, wird nicht ordentlich
funktikonieren. Was man bekommt, ist einfach nicht zu gebrauchen.
Da es ein eher altes Produkt ist, brauchst du eine entsprechend
"alte" terminalemulationsspezifische Software.
Nach einem langen Kampf, um die richtige Emulation zu bekommen,
findest du z.B., daß "ibm3151" das beste Ergebnis liefert.
Soweit, so gut!
Aber, da die Software, die du benutzt, vor vielen Jahren entwicklet
wurde, weiß sie nichts über Sicherheit. Die Verbindung
benutzt telnet ! Jedoch sind die transferierten Daten sehr
vertraulich... So, was jetzt? Du mußt zumindestens einen Weg
finden, die Daten zu verschlüsseln. Und wiederum wird ssh
helfen.
Wiederum, Da Gibt Es Mehr Als Nur Einen Weg, Das Zu Machen ...
Entweder leitet man telnet zu port 22 (ssh) um oder man forwarded
den Port der Terminalemulation. Aber... ich fürchte, der
Server wird es nicht akzeptieren, daß ein normaler Benutzer
den telnet port (default ist 23) umleitet: du mußt root sein,
um solche Dinge machen zu können (zumindest hoffe ich das!).
Was die Terminalapplikation angeht, so kann sie von verschiedenen
Benutzern auf einmal benutzt werden, auf diese Weise werden
verschiedene Ports für jede Verbindung benutzt, z.B. 10
Benutzer=10 ports.
Das wird ein bißchen trickreich, nicht wahr?
So, zuallererst muß auf dem Applikationsserver auch ein ssh
Server laufen und auf port 22 zuhören.
Von einem NT client verbindet man ihn zum Applikationsserver
entweder durch Benutzen von Ttssh oder durch die "Kommandozeile".
Das bedeutet, du baust eine sichere Verbindung zwischen dem Server
und dem Client als ein spezieller Benutzer auf. Von Ttssh
forwardest du den lokalen port 50000 zu port 23 (telnet) auf dem
remote server. Von der Kommandozeile sollte es so aussehen
"ssh-L50000:servername:23". Jetzt kannst du deiner
Terminalemulation erzählen, durch port 50000 statt durch port
23 zu laufen. Die Daten zirkulieren nun durch einen sicheren Kanal,
das meint, verschlüsselt. Du kannst es mit snoop oder tcpdump
überprüfen.
Natürlich solltest du dasselbe für jeden Client machen,
dem es erlaubt ist, sich mit der Apllikation zu verbinden, durch
Ändern der geforwardeten Portnummer. Zum Beispiel
könntest du 50001, 50002, usw. benutzen.
Jetzt könntest du fragen: warum solche hohen Ports? Die
Antwort ist: aus vielen Gründen !
Ernsthaft, der Hauptgrund ist, daß du hohe Ports
"manipulieren" kannst, ohne root zu sein.
Der zweite Grund ist, daß der gewählte Port nicht schon
auf beiden Maschinen benutzt werden darf. Beispiel: wenn der Server
Solaris laufen hat, werden viele Ports schon benutzt, entsprechend
der laufenden Dienste. Deshalb sollte port 50000 und darüber
funktionieren. Das bedeutet, du solltest die in Benutzung
befindlichen Ports überprüfen, bevor du forwardest.
Natürlich gilt dies auch für viele andere
Betriebssysteme, die in der Lage sind, ssh clients zu benutzen.
Was den Weg betrifft, um den Prozeß auf den Clientmaschinen
zu automatisieren, liegt es an dir. Du kannst nicht einen
"normalen" Benutzer bitten, all dies vor dem Verbinden zu tun,
nicht wahr? Dann lassen wir das als eine Übung für die
Leser...
Diese paar Beispiele zeigen die zahlreichen
Nutzungsmöglichkeiten von ssh. Du kannst mit vielen
Applikationen und ssh sehr viel mehr machen. Es hängt von
deinen Bedürfnissen ab. Die "Philosophie" ist jedoch fast
immer gleich: port forwarding.
Trotzdem sei vorsichtig, wenn du komplexeres forwarding benutzt.
Zum Beispiel, wenn du durch eine dritte Maschine forwardest, werden
die Daten, die in der mittleren Verbindung zirkulieren, nicht
verschlüsselt.
Ein weiterer Nachteil betrifft Windos clients, die Ttssh benutzen.
Die Verbindung zu den forwarding ports beruht auf IP Adressen wie
bei den remote Befehlen. Damit sind spoofing Attacken
(Vortäuschen falscher IP-Adressen) möglich. Daher die
Notwendigkeit, andere Werkzeuge außer ssh zu benutzen, wie
tcpwrappers.
Durchforsche die "Literatur" über ssh, sie wird dich eine
Menge lehren. Deine Vorstellungskraft macht dann den Rest.
Sicherheit sollte ein Anliegen von jedem sein, aber das ist es
nicht! ssh ist nur eines der Sicherheitswerkzeuge, die du jeden Tag
benutzen kannst. Es ist ein ganz gutes, sobald du in Betracht
ziehst, wofür es gemacht ist, daß es ein
Verchlüsselungs- oder Kompressionswerkzeug ist.
Allein ist ssh fast nutzlos, da es zahlreiche "Lücken" nicht
schließt, die du in einer Maschine oder einem Netzwerk haben
kannst. Sichern eines hosts, eines Netzwerkes ist eine große
Aufgabe und Werkzeuge sind nicht alles, auch wenn sie ganz gut
sind.
Die grundlegenden Aufgaben sind wichtig, wenn es um Sicherheit
geht. Vergiß nicht, alle ungenutzten Dienste zu entfernen,
überprüfe die SUID root Programme, deaktiviere
"risikoreiche" Programme"... Es gibt eine Menge zu tun und es wird
nie genug sein. Du kannst alle verfügbaren
Sicherheitswerkzeuge installiert haben, aber sie sind nutzlos, wenn
du eine oder mehrere Hintertüren weit offen läßt.
Natürlich ist das eine andere Geschichte, aber vergiß
das Offensichtliche nicht.
Zurück zu ssh, laßt uns sagen, es ist das Werkzeug, ohne
das du nicht leben kannst, sobald du es ordentlich benutzt und
dafür einsetzt, wofür es gemacht wurde. Noch einmal,
benutzte es mit Paßsätzen, RSA Schlüsseln, nicht
mit Paßwörtern. Überprüfe die Rechte der
verschiedenen Dateien im .ssh Verzeichnis und natürlich die
Rechte des Verzeichnisses selbst. Und noch und nochmals, benutze
zumindest tcpwrapper!
Du kannst durch ssh die meisten existierenden Protokolle tunneln.
Dies kann sehr nützlich sein, um Verbindungen ein
bißchen sicherer zu machen.
Es gibt einen weiteren häufigen Gebrauch, über den wir
nicht gesprochen haben, X session forwarding. Da dies impliziert,
daß wir X auf verschiedenen Betriebssystemen laufen haben,
haben wir es absichtlich ausgelassen. Aber es ist im Bereich des
Protokoltunnelns. Da X nicht so sicher ist, kann ssh die Dinge
besser machen.
Für komplexere Aufgaben ist ssh nicht ausreichend. Wie vorher
gesagt, prüfe VPNs oder Werkzeuge wie VTun, sie helfen
wahrscheinlich.
Und schließlich überprüfe die Situation der
Verschlüsselung für dein eigenes Land. Es wäre
traurig, als Spion ins Gefängnis zu gehen, nur weil man
Software wie ssh benutzt hat.
Es ist wie es ist...
Trotzdem, wir leben in einer großartigen Zeit!