by Rik Farrow
Your organization most likely uses one or more firewalls to control access to your internal networks. You might also use intrusion detection systems (IDS) to monitor internal systems. Your company will certainly be using anti-virus software to detect and remove the malware that so commonly plagues Microsoft systems. And, to provide safe remote access, your organization may use an IPsec VPN (Virtual Private Network) client software so that remote users can securely participate in your internal networks.
But those VPN tunnels can carry a lot more than the traffic than you expect. Most remote VPN client software only directs IP traffic destined for your internal network through the VPN tunnel. All Internet traffic gets routed directly through to the Internet, leaving a way for an attacker to use the remote client to relay attacks through the VPN tunnel.
Farfetched? Not really, as the most popular trojans for Windows
include the relay software necessary to accomplish this, software that can pass an
attack from the Internet, through your firewall using the VPN
tunnel. Trojans can wind up installed
on Windows desktops in many ways, the most common being the use
of Microsoft software, and the spread of viruses that exploit this software.
Securing your network
means securing every remote system that is permitted to connect
via VPN.
VPNs provide an illusion of safety. Just as SSL encrypts data sent from a browser to a Web server, but doesn't protect the Web server from attacks, VPN doesn't protect the internal network either. VPNs do provide confidentiality of transmitted data, data that might include passwords that could be used in attacks against someone's internal network--if they can get inside. And the VPN itself can be the road path through the firewall.
In the summer of 2000, an attacker embarassed Microsoft by using PPTP to gain entry to part of its Redmond campus network. The attacker had installed a trojan that captured keystrokes, and sent those captured keystrokes to an email address in Russia. Those captured keystrokes included the username and password necessary to use PPTP, and authenticate to the Microsoft internal domain account as well. The attacker spent an undetermined amount of time within Microsoft, until an astute system administrator noticed that a new user account had been created, most likely as a side effect of an elevation of privilege attack.
Other VPN products don't rely on domain authentication, like PPTP does. Most VPN products, including popular remote client software in use today implement IPSec (IP Security). IPSec provides standard methods for setting up security associations (paired tunnel endpoints), key exchange, messages integrity, and encryption (encapsulation) of messages. Most versions of IPsec will interoperate today, as long as you can match the IKE (Internet Key Exchange) and IPsec SA (Security Associations) parameters (see Resources).
You can also use SSL/TLS as another method for encrypting traffic. Netscape designed SSL (Secure Sockets Layer) as a method for encryption communication between browsers and Web servers. TLS, Transport Layer Security, is the Internet standard that evolved from SSL. Both rely on the use of digital certificates for authentication, but typically, only the server has a certificate and gets authenticated.
Your more technical users will often take advantage of SSH, the Secure Shell. SSH provides command line access, and can also tunnel other protocols. But, you cannot use SSH in the same way that you use a VPN tunnel, as each protocol requires its own tunnel (with the exception of X Window). Most remote users will be running versions of Windows and using VPN clients with IPSec.
After a remote VPN client has been configured, usually when the IT department adds a new user to the firewall or VPN endpoint, all the remote user needs to do is connect to the Internet. Then, as soon as the user attempts to accesss the internal network, a VPN tunnel into the internal network will automatically be set up (if all goes well). The user can now participate in the internal network, secure in the knowledge that all traffic between the remote system and the internal network is encrypted.
VPN client software does not control what traffic passes into the internal network. And, in most configurations, neither does the VPN endpoint, that may be a firewall, special VPN appliance, or a software server. The VPN endpoint may sit in the firewall, next to the firewall (the Cisco solution), within the internal network, or in front of the firewall (outside or in a DMZ). So, with the exception of the last configuration (outside the firewall) anything an attacker can relay through a remote system shows up on the internal network. Commonly, the address of any attack will appear to be part of the internal network, depending how the VPN client has been configured.
You can configure your firewall, if it is your VPN endpoint, to permit only certain traffic through the VPN tunnel. After all, the VPN tunnel makes a remote system, one over which you have little control, part of your internal network. What happens if the laptop with the VPN client on it gets stolen? Does tunnel setup require at least a password (that doesn't get saved on the laptop itself)? If not, anyone who acquires the laptop has access to the internal network. Likewise, an unprotected file share can expose the client configuration and stored certificiates, permitting someone else to copy the VPN client configuration.
The relay software comes courtesy of trojans. Trojans, like SubSeven (see Resources), include the ability to remotely scan and to relay connections. The attacker can configure the trojan so that it can relay traffic through the remote system into your internal network. The relayed traffic has the same source address as the remote system, and uses the same VPN tunnel. For an attacker, life is good. For the defender, the firewall and VPN do not work as expected.
You can employ software today that provides at least part of the answer
to this problem. Remote systems must be treated like local
systems, that is, be protected by firewall software and
the latest in anti-virus software and signatures. The firewall
software can be a personal firewall, and some vendors, like
SafeNet (www.safenet-inc.com), include a personal firewall
as part of their remote
VPN client. If the personal firewall prevents access to any
relay that is part of a trojan, you have come a good part of
the way to solving this problem. Of course, if the designer
of the trojan has found a way to bypass the personal firewall,
for example, using what appears to be Web traffic coming from
iexplorer.exe, then the firewall may not be enough.
You must have the other piece of the solution, anti-virus software. Anti-virus software has been able to detect known trojans for a long time. Your policy must dictate that remote users employ the latest anti-virus software, and get routine updates, so to avoid infection by a tricky trojan. The policy must also require the use of properly configured firewall software.
Your organization could also take an extra step, although doing may not be simple. The remote system could route all traffic, even Internet directed traffic, through the VPN tunnel. Once within the internal network, the Internet-directed traffic would have to pass through your corporate firewall, which can enforce whatever policies you want on that traffic. A side-effect of this would be to block most relays. Another side-effect, of course, is the increased latency involved in having Internet traffic pass through the firewall not once, but four times: in via the VPN, out to the Internet, the reply back in through the firewall, then out via the VPN to the remote client.
Popular VPN software today does not even make this easy to do. You can do it manually by installing a default route through the VPN tunnel.
Having a policy that requires remote users, whether they are working at home or on the road, use properly configured and updated firewall and anti-virus software is important. Enforcing this policy is a fantasy.
Certainly, if everyone who works in your organization has the utmost regard for security, and rigorously follows your policy, you will not have problems with your remote systems. Experience teaches us that most people disregard security in general, with the more powerful members of an organization often being the worst offendors. It would be nice if there was a software mechanism that could enforce policy, but this is not currently possible.
Software that can enforce policy is itself software that could be replaced or subverted. Even operating systems are not immune to corruption, as kernel modules that subvert both UNIX and Windows server operating systems exist, and can bypass any security regimen. Software that can provide updates, for example, of anti-virus signatures each time a remote user opens a VPN tunnel into the home office, do help. There is a danger that if the update software can be subverted, the security system then becomes as dangerous as SubSeven, yet another RAT (Remote Administration Tool). Still, having a product that can remotely enforce security policies would be a better solution than what we have now.
VPNs that connect branch offices together face similar issues. Does each branch office follow the same security policy? Does the branch office even have a firewall at all? Have they recently updated their anti-virus software? These are the same issues that face organizations that use T1s, or ATM or Frame Relay virtual circuits to connect remote sites together. Each site must have the same security policy, and maintain that security policy at the same level.
As an example, imagine that your organization has offices in another country, and that you have a VPN tunnel between the remote office and your local office. You already know how difficult it is to get your fellow workers to follow good security practices. How are things going in the other country's office? You might just find out the hard way, by means of an attack or virus infection that comes through the VPN.
You can also imagine attempting to achieve good security practices in an e-business environment, where you permit approved business partners access to certain services within your internal network. You have no control over your partner's security policy and practices at all.
The most important things to remember about VPNs are simple. VPNs provide protection against eavesdropping and insertion attacks. A VPN does not stop an attack from being passed through it. You can, of course, terminate the VPN tunnel outside your firewall, on a DMZ subnet, and some organization do this--but not many. You can also apply firewall rules to VPN tunnels that terminate at a firewall. But again, most people don't do this. Like I wrote in my January 2001 column, encryption is not a magic bullet, but just another tool that must be used correctly to succeed in accomplishing its purpose.
CORE Competence VPN FAQ: http://www.corecom.com/external/vpn/vpnfaq.htm
IP Security (IPSec) IETF Charter page, with links to standards (RFCs) and draft standards: http://www.ietf.org/html.charters/ipsec-charter.html
Information on the capabilities of SubSeven, including relaying: http://rr.sans.org/malicious/subseven2.php
Since writing this article, several readers have made me aware that products do exist that can enforce firewall and VPN policies. One reader asked me about ZoneAlarmPro, when I asked him to report his company's experiences with this product, he wrote back later and said that "It seems to work great!" Another product that works in this space comes from Sygate, although my source in this case was the vendor, not a satisfied client. I did spend time talking with Sygate about their approach, and it appears sound and secure.