Öffentliche Internetzugänge sind meist durch restriktive Firewalls geschützt, auch SSH hat dann keine Chance. HTTPS auf Port 443 ist aber in der Regel erlaubt. Mit Ajaxterm nutzen Anwender auf Reisen diese letzte Lücke für sichere Logins auf dem eigenen Server.

Egal ob Urlaub oder Dienstreise: Viele Anwender zieht es unterwegs in Internetcafés, um Mail zu lesen, auf dem eigenen Webserver die Logs zu prüfen oder gar aus der Ferne Software zu aktualisieren (denn Sicherheitsupdates sind zeitkritisch). Die erste Aufgabenstellung löst ein Webmail-System, aber Linux-Freunde bevorzugen oft Konsolen-Tools wie Mutt, die weniger schwerfällig sind. Früher war es meist möglich, fehlende Software auf den Internetcafé-Rechnern nachzuinstallieren; für Remote-Zugriffe eignete sich etwa Putty [1] als Windows-SSH-Client. Mit zunehmenden Virenproblemen der Café-PCs ist diese Möglichkeit jedoch rar geworden.

Als Alternative bieten sich Java-Applets an, die SSH-Verbindungen mit dem eigenen Server aufnehmen, wie etwa Mindterm [2]. Wachsende Sorgen der Café-Betreiber haben aber zum verstärkten Einsatz von Firewalls geführt, die auch den SSH-Port (22) sperren. Selbst der Trick, den SSH-Port auf den HTTPS-Port 443 zu verlegen, greift in einigen Fällen nicht mehr, da Protokoll-Analyzer auch dieses Tor schließen. Spricht der Client auf dem HTTPS-Port ein anderes Protokoll als HTTPS, blockiert der Analyzer die Verbindung.

Raus durch die Firewall

Es gab lange Zeit kein Tool, das Terminaldienste in einer HTTPS-Session anbot, aber genau dies ist notwendig, um von einem verbarrikadierten Rechner aus noch ein sicheres Einloggen auf dem eigenen Server zu erlauben. Abhilfe könnte die neue Ajax-Technologie (Asynchronous Javascript and XML, [3]) schaffen, und tatsächlich gibt es eine Ajax-basierte Lösung namens Ajaxterm [4]. Das VT100-kompatible Terminalprogramm ist eine Weiterentwicklung von Anyterm [5], allerdings ist es deutlich leichter zu installieren und zu benutzen. Für einen ersten Test reichen die Befehle in Listing 1.

01 mkdir -p /var/www/test; cd /var/www/test
02 wget http://antony.lesuisse.org/qweb/files/Ajaxterm-0.9.tar.gz
03 tar zxvf Ajaxterm-0.9.tar.gz
04 mv Ajaxterm-0.9 ajaxterm
05 cd ajaxterm
06 ./ajaxterm.py

Python-Skript

Ajaxterm ist ein Python-Skript. Es öffnet auf der Localhost-Schnittstelle den Port 8022 und ist sofort einsatzbereit. Ein Verbindungsaufbau über Port 443 (das eigentliche Ziel) ist damit noch nicht möglich, aber ein erster Test zeigt nun schon, wohin die Reise geht: Über die URL »http://localhost:8022« ist die lokale Anmeldung möglich; Ajaxterm ruft dazu auf dem Server »/bin/login« auf. Danach läuft im Browserfenster eine voll funktionsfähige Terminalsitzung ab.

Drei Buttons im Fenster bieten Zusatzfunktionen: »Color« schaltet den Farbmodus aus und wieder an, »GET« wechselt zwischen Get- und Post-Modus (der Post-Modus ist der sicherere der beiden und deshalb voreingestellt) und »Paste« erlaubt Copy&Paste, wenn es in den Browser-Sicherheitseinstellungen erlaubt wurde. Dabei geht es um das Einfügen von Daten aus der Zwischenablage in die Ajaxterm-Sitzung, was nur funktioniert, wenn Javascript darauf zugreifen darf. Der umgekehrte Weg ist immer möglich, denn die Darstellung des Terminals im Browser ist zeichenbasiert. Die Betriebsarten sind per Klick umschaltbar; ein grüner Knopf signalisiert, dass der Modus eingeschaltet ist.

