Make your own free website on Tripod.com


vorheriges KapitelInhaltsverzeichnisStichwortverzeichnisnächstes Kapitel


27

Telnet-basierte Angriffe

Dieses Kapitel beschäftigt sich mit den Angriffen, die sich über die Jahre auf Basis des Telnet-Dienstes entwickelt haben. Das Telnet-Protokoll wurde zum ersten Mal 1980 von Jan Postel umfassend definiert. Im RFC 764 schrieb Postel:

Der Zweck des Telnet-Protokolls ist die Bereitstellung einer recht allgemeinen, bidirektionalen, byte-orientierten Kommunikationsmöglichkeit. Sein Hauptziel ist es, eine Standardmethode zur Kommunikation zwischen Terminal-Geräten und Terminal-orientierten Prozessen zu ermöglichen. Es ist vorstellbar, daß das Protokoll auch für die Terminal-Terminal-Kommunikation (»Linking«) und die Prozeß-Prozeß-Kommunikation (verteilte Berechnungen) verwendet werden wird.

Wegweiser:

RFC 764 finden Sie im Web unter http://sunsite.auc.dk/RFC/rfc/
rfc764.html
.

27.1 Telnet

Wie bereits in Kapitel 4, »Ein kurzer Überblick über TCP/IP«, erwähnt, ist die Konzeption von Telnet einzigartig, wenn man von rlogin einmal absieht. Telnet soll einem Benutzer ermöglichen, sich an einem fremden Rechner einzuloggen und dort Befehle auszuführen. Telnet (wie auch rlogin) funktioniert so, als würden Sie persönlich vor der Konsole des entfernten Rechners sitzen.

Hinweis:

Benutzer von Microsoft-Betriebssystemen können ein Gefühl dafür bekommen, indem sie sich Programme wie PCAnywhere oder CloseUp ansehen. Mit diesen können Sie sich entfernt an einem anderen PC einloggen und am C:-Prompt des entfernten Rechners Befehle ausführen (oder sogar in Windows, wenn Sie eine ausreichend schnelle Verbindung haben, so daß die Grafiken übertragen werden können).

27.1.1 Virtuelles Terminal

Das Besondere an Telnet ist, daß es eine ASCII-Terminalverbindung zwischen zwei Rechnern simuliert, die weit voneinander entfernt sind. Das geschieht mit Hilfe eines virtuellen Terminals, wie Postel es in RFC 854 beschreibt:

Wenn eine Telnet-Verbindung hergestellt wird, wird von jedem Ende angenommen, daß es von einem »Network Virtual Terminal« (NVT) stammt oder dort endet. Ein NVT ist ein imaginäres Gerät, das eine standardisierte, netzwerkweite Zwischenrepräsentation eines kanonischen Terminals darstellt.... Das NVT ist ein bidirektionales, zeichenorientiertes Gerät. Es hat einen Drucker und eine Tastatur. Der Drucker reagiert auf ankommende Daten, und die Tastatur erzeugt ausgehende Daten, die über die Telnet-Verbindung gesendet werden und - wenn »Echos« gewünscht werden - auch an den Drucker des NVT. Es wird von »Echos« nicht erwartet, daß sie das Netzwerk durchqueren (obwohl es die Möglichkeit gibt, einen »entfernten« Echo- Modus zu aktivieren, ist es für keinen Host zwingend erforderlich, diese Option zu implementieren). Als Codesatz wird 7-Bit US-ASCII in einem 8-Bit-Feld verwendet, mit Ausnahme der hier beschriebenen Modifizierungen. Alle Code-Konvertierungen und Timing-Überlegungen sind lokale Probleme und betreffen den NVT nicht.

Wegweiser:

Lesen Sie das gesamte RFC 854 unter http://sunsite.auc.dk/RFC/rfc/
rfc854.html
.

Ein virtuelles Terminal ist das Äquivalent (zumindest vom Anschein her) einer Direktverbindung zweier Rechner per Kabel über die seriellen Schnittstellen. Sie können z.B. etwas einer Telnet-Sitzung sehr ähnliches simulieren, indem Sie die respawn-Anweisungen in der inittab-Datei auf einem Linux-Rechner (und den meisten anderen Unix-Rechnern) auskommentieren, oder indem Sie den Monitor und die Tastatur von einer SparcStation entfernen und ein VT200-Terminal an die serielle Schnittstelle A oder B anschließen. Im ersten Fall wird ein login:-Prompt ausgegeben. Im zweiten Fall werden alle Meldungen des Bootvorgangs an das verbundene Terminal als Echo übertragen, ein boot-Prompt wird ausgegeben (oder, wenn das richtige SCSI-Festplattenlaufwerk als Bootgerät im PROM angegeben ist, wird der Rechner booten und einen login:-Prompt ausgeben).

Deshalb gehören Telnet-basierte Verbindungen zu den sogenannten rudimentären Verbindungen. Telnet- und Terminal-Sitzungen sind vollkommen textbasiert. Außerdem haben Telnet-Verbindungen ohne die Zuhilfenahme eines textbasierten Browsers wie Lynx keine Möglichkeiten zur Interpretation von darstellungsorientierten Sprachen wie HTML. Deshalb erhalten Sie, wenn Sie per Telnet eine Webseite anfordern, keine Bilder oder nett formatierten Text, sondern nur den Quelltext des Dokuments (außer natürlich, wenn Sie Lynx verwenden).

Hinweis:

Lynx ist ein vollständig Terminal-basierter HTML-Browser zur Verwendung mit Shell-Account- oder sogar auf DOS basierenden TCP/IP-Verbindungen. Er bietet eine sehr schlichte Möglichkeit, auf das World Wide Web zuzugreifen.

27.1.2 Die Geschichte der Telnet-Sicherheit

Telnet ist bereits viele Male in Sicherheitsadvisories erwähnt worden. Die Sicherheitsprobleme von Telnet variieren stark, wobei ein Großteil der Probleme auf Programmierfehler zurückzuführen ist. Programmierfehler sind jedoch nicht der einzige Grund dafür, warum Telnet in Advisories aufgetaucht ist. Im August 1989 war das Problem zum Beispiel ein Trojanisches Pferd, wie es in diesem CERT-Advisory heißt:

Viele an das Internet angebundene Computer haben vor kurzem Probleme durch unautorisierte Systemaktivitäten bekommen. Untersuchungen haben gezeigt, daß diese Aktivitäten bereits seit einigen Monaten auftreten und sich weiter ausbreiten. Bei mehreren Unix-Rechnern wurden die Telnet-Programme von unberechtigten Personen durch Telnet-Programme ersetzt, die externe Login-Sitzungen protokollieren (einschließlich Benutzernamen und Paßwörtern entfernter Systeme). Es sieht so aus, als sei sich zu vielen der Rechner, die in diesen Sitzungsprotokollen auftauchen, Zugang verschafft worden.

