Security

Dynamic Firewall

The dynamic firewall provides the highest level of security available in Pritunl. When a server is run with the dynamic firewall enabled the VPN port will not be open to the internet. The Pritunl server will block access to the port with iptables. When configured the only port open to the internet on a Pritunl server will be the web server. This design in combination with the high level of security provided from the dual web server can make a Pritunl server nearly impossible to attack from unauthenticated attackers. When using the dynamic firewall only the Pritunl Client that is updated to a supported version will be able to connect. Other OpenVPN clients are not supported. Currently server linking is not supported with the dynamic firewall.

This server option can be used along side existing VPN servers on the same host to support other OpenVPN clients or to allow transitioning to the dynamic firewall from servers that do not have the feature enabled.

For a client to connect the Pritunl client will first authenticate with the Pritunl web server. A Pritunl client profile includes multiple keys that allow for multiple layers of encryption. This connection approval request will utilize these keys to create three layers of authorization for the request. The components of this are explained below. Many administrators do not configure a valid HTTPS certificate and HTTPS is not relied on or required to provide secure authentication.

• Client SHA512-HMAC Key (Authorization)
  The client will use a SHA512-HMAC secret to sign each connection request. The server will also use this secret to sign the response allowing the client to verify the connection response. This is the same authentication system used to authorize the client configuration sync which syncs profile configuration changes such as host addresses and server port changes (private keys are never synced).

• Client/Server NaCl Asymmetric Key (Authorization + Encryption)
  The client utilizes a NaCl public key for the server that is included in the client profile. This provides asymmetric encryption of the connection request from the client to the server. The server will encrypt the response with the clients NaCl public key providing encryption of the response. The client will also verify the server response using the server NaCl public key. This is the same authentication system used to provide the additional layer of encryption and authorization available in OpenVPN connections with passwords and two-factor codes.

• Client RSA-4096 Asymmetric Key (Authorization)
  The clients RSA certificate and key is used to sign each connection request. The server will use this verify the client connection request. This is the same certificate used to verify OpenVPN connections.

Once the Pritunl server validates the connection approval request the server will open the VPN port for the requested server to the client IP addresses. Three sources are used to determine the client IP address, the client provided IPv4 and IPv6 address discovered from the Pritunl app servers and the remote address of the incoming web request on the Pritunl server.

Pritunl web servers are often run behind load balancers, by utilizing the Pritunl app servers even if the web request returns the load balancer IP address the server will still have the correct address. Additionally the Pritunl server will return the IP address of the Pritunl host that received the connection approval. This ensures the client will connect to the correct Pritunl VPN server when sending a request to multiple Pritunl web servers behind a load balancer. It is not recommended to ever configure Pritunl VPN servers behind a network load balancer as the client will already choose a server at random. When using the dynamic firewall a network load balancer cannot be used.

An external firewall or security group will still need to be configured when using the dynamic firewall. The dynamic firewall only controls access to the VPN ports of the VPN servers that have the dynamic firewall enabled. Servers will still have other open ports such as SSH that need to be controlled externally.

To enable the option an enterprise subscription is required. In the advanced server settings enable the Dynamic Client Firewall option.

Dual Web Server

The Pritunl web console uses an internal and external web server. This was done to protect the internal Python process.

The pritunl-web process is a Golang web server that will handle SSL and validate the incoming data. The Golang web server has a very good history of security and this isolation provides a high level of protection from RCE attacks. Additionally on RHEL distributions SELinux policies are included with the pritunl package that will significantly limit the capabilities of the pritunl-web process providing additional protection from RCE attacks. Every web handler and the JSON data structure for that handler is statically defined in pritunl-web. This prevents unexpected types or data structures from reaching the internal Python process.

Each request is also recreated with only known headers and valid JSON data. The validated JSON data is parsed then serialized again to ensure only the valid parsed data is transferred to the new request. The new request is then sent to the internal pritunl process and the response is returned to the client. There have been several header and parsing related CVE's with the Golang web server and reverse proxy. The pritunl-web server has not been affected by these issues and does not utilize the Golang reverse proxy. By creating new requests that are known to be clean vulnerabilities with request smuggling and corrupted HTTP data are extremely unlikely.

The web server in the internal pritunl process is bound only to 127.0.0.1 to accept requests from the pritunl-web process. This process also contains additional input data validation and has SELinux policies.

Self Shutdown Notification System

Every hour the Pritunl server sends a request to https://app.pritunl.com/notification with the version of the Pritunl server. If a vulnerability with a past version of Pritunl is found the notification server can send back the state for three categories www, web and vpn. A shutdown state for www will block all incoming web requests to the web server and instead return a message indicating the reason. A shutdown state for web will stop the pritunl-web external web server process and disable the internal pritunl web server. A shutdown state for vpn will stop and disable all running VPN servers.

With this system there is no need to monitor and wait for emails indicating updates are required for urgent security issues. Within an hour of discovering an issue all running Pritunl servers will be protected with a self shutdown.

OpenVPN Process Permissions

By default the OpenVPN process runs as root. This can be changed by enabling Drop OpenVPN Permissions in the top right settings from the Pritunl web console. Once enabled OpenVPN servers will drop to a non-root user after starting. This may not work with all Linux distributions, test starting a non-production server first.