Recommendations to improve security after installation

Upgrade to Latest Version

Introduction

After completing the initial installation of OpenVPN Access Server, we recommend the following ways to increase security:

  1. Secure the root user account for servers on virtual machines.
  2. Keep your Access Server updated.
  3. Secure the administrative user for the Admin Web UI.
  4. Install an SSL certificate for the web interface.
  5. Harden the web cipher suite string.

Secure the root user account

If you install OpenVPN Access Server on a virtual appliance with VMWare ESXi or Microsoft Hyper-V, we recommend taking these additional steps to secure the OS root user account.

The initial password set for the root account with one of our appliances is simplistic. While we take precautions with our appliances that accessing the root account over the network isn’t easy, we recommend strengthening the password to protect against the risk of someone gaining access to the console.

To replace the account password for the root user:

  1. Via the console, sign on to the operating system as a root user. (Or sign in, then gain root privileges.)
  2. Enter this command to set a new password: passwd.

You can also create your own Linux account for SSH access since the root account usually can’t unless you adjust the SSH server settings to allow it.

Create a new user account with sudo rights (these commands assume you’re running them on a Debian/Ubuntu system):

  1. Install the sudo program: apt-get -y install sudo.
  2. Add a new user: adduser <USERNAME>.
  3. Give the user the right to run commands as a root user: usermod -aG sudo <USERNAME>.

Where <USERNAME> is a name of your own choice, without spaces or special characters. You can use this account to sign in through SSH and transfer files with programs such as SCP or WinSCP.

To gain root privileges with your new account, run this command and provide the user password:

sudo su

Finally, we recommend setting up an SSH keypair for user login under this user account instead of just the username and password authentication. Refer to the Linux operating system documentation for setting that up.

Note: AWS appliances already require a secure private/public key pair on an unprivileged account (openvpnas), and then you can “sudo up” to gain root access. AWS has no direct console access, and the root account is blocked from direct SSH access.

Keep your Access Server updated

For security products such as OpenVPN Access Server it is vital to install updates. With every new release security fixes and improvements are added to ensure that the product remains up-to-date with current security developments. OpenVPN Access Server updates are provided using our software repository. In general the updates can be installed with the commands below. We also have a more comprehensive keep your Access Server updated guide available.

Update OpenVPN Access Server on Debian/Ubuntu (as root user):

apt update
apt upgrade openvpn-as

Update OpenVPN Access Server on CentOS/RedHat/AL2 (as root user):

yum update

Secure the openvpn administrative user account

If you start with Access Server version 2.10 or newer, the installation process gives you a randomly generated password for the locally authenticated openvpn administrative account. This local administrative account is more secure than the bootstrap account type and adheres to MFA requirements and the password lockout policy. After you sign in to the Admin Web UI and change the randomly generated password to one of your choosing, you don't need to take any further steps to secure the account.

If you start with an Access Server older than 2.10, then the default openvpn administrative account is a bootstrap account specified in the as.conf file; this account exists in the operating system as a PAM authenticated user. When you upgrade Access Server, it retains this authentication to PAM for this account. This unique account type is automatically granted administrative login rights in Access Server, bypasses the post_auth script, bypasses MFA requirements, bypasses the password lockout policy, and always authenticates via PAM to the operating system. If this is your situation, we recommend that you upgrade to the latest version, remove this bootstrap account, and then use the reset default administrative account instructions to create a local administrative account. This results in a more secure administrative account that is no longer in the operating system itself and adheres to MFA and lockout policies.

Change password on Access Server 2.10 and newer

On OpenVPN Access Server 2.10 and newer you should change the random generated default password for your openvpn administrative user:

  1. Sign in to the Admin Web UI.
  2. Click User Management > User Permissions.
  3. Click More Settings for the openvpn username.
  4. Enter the new password in the Change Password field.
  5. Click Save Settings and Update Running Server.

Note: If you no longer have credentials for the Admin Web UI you can reset the default administrative account password.

For installations upgraded from version 2.9 and older

After upgrading an older Access Server to version 2.10 or newer, the old bootstrap account behavior from the older Access Server version remains. Bootstrap accounts defined in the as.conf file are reset to authenticate via PAM using the user_auth_type user property each time Access Server starts up, so the behavior of these accounts to login via PAM remains. 