Wegweiser:

Das vollständige CERT-Advisory finden Sie unter http://www.sw.com.sg/ Download/cert_advisories/CA-89:03.telnet.breakin.warning.

Diese Angriffe erfolgten kurz vor der Gründung des DDN Security Coordination Center (im September 1989), weshalb kaum dokumentiert ist, ob auch Rechner der US-Regierungsbehörden betroffen waren. Anders als die CERT-Advisories enthalten die DDN-Advisories oft eine technischere Analyse der Probleme.

Im März 1991 fand man heraus, daß der telnetd-Daemon bestimmter Sun-Distributionen fehlerhaft war. In einem CERT-Advisory steht:

Das Computer Emergency Response Team/Coordination Center (CERT/CC) hat Informationen von Sun Microsystems, Inc., hinsichtlich einer Schwachstelle erhalten, die die SunOS-in.telnetd-Versionen 4.1und 4.1.1 aller Sun-3- und Sun-4-Architekturen betrifft. Diese Sicherheitslücke betrifft außerdem die SunOS-4.0.3-Versionen sowohl von in.telnetd als auch in.rlogind auf allen Sun-3- und Sun-4-Architekturen. Soweit uns bekannt ist, existiert keine Sicherheitslücke bei den SunOS-4.1- und 4.1.1- Versionen von in.rlogind. Die Sicherheitslücke wurde von Sun Microsystems, Inc., behoben.

Wegweiser:

Das vollständige CERT-Advisory (»SunOS in.telnetd Vulnerability«) finden Sie unter ftp://info.cert.org/pub/cert_advisories/CA-91%3A02a.
SunOS.telnetd.vulnerability
.

Tip:

Wenn Sie eine alte Sun 3/60 kaufen, möchten Sie sich wahrscheinlich die Patches besorgen. Sie sind in dem oben genannten Advisory enthalten.

Monate später wurde entdeckt, daß eine spezielle LAT/Telnet-Anwendung von Digital Corporation ebenfalls einen Fehler hatte. In dem CERT-Advisory heißt es:

Es gibt eine Schwachstelle der Art, daß ULTRIX-Systeme 4.1 und 4.2, auf denen die LAT/Telnet-Gatewaysoftware läuft, unbefugten Zugriff ermöglichen können... Jeder, der Zugriff auf ein Terminal oder Modem erhalten kann, das mit dem LAT-Server verbunden ist, auf dem der LAT/Telnet-Dienst läuft, kann unautorisiert an Root-Privilegien gelangen.

Wegweiser:

Dieses CERT-Advisory (»ULTRIX LAT/Telnet Gateway Vulnerability«) finden Sie unter ftp://info.cert.org/pub/cert_advisories/CA-91%3A11.Ultrix.LAT-Telnet.gateway.vulnerability .

Das erste Telnet-Problem, das Auswirkungen auf den Durchschnittsbenutzer hatte, hing mit einer Distribution des NCSA-Telnet-Clients für PCs und Macintosh-Rechner zusammen. Damit es hier nicht zu Mißverständnissen kommt: Dies war eine Client-Telnet-Applikation, die über einen integrierten FTP-Server verfügte. Das Sicherheitsloch wurde hauptsächlich dadurch gefördert, daß die Benutzer nicht richtig verstanden hatten, wie diese Anwendung funktionierte. Die Leute bei DDN schrieben folgendes dazu:

Die Default-Konfiguration von NCSA Telnet für sowohl den Macintosh als auch PCs hat eine ernste Sicherheitslücke in ihrer Implementierung eines FTP-Servers... Jeder Internet-Nutzer kann sich über FTP mit einem PC oder Macintosh verbinden, auf dem die Default-Konfiguration von NCSA Telnet läuft, und unbefugt Lese- und Schreibberechtigungen für alle Dateien dieses Rechners erhalten, auch die Systemdateien.

Das Problem hing mit einer Konfigurationsdatei zusammen, in der man den integrierten FTP-Server aktivieren oder deaktivieren konnte. Die meisten Benutzer nahmen an, daß der Server nicht aktiviert sei, wenn keine Angabe zur Aktivierung vorhanden war. Das war jedoch ein Irrtum. Durch Weglassen dieser Zeile (genau wie durch Hinzufügen von ftp=yes) erlaubte man jeder unbefugten Person Lese- und Schreibzugriff auf die Dateien seiner Festplatte.

Dies wird hoffentlich dem Streit darüber ein Ende setzen, ob ein PC-Benutzer von der Außenwelt angegriffen werden kann. Im Usenet wurde schon tausendfach über diese Frage gestritten. Die NCSA-Telnet-Panne war nur eine von vielen Situationen, in denen ein PC- oder Mac-Benutzer aus dem Nichts heraus angegriffen werden kann. Unter bestimmten Umständen kann auch der durchschnittliche Anwender an seinem PC zu Hause zum Opfer eines Angriffs werden. Jemand könnte in der Lage sein, Ihre Dateien zu lesen, zu löschen und so weiter.

Das Interessante dabei ist, daß sogar heute noch jeder, der die NCSA-Telnet-Anwendung benutzt, einem gewissen Risiko ausgesetzt ist, auch wenn er nur sogenannten autorisierten Personen Zugriff auf den FTP-Server gewährt. Wenn der Cracker sich von dem Zielsystem einen gültigen Benutzernamen und das dazugehörige Paßwort besorgen kann (und der Crakker daraufhin ein autorisierter Benutzer ist), kann er an die Datei FTPPASS gelangen. Das ist eine Datei zur Authentifizierung, in der die Benutzernamen und Paßwörter der Benutzer abgelegt sind. Die verschlüsselten Paßwörter in dieser Datei sind leicht zu knacken.

Der Benutzername wird in dieser Datei nicht in verschlüsselter Form gespeichert (nur wenige Programme verschlüsseln Benutzernamen). Das Paßwort ist zwar verschlüsselt, aber das Verschlüsselungsschema ist sehr dürftig. Wenn das Paßwort z.B. aus weniger als sechs Zeichen besteht, kann man es innerhalb von wenigen Sekunden knacken. Das Knacken solcher Paßwörter ist sogar so trivial, daß man es mit einem 14 Zeilen langen BASIC-Programm erledigen kann.

Wegweiser:

Das BASIC-Programm zum Knacken von Paßwörtern finden Sie unter http://www.musa.it/gorgo/txt/NCSATelnetHack.txt.