Javascript mag Copy&Paste nicht

Copy&Paste erleichtert in vielen Fällen die Arbeit, gilt aber für Javascript-Anwendungen als Sicherheitsproblem. Darum erscheint beim Einschalten dieser Option meist nur der Verweis auf eine Anleitung [6], die erklärt, wie diese Funktion in den Sicherheitseinstellungen von Firefox zu aktivieren ist.

Statt von »/bin/login« startet Ajaxterm über die Option »-c« wahlweise ein anderes Programm, sodass zum Beispiel via »ssh« die Weiterleitung auf einen anderen Rechner möglich ist. Auch der Port (Standard ist 8022) ist frei wählbar und auf Wunsch schreibt Ajaxterm ein eigenes Log (über die Option »-l« auf die Standardfehlerausgabe).

Da Ajaxterm Verbindungen nur über die Localhost-Netzwerkschnittstelle zulässt, ist für den Remote-Zugriff zusätzlich ein Webserver nötig – die Listings in diesem Artikel beschreiben die Konfiguration von Apache ab Version 2.

01 Listen 443
02 NameVirtualHost *:443
03 
04 <VirtualHost *:443>
05    ServerName test.Domain.de
06    SSLEngine On
07    SSLCertificateKeyFile ssl/apache.pem
08    SSLCertificateFile ssl/apache.pem
09 
10    # Haupt-Verzeichnis dieses virtuellen Hosts
11    #
12    DocumentRoot /var/www/test
13 
14    # Möglichst das normale Proxy-Verhalten des
15    # Proxy-Moduls ausschalten, damit keine Fremden
16    # den Webserver als offenen Proxy missbrauchen!
17    #
18    ProxyRequests Off
19 
20    # Loglevel normalerweise bei "warn", loggt also
21    # recht viel mit. Um wenig bis nichts zu loggen,
22    # empfiehlt sich "emerg"
23    #
24    LogLevel warn
25 
26    # Selbst wenn man loggt, sollte man nur wenig
27    # mitloggen, hier nur Quell-IP, Zeit und Status
28    #
29    CustomLog /var/log/apache2/ajaxterm-access.log "%a %t %s"
30    ErrorLog /var/log/apache2/ajaxterm-error.log
31 
32    # Das sind nun die eigentlichen Weiterleitungen auf
33    # die intern laufende Applikation
34    #
35    ProxyPass /ajaxterm/ http://localhost:8022/
36    ProxyPassReverse /ajaxterm/ http://localhost:8022/
37 </VirtualHost>

Abbildung 1: Auch wenn eine Firewall den SSH-Login via Port 22 verbietet und generell alle Ports außer 80 (HTTP) und 443 (HTTPS) schließt, erlaubt Ajaxterm den Remote-Login, denn es läuft auf dem Server und stellt über HTTPS ein Terminalfenster im Webbrowser dar.

Ajax und Apache

Um über den HTTPS-Port auf Ajaxterm zugreifen zu können, empfiehlt die Programmdokumentation eine externe Umleitung über Apaches Proxy-Funktionen (Listing 2, Zeilen 35 und 36). Abbildung 1 illustriert das Zusammenspiel der drei Komponenten Webbrowser (auf der Client-Seite) sowie Apache und Ajaxterm (auf dem Server).

