Da auf vielen Kisten in den Schul- und Firmennetzwerken eh Windows läuft und man nicht immer ein Notebook dabei hat oder damit nicht ins Netz will/kann empfehle ich das Browser Plugin Mindterm. Einfach Proxy und IP/DNS und SSH-Port eingeben (ich habe auch die Erfahrung gemacht, dass meistens nur 443 funktioniert, wenn überhaupt https zugelassen wird) und los gehts. http://www.oit.duke.edu/sa/security/ssh.html
Von Vinzenz Hopfgartner am Fr, 5. September 2003 um 07:35 #
Wenn ich wie im Artikel beschrieben einen http proxy verwenden will, bekomme ich folgende Fehlermeldung: /bin/sh: line 1: exec: connect: not found Lasse ich das connect weg dann kommt er zwar etwas weiter aber Verbindung bekommt er keine.
DEBUG: (none) DEBUG: relay_method = HTTP (3) DEBUG: relay_host=proxy-server DEBUG: relay_port=8080 DEBUG: relay_user=proxy-user:proxy-pwd DEBUG: local_type=stdio DEBUG: dest_host=ssh-ziel DEBUG: dest_port=22 DEBUG: Program is $Revision: 1.68 $ DEBUG: resolving host by name: ssh-ziel DEBUG: failed to resolve locally. DEBUG: connecting to proxyserver:8080 DEBUG: begin_http_relay() DEBUG: >>> "CONNECT ssh-ziel:22 HTTP/1.0\r\n" DEBUG: >>> "\r\n" DEBUG: <<< "HTTP/1.0 403 Forbidden\r\n" DEBUG: http proxy is not allowed. FATAL: failed to begin relaying via HTTP. ssh_exchange_identification: Connection closed by remote host
Ich habe die Erfahrung gemacht, dass in vielen Schul- und Firmennetzwerken Windows eingesetzt wird, man nicht immer einen Laptop an der Hand hat oder damit nicht ins Netz will/kann. Für solche Fälle empfehle ich das Browser Plugin Mindterm. Einfach Ziel IP/DNS, Proxy und ssh Port (in den meisten Fällen geht nur wie o.g. 443, also einfach ssh auf 443 legen. Man kann ssh ja auch auf mehreren Ports laufen lassen, damit es im eigenen Netz nicht umständlich wird) eintragen und los gehts. http://www.oit.duke.edu/sa/security/ssh.html
Bleibt noch anzumerken, das das Tunneln von SSH durch HTTPS meist nicht gewünscht ist, weil sonst ssh direkt freigegeben wäre. Das ist also ein Verstoss gegen Sicherheits-Regeln die, je nach Umsetzung, ernsthafte Konsequenzen haben können. Besonders Firmen können da sehr empfindlich reagieren.
der ssl-prxy entschlüsselt, leitet an einen virenscanner (oder etwas anderes weiter, bekommt es danach zurück, verschlüsselt alles wieder... für den client ist es ein Server, für den ziel-server ist es ein client, eben ein proxy...
Von Gernot Tenchio am Fr, 5. September 2003 um 12:02 #
Das allerdings verstösst gegen jegliche Datanschutzrichtlinien und stört massiv die Vertrauensstellung zwischen Server und Client. Man könnte von einer Man in the Middle Atacke reden.
Ein anstaendiger Proxy erkennt auch so ob er als Relay missbraucht wird.
Von Sven Geggus am Fr, 5. September 2003 um 19:53 #
Das hab ich nie verstanden wie das gehen soll. Dazu müsste der Proxy doch Zertifikate haben, die auf alle Domains ausgestellt wurden für die er Proxy sein will. Andernfalls würde mich doch der Browser wegen falschem CN anmeckern oder sehe ich da jetzt was falsch?
SSL ist ja gerade designed Man in the middle Attacks wie sie ein solcher Proxy darstellt zu verhindern.
Das ist ein ziemlicher Schwachsinn. Wenn das so einfach möglich wäre, könnte man eine solche Verbindung ja an beliebiger Stelle kompromittieren. Die Zertifikate und ihre Keys wären damit komplett sinnlos und man könnte gleich wieder Telnet nehmen.
Wer natürlich beim Verbindungsaufbau den Fingerprint des falschen Servers akzeptiert, der ist selber schuld.
Es gibt Firmen, die ein (imho berechtigtes) Interesse daran haben, daß auch über https-geschützte Verbindungen (bspw. freemailer) keine virenverseuchten downloads ins firmennetz gelangen können. der umstand, daß solche lösungen im produktiven betrieb sind, ist eine Tatsache, unabhängig ob man sie für möglich hält oder nicht...
IMHO kann snort (bzw. fast jedes IDS) diese Verbindungen erkennen. Also, nicht in falscher Sicherheit wiegen. Firmen reagieren empfindlich (die einen mehr als die anderen) auf so etwas. Wahrscheinlich ist jeder Admin böse bzw. amüsiert wenn so etwas gemacht wird. Mein Tip, mit offenen Karten spielen, erhöht die eigene Reputation und vielleicht kann man ja mit dem Admin reden. Andererseits, ist man ja in der Firma um zu arbeiten, und nicht um seine privaten Server zu administrieren ;-).
Von Peter Woelfel am Fr, 5. September 2003 um 09:28 #
Das Tool transconnect macht prinzipiell das gleiche, nur dass es nicht auf ssh beschraenkt ist. Es ist eine shared library, die man mit der Variable LD_PRELOAD einbinden muss. Dann kann praktisch alles, was dynamisch gelinkt ist, ueber einen https-Proxy arbeiten (sofern dieser das unterstuetzt ;-)).
Da ich auf Arbeit nur eine Windows Kiste habe, benutze ich dafür GNU httptunnel (http://www.nocrew.org/software/httptunnel.html)
Das Teil tunnelt beliebige HTTP Verbindungen (nicht nur ssh) (auch) über Proxy-Server und funktioniert bei mir hervorragend. Es gibt sowohl den Client als auch den server für Linux, Windows und noch ein paar andere Betriebssysteme.
Und meines Wissens sind solche Verbindungen nicht von normalen HTTP Verbindungen zu unterscheiden, da es sich um normale HTTP Anfragen handelt. Vielleicht wenn man mit viel Aufwand den Inhalt der HTTP Daten untersucht, kommt ein erfahrener Admin vielleicht dahinter, aber welcher Admin in der Firma hat schon so viel Zeit?
Ist wahr, aber ob ich jetzt meinen sshd auf 443 umkonfigurieren muß, oder ne httptunnel Gegenstelle einrichten muß, ist mir vom administrativen Aufwand wirklich egal.
wie genau funktioniert das ganze? kann leider nicht so gut englisch!
in der cmd konsole auf dem server gebe ich 1zu1 folgendes ein:
hts --forward-port localhost:22 80
oder muß ich noch anpassungen an diesem befehl vornehmen? wo oder wie kann ich sehen, ob hts richtig gestartet wurde und auch läuft? und vorallem mit welchem befehl kann ich diesen auch stoppen?
Von Sven Geggus am Fr, 5. September 2003 um 19:56 #
Was ich mir in diesem Zusammenhang schon mehrfach überlegt habe. Wäre es eigentlich möglich über einen normalen Webserver (z.B. Apache mit mod-proxy) sowas transparent durchzureichen?
Oft hat man ja nur eine IP zur Verfügung und kann schlecht auf 443 sowohl apache als auch ssh laufen lassen.
ssh bräuchte man dann natürlich nicht mehr wirklich, telnet würde dann ausreichen.
warum willst du genau das abschaffen was dir ssh bietet? ;)
Sobald du auf einen Server per ssh connecten kannst, kann ssh für dich die Ports der beiden Rechner beliebig tunneln. Du greifst dann lokal auf dem client auf localhost:port zu und ssh leitet die zugriffe dann auf einen beliebigen Port (oder host) vom server aus weiter. Schau dir mal die man page an, bei putty für windows kann man da auch schön einstellen.
Von Sven Geggus am Sa, 6. September 2003 um 12:22 #
Von mir aus auch ssh. Aber so einen pseudo SSL Verbindung über die man ssh macht kann man immer noch erkennen. Normales https hingegen erkennt niemand mehr. Und da doppelt verschlüsseln Unsinn ist würde halt wieder sowas wie Telnet reichen.Oder ssh mit cipher=non, aber das haben die Openssh Jungs ja unbedingt ausbauen müssen.
Wenn der Verbindungsaufbau nicht klappt, benutzt man einfach die Option '-d' von connect. Dann sieht man gleich, wo das Problem liegt und muß nicht im Nebel stochern.
Für's Debugging 'root' zu werden, oder die globale ssh_config zu ändern ist völlig unnötig.
nur so als Tip am Rande
/bin/sh: line 1: exec: connect: not found
Lasse ich das connect weg dann kommt er zwar etwas weiter aber Verbindung bekommt er keine.
DEBUG: (none)
DEBUG: relay_method = HTTP (3)
DEBUG: relay_host=proxy-server
DEBUG: relay_port=8080
DEBUG: relay_user=proxy-user:proxy-pwd
DEBUG: local_type=stdio
DEBUG: dest_host=ssh-ziel
DEBUG: dest_port=22
DEBUG: Program is $Revision: 1.68 $
DEBUG: resolving host by name: ssh-ziel
DEBUG: failed to resolve locally.
DEBUG: connecting to proxyserver:8080
DEBUG: begin_http_relay()
DEBUG: >>> "CONNECT ssh-ziel:22 HTTP/1.0\r\n"
DEBUG: >>> "\r\n"
DEBUG: <<< "HTTP/1.0 403 Forbidden\r\n"
DEBUG: http proxy is not allowed.
FATAL: failed to begin relaying via HTTP.
ssh_exchange_identification: Connection closed by remote host
Mein Eintrag in der ~/.ssh/config
Host ssh-ziel
ProxyCommand /usr/local/bin/sconnect -4 -d -H proxy-usr:proxy-pwd@proxyip:8080 %h %p
http://www.oit.duke.edu/sa/security/ssh.html
betreibt, geht das schon...
virenscanner (oder etwas anderes
für den client ist es ein Server, für den ziel-server ist es ein client, eben ein proxy...
siehe
http://www.iccgmbh.com/produkte/TOMMY.htm
Ein anstaendiger Proxy erkennt auch so ob er als Relay missbraucht wird.
Gruss, Gernot
SSL ist ja gerade designed Man in the middle Attacks wie sie ein solcher Proxy darstellt zu verhindern.
Sven
Wer natürlich beim Verbindungsaufbau den Fingerprint des falschen Servers akzeptiert, der ist selber schuld.
Es ist eine shared library, die man mit der Variable LD_PRELOAD einbinden muss. Dann kann praktisch alles, was dynamisch gelinkt ist, ueber einen https-Proxy arbeiten (sofern dieser das unterstuetzt ;-)).
http://transconnect.sourceforge.net/
cu.
peter
Das Teil tunnelt beliebige HTTP Verbindungen (nicht nur ssh) (auch) über Proxy-Server und funktioniert bei mir hervorragend. Es gibt sowohl den Client als auch den server für Linux, Windows und noch ein paar andere Betriebssysteme.
Und meines Wissens sind solche Verbindungen nicht von normalen HTTP Verbindungen zu unterscheiden, da es sich um normale HTTP Anfragen handelt. Vielleicht wenn man mit viel Aufwand den Inhalt der HTTP Daten untersucht, kommt ein erfahrener Admin vielleicht dahinter, aber welcher Admin in der Firma hat schon so viel Zeit?
oder transconnect arbeiten auch ohne entsprechende Gegenstelle.
iptables -t nat -A PREROUTING -p tcp --dport 443 -j REDIRECT --to-port 22
reicht! Am ssh muss man dann nix drehen!
wie genau funktioniert das ganze? kann leider nicht so gut englisch!
in der cmd konsole auf dem server gebe ich 1zu1 folgendes ein:
hts --forward-port localhost:22 80
oder muß ich noch anpassungen an diesem befehl vornehmen?
wo oder wie kann ich sehen, ob hts richtig gestartet wurde und auch läuft? und vorallem mit welchem befehl kann ich diesen auch stoppen?
danke
Oft hat man ja nur eine IP zur Verfügung und kann schlecht auf 443 sowohl apache als auch ssh laufen lassen.
ssh bräuchte man dann natürlich nicht mehr wirklich, telnet würde dann ausreichen.
Sven
Sobald du auf einen Server per ssh connecten kannst, kann ssh für dich die Ports der beiden Rechner beliebig tunneln. Du greifst dann lokal auf dem client auf localhost:port zu und ssh leitet die zugriffe dann auf einen beliebigen Port (oder host) vom server aus weiter. Schau dir mal die man page an, bei putty für windows kann man da auch schön einstellen.
Sven
> $ su -
> $ wget http://www.imasy.or.jp/~gotoh/connect.c
> $ gcc -o sconnect connect.c
> $ cp sconnect /usr/local/bin
> $ nano ~/.ssh/config
$ wget http://www.imasy.or.jp/~gotoh/connect.c
$ gcc -o sconnect connect.c
$ su -c "cp sconnect /usr/local/bin"
$ nano ~/.ssh/config
Statt nano gibt man den Lieblingseditor ein (joe, vi, emacs, kwrite, ...)
Für's Debugging 'root' zu werden, oder die globale ssh_config zu ändern ist völlig unnötig.