Wenn Sie ein Mac- oder PC-Benutzer sind und momentan NCSA Telnet (mit dem FTP-Server) verwenden, sollten Sie den FTP-Zugriff jedem verweigern, dem Sie nicht vertrauen. Wenn Sie diese Warnung ignorieren, können Sie leicht Opfer eines Angriffs werden. Stellen Sie sich einmal die Situation vor, daß eine einzige Person in einem Netzwerk NCSA Telnet verwendet. Sogar wenn der Rest des Netzwerks eigentlich sicher ist, würde dies die Sicherheit des gesamten Netzwerks gefährden. Da diese Anwendung keine Protokollierung vornimmt, werden zudem bei einem Einbruch noch nicht einmal Spuren hinterlassen. Jedes Netzwerk, in dem diese Applikation läuft, kann angegriffen, lahmgelegt oder zerstört werden, und niemand wird in der Lage sein, den Eindringling zu identifizieren.

Das interessanteste Telnet-Sicherheitsloch, das je entdeckt wurde, war mit der Option der Weitergabe von Umgebungsvariablen verbunden. Das DDN-Bulletin dazu wurde am 20. November 1995 gepostet:

In einigen Versionen des Telnet-Daemons, die RFC 1408 oder 1572 (beide mit dem Titel »Telnet Environment Option«) unterstützen und auf Systemen laufen, die auch die gemeinsame Nutzung von Objekt-Bibliotheken (shared object libraries) unterstützen, existiert eine Sicherheitslücke... Lokale und entfernte Benutzer mit oder ohne lokale Accounts können sich auf dem Zielsystem Root-Zugang verschaffen.

Viele Sites sind von dieser Sicherheitslücke betroffen. Um das Problem verstehen zu können, müssen Sie den Begriff Umgebung richtig verstehen. Im Unix-Jargon bezieht sich dieser Begriff im allgemeinen auf die Umgebung der Shell (d.h. welche Shell Sie standardmäßig benutzen, welche Terminal-Emulation Sie verwenden und so weiter).

Hinweis:

DOS/Windows-Benutzer können dies vielleicht am besten verstehen, wenn sie über einige der Angaben in den Dateien AUTOEXEC.BAT und CONFIG.SYS nachdenken. Die Variablen werden dort mit Hilfe des SET-Befehls gesetzt, wie in SET PATH=C:\;C:\WINDOWS; (die PATH-Umgebungsvariable ist eine von mehreren, die in der DOS-Umgebung spezifiziert werden können). Diese Angaben definieren, wie Ihre Programmumgebung aussehen wird, wenn Sie in den Befehlsmodus booten. Einige übliche Umgebungsvariablen, die Sie auf diese Weise setzen können, sind Shell, Pfad, Zeitzone etc.

Ändern der Umgebung

In Unix kann man sich die Umgebung ansehen oder diese verändern, indem man den Befehl env verwendet. Hier ist ein Beispiel für die Ausgabe, die Sie dann sehen könnten.

> env

ignoreeof=10
HOSTNAME=samshacker.samshack.net
LOGNAME=tr
MINICOM=-c on
MAIL=/spool/mail/samshack
TERM=ansi
HOSTTYPE=i386-linux
PATH=/usr/local/bin:/bin:/usr/bin:.:/sbin:/usr/sbin:.
HOME=/usr/local/etc/web-clients/samshacker/./
SHELL=/bin/bash
LS_OPTIONS=--8bit --color=tty -F -T 0
PS1=\h:\w\$
PS2=>
TAPE=/dev/nftape
MANPATH=/usr/local/man:/usr/man/preformat:/usr/man:/usr/X11/
[ic:ccc]man:/usr/openwin/man
LESS=-MM
OSTYPE=Linux
OPENWINHOME=/usr/openwin
SHLVL=2
BASH=/bin/bash
LS_COLORS=
_=/bin/csh
PWD=/usr/local/etc/web-clients/samshacker/./
USER=tr
HOST=samshack

Dieses Listing ist eine sehr umfangreiche Ausgabe auf einem Rechner, auf dem wahrscheinlich mehrere virtuelle Domains eingerichtet sind. Sie erkennen einen Hinweis darauf an dem vermeintlich nutzlos angehängten /./ am HOME-Verzeichnis des Benutzers. Dieses Suffix hat aber für manche Implementationen des ftp-Daemons eine spezielle Bedeutung: Der Benutzer kann die Verzeichnisse unterhalb dieses Pfads nicht verlassen, wenn er sich per ftp eingeloggt hat. Das ist insbesondere dann nutzbringend, wenn mehrere Benutzer oder Firmen Zugang zu dem Rechner haben und voneinander getrennt bleiben sollen. Bei virtuellen Hosts oder Domains ist das meistens der Fall. Ein reiner Shell-Rechner liefert eine überschaubarere Ausgabe:

samshacker% /usr/ucb/printenv
HOME=/home/hacker
HZ=100
LOGNAME=hacker
MAIL=/var/mail/hacker
PATH=/usr/bin:
SHELL=/sbin/sh
TERM=ansi
TZ=US/Pacific
PWD=/home/hacker
USER=hacker

Diese Ausgabe stammt von einer SPARCstation 10, auf der ich zum Schein einen Shell- Account eingerichtet habe (das erste Beispiel war ein Linux-Rechner). Dies ist eine sehr abgespeckte Umgebung. Die PATH-Angabe (Zeile 6) zeigt nur auf /usr/bin. Das ist eigentlich unzweckmäßig, da es auf einem Unix-System sehr viel mehr Binärdateien gibt als nur die in /usr/bin befindlichen. Zum Beispiel gibt es noch welche in /usr/sbin, /usr/bin/X11 und so weiter. Sie können sehen, daß sogar der Befehl (printenv) durch Angabe des gesamten absoluten Pfads erteilt wurde (/usr/ucb/printenv). Der Befehl env befindet sich im Verzeichnis /usr/bin.

Hinweis:

Die PATH-Angabe funktioniert bei Unix fast genauso wie die von DOS. Verzeichnisse, die Sie gerne im Pfad hätten, müssen in der PATH-Zeile angegeben und durch Doppelpunkte (statt Semikolons) getrennt werden. Durch die Angabe dieser Verzeichnisse in der PATH-Zeile geben Sie dem Benutzer die Möglichkeit, auf Befehle innerhalb dieser Verzeichnisse zuzugreifen (wobei es keine Rolle spielt, in welchem Verzeichnis er sich gerade befindet).

Terminal-Emulation

