A Virtual Private Network (VPN) provides connections between servers and clients from various internal networks across a public network (for eg, the internet), just as though the nodes are located in the same private network. Since the communication is transported across a public network, it must be encrypted properly in order to prevent snooping. The extended network services can be accessed the same way, by a user connected to the VPN connection, as if they were placed with its private network.
There are two kinds of VPNs: site-to-site VPN that is used to connect two networks together and the remote-access VPN that is used to link a device to a network. A VPN can be used for different scenarios, such as permitting employees to safely access company’s internal network, even while being outside the office (remote-access VPN), or to connect two remote offices together into one private network (site-to-site VPN), etc.
VPN protocols have different implementations, including the ones that are listed below:
• Internet Protocol Security (IPsec): an extensively used VPN implementation using IPv4 and operating on layer 2. Here, the packet is enclosed into an IPsec header and is sent to its endpoint.
• Transport Layer Security (SSL/TLS): another broadly used VPN implementation, mostly incorporated with OpenVPN, which is an SSL-based VPN that uses SSL certificates to encode the data in transit.
• Microsoft Point-to-Point Encryption (MPPE)
• Datagram Transport Layer Security (DTLS)
• Secure Shell (SSH) VPN
• Microsoft Secure Socket Tunneling Protocol (SSTP)
According to the VPN being checked during penetration testing, there are numerous procedures that drive our testing. Regardless of the kind of VPN being used, following are the basic steps of pentesting the VPN:
Reconnaissance: The first step is determining the kind of VPN that we’re dealing with, so that one could plan how to progress with the attack. A simple port scan can help in doing that, by using an open-source tool such as Nmap and other tools with port scanning capabilities. The objective is deciding on the kind of VPN implementation that we are dealing with, as it often bounds with a default port.
Exploitation: This phase is under direct impact of the type of VPN being dealt with. While testing network-based IPSec VPN, we can depend on the Ike-scan program that performs testing. First, the VPN product can be identified, along with its version and related vulnerabilities can be searched online; different vendors like CheckPoint or Cisco have vulnerabilities about the VPN services, that can be used to our advantage. While handling the SSL VPN, we can theoretically use tools that are used for SSL pentesting, but most tools are only supporting TCP protocol, where UDP is not supported.
Credentials: When contact with the VPN server is initiated, a client must provide a valid passphrase or certificate that proves that the user is legitimate and is authorized to use the server. If only passphrases are being used by the VPN server, we should rather configure to use certificates with every passphrase, in order to improve security. I have usually seen a VPN server only using user credentials for authentication. Not to mention some user passwords that were quite simple and could be guessed within a few attempts. We certainly have to keep this in mind while conducting a VPN server penetration test, or while setting up a server for our own network.
Proposal for Hardening OpenVPN
In order to harden the OpenVPN security, the configuration file has to be edited. It is generally passed to the OpenVPN daemon by the option of -config command-line. If the “ps-ef” command and the OpenVPN processes are used, we can see the location of the configuration file and view it accordingly.
Table 1: Openvpn.conf Security Configuration Options
Following are some options with the description:
tls-auth: In this, an additional layer of security is provided that checks whether every SSL/TLS handshake packet has the correct HMAC signature. If that does not happen, the packet is rejected immediately. This option is safeguarded against DoS attacks, fingerprinting to understand if the UDP port is open, UDP port – flooding attacks, TLS/SSL handshakes from unapproved clients, etc. The 2048-bit static key for attestation of TLS packets can be generated with the following commands:
# openvpn –genkey –secret server.tls-auth – The key has to be available on the server, along with the clients who wish to link to the VPN server. Following has to be added to the server configuration – > tls-auth server.tls-auth 0
port (port): This explains the port that the OpenVPN server listens to for all incoming connections. By changing the OpenVPN default port server, the hacker might not be able to find the open port, or transfer to the next interesting port. By transferring the port to some other number, we are mainly using security through obscurity technique, which a lot of people do not consider as a security feature: > port 1234.
group (group): This configuration option usually allows OpenVPN daemon to exclude root privileges after the initialization phase. This offers an extra layer of security, as the daemon runs under nobody, not even under root user. This offers improved security, as the hacker can successfully exploit vulnerability in OpenVPN daemon. This immediately gains root privileges on the server. When the exact user/group directives are used, different unprivileged user accounts can be used to run the OpenVPN daemon.
It is understood that when an attacker comes across an open VPN port, he will most probably check for different security holes. Therefore, our VPN server has to be properly protected, so that our users, as well as the complete internal network can be secured.