Beim Einsatz mit Apache wird die höhere Geschwindigkeit des Get-Modus zum zweischneidigen Schwert: Im Webserver-Log tauchen dann alle URLs auf – und damit auch die einzelnen Tastendrücke. Darum muss jeder Anwender zumindest bei Passworteingaben auf den Post-Modus umschalten, unter anderem bei der Anmeldung. Auch wer nach dem Login via SSH eine Verbindung zu einem dritten Rechner aufbaut, ist nicht vor Apache-Log-Einträgen geschützt, denn der Apache-Server empfängt die Tastatureingaben weiterhin im Klartext.

SSL-Zertifikat erstellen

Hat der Apache-Server noch gar kein SSL-Zertifikat (in der Konfigurationsdatei: »apache.pem«), folgt nun ein Aufruf von »apache2-ssl-certificate«: Das Skript erstellt solche Zertifikate. Beim Aufruf mit dem Parameter »-new« fragt das Tool diverse Daten ab (darunter die Länderkennzeichnung, den Bundesstaat, die Stadt, den Organisationsnamen und so weiter), bei denen man sinnvolle Angaben machen sollte, aber auch einfach die Defaultwerte übernehmen kann.

Ein absolutes Muss ist der korrekte Servername, denn sonst beschweren sich die Browser bei jedem Ladevorgang über das Zertifikat und verweigern möglicherweise sogar die Zusammenarbeit mit dem Server. Das selbst signierte Zertifikat hat Nachteile gegenüber einem Zertifikat, das eine CA ausgestellt hat. Für den Terminalzugang zum eigenen Rechner reicht es aus, beim Zugriff über den Browser die Fingerprints zu prüfen. Ist das zu unpraktisch, bleibt nur der Kauf eines Zertifikats.

Auch zur Verwendung des Proxy-Moduls muss der Administrator Apache erst überreden. Die Befehlssequenzen in Listing 3 aktivieren unter Debian Sarge gleichzeitig die SSL- und Proxy-Module. Ist die Arbeit erledigt, sodass der Server Anfragen auf dem SSL-Port beantwortet, funktioniert auch der Ajaxterm-Zugriff über eine URL der Form »https://test.domain.de/ajaxterm/«. Eine Beispiel-Session mit »screen« zeigt Abbildung 2.

01 cd /etc/apache2/mods-enabled/
02 for i in proxy.load proxy.conf ssl.load ssl.conf; do ln -s ../mods-available/$i .; done
03 /etc/init.d/apache2 restart

Abbildung 2: Diese Terminalsitzung läuft mit SSL über den Apache-Server, der als Proxy die Anfragen an Ajaxterm weiterleitet. Das Programm startet dann »/bin/login«, der Anwender meldet sich wie an einer lokalen Konsole an.

Loggen ist schlecht für die Sitzung

Das Apache-Log wird schnell sehr groß, weshalb es in der Beispielkonfiguration auf das Wesentliche verkürzt ist (Zeile 29): Der Server protokolliert nur Quell-IP, Zeit und Status der Anfrage. Da nicht nur Tastaturevents über die Verbindung laufen, sondern auch alle zwei Sekunden eine Keep-alive-Abfrage, damit die Session erhalten bleibt, ist es empfehlenswert, das Logging stark einzuschränken: »LogLevel emerg« statt »LogLevel warn«. Im obigen Beispiel steht der Loglevel noch auf »warn«, was in der Probephase beim Debuggen hilft.

Loggt der Server, verlangsamt sich die Terminalsitzung so stark, dass sich Get- und Post-Modus ähnlich anfühlen. Auflistungen mit »ls« oder Ausgaben von »cat« laufen zwar zügig über den Bildschirm, sind aber deutlich langsamer als über eine SSH-Verbindung. So ist die Arbeit mit »vi« recht zäh, wenn auch im brauchbaren Bereich. Erst wenn Apache über »LogLevel emerg« nur noch die wichtigsten (Panic-)Ereignisse ins Log schreibt, gibt es einen deutlichen Unterschied zwischen Get- und Post-Modus: In Letzterem arbeitet es sich fließender.

Ordentliche Geschwindigkeit