Andere in dem obigen Beispiel gesetzte Variablen sind HOME, MAIL, SHELL und TERM. TERM ist eine der wichtigsten Variablen und gibt die Art der Terminal-Emulation an, die Sie verwenden werden. Da vielleicht nicht jeder von Ihnen weiß, was eine Terminal-Emulation ist, möchte ich dies kurz erklären.

Vor Jahren waren die meisten Server Großrechner (Mainframes). Damals hatten die Benutzer keine leistungsfähigen PCs, die mit dem Großrechner verbunden waren, sondern Terminals, die (normalerweise) aus Rechnern ohne Festplatte bestanden. Es waren eigentlich nur Datensichtgeräte, bei denen Bildschirm und Tastatur oft eine Einheit bildeten. Auf der Rückseite der Terminals gab es eine Reihe von Anschlüssen, die unterschiedliche Verbindungsarten ermöglichten. Eine beliebte Methode war eine rudimentäre serielle Verbindung, die einzig und allein aus einem Kabel zur direkten Verbindung über die seriellen Schnittstellen bestand. Andere Terminals hatten Netzwerkkarten, die über Netzwerkkabel mit dem Großrechner verbunden waren (z.B. Ethernet).

Auf jeden Fall hatten diese Terminals eine sehr eingeschränkte Funktionalität (zumindest verglichen mit durchschnittlichen PCs). Auf der Hauptplatine eines solchen Terminals befand sich ein wenig Arbeitsspeicher und Firmware (auf der Platine gespeicherte Software). Diese Firmware bot dem Benutzer einige Möglichkeiten. Man konnte z.B. die Geschwindigkeit und Art der Verbindung einstellen, das lokale Echo (de)aktivieren und so weiter. Manchmal konnte man auch den verwendeten Druckertyp einstellen, oder den Port, von dem die Daten gesendet werden sollten.

Tip:

Solche Terminals werden in bestimmten Usenet-Newsgruppen immer noch verkauft. Wenn Sie z.B. Student und knapp bei Kasse sind und Ihnen eine Form des Ethernet- oder sogar seriellen Anschlusses an den Server Ihrer Uni angeboten wurde, und dieser Server-Account ein Shell-Account ist, sollten Sie sich ein Terminal besorgen. So können Sie für wenig Geld einen High-Speed-Zugang zum Internet erhalten. Sie können zwar im allgemeinen nichts auf eine Festplatte speichern, aber Sie können immerhin ausdrucken, was Sie auf dem Bildschirm gerade sehen. Sie werden staunen, wie schnell sich die Seiten aufbauen. Das sind ideale Voraussetzungen für Internet Relay Chat (IRC). Diese Terminals sind klein, billig und schnell.

Die beiden bekanntesten Terminals waren das Tektronix 4010 und das VT100 (und das IBM 3270, das ein bißchen unterschiedlich war). Sie konnten eine festgelegte Anzahl von Zeichen pro Zeile und Zeilen pro Bildschirm anzeigen. Die meisten Terminals hatten zwei unterschiedliche Einstellungsmöglichkeiten für die Darstellung. Später gab es sogar ein Terminal, das Spalten und schließlich sogar Grafiken darstellen konnte (das Tektronix war grafikorientiert).

Da diese Terminals zur Standardmethode der Verbindung mit Großrechnern wurden, drangen sie auch in die Unix-Welt vor. Deshalb haben alle Unix-Betriebssysteme Tastatur- und Bildschirm-Mappings für Terminals. Mappings sind Beschreibungen der Bildschirm- und Tastatureinstellungen. Darin wird z.B. angegeben, wie viele Zeilen und Spalten pro Bildschirm dargestellt werden können, oder - noch wichtiger - welche [Strg]-Tastenkombinationen für welche Sonderzeichen stehen. Letztere sind erforderlich, weil bestimmte Terminals mehr Tasten verwenden, als auf einer normalen PC- oder Mac-Tastatur dargestellt sind. Zum Beispiel gibt es zusätzlich zu den Funktionstasten noch spezielle [P]-Tasten, mit denen bestimmte Aktionen ausgeführt werden, wie die Aktivierung von Menüs oder die Navigation des Cursors in Datenbanken. Um diese Tasten auf einem PC nachahmen zu können, werden ihre Funktionen dort bestimmten Tastenkombinationen zugewiesen.

Bei Unix werden die Terminal-Mappings normalerweise in der Datei termcap gespeichert. Die Termcap-Library ist ein sehr wichtiger Bestandteil des Systems. Ohne sie wären viele Rechner nicht in der Lage, ordentlich miteinander zu kommunizieren. Wenn Sie z.B. ein frisch installiertes Linux-System haben und keine Änderungen der TERM-Variablen vornehmen, wird sie auf Linux gesetzt. Wenn Sie dann eine Telnet-Verbindung zu einer SPARCstation (oder einem anderen Rechner, der auch seine Default-Einstellung von TERM behalten hat) herstellen, werden Sie nicht in der Lage sein, den Bildschirm mit dem bekannten Befehl clear zu löschen. Der Grund dafür ist, daß die beiden Einstellungen für die Terminal-Emulationen nicht kompatibel sind. Wenn Sie versuchen, ein Programm wie PINE auszuführen - das kompatible Terminal-Typen voraussetzt - wird das Programm mit einer Fehlermeldung abbrechen, die besagt, daß Ihr Terminal nicht unterstützt wird. (Alle neueren Systeme verwenden anstelle der alten /etc/termcap-Datei das terminfo-System, welches aus einem ganzen Baum von Beschreibungsdateien unter /usr/lib/terminfo oder /usr/share/lib/terminfo besteht. Näheres dazu finden Sie in der Unix-Man-Page zu terminfo.)

Warnung:

Viele Unix-Distributionen haben vollständige termcap-Listings, die manchmal Hunderte von Terminal-Emulationen enthalten. Wenn Sie ein Unix-Neuling sind und mit dem Gedanken spielen, Ihre termcap-Einträge zu ändern, sollten Sie äußerst vorsichtig sein. Sie könnten zu sehr bizarren Ergebnissen kommen. In einigen Fällen kann etwas, das einmal wie ein nett formatierter Text ausgesehen hat, als eine seltsame Anordnung von verstreuten Textblökken dargestellt werden, die kaum mehr lesbar sind. Sie sollten unbedingt die entsprechende ManPage sorgfältig studieren, bevor Sie anfangen, Ihre termcap-Datei zu verändern.

