AOH :: ISN-3112.HTM

RE: 10 tips to secure client VPNs




RE: 10 tips to secure client VPNs
RE: 10 tips to secure client VPNs



  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--1457021584-1687728467-1160397191=:27309
Content-Type: TEXT/PLAIN; charset=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE

Forwarded from: Andrew Kalat 

Someone read too much CISSP/MS study material, and didn't spend enough 
time in the field.

I have a number of specific issues with the advice listed below. I'll 
detail them in order and under the number of his specific tip.

1) Lack of any mention of two-factor authentication, and focusing on a 
   MS centric environment is incorrect. The author is arguing about the 
   authentication transport method, and not so much about how secure the 
   authentication is against brute force attack. He makes no mention of 
   disabling an account after X number of bad authentications, or 
   ensuring that automated attacks can be used against the technology in 
   play.

2) This is clearly someone who spent a lot of time working with only 
   Microsoft technology. Anyone who is serious about secure remote 
   access would be well advised to look at industrial class IPSec thick 
   clients, or very secure SSL VPN clientless software. But 
   specifically, the advice to use the strongest possible encryption 
   technology is certainly near sighted at best. Most companies do not 
   need to use CPU intensive 256 bit AES. A strong, 3des, or 128 bit 
   AES, key is fine, and is a good balance between keeping data out of 
   the hands of competitors and not overtaxing CPU time on both ends of 
   the VPN link. The VAST majority of data leakage over VPN is due to 
   misconfiguration by the administrator, or bad implementation by the 
   vendor. Using a high end key that, theoretically, can only be broken 
   by government-level adversaries, is excessive and na=C3=AFve to the actual 
   threats experienced by customers.

3) This feeds into a major mistake this author touts. Remote access 
   VPN's should be limited, by user, to only the specific resource 
   (server, file share, etc) with a specific port (443, 80, 139, etc) 
   for that exact need. This has been in the computer security cannon 
   knowledge for 20 some years. Least privilege access is a good thing. 
   The author seems to assume that any all VPN's give full access to all 
   parts of the network.

4) Is this guy truly arguing that it is safer to allow 
   partners/customer/employees completely web access to a website, and 
   rely solely on the security of the web application to protect the 
   data? It is much more secure to wrap this web site up behind a VPN 
   termination point of some type and have the user have to get past the 
   VPN before even touching the server. The method the author promotes 
   is allowing random anonymous internet users (read, automated scans) 
   to hit this so-called secured server and try any attack they like on 
   it. At will.

5) Wrong, wrong, wrong. Again, this is allowing every attacker to attack 
   the email server at will. Having a VPN authentication point that at 
   least limits the people who can attack the server to authenticated 
   users is much more secure. How can this possibly be a better option? 
   Again, the author must be assuming that any VPN access means full 
   access to every resource in the company.

The authors tips 6 through 10 are at least somewhat more sensible. 
Though, I would argue that any properly designed VPN termination point 
would also be applying IPS technology to spot any attacks coming from 
properly authenticated users, including automated worms that the user my 
unknowingly be launching. Further, limiting access to the network from 
the VPN can mitigate some of this risk.

Some of these suggestions may be valid for the smallest and least 
sophisticated companies, but can mislead a more robust organization. I 
hope my points above give more insight into this.

Rants/comments/flames can be sent to lerg@lerg.org. 

Lerg

-----Original Message-----
From: isn-bounces (at) infosecnews.org 
[mailto:isn-bounces(at) infosecnews.org] On 
Behalf Of InfoSec News
Sent: Thursday, October 05, 2006 4:42 AM
To: isn (at) infosecnews.org
Subject: [ISN] 10 tips to secure client VPNs

http://www.computerworld.com/action/article.do?command=viewArticleBasic&taxo 
nomyName=security&articleId=9003779

By Martin Heller
October 02, 2006
Computerworld

If you have given your trusted employees and key contractors remote access
to your network via a client virtual private network (VPN), congratulations!
By now, you have seen the productivity and cost benefits from allowing
collaboration that surmounts geographical separation.

You may also have discovered that keeping your network secure is now even
trickier than it was, because each uncontrolled remote computer potentially
creates another avenue of access to the network for attackers. Here are 10
tips to help secure your network while ensuring the benefits of your VPN.

[...]


--1457021584-1687728467-1160397191=:27309
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_________________________________
Donate online for the Ron Santo Walk to Cure Diabetes!
http://www.c4i.org/ethan.html 
--1457021584-1687728467-1160397191=:27309--

Site design & layout copyright © 1986-2014 CodeGods