Virtual Private Networks

Companies used to create private networks using expensive point-to-point data lines from the phone company to keep their information safe. These lines cost thousands of dollars per month per location and linked only two sites at a time. Companies often ended up with a spider web of expensive communication lines connecting their sites. With the advent of the commercial Internet, people immediately saw its potential for interoffice communications. Unfortunately, the open nature of the Internet presented a major security risk. This is where encryption came to the rescue. By using encryption technology, companies can create a Virtual Private Network (VPN) and harness the low-cost Internet for their corporate communications, safely and securely. Their data is encapsulated in a "tunnel" of encryption, so any parties intercepting the packets in between cannot recover any usable data.

There are many vendors selling dedicated hardware devices to do virtual public networks. However, there is an open source solution that will let you set up your own VPN with nothing more than a couple of extra PCs.

FreeS/WAN: Open Source IPsec VPN Software

The FreeS/WAN project is sponsored and managed by John Gilmore. John is a legendary name in coder and net-libertarian circles. He is one of the founders of the Electronic Freedom Foundation, which was an early proponent of free strong encryption. After making his fortune in several Silicon Valley start-ups, most notably Sun Microsystems, he now dedicates his time to various projects, many of them open source software–related.

The FreeS/WAN project started as an effort to have everyone encrypting his or her communications. While it hasn't quite had this effect yet, it does offer users of Linux a cost-effective way to set up a VPN. It also allows you to connect to other devices using IPsec, since the IPsec protocol is a widespread standard. Some vendors may not stick precisely to the standard, so your results may vary when using other equipment or software for one of the ends. Check the FreeS/WAN Web site for a list of compatibility with other vendor's implementations.

Using IPsec, everything is encrypted at the IP level, regardless of the application or port. This is what makes IPsec the most popular system for creating secure communications. FreeS/WAN also can use what is called opportunistic encryption, which means it will use encryption to communicate with hosts that support IPsec, and will use regular IP communications for those that don't. So if you run FreeS/WAN on your firewall box, you can have an automatic VPN to sites running IPsec and still interoperate with other sites that don't.

You need two machines to act as your gateways. To use FreeS/WAN, these machines must be UNIX boxes, preferably Linux. If you want to set up an IPsec connection between Windows systems, you can use the built-in IPsec support (Windows 2000 and later) and don't need FreeS/WAN. Supposedly, the newest Linux kernel is going to have IPsec integrated into it. But even when it does, FreeS/WAN will still have an application for communicating with older versions and using the opportunistic encryption feature. The FreeS/WAN team is also working on interoperability with the upcoming Linux kernel IPsec support.

Installing and Starting FreeS/WAN

FreeS/WAN comes preinstalled on many Linux distributions. To see if you have FreeS/WAN installed, type ipsec verify at the command line. If you get a "file not found" response, then you don't have it preloaded. Even if you don't have the RPMs, you can get the source code from the book's CD-ROM or you can download the latest version to take advantage of the latest cryptographic protocols and features. Follow these instructions to compile FreeS/WAN from source code.

Download the latest package from the Web site and unzip it, or copy the file from the CD-ROM.
Run the following commands as root from the FreeS/WAN directory to compile and install the package:
```
Make oldmod

Make minstall
```
Once FreeS/WAN is installed, you need to reboot your system for the changes to take effect.

When your system comes back up, use the verify ipsec at the command line to check your install. You should see a message something like this:


Checking your system to see if IPsec got installed and started

correctly

  Version check and ipsec on-path                     [OK]

  Checking for KLIPS support in kernel                [OK]

  Checking for RSA private key (/etc/ipsec.secrets)  [OK]

  Checking that pluto is running                      [OK]

  ...

If you see this, you can start the IPsec service using this command:
```
service start ipsec
```

The IPsec service runs in the background. You are now ready to initiate IPsec sessions.

Using FreeS/WAN

