netilla clientless vpn.... iets bekend?

[rdoorn]

Hallo,
Ik heb gisteren een gesprek gehad met een leverancier van firewall en netwerk 'spul' en hij probeerde mij netilla te verkopen.

Nu ben ik benieuwd of iemand hier daar ervaring mee heeft.
Het is een 'clientless SSL VPN appliances ' welke in de DMZ komt te staan.
Hiermee zouden via ssl connecties naar terminalservers en applicatie servers binnen je netwerk gemaakt kunnen worden zonder dat er op de clientpc iets geinstalleerd hoeft te worden.

Het concept klonk mij aardig in de oren, maar de praktijk is vaak toch iets weerbarstiger..........

Enige ervaring hier?

[Bor]

Bedoel je deze: http://www.netilla.com/ ?

[Johnny E]

Bij het bedrijf waar ik werken bieden we een soort gelijke oplossing maar dan van http://www.aventail.com, zowel met als zonder client is het mogelijk om SSL VPN verbindingen op te zetten.

Het mooie ervan is dat je redelijk veilig van 99% van alle internet verbindingen een connectie kan maken met de zaak.

De client versie welke wij bieden heeft bijv volledige Active Directory integratie, dus je logon scripts e.d. lopen allemaal, de group policies worden door gestuurd etc.

Nokia heeft trouwens ook een dergelijke oplossingen in de portofolio zitten.

[ Voor 1% gewijzigd door Johnny E op 25-09-2003 11:12 . Reden: typo ]

[elevator]

Voor terminalservers - Citrix heeft ook een dergelijk product als toevoeging voor hun MetaFrame lijn - http://www.citrix.com/securegateway - ik gebruik het om toegang te krijgen tot Citrix servers en daarvoor werkt het product heel erg goed, het concept kan dus zeker.

Je moet alleen wel opletten (bij Secure Gateway iig) dat je client OS een juiste browser versie heeft (128-bit enabled) e.d., en dat kan op oudere PC's moeilijker worden.

[Bor]

Clientless maakt dus alleen gebruik van SSL? Zonder client authenticatie dan neem ik aan? Of moet men zelf nog certificaten naar de clients distribueren? Dan heb ik liever een normale VPN client eigenlijk.

[Johnny E]

De Aventail oplossing heeft wel degelijk authenticatie, je kan bijv op het platform een userbase aanmaken maar je kan hem ook koppelen aan een willekeurige LDAP of radius server. Je typt het naampje en password in en er wordt een certificaat geïnstalleerd. Het certificaat is dus alleen geldig voor die sessie.

[Bor]

Johnny E schreef op 25 september 2003 @ 11:15:
De Aventail oplossing heeft wel degelijk authenticatie, je kan bijv op het platform een userbase aanmaken maar je kan hem ook koppelen aan een willekeurige LDAP of radius server. Je typt het naampje en password in en er wordt een certificaat geïnstalleerd. Het certificaat is dus alleen geldig voor die sessie.

Leg me dat eens uit. Wordt er daadwerkelijk een certificaat geinstalleerd of wordt er gewoon gebruik gemaakt van sessies? Dan wil je dus voor elke sessie een nieuw certificaat in IE installeren? Of begrijp ik het dan verkeerd? En hoe zit het dan met ondersteuning voor andere browsers?

[Johnny E]

Je gaat naar een pagina op het internet, er wordt een java applet geladen, deze vraagt om je authenticatie gegevens.

Je voert ze in en het applet authenticeert je, via hetzelfde java applet wordt het certificaat geïnstalleerd en heb je toegang. Het werkt dus multiplatform (java).
En je kan het inderdaad zien als een sessie methode het certificaat is immers geldig to er wordt uitgelogd.

[ Voor 1% gewijzigd door Johnny E op 25-09-2003 11:25 . Reden: typo ]

[rdoorn]

