No Magic Needed

As the story goes, Aladdin was good-for-nothing, idle, and mischievous and had no respect for his parents. Would you put your enterprise security into the hands of a rascal like that? Fortunately, with the help of some magic, the magician and the genie in the lamp finally made a sultan out of the boy [1].

OpenVPN and Aladdin

Luckily, you don't need magic to use Aladdin e-tokens with Linux and OpenVPN. The free SSL virtual private network (VPN) joined the mainstream with release 2.1, and it is useful for large-scale setups. Aladdin [2] dominates the market for USB stick-based cryptographic access control with its e-tokens – one reason they were acquired by SafeNet. However, e-token is e-token, whether labeled Aladdin or SafeNet. At a price of around US$ 100, an e-token is basically a USB device containing a user certificate. However, integrating USB stick-based authentication with password management and PIN input is not a trivial task.

In this article, we show how an organization can configure and secure a large-scale infrastructure and discuss the integration of Linux and Windows clients. We also look at customized client configurations for the VPN and a matching start script to handle PIN entry on Linux.

Tokens and Certificates

Of course, the VPN dial-up no longer uses a simple pre-shared key (PSK) but, instead, uses secure, centrally manageable X.509 certificates [3] that automatically expire. You can also use OpenVPN in combination with simpler, public key certificates, a technique that Strato employs for its HiDrive network storage [4]. However, this means that you need to create the certificate as a clientAuth certificate; otherwise, OpenVPN will not open the tunnel.

Individual client certificates and keys are preferable for the enterprise, but they still need protection, which is where Aladdin comes in with its hardware and software solution. You need a password to read the e-token, and this fulfills the "something you have and something you know" requirement imposed by data protection. On top of this, the e-token is an intelligent device that blocks the token if the user types the wrong password too many times. This precaution prevents an unauthorized third party from opening a connection without a password if the token is lost or stolen. The stored certificate is read in line with the PKCS#11 standard [5].

Step by Step

On a Ubuntu server, you would start by installing the openvpn package, which depends on the liblzo2-2, libpkcs11-helper1, openssl-blacklist, and openvpn-blacklist packages. The next step is to set up your own Public Key Infrastructure (PKI). OpenVPN provides a software tool for small and medium-sized setups in the form of Easy RSA, and this tool is fine for test purposes. Admins who need larger PKIs can turn to tools like OpenCA [6] or outsource the task to a service provider.

No matter which tool you use, after creating the certificates, you will want to move your PKI, preferably to an isolated, internal system without a network connection. If the PKI is compromised (especially the CA.key file), your enterprise IT landscape is at risk: The PKI should never be accessible via a network.

Easy RSA

The Easy RSA scripts provided with the package give admins a quick and uncomplicated approach to setting up the PKI; you will find the scripts in /usr/share/doc/openvpn/examples/easy-rsa/2.0. You can start by modifying a couple of things in the vars; this is mainly to make the procedure more convenient (see Listing 1). After modifying these lines, you don't need to enter the details manually later on; instead, you can just type Y or press Enter. The next step is to clean up a couple of commands, export the values you just edited, and create a Diffie-Hellman (DH) key, which you need to secure the key exchange:

01 # Key length
02 export KEY_SIZE=1024
03
04 # CA validity (in days)
05 export CA_EXPIRE=3650
06
07 # Certificate validity (in days)
08 export KEY_EXPIRE=3650
09
10 # Predefined certificate values
11 export KEY_COUNTRY="DE"
12 export KEY_PROVINCE="BY"
13 export KEY_CITY="Muenchen"
14 export KEY_ORG="Linux-Magazin"
15 export KEY_EMAIL="pki@linux-magazin.de"
16
17 ./clean_all
18 ./vars
19 ./build-dh.sh

After a little time, and a couple of screens full of cryptic characters, you should have your DH key and can run ./build-ca to create your own CA. The script guides you through the process, offering the predefined values from your vars files as the defaults. You just need to type in the Organizational Unit Name and Common Name manually.

Next, you can create a server certificate. Easy RSA includes the build-key-server script for this; it expects the certificate name as a parameter. This means manually entering several pieces of information, one of which is the Common Name, typically the server's FQDN. Don't forget to include a challenge password here, as signing will occur immediately after this process. You can say Y to the other two questions:

Sign the certificate [y/n]:
1 out of 1 certificate requests certified, \
commit? [y/n]:

After completing this step, you can issue as many user certificates as you like. Again, Easy RSA gives you a script, build-key, for this. You need to confirm the defaults and add personal details before going on to create a TLS key to provide protection against DoS attacks. The following command is useful here:

openvpn --genkey --secret tls-auth.key

It stores the key in the tls-auth.key file.

What Belongs Where?

The process of putting the certificates you create in the right places can be confusing. Figure 1 shows the correct locations: You need the CA.crt, server.crt, server.key, tls-auth.key, dh.key, and client.crt files on the OpenVPN server. On the client side (a laptop in this case) you only need the CA.crt and tls-auth.key files. The client.pem file belongs on the e-token. The lower part of the figure shows the isolated PKI management machine pushing out the client.pem file on the right.

Finally, you just need to store the new user certificates on the users' e-tokens. The following command

openssl pkcs12 -export -in John_Doe.\
crt -inkey John_Doe.key  -out \
John_Doe.p12

combines the client's certificate/key pair in a PKCS#12 file, which you then copy to the e-token using the SafeNet Authentication Client (SAC) [7] (formerly known as Aladdin PKI Client; it was renamed in the acquisition of Aladdin by SafeNet but contains the same functions).

When you launch this software for the first time, a button in the Advanced view initializes the e-token. You need to enter a user and administrator password for unlocking the e-token. You can also define the number of invalid attempts that a user gets before the token is blocked. The "Unlocking E-Tokens" box outlines the correct approach for reanimating an e-token using the SAC tool (Figure 2).

Import and Export

The import function helps you put the certificate on the e-token. When you are prompted for a password, enter the user password that you just assigned to be taken to another authentication dialog. If you entered a Challenge Password when issuing the user certificate, you will need to enter this now; otherwise, just leave this field blank. The e-token is now ready for use.

OpenVPN: The Server

Admins in large-scale environments will typically run OpenVPN in a separate DMZ, which is probably the ideal solution because it routes access via the centralized firewall systems and is thus controllable. But, this approach means that every VPN user needs a static IP address, for which rules are defined on the firewalls. After all, you don't want to give an external company the same privileges as an internal member of staff currently working from home.

To allow this to happen, OpenVPN version 2.1 or newer offers a topology subnet mode. In combination with the practical ccd-exclusive parameter, it assigns a fixed IP address to the certificate/user pair and locks out unconfigured users. The administrator needs to create a configuration file with a .conf suffix below /etc/openvpn/ on the server (Listing 2). This file tells OpenVPN to run on TCP port 443, use a TUN device for tunneling, and use subnet as the topology. In this mode, the OpenVPN server is assigned the first address in the designated address range (IP 192.168.1.1, in the example). The certificate and key path details are followed by the server directive with the IP range of the virtual network.

01 port 443
02 dev tun
03 proto tcp
04 topology subnet
05
06 dh /etc/openvpn/keys/dh1024.pem
07 ca /etc/openvpn/keys/CA.crt
08 cert /etc/openvpn/keys/server.crt
09 key /etc/openvpn/keys/server.key
10 tls-auth /etc/openvpn/keys/tls-auth.key
11
12 server 192.168.1.0 255.255.255.0
13
14 keepalive 10 60
15 comp-lzo
16
17 persist-key
18 persist-tun
19 client-config-dir /etc/openvpn/ccd
20 ccd-exclusive
21 status /var/log/openvpn/status.log
22 log-append /var/log/openvpn/openvpn.log
23 verb 5

The important thing here is to modify routing on the firewall systems involved and to route the private network via the OpenVPN server. The keepalive parameters at line 14 then tell OpenVPN to automatically terminate the tunnel after 60 seconds if the connection fails, thus allowing the user to redial.

The comp-lzo directive enables compression, which noticeably increases the response that users experience when working via the tunnel. persist-key and persist-tun prevent OpenVPN reparsing the tunnel and key files when the tunnel is restarted. This makes sense if OpenVPN drops its privileges after launching, because only root is allowed to create the TUN device and parse the key file.

The client-config-dir directive defines where the user configuration (e.g., with individual IP address assignments or special routes) is stored. The next directive, ccd-exclusive, tells OpenVPN to reject any users that don't have a configuration; status, log, and verb configure the logfiles and verbosity.

Push Configurations

The server-side configuration for user John Doe is stored in a file called /etc/OpenVPN/ccd/John_Doe and will look pretty much like the code in Listing 3. The important thing is for the filename to match the CN from the subject line in the client certificate; in other words, you need to make sure you plan ahead when designing your PKI. The server assigns the client an IP address of 192.168.1.3 when it dials up the connection. At the same time, redirect-gateway tells the client to run its default gateway through the VPN tunnel. Additionally, OpenVPN uses dhcp-option to modify the DNS, WINS, and domain settings. Unfortunately, only Windows clients will understand the dhcp-option directive, but you can use the /etc/openvpn/update-resolv-conf script for Linux clients. If your distribution doesn't deliver this script, you can download a modified version [9].

01 # John Doe
02 ifconfig-push 192.168.1.3 255.255.255.0
03 push "topology subnet"
04 push "redirect-gateway"
05 push "dhcp-option DNS 192.168.10.1"
06 push "dhcp-option WINS 192.168.10.1"
07 push "dhcp-option DOMAIN linux-magazin.de"

Of course, you could handle all the configurations listed in the ccd directory on the client side, but this is not a good idea for security reasons. A user could easily change the IP address assigned to them to escalate their privileges. The VPN server also needs to support packet forwarding, which is handled by the ip_forward via sysctl -w net.ipv4.ip_forward=1 kernel parameter.

Integrating Windows Clients

Linux and Windows clients use a totally different OpenVPN configuration. You will find the necessary Windows software at [8]. The Linux Magazine editorial team recommends the community software offered by OpenVPN.net. The alternative from OpenVPN.se doesn't include Microsoft-certified drivers, which can cause issues with some Windows versions. Besides the OpenVPN software, you also need the SAC e-token software, which you can retrieve after registering [7].

After installing the two programs, you can start with the configuration. Begin by creating a client.ovpn file with the content shown in Listing 4 in C:\Program files\openvpn\. Note that the double backslashes aren't a typo – they are absolutely necessary. Remember to correct the path if you run a 64-bit system. It then has to be C:\Program files (x86)\openvpn\, again with double backslashes.

01 remote myopenvpn.exmaple.com 443
02 dev tun
03 proto tcp
04 client
05 tun-mtu 1500
06 ca "C:\\program files\\openvpn\\keys\\ca.crt"
07 tls-auth "C:\\program files\\openvpn\\keys\\tls-auth.crt"
08 cryptoapicert "THUMB:xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx"
09
10 cipher BF-CBC
11 comp-lzo
12 register-dns
13 explicit-exit-notify

Besides the certificates, which belong in C:\Program files\openvpn\keys, the major part of the configuration that you need to modify here is the cryptoapicert directory. Replace the xx:xx... section with the certificate fingerprint. Windows operating systems use a certificate store, which houses all temporary and permanent certificates. You can use an API to parse it for e-tokens, for example in the Microsoft Management Console. Click Start | Run and type mmc in the dialog to pop up the Microsoft Management Console; then add the certificate snap-in (Figure 3).

As a final step, choose whether the MMC should open the certificate store for the current user, the service account, or the computer account. If more than one user account exists on the machine, you should use the computer account; if not, the current user's account is fine.

Next, open the crypto store and go to My Certificates to parse the plugged-in token. Double-clicking the certificate takes you to an overview of your options. Select the fingerprint, copy it, and paste it into client.ovpn. Before quitting the MMC, add the CA certificate, ca.crt, as a trusted root certification authority in the crypto store to indicate that the e-token is trustworthy. Although this step is not mandatory, it helps in some situations.

register-dns helps enable the DHCP options. In some cases, Windows doesn't load the new DNS configuration after establishing the tunnel. explicit-exit-notify helps reconnect clients rapidly. With this option set, the OpenVPN client tells the server explicitly when it exists so the server can close the connection gracefully. Otherwise, the client has to wait until the server-side keepalive timeout occurs.

To allow users without administrator rights to connect with OpenVPN, you have to put them in the local group of Network Configuration Operators. In Windows 7, you also have to click OpenVPN GUI Client Properties and, under the Shortcut register, click Advanced and check Run as administrator). Otherwise, the new UAC system would prevent a functional tunnel.

Now, when you launch the OpenVPN GUI and right-click the icon in the start bar to open a connection, the SAC client asks for the token password. Assuming the password is entered correctly, the tunnel is set up immediately.

