Gefahr durch SSH: Portforwarding außer Kontrolle

SSH gilt als besondere sichere Lösung für Fernzugang und Filetransfer. ZDNet zeigt, warum ausgerechnet durch diese Technologie Gefahren für die IT-Sicherheit drohen - selbst für Unternehmen, die keinen SSH-Server betreiben.

Aufgrund der offenen Gestaltung von
SSH lässt sich jeder TCP-basierte Dienst
durch eine SSH-Verbindung tunneln. Dies wird gern genutzt, um
unverschlüsselte Dienste, etwa
SMTP
oder VNC, in sicherer Form anbieten zu können.

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.

Über so genannte Gateway-Ports bietet SSH den Clients Zugang zu ihren
Servern in gewohnter Weise, ohne dass Software angepasst werden
muss. Das schafft hohe Kompatibilität, aber auch die Möglichkeit, einen
Intranet-Zugang zu einem Server unbemerkt ins Internet zu verlegen.

Portforwarding und Gateway-Ports lassen sich per Konfigurationsdatei ein-
oder ausschalten. Zugang zur Datei /etc/ssh/sshd_config hat nur
der Benutzer root. Scheinbar eine einfache Aufgabe für den Praktikanten
der Security-Abteilung – wenn da nicht ein kleiner Haken wäre.

Mittels zweier Parameter lässt sich SSH leicht zu einem Zugangsserver für das Intranet machen.
Bild 1: Mittels zweier Parameter lässt sich SSH leicht zu einem Zugangsserver für das Intranet machen.

In einem Intruder-Szenario steht der SSH-Server nicht im Intranet des
Unternehmens, sondern mit öffentlicher IP-Adresse im Internet. Seine
Kontrolle durch die IT-Security ist nicht möglich.

Dank Virtualisierung lässt sich ein Linux-Root-Server mit fester IP-Adresse von einem Angreifer
kostengünstig anmieten. Einsteigerpakete kosten weniger als zehn Euro pro Monat.
Lockangebote gibt es bereits für unter drei Euro. SSH ist beim angemieteten
Root-Server grundsätzlich
vorinstalliert und hochgefahren.

Verdächtig machen sich Privatpersonen durch die Anmietung kaum, da sich solche Rechner
als Multiplayer-Online-Game-Server stetig steigender Beliebtheit
erfreuen.

Themenseiten: Hacker, Security-Praxis

Fanden Sie diesen Artikel nützlich?
Content Loading ...
Whitepaper

ZDNet für mobile Geräte
ZDNet-App für Android herunterladen Lesen Sie ZDNet-Artikel in Google Currents ZDNet-App für iOS

Artikel empfehlen:

Neueste Kommentare 

4 Kommentare zu Gefahr durch SSH: Portforwarding außer Kontrolle

Kommentar hinzufügen
  • Am 11. Februar 2008 um 14:37 von ssh-nutzer

    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?

    • Am 11. Februar 2008 um 15:35 von N-)

      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.

      • Am 11. Februar 2008 um 19:45 von Christoph H. Hochstätter

        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

  • Am 4. März 2011 um 20:51 von The One

    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?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *