Die Mär vom ssh, den proxys und verbindungen...

[Kaufmann_eni]

n gudn wünsch ich,

folgendes Problem tritt auf wenn ich versuche von der Arbeit aus auf meinen SuSe 8.2 Rechner (Ruhe ihr Debianneider... ;-P ) zuhause zuzugreifen:

Er bekommt keine Verbindung.... das liegt am Proxy den wir hier haben.

Nun dachte ich mir "Mensch... mein SSH-Server muss doch auch auf anderen Ports lauschen können...".

Nun gibt es in der config-file ja die Zeile in der "Port 22" steht, kann ich das erweitern auf "Port 22 1337"? Muss ich vllt. für den theoretischen Port 1337 ncoh was anderes beachten? Muss ich bei der Syntax aufpassen, ein Komma setzten o.ä.? :mod:

Gibt es eine andere Lösung des Problems durch ein script o.ä.?

Ich wär euch für eure konstruktiven Vorschläge sehr dankbar....

Bye euer Kaufmann

[back.to.roots]

hast du nicht eine firewall am laufen?

dann kannst du doch einfach sagen externer Port 80 > interner Port 22

[Nachtgeist]

man sshd(8):

Port Specifies the port number that sshd listens on. The default is

22. Multiple options of this type are permitted.

[Kaufmann_eni]

die man page hatte ich mir auch angeschaut, nur steht da nicht ob ich irgendwas beachten muss bei der angabe.

funktioniert es wenn ich das "port 22" umänder in "port 22 1337"?

ich hab mit config files sonst weniger zu tun und bin da mit der syntax immer etwas unsicher :-/

[DevilDawn]

grep -i port /etc/ssh/sshd_config

#Port 22

lsof -i -P -n | grep sshd

sshd      1537 root    3u  IPv6   3603       TCP *:22 (LISTEN)

Ändere in:

grep -i port /etc/ssh/sshd_config

Port 22

Port 433

/etc/init.d/sshd restart

Shutting down SSH daemon                                             done

Starting SSH daemon                                                  done

lsof -i -P -n | grep sshd

sshd      2579 root    3u  IPv6  15205       TCP *:433 (LISTEN)

sshd      2579 root    4u  IPv6  15207       TCP *:22 (LISTEN)

Ta-daa...

[Kaufmann_eni]

Na das is doch mal ne Aussage!

Danke :-)

Werds heute nachmittag gleich mal reinklackern :cool:

[DownAnUp]

Wenn da ein Proxy dazwischen hängt wir nur das ändern des Ports nicht viel nützen da der Proxy nur HTTP kann. Mal abgesehen davon das das ja mit absicht nicht geht...

[Terran Marine]

Wenn da ein Proxy dazwischen hängt wir nur das ändern des Ports nicht viel nützen da der Proxy nur HTTP kann. Mal abgesehen davon das das ja mit absicht nicht geht...

putty (ich geh einfach mal von ner Windows-Kiste auf der Arbeit aus, wobei es putty ja mittlerweile auch für linux gibt) kann mit einem SOCKS oder HTTP Proxy umgehen.

Details dazu hier :

http://the.earth.li/~sgtatham/putty/0.53b/htmldoc/Chapter4.html#4.14

Und natürlich stimme ich DownAnUp zu, es hat einen guten Grund, warum sowas NICHT geht, über solch eine SSH-Verbindung kann ich mir nämlich jeden "Mist" in mein Firmen LAN tunneln.

Im Idealfall fragst du einfach deinen zuständigen Admin, er wird die notwendigen Einstellungen vornehmen, wenn er es für richtig hält, dir SSH-Zugriff auf deinen Heimserver zu geben.

Gruß

Terran

[DevilDawn]

Wenn da ein Proxy dazwischen hängt wir nur das ändern des Ports nicht viel nützen da der Proxy nur HTTP kann. Mal abgesehen davon das das ja mit absicht nicht geht...

Jeder zeitgemässe Proxy kann SSL. SSL ist einfach nur TCP, da encrypted. Ich schrieb bereits woanders, wenn dein Service auf einem SSL-Port läuft ist er durch nahezu jeden Proxy Tunnelbar. PuTTY auf Windows und Corkscrew auf Unix erlauben z.b. SSH via SSL-Proxy. Benötigt ist nur das der Proxy die CONNECT Methode für die betroffenen Ports erlaubt - was sie i.d.R. tun, denn du kannst dir ja Denken wie schnell deine User an deinem Schreibtisch stehen wenn sie keine SSL-Seiten aufrufen könnten.

Kurz, wer denkt durch einen Proxy ist er "sicher" was tunneln betrifft liegt falsch. Die Schwierigkeit ist lediglich auch den Endpunkt konfigurieren zu können (müssen).

[Terran Marine]

woanders, wenn dein Service auf einem SSL-Port läuft ist er durch nahezu jeden Proxy Tunnelbar.

