WAN lockdown

Among the estimated half-million computers infected with the Blaster worm by the end of August, many tens of thousands were behind corporate firewalls specifically configured to prevent that class of attack. The vulnerability was the WAN -- remote users connected via VPN to a LAN, tunnelling in to the protected network as trusted nodes.

WANs are the proof that if you cast your net wide enough, you'll catch something nasty. The industry is realising that while networks confined to company premises can be controlled using the normal mix of security procedures, a different management policy is required to secure any system where remote users have access to corporate resources. While the classic model of WAN nodes connected over VPN treats them as members of whatever local network they connect to, it ignores the reality that the same computers have another life when not connected, one where they can be very vulnerable indeed.

In the days when WANs ran exclusively over private networks, management and security could sensibly consider them as networks of LANs, all with well defined and centrally controlled borders. There were and are management problems with this model: WAN links are always slower than the LANs they connect, and poor topology and choice of server siting can create big performance problems, compounded by a lack of understanding of what traffic is actually being carried. But security -- always a bigger issue than mere performance -- is not much more of a problem here than with networks confined to one location.

Convenience, cost and changing working patterns mean that WANs are increasingly implemented by IPsec VPN links over the public Internet, extending via broadband to home workers and via the PSTN or cellular networks to the mobile workforce. This changes the picture more than the cute little diagrams of clouds and VPN routers let on. If the same remote PC is used for private Internet access when it's not connected to the VPN, it can be a security risk. The user logs onto the Internet and gets hit by a worm or downloads a virus: as soon as that machine subsequently connects to the WAN, the worm finds itself behind your firewall and can infect everything it sees. More worryingly, viruses designed to implant remote control back doors in computers can silently tunnel back out of your network and establish links to hackers through your firewall. The Trojan horse analogy is entirely apt.

One solution is to use thin clients to connect to services such as Citrix's MetaFrame. If those clients are physically incapable of connecting to any other service, then they can be managed as if they were ordinary network nodes -- this may be appropriate for retail sites, warehouses and other disparate workplaces. For users who have a full PC or laptop, though, while it is certainly possible to run thin-client software on those platforms it doesn't stop them also connecting to the Internet.

Another option is to have a firewall with hardware VPN and routing functions at the user's end, connected to their broadband access. The firewall should do stateful packet filtering, Layer 7 filtering, DoS control, authentication and IPSec termination, and this will prevent a large number of attacks from propagating from the user's PC. As well as working well for remote sites with more than one user, this approach means that individual PCs don't have to have VPN client software loaded, and with stateful packet routing the firewall can direct some traffic out to the Internet, only passing onto the corporate WAN appropriate connections. Also, the router can manage NAT address allocation, which helps WAN IP address management issues.

However, this will not stop the basic problem that to be productive, a remote user must have some form of privileged access to the corporate network and that any attack software running on their PC will acquire those privileges. You must ensure that all remote PCs that connect to the work WAN have up-to-date virus scanning, a properly configured personal firewall, and that strong policies exist to encourage the users to act responsibly. Remote management is essential, and some form of encryption of data local to the user should be considered: PCs can be stolen, and laptops lost. If a computer has corporate information on it, it's part of the WAN even when not connected and must be managed.

Wireless LANs at home are also problematical. Although a PC running IPsec across a wireless link will have a high degree of inherent protection against snooping and hijack attempts, it is hard to ensure that work data never gets transmitted in clear -- and the various vulnerabilities of improperly configured wireless access points are no less dangerous in the home environment. It is possible to have a wireless segment at the remote part of the WAN, but it must be configured as tightly as any within the corporation.

These policies may seem unduly restrictive and expensive, especially when -- as so often -- the remote WAN node is an employee's own personal computer and the connection at least partially funded by the user for their own domestic use. It is entirely possible that this solution, economically attractive as it is for the company, is never going to be secure enough in any case, and only computers conforming to the company's existing acceptable use policy should ever be connected to the WAN. That's also only fair to the employees, who may habitually use their PCs at home for things acceptable there but damaging to the company should they occur from within the network. It's easy enough to forget that the VPN is active when accessing an Internet service for personal reasons, but the resultant traffic will appear on the Internet as if it came from within the company and travel through the internal networks.

As the pressures on companies to maintain internal data security mount, for regulatory as well as for purely commercial reasons, security management policies must reflect the real world rather than that depicted in network diagrams. WAN access is a great benefit to a company, but it must be realistically assessed for its potential downside.