SSL VPN vs Proxy

[Verwijderd]

Hello,


Ik zit met een probleem. Het bedrijf waar ik werk host voor klanten self made applicaties (win32), en host dit momenteel via een SSL portal, aangezien veel klanten hier een voorkeur voor hebben omdat er dan geen extra server etc etc etc op lokatie moet worden ingezet.

Voor deze setup maken we gebruik van een SSL-VPN2000 Appliance van Sonicwall. Cool apparaat, met leuke features, ActiveX gebaseerd RDP Protocol over https. Mooi mooi mooi. Maarnu, het probleem.
De RDP Sessies vanuit de SSL appliance willen zich niet laten leiden over een ingesteld proxy systeem. De appliance is dusdanig ingesteld dat deze direct op poort 443 tegen de firewall aanpraat naar buiten toe.
Een aantal van onze klanten staat dit soort verkeer niet toe (bypassen proxy, direct naar buiten) (grotere overheden en multinationals). Nu zit ik met de vraag; "wat is nu normaal"

Is het normaal dat dit soort verkeer door een proxy heen moet (lijkt mij niet, aangezien je https niet mag cachen, en het zelf al secure is), of is het normaal dat de appliance direct naar buiten wil?

Ik moet dit weten om klanten in de toekomst te informeren cq aanschaf van materieel hierop aan te passen.
Het schijnt dat de Juniper SA2000 z'n https sessies wel door een proxy laat verlopen ... Kan iemand dit bevestigen?


Thanks, Sander

[Verwijderd]

Niemand met kennis van deze materie?

[assembler]

Dit is niet echt eenvoudige koek. Ik raad je aan om contact op te nemen met SonicWall zelf, zij hebben volgens mij best professionele support en kunnen je waarschijnlijk wel verder helpen.

[Verwijderd]

assembler schreef op donderdag 18 januari 2007 @ 20:39:
Dit is niet echt eenvoudige koek. Ik raad je aan om contact op te nemen met SonicWall zelf, zij hebben volgens mij best professionele support en kunnen je waarschijnlijk wel verder helpen.

Dat hebben ze zeker, echter zijn ze niet voornemens om toekomstige software aan te passen zodat deze connecties zich laten leiden door een proxy heen.

Dat vind ik ook geen probleem, indien dit een normale gang van zaken is (dat dit soort verkeer niet over een proxy heen mag), dan kan ik dit namelijk verkopen naar klanten toe....

[Bor]

Een aantal van onze klanten staat dit soort verkeer niet toe (bypassen proxy, direct naar buiten) (grotere overheden en multinationals). Nu zit ik met de vraag; "wat is nu normaal"

Als je vraag is of het niet toestaan van verkeer buiten de proxy om normaal is kan ik alleen maar antwoorden met "ja". Dat is in mijn ogen ook niet meer dan een normale beveiligde verbinding. Ik denk niet dat je de FW admins van een bedrijf zo ver krijgt dat ze SSL verkeer van elk station naar internet toe zullen staan. Je raakt namelijk dan alle controle kwijt gezien je logischerwijs niet in de SSL tunnel kunt kijken.SSL en HTTPS werken overigens prima over o.a. SOCKS (4 of 5) proxy.

[ Voor 5% gewijzigd door Bor op 18-01-2007 21:44 ]

[Verwijderd]

Ok,

Dat lijkt mij dus ook logisch. Wel kan een netwerkbeheerder natuurlijk regels aanmaken dat https protocol alleen vanuit bepaalde stations naar bepaalde sites toe kunnen, op die manier laat je het dus toe, gecontroleerd.

Wat ik dan dus niet snap is dat Sonicwall een SSL VPN Appliance maakt, en deze vervolgens zijn RDP protocol verkeer buiten een proxy om laat lopen, met als stelling dat dit een security breach is omdat dat verkeer gecached en gedecrypt zou kunnen worden. Wat is dan nog het nut van de appliance?

Iemand ervaring met Juniper SA700/2000 materiaal, of Cisco? Ik wil graag ervaringen horen voordat ik weer 2K uitgeef voor een apparaat wat uiteindelijk niet blijkt te voldoen

[Bor]

Verwijderd schreef op donderdag 18 januari 2007 @ 22:07:
Ok,

Dat lijkt mij dus ook logisch. Wel kan een netwerkbeheerder natuurlijk regels aanmaken dat https protocol alleen vanuit bepaalde stations naar bepaalde sites toe kunnen, op die manier laat je het dus toe, gecontroleerd.

