From Gentoo Linux Wiki

ello moto

I've worked extensivly on the HOWTO LDAP SAMBA PDC. Its quite out of date now, and defently needs lots more work.

Contents 1 OpenVPN 1.1 Bridged or Routed? 1.1.1 Bridged 1.1.2 Routed 1.2 Installation 1.2.1 Kernel Needs (TUN/TAP) 1.2.2 Emerge 1.3 Security 1.3.1 Static Key 1.3.2 Public Key Infrastructure (PKI) 1.3.3 tls-auth 1.3.4 proto UDP 1.3.5 user/group 1.3.6 chroot 1.3.7 Larger RSA keys 1.3.8 Larger Symmetric Keys 1.3.9 Pass-phrase protect secret keys 1.3.10 Keep the root key (ca.key) secure 1.3.11 Prevent Man in the Middle Attacks 1.4 Working with x509 Certs 1.4.1 Initial Setup 1.4.2 Client Certs 1.5 Server Configuration 1.6 Client Configuration

[edit] OpenVPN

I've been working on how to configure OpenVPN for my needs and have found a lot of the articles lacking, I will start to write my own here, and move it to separate pages when I have enough content.

I'm going to aim this document around using the current ebuild of OpenVPN which is net-misc/openvpn-2.0.6

[edit] Bridged or Routed?

You can only have one or the other. Whats the Difference?

[edit] Bridged

Makes use of the TAP driver, with this model you will create a Ethernet (Layer 2) VPN. This will enable you to use all Layer 3 protocols, broadcasts, and the like. Effectively this makes your VPN gateway a switch on your LAN.

[edit] Routed

Makes use of the TUN driver, with this model you will create a IP (Layer 3) VPN. This will limit you're network traffic to only what you works with IP or can be encapsulated in IP. Effectively this makes your VPN gateway a router on your LAN.

[edit] Installation

[edit] Kernel Needs (TUN/TAP)

You have to build the TUN/TAP driver as a module or as a built-in. Also, if you want to bridge you're need to build that as well.

[edit] Emerge

You need to emerge OpenVPN, also if you are going to bridge you need bridge-utils

• • Dont be dumb, emerge OpenVPN with SSL, better yet add it to your make.conf USE flags!
  • Note: that if you're running <sys-apps/baselayout-1.12.6, you may need sys-apps/usermode-utilities

[edit] Security

When it comes to security you should never rely on one item to protect you. Instead you should layer your security so that if one method where to fail, another would be there so that you are not left completely vulnerable. OpenVPN supports layering security to help realize this. However it is always up to the end user to utilize these features as individual needs differ and some of this may be overkill for any particular application.

[edit] Static Key

While OpenVPN can be configured to use Static Keys, it is extremely insecure and even then only practical in a single connection environment or in a non-production Lab environment.

• Advantages
  • Simple Setup
  • No x509 Public Key Infrastructure(PKI) to maintain.
• Disadvantages
  • Limited Scalability
  • Lack of perfect forward service -- key compromise results in total disclosure of previous sessions
  • Secret key must exist in plan-text form on each VPN peer
  • Secret key must be exchanged using a pre-existing secure channel
• (Source: [1])

A static key can be generated with the following command, which will create a static key called ta.key

openvpn --genkey --secret ta.key

then in your client and server configuration files reference the location of the static key with the secret option.

[edit] Public Key Infrastructure (PKI)

PKI is the preferred primary authentication / encryption method used by OpenVPN.

In regards to OpenVPN a typical PKI consists of:

• a separate certificate (also known as a public key) and a privet key for the server and each client
• a master Certificate Authority (CA) certificate and key which can is used to sign each of the server and client certificate

With this model the following features apply:

• The server only needs its own certificate/key -- it doesn't need to know the individual certificates of every client which might possibly connect to it.
• The server will only accept clients whose certificates where signed by the master CA certificate. Because the server can preform this verification without needing access to the CA private key itself, it is possible for the CA key (the most sensitive key in the entire PKI) to reside on a completely different machine, even one without a network connection.
• If a private key is compromised, it can be disabled by adding its certificate to a certificate revocation list (CRL). The CRL allows compromised certificates to be selectively rejected with out requiring that the entire PKI be rebuilt.
• The server can enforce client-specific configurations and access right based on embedded certificate fields, such as common name.

[edit] tls-auth

The tls-auth directive adds and additional HMAC signature to all SSL/TLS handshake packets for integrity verification. Any UDP packed no bearing the correct HMAC signature can be dropped without further processing. The tls-auth signature provides and additional level of security above and beyond that provided by SSL/TLS. It can protect against:

• DoS attacks or port flooding on the OpenVPN UDP port.
• Port scanning to determine which server UDP ports are in a listening state.
• Buffer overflow vulnerabilities in the SSL/TLS implementation.
• SSL/TLS handshake initiations from unauthorized machines (while such handshakes would ultimately fail to authenticate, tls-auth can cut them off at a much earlier point).

(Source: [2])

Using tls-auth requires that you generate a shared-secret key that is used in addition to the standard RSA certificate / key. This can be done with

openvpn --genkey --secret ta.key

This will create a secret key ta.key and will need to be copied to the servers and clients. In the server config you need to reference the location of the key with the following:

tls-auth ta.key 0

And in the client configuration with:

tls-auth ta.key 1

[edit] proto UDP

as UDP is connectionless is will provide better protection against DoS attacks and port scanning that TCP can offer.

[edit] user/group

