Home  |  Plan  |  Index  |  Suchen

Convert to GutenPalm or to PalmDoc von Georges Tarbouriech Über den Autor: 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. Inhalt: Warum ssh benutzen ? SSH und VNC SSH und MySQL SSH und Terminalemulation Wohin geht es von hieraus? Zumindest ist es vorbei! Talkback für diesen Artikel

Durch den Tunnel

Zusammenfassung:

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!

Warum ssh benutzen ?

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.

SSH und VNC

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.

SSH und MySQL

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

SSH und Terminalemulation

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

Wohin geht es von hieraus?

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.

Zumindest ist es vorbei!

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!

Talkback für diesen Artikel

2001-05-01, generated by lfparser version 2.13

mirror server hosted at Truenetwork, Russian Federation.