Man kann viele unterschiedliche Umgebungsvariablen setzen. Diese Variablen haben einen starken Einfluß darauf, wie ein entfernter Rechner Ihre Telnet-Verbindung empfangen, verarbeiten und unterstützen wird. Deshalb wurde im Telnet-Protokoll die Möglichkeit vorgesehen, bestimmte Umgebungsvariablen zum Zeitpunkt der Verbindungsherstellung übergeben zu können. In RFC 1408 ist dies folgendermaßen beschrieben:

Viele Betriebssysteme haben Startinformationen und Umgebungsvariablen, die Informationen enthalten, die beim Herstellen einer Telnet-Verbindung an den entfernten Rechner übergeben werden sollen. Statt jedesmal eine neue Telnet-Option zu erzeugen, wenn jemand mit einer neuen Information auftaucht, die über eine Telnet-Sitzung übermittelt werden sollte, von der die Telnet-Sitzung selbst aber gar nichts wissen muß, kann diese generische Informationsoption verwendet werden.

Wegweiser:

Das gesamte RFC 1408 finden Sie unter http://sunsite.auc.dk/RFC/rfc/ rfc1408.html.

Das vor kurzem entdeckte Telnet-Sicherheitsloch basierte auf der Fähigkeit eines Telnet- Servers, diese Umgebungsvariablen zu empfangen, auf sie zu reagieren und ihre Übergabe zu autorisieren. Da diese Option bei Unix-Systemen so verbreitet ist, waren unglaublich viele Plattformen von dieser Sicherheitslücke betroffen.

Diese Schwachstelle tritt häufiger auf, als man erwarten würde. In einem ziemlich spannenden Bericht hat die Firma Novatech die Ergebnisse eines Sicherheitsaudits von einem Netzwerk mit 13 Hosts präsentiert. Darin taucht die Telnet-Sicherheitslücke auf - und 138 weitere Sicherheitslöcher. Das bemerkenswerteste daran ist, daß dieser Site bereits eine gute Sicherheit bescheinigt worden war, komplett mit Firewall. In Novatechs Auditbericht heißt es:

Dies ist eine Kopie eines Sicherheitsberichts mit Definitionen und Lösungsmöglichkeiten der entdeckten Probleme. Das Netzwerk verfügt über eine hochmoderne Firewall und wurde von CERT überprüft. Wie Sie sehen können, gab es eine Vielzahl kleinerer Probleme und auch ein größeres. Dies war nicht auf Fehler bei der Systemadministration zurückzuführen, sondern auf ein Zusammentreffen der Tatsache, daß sich Systeme dauernd ändern und deshalb ständige Aufmerksamkeit erfordern, und mangelndem Wissen darüber, wie Eindringlinge sich Zugang verschaffen (ein Spezialgebiet). Wir können Ihr System auf fast 300 unterschiedliche Schwachstellen untersuchen, die alle auf einem Zugang über das Internet beruhen.

Wegweiser:

Wenn Sie gegenüber Sicherheitsfragen eher eine Mentalität der Art »abwarten und Tee trinken« haben, sollten Sie diese Site sofort aufsuchen und sich die Ergebnisse des Audits ansehen. Sie sind frappierend. Sie finden die Ergebnisse des Audits unter http://www.novatech.net.au/sample.htm.

Die Zeile, die diese auf der Umgebungsvariablen-Option basierende Telnet-Sicherheitslücke offenbart, sieht folgendermaßen aus:

Dynamic Linker Telnet Vulnerability [High Risk]2

Diese Zeile sagt aus, daß eine Telnet-Sicherheitslücke der Risiko-Kategorie 2 gefunden wurde (in dem oben zitierten Audit wurde diese Sicherheitslücke gleich bei zwei Hosts innerhalb desselben Teilnetzes gefunden). [High Risk]2 bezeichnet die Schwere der Sicherheitslücke und steht für ein extrem hohes Risiko. Machen Sie sich folgendes noch einmal deutlich: Diese Lücke wurde auf einem Host mit einer modernen Firewall gefunden!

Um die zugrundeliegende Methode verstehen zu können, müssen Sie genau wissen, welche Optionen von den Clients an den Server übergeben werden können. Eine Möglichkeit ist die Übergabe einer eigenen libc.

Hinweis:

libc ist die Standard-C-Bibliothek. Eine vollständige libc-Distribution enthält im allgemeinen Header- und Include-Dateien zur Verwendung bei der C-Programmierung. Alle Unix-Arten haben diese Bibliothek installiert und sind ohne die dynamische Version der Bibliothek (shared object library, libc.so) nicht funktionsfähig. Die statische Version der Bibliothek (libc.a) ist Voraussetzung für das statische Linken eines Programms, das in der Programmiersprache C geschrieben wurde.

Sam Hartman vom MIT schreibt in seinem Artikel »Telnet Vulnerability: Shared Libraries«:

Das Problem ist, daß telnetd es dem Client erlaubt, LD_LIBRARY_PATH, LD_PRELOAD und andere Laufzeit-Linker-Optionen an die Prozeßumgebung des Prozesses zu übergeben, unter dem login läuft.

Wegweiser:

Hartmans Artikel finden Sie im Web unter http://geek-girl.com/bugtraq/ 1995_4/0032.html.

Bei der Übergabe der Umgebungsoption LD_LIBRARY_PATH an den Server kann ein Cracker diesem Suchpfad ein eigenes Verzeichnis (und damit eine eigene Bibliothek) hinzufügen. Dies kann zu einer Veränderung des dynamischen Link-Prozesses führen, wodurch der Angreifer beliebigen Zugriff auf das System erlangen kann, einschließlich Root-Privilegien.

Hinweis:

Hartman wies darauf hin, daß, wenn das Ziel ein Kerberos-basiertes telnetd verwendet, nur Benutzer mit einem gültigen Account auf dem entfernten Rechner den Angriff ausführen können. Ich vermute allerdings, daß der Großteil der Rechner nicht mit einer derartig abgesicherten Telnet-Version ausgerüstet ist.

Noch etwas ist an dieser Sicherheitslücke interessant: Es wurde festgestellt, daß man Telnet- Sitzungen identifizieren konnte, in denen die Umgebungsvariablen durch Ausführung einer ps-Anweisung übergeben wurden. Larry Doolittle stellte jedoch fest, daß man bei bestimmten Unix-Betriebssystemen (besonders Linux) Root sein mußte, um solche Prozesse ausführen zu können. Als Antwort auf den Hartman-Bericht schrieb Doolittle folgendes:

