ist, können Administratoren Hilfe von recht ungewohnter Seite in
Anspruch nehmen.
Webcrawler,
die von Suchmaschinen und
Marktanteilsmessern,
aber auch Spammern eingesetzt werden, entpuppen sich als mögliche Falle für
einen Portforwarding-Angreifer.
Jede noch so bedeutungslose Website bekommt mehrmals am Tag Besuch von
einem Webcrawler und kann ein paar "Klicks" für sich verbuchen. Die
Webcrawler machen sich natürlich keine Mühe, einen Angreifer
per DNS-Spoofing zu schützen, von dem sie nicht einmal wissen, dass er existiert.
Vielmehr besuchen sie die Website unter der IP-Adresse oder der
DNS-Bezeichnung, die der Hoster dem Server gegeben hat. Die bleibt
bestehen, auch wenn der Kunde eigene DNS-Namen hinzufügt. Finden sich in
der Log-Datei Namen, die nicht aus dem eigenen Intranet stammen, so ist
dies ein sicherer Hinweis auf eine Portforwarding-Attacke.
Fast alle Suchmaschinen besuchen Websites immer mit einem
User-Agent-String, der die Bezeichnung der Suchmaschine enthält. Dies
ermöglicht Websitebetreibern, echte Besucher von Suchmaschinen zu
unterscheiden.
Ein ganz offensichtliches Sicherheitsproblem liegt vor, wenn der hoch
schützenswerte Intranet-Server plötzlich Besuch von
Google erhält.
Eine Sache, die eigentlich leicht zu entdecken ist.
Das Entdecken anderer Zugänge, etwa per Remote Desktop, ist auf diese
Weise aber nicht möglich. Professionelle Angreifer verwenden zudem für den
HTTP-Zugang nicht Port 80, um den zufälligen Besuch einer Suchmaschine
zu verhindern. Hier hilft nur die Auswertung des Nutzerverhaltens,
um beispielsweise nachzuvollziehen, warum ein Mitarbeiter ungewöhnlich
fleißig ist und scheinbar 24 Stunden am Tag arbeitet. Dieses Vorgehen
ist jedoch bei Betriebsräten nicht gerade beliebt und obendrein
mit erheblichen heuristischen Unsicherheiten behaftet.
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?