According to OpenVPN official website OpenVPN is “an open-source software that implements virtual private network (VPN) techniques for creating secure point-to-point connections”.
- Additional authentication
- Attacks on default gateway
- Custom Port
- Disable IPv6
- Disable management interface
- DNS management
- Don not allow certificate re-use
- Key Size
- Limit concurrent clients
- Persistent VPN device
- Run as unprivileged user
- Secure Ciphers
- Secure PKI Management
- Set minimum TLS version
- SHA-2 for message authentication
- Use PSK
- Verify Certificate subject name
- Verify CRL
- Verify the server certificate
If possibile, it is suggested to request an additional authentication in addition to a client certificate. This could protect you in case of certificate loss. Additional authentication could be configured server side in two ways:
- Using the auth-user-pass-verify
- Using a plugin (i.e. PAM)
OpenVPN is commonly used to route all traffic or only some subnets through the VPN tunnel. This is implemented adding wide scope routing rules. A rogue DHCP server able to push more specific routes could be able to take precedence on the routing table and route your traffic outside the VPN. To prevent this kind of attacks it is suggested to configure your DHCP client to ignore classless static routes. A rogue DHCP couls also push a subnet mask for an extremely large subnet, so all the traffic could be routed on the local network and not in the VPN. This issue has not an easy solution, it depends by your OS, for example in Linux you can use advanced routing and multiple routing table (see https://www.agwa.name/blog/post/hardening_openvpn_for_def_con).
It is suggested to move OpenVPN from the default port to a custom one. For example we are setting it on port 10000, edit the server configuration file as follows:
You know, IPv6 could be a security beast. Unless you are using IPv6 in your OpenVPN tunnerl, then all IPv6 traffic from your client will bypass the VPN and egress over the local network. It is suggested to disable IPv6 support in your OS if you are not using it.
The OpenVPN Management interface allows OpenVPN to be remotely administered. It is suggested to disable or restrict to localhost (or local trusted clients) the management interface. Edit the server configuration file and comment the management option or make sure it is only accessible via localhost:
# management 127.0.0.1 8000
When you are using a VPN tunnel, you should use only a trusted DNS server. If an attacker is able to push a rogue DNS server it is a game over for you because he could redirect all your traffic outside the VPN. It should take care of your configured DNS servers, unfortunately how DHCP clients manage pushed DNS servers depends by operating systems. Some systems do it incredibly poorly and it is possible to change your DNS server, by pushing it via DHCP, after the VPN tunnel startup. It is suggested to pin your DNS servers to be suere you are always using the right one.
Certificates should not be shared and each VPN client must have its unique certificate. Is is suggested to enforce it disabling the duplicate-cn in the server configuration file, if present, commenting or deleting it, as follows:
It is suggested to use a key size of, at least 2048 bits (better 4096 bits), for your certificates. If you are creating certificates with OpenSSL you have to modify the default_bits parameter.
It is suggested to restrict the maximum number of concurrent clients to a reasonable number. Set max-clients in the server configuration file, as follows (limited at 100 clients in the example):
If your connection is interrupted and OpenVPN is trying to reconnect, in the meanwhile, traffic is passing by your default route, bypassing your VPN. It is suggested to configure OpenVPN to keep the device open and to hold traffic until the connection is restored, add the following option to the configuration file:
It is suggested to run OpenVPN process as unprivileged user. Add the following lines to the configuration file:
user nobody group nobody
It is suggested to use strong symmetric ciphers (at least 256bit). For example, add to both server and client configuration file the following to use AES-256:
Is also suggested to limit the use of TLS ciphersuites with:
OpenVPN authentication, in most cases, is based on PKI and X.509 certificates. Practicing secure PKI management is mandatory to safeguard, also, OpenVPN. It is suggested to follow best practices for secure PKI management, for example:
- Secure management of CA PKI.
- Generate private keys on the target system and never transport them.
- Never share private keys.
- Use certificate passwords if possibile and use a secure password policy.
- Use a CRL and revoke lost/compromised keys.
It is suggested to set minimum TLS version editing the configuration file and adding:
It is suggested to use strong alghoritm for message authentication (HMAC). Add the following line to the configuration file:
The –tls-auth option uses a static pre-shared key (PSK) shared among all connected peers. This is an extra layer of protection to the TLS channel by requiring that incoming connections are correctly HMAC signed by the PSK key. This feature could protect your VPN server by DoS attacks aimed to load your CPU load, by port scanning avoiding service fingerprinting, and act as second line of defense for SSL library vulnerabilities. Generate a PSK with the command:
openvpn --genkey --secret ta.key
Add the following line to your server configuration:
Add the following line to your server configuration:
Beware, the –tls-auth key is changed, it must be changed on all peers at the same time, so it could potentially lead to a network management horror story. It is suggested to use it with care.
This is not a general reccomendation although in some cases could be useful to verirify X.509 certificate subject name on the client. Add to the client configuration file the following line:
verify-x509-name 'C=XX, O=Example, CN=example.xxx' subject
It is suggested to erify revoked client certificates, they should not connect or keep a connection alive. Add crl-verify to the server configuration file, as follows:
It is recommended to check that the server certificate contains a specific key usage and and extended key usage. Add to the client configuration file the following line:
This also is a measure to prevent a client using his certificate to impersonate a server.
Certificates using the X509v3 format have key usage flags set. Clients should use certificates with the “TLS Web Client Authentication” set and servers with “TLS Web Server Authentication” set.
Add to the client configuration file the following line:
remote-cert-eku "TLS Web Server Authentication"
Add to the server configuration file the following line:
remote-cert-eku "TLS Web Client Authentication"