In today’s networking environment, remote access is almost assumed for companies of all sizes. It gives employees and IT support staff a great amount of flexibility with the option of working from anywhere, not just at home. Of course, anytime you open up your network for remote access, you increase the risk of unauthorized users gaining access to your network.

We don't allow any of our clients to open up remote access without a VPN. When establishing a VPN, make sure to use 3DES encryption (DES can be cracked) or higher to ensure data privacy. Hackers know that VPNs are difficult to hack, so a common tactic is to go after the often poorly protected endpoints (remote user’s workstation) to gain remote access. Remote users can potentially have a variety of hardware, software, and OSs running on the remote computers. If these endpoints are poorly protected, without antivirus and antispyware software and some type of firewall, it’s relatively easy to install a key stroke logger or remote control program and take over the endpoint and gain remote access to the network. Regardless of the VPN solution you implement, we suggest that all remote endpoints are running at least Windows XP with Service Pack 2 (SP2) with the Windows Firewall enabled and a good antivirus and antispyware solution that has current patterns. If you’re unsure of what's running on your remote computers, you might want to take a survey to verify that your remote users have computers that meet your company’s standard.

To establish the VPN, you have a couple of options. One of the most secure solutions is to establish a site-to-site (firewall-to-firewall) VPN. This involves the firewall at the corporate location with a smaller firewall at the remote user’s location. Often if you use the same vendor’s firewall, one of the locations can have a dynamic IP address. Ideally, certificates should be used to establish the tunnel rather than a shared secret that can be compromised rather easily. Placing the remote user behind a firewall protects the remote user as well as any other computer on the remote user’s network. The major drawback is this solution can get expensive relatively quickly because you must purchase a “baby” firewall ($400) for each remote user.

For users that don't connect from a consistent location, carrying around a firewall for remote access isn't very practical. For these users, you can install your firewall’s VPN client software on the laptop to establish the tunnel. If a user is connecting from a random location it's much more difficult for a hacker to track them down, unlike a home user that might be using a relatively consistent broadband connection. If you use this solution, it 's imperative that the laptop has some type of software firewall enabled on the machine because they won't be protected behind a firewall appliance.

What if you have more than a few remote users to support? A Secure Sockets Layer (SSL) VPN might be a good solution. Typically, vendors have solutions that support from 10 to 500 concurrent users. A typical SSL VPN concentrator can range from $500 to $10,000 depending on the number of remote users it supports. An SSL VPN is easier to implement because you don’t have to install a VPN client on each remote computer. These solutions can usually authenticate users from Active Directory (AD), LDAP, RADIUS or an internal database. All that's required is an Internet connection with a browser. If you decide on this remote access solution, I suggest you look for a device that supports two-factor authentication using two physically separate devices. One interesting solution is made by SonicWALL. The company's solution supports a two-factor authentication in which the user requests a remote session, and the SSL VPN Concentrator sends a one-time-use password as a text message to the user’s cell phone. This one-time-use password in conjunction with a user name and password grants remote access to the user. Using the one-time-use password from the cell phone has many of the benefits of a separate authentication method such as Secure ID, tokens, or biometrics without having to implement the infrastructure. Even if a keystroke logger is installed on a remote computer, the hacker must have access to a remote user’s cell phone to gain remote access.

Of course, the biggest downside of this authentication method is the remote user must have a cell phone that is capable of receiving a text message, have the cell phone present when they require remote access, and must be within the mobile carrier’s range to receive the text message. As a possible workaround, your wireless carrier might support receiving text messages from your computer, but this makes the two-factor authentication significantly less secure. Even with two-factor authentication, I still suggest running XP with SP2 and the Windows Firewall enabled. You have several options for remote access. But always use a VPN and protect those remote endpoints!

Tip: SMS Google (in beta)

Google has a neat little service that allows you to send a text message query to 46645 (Googl) and it will send you back answers as a text message. For example, if you text sushi <zip code> or <city> it will answer with all of the sushi restaurants in the requested area. It works with most mobile carriers and answers are usually received within one minute. For more sample queries go to http://www.google.com/intl/en_us/mobile/sms/.