- A Quick
Overview
- Installation
- Initial Config on
ISA
- VPN Client
Package
- The Default Behaviour Of
The VPN-Q 2006 Client If The Health Checks
Fail
- Default Health Checks
Performed by VPN-Q 2006 Enterprise
Edition:
- IP Routing
Status
- ICS - Internet Connection
Sharing Status
- Antivirus
Checks
- Personal Firewall
Checks
- Automatic Updates and
Security Updates
Status
- Minimum Operating System
and Service Pack
Level
- Screen Saver
Status
- Use Default Gateway on
Remote Network
A Quick
Overview
There are a couple of things concerning any
security admin regarding its users like don't do
anything stupid and keep your software(like
OS, antivirus definitions...) up to date.
For the security admin, these
things might be under her/his control if the
machines are located on the corporate
network.
The admin will make sure tha the OS'
are patched on a timely basis, install on every
user machine a personal antivirus and a personal
firewall. He or she will keep the antivirus
definitions up to date.
When these machines leave the
corporate network for a period of time, and need
access to the corporate network from remote
locations, the admin is clueless about their
state of health.
Were the latest security patches
installed ?
Was the antivirus kept
up to date, or even worse, is still the
antivirus program enabled on these
machines ?
Is the personal firewall
still enabled on the users' machines
?
Have those machines become a sort of
gateways for the user's home network, thus
serving as a potential path to the corporate
network for an attacker once the user uses a VPN
connection to access the corporate network ?
Remote VPN access can be the
solution to the need of connectivity of the
remote users, users like the road warriors, home
workers or a remote partner.
ISA Server 2004/2006 is a powerful
remote access VPN server offering remote access
connectivity using an Internet Standard protocol
like L2TP/IPsec.
Within the VPN
Consortium document of supported
technologies, L2TP/IPsec is listed under
Secure VPN technologies.
ISA Server 2006,
as a VPN server is discussed in detail in Dr. Tom Shinder's ISA
Server 2006 Migration Guide.
As
you may know or not, I've started a series of
articles dedicated to L2TP/IPsec and ISA. If you
like, you may start to read them:
http://www.carbonwind.net/ISA/L2TP/l2tp1.htm
Unfortunetely, there aren't by
default any practical means available
with ISA for the security admin to check the
remote VPN users machines' health status(when I say
practical, I exclude the administrative
nightmare VPN Quarantine made available with ISA
2004/2006 by Microsoft, solution which will
make most of the people abandoning the
idea of using a remote access VPN
quarantine with ISA).
NAP is a hot topic
right now.
If you search for NAP, you may
found out that this will be available on the
future version of ISA, called TMG. But TMG is
far away at this moment.
Luckily for the ISA admins, an
enterprise grade VPN quarantine solution for ISA
is available for quite a while now. This
solution is called VPN-Q 2006. You can reach it
at its vendor site, http://www.winfrasoft.com/.
It will work with the VPN protocols available on
ISA, PPTP and L2TP/IPsec. And very important,
VPN-Q 2006 is a very easy to use and to
implement solution.
VPN-Q 2006 was
reviewed by Doctor Tom Shinder, please refer to
http://www.isaserver.org/tutorials/Releasing-VPN-Quarantine-Users-VPN-Q-2006.html.
And it's
about to get even better, a new version, VPN-Q
2008 knocking on the door.
VPN-Q 2006
is available in two editions: Standard
Edition and Enterprise Edition.
In this
part we will talk about VPN-Q 2006 Enterprise
Edition, what it does and what it does
not.
In a future part, when VPN-Q 2008 will
be RTM, we will talk about it.
To say it in a few words, VPN-Q
2006 holds the VPN clients in a Quarantine
Network, checks their health status, and if they
pass the checks, it releases them from
quarantine.
Since ISA has the ability to apply
firewall policies for users or groups of
users, you will not have a flat Quarantine
Network.
For example, if ISA is a domain
member, you can create two group of users in
Active Directory, VPN1 and VPN2. Create separate
access rules on ISA in respect with the VPN
Quarantine Network, for VPN1
group and for the VPN2 group.
So
if a VPN user from the VPN1 group fails the
checks, and is retained within the Quarantine
Network, he or she may be allowed to access
different resources than a VPN user from the
VPN2 group which is in the same
situation.
This ensures a lot of flexibility
for the ISA admin, because it is not required
that all quarantine users to be under the same
firewall policies.
By default, numerous security
checks are performed on the VPN clients machines
to determine the status of their health.
The
downside with VPN-Q 2006 is that you can only
customize these checks with an Active Directory
group policy, so the VPN users's machines must
be domain member computers, see Using the VPN-Q 2006
Active Directory Group Policy
Template.
That might
not be a big problem, since the default settings
cover multiple areas. Scroll bellow for the Default Health Checks
Performed by VPN-Q 2006 Enterprise
Edition.
With VPN-Q 2008
however, you will be able to customize the
security checks for non-domain member machines
too, directly from ISA, so VPN-Q 2008 promises
to introduce new important and useful
features.
Installation
The version of VPN-Q 2006 used in this article
was VPN-Q 2006 Enterprise SP3 Trial.
VPN-Q
206 was installed on ISA Server 2006
Standard Edition running on Windows Server 2003
Standard R2 SP2.
ISA Server 2006 was a domain
member.
I will not insist on the
installation procedures, because these are
covered in detail, with step-by-step pictures,
in VPN-Q 2006's manual. Installation is pretty
much an easy process.
I just want to say that you need to
have:
ISA Server
2004/2006:
- installed at a minimum on
Windows Server 2003 SP1
- Microsoft
.NET Framework 1.1 or higher
On the client:
- Windows
XP Home Edition SP2, Windows XP
Pro SP2, Windows XP Pro x64, Windows
XP Media Center Edition 2005 or Windows
Vista(Home Basic, Home Premium, Ultimate,
Business, Enterprise) are
required.
- Microsoft .NET Framework
1.1 or higher
Also VPN-Q 2006 installs on ISA the
Remote Quarantine Agent and CMAK, so you need to
have the Windows source file(say the Windows CD)
available during the installation phase.
Initial Config on
ISA
After you install VPN-Q 2006 on ISA, you'll run
the VPN-Q 2006 Config Wizard,
which is quite important because it will create
for you some required access rules. I want
to say a few words about it.
It will create an access rule
to allow communication between the VPN-Q 2006
Client and ISA, see
Figure1.
Figure1: VPN-Q
2006 Config Wizard - Create VPN Quarantine
protocol and access
rule
Also you need to specify a location
for VPN clients to check for missing security
updates. While the VPN clients are in the
quarantine network, they must be given access to
the Internet(to be able to connect to the
Microsoft Update) or a to an internal WSUS
server.
If you won't do that, the Security
Updates checks on the client will fail.
The
wizard will create the required access rule on
ISA to provide access to Microsoft Update, see
Figure2.
You
can specify the name of the WSUS server if
you have a WSUS server. An URL will
be constructed from the specified WSUS
server name for the access rule. Note that you
need to configure your VPN clients to use
that WSUS server.
Figure2: VPN-Q
2006 Config Wizard - Microsoft
Update
The DNS servers configured on the quarantine
clients' VPN adapter will be used for name
resolution, for example to access Microsoft
Update .
The wizard will automatically create
for your the required access rule, see
Figure3. I've specified
the name of the internal DNS server which will
be provided to the VPN clients on their PPP
adapter.
Figure3: VPN-Q
2006 Config Wizard - DNS
Access
There is one more access rule automatically
create for your by the wizard, see
Figure4.
This one is
useful for example, if you want to update the
group policy of the VPN clients once their are
connected, while they are in the Quarantine
Network, either before or after the health
checks are performed(in case they fail these
checks). If you plan to use the group policy to
customize the default health checks performed by
VPN-Q 2006, you may be interested to run a group
policy update on the VPN quarantine clients,
either with the help of a custom CMAK
profile or using the Run
Command After Security Checks option of
VPN-Q's Active Directory group policy.
Figure4: VPN-Q
2006 Config Wizard - Active
Directory Access
After the Config Wizard was completed, you
can check the firewall policy created on ISA by
it, see Figure5.
As
said earlier, note that the access rules are
applied to All Authenticated
Users. You might want that
only specific users to have Active
Directory access, replace the All
Authenticated Users condition with
a certain group of users.
Figure5: ISA - The
Firewall Policy Created By The VPN-Q 2006
Config Wizard
You can run the Config Wizard at any
time from the VPN-Q 2006 Server
Administrator, see
Figure6.
Figure6: VPN-Q
2006 Server Administrator - ISA 2006
Tab
Also from the VPN-Q 2006 Server
Administrator, you can modify the
address or name of the VPN server that you've
specified during the installation phase, see
Figure7. This name will
be included in the VPN client package that
will be installed on the VPN users'
machines.
Figure7: VPN-Q
2006 Server Administrator - General
Tab
From the VPN-Q 2006 Server
Administrator, you can control the
logging level or start/stop/set the Remote
Access Quarantine Access service, see
Figure8.
Figure8: VPN-Q
2006 Server Administrator
- AdvancedTab
VPN Client
Package
You will create the VPN Client package from
the VPN-Q 2006 Server
Administrator, by clicking the
Create button, see
Figure9. It's a custom
CMAK profile.
If you select the Use
Pre-shared key for L2TP/IPsec
connections checkbox, the configured
pre-shared key on ISA for IKE
authentication will be included in the VPN
Client package. If the this pre-shared key is
not long enough(less than 8 characters), VPN-Q
can automatically configure if you want a 32
character pre-shared key on ISA. Also if no
pre-shared key was configured on ISA, VPN-Q can
automatically configure if you want a 32
character pre-shared key.
You can enable the
option that allows the user to save the
password, but that's a possible dangerous
setting.
The default VPN client package will
work fine with MS-CHAPv2 for user
authentication, and certificates or pre-shared
keys for IKE authentication. MS-CHAP, CHAP or
PAP will also work for user
authentication.
Figure9: VPN-Q
2006 Server Administrator - VPN
Client Tab
If you want to
create a VPN client package that will use
EAP-TLS for user authentication, with the users'
certificates being stored on smart cards, or RSA
SecurID two factor authentication, check
the VPN-Q 2006 CD, the AuthUpdates folder, see
Figure10.
Figure10: VPN-Q
2006 CD - AuthUpdates
Folder
For example
within the VPN-Q 2006 SP3 Smart Card Update
folder, you will find a client.exe file and a
link to a help web page, see
Figure11. You need
to backup the existing client.exe file
found in C:\Program Files\VPN-Q 2006, and copy
the one from the CD in C:\Program Files\VPN-Q
2006.
Figure11: VPN-Q
2006 CD - Smart Card
Update
You can create
your own custom CMAK
profile to work with VPN-Q 2006
if you want.
VPN-Q 2008, as writing this available for
testing as Beta 1 version, comes with more VPN
client packages out of the box.
The Default Behaviour Of The
VPN-Q 2006 Client If The Health Checks
Fail
By default, if the VPN client fails the health
checks, it will receive a message, see
Figure12, and
once he or she clicks the
OK button, the VPN
connection will be disconnected. And a web
page from Winfrasoft's web site will be
opened, web page containing some general help
instructions.
If you want to change this
behaviour, and to keep the VPN clients connected
in the Quarantine network, you need to use the
VPN-Q Active Directory group policy.
Figure12: VPN-Q
2006 Client- Failed
Message
Default Health Checks Performed
by VPN-Q 2006 Enterprise
Edition
Let's view a couple of default checks performed
by VPN-Q 2006.
Note that with VPN-Q 2006
Enterprise, an event will be logged on ISA
whenever the health status of a VPN client is
checked, so the admin can see for
example the cause why the realease from
quarantine failed. Thus the management is
informed, and can take actions, if imposed by
the company's policies, against the hapless
user.
IP Routing Status
If IP routing is enabled on the client machine,
this opens the posibility that an attacker
located on the same network with the VPN
client, to access the corporate network using
the established connection. You may like to read
this article:
http://www.isaserver.org/tutorials/2004fixipsectunnel.html
Let's visualize this attack. Say
that the remote network is
192.168.50.0/24.
The network behind ISA is
192.168.10.0/24.
The VPN client(using a
Windows XP SP3 machine) has received an
on-subnet IP address for its PPP adapter,
192.168.10.205.
Note that the
Use
default gateway on remote network
checkbox is checked on the VPN adapter. The
Windows Firewall is enabled on every connection
on the VPN client. Also note that, with the
default routing table in place, the VPN client
access directly local resources, meaning hosts
located on the 192.168.50.0/24 network.
I've
started a Wireshark capture on ISA's external
interface, and I've set IPsec ESP
confidentiality(encryption) to null, so we can
see in clear the packets. Also compression was
disabled.
In
Figure13 we can see
a normal reply message, from a server behind ISA
sent to the VPN client.
Figure13: Wireshark on
ISA - XP Client with IP Routing
Enabled: Normal Packet Sent over the
VPN Tunnel
In
Figure14 we can spot that
instead of being sourced with the
192.168.10.205, some packets are coming from the
VPN client with the source IP address
192.168.50.1.
I've simulated an "attack" from
a host, 192.168.50.1, located on the same
network with the VPN client, using the ping
command. This host has a route to the network
behind ISA through the physical adapter of the
VPN client. The IP address 192.168.50.1, is an
off-subnet one in respect with the network
behind ISA.
Since IP routing is enabled, my
Echo Request messages have been routed through
the VPN connection.
Note that, if other more
advanced personal firewall would have been
installed on the VPN client, the Echo Request
messages might have been dropped by this
firewall(for example if Kaspersky Internet
Security 8 was installed, and the
192.168.50.0/24 was configured as public network
within the Kaspersky Firewall, then
the Echo Request messages would be dropped by
the Kaspersky Firewall).
As you can notice,
this "attack" was an easy to execute one.
Figure14: Wireshark on
ISA - XP Client with IP Routing Enabled: Foreign
ICMP Echo Request Message Injected into the VPN
Tunnel: IP Source
Address Off-Subnet
But we cannot see any ICMP Echo Reply
messages, thus I was not able to "establish" a
connection with the host behind ISA.
In
fact, my packets did not even reach the
specified destination.
Why ?
Because the ISA firewall was between the VPN
client and the 192.168.10.2 host.
I've also
started the live logging on ISA. Looking at it,
we can view the ping packets being dropped by
ISA as spoofed, see
Figure15.
Figure15: Logs on
ISA - The IP Spoof Detection Feature
Blocked the Foreign ICMP Echo Request Message
Injected into the VPN Tunnel: IP Source
Address Off-Subnet
ISA includes, turned on by default, an
advanced anti-spoofing mechanism. ISA uses the
concept of Networks. For example the default
Internal Network includes only
the 192.168.10.0/24 subnet. If a host
located on this Network, would have, say the
192.168.123.56 IP address, ISA will drop any
packets from this host, as spoofed, because only
pakets sourced with an IP address from
192.168.10.0/24 are expected to reach ISA's
internal interface.
These checks are part of
ISA's anti-spoofing mechanism, which, as
said above, is on by default. ISA knows that the
ping packets sent by the attacker, should not
come from that direction, only packets sourced
with the 192.168.10.205 messages are supposed to
be received from that VPN client.
You may wonder, what if the IP address of the
attacker is an on-subnet one ?
To make a
quick test, I've configured static IP
addressing for the VPN clients on ISA, by
defining a static pool of IP addresses,
192.168.50.1-192.168.50.20.
Now the VPN
client, physically located on the
192.168.50.0/24, receives the 192.168.50.6 IP
address for its PPP adapter, see
Figure16, which shows an
Echo Reply message from a host behind ISA,
192.168.10.2, sent to the VPN client, as
response to an earlier Echo Request
message.
Figure16: Wireshark on
ISA - XP Client with IP Routing
Enabled: Normal Packet Sent over the
VPN Tunnel
And I will repeat the "attack", this
time from the 192.168.50.10 host, see
Figure17.
Figure17: Wireshark on
ISA - XP Client with IP Routing Enabled: Foreign
ICMP Echo Request Message Injected into the VPN
Tunnel: IP Source
Address On-Subnet
And again the same result, ISA drops these
packets as spoofed, see
Figure18.
Figure18: Logs on
ISA - The IP Spoof Detection Feature
Blocked the Foreign ICMP Echo Request Message
Injected into the VPN Tunnel: IP Source
Address On-Subnet
Using its anti-spoofing detection
methods, ISA knows that the ping packets sent by
the attacker, should not come from that
direction, only packets sourced with the
192.168.50.6 messages are supposed to be
received from that VPN client.
As we have seen, ISA is capable of defeating
certain attacks, which may come as a result that
IP routing was enabled on the VPN client's
machine.
However, this setting should stay
off.
VPN-Q 2006 takes care of this
aspect.
A default check performed by the
VPN-Q 2006, is the status of the IP routing
setting. This is part of the System
Overview Checks, see
Figure19 and
Figure20. As can be
noted, the client was not realesed from
quarantine.
Figure19: VPN-Q 2006
Client - Failed: System
Overview
Figure20: VPN-Q 2006
Client - Failed Detail: Windows IP Routing Is
Enabled
ICS
- Internet Connection Sharing Status
As discussed in this already mentioned
article:
http://www.isaserver.org/tutorials/2004fixipsectunnel.html even
when IP routing is disabled, if the user enables
ICS on the VPN adapter, the same risks
appear.
So we will repeat one more time the
above "attack", this time with IP routing
disabled, and ICS enabled on the VPN adapter.
I've received a message on the VPN
client about the needed network for ICS,
192.168.0.0/24, and my physical adapter was
configured to use an IP address from this range,
I've just put back the original settings on this
adapter.
The VPN client receives an IP
address from the corporate internal
network, on-subnet IP address.
I've
started a Wireshark trace on the VPN client, on
its physical adapter.
We can see in
Figure21, the ICMP Echo
Request message sent by the "attacker",
192.168.50.10.
Figure21: Wireshark on
the XP Client with ICS Enabled on the VPN
Connection - Foreign ICMP Echo Request Message
Injected into the VPN Tunnel: The Source
Address
And from Figure22 we
can view that the ICMP message was NAT-ed,
because ICS is enabled, and sent over the VPN
link.
Figure22: Wireshark on
the XP Client with ICS Enabled on the VPN
Connection - Foreign ICMP Echo Request Message
Injected into the VPN Tunnel: Packet Gets
NAT-ed
And now a ICMP Reply message is
received(I have created an access rule on ISA
allowing Ping from the VPN Clients Network to
the Internal Network), see
Figure23. This
message is destined the VPN client, destination
IP address 192.168.10.207.
Figure23: Wireshark on
the XP Client with ICS Enabled on the VPN
Connection - An ICMP Echo Reply Message
Is Returned
NAT is applied in reverse now, and the ICMP
Reply message is sent to the "attacker",
see
Figure24.
Figure24: Wireshark on
the XP Client with ICS Enabled on the VPN
Connection - The ICMP Echo Reply Message
Is Forwarded
Also, the log on ISA, shows that Ping
was allowed, see
Figure25.
Figure25: ISA Log -
XP Client with ICS Enabled on the VPN
Connection - Foreign Ping
Allowed
So, this time, due to the NAT process
introduced by ICS, the anti-spoofing mechanisms
on ISA can do nothing, because the packets are
sourced with the correct IP address. Another
easy to execute attack.
ISA can reduce
the damages though, if configured correctly, to
allow only needed protocols from the VPN client
to the needed internal hosts, thus to limit
the attack area. With ISA, as opposed to other
VPN remote access servers which allow by
default everything from the VPN clients to the
internal network, you can easily create a
granular policy for specifing users or
groups.
Also application layer filtering is
applied, if available, over the VPN clients'
traffic.
It's always nice to have the practical means
to prevent users doing stupid things.
VPN-Q
2006 easily solves the ICS issue.
A
default check performed by the VPN-Q 2006
Client, is the status of the ICS setting,
see Figure26 and
Figure27. As can be
noted, since ICS was enabled, the client was not
released from quarantine.
Figure26: VPN-Q 2006
Client - Failed: Connection
Sharing
Figure27: VPN-Q 2006
Client - Failed Connection Sharing
Detail: Internet Connection Sharing Is
Enabled
Antivirus Checks
Other default checks performed by the VPN-Q
2006, are the antivirus checks.
It's vital to have an antivirus
solution installed on your machine connected to
the Internet.
And it is also important to
keep the antivirus definitions up to date,
otherwise, the antivirus software becomes
inefficient.
VPN-Q 2006
verifies if an antivirus
program exists on the VPN users's machine,
see
Figure28 and
Figure29.
Figure28: VPN-Q 2006
Client - Antivirus Checks
Failed
Figure29: VPN-Q 2006
Client - Antivirus Checks Failed
Detail: Antivirus Software Not
Found
VPN-Q 2006 also verifies if the
antivirus definitions are up to date.
As can
be noted from Figure30, the
user has installed an antivirus on his machines,
but the anitvirus definitions are out of
date.
Figure30: VPN-Q 2006
Client - Antivirus Checks Failed
Detail: Antivirus Definitions Out of
Date
Also the VPN-Q 2006 verifies if the
antivirus program is enabled on
the VPN users's machine.
Because, usually,
the antivirus programs introduces some
performance issues, and the computer may run
slower, the user can be tempted to disable the
antivirus software, see
Figure31. As can be
noted, this user has disabled the
antivirus on his machines.
Figure31: VPN-Q 2006
Client - Antivirus Checks Failed
Detail: Antivirus Disabled
Personal Firewall Checks
The antivirus is just a part of the protection
suite which must be enabled on your
machine.
It is also very important to have
installed and enabled a personal firewall on
your machine.
By default, VPN-Q requires that minimum the
Windows Firewall to be enabled on the VPN user's
machines.
In Figure32
and Figure33, we can see
that the user has disabled the Windows Firewall,
and has not installed other third-party
firewall.
Figure32: VPN-Q 2006
Client - Firewall Checks
Failed
Figure33: VPN-Q 2006
Client - Firewall Checks Failed
Detail: Firewall Disabled
If the Windows Firewall is enabled on the
client computer, VPN-Q 2006 checks by
default if the File and Print
sharing exception is enabled on the
firewall.
Note that this check is
performed only when the Windows Firewall is
used, if a third-party firewall exists, this
check will not be available.
If the File and Print sharing
exception is enabled on the
firewall, the VPN user will get a
warning, see Figure34
and Figure35.
Figure34: VPN-Q 2006
Client - Personal
Firewall Checks Warning
Figure35: VPN-Q 2006
Client - Personal
Firewall Checks Warning
Detail: File and Print sharing exception is
enabled
As can be seen in
Figure36, a third-party
firewall was installed and is enabled on the
client machines.
Figure36: VPN-Q 2006
Client - Firewall Checks
Detail: Third-Party Firewall
Enabled
Automatic Updates and Security
Updates Status
Ii's not a secret anymore that every major OS
out there has a history of security
patches.
Therefore is critical to make sure
that the OS has installed the latest security
patches.
And it is vital as well to make sure
that an automatic method of updating is in
place. Is hard to keep up by manually updating a
system.
By default VPN-Q 2006 verifies the status of
Automatic Updates. In
Figure37 and
Figure38, we can see
that the user has simply disabled
completely Automatic Updates.
Figure37: VPN-Q 2006
Client - Security Update Checks
Failed
Figure38: VPN-Q 2006
Client - Security Update Checks Failed
Detail: Automatic Updates
Disabled
As can be viewed in
Figure39, the user
configured the updates to be downloaded
automatically, but choosed to install them
manualy, so an update was downloaded but not
installed. If this user forgets or delays the
installation of security patches, he or she may
be vulnerable to certain exploits targeting the
vulnerabilities addressed in those security
updates.
Note that only missing security
patches rated as Critical or
Important will make this check
to fail. Missing ones rated as
Low, Moderate,
Mandatory or unrated will
produce only a warning.
Figure39: VPN-Q 2006
Client - Security Update Checks Failed Detail:
Windows is Not Up to
Date
By default, VPN-Q is not that restrictive in
a good sense. The user may set the Automatic
Updates status to Notify but do not Download,
and carefully keep his or her computer up to
date. If all the security updates were
installed, VPN-Q 2006 will issue an warning, and
release this user from quarantine, see
Figure40 and
Figure41.
Figure40: VPN-Q 2006
Client - Security Update Checks
Warning
Figure41: VPN-Q 2006
Client - Security Update Checks Warning Detail:
Automatic Updates set to Notify but not
Download
Minimum Operating System and
Service Pack Level
Also by default, VPN-Q 2006, verifies
the minimum operating system allowed and
the minimum service pack level installed.
So
at a mimimum: Windows XP Home
Edition SP2, Windows XP Pro SP2,
Windows XP Pro x64, Windows XP Media Center
Edition 2005 or Windows Vista(Home Basic, Home
Premium, Ultimate, Business,
Enterprise) are required.
In
Figure42 and
Figure43 we can see that
this test was passed, because Windows XP Pro SP3
was detected.
Figure42: VPN-Q 2006
Client - System Overview
Checks Passed
Figure43: VPN-Q 2006
Client - System Overview
Checks Detail: Windows XP Pro SP3
Detected
Screen Saver
Status
Another default check performed by
VPN-Q 2006 is the status of the Screen
Saver.
In order to be successfully released
from quarantine, the user must have the Screen
Saver enabled and password protected.
In
Figure44 and
Figure45, we can see
that the Screen Saver was not password
protected, thus the VPN client failed the System
Overview checks.
Figure44: VPN-Q 2006
Client - System Overview
Checks Failed
Figure45: VPN-Q 2006
Client - System Overview Checks Failed
Detail: The Screen Saver Is Not Password
Protected
The maximum allowed wait time is 15 minutes.
You'll get a warning if this period is greater
than 15 minutes, but you'll be released from
quarantine, see Figure46
and Figure47.
Figure46: VPN-Q 2006
Client - System Overview
Checks Warning
Figure47: VPN-Q 2006
Client - System Overview Checks Warning
Detail: The Screen Saver Has a Long Wait
Time
Use
Default Gateway on Remote Network
There is one thing that VPN-Q 2006 does not
verify, and you might desire to verify: if the
Use Default Gateway on
Remote Network checkbox on the VPN
adapter on the VPN client is checked, see
Figure48.
It would be good that once the VPN
client is conencted, to tunnel all the traffic
through the VPN server, since the VPN client's
machine is now a part of the corporate
network. Thus the corporate policies might block
access to porn sites, might block the use of IM
programs and so on.
If this checkbox is not
checked, the user can access Internet resources
directly, and only traffic destined to the
corporat network is send through the VPN tunnel,
thus the user can bypass the company's policies.
By default, with the VPN-Q 2006
default client package, all the traffic from the
VPN client is send through the VPN tunnel.
However, VPN-Q 2006 does not perform any checks
on the above mentioned setting, thus a smart
user might be able to modify the default
settings.
Figure48: VPN Connection
- Use Default Gateway on Remote
Network