If you’ve upgraded from an older version to Access Server 2.10 or newer and you still have a bootstrap user account, we recommend that you remove this bootstrap account and then use the reset default administrative account instructions to create a local administrative account. To remove the bootstrap account you can follow the steps below.

Comment out the bootstrap openvpn account from the as.conf file:

# boot_pam_users.0=openvpn

Remove the bootstrap account from your operating system:

deluser openvpn

Restart the Access Server service for the changes to take effect:

service openvpnas restart

If you’re using other bootstrap accounts, you can handle them in a similar way. 

Last, go through the reset default administrative account instructions to ensure you have a local administrative openvpn account that you can use to sign in to the Admin Web UI.

Installing an SSL certificate on the web interface

By default, OpenVPN Access Server comes with a self-signed certificate to get you up and running. Your browser can’t automatically verify a self-signed certificate. Also, an OpenVPN client program can’t validate the server with that certificate. You see warnings about this in both browsers and VPN clients when connecting or importing connection profiles.

The web browser can automatically verify if you are connecting to the real server using valid signed SSL certificates, and automatically establish trust to the server. Then the web interface no longer displays a warning message about not being able to validate the server’s authenticity.

To set this up, you must first have the following configured:

  • A fully qualified domain name (FQDN) that points to the public IP address where your Access Server is reachable from the internet.
  • The FQDN configured in the Admin Web UI in Configuration > Network Settings > Hostname or IP Address.
  • Obtain a valid signed SSL certificate from a party that is trusted in your root certificates.

We recommend setting up Access Server with an FQDN. It is required for an SSL certificate to function correctly. And if the IP address of your Access Server ever changes you only need to update the DNS record for all clients to find your server again. If however you choose to stay with just the IP address you must reinstall all clients if your server ever moves to another public IP address.

Once you have the FQDN set up you can refer to more detailed steps on this page: install an SSL certificate on the Access Server web server.

Hardening the web server cipher suite string

The web server built into OpenVPN Access Server uses HTTPS SSL encryption. This secures the connection between the web browser and the web server. Any credentials you enter on the web interface can’t be intercepted by a "man-in-the-middle" attack or seen in plain text on the network connection. Instead, that data is encrypted.

The cipher used to encrypt this information is agreed upon by the web server and the web browser. The server offers several allowable ciphers, and the web browser then picks (usually) the best one of those that it can support. The browser then uses that cipher to encrypt information.

The list of ciphers that the web server allows is called the cipher suite string. The default cipher suite string for OpenVPN Access Server is reasonably secure. There are some older ciphers allowed to offer compatibility for older web browsers and operating systems.

We recommend running the web server through an online SSL security checker like Qualys SSL Labs SSL Server Test. You can see a grade for your current settings and then adjust the cipher suite string to eliminate weak ciphers and improve the grade and thus the security of your web server.

The cipher suite string must be set through the command line and is described in the custom cipher suite string for the web server section of the command line tools documentation.

Note: Users with older browsers or operating systems won’t be able to connect to the web interface anymore if the older ciphers they must use are removed. We recommend having users upgrade their browser or OS.

Isolating the web services

Some of our customers do not want the web services visible on the Internet, but only want the OpenVPN daemons reachable for VPN tunnel termination. We advise against doing this because of the fact that managing the Access Server without a web service makes things a lot more difficult. You would then have to rely on using the command line interface tools to manage the Access Server settings, users, and certificates, and also the distribution of the required connection profiles to the users. Having the web services available makes this a lot easier. Furthermore, the OpenVPN Connect Client may require the web services of the Access Server using a secure XML-RPC connection over SSL. Making the web services unreachable from the Internet will force you to use user-locked or auto-login profiles only. In short you may end up breaking some of the designed functionality and force you to do some extra work.

However, if you really want to, you can choose to for example only allow ports TCP 443 and UDP 1194 default ports for the OpenVPN daemons from the Internet through your firewalls to your Access Server installation, and then disable the service forwarding options for the client web UI and the admin web UI in the Server Network Settings page. Those two actions together will make the web interface unreachable from the Internet but still allow incoming OpenVPN tunnels to make a connection. But server-locked profiles may not be able to connect anymore. To learn more about what the service forwarding is, and what effect it has, check the description in the command line page describing how to configure the web service forwarding settings. To learn about the various types of connection profiles see the connection profiles page.