Bor de wollef: Ja inderdaad http://www.netilla.com/
Johnny E: http://www.aventail.com, het klinkt inderdaad hetzelfde.
Zijn er nog verschillen met netilla?
Wat zijn de nadelen van deze techniek? (behalve de prijs zie ik nu nog alleen maar voordelen
Wat zijn de ervaringen qua snelheid en stabiliteit

[rdoorn]

SC magazine heeft een test gedaan van dit soort apperaten:
http://www.westcoast.com/...003_09/test_02/index.html

[Bor]

Nadeel is bv dat je zowiezo vast zit aan het java security model en SSL. Je kunt dus geen andere vormen van encryptie kiezen. De gebruikte algoritmen liggen vast.

Verder werkt het alleen met net-enabled technologie?

Overigens vind ik client-loos een beetje een groot woord. Er moet immers nog altijd een soort van client worden gedownload.

The NSP desktop application access is supported through a VPN
adapter that is downloaded and installed the first time a user logs
into the NSP for client/server access.

Hoe zijn de screening en loggingsmogelijkheden van deze apparaten?

Dan nog dit:

"The technology itself is just as secure as IPSec VPN," Kerravala said. "However, because of the way it is deployed, SSL VPN can be less secure. By providing users access from any location over any device, in the work, corporations are taking the risk that the computers or devices utilized may have security risks that the IT department is not aware of. With SSL VPN, you have two unknowns — the user and the device."

[ Voor 105% gewijzigd door Bor op 25-09-2003 19:08 ]

[igmar]

rdoorn schreef op 25 September 2003 @ 11:02:
Hallo,
Ik heb gisteren een gesprek gehad met een leverancier van firewall en netwerk 'spul' en hij probeerde mij netilla te verkopen.

Nu ben ik benieuwd of iemand hier daar ervaring mee heeft.
Het is een 'clientless SSL VPN appliances ' welke in de DMZ komt te staan.

Het werkt op basis van SSL + (tijdelijke) certificaten. Citrix Secure Gateway is ook z'n product.

Hiermee zouden via ssl connecties naar terminalservers en applicatie servers binnen je netwerk gemaakt kunnen worden zonder dat er op de clientpc iets geinstalleerd hoeft te worden.

Het concept klonk mij aardig in de oren, maar de praktijk is vaak toch iets weerbarstiger..........

Met SSL liggen je protocollen vast, die kun je niet veranderen. SSL is ook niet bestand tegen man-in-the-middle spoof attacks. Ik zou wat dat betreft m'n geld zetten op IPSEC.

De term VPN in deze contex is ook niet correct : Het is een encrypte peer-naar-peer connectie, geen peer-netwerk of netwerk-netwerk koppeling. De term VPN word helaas voor zowat alles gebruikt, ook al is het niet correct.

[ Voor 13% gewijzigd door igmar op 25-09-2003 20:14 ]

[rdoorn]

Bor_de_Wollef schreef op 25 September 2003 @ 18:52:
Nadeel is bv dat je zowiezo vast zit aan het java security model en SSL. Je kunt dus geen andere vormen van encryptie kiezen. De gebruikte algoritmen liggen vast.

Dat is een punt maar dat hoeft geen groot probleem te zijn; immers geen clients dus upgrade is simpeler want je hoeft de clients niet af.

Bor_de_Wollef schreef op 25 September 2003 @ 18:52:
Overigens vind ik client-loos een beetje een groot woord. Er moet immers nog altijd een soort van client worden gedownload.

Maar dat is vaak makkelijker als een client installeren op een PC die niet van jou is, of niet onder jou beheer valt. Dus stirkt genomen niet client loos, maar practiesch gezien hoeft er door degene die de verbinding aanbied niets te worden geinstalleerd op de pc van de client.

Bor_de_Wollef schreef op 25 September 2003 @ 18:52:

Hoe zijn de screening en loggingsmogelijkheden van deze apparaten?

Dan nog dit:
quote:
--------------------------------------------------------------------------------
"The technology itself is just as secure as IPSec VPN," Kerravala said. "However, because of the way it is deployed, SSL VPN can be less secure. By providing users access from any location over any device, in the work, corporations are taking the risk that the computers or devices utilized may have security risks that the IT department is not aware of. With SSL VPN, you have two unknowns — the user and the device."
--------------------------------------------------------------------------------

Logging is nog niet bekend, zal dat dus zeker na vragen.
Unknown device/user:Tja, dat is natuurlijk wel een risico dat je moet incalculeren, dus de toegang moet niet alomvattend zijn, een systeembeheerder laatje dan met IPsec inloggen..

Bedankt voor deze critisch kijk

[Bor]

rdoorn schreef op 29 September 2003 @ 14:33:
[...]


Dat is een punt maar dat hoeft geen groot probleem te zijn; immers geen clients dus upgrade is simpeler want je hoeft de clients niet af.

Dat is waar maar je moet je afvragen of je uberhaubt de toegang tot bedrijfskritische apps wilt overlaten aan alleen het java security model en zijn implementatie.

Wie regelt verder de uitgave van certificaten? Als je namelijk de gehele controle bij het inloggen alleen over laat aan bv tacacs+ of radius, want heeft het certificaat dan voor zin als die automatisch geinstalleerd wordt? Maw de enige authenticatie (waarvoor het certificaat dient) wordt eigenlijk afgehandeld door tacacs+ of radius oid op dat moment. Als ik dus een goede username / password combinatie heb krijg ik automatisch een certificaat met bijbehorend sleutelpaar? (voor de sessie)?

Dit is zoals ik het lees:

1 - client opent website
2 - upload java applet vanaf server
3 - client authenticatie mbt tacas of radius oid
4 - bij goedkeuring upload certificaat naar client

Het certificaat dient juist ter authenticatie van de public key van de user (dus ik weet dat die sleutel absoluut bij de gebruiker hoort).

Wat is nu het verschil tussen gewoon SSL met alleen server authenticatie en user authenticatie middels tacacs+ / radius etc en het model van netilla?

Misschien lees ik ergens over heen, maar volgens mij helemaal niets behalve dat het toegestuurd certificaat ter authenticatie van de sessie wordt gehanteerd (en niet de user) ipv de normale "server side" sessie tracking.

[ Voor 68% gewijzigd door Bor op 29-09-2003 14:51 ]

[Bor]

Verder is het wellicht interessant op welk os het draait ivm eventuele patches etc.

[Border|IA]

ssl is zo veilig nog niet kan realtime gespoofed en gedecrypt worden.

[Bor]

Border|IA schreef op 01 October 2003 @ 10:21:
ssl is zo veilig nog niet kan realtime gespoofed en gedecrypt worden.

Heb je hier bewijs voor? SSL is onder bepaalde voorwaarde vatbaar voor een man in te middle attack. Wat jij hier boven zegt lijkt op "je kunt het net zo goed niet doen want alle vormen van SSL zijn in een handomdraai te kraken".

Kom eerst eens met bewijs voordat je dit soort drastische onwaarheden vermeld. Of bedoel je iets totaal anders?

[ Voor 5% gewijzigd door Bor op 01-10-2003 12:25 ]

[Bor]

Graag zou ik van de topicstarter weten hoe het gaat met dit "probleem".

[Border|IA]

Bor_de_Wollef schreef op 01 October 2003 @ 12:25:
[...]


Heb je hier bewijs voor? SSL is onder bepaalde voorwaarde vatbaar voor een man in te middle attack. Wat jij hier boven zegt lijkt op "je kunt het net zo goed niet doen want alle vormen van SSL zijn in een handomdraai te kraken".

Kom eerst eens met bewijs voordat je dit soort drastische onwaarheden vermeld. Of bedoel je iets totaal anders?

een voorbeeld:
SSH1 support : you can sniff User and Pass, and even the data of an SSH1 connection. ettercap is the first software capable to sniff an SSH connection in FULL-DUPLEX
+ bijbehorende tool:
http://ettercap.sourceforge.net/

[Bor]

Border|IA schreef op 13 October 2003 @ 09:01:
[...]


een voorbeeld:
SSH1 support : you can sniff User and Pass, and even the data of an SSH1 connection. ettercap is the first software capable to sniff an SSH connection in FULL-DUPLEX
+ bijbehorende tool:
http://ettercap.sourceforge.net/

Yep, omdat de implementatie van SSL in SSH1 buggy is. Dit heeft dus weinig met SSL te maken...

[rdoorn]

Bor_de_Wollef schreef op 10 oktober 2003 @ 17:04:
Graag zou ik van de topicstarter weten hoe het gaat met dit "probleem".

Nou hierbij een update:

Nog geen keuze gemaakt, maar ik zie inmiddels het beeld wel een stuk helderder.
Inmiddels blijkt dat het installeren van een client niet zo'n groot probleem is, dus komen er weer veel meer mogelijkheden bij, zoals een 'gewone' vpn verbinding.

Wel is duidelijk geworden dat de voorgestelde oplossing te duur (€ 7000,-) is voor de MKB klant waar het eea moet komen.

Ik zit inmiddels te kijken naar een sonicwall soho3 oid......

[igmar]

Bor_de_Wollef schreef op 01 October 2003 @ 12:25:
Heb je hier bewijs voor? SSL is onder bepaalde voorwaarde vatbaar voor een man in te middle attack. Wat jij hier boven zegt lijkt op "je kunt het net zo goed niet doen want alle vormen van SSL zijn in een handomdraai te kraken".

Een transparante proxy kan dit, dat wil zeggen : Je kan de connectie afvangen, en die lezen. Het enige wat niet kan is jezelf voordoen als de andere kant, dus clients krijgen een waarschuwing dat d'r iets niet klopt (veroorzaakt door het certificaat van de proxy).

Een groot nadeel van SSL zelf vind ik dat alle protocollen vastleggen, en dat ik met enig regelmaat implementaties zie die zich daar niet aan houden. Verder is het een 1 op 1 verbinding, hele netwerken koppelen gaat dus niet (logisch, het is OSI laag 7).

Wat dat betreft heb ik liever IPSEC met OE en een policy. Zie http://www.freeswan.ca/do...-2.02/doc/quickstart.html

[Bor]

igmar schreef op 13 October 2003 @ 17:24:
[...]


Een transparante proxy kan dit, dat wil zeggen : Je kan de connectie afvangen, en die lezen. Het enige wat niet kan is jezelf voordoen als de andere kant, dus clients krijgen een waarschuwing dat d'r iets niet klopt (veroorzaakt door het certificaat van de proxy).

Klopt, en dus werkt dat niet bij 2 zijdige authenticatie.