Je laat het op die manier toe maar slecht zeer beperkt "gecontroleerd". Dit omdat je niet in de tunnel kunt kijken en dus eigenlijk geen enkele invloed hebt op het uigaande (en eventuele inkomende) verkeer. Screening van de informatie in de tunnel is op die manier niet mogelijk. Ik zou het zelf een "no go" vinden die vaak al in een beveiligingsbeleid of -plan word vastgesteld.

[Verwijderd]

Ok, thanks.

Maar, kan een proxy zomaar in de tunnel kijken om te zien wat erdoorheen gaat?

Wat is het nut van de SSL verbinding als het (zo makkelijk) kan worden onderschept? (ik denk ook dat dat de visie is van Sonicwall in deze kwestie )

[ Voor 16% gewijzigd door Verwijderd op 18-01-2007 23:25 ]

[Rolfie]

Verwijderd schreef op donderdag 18 januari 2007 @ 23:24:
Ok, thanks.

Maar, kan een proxy zomaar in de tunnel kijken om te zien wat erdoorheen gaat?

Wat is het nut van de SSL verbinding als het (zo makkelijk) kan worden onderschept? (ik denk ook dat dat de visie is van Sonicwall in deze kwestie )

Neen, een proxy kan niet zomaar 123 in een HTTPS sessie kijken. Het is echte niet onmogelijk. Er zijn applicaties en appliances die wel in een HTTPS sessie kunnen kijken.

Maar in vind de houding van je leverancier niet echt goed.

Als ik het goed begrijp is dat gewoon het verkeer via port 443 communiceerd? Dit ga je inderdaad bijna bij geen enkel groot bedrijf direct door de firewall heen krijgen. Bij mijn klanten klanten zeggen we daar gewoon NEE op.

Heb je niet de mogelijkheid om een complete SSL VPN tunnel op te bouwen? Deze gaan wel direct door een proxy server heen.

[Verwijderd]

Rolfie schreef op vrijdag 19 januari 2007 @ 08:41:
[...]
Heb je niet de mogelijkheid om een complete SSL VPN tunnel op te bouwen? Deze gaan wel direct door een proxy server heen.

Die mogelijkheid heb ik wel, echter wordt dat verkeer ook direct naar de firewall toe geleid ....

[Predator]

Verwijderd schreef op donderdag 18 januari 2007 @ 22:07:
Iemand ervaring met Juniper SA700/2000 materiaal, of Cisco? Ik wil graag ervaringen horen voordat ik weer 2K uitgeef voor een apparaat wat uiteindelijk niet blijkt te voldoen

Ik gebruik een SA4000 (technologie gelijk aan de SA700/2000).

Ik heb geen probleem om te connecteren via een http(s) proxy.
Maar het hangt er natuurlijk ook vanaf wat voor proxy en of die authenticatie doet.
Maar doorgaans geeft dat probleem.

Kijk wel even uit want bij Juniper hebt je verschillende manier (en bijbehorende licenses) om het product te gebruiken:
• SAM -> apps over een tunnel
• ActiveX RDP/ICA client
• Network Connect: volwaardige VPN client cfr IPSEC client, maar gebruikt ESP of SSL al tunnel.
• HTTP(s) reverse proxy

Maar euh:
2K uitgeven ?

Ik heb nog nooit een appliance gekocht zonder die eerst een maand te testen.
Dus ga naar je leverancier en vraag een demotoestel.

Afhankelijk van je connecties met je leverancier en eventueel een try&buy overeenkomst krijg je er nog een gratis productspecialist bij voor 1 dag

[ Voor 15% gewijzigd door Predator op 19-01-2007 09:49 ]

[Verwijderd]

Ha Predator,

Thanks voor de info!!

Alleen uh, uitproberen? M'n leverancier is de groothandel.... Die doen dat niet

[rdfeij]

Verwijderd schreef op vrijdag 19 januari 2007 @ 10:11:
Ha Predator,

Thanks voor de info!!

Alleen uh, uitproberen? M'n leverancier is de groothandel.... Die doen dat niet

En een stapje hoger gaan zoeken, dus direct bij Juniper...
Demo lenen, daarna kopen?

[Predator]

Verwijderd schreef op vrijdag 19 januari 2007 @ 10:11:
Ha Predator,

Thanks voor de info!!

Alleen uh, uitproberen? M'n leverancier is de groothandel.... Die doen dat niet

De distributeur(s) doen dat normaal gezien wel.
Ofwel bij een grote intergrator even gaan horen.

[Verwijderd]

Ik heb een request ingediend voor future firmware release, schijn niet de enige te zijn met dit probleem, dus hoop er het beste van. Desalniettemin moet ik over 2 weken een nieuwe omgeving hebben draaien, en zal k dus moeten overgaan op ander spul....