Secure your extended networks

Tom Lancaster discusses the security liabilities of VPNs.



VPN tunnels are a fantastic way to save money by replacing leased-line services, or by allowing remote users access

to an internal network without exposing your data to the world as it traverses a public network such as the Internet. In that sense, VPN tunnels are considered a security feature. However, they can also be a liability.

The fundamental problem is the way many network architects view security: an inside versus outside challenge, where defenses are deployed around the 'perimeter' of the network. This rests on the assumption that things on the inside are trusted and things on the outside are untrusted. (Hint: Half of that statement is true.) Since this view of network security isn't likely to change soon, security in the forseeable future will continue to consist of firewalls and proxy servers, etc. placed on the perimeter, but VPN tunnels often extend that perimeter in ways that are far more risky than adding a comparable number of network nodes on the "inside."

This risk is due to a number of factors. Branch and small offices typically have relatively less physical security. They are more likely to have incoming analog lines attached to modems. Remote users often have home LANs with unprotected Internet access or unprotected wireless access points. Remote users are more likely to get viruses and less likely to scan for them. The centralization and reduction of network and security staff may make it more difficult to tell when remote users are non-compliant with corporate security rules. The list goes on.

The point is that if you want to think of network security in terms of 'inside' and 'outside', consider putting remote users in the 'outside' category, or at least a 'not quite inside' area. As a practical matter, consider the following:

  • Place packet-filtering rules on tunnels to allow only packets from devices on that network through the tunnel. This may help prevent access from other networks you may not know exist. Put anti-spoofing rules in there too.
  • If possible, block inbound traffic from devices such as printers and servers, which do not normally initiate connections.
  • If possible, further restrict the packets based on protocols. If the users only need access to an internal Web site or e-mail, block everything else. Definitely block ICMP, SNMP and other problem traffic.
  • Consider using a proxy that requires authentication that is different from the username and password required by the VPN.
  • Review your auditing policy to ensure that remote PCs and networks aren't neglected.

About the author
Thomas Alexander Lancaster IV is a consultant and author with over ten years experience in the networking industry, focused on Internet infrastructure.


This was first published in October 2002

Dig deeper on Security Resources

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchConsumerization

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly

Close