There are several ways to use FreeS/WAN. One is for a gateway-to-gateway permanent connection, which is called peer-to-peer mode. This mode is appropriate if you have two offices wanting to communicate securely over the Internet. The second method is called road warrior mode, where you have remote users wanting to connect securely to your LAN. Finally, you can operate in Opportunistic Encryption (OE) mode, in which it connects with encryption to any hosts or gateways that are capable of it. The following procedures describe how to set up each one.

Peer-to-Peer Mode

FreeS/WAN uses the names Right and Left to refer to the two machines you are connecting via IPsec. This doesn't have anything to do with direction or location; it just makes it easier to refer to the different sides of the IPsec connection. Just pick one to be your Left machine and one to be your Right machine.

First, get on one machine that you are going to call the Right machine. Type the following command to get its public key:
```
ipsec showhostkey --right
```
FreeS/WAN shows you some information about the IPsec on that machine, including its public key. After the equals sign will be a long list of seemingly random digits. This is the key. Copy this number down or use the copy function in your text editor.
Now get the public key from the Left machine by using the same command, except use the --left switch in the command.

Go to /etc/freeswan and edit the file ipsec.conf (some distributions may store this file in /etc). Table 9.2 lists and describes the parameters you need to set in the conn net-to-net section.

Table 9.2. FreeS/WAN Parameters
Parameters
Description
Left
The IP address of your Left IPsec gateway.
Leftsubnet
The range of IPs behind the Left gateway.
Leftid
The host name in a fully qualified domain name format and with an @ in front of it. For example, @gateway.example.com.
Leftrsasigkey
The key you copied earlier from the Left machine.
Leftnexthop
The default gateway for the Left machine. The default setting should work in most cases.
Right
Same as Left above but for the Right machine
Rightsubnet
Same as Leftsubnet above but for the Right machine.
Rightid
Same as Leftid above but for the Right machine.
Rightrsasigkey
Same as Leftrsasigkey above but for the Right machine.
Rightnexthop
Same as Leftnexthop above but for the Right machine.
Auto
The default setting of add authorizes the connection but doesn't start it up when the system is booted. If you want it to start automatically, change this to start.

Leave the rest of the settings as is and save the file.
Copy this file onto the other machine in the same place.
Use the verify ipsec command described earlier to be sure that the IPsec service is running on both machines
To start up the IPsec connection, type:
```
ipsec auto --up net-to-net
```
You should see the message IPsec SA established. If you don't, check your settings or consult the man pages for troubleshooting information.

If you are running a firewall with NAT, you may have to write a special rule in your firewall so that it doesn't translate the network address of that machine. Many newer firewall models automatically recognize IPsec packets and pass them through unchanged so this extra step is unnecessary.
To test your connection, try pinging an internal address on the other side of the remote gateway. If you get a successful response, then you have an IPsec tunnel up and running.
If you really want to verify that the packets are being encrypted, use a packet sniffer such as Tcpdump or Ethereal to see if you can read any of the packets. If the sniffer identifies the packets as ESP packets (ESP is one of the IPsec subprotocols) and the packet payloads come up looking like gibberish, then all is working correctly.
If you want to add multiple net-to-net connections, you can just add another section with a new title such as conn office1-to-office2. You can also rename the original net-to-net connection name as long as it is the same in the ipsec config files on both machines.

Road Warrior Mode

This procedure is fairly similar to the last one, with a few exceptions. In this mode, the Right machine is the local machine on your IPsec gateway and the Left machine is your remote user.

On your remote machine, edit the same /etc/freeswan/ipsec.conf file using the following template. It looks similar to the net-to-net configuration with a few differences.


conn road

  left=%defaultroute

  leftnexthop=%defaultroute

  leftid=@tonyslaptop.example.com

  leftrsasigkey=0sAQPIPN9uI...

  right=192.0.2.2

  rightsubnet=10.0.0.0/24

  rightid=@gateway.example.com

  rightrsasigkey=0sAQOnwiBPt...

  auto=add

The remote configuration uses %defaultroute to pick up your dynamic IP.

The Right side should contain the information for the gateway. Get on the gateway machine and use this template for that ipsec.conf file.
```
conn road

  left=192.0.2.2

  leftid=gateway@example.com

  leftsubnet=192.0.2.1/24

  leftrsasigkey=0sAQOnwiBPt...

  rightnexthop=%defaultroute

  right=%any

  rightid=tonyslaptop@example.com

  rightrsasigkey=0sAQPIPN9uI...

  auto=add
```
Notice the entries are reversed on the gateway, using left for the Local machine and right for the remote. Also, the right IP is defined as %any. This is a wildcard that allows any IP address, since you won't learn it until the remote user tries to connect.
Save this file.
You are ready to connect. Make sure that IPsec is up and running on the gateway machine, and then type the following command on the remote user end:
```
ipsec auto --start road
```
This should initiate the connection as before. If you don't get the message Ipsec SA established, check your settings or refer to the troubleshooting section on the FreeS/WAN Web site.
Test and verify the connection in the same manner as the net-to-net procedure.
You can set up multiple remote connections as in the previous procedure and rename them whatever makes sense to you.

Opportunistic Encryption

If you want to do this with FreeS/WAN, your gateway box must not be behind a firewall doing NAT (the change in the IP address in the headers messes up the IPsec header verification mode). It is preferable to have a static IP address on your gateway box. There are two ways to do OE: full or partial. In the full OE you can initiate outward IPsec connections and other IPsec hosts can initiate OE sessions with your gateway. In partial mode, your gateway must always initiate the connection. Both OE modes require you to have access to the DNS record for the hostname you want set up.

Setting Up a Partial Opportunistic Encryption (initiate only)

First, edit the DNS record for the host name that you intend to use to add an entry for your key. The DNS record must match the ID you use in the ipsec.conf file. In the Road Warrior example earlier, that was gateway.example.com. Issue the following command on your gateway machine to create this record:
```
ipsec showhostkey --txt @gateway_hostname
```
Replace gateway_hostname with your hostname, such as gateway.example.com.

It produces a text file with a text record containing your key and formatted in the proper DNS syntax.
Insert this record into the zone file for that domain as a forward TXT record.

Note: If you aren't sure how to edit DNS records, have your DNS administrator help you. Making a mistake with a DNS record can easily take your whole domain down.
Also, keep in mind that the changes will take a while to propagate across the Internet. Depending on where you are querying from, this process might take as long as 48 hours.
You can check to see if the change has taken place yet with the following query:
```
ipsec verify --host gateway.example.com
```
It should respond with an OK statement for the forward record.

The reverse record lookup will fail, but this is acceptable as long as you don't want to do a full OE. Remember that even though you can correctly query the DNS server, the other end of your connection may not be able to yet. Have them run the verify command as well.
Once both sides can see the DNS record, then all you should have to do is restart your IPsec service by typing:
```
service ipsec restart
```
When it comes back up, you should be ready to go.

This is all that is required, since FreeS/WAN will automatically configure the connection using the DNS record information when it comes up.

Setting Up Full Opportunistic Encryption

In order to do full OE, you must have a static IP on the gateway and have full control of the DNS record for that IP. FreeS/WAN OE uses a reverse DNS lookup to verify the public key of any machine attempting to connect. The instructions are exactly the same as for partial OE, except that you also create a reverse DNS record for your gateway host name. Create the text file the same way as above and after adding it as a forward record, add it as a reverse record tying it back to your static IP address. Again, if you are unsure of how to edit a DNS file, get some help. DNS is not something to monkey around with lightly. Once both records are visible from the Internet, you should be able to restart your IPsec service and establish connections with IPsec OE compliant hosts.

Password Crackers

You have learned how to protect your information various ways using encryption, and how to encrypt files, sessions, and whole connections with other sites. The next section looks at a tool to help you make sure your password files are safe. This tool is a password encryption cracker. It does the reverse of all the tools in this chapter in that it tries to decrypt the password file without any keys. It is primarily to be used on password files to make sure you don't have passwords that are easy to crack.