Neuere Linux-Kernel ermöglichen den Zugriff auf Umgebungsvariablen durch ps niemandem außer dem Benutzer selbst. D.h., /proc/*/environ ist durch den Modus 400 geschützt. Das könnte Leute verwirren, die Ihre Empfehlungen lesen, da sie Umgebungen für ihren eigenen Prozeß sehen würden, aber nicht die von root. Um die Umgebungsvariablen von Logins zu überprüfen, müssen Sie ps als root ausführen.

Wegweiser:

Den Artikel von Larry Doolittle finden Sie im Web unter http://geek- girl.com/bugtraq/1995_4/0042.html.

Hier finden Sie Patches für verschiedene Distributionen von telnetd:

Hinweis:

Obwohl Patches für dieses Problem herausgegeben worden sind, könnten einige andere mit Telnet verbundene Module und Programme immer noch betroffen sein. Erst im Februar 1997 wurde berichtet, daß in.telnetsnoopd durch die Übergabe von LD_PRELOAD auf einigen Plattformen, einschließlich Linux, verwundbar sei. Es gibt jedoch einen Patch für dieses Problem, den Sie hier finden: ftp://sunsite.unc.edu/.

Das normale Telnet ist kein besonders sicheres Protokoll. Man kann eine Telnet-Sitzung leicht abhören. Es gibt zu diesem Zweck sogar ein Utility, das ttysnoop heißt. Sein Autor, Carl Declerck, beschreibt es so:

[ttysnoop] ermöglicht Ihnen, Login-ttys über ein anderes tty-Gerät oder Pseudo-tty auszuspionieren. Der ausspionierende tty wird zu einem »Klon« des ursprünglichen tty und leitet sowohl Ein- als auch Ausgaben von bzw. zu diesem.

Wegweiser:

Declercks README für ttysnoop 0.12 (alpha) finden Sie unter http:// ion.apana.org.au/pub/linux/sources/admin/ttysnoop-0.12.README.

Hinweis:

ttysnoop ist nicht einfach nur ein Telnet-spezifischer Snooper; er spioniert das tty aus, nicht das Telnet-Protokoll. Ein Netzwerk-Sniffer wie sniffit kann ebenfalls verwendet werden (und ist wahrscheinlich geeigneter), um das Telnet-Protokoll auszuspionieren.

Telnet-Sitzungen sind zudem besonders sensibel. Ein Grund dafür ist, daß diese Sitzungen oft wie ein »Inselhüpfen« durchgeführt werden. D.h. der Benutzer kann sich mit einem Netzwerk-Rechner per Telnet verbinden, um seine Webseiten zu aktualisieren; von dort aus kann der Benutzer sich per Telnet mit einem anderem Rechner verbinden und dann wieder mit einem anderen usw. Wenn ein Crakker eine solche Sitzung ausspioniert, kann er Benutzerkennungen und Paßwörter für andere Systeme herausfinden.

27.1.3 Haben diese Angriffe überhaupt noch Zweck?

Aufgrund mangelnder Kenntnisse über diese Angriffe: ja. Die oben beschriebene Umgebungsvariablen-Attacke ist auf vielen Systemen immer noch recht wirkungsvoll. Und das, obwohl es im Internet genügend Advisories zu diesem Angriff gibt.

27.1.4 Telnet als Waffe

Telnet ist ein interessantes Protokoll. Wie ich bereits erwähnt habe, können Sie eine Menge in Erfahrung bringen, wenn Sie Telnet verwenden. Sie können z.B. herausfinden, welche Version des Betriebssystems auf dem Rechner läuft. Die meisten Unix-Distributionen geben diese Informationen bei der Verbindungsherstellung an. Es wurde von mindestens einer zuverlässigen Quelle berichtet, daß verschiedene Scanner die Informationsausgabe bei der Verbindungsherstellung dazu verwenden, den Systemtyp zu identifizieren (SATAN ist einer dieser Scanner). Das Betriebssystem kann man im allgemeinen durch eine Verbindung auf einen oder mehrere der folgenden Ports herausbekommen:

Hinweis:

Obwohl ich hier nur fünf Ports aufgeführt habe, kann man sich mit den meisten TCP/IP-Ports verbinden, wenn man eine Telnet-Sitzung initiiert. Einige dieser Ports bleiben während der Verbindung absolut passiv, und der Benutzer kann nicht erkennen, daß etwas passiert. Das ist z.B. bei Port 80 (HTTP) so. Dennoch können Sie über Telnet Anfragen an Port 80 machen, und wenn diese Anfragen gültig sind, wird Port 80 auch antworten. (Die Anfragen müssen noch nicht einmal gültig sein. Eine fehlerhafte GET-Anweisung wird eine lebhafte Antwort des Web-Servers auslösen, wenn die Anfrage ausreichend schlecht formuliert ist.)

In ihrer inzwischen berühmten Abhandlung »Improving the Security of Your Site by Breaking Into It« weisen Dan Farmer und Wietse Venema darauf hin, daß Ports angegriffen werden können. Sie sprechen insbesondere Port 6000 an:

Das X-Windows-System verwendet normalerweise Port 6000... Wenn es nicht richtig abgesichert ist (über Magic-Cookie- oder xhost-Mechanismen), können Fensterinhalte abgefangen oder eingesehen werden, Tastatureingaben der Benutzer gestohlen werden, Programme entfernt ausgeführt werden etc. Außerdem kann, wenn auf dem Ziel X läuft und es Telnet auf Port 6000 akzeptiert, dies für eine DoS-Attacke ausgenutzt werden, da das Fenstersystem des Ziels oft für kurze Zeit »eingefroren« werden kann.

Wegweiser:

»Improving the Security of Your Site by Breaking Into It« finden Sie im Web unter http://stos-www.cit.cornell.edu/Mark_html/Satan_html/docs/ admin_guide_to_cracking.html.

Farmer und Venema weisen in diesem Dokument auf viele Angriffe hin, die mit Telnet alleine oder in Verbindung mit anderen Programmen implementiert werden können. Eine dieser Attacken betrifft ein X-Terminal:

X-Terminals sind normalerweise plattenlose Clients. Das sind Geräte, die nur über die minimale Hard- und Software-Ausstattung verfügen, um sich mit einem X-Server verbinden zu können. Sie werden am häufigsten in Universitäten benutzt und bestehen aus einem 17- oder 19-Zoll-Monitor, einer Basis, einer Tastatur und einer Maus. Das Terminal unterstützt normalerweise ein Minimum von 4 Mbyte RAM, aber einige können bis zu 128 Mbyte aufnehmen. X-Terminals haben außerdem eine Client-Software, mit deren Hilfe sie sich mit dem Server verbinden. Normalerweise erfolgt die Vernetzung über einen Fast-Ethernet-Anschluß auf der Rückseite des Terminals. X- Terminals stellen eine High-Speed-Anbindung an X-Server zur Verfügung, zusammen mit einer Hochleistungsgrafik. Diese Rechner werden im Internet verkauft und eignen sich ausgezeichnet als »zusätzliche« Terminals für zu Hause. (Sie sind besonders gut für Übungszwecke zu gebrauchen.)

Die X-Terminal-Technik von Farmer und Venema verwendet eine Kombination von rsh und Telnet zur Durchführung eines koordinierten Angriffs. Die Technik beinhaltet die Stapelverarbeitung mehrerer Befehle. Der Cracker verwendet rsh zur Verbindung mit dem X-Terminal und ruft dann das Telnet-Client-Programm des X-Terminals auf. Schließlich wird die Ausgabe an das lokale Terminal des Crackers umgeleitet, indem die DISPLAY-Option oder - Variable angegeben wird.

Eine weitere interessante Aufgabe, für die Telnet verwendet werden kann, ist die unmittelbare Feststellung, ob es sich bei dem Ziel um eine reale oder eine virtuelle Domain handelt (das kann man auch auf andere Weise herausfinden, aber nicht so schnell). Dem Cracker kann dies helfen, genau festzustellen, welchen Rechner er knacken muß, um an Ihre Ressourcen zu gelangen.

Eine reale Domain ist normalerweise eine Domain, die beim InterNIC registriert worden ist und ihren eigenen dedizierten Server hat. Irgendwo steht ein Rechner mit einer permanenten IP-Adresse, und dieser Rechner ist ständig an das Internet angebunden (über ein 28.8-Kbps- Modem, ISDN, 56-Kbps-Modem, Frame Relay, T1, T3, ATM oder vielleicht sogar FDDI). Wenn Sie also mit einer solchen realen Site eine Telnet-Verbindung herstellen, erreichen Sie genau diesen Rechner und keinen anderen.

Virtuelle Domains sind dagegen einfach nur Verzeichnisse auf einem realen Server, die mit einem bestimmten Domainnamen verbunden sind. D.h. Sie bezahlen einen ISP für die Registrierung Ihres Domainnamens und die Bereitstellung eines Verzeichnisses auf seiner Festplatte, das mit diesem Namen verbunden ist. So erwecken Sie durch die Adresse Ihr_Unternehmen.com den Anschein, als hätten Sie einen realen Server. Wenn Internet- Benutzer ihren Browser auf www.Ihr_Unternehmen.com führen, erreichen sie in Wirklichkeit den Server Ihres ISPs. Dieser Server leitet die Verbindungsanforderung dann an Ihr Verzeichnis weiter. Diese virtuellen Domains sind aus mehreren Gründen sehr beliebt, unter anderem wegen der geringeren Kosten. Ihr Unternehmen muß auf diese Weise keinen eigenen Server bereitstellen und vermeidet damit die Ausgaben für:

Sie zahlen einfach eine Einrichtungsgebühr (und danach monatliche Gebühren), und der ISP kümmert sich um den Rest. Für Cracker könnte dies eine wichtige Information sein. Wenn ein Cracker z.B. Ihre Domain knacken will - ohne vorher festzustellen, ob Ihr Rechner ein realer Server ist -, könnte er sich Ärger einhandeln. Er denkt, er würde irgendeinen kleinen Rechner in Ihrem Büro knacken, und in Wirklichkeit ist er dabei, einen großen, bekannten Netzwerkprovider anzugreifen.

Telnet gibt den Status Ihres Servers unmittelbar preis. Wenn ein Cracker eine Telnet-Sitzung zu Ihr_Unternehmen.com initiiert (und bei der Verbindungsherstellung den Namen des Rechners als Node eines anderen, größeren Netzwerks sieht), weiß er sofort, daß Ihre Adresse eine virtuelle Domain ist.

Telnet kann auch noch zu anderen schändlichen Zwecken eingesetzt werden. Einer ist die beliebte Gewaltattacke (brute-force-Angriff). Ich bin mir nicht sicher, warum Gewaltattakken bei jungen Crackern so beliebt sind; fast alle Server führen heutzutage irgendeine Art der Protokollierung durch. Dennoch hat diese Methode bis heute überlebt. Diese Angriffe werden meistens über Telnet-Clients initiiert, die ihre eigene Scriptsprache eingebaut haben. Tera Term ist eine solche Applikation.

Tera Term verfügt über eine Sprache, die Ihnen die Möglichkeit gibt, Telnet-Sitzungen zu automatisieren. Diese Sprache kann zum Schreiben von Scripts verwendet werden, die gültige Benutzernamen auf einem System herausfinden können, das sich weigert, auf finger- oder sendmail-expn-Anforderungen hin Informationen preiszugeben. Die Telnet-Versionen geben diese Informationen auf unterschiedliche Art aus. Wird z.B. ein falscher Benutzername angegeben, wird die Verbindung gekappt. Wenn jedoch ein gültiger Benutzername eingegeben wird, wird ein neuer login:-Prompt ausgegeben.

Wegweiser:

Tera Term finden Sie unter http://www2.tinet-i.or.jp/cybird-f/windows/ comm/ttermv13.zip

Außerdem ist Telnet auch ein ausgezeichnetes Tool um festzustellen, ob ein bestimmter Port offen ist oder ob auf einem Server ein bestimmter Dienst läuft. Telnet kann auch als Waffe für DoS-Angriffe verwendet werden. Durch das Senden von Müll an bestimmte Ports eines NT-Web-Servers unter IIS kann man den Zielprozessor auf eine Auslastung von 100% treiben. Das Initiieren von Telnet-Sitzungen zu anderen Ports eines NT-Web-Servers kann den Rechner dazu bringen, sich aufzuhängen bzw. abzustürzen. Das geschieht insbesondere nach Aussenden einer Telnet-Verbindungsanforderung an Port 135.

Wegweiser:

Microsoft hat eine Abhilfe für dieses Problems herausgegeben, die Sie hier finden: ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/ nt40/.

Man kann auch Microsofts Internet Information Server zum Absturz bringen, indem man sich per Telnet mit Port 80 verbindet und eine GET.../...-Anforderung ausführt. Dieses Problem wurde Berichten zufolge jedoch durch den Microsoft Windows NT Service Pack 2 für Windows NT 4.0 behoben. Wenn Sie dieses Service Pack nicht haben, sollten Sie ihn sich unbedingt besorgen. Eine gute Abhandlung über dieses und andere Probleme können Sie in dem Denial of Service Info finden, das Chris Klaus von Internet Security Systems gepostet hat. Darin schreibt Klaus:

Wenn der Filesharing-Dienst für jeden verfügbar und zugänglich ist, kann dies dazu führen, daß der NT-Rechner abstürzt und neu gebootet werden muß. Diese Technik verwendet den Dot-Dot-Bug auf einem Windows-95-Rechner und ermöglicht es jedem, Zugriff auf die gesamte Festplatte zu erlangen. Diese Sicherheitslücke ist in der Microsoft Knowledge Base dokumentiert, in Artikel Nummer Q140818, überarbeitete Fassung vom 15. März 1996. Abhilfe schafft die Installation des neuesten Service Pack für Windows NT Version 3.51. Das neueste Service Pack mit diesem Patch ist Service Pack 4.

Wegweiser:

Das Denial of Service Info finden Sie unter http://geek-girl.com/bugtraq/ 1996_2/0052.html.

Hinweis:

Diese Sicherheitslücke gab es nur beim Internet Information Server 2.0 Webserver (HTTP). Spätere Versionen von IIS sind Berichten zufolge nicht mehr davon betroffen.

Schließlich wird Telnet auch noch gerne dazu verwendet, Mail und News zu fälschen. Versender von Massen-Mailings (Spams) verwenden diese Möglichkeit oft anstelle des regulären Postens von Usenet-Nachrichten. Es gibt bestimmte Optionen, die so gesetzt werden können, daß diese »Spammer« zumindest einige der Abwehrmaßnahmen umgehen können, die von Robots zur Abwehr von Spams im Usenet erzeugt werden.

27.2 Zusammenfassung

Telnet ist ein sehr vielseitiges Protokoll, und mit etwas Aufwand kann man es zu einem sicheren Protokoll machen. (Ich persönlich bevorzuge SSH als Ersatz für Telnet, da es vor dem Ausspionieren von Telnet-Sitzungen schützt). In seiner Default-Konfiguration ist Telnet jedoch nicht immer sicher. Wenn Sie ältere Software verwenden (vor 1997), sollten Sie überprüfen, ob die entsprechenden Patches installiert wurden.

Telnet kann auch dazu verwendet werden, entfernte Hosts anzugreifen oder von ihnen Informationen zu erhalten (einige Möglichkeiten wurden in diesem Kapitel beschrieben). Wenn dieses Buch erscheint, werden bereits viele andere Telnet-Attacken aufgetaucht sein. Wenn Sie ein Netzwerk betreiben und beabsichtigen, Ihren Benutzern Telnet-Zugriff zu ermöglichen, sollten Sie sich in acht nehmen. Das gilt besonders für neue Telnet-Server. Diese neuen Server könnten Bugs enthalten, die noch unentdeckt sind. Und da Telnet sehr interaktiv ist und dem Benutzer viele Möglichkeiten gibt, Befehle auf entfernten Rechnern auszuführen, ist jedes Sicherheitsloch in einer Telnet-Distribution ein kritisches. In dieser Hinsicht steht es auf einer Stufe mit FTP oder HTTP (oder ist vielleicht sogar noch ernster).

27.2.1 Informationsquellen

Sendmail Bug Exploits List. Erläutert Methoden zum Angreifen von Sendmail. Einige dieser Techniken beruhen auf Telnet. http://www.tern.com.hk/~death/buglist.htm

Improving the Security of Your Site by Breaking Into It. Dan Farmer und Wietse Venema. http://stos-www.cit.cornell.edu/Mark_html/Satan_html/docs/ admin_guide_to_cracking.html

The Telnet Protocol Specification (RFC 854). J. Postel und J. Reynolds. Mai 1983. http:// sunsite.auc.dk/RFC/rfc/rfc854.html

The Telnet Environment Option (RFC 1408). D. Borman, Editor. Cray Research, Inc. Januar 1993. http://sunsite.auc.dk/RFC/rfc/rfc1408.html

Telnet Environment Option (RFC 1572). S. Alexander. ftp://ds.internic.net/rfc/ rfc1572.txt

Telnet Authentication: SPX (RFC 1412). K. Alagappan. ftp://ds.internic.net/rfc/ rfc1412.txt

Telnet Remote Flow Control Option (RFC 1372). C. Hedrick und D. Borman. ftp:// ds.internic.net/rfc/rfc1372.txt

Telnet Linemode Option (RFC 1184). D. A. Borman. ftp://ds.internic.net/rfc/ rfc1184.txt

The Q Method of Implementing Telnet Option Negotiation (RFC 1143). D. J. Bernstein. ftp://ds.internic.net/rfc/rfc1143.txt

Telnet X Display Location Option (RFC 1096). G. A. Marcy. ftp://ds.internic.net/rfc/ rfc1096.txt

Telnet Binary Transmission (RFC 856). J. Postel und J. K. Reynolds. ftp://ds.internic.net/rfc/rfc856.txt

Remote User Telnet Service (RFC 818). J. Postel. ftp://ds.internic.net/rfc/rfc818.txt

Discussion of Telnet Protocol (RFC 139). T. C. O'Sullivan. Leider konnte ich diesen RFC online nicht finden.

First Cut at a proposed Telnet Protocol (RFC 97). J. T. Melvin und R. W. Watson. Leider ist dieser RFC anscheinend nicht mehr online verfügbar.

The Telnet Authentication Option. Internet Engineering Task Force Internet Draft. Telnet Working Group. D. Borman, Hrsg. Cray Research, Inc. Februar 1991. http://web.dementia.org/~shadow/telnet/preliminary-draft-borman-telnet-authentication-00.html

Telnet Authentication: Kerberos Version 4 (RFC 1411). D. Borman, Hrsg. Cray Research, Inc. Januar 1993. ftp://ds.internic.net/rfc/rfc1411.txt

Session-Layer Encryption. Matt Blaze und Steve Bellovin. Proceedings of the Usenix Security Workshop. Juni 1995.

Attaching Non-TCP-IP Devices with Telnet. Stefan C. Johnson. Sys Admin: The Journal for UNIX Systems Administrators, 5(6), S. 51. Juni 1996.

Secure RPC Authentication (SRA) for Telnet and FTP. David K. Hess, David R. Safford und Douglas Lee Schales. Proceedings of the Fourth Usenix Security Symposium, Supercomputer Center, Texas A&M University. 1993.

Internetworking with TCP/IP Vol. 1: Principles, Protocols and Architecture. Douglas Comer. Prentice Hall. 1991. http://www.pcmag.com/issues/1606/pcmg0050.htm

EFF's (Extended) Guide to the Internet - Telnet. Adam Gaffin. Mining the Net, Part I. http:/ /cuiwww.unige.ch/eao/www/Internet/Extended.Guide/eeg_93.html



vorheriges KapitelInhaltsverzeichnisStichwortverzeichnisKapitelanfangnächstes Kapitel