HTTP/HTTPS via SSH-Tunnel

FragenHTTP/HTTPS via SSH-Tunnel
Martin Broll - Dienstag, 07. Oktober 2003 18:06 Uhr

Hi,

ich habe eine vielleicht etwas ungewöhnliche Aufgabenstellung:

Ich habe einen Proxy-Server der via DSL mit dem Internet verbunden ist.
Auf dem Proxy habe ich SQUID (unter SuSE) im Einsatz.
Die Verbindung von einem Client über den Proxy ins Interent ist ja kein Problem aber: wie kann ich die Verbindung zwischen dem Client und dem Proxy über SSH tunneln? Es werden sowohl Linux- als auch Windows-Clients verwedet.

Es soll dadurch vermieden werden daß man z.B. mit einem Sniffer im internen Netzwerk die Surfgewohnheiten der User ausspioniert.

Vielleicht kann mir ja jemand einen Tip geben.

Danke im Voraus
Martin

2 Antworten
Ulrich Koschella - Dienstag, 07. Oktober 2003 18:21 Uhr

Hallo,

den Tunnel baust Du auf mit:

client> ssh -f -N -L 13128:proxyserver:3128 proxyserver

Jetzt musst Du im Browser auf dem Client die Proxy-Einstellungen
auf loalhost:13128 stellen (vorher vermutlich proxyserver:3128).

Den lokalen Port (13128) kannst Du natuerlich frei waehlen,
wenn auf dem Client kein Proxyserver laeuft, kannst Du auch
lokal 3128 nehmen.

Gruss, Uli

Ulrich Koschella - Dienstag, 07. Oktober 2003 18:38 Uhr

P.S.: Fuer die Windows-Clients nimmst Du am besten PuTTY und traegst den Tunnel unter Connection-SSH-Tunnels ein (Source Port: 13128, Destination: proxyserver:3128, Local).

Uli

Martin Broll - Mittwoch, 08. Oktober 2003 09:07 Uhr

Hallo Uli,

ich habe es nun so wie du es mir beschrieben hast ausprobiert aber es funktioniert leider noch nicht.

Ich habe folgenden Befehl auf meinem Client aufgerufen:

ssh -f -N -L 8888:adsl:8080 adsl (wobei 8888 mein gewünschtes Clientport, 8080 das ProxyPort auf dem Proxyserver „adsl“ ist).

Ich habe auf meinem Client und auf dem Proxy mit lsof -P -n -i geprüft ob die SSH-Verbindungen da sind und ich habe sie auch gefunden.

Wenn ich nun im Browser (Mozilla) als Proxy localhost:8888 eintrage und versuche eine Seite aufzurufen erhalte ich die Meldung (direkt als Browser PopUp): „Document Contains no Data“

In der Konsole erhalte ich folgende Meldung:
„9332: channel 2: open failed: connect failed: Connection refused“

Ich finde leider in keinem anderen Logfile irgend eine Meldung die weiterhelfen könnte.

Hast du vielleicht noch eine Idee wo es da hängen könnte?

Grüße
Martin

Carsten Frank - Mittwoch, 08. Oktober 2003 11:37 Uhr

Hallo Martin,

da fehlt einfach das zweite Ende am Tunnel. Jetzt frage mich mal wie man das macht … Habe ich wenig Ahnung, aber die Info sollte doch zu finden sein.

[1] http://www.linux-community.de/Neues/story?storyid=9523

Ulrich Koschella - Mittwoch, 08. Oktober 2003 12:20 Uhr

Komisch,

ich habe es bei mir extra nochmal ausprobiert.

1. Bist Du sicher, dass squid auf Port 8080 laeuft (3128 ist die Standardeinstellung)? Mach mal auf „dsl“ einen telnet auf localhost 8080:
dsl> telnet localhost 8080
Dann gibst Du irgendwas ein „x“, dann sollte irgendeine Fehlermeldung kommen, in der sich squid „outet“ („Generated… (Squid/…)“).

2. Pruefe die Konfiguration von Deinem squid; hoert er auf „localhost“ und auf „sich selbst“ mit seiner IP im lokalen Netz, oder nur auf die Clients im lokalen Netz? In /etc/squid.conf sollten folgende Zeile vorkommen (oder aehnlich):
acl localhost src 127.0.0.1/255.255.255.255
acl dsl src /255.255.255.255
http_access allow localhost
http_access allow dsl

Ulrich Koschella - Mittwoch, 08. Oktober 2003 12:26 Uhr

Da fehlt kein zweites Ende! Bei mir laeuft’s so. Der „hintere“ Port (hier 8080) ist auf dem remote-Rechner der, auf dem squid laeuft, auf dem „vorderen“ lokalen Port (hier 8888) soll der Browser anfragen.

Uli

Martin Broll - Mittwoch, 08. Oktober 2003 12:55 Uhr

Hallo Uli,

danke für deinen Hinweis!
Das Problem lag tatsächlich bei meiner SQUID-Konfiguration!!

Ich habe meine Konfiguration an deine Angaben angepasst und mußte noch zusätzlich eine Änderung bei der „http_port“-Angabe machen. Ich hatte dort nämlich die IP des Interfaces sowie das Proxyport angegeben. Ich habe nun nur mehr das Port dort stehen und siehe da – es funktioniert!

