|
|
Telnet- AngriffeJetzt beschäftigen wir uns mit 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:
Tipp:
TelnetWie 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. Tipp:
Virtuelles TerminalDas Besondere an Telnet ist, dass 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:
Tipp:
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). Tipp:
Die Geschichte der Telnet-SicherheitTelnet 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:
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, dass der telnetd-Daemon bestimmter Sun-Distributionen fehlerhaft war. In einem CERT-Advisory steht:
Tipp:
Tipp:
Monate später wurde entdeckt, dass eine spezielle LAT/Telnet-Anwendung von Digital Corporation ebenfalls einen Fehler hatte. In dem CERT-Advisory heißt es:
Tipp:
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, dass die Benutzer nicht richtig verstanden hatten, wie diese Anwendung funktionierte. Die Leute bei DDN schrieben folgendes dazu:
Das Problem hing mit einer Konfigurationsdatei zusammen, in der man den integrierten FTP-Server aktivieren oder deaktivieren konnte. Die meisten Benutzer nahmen an, dass 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, dass 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 Passwort 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 Passwörter der Benutzer abgelegt sind. Die verschlüsselten Passwö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 Passwort ist zwar verschlüsselt, aber das Verschlüsselungsschema ist sehr dürftig. Wenn das Passwort z.B. aus weniger als sechs Zeichen besteht, kann man es innerhalb von wenigen Sekunden knacken. Das Knacken solcher Passwörter ist sogar so trivial, dass man es mit einem 14 Zeilen langen BASIC-Programm erledigen kann. Tipp:
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, dass 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:
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). Tipp:
Ändern der UmgebungIn 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.
Dieses Listing ist eine sehr umfangreiche Ausgabe auf einem Rechner, auf dem wahrscheinlich mehrere virtuelle Domains eingerichtet sind. Sie erkennen einen Tipp 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:
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, dass sogar der Befehl (printenv) durch Angabe des gesamten absoluten Pfads erteilt wurde (/usr/ucb/printenv). Der Befehl env befindet sich im Verzeichnis /usr/bin. Terminal-EmulationAndere 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. Tipp:
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
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, dass 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, dass 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
Tipp:
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:
Tipp:
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, dass dieser Site bereits eine gute Sicherheit bescheinigt worden war, komplett mit Firewall. In Novatechs Auditbericht heißt es:
Tipp:
Die Zeile, die diese auf der Umgebungsvariablen-Option basierende Telnet-Sicherheitslücke offenbart, sieht folgendermaßen aus:
Diese Zeile sagt aus, dass 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 zugrunde liegende 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. Tipp:
Sam Hartman vom MIT schreibt in seinem Artikel »Telnet Vulnerability: Shared Libraries«:
Tipp:
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. Tipp:
Noch etwas ist an dieser Sicherheitslücke interessant: Es wurde festgestellt, dass man Telnet- Sitzungen identifizieren konnte, in denen die Umgebungsvariablen durch Ausführung einer ps-Anweisung übergeben wurden. Larry Doolittle stellte jedoch fest, dass 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:
Tipp:
Tipp:
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:
Tipp:
Tipp:
Telnet-Sitzungen sind zudem besonders sensibel. Ein Grund dafür ist, dass 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 Passwörter für andere Systeme herausfinden. 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. Telnet als WaffeTelnet 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, dass 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:
Tipp:
In ihrer inzwischen berühmten Abhandlung »Improving the Security of Your Site by Breaking Into It« weisen Dan Farmer und Wietse Venema darauf hin, dass Ports angegriffen werden können. Sie sprechen insbesondere Port 6000 an:
Tipp:
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:
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, dass 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. Tipp:
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. Tipp:
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:
Tipp:
Tipp:
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, dass diese »Spammer« zumindest einige der Abwehrmaßnahmen umgehen können, die von Robots zur Abwehr von Spams im Usenet erzeugt werden. ZusammenfassungTelnet 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 |
Senden Sie E-Mail mit Fragen oder Kommentaren zu dieser Website an:
tos.computer@gmx.de
|