SSH en SSL hetzelfde door een proxy?

[BSeB]

ik zit hier achter een proxy, inderdaad dit is weer zo'n proxy verhaal.

Als ik goed op de hoogte ben is dit een Squid proxy. Ik kan internetten, dus dat is het probleem niet. Ik probeer met ssh verbinding te maken naar port 22 maar dat werkt niet want dan krijg ik de melding dat het niet wil omdat deze poort daarvoor niet geschikt is. Hij geeft aan dat dit meestal via port 443 gebeurd, dus heb ik op mijn server een forward ingesteld zodat deze op port 443 accepteerd en deze zelf doorstuurd naar 22.

Nu kan ik wel daarnaar connecten, maar de server verbreekt de verbinding (client-side), dit vind ik erg raar ik krijg ook geen login oid, mijn vraag is nu:

- Kan een proxy het verschil zien tussen een SSL en een SSH connectie
- Moet ik ergens iets instellen zodat ik wel kan verbinden!?

Ik zou erg graag verbinding willen kunnen maken

[Keiichi]

de proxy ziet iig aan de hand van de poort het verschil tussen SSL en SSH

Waarschijnlijk zul je de configuratie van Squid even aan moeten passen om langs poort 22 te ssh-en als ie dat al ondersteund. (5 jaar geleden dat ik voor het laatst er mee gewerkt heb )

[BSeB]

Nee, ik zei al dat ik een forward had ingesteld op mijn eigen server en dus naar 443 kan verbinden. Mijn iptables firewall forward dan naar port 22 en kan dus connecten naar ssh.

Vanaf een normale pc werkt dit, dus zonder proxy. Met een proxy echter wil dit niet.

Ik maak dus voor ssh verbinding naar 443!

[FireDrunk]

Ja een proxy kan aan de hand van de pakketjes die er over een bepaalde poort gaan, zien om wat voor type verkeer het gaat. Het verschil tussen HTTPS (443) en SSH(22) is welliswaar lastig te zien, omdat dit allebei encrypted verkeer is. Dus zal er wel een hele dikke dure firewall achterzitten (ik heb geen ervaring met Squid, en weet dus ook niet of deze dit kan)

je zou ook nog kunnen proberen om SSH te laten luisteren op port 80, daar word meestal vrijwel alle verkeer toegelaten.

[BSeB]

Hmz, dat moet ik is bekijken hoe ik dat doe. Want op 80 draait nu mijn webserver voor mail.

Ik kan namelijk wel connecten nar een port 5902 of 5802 voor vnc (verifieren kan niet omdat vnc geen proxy ondersteund)

Dus verbindingen naar buiten gaan wel, evenals ftp verbindingen.

[FireDrunk]

probeer eens een portscan op je proxy, dan weet je welke poorten openstaan, en kan je ze gewoon allemaal proberen , en dan kijken op welke poort jou SSH verbinding werkt.
niet de "netste" manier, maar als het werkt

[BSeB]

In dit geval heb je het over een portscanner die via de proxy naar alle poorten naar buiten (internet wil connecten)

Dus hij begint naar de proxy en wil dan naar port 1 connecten tot 65000 als ik het goed begrijp.
Maar tools als nmap heb ik niks aan, even zoeken naar die tools.

Dus van intern naar extern checken en kijken welke poorten open staan.

Andersom heeft weinig zin.

[FireDrunk]

je moet ook geen scan naar huis doen, maar echt een directe scan op de proxy zelf.
je pakketten hoeven niet aan te komen, maar als de proxy een verbinding op die poort toestaat, weet je gelijk of de poort openstaat, en kun je deze daarna testen met je SSH verbinding.

[Puch-Maxi]

Dit zou gewoon moeten werken, SSH op poort 443 (wel proxy instellen in putty oid)
Ik zit hier ook achter een transparante squid proxy die werkelijk alles blocked behalve http en https
maar hij laat SSH gewoon door op 443.

[Janoz]

Ook heir hebben we een firewall en ook hier kan ik alsnog via 443 ssh-en naar huis. Er is echter wel verschil te zien tussen een ssh connectie en een webrequest. Een https request verstuurd eerst data (het request) en krijgt vervolgens een bak data terug (response) en de verbinding wordt gesloten. Bij ssh wordt er constant verstuurd en ontvangen. Een duurdere en strak afgestelde firewall kan dit herkennen en vervolgens de boel afsluiten.

[BSeB]

Thijs, ik snap wat je bedoelt:

Client -> Proxy 8080 -> port

En dat zal met een tooltje moeten neem ik aan, dus vanaf de client. Welke programma's zijn hier geschikt voor, want ik ben aan het zoeken maar kan 123 niet iets normaals vinden wat gewoon te gebruiken is, want ik zal een proxy moeten kunnen instellen dan een portscan moeten doen.

Proxy grabber 2 zou zoiets moeten kunnen, maar dat is allemaal trail.

Of moet ik een externe portscan uitvoeren, maar ik begrijp dat dat niet de bedoeling is.

Hier zie ik wat betreffende de techniek:

http://www.auditmypc.com/...ingroom/port_scanning.asp

Een https request verstuurd eerst data (het request) en krijgt vervolgens een bak data terug (response) en de verbinding wordt gesloten. Bij ssh wordt er constant verstuurd en ontvangen. Een duurdere en strak afgestelde firewall kan dit herkennen en vervolgens de boel afsluiten.

Is dit te omzeilen? Zodat dit op dezelfde manier gaat als bij https

[ Voor 23% gewijzigd door BSeB op 26-03-2007 10:26 ]

[FireDrunk]

thijs_cramer schreef op maandag 26 maart 2007 @ 08:54:
Ja een proxy kan aan de hand van de pakketjes die er over een bepaalde poort gaan, zien om wat voor type verkeer het gaat. Het verschil tussen HTTPS (443) en SSH(22) is welliswaar lastig te zien, omdat dit allebei encrypted verkeer is. Dus zal er wel een hele dikke dure firewall achterzitten (ik heb geen ervaring met Squid, en weet dus ook niet of deze dit kan)

je zou ook nog kunnen proberen om SSH te laten luisteren op port 80, daar word meestal vrijwel alle verkeer toegelaten.

Janoz schreef op maandag 26 maart 2007 @ 10:20:
Ook heir hebben we een firewall en ook hier kan ik alsnog via 443 ssh-en naar huis. Er is echter wel verschil te zien tussen een ssh connectie en een webrequest. Een https request verstuurd eerst data (het request) en krijgt vervolgens een bak data terug (response) en de verbinding wordt gesloten. Bij ssh wordt er constant verstuurd en ontvangen. Een duurdere en strak afgestelde firewall kan dit herkennen en vervolgens de boel afsluiten.

like he said

BSeB schreef op maandag 26 maart 2007 @ 10:24:
Thijs, ik snap wat je bedoelt:

Client -> Proxy 8080 -> port

En dat zal met een tooltje moeten neem ik aan, dus vanaf de client. Welke programma's zijn hier geschikt voor, want ik ben aan het zoeken maar kan 123 niet iets normaals vinden wat gewoon te gebruiken is, want ik zal een proxy moeten kunnen instellen dan een portscan moeten doen.

Proxy grabber 2 zou zoiets moeten kunnen, maar dat is allemaal trail.

Of moet ik een externe portscan uitvoeren, maar ik begrijp dat dat niet de bedoeling is.

Hier zie ik wat betreffende de techniek:

http://www.auditmypc.com/...ingroom/port_scanning.asp

volgens mij begrijp je toch niet helemaal wat ik bedoel,
als je je proxy scant op openstaande poorten (moet de proxy je niet blocken omdat je hem scant maar je kan het proberen) weet je welke poorten openstaan,

Dus eerst:

Client <-> proxy Poort scannen

daarna

vul bij ? de gevonden poort in
Client - - - (proxy) - - - Thuis (poort ?)

en dan gewoon proberen tot het werkt...

[ Voor 32% gewijzigd door FireDrunk op 26-03-2007 10:28 ]

[Verwijderd]

Puch-Maxi schreef op maandag 26 maart 2007 @ 10:15:
Dit zou gewoon moeten werken, SSH op poort 443 (wel proxy instellen in putty oid)
Ik zit hier ook achter een transparante squid proxy die werkelijk alles blocked behalve http en https
maar hij laat SSH gewoon door op 443.

Nee hoor, dat hoeft helemaal niet te werken. hangt er maar helemaal vanaf hoe "scherp" de proxy ingesteld is.

Het enige wat je bij een "scherp ingestelde" proxy kan doen is HTTP tunneling op poort 80. Maar ja, als je thuis al een webserver draait lukt dat ook niet.

[BSeB]

Dit is de error als ik op 22 probeer te verbinden:

Proxy error :502 Proxy Error ( The specified Secure Sockets Layer (SSL) port is not allowed. ISA Server is not configured to allow SSL requests from this port. Most web browsers use port 443 for SSL requests. )

volgens mij begrijp je toch niet helemaal wat ik bedoel,
als je je proxy scant op openstaande poorten (moet de proxy je niet blocken omdat je hem scant maar je kan het proberen) weet je welke poorten openstaan,

Dus eerst:

Client <-> proxy Poort scannen

daarna

vul bij ? de gevonden poort in
Client - - - (proxy) - - - Thuis (poort ?)

en dan gewoon proberen tot het werkt...

Heb je enig idee wat voor programma dit kan? Ik zie alleen de webveries of eraan verwant?>

[ Voor 48% gewijzigd door BSeB op 26-03-2007 10:35 ]

[Rolfie]

Als ik goed op de hoogte ben is dit een Squid proxy.

ISA Server is not configured to allow SSL requests from this port.

Klopt dus niet helemaal.

Maar waarschijnlijk heeft de systeem beheerder een bepaalde redenen bedacht om geen SSH verkeer door te laten. Misschien moet je gewoon aan hem vragen of die poort open mag. Wat je nu aan het doen bent, is de beveiliging omzeilen, en daar wordt een systeem beheerder meestal niet zo blij van. Ik zou zeggen ga met hem de discussie aan, en kijk of je de port open krijgt.