OpenVPN has been designed so that root privileges are not needed after startup. And In *NIX environments there is no reason not to. By dropping to an essentially unprivileged account, if an attacker where to compromise the OpenVPN service, and gain access, they would only have the access of the group and user specified.

user nobody group nobody

[edit] chroot

Placing OpenVPN in a chroot effectively creates a jail for OpenVPN to operate out of. This will prevent OpenVPN from accessing anything outside of the chroot jail directory. If an attacker where to compremize OpenVPN they would no be able to leave the chroot jail

chroot jail

would cause OpenVPN to operate from the directory jail, preventing anything not in the subtree of jail to be accessed. You will need to put files that OpenVPN will need after initialization in this directory, such as:

• the file referenced by crl-verify (Certificate Revocation List)
• the directory referenced by client-config-dir

[edit] Larger RSA keys

by default the RSA key size is set to 1024 in the easy-rsa/vars file increasing this from 1024 to 2048 is reasonable. It will have a marginal impact upon tunnel performance (during SSL negotiation). It will slow down cert/key generation and will double the time to do the one time Diffie Hellman parameters.

You must change this value before any keys are created or all keys will have to be rebuilt.

[edit] Larger Symmetric Keys

By default OpenVPN uses Blowfish, a 128 bit symmetrical cipher. This can be changed to anything that the OpenSSL library supports using the cipher option and as such can support ciphers which use large key sizes. This option needs to be specified in both the client and server configuration files.

cipher AES-256-CBC

The above statement would cause OpenVPN to use the 256-bit version of the Advanced Encryption Standard.

[edit] Pass-phrase protect secret keys

While impractical (and I don't see support for) the server key, I would highly recommend creating a pass-phrase protected CA and require passwords or better yet, pass-phrases on the client keys. This will cause the private key to be encrypted with the password adding another layer of protection against in-approate use.

A pass-phrase is a secret phrase, where a password, is a secret word. The main intention of using a phrase versus a word is that a Phrase is much, much harder to predict, but not so complex that it would be totaly random (and impossible to remember). A good pass-phrase would contain several sentances and all proper punctuation. (usually around 40 or more characters).

to pass-protect your CA use:

./pkitool --initca --pass

to pass-protect your client certs use:

./build-key-pass

This will help prevent unauthorized key access, and in the case of the CA is highly recommended. As without the decrypting pass-phrase it will not be possible to sign new certs with the CA's private key. With the client, it will prevent access to the VPN if the computer is physically stolen (road-warrior), or if the key is stolen off off the computer.

[edit] Keep the root key (ca.key) secure

One of the primary benefits of using the x509 PKI is that the root CA key (usualy CA.key) doesn't need to be present on the VPN server, or for that matter and computer with a network connection. If your paranoid, a disconnected box could be used for key signing this way the private key is never exposed to possible network retrieval. All you would then have to worry about is physically securing the box. Keys can be moved from the computer via removable storage. If you are not so paranoid, simply store the root CA key on a hearty (or multiple) removable storage device and store it in a fire-proof safe (which would probably be a good idea anyway)..

[edit] Prevent Man in the Middle Attacks

Man in the middle attacks are where an authorized client tries to connect to another client by inpersonating the server. To prevent this make sure to force the clients to verify the certificate presented by the server is in fact a server certificate. According to The OpenVPN HowTo can implement these items, in order of prefrence

• OpenVPN 2.1x and above build your server certificates with the build-key-server script, this will designate the certificate as a server only certificate by setting the right attributes(by RFC3280). Also you need to add the following line to your client configuration.

remote-cert-tls server

• OpenVPN 2.0x and below build your server certificates with the build-key-server script, this will designate the certificate as a server only certificate by setting nsCertType=server. Also, you will need to add the following line to your client configuration.

ns-cert-type server

• Use a tls-remote script or plug-in to accept/reject the server connection based on a custom test of the server connection based on the common name of the server certificate.

• Use a tls-verify script or plug-in to accept/reject the server connection based on a custom test of the server certificate's embedded x509 subject details

• Sign the server certificates with one CA and sign the client certificates with a different CA. The client configuration ca directive should reference the server-signing CA file, while the server configuration ca directive should reference the client-signing CA file.

[edit] Working with x509 Certs

[edit] Initial Setup

1. copy /usr/var/openvpn/easy-rsa/vars to /etc/openvpn/default.vars this will allow you to edit the vars to you're liking with out making it standard for every one on the system.
2. edit /etc/openvpn/default.vars to your liking. change all of the default values for the cert fields( KEY_COUNTRY, KEY_PROVINCE, KEY_CITY, KEY_ORG, and KEY_EMAIL), so you don't have to remember them each time you make a new cert. Also, its handy if you change the KEY_DIR to /etc/openvpn/keys.
3. source /etc/openvpn/default.vars
4. cd to /usr/share/openvpn/easy-rsa/
5. ./pkitool --initca --pass (this is my personal prefrence, I like to put a passphrase on my CA key, if you don't, use ./build-ca
6. ./build-dh & >/dev/null 2>&1 (it takes a while, background it)
7. ./build-key-server server-common-name

That will get you started with the CA, DH paramaters and server Cert.

[edit] Client Certs

If you haven't created a CA, you must do so before you get here, please complete the above section. If you haven't already sourced this session with your vars file, do it now

1. source /etc/openvpn/default.vars
2. cd /usr/share/openvpn/easy-rsa/

You can build client certs with the following commands

./build-key common-name

or

./build-key-pass common-name

in both cases common-name will be the filename for your cert, and will default as the common name of the cert. This is default is recommended so that identifying the common name of a key from the file name will be easy.

[edit] Server Configuration

[edit] Client Configuration