Most passwords these days are not stored in plain text on the server. They are stored as hashes of the password so that the clear text password is not being passed across the network. On some operating systems, however, this hashing system is weak and the encryption is easily cracked. Worst case, if someone captures a password file, he or she can run a brute force attack on the hashes, discovering some passwords. This takes advantage of the tendency of most people to use simple passwords. You can limit this ability in most operating systems, but even then, people will figure out ways to get around the limitations in the interest of making their life simpler. Testing your password files with password crackers is the only way to know for sure how safe your users' passwords are.

John the Ripper: A Password Cracking Tool

John the Ripper was designed by the enigmatic Solar Designer to help system administrators flush out weak passwords, mostly on UNIX systems. John uses a text password file and checks the hash for each word in the file against the password file. It even tries variations on dictionary words such as cat1, cat2, and so on. It also uses some randomizing techniques after it runs out of words to keep on trying as long as you want to let it run. It comes with a basic word file and you can also download various custom word files for different operating systems or create your own.

It is available for both UNIX and Windows. Since it is a command line tool only, the basic operations are the same for both operating systems. The separate installation processes are covered here.

Windows Installation

Download the Windows binary package from the Web site or the book's CD-ROM and unzip the file into its own directory.
There is no real Windows setup process here. Just put the files where you want them to reside and run them from that directory with the proper commands. You may want to add that directory to your system path if you want to be able to run John the Ripper from any directory. Otherwise, change to the john/run directory to access the binaries and run the program.

UNIX Installation

Download and untar the source code files from the Web site or the book's CD-ROM.
Issue the following command from the src directory it created:
```
make
```
This displays a list of systems supported.

Note: If your system is not listed, substitute the command make generic in the next step (this should work most of the time).
Issue the following command substituting your supported system type for system:
```
make system
```
This builds the program and puts the main binary programs in the john/run directory.
Change into that directory and you are ready to run John the Ripper.

Using John the Ripper

First, you need to have a copy of the password file.

On most UNIX systems the password hashes aren't stored in the main password file but are kept in a file called the shadow password file (called shadow on Linux systems). This protects the password hashes from being viewed easily, since the main user password file has to be accessible to various other parts of the operating system and so has to be world-readable.

The password hash file looks something like Listing 9.1.

Listing 9.1. Sample Password Hash File
```
root:$1$8_pw/'$3ABCmAmVVtBbgXc1EpAZ7.:12080:0:99999:7:::

bin:*:12080:0:99999:7:::

daemon:*:12080:0:99999:7:::

adm:*:12080:0:99999:7:::

lp:*:12080:0:99999:7:::

sync:*:12080:0:99999:7:::

apache:!!:12080:0:99999:7:::

postfix:!!:12080:0:99999:7:::

mysql:!!:12080:0:99999:7:::

tony:$1$™bFíb/_R$6RFzrkqq6nY4zTkmWQ8xV0:12080:0:99999:7:::
```
The seemingly list of random characters after the account name is the hash of the password. That is what John the Ripper goes to work on.
The text file password in your John the Ripper directory contains the default word list. You can add to this list if you have some custom passwords you want it to try or replace it with your own word list.
To run John the Ripper, type the following command:
```
john password_filename
```
Replace password_filename with the filename of the password file you want to test.

John the Ripper shows you any passwords it is able to crack on the screen as it tries. Most of the word lists will be run through in a few minutes. This is long enough for most purposes, but if you want to let it run longer to really test your passwords, you can run the process in the background.

You can also interrupt the testing process and return to it later. Press CTRL+C once to stop the testing and save the results in a file called john.pot. Note that pressing CTRL+C twice will abort the search and not save your results.
You can view the passwords retrieved thus far by typing:
```
john -show password_file
```
If you want to back up a cracking session, use the following command:
```
john –restore
```

And that's about all there is to it. Happy password cracking (only your own password files, please!). If you find weak passwords, you can go to those people and have them change them or institute policies on the server that require stronger passwords.