Gefahr durch SSH: Portforwarding außer Kontrolle

Gängige Sicherheitssoftware, etwa eine Firewall mit Stateful Inspection, kann hier nichts ausrichten.
Die meisten Sicherheitslösungen sind nur auf den Schutz von Servern im
Unternehmen gegen Clients von außen ausgelegt.

Dreht der Angreifer den Spieß um und stellt den Server ins Internet,
während ein Client im Intranet agiert, funktionieren die gängigen
Erkennungsmethoden nicht. Die IP-Adresse, die beim kompromittierten Server eingeht, ist eine
offiziell beim Unternehmen bekannte Intranet-Adresse eines
Mitarbeiter-PCs. Das ist nicht weiter verdächtig.

Eine Sperre für abgehende Verbindungen via SSH-Port 22 kann der
Angreifer umgehen, indem er seinen SSH-Server auf einem anderen, frei
wählbaren Port, betreibt. Im Zweifel wählt er einfach Port 80, muss dann
aber einen HTTP-Zugang auf einen anderen Port verlegen, beispielsweise
Port 81. In diesem Fall muss der Angreifer von außen der URL den Zusatz ":81"
hinzufügen.

Verhindern kann man dies nur durch Auswertung des
SSH-Handshake-Protokolls auf allen TCP-Ports. Das ist extrem
ressourcenaufwendig und führt zwangsläufig dazu, dass kein Mitarbeiter
SSH nutzen kann. Dies lässt sich wiederum dadurch unterlaufen, dass der
Angreifer selbstprogrammierte Portforwarder auf einem öffentlichen
Server implementiert.

Nicht einmal
IP-Sec
bringt einen wirksamen Schutz gegen Portforwarding. Da der
missbräuchlich genutzte Rechner die TCP-Verbindung zum kompromittierten
Server aufbaut, verfügt er als offizieller Arbeitsplatzrechner auch über
die nötigen
X.509-Zertifikate.