Vielen Dank für deine Hilfe!!!!!
LG
Martin

Harald Milz - Mittwoch, 08. Oktober 2003 13:02 Uhr

Und warum nicht SSL? stunnel kann das so ziemlich genau so, und existiert in einer Windows-Portierung, die auch als Service laufen kann.

Martin Broll - Mittwoch, 08. Oktober 2003 13:40 Uhr

Hallo Harald,

danke für den Hinweis.
Ich werde mir die SSL-Variante auf jeden Fall auch ansehen.
Angenehm an der SSH-Sache ist, zumindest aus meiner Sicht, daß ich für eine schnelle Lösung nichts installieren brauche. Auf meinem Client geht es ja gut da er unter LINUX läuft.

Die SSH-Sache muß ich mir für Windows aber erst noch ansehen.
Schaun mer mal 😉

Thanks a lot
Martin

Harald Geiger - Mittwoch, 08. Oktober 2003 14:00 Uhr

Hallo Martin!

Auch ich würde in diesem Fall ’stunnel‘ dem SSH-Port-Forwarding vorziehen. Denn die SSH-Methode hat einen gravierenden Nachteil: Falls nicht eh schon jeder Benutzer, der surfen können soll, einen SSH Zugang zum Server hat, musst Du das jetzt erlauben.

Und mit interaktiven Benutzern ist es für den Admin ungleich schwerer, das System einigermassen sicher zu halten, als ohne. Die Aufgabe, die Möglichkeiten der Benutzer auf die erforderlichen Tätigkeiten zu beschränken, ist nicht trivial (vernünftige Rechtevergabe, chroot, restricted shell, ulimits, pam_limits, bis hin zu Access Control Systemen wie RSBAC, selinux, LIDS, Medusa DS9, RBAC, usw).

Harald

Ulrich Koschella - Mittwoch, 08. Oktober 2003 14:58 Uhr

Klar gibt es allgemeinere Tunnel als den SSH-Tunnel, aber solange es nur um einen Port geht, find‘ ich SSH nicht so schlecht. Nicht jeder Benutzer muss SSH-Zugang haben; root kann den Tunnel z.B. waehrend dem Booten schon initiieren; dann kann jeder lokale Benutzer unter dem Pseudo-Proxy „localhost:8888“ surfen.

Uli

Harald Geiger - Donnerstag, 09. Oktober 2003 00:54 Uhr

Hallo Ulrich!

root kann den Tunnel z.B. waehrend dem Booten schon initiieren; dann kann jeder lokale Benutzer unter dem Pseudo-Proxy „localhost:8888“ surfen.

BIST DU DES WAHNSINNS? 😉
Du schlägst vor, Passphrase-lose Private Keys, die den Zugang zu einem Serversystem ohne Passwort ermöglichen, auf inhärent unsichere Clientsysteme zu verteilen?

Kurze Betrachtung von Martins Szenario und der vorgeschlagenen Lösung:

Martin möchte die Verbindungen der Webbrowser auf den Arbeitsplatzrechnern zum Proxy auf dem Server verschlüsseln, um die Benutzer vor dem Ausspionieren ihres Datenverkehrs durch Sniffen des Netzwerkverkehrs im lokalen Netzwerk zu schützen. Insbesondere bei einem geswitchten Netzwerk (vom dem ich jetzt mal ausgehe, wer hat den noch HUBs im Einsatz?) geht er also von internen Angreifern mit gewissem technischen Know-How und krimineller Energie aus.

Bei Deinem Vorschlag baut jeder Arbeitsplatzrechner beim Booten eine SSH-Verbindung und den genannten SSH-Tunnel zum Server auf. Dabei wird weder Passwort noch ein Passphrase-geschützter Private Key verwendet, da diese Verbindung ja automatisch aufgebaut werden soll. Jeder Arbeitsplatzrechner verwendet für den Zugriff auf den Server den geichen Account (z.B. „tunnel“), da Du ja nicht für jeden Benutzer einen Account anlegen willst.

Da nun so ein Arbeitsplatzrechner in aller Regel physikalisch nicht gegen unbefugten Zugriff gesichert ist, kann ein Benutzer prinzipiell die volle Kontrolle über seinen Rechner erlangen (Bootparameter, Booten von Floppy, CD-ROM, Netzwerk, …, Einbau der Festplatte in einen anderen Rechner, usw.). Insbesondere kann er Kenntnis des Private Keys erhalten und damit selbst SSH-Verbindungen zum Server aufbauen.

Da es wie gesagt knifflig ist, die Möglichkeiten eines SSH-Benutzers einzuschränken, gehe ich mal vom Worst-Case aus, in dem der Benutzer „tunnel“ doch beliebigen Code ausführen kann. Dann kann er über die ptrace() Schnittstelle die sshd-Prozesse der einzelnene SSH-Tunnel überwachen, da diese ja alle unter der selben Benutzerkennung „tunnel“ laufen, und somit den Netzwerktraffic zum Proxy doch wieder mitsniffen.

Harald

Deine Antwort