[FireDrunk]

moet je bij Putty ook zelf de proxy opgeven? of gaat dit automagisch?
als je dit niet hoeft te doen, is ISA ingesteld als gateway (automagische proxy) en als je zelf prut moet invullen is het een proxy, want als ik de foutmelding bekijk, vraag jij nu aan de ISA server of hij een HTTPS verbinding wil opzetten met jou thuis server (dus voor jou, doet hij dit zelf, ipv dat hij het verkeer forward naar jou client pc)

als dat zo is, kan je de ISA server niet omzeilen, want je kan ISA natuurlijk geen SSH verbinding laten maken met jou thuis pc.

dus zou ik ook bij de beheerder gaan zeuren... (brenge een kop koffie mee, vinden ze fijn )

[BSeB]

Uhm, in IE stel ik gewoon de proxy in welke hij moet gebruiken voor de verbinding gekoppeld aan een gebruikersnaam en wachtwoord.

Dus in IE en in opera de proxy opgegeven voor de betreffende onderdelen: Http https en ftp

Dit is denk ik de beste uileg die ik kan geven. In putty moet ik die gegevens ook invullen en als ik dat doe en ik maak verbinding naar poort 22 dan krijg ik die melding. Doe ik hetzelfde naar 443 dan sluit de client, waarschijnlijk de server die hier staat de verbinding. Ik krijg dan een foutmelding als volgt:

Server unexpectedly closed network connection

Mijn server werkt gewoon, en uit de liog van mijn server zou het aan de client kant moeten liggen.

[Verwijderd]

in putty heb je een kopje proxy, onder connection. Daar moet je je proxygegevens invullen en bij session moet je ipadres van je server thuis + poort opgeven.

[BSeB]

Verwijderd schreef op maandag 26 maart 2007 @ 14:27:
in putty heb je een kopje proxy, onder connection. Daar moet je je proxygegevens invullen en bij session moet je ipadres van je server thuis + poort opgeven.

Lol, dat snap ik ook, maar was meer als vraag op het ISA gedeelte.

Zou het kunnen dat alleen het priv gedeelte afgesloten is, en dat het unpriv gedeelte gewoon open staat?! Gezien standaard servioces altijd binnen de priv gedeelte draaien.

[FireDrunk]

wat bedoel je met "priv" en "unpriv" ?
ik heb nog nooit gehoord van die termen binnen nog de PuTTy wereld nog de ISA wereld

Correct me if i'm wrong...

[BSeB]

Met unpriv poorten bedoel ik alles hoger dan 1024 en met priv poorten alles beneden 1024.

Want ik kan bijvoorbeeld wel verbinding maken naar 5802 etc...

Daardoor bedoelde ik te zeggen dat priv poort misschien dicht zijn!

[Verwijderd]

als deze dicht zouden zijn, dan zou je ook geen websites kunnen bekijken die op poort 80 (http) of 443 (https) draaien en denk ik dat de proxy waar je gebruik van maakt toch op scherp staat ingesteld en daadwerkelijk het verschil ziet tussen http(s) en ssh verkeer.

Probeer eens te ssh'en naar een andere machine op poort 443. Bijv. xs2.xs4all.nl. Wordt bij deze ook de verbinding verbroken of krijg je een loginscherm?

De machine waar je iptables op draait en je server waar je naar toe wil connecten is dat 1 en dezelfde machine of zijn dat 2 aparte machines?

[BSeB]

Kan geen verbinding krijgen. Met geen mogelijkheid, hij gooid hem nu nog sneller dicht als normaal.

Overigens is de bak waar iptables op draait inderdaad dezelfde als waar ssh op luisterd.

[FireDrunk]

***lig maar waar, maar waarschijnlijk zit je dan toch achter een packet filtering firewall (zo-een die kijkt wat een pakketje is )

Toch maar even de beheerder een kop koffie gaan brengen

[Janoz]

BSeB schreef op dinsdag 27 maart 2007 @ 10:06:
Kan geen verbinding krijgen. Met geen mogelijkheid, hij gooid hem nu nog sneller dicht als normaal.

Overigens is de bak waar iptables op draait inderdaad dezelfde als waar ssh op luisterd.

Waarom heb je het dan met ip tables opgelost? Je kunt bij sshd keurig aangeven dat hij op 22 en 443 moet luisteren. Heb ik thuis ook. Maar goed, gezien het probleem al in de firewall zit heb je weinig aan deze info

[ Voor 8% gewijzigd door Janoz op 27-03-2007 16:57 ]

[Equator]

Goed: Dus je zit op een netwerk, waarbij je niet naar buiten toe mag met SSH, dus probeer je dat over poot 443 (SSL) te doen.
Nice try, maar een ISA server controleert op die poort toch echt of het wel een HTTPS sessie is.
Dat is het niet, dus blokkeert hij dat verkeer. Works as designed dus.

Verder valt dit dus onder het kopje "beveiliging omzeilen" en daar doen we hier niet aan..