Re: SBS 2003 R2 limited to 5 VPN connections although I have a 30
- From: "Dana Epp [Security MVP]" <dana@xxxxxxxxxxx>
- Date: Thu, 1 Jan 2009 12:08:16 -0800
Hey Leythos,
Interesting concept. This could indeed provide a good secure tunnel across an insecure network like the Internet. That is the whole point of VPN. However, that shouldn't be the point here. As an effective solution to reduce risk from remote users who will be trying to access corporate resources, I think you are missing a few elements that may not make it an appropriate safeguard to protect business information systems and assets for most organizations.
Firstly, in the world of small and midsized businesses, creating NEW identity silos is typically a bad thing. If you introduce a VPN appliance that ends up having yet ANOTHER password you are reducing the effectiveness and use by end users as they have to remember more information, creating the risk that they will use weak ones, or be forced to write more complex ones down. Where? Usually near the remote machine or laptop. We routinely find during audits users writing down VPN gateway credentials and LEAVING them in the laptop bag, making it effectively useless. Worse, during staffing changes it is typical for IT to forget about the appliance, leaving an entry point into the network unmodified and unprotected. Sometimes for months or years. That becomes an unneccessary attack vector we shouldn't have to worry about.
You could of course use an appliance that will use the domain credentials. Many support LDAP and make that feasible. However, that is just as much a risk since if the credential is shared, stolen or easily guessed now an untrusted user has full access and privileges as that account. Including getting to log into a terminal services session after the VPN is established. And we have seen this happen. Salespeople share credentials, access resources irresponsibly and the business has no recourse as they have no way to prove WHO used the credential. Actually, this is an example of a weakness in how RWW may function in its default configuration as well, since it becomes at attack vector in itself as you have no way to prove the identity of the incoming user to the portal. So it doesn't really matter at that point if its RWW or VPN.
Charlie's recommendation of using AuthAnvil with RWW has many benefits and overcomes all this. First off, there is no need to secure and maintain a secondary security appliance. Unless the VPN is SSL-based, you also have to consider the common problem where the appropriate ports may be blocked by firewall policy on either end, and you may need to distribute and configure VPN clients. Secondly, there is no need to manage two sets of authentication credentials for the end users. Makes it easier for the user, and IT management. You can use your Windows credential as you would normally in RWW, and then use a one-time password (OTP) dynamically generated on an AuthAnvil keyfob token. Once logged in, if you attempt to connect to another system behind RWW via proxied rdp, you can be further challenged for the next OTP if you deem the security policy requires it. A good example where to use this may be an application terminal server with critical LOB apps. In both your VPN and RWW scenario, you are exposing access to the TS. If the session is left unattended and someone knows the Windows credential, they will be able to get in. Let's assure we know WHO it is. VPN will do nothing to help this.
Of course, if you feel a VPN solution is appropriate for you, that's OK. It's your network. But it isn't MORE secure that RWW. Far from it. You still have risk in relation to the device and identity assurance. You have more administrative burden in configuring and managing the appropriate access policies on the appliance, as well as maintaining credentials. And you are providing a layer3 connection to the network. If the appliance is in any way misconfigured you now have an untrusted source (the remote host) which is not under your control polluting your network. Why even expose yourself to such risk?
Security is about risk mitigation. Not risk avoidance. You have to balance the effectiveness of the security safeguard against the usability that affects the end user. If you are going to use VPN as a router end-point, consider using something like AuthAnvil and configure your VPN appliance to do authentication via RADIUS. In this way, you can use a strong authentication credential that will provide you the confidence that the remote user is who they say they are. Which is the whole point of identity assurance, and a critical component you need to consider when looking at remote access. Furthermore, you won't have to manage a secondary password database, and you can reuse AuthAnvil elsewhere such as on that Terminal Server to provide further protection.
At that point though, it would be far easier to just use AuthAnvil with RWWGuard on SBS. Eliminate the need to even use VPN, or significantly reduce its risk exposure by reconfiguring RRAS to use RADIUS and force a strong authentication identity check before they gain access. No need for the VPN appliance at all.
---
Regards,
Dana Epp
[Microsoft Security MVP]
"Leythos" <spam999free@xxxxxxxxxx> wrote in message news:MPG.23c5accc101f0049897c4@xxxxxxxxxxxxxxxxxxxxxxx
In article <u9ByNQ3aJHA.3952@xxxxxxxxxxxxxxxxxxxx>,
charlie@xxxxxxxxxxxxxxxxxxxxxxx says...
I would disagree. Not that the connection isn't secure - I think it is. But
you've now granted level 3 access to an essentially uncontrolled external
PC. If it's owned, your network is owned. I much prefer RWW, which keeps any
external machines from being a direct part of my network.
Wrong, you're still thinking unrestricted access and firewall, which are
not the same.
VPN TO firewall appliance, non-Domain user/password (first combination)
VPN Rule permits ONLY TCP3389 between VPN User IP and Terminal Server,
no other ports.
Remote user connects using Remote Desktop to Terminal Server (or
workstation if you setup a rule for that) and has to login with Windows
user/password - second combination - not same as first).
Only TCP 3389 traffic can pass, requires two different passwords,
limited to TCP 3389 only....
Seems to me that this is MORE secure than RWW.
Most people don't know how to configure a firewall, nor do they know
much about VPN security. In every case we setup VPN connections to only
allow the ports needed, and that means 3389 is about the only port we
allow via VPN sessions.
--
- Igitur qui desiderat pacem, praeparet bellum.
- Calling an illegal alien an "undocumented worker" is like calling a
drug dealer an "unlicensed pharmacist"
spam999free@xxxxxxxxxx (remove 999 for proper email address)
.
- Follow-Ups:
- Prev by Date: Re: SBS 2003 R2 limited to 5 VPN connections although I have a 30
- Next by Date: Re: SBS 2003 R2 limited to 5 VPN connections although I have a 30
- Previous by thread: Re: SBS 2003 R2 limited to 5 VPN connections although I have a 30
- Next by thread: Re: SBS 2003 R2 limited to 5 VPN connections although I have a 30
- Index(es):
Relevant Pages
|
