Use OpenSSH and Squid to create a non-Microsoft VPN
Connecting to the Internet while traveling can sometimes be dangerous, especially over open, unencrypted networks, such as those found at hotels, coffee shops, conventions, and sometimes even at client or business partner sites.
To give you an example, at the 2006 DEFCON 14 hacker convention in Las Vegas, hackers sniffed the public wireless network airwaves to discover all sorts of information from people who didn't bother to encrypt their network traffic. The hackers then posted those details on a "Wall of Shame" for everyone to see. As a result, a lot of people's sensitive information, including banking and business information, was compromised.
You can, of course, use a VPN to establish secure connectivity when you're mobile so that you don't fall victim to snoops. If you want a lightweight VPN solution that's easier to install and manage than other solutions, check out the OpenSSH VPN tool and the Squid for Windows proxy server (formerly SquidNT), both of which are free.
WHAT YOU NEED:
Open SSH and Squid for Windows
OpenSSH is based on the popular Secure Shell (SSH) technology, and Squid for Windows is based on the popular Squid proxy server, both of which were originally developed for UNIX and Linux platforms. OpenSSH and Squid for Windows are versions of those tools, which have been designed specifically to run on Windows platforms. One major benefit of using these tools is their simplicity and portability. They're easy to install, require very little configuration and management, and the solution works on nearly any client OS today, which means you can install this solution on two desktops if you want, instead of needing a dedicated server platform. These benefits are, of course, not the case with other proprietary solutions. Note that any client software you use must be able to support the use of a proxy server to communicate over this VPN solution. If you want to implement this solution on another platform, such as Linux, BSD, or OS X, then simply obtain OpenSSH and Squid for those platforms and use the same principles that I provide in this article.
I'll show you how to build a VPN server and client, collectively referred to in this case as "VPN," step by step, by using the OpenSSH toolkit and Squid for Windows proxy server, which you can run on nearly any Windows system. This solution will let you move all your mobile-client traffic over an encrypted connection through the VPN and then out to the Internet or to systems on the network on which your VPN server resides.
An added benefit of this solution is that you can use it to remotely manage the server that runs OpenSSH or any systems that you have access to through the OpenSSH server (e.g., other systems on the same network). This is possible because when you connect to the OpenSSH server, you get a command-line prompt, which is actually a remote command shell running on the OpenSSH server. In that command shell, you can run any Windows commands or command-line tools that you have permission to access under the account with which you logged on. So if you want to manage other systems by using the OpenSSH connection, plan ahead by copying any tools that you might need onto the server before you head out on the road, or make sure you have access to other remote servers where any required tools might reside. If you need to manage other systems over the OpenSSH connection, you should probably use domain authentication (which Step 1 describes) so that you have proper permissions on those other systems.
How It Works
The OpenSSH/Squid for Windows solution is relatively simple. You install OpenSSH on a server and on any clients. You install Squid for Windows only on the server system. On the client side, OpenSSH connects to your OpenSSH server and opens a separate port on the client computer to listen for client traffic on the localhost address. You configure your client applications (Web browser, email client, chat client) to use a proxy server with the localhost address. The client applications then send traffic to the OpenSSH localhost port, which routes the traffic to the OpenSSH server over the encrypted connection. The OpenSSH server then receives that traffic and routes it to Squid for Windows, which in turn sends that traffic on to its destination. Although this might sound a bit complex, once you try it you'll see that it's very easy to understand and implement.
To implement this solution, you'll need one computer to use as the VPN server and at least one mobile computer to use as the VPN client. OpenSSH and Squid for Windows don't require much memory or CPU time, so you can easily run both on nearly any server that mobile computers can reach from the Internet. You could also build the VPN server on a computer on your home network, and if your company policy allows for it, build on the company network instead. Be sure to read this solution in its entirety before you implement it.
Step 1: Install and Configure OpenSSH on the Server
To get started, download a copy of OpenSSH (http://sshwindows.sourceforge.net/download) and install it on your server by using the installation wizard. This is a straightforward process and doesn't require any special knowledge.
After you install OpenSSH, I recommend that you edit the default configuration so that OpenSSH runs on some port other than the default port 22. Running on a port other than 22 makes it harder for intruders to discover the OpenSSH server by performing a port scan of the machine. Intruders expect an SSH server to listen on port 22, so if you move it to another port, then they'll have a harder time figuring out what service is listening on that port. To change the default port, go to your OpenSSH installation directory and navigate to the etc subdirectory. Edit the sshd_config file and adjust the port parameter to an unused port number on your system. In this article, I use port 422. If you're unsure what ports might be available, use the netstat -an command, to view all open ports. Any port not in the list could probably be used for OpenSSH. Just be sure to remember the port number because you'll need it to log on to the OpenSSH server later.
Then you must also create a group file and a passwd file, both of which determine who is allowed to log on to the OpenSSH server. The group file contains a list of groups extracted from the local system's Windows registry, which OpenSSH uses to map permissions similar to the way Windows does. The passwd file contains a list of users, also extracted from the local system's registry, who are allowed to log on to the OpenSSH server.
To create the group file, change to the OpenSSH bin subdirectory and type the following command:
mkgroup -l >> ..\etc\group
This command dumps the local registry's groups into the group file in the etc subdirectory.
Next, use the following command to create the passwd file that authorizes users to log on to the OpenSSH server:
mkpasswd -l -u XYZ >> <p> ..\etc\passwd</p>where XYZ is your local logon name. This command dumps the XYZ user's credentials from the local registry into the etc\passwd file. Do this for each user for whom you want to allow access.
If you want to use Windows domain accounts for authentication, use the same two commands with a -d switch instead of the -l switch and specify the appropriate Windows domain. The mkgroup command will contact your PDC for the specified domain to obtain the list of groups and accounts. Creating these two files is pretty simple, but see the OpenSSH documentation if you need more help.
If the username and password logon method isn't strong enough authentication for your needs, you can use even stronger authentication by implementing encryption keys on your OpenSSH installations. I don't have room to cover that subject here, but you can find step-by-step instructions in the key_authentication. txt file located in OpenSSH's docs\OpenSSH directory. It's relatively simple to accomplish.
Note that OpenSSH installs itself as a Windows service that automatically starts each time the system is booted. If you don't want the service to start automatically, you need to adjust the service properties to require a manual start. On Windows Server 2003, Windows XP, and Windows 2000 systems, you can adjust the service properties by using the Computer Management tool in Administrative Tools. Go to Services and Applications\Services, rightclick OpenSSH service, select Properties, then adjust the startup mode accordingly.
Step 2: Install and Configure Squid for Windows
Next, install Squid for Windows (http://www.serassio.it/SquidNT.htm) on your server system (e.g., not your mobile computer). To configure Squid for Windows, I recommend that you download and use Kraken Config for Squid (http://www.krakenreports.com/index.php?subPage=krakenConfig), which greatly simplifies configuring the proxy server. Kraken Config has a simple wizard that asks you for some basic parameters, including the local host name, disk cache size and the amount of memory Squid is allowed to use, allowed network addresses, and a few other simple details. The tool costs only $10 and, in my opinion, it's worth every penny. You can test-drive it free for 30 days, after which the monitoring features will become disabled, but even so, your Squid for Windows configuration will continue working.
After you run the Kraken Config tool, edit the squid.conf file (in Squid for Windows's etc subdirectory) to add a line such as the following:
This tells Squid to listen only on the localhost address (127.0.0.1) on port 3128. It's important that you add this line with the http_port directive. If you don't, Squid for Windows will use the system's real IP address, which will cause Squid for Windows to be exposed to your local network and possibly the Internet, where others might be able to connect to it. Note that you can choose any unused port number you prefer, but you need to remember this port number because you'll need to connect to it in Step 4.
Incidentally, another benefit of using Kraken Config is that when you start the Squid for Windows service, Kraken Config's dialog window, which Figure 1 shows, will appear so that you can monitor Squid for Windows and make configuration adjustments.
Like OpenSSH, Squid for Windows installs itself as a Windows service that automatically starts each time the system is booted. You'll need to adjust the service properties if you require a manual start. To do so, follow the same instructions as described near the end of Step 1.
Step 3: Install OpenSSH on the Client Computer
Next, you need to install a copy of OpenSSH on your mobile computer system. Because you're using your mobile computer as a client and not as an OpenSSH server, you don't need to configure anything after installing the OpenSSH software on your mobile computer. Just remember where you installed the software, so you can access the ssh command-line tool to connect to your newly built OpenSSH server.
Again, remember that OpenSSH installs itself as a service set to start automatically. It's probably a good idea to set the service to start manually on your client system, unless you're sure that you'll use it frequently.
Step 4: Fire Up the Server and Connect
Now you're ready to start the OpenSSH and Squid for Windows services (if they aren't already started) on the server and test client connectivity. After you start the server services, on your mobile workstation, open a command shell and navigate to the bin subdirectory of your OpenSSH installation, in which you'll find the ssh command-line tool. Log on to your OpenSSH server by using the following command:
The -p 422 parameter tells the ssh client to connect to the OpenSSH server on port 422 (or the port number you defined in the OpenSSH configuration in Step 1). The -L parameter causes the ssh client to open port 3127 on the local machine and forward traffic sent to that port to port 3128 on the remote system, which is your Squid for Windows proxy server's port. If you used a different port number for Squid for Windows, be sure you adjust the command appropriately. XYZ is your username, and IP is the IP address of your OpenSSH server.
You can use any unused port number in place of 3127 on the client. Remember the port number because you'll need it when configuring client applications in Step 5.
After the ssh client opens the connection between your mobile system and your remote OpenSSH server, you'll be prompted to log on. Be sure to use the same username and password to log on that you defined in Step 1. This is either your local Windows username and password on your OpenSSH server or your domain username and password as derived from your domain controller (DC), if you used that method of creating the group and passwd files.
Step 5: Configure Your Client Applications
With the encrypted connection open and ready to use, you can configure your Web browser (and other necessary applications) to use the Squid proxy server. Be sure to set the proxy server address to the localhost address 127.0.0.1 on port 3127 (or the port you used on your local client computer).
When you configure your client applications to use a proxy server (which in this case is actually the SSH client running on your local system), all your network traffic will be tunneled over your secure encrypted VPN connection, which is routed through your OpenSSH server to its destination, as Figure 2 shows. However, if your applications don't support proxy connections, their traffic won't be tunneled over the secure connection and instead will travel directly over your regular network connection.
That was easy, right? Even though this solution takes only a few minutes to implement, you might consider making a copy of your OpenSSH server and Squid for Windows configurations on portable media such as a flash drive, so that you can rebuild the server side of the solution on another server much faster in the future.
Also, be sure you test this solution before you go on the road, because your client, server, and network border firewalls might need adjustments to port settings or general rules for the OpenSSH and Squid for Windows services to work correctly. And finally, if your network uses Network Address Translation (NAT) and your OpenSSH server has a NAT address, you might need to configure port forwarding on your firewall to ensure that overall routing and connectivity works correctly.