Countless organizations have transitioned their operations from in-person offices to remote working. To shed light on the tools that are most often used in these transitions, Tetra Defense explains how to strengthen defenses when using the OpenVPN client.
Pop culture often makes multiple layers of security look dramatic and action-packed. Every quintessential spy movie has that scene where a character either enters (or breaks into) a high-security room. First, there’s a door, then a password, then a retina-scanner, fingerprint scanner, voice recognition test, unique key, etc. While these extreme measures aren’t the most realistic, a very similar scene applies to a cybersecurity environment. For a threat actor trying to access a network, the simple truth is that it’s easier to break in if only one barrier is in the way. It’s harder to bypass the combination of a door and a hallway of dancing lasers.
Let’s take the real-world example of suddenly moving an entire business’ operation to completely remote work. Consider the first barrier as a Virtual Private Network (VPN), and the retina scanner, the unique key card, or any other spy movie trope as a Multi-Factor Authentication tool, often called MFA or 2FA.
The traditional office or school campus provided a set number of machines connected to a single, secure network, including relevant files and databases that could not be reached from the public internet. The challenge in recent times is that of accessibility and security: How can the same, secure network be provided to those who are no longer under one roof? VPNs are a highly recommended tool to maintain security across a large, sparse distance. For organizations that have recently transitioned to remote work or study, OpenVPN has been a popular choice. The tool is widely available, is an open-source application, and is known for maintaining a private network on the public internet, all without sacrificing security.
The Next Barrier
The VPN is usually protected with standard account credentials, unique usernames and strong, account-specific passwords that are not shared, only known to the user, and at least 12 characters long. Robust passwords like this are critical to keeping accounts safe, but there is still a need for a second (albeit less dramatic) barrier beyond. Threat actors have an equally robust arsenal of automated tools that can crack passwords; there are dictionary attacks to decipher common words and instant brute-force attacks that calculate every possible combination of characters within seconds.
If a threat actor finds credentials this way, MFA can thwart them since it requires authentication from a separate source. This is often in the form of something a user can know (What is your mother’s maiden name? Where was your first job held?), something a user has (a unique key, a cell phone with a code), or something a user is (facial recognition, fingerprint scan). If a threat actor cannot verify the second factor of authentication, then the account remains locked, and a potential attack is prevented.
While effective, MFA can indeed be cumbersome. The time it takes to retrieve a new device or remember an oddly specific answer sacrifices convenience, especially when sites and tools can “remember” an account on a user’s behalf. For users of OpenVPN, many admins have implemented MFA only to be inundated with reports of connection instability. This is a perplexing problem; MFA should not impact the general reliability of OpenVPN connections, but it often does.
While users attempted to log in, the time required to use MFA would suspend all traffic, for all users, until the account in question could be verified. For organizations with more than a handful of employees, this meant that the use of their VPN would be interrupted incessantly as their colleagues logged in one by one, time delay by time delay, dozens of times per day. The root cause of these interruptions is not easy to find, and many admins simply give up and disable MFA despite this significantly weakening their security. While the root cause is difficult to identify, the fix is relatively simple.
Douglas Mueller, Director of Technical Operations, offers the following explanations: “Open VPN is a great tool, but implementing MFA posed a problem because the entire operation would cease during the time required to verify the multi-factor in question. OpenVPN is ‘single-threaded;’ all traffic stops until the backend authentication service returns a result.” Keeping traffic flowing would require a customized script for external authentication.
Three pieces to this puzzle included the OpenVPN server, the authentication piece, and a technical bridge to connect them. The technical bridge in this case is a unique script via a C plugin API. Without this script, the OpenVPN server is essentially forced to “wait” and stop traffic until the authentication is complete, despite the time delay that’s required to retrieve a second device or plug in a security code. With the script, the OpenVPN server is told to essentially check back soon to see if a user can authenticate, and it no longer locks traffic for everyone.
An important note to make here about the script solution is that it has to actually communicate with the authentication piece as well. The script itself does not authenticate, but rather acts as a bridge to connect the authentication piece to the flexible OpenVPN server to avoid a traffic jam. A possible template that can be implemented to fulfill this “bridge” role lies within Linux-PAM, or Pluggable Authentication Module. Depending on the unique configurations of an organization, these templates can be customized and implemented to essentially solve the packet loss and hang-ups that some users experienced while using OpenVPN.
This is a known issue, and thanks to collaborative resources, there are many avenues to follow when finding a solution. To find, create, and implement the script that will work best to bridge the gap between an organization’s OpenVPN server and a preferred authentication method, we recommend insights from:
Layers of Security
While MFA can be cumbersome at times, especially if the time delay locks all traffic on a VPN, it is still necessary. Given the accessibility of credentials for sale on the dark web and the ease of software that can apply countless passwords in a matter of seconds, MFA is an effective second barrier that can keep an account safe. In the era of “working from home,” a VPN is a useful tool to keep an organization’s network private. Still, just as no spy movie has only one barrier, it’s imperative to strengthen defenses on multiple layers.