Messungen der Übertragungsgeschwindigkeit zwischen Browser und Webserver lieferten folgende Ergebnisse: Im Leerlauf (wenn der angemeldete Benutzer keine Tasten drückt) wandern laut »ifstat« zirka 1 bis 3 KByte pro Sekunde zwischen Server und Client hin und her. Laufen umfangreiche Ausgaben (mit »cat« oder »ls«), ist das Verhältnis zwischen ausgegebenen und übertragenen Daten im Get-Modus knapp 1:5, das heißt, das Fünffache der angezeigten Datenmenge wandert über die Leitung.

Im Post-Modus verringert sich der Wert auf günstige 1:1,5 bis 1:2, es fließen also deutlich weniger Daten vom Server zum Browser, maximal das Doppelte der im Terminal angezeigten Daten. Das Zwischenschalten des Apache-Servers scheint Ajaxterm grundsätzlich ein wenig auszubremsen: Am schnellsten reagiert die Anwendung auf dem Localhost-Port ohne Apache-/SSL-Umgebung.

Mehr als nur ein Terminal

Interessant ist auch die Möglichkeit, Ajaxterm über mehrere Proxy-Einträge verschiedene Befehle ausführen zu lassen. Dazu startet man Ajaxterm einfach mehrfach (auf verschiedenen Ports) und trägt entsprechende Verweise ein. Um etwa über die URL »https://server.de/top/« eine Ausgabe des Programms Top anzuzeigen, sind zwei Zusatzzeilen in der Apache-Konfiguration nötig:

ProxyPass /top/ http://localhost:8023/
ProxyPassReverse /top/ http://localhost:8023/

Dazu kommt ein passender Ajaxterm-Aufruf (»./ajaxterm.py -ctop -p8023«); wie dann die Ausgabe von »top« im Browser aussieht, zeigt Abbildung 3. Der Parameter »-c« gibt hierbei das Programm an, das im Terminal laufen soll, »-p« legt den Port fest. Die zusätzliche Option »-d« schickt Ajaxterm gleich in den Hintergrund.

Abbildung 3: Keine Anmeldung nötig: Nach dem Anlegen von Zusatzeinträgen in der Apache-Konfiguration und dem Start weiterer Ajaxterm-Prozesse bringt die richtige URL die Ausgabe von »top« ins Browserfenster.

Kein Zugang für jedermann

Die direkte Anbindung eines Programms (wie im Beispiel mit Top) ist allerdings riskant: Hier gehört zumindest in die Apache-Konfiguration eine Username-Passwort-Abfrage, um nicht durch etwaige Shell-Escapes fremden Personen Zugriff zu geben (siehe Kasten “Apache-Passwortschutz”). Hier ist jede zusätzliche Hürde hilfreich.

<Location "/top">
   AuthName        "Ajaxterm"
   AuthType        Basic
   AuthUserFile    /etc/apache2/Usecurity/.htpasswd
   Require user    Username
</Location>

htpasswd /etc/apache2/security/U.htpasswd Username

Außerdem sollte Ajaxterm möglichst mit den Rechten eines unprivilegierten Benutzers laufen, den der Administrator zu diesem Zweck (mit »groupadd ajaxterm; useradd -g ajaxterm ajaxterm«) anlegt. Das Ajaxterm-Skript bietet dazu den Parameter »-u«, der als Argument eine User-ID erwartet. Noch besser ist es, das Programm mit »su ajaxterm Pfad/ajaxterm« zu starten.

Sicher dank One-Time-Passwort

SSL schützt zwar die Session durch Verschlüsselung, aber nicht vor Keyloggern auf Betriebssystemebene. Gerade in Internetcafés ist mit Trojanern und ähnlichen Schädlingen zu rechnen. Das ist aber ein allgemeines Problem und kein spezielles von Ajaxterm; auch das alte Java-Mindterm ist nicht gegen das Abhören der Tastatur geschützt. Hier hilft das One-Time-Password-Verfahren OPIE [7], das Listen von Einmal-Passwörtern erstellt. OPIE ist PAM-kompatibel – es reicht aus, in die Datei »/etc/pam.d/ssh« die folgende erste Zeile einzutragen:

auth     sufficient   pam_opie.so

Theoretisch funktioniert dies auch bei »/bin/login«, denn »/etc/pam.d/login« ist ähnlich aufgebaut, aber das Beispiel SSH zeigt noch zusätzlich, wie die Parameterübergabe funktioniert. Am einfachsten ist es, Ajaxterm mit

./ajaxterm.py -c'ssh user@localhost'

aufzurufen, die Anführungszeichen sind wegen des Leerzeichens wichtig.

OPIE fragt nun nach dem Passwort mit einer bestimmten Nummer (Abbildung 4, in diesem Fall 1999). Es ist zwar zeitraubend, diese Passwörter in einer Liste nachzuschlagen, aber bestimmt sicherer als die Verwendung des immer gleichen Passworts auf wenig vertrauenswürdigen Rechnern im Internetcafé. Ein Keylogger müsste jetzt, um erfolgreich zu sein, sich das Passwort greifen und sich damit sofort selbst anmelden.

Abbildung 4: Einmal-Passwörter mit OPIE schützen den Terminalzugang auch vor Angriffen mit Keyloggern; im Bild erwartet die Anmelderoutine, dass der Anwender das Passwort mit der Nummer 1999 eingibt.

Übrigens hat diese Methode des SSH-Zugangs den Charme, dass kein offener SSH-Port auf dem externen Interface des Servers mehr erforderlich ist. Jeder potenzielle Angreifer müsste dann den gleichen Weg (über das Webinterface) gehen, was zumindest einfache Skriptangriffe abwehrt. Wer auch vor die Login-Sitzung eine Apache-Passwortabfrage (mit einem anderen Benutzernamen und/oder Passwort) setzt, erhöht den Schwierigkeitsgrad weiter.

Langlebige Prozesse

Programme, die sich nicht automatisch nach einer gewissen Zeit beenden (wie das hier als Beispiel verwendete Top), laufen auf dem Server auch dann weiter, wenn der Client das Browserfenster geschlossen hat. Erst wenn der Browser nicht mehr läuft, erkennt die Gegenseite das Ende der Verbindung.

Da eine größere Anzahl nicht mehr genutzter, aber dennoch weiterlaufender Prozesse potenziell zu Performance-Einbußen führen könnte, mindestens aber unschön ist, sollte der Administrator regelmäßig nach übrig gebliebenen Prozessen suchen (lassen), beispielsweise per Cronjob.

Nützlich, aber leicht riskant

Programme wie Screen und Mutt funktionieren dank der VT100-Emulation, aber es ist noch nicht alles perfekt. So gibt es mit der aktuellen Version (0.9) unter anderem das Problem, dass Mutt sich nicht mit [Strg]+[L] zum Refresh der Anzeige bewegen lässt. Außerdem läuft Ajaxterm nicht in jedem Browser: Mit Firefox und Internet Explorer gibt es keine Probleme. Konqueror und Opera zeigen das Terminal an, machen aber viele Fehler. Das scheint kein reines Ajaxterm-Problem zu sein, denn mit dem Thema Browserkompatibilität haben viele Ajax-Programme Schwierigkeiten.

Zum Schluss ein Sicherheitshinweis: Programmierfehler im Ajaxterm-Skript könnten im schlimmsten Fall dazu führen, dass ein Angreifer eine Shell erhält. Letztlich ist Ajaxterm eine Python-Applikation, und aus Skripten in eine Shell zu springen ist häufig einfacher als aus binären Programmen heraus. Deshalb muss jeder Serverbetreiber das Risiko selbst abwägen. (hge)

Copyright © 2002 Linux New Media AG