Linux Clients

On Linux clients, you need to install the openvpn and pcscd packages and the SAC tool [7] (which depends, among other things, on libhal0). Newer distributions provide pcscd in version 1.7.0, which no longer runs as a daemon. But SAC needs a daemon. You can easily correct this by commenting out the exit 0 line in the /etc/init.d/pcscd startup script.

Then, in /etc/openvpn/, you can create a client.conf file similar to the one shown in Listing 5. The certificates need to be in /etc/openvpn/keys. Because Linux clients can't interpret the server-side dhcp-option, you need to run update-resolv-conf, which comes courtesy of OpenVPN or by download [9]. The script converts the option into Linux-compliant commands, which are then run when setting up and breaking down the tunnel.

01 remote myopenvpn.exmaple.com 443
02 dev tun
03 proto tcp
04 client
05 tun-mtu 1500
06 ca /etc/openvpn/keys/ca.crt
07 tls-auth /etc/openvpn/keys/tls-auth.key
08
09 up /etc/openvpn/update-resolv-conf
10 down /etc/openvpn/update-resolv-conf
11
12 pkcs11-providers /usr/lib/libeTPkcs11.so
13 pkcs11-id 'Aladdin\x20Knowledge\x20Systems\x20Ltd\xxx/eToken/0000xxxx/eToken\xxx\xxx\xxxxxx/xxxx'
14
15 management 127.0.0.1 4711
16 management-query-passwords
17
18 cipher BF-CBC
19 comp-lzo
20 explicit-exit-notify
21 verb 3

The pkcs-11-providers directive defines the path to the SafeNet library for parsing the e-token; pkcs11-id specifies the e-token used on this system (similar to the fingerprint in the Windows configuration). To discover the string you need for this, plug in the USB stick and run

openvpn --show-pkcs11-ids \ /usr/lib/libeTPkcs11.so

(Listing 6). The fingerprint is listed in the Serialized id field (on 64-bit systems, you have to adjust the path to /user/lib64/).

01 The following objects are available for use.
02 Each object shown below may be used as parameter to
03 --pkcs11-id option please remember to use single quote mark.
04
05 Certificate
06  DN:             /C=DE/ST=BY/L=Muenchen/O=Linux Magazin/OU=TR/CN=John_Doe/emailAddress=jd@example.com
07  Serial:         03
08  Serialized id:  SafeNet\x20Inc\x2E/eToken/xxxxxxxx/eToken/xxxxxxxxxxxxxxxxxx

OpenVPN Management Interface

Because Linux systems don't have a crypto store, you need to find a different approach to enabling the e-token password check. The management and management-query-password lines help you do this.

If you now launch OpenVPN at the console as the root user and type openvpn --config /etc/openvpn/client.conf, the output shows you the steps that have been processed thus far. The program normally stops after issuing the following message:

openvpn --config /etc/openvpn/client.conf
[...]
Sun Aug 15 15:07:56 2010 Need password(s)\
 from management interface, waiting...

OpenVPN is waiting for a Telnet connection to port 4711 on the local host, where the OpenVPN management interface welcomes users with the following message:

telnet 127.0.0.1 4711
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
>INFO:OpenVPN Management Interface Version \
 1 -- type 'help' for more info
>

The OpenVPN management interface requires a specific syntax for the password. Typing the following command in the Telnet session does the trick:

password 'eToken John_Doe' secret

Here, secret is the e-token password. If you get this right, OpenVPN will set up the tunnel.

Manual Dial-Up Script

Of course you can't expect your users to do all this. Instead, the Linux Magazine editorial team has written a Bash script called Etovpn. The script is now available as test version 0.42, including packages for Debian or SUSE, or as a tarball. The script can also be downloaded [9].

The script opens the VPN tunnel in the background and prompts the user for their password. It then passes the password to OpenVPN via a (local) Telnet session. You can configure this in the /etc/etovpn.conf file.

Time Control

The client configuration directory also gives you a simple time control option. After enabling the ccd-exclusive directive, you can easily manage a user's login time via a mv command, which pushes the configuration file out of the ccd directory.

A cronjob can help automate this process and then – presto – external staff or service providers now have defined login time slots. A word of caution: This restriction doesn't apply to existing tunnels; you would need to take an existing tunnel down via the management interface on the server.