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: as 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 website or email, 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.
Thomas Alexander Lancaster IV is a consultant and author with over ten years experience in the networking industry, focused on Internet infrastructure.
