Posts: 5
Joined: 13.Jan.2004
From: Vancouver, BC
Status: offline
If anyone is interested, Microsoft also has a great sample for quarantine scripts that check for a range of items available for free download. As Tom mentions, it requires some scripting knowledge, but I wouldn't consider myself an expert and I can understand and expand on the samples for a slightly customized check. The download is available here. From the readme ... the script checks for the following: 1. Windows Firewall must be enabled on all the interfaces on the client machine. 2. Internet Connection Sharing must be disabled on all the interfaces on the client machine. 3. Password Strength values must meet the configured criteria. 4. Screen Saver must be enabled and password-protected for the current user. 5. Latest Anti-Virus and Virus Signature Files must be installed on the client machine. 6. All the requisite OS Hot Fixes/ QFEs must be installed on the client machine.
You can obviously add or remove as much as you want.
Posts: 64
Joined: 14.Jan.2002
From: Paris
Status: offline
Hi,
Thomas talked about QSS to prevent this security hole.
On this link (http://fesnouf.online.fr/images/QSS3Console.gif) you have a screenshot of the configuration console where you describe your own security policy. Check the "XP Firewall (ICF)" section and you will see that to be proved, ICF must be TRUE and ISHARING must be FALSE.
This is the way you prevent this problem using QSS.
BTW : QSS is free (no limitation, best effort support) as soon as you don't have more that 5 simultanous VPN connections. More info on my web site www.esnouf.net.
quote:Originally posted by Karan Mavai: If anyone is interested, Microsoft also has a great sample for quarantine scripts that check for a range of items available for free download. As Tom mentions, it requires some scripting knowledge, but I wouldn't consider myself an expert and I can understand and expand on the samples for a slightly customized check. The download is available here. From the readme ... the script checks for the following: 1. Windows Firewall must be enabled on all the interfaces on the client machine. 2. Internet Connection Sharing must be disabled on all the interfaces on the client machine. 3. Password Strength values must meet the configured criteria. 4. Screen Saver must be enabled and password-protected for the current user. 5. Latest Anti-Virus and Virus Signature Files must be installed on the client machine. 6. All the requisite OS Hot Fixes/ QFEs must be installed on the client machine.
You can obviously add or remove as much as you want.
Hi Karan,
Exactly. Those are good scripts, but you still need to be a scripting professional to make them work in your own environment and customize them to make them actually work. That's the problem with the MS RQS/RQC. With QSS solution, you don't have to make it a avocation just trying to understand the scripts, troubleshooting and pound your head against the monitor for a week, and then end up giving up because you're not a programmer.
Thomas talked about QSS to prevent this security hole.
On this link (http://fesnouf.online.fr/images/QSS3Console.gif) you have a screenshot of the configuration console where you describe your own security policy. Check the "XP Firewall (ICF)" section and you will see that to be proved, ICF must be TRUE and ISHARING must be FALSE.
This is the way you prevent this problem using QSS.
BTW : QSS is free (no limitation, best effort support) as soon as you don't have more that 5 simultanous VPN connections. More info on my web site www.esnouf.net.
So where's the beef. Exactly how many exploits of split tunneling have you come across or heard about?
As I understand things, IP routing has to be enabled before an exploit is even possible. And, without split-tunneling enabled, the corporate Internet connection is subject to a DOS condition if a Remote VPN users has a worm thats doing heavy scanning, or even if the remote VPN user wants to listening to streaming music. Split-tunneling a danger? it seems like an unsubstantiated assertion to me.
With split tunneling enabled, a trojan on the remote access client can establish a connection to the attackers site, and the attacker can then leverage that connection to attack the corpnet. However, this won't take place when split tunneling is disabled because a well designed firewall policy on the ISA firewall will not allow the connection.
Split tunneling allows a client at a remote location to violate corporate network access policy when the host is connected to the corpnet. Its like turning off the ISA firewall for that host. You woundn't do it for internal hosts, and you shouldn't do it for remote access hosts.
You responded with the classic mantra that's always been associated with split-tunneling. Only I've never heard or read of it actually taking place. Yes, supposely it's this dire threat, but strange isn't it that it never comes to fruition. Perhaps, one reason is that it first requires IP routing to be enabled before it could even be possible, and on a PC that's as rare as hens teeth. As I said in my first post, name some headline instances where it has happened.
What I have seen several times is a VPN user saturate the corp WAN line (i.e. them brainlessly pulling down streaming video, or unintentionally via a worm attempting to scan). This happened because split-tunneling was turned off and ALL traffic flowed thru the Corporate WAN line. So how secure is a self imposed DOS attack.
Worms and trojans are a threat whether split-tunneling is or isn't enabled. Using them as a catch all excuse for old cliches doesn't seem to advance security.
You can enable split tunneling if you like. There's no law that requires that you disable it. Its just one easy thing you can do to provide an incremental improvement to your overall network security posture.
By editing the remote access policy to allow only traffic from that PC, I am referring to the article here http://www.isaserver.org/tutorials/VPN_Client_Security_Issues.html , can you eliminate this split tunnel threat? I realize this article is for ISA2000 but does it apply to ISA 2004 as well? I feel it will be difficult at best making sure everyone leaves their "use default gateway on remote network" setting checked. I am not real sure you can feasibly control that on unmanaged PCs. Besides, they will just uncheck it when it gets in their way.
That's the beauty of QSS or VPN quarantine. You configure your policy to whack split tunneled VPN clients and they get dropped. MS, HP and other large companies I've had the pleasure to work with whack split tunneled VPN clients for good reason.
The truth is that with the new ISA firewall, you do NOT need to allow split tunneling. VPN clients can now access the Internet through the same ISA firewall to which they created the VPN link, *and* they are subjected to corporate firewall policy.
So what if I prefer not to do the quarantine setup. Will the steps in the article I posted be enouigh to mitigate any threats?
quote:Originally posted by tshinder: Hi Ch,
That's the beauty of QSS or VPN quarantine. You configure your policy to whack split tunneled VPN clients and they get dropped. MS, HP and other large companies I've had the pleasure to work with whack split tunneled VPN clients for good reason.
The truth is that with the new ISA firewall, you do NOT need to allow split tunneling. VPN clients can now access the Internet through the same ISA firewall to which they created the VPN link, *and* they are subjected to corporate firewall policy.
No, because the ISA firewall obviates the RRAS packet filters.
On the other hand, you can create very granular and user/group based access controls on VPN clients and what they can access on the corporate network, which does a lot to solve the problem.
For example, most VPN servers just let everyone on the network "party down" as if they were directly connected.
What you need to treat VPN clients as completely untrusted clients and create Access Rules for those clients that match their access requirements and no more.
Posts: 64
Joined: 14.Jan.2002
From: Paris
Status: offline
Guys,
Nice talking about VPN-Q ;-)
One of the things I love with VPN-Q is the fact that I can - as a Chief Security Officer - be 100% sure that in case of a major attack (a strong virus for example), I can prevent 'risky' laptops entering the company (via VPN), BUT, MORE IMPORTANT you can say to the board that the business comin from VPN Access will be back 5 minutes later,... just the time needed to make those remote machine compliant with the security policy remotly.
If you are in a middle of a major attack and if the only solution is to shutdown you VPN concentrator, .. you are in a pretty bad situation to ask for a raise ;-)
I am currently working to promote VPN-Q on the LAN (VPN-Q-OnLAN).. and it goes for machines connected on a switch or for the ones connected by wifi. A lot of fun ;-)
Posts: 1
Joined: 9.Jun.2005
From: UK
Status: offline
Hi Tom, Ive been trying to use a VPN setup as youve described for a ISA 2000 setup non-split, in that remote users cannot access the internet thru ISA over a VPN connected to ISA.
In the article it states that you need to configure the remote client to be a Web Proxy client. Since the PC Ive tested has joined the domain internally over its inbuilt NIC and works fine internally giving Internet access, but when moved outside the building and access the internet over dial up and then connect using VPN, the now remote PC will not access as described. How is the remote PC configured to give internet access thru the VPN?
|
My Subscription |
My Forums |
Address Book |
Member List |
Search |
FAQ |
Ticket List |
Log Out
Printable Version
All Forums >> [ISA Server 2004 Firewall] >> VPN >> Discussion about article on the dangers of split tunneling and ICS 
Discussion about article on the dangers of split tunnel... - 
New Messages
No New Messages
Hot Topic w/ New Messages
Hot Topic w/o New Messages
Locked w/ New Messages
Locked w/o New Messages
Post New Thread