Gerade in Windows-basierten Netzwerken verlangt der Proxy nach einer NTLM-Authentifizierung, bevor er einen Zugriff ins Internet freigibt.

Diese Art der Authentifizierung kann afaik kein mir bekannter SSH-Client, sodass es eben nicht möglich ist, einfach per putty durch einen Proxy auf beliebige Dienste zuzugreifen die auf Port 443 hören.

P.S. :

Es gibt mittlerweile auch schon Proxies, welche die SSL-Verbindung auf sich terminieren, die Dateninhalte prüfen und erst dann eine erneute SSL-Verbindung zum richtigen Ziel aufbauen.

Solche Proxies dürften ebenfalls sicher vor der Connect Methode sein, da sie denn Datenstrom auf Content wie z.b. HTTP Befehle prüfen können.

Gruß

Terran

[Schlaubi]

Solche Proxies dürften ebenfalls sicher vor der Connect Methode sein, da sie denn Datenstrom auf Content wie z.b. HTTP Befehle prüfen können.

Nennt man sowas dann Application Level Gateway??? *blödfrag*

[Terran Marine]

Nennt man sowas dann Application Level Gateway??? *blödfrag*

Afaik ist ein Application Level Gateway (tolles Wort) auf OSI Schicht 7 angesiedelt, d.h. das er content-basiert arbeiten und filtern kann (bsp HTML), im Gegenzug zu bsp. einer Paketfilter Firewall, welche nur bis OSI Schicht 4 greift, und den Content der Pakete ingnoriert bzw. einfach nicht versteht.

Diese Eigenschaft wird allerdings von jedem Web-Proxy erfüllt, die diese ja auch nach Webseiten bzw. Inhalt filtern können.

Imho ist Application Level Gateway also nur ein Modewort, und nichts anderes als ein stinknormaler Proxy..

Gruß

Terran

[Schlaubi]

Naja was lernt man nicht alles für Schimpfwörter in der Berufsschule

[taschentoast]

Hi,

Afaik ist ein Application Level Gateway (tolles Wort) auf OSI Schicht 7 angesiedelt, d.h. das er content-basiert arbeiten und filtern kann (bsp HTML), im Gegenzug zu bsp. einer Paketfilter Firewall, welche nur bis OSI Schicht 4 greift, und den Content der Pakete ingnoriert bzw. einfach nicht versteht.

Diese Eigenschaft wird allerdings von jedem Web-Proxy erfüllt, die diese ja auch nach Webseiten bzw. Inhalt filtern können.

Imho ist Application Level Gateway also nur ein Modewort, und nichts anderes als ein stinknormaler Proxy..

Kann ich meines Erachtens nicht ganz so stehenlassen

Ein Proxy ist genau genommen nur ein Stellvertreter, d.h. er benimmt sich für den Client wie ein Server und umgekehrt. Kommen jetzt Zusatzfunktionen wie Caching, Contentfilter, Relays, Virenfilter, etcetc dazu, würd ich von einem Applicationlevel Gateway (ALG) sprechen.

Und weiterhin kann ein Proxy ja auf verschiedenen ISO/OSI Schichten arbeiten, z.B. IP-Proxy, Telnet-Proxy, TCP- oder UDP-Proxy (ja das gibts es!). Packt man dann alles zusammen in ein Gerät/eine Software, heißt das für mich ALG.

Aber es stimmt schon, die beiden Begriffe werden oft und gern vermischt.

taschentoast

[Terran Marine]

Ein Proxy ist genau genommen nur ein Stellvertreter, d.h. er benimmt sich für den Client wie ein Server und umgekehrt. Kommen jetzt Zusatzfunktionen wie Caching, Contentfilter, Relays, Virenfilter, etcetc dazu, würd ich von einem Applicationlevel Gateway (ALG) sprechen.

D.h. ALG = Proxy + Zusatzfunktionen ?

Klingt ganz logisch, aber für mich gibt es da keine richtige Grenze und Trennung. Ich bleib bei Modewort

Squid kann Cachen, auf Content filtern und Benutzer authentifizieren, also ist Squid kein Proxy sondern ein ALG?

Das musst du den Squid-Entwicklern mal erzählen

postfix als Mailgateway mit Mailumschreibungen und Spamfilter ist auch kein einfacher SMTP-Proxy mehr, sondern gleich ein ALG?

Schwammig, schwammig ... damit sollen sich die Consultants und Marketingmenschen auseinander setzen und nicht die Techniker

Gruß

Terran

[taschentoast]

D.h. ALG = Proxy + Zusatzfunktionen ?

Klingt ganz logisch, aber für mich gibt es da keine richtige Grenze und Trennung. Ich bleib bei Modewort

Macht ja nix

Squid kann Cachen, auf Content filtern und Benutzer authentifizieren, also ist Squid kein Proxy sondern ein ALG?

Das musst du den Squid-Entwicklern mal erzählen

