In-Reply-To: <8AAB5E48C043704B8F1B835DD8F0A4465CA50C (at) ROBIN.eightinonepet (dot) com [email concealed]>
===
Disclosure: I work for Whale Communications, an SSLVPN vendor.
This email represents my opinion as opposed to the endorsed corporate policy of my employers.
It is my $.02 based on numerous SSLVPN projects
===
Any SSLVPN connection that creates a network layer connection; either by using a virtual adapter at the client, or by some other TCP forwarding mechanism, opens itself up to the risk of acting as a transport vector for virii, trojans and worms.
The ways to mitigate against all layers of this threat are to:
a)run AV on the client
b)have the SSLVPN check not only the AV is running, BUT ALSO when it was last updated, as having last year's signatures isn't much help to anyone.
c)DO NOT TRUST even authenticated session data - filter all incoming SSLVPN application traffic against worms, trojans etc., with a positive-logic, whitelist based application firewall that drops anything that is not on it's 'approved' list.
d)do not run network layer SSLVPN components that allow the user "full access, just as if they were in the building" as the fact is, they're remote users, and should be treated as such.
There is no way to predict the state of a client prior to connection, as they could have been surfing anywhere or doing anything before they logged in to the SSLVPN, whereas in the office chances are they more often than not are in a controlled browsing environment.
If a user requires non-http access to a client server app, make sure that:
i)the SHA-1 hash of the client exe file is checked before the client app connection is made - you don't want trojaned versions of explorer.exe mapping internal shares for example.
ii)all possible client side .ini files, reg settings, etc. required by the client app are pushed to it from the server, so that the administrator can have assurance that the users(who may be external users) are not tampering with the application setup to compromise security policy.
iii)only allow SSLVPN connections to be made by the exe that the SSLVPN checked first; it's no good opening up only port X, but then allowing any old process/app to telnet to that port and start pumping potentially malicious data|app requests through it.
Hope this helps,
-bill
>From: "Beauford, Jason" <jbeauford (at) EightInOnePet (dot) com [email concealed]>
>To: <focus-virus (at) securityfocus (dot) com [email concealed]>
>
>Group,
>=20
>I want to know if it is possible / plausible that a virus can travel
>from an unsecured and infected machine to an internal virus protected
===
Disclosure: I work for Whale Communications, an SSLVPN vendor.
This email represents my opinion as opposed to the endorsed corporate policy of my employers.
It is my $.02 based on numerous SSLVPN projects
===
Any SSLVPN connection that creates a network layer connection; either by using a virtual adapter at the client, or by some other TCP forwarding mechanism, opens itself up to the risk of acting as a transport vector for virii, trojans and worms.
The ways to mitigate against all layers of this threat are to:
a)run AV on the client
b)have the SSLVPN check not only the AV is running, BUT ALSO when it was last updated, as having last year's signatures isn't much help to anyone.
c)DO NOT TRUST even authenticated session data - filter all incoming SSLVPN application traffic against worms, trojans etc., with a positive-logic, whitelist based application firewall that drops anything that is not on it's 'approved' list.
d)do not run network layer SSLVPN components that allow the user "full access, just as if they were in the building" as the fact is, they're remote users, and should be treated as such.
There is no way to predict the state of a client prior to connection, as they could have been surfing anywhere or doing anything before they logged in to the SSLVPN, whereas in the office chances are they more often than not are in a controlled browsing environment.
If a user requires non-http access to a client server app, make sure that:
i)the SHA-1 hash of the client exe file is checked before the client app connection is made - you don't want trojaned versions of explorer.exe mapping internal shares for example.
ii)all possible client side .ini files, reg settings, etc. required by the client app are pushed to it from the server, so that the administrator can have assurance that the users(who may be external users) are not tampering with the application setup to compromise security policy.
iii)only allow SSLVPN connections to be made by the exe that the SSLVPN checked first; it's no good opening up only port X, but then allowing any old process/app to telnet to that port and start pumping potentially malicious data|app requests through it.
Hope this helps,
-bill
>From: "Beauford, Jason" <jbeauford (at) EightInOnePet (dot) com [email concealed]>
>To: <focus-virus (at) securityfocus (dot) com [email concealed]>
>
>Group,
>=20
>I want to know if it is possible / plausible that a virus can travel
>from an unsecured and infected machine to an internal virus protected
>network via an encrypted SSL VPN tunnel?
>=20
>Thanks in advance.
>=20
>JMB
>
[ reply ]