Squid selber kann nur Caching, also das was ein Web-Proxy macht (boah wie logisch *selberhau*), aber fürs Authentisieren und Contentfiltern brauchts Zusatzprogramme (LDAP, SMB, PAM und squidguard)

Schwammig, schwammig ... damit sollen sich die Consultants und Marketingmenschen auseinander setzen und nicht die Techniker

Naja, wenn der Salesdroid dann plötzlich ein ALG verkaufen will, der Techie aber nur einen Proxy auf Lager hat. uiuiui.

Aber das wird hier OT, vielleicht sollte man mal die Spezis in de.comp.security.misc oder .firewall fragen.

taschentoast

[Terran Marine]

Squid selber kann nur Caching, also das was ein Web-Proxy macht (boah wie logisch *selberhau*), aber fürs Authentisieren und Contentfiltern brauchts Zusatzprogramme (LDAP, SMB, PAM und squidguard)

Einmal noch.

Reicht eine extra Fähigkeit dann doch nicht aus, um ein ALG zu sein?

(Proxy heisst ja nur Stellvertreter, Caching ist ein Feature)

Ab wieviel und welchen Features darf sich denn ein Proxy ALG nennen? -> Wir werden wieder bös schwammig.

Squid KANN nach Domainennamen filtern, außerdem spricht er SNMP und hat feingranulierbare Access Control Listen.

(Nur um nochmal 3 Features dieses "Proxies" zu nennen )

Also Modewort.

[spree]

Es gibt mittlerweile auch schon Proxies, welche die SSL-Verbindung auf sich terminieren, die Dateninhalte prüfen und erst dann eine erneute SSL-Verbindung zum richtigen Ziel aufbauen.

Kann ich mir nicht vorstellen, dass es sowas gibt. Auf alle fälle wäre dann das prinzip von Zertifikaten und SSL verbindungen auf tiefste hintergangen. Im Endeffekt wäre das eine mitm attack.

Woher hast du diese Infos?

Gruß

Matthias

[Terran Marine]

Kann ich mir nicht vorstellen, dass es sowas gibt. Auf alle fälle wäre dann das prinzip von Zertifikaten und SSL verbindungen auf tiefste hintergangen. Im Endeffekt wäre das eine mitm attack.

Woher hast du diese Infos?

Dann habe ich wohl eben deinen Horizont erweitert ,

war ein Artikel in der LANLine (ist keine tolle Zeitung, ok, haben wir halt im Abo), den ich leider ums Verrecken gerade nicht finde.

Warum Attack, spielt sich doch alles nur innerhalb deines LANs ab, sofern es rechtlich keine Probleme gibt, und alles mit den Mitarbeitern und den Betriebsarzt abgestimmt ist, sehe ich da kein Problem.

Beispielhaft hier ein Link zu dem Proxy äh ALG Webwasher, der das auch kann, die Technik dahinter wird leider nicht erläutert, aber das kann man sich ja vorstellen.

http://webwasher.de/enterprise/products/webwasher_products/ssl_scanner/index.html?lang=<%25=language%25>

Gruß

Terran

(Verdammt sind wir offtopic, sorry Wolle)

[spree]

Dann habe ich wohl eben deinen Horizont erweitert ,

war ein Artikel in der LANLine (ist keine tolle Zeitung, ok, haben wir halt im Abo), den ich leider ums Verrecken gerade nicht finde.

Warum Attack, spielt sich doch alles nur innerhalb deines LANs ab, sofern es rechtlich keine Probleme gibt, und alles mit den Mitarbeitern und den Betriebsarzt abgestimmt ist, sehe ich da kein Problem.

hi,

sorry war länger nicht da.

mich würde der artikel trotzdem interessieren. Es geht da ums prinzip. Man kann nicht einfach sagen dass man sämtliche SSL verbindungen "spoofed" also falsche zertifikate schickt.

Und wenn, dann ist es wirklich grausam und dumm.

meiner meinung nach halt.

grüße

matthias

[Terran Marine]

Man kann nicht einfach sagen dass man sämtliche SSL verbindungen "spoofed" also falsche zertifikate schickt.

Und wenn, dann ist es wirklich grausam und dumm.

Wieso kann man das nicht einfach machen (und sagen)?

Ich bin ein großes Unternehmen, ich will meinen Mitarbeitern Internet erlauben, ich will aber zu 100% kontrollieren können, was derUser sich im Internet ansieht, da ich schlecht HTTPS Verkehr komplett sperren kann, brauche ich eben solche Proxies, welche der Markt natürlich auch anbietet.

Und sorry nochmal, ich finde Artikel nicht, ich tippe aber auf Lanline 07/2004, sollte dir die also in die Hände fallen, nachschlagen.

meiner meinung nach halt.

Ist dein gutes Recht, anderseits kann ich auch die Gegenseite verstehen, stell dir vor deine Mitarbeiter tauschen über HTTPS irgendwelches illegales Zeug, da kannst du ohne so nen Proxy, nicht viel machen.

Gruß

Terran