How can I validate that VPN clients are machines owned by the company?

Question

Employees that travel can access some of our servers through a VPN. This works fine and isn't a problem on its own. Some days ago I noticed that seemingly a VPN Client was trying to perform a portscan on the internal network. I then scanned the host and found out that it wasn't a device owned by our company. When I talked to the user associated with the certificate that was used to initialize the connection he admitted that he did copy the VPN client to his private PC which obviously was infected with malware.

Is there a propper way to imlement something like a NAC for VPN clients to keep Hosts out that aren't owned by the company?

Answer 1

First, I would think about this slightly differently. Some folks will point to Device Fingerprinting as a mechanism, but I don't think that solves the real problem here.

I'm going to assume a well hardened VPN (Multi-Factor, Certificate required etc) in this circumstance. This is essentially the standard expectation for VPN. Now this in it of itself doesn't solve the problem you describe.

Unless you have seriously strong client management including: nobody is ever an admin who shouldn't be, it's nearly impossible to prevent someone who really wants to from exporting the certificate (priv/pub) you issue for the client.

To squash these potential leaks of the certificates needed to get on VPN you need to prevent the certificate from being exported in any way. There are two ways to go about certificate management that are meant to do just that. The first is traditional Smartcard based, you can get them in credit card size, or now the new chiclet size.

Credit Card Sized

Chiclet Sized (smaller than pictured here.)

If these are untenable, or expensive (they can be both) for your organization, you can look into using Virtual Smartcards. These function essentially the same as the physical smartcards except they use the machine's TPM and a third party driver to perform those operations, and hold the relevant private keys.

Now TPM is the mechanism hardware providers will indicate is the best (and academically I agree with that logic) however, practically you'll find the way you interact with VPN clients the best is to stick to the certificate interactions. Virtual smartcards give you both the host-stickiness of the TPM and most of the time is just easier to interact with.

The reason for the SmartCard like functionality is it makes it virtually impossible (presently) to extract the certificate's private keys without a significant level of effort. Using the TPM as the mechanism now ties certificate to machine.

With good lifecycle management and tightly controlling where you issue these certificates. You can do a pretty darn good job of authenticating that devices you have issued these certificates to are the ones connecting to VPN.

Answer 2

The problem is that there is little differences between a corporate machine holding a certificate and another machine holding same certificate!

IMHO there are 2 lines of defense here:

1. First is social: employees allowed to use the VPN should sign a charter to acknowledge they know that they may only connect corporate machines to the VPN and that connecting another machine would be a security attack - far from a panacea but never forget to educate users...
2. Second is technical, but harder. Some VPN solutions can control that any machine connecting to the network has the required antivirus installed and all required patches. I'm not used to OpenVPN, but you could try to encapsulate the connection in a piece of software installed on the client machine that scans it for the presence of required security software (antivirus and system patches) and sends a report to the server. If the server does not validate the report, the connection is broken. It is still possible to fake that machine authentication, but then it is really intentional and the user should have to explain why he/she did that...

In fact that second technical way mainly allows to control that the client machine follows the corporate security rules to avoid some (VIP...) users to never connect their laptop to the main network to load the security patches and antivirus signatures...

Answer 3

While the specific solution will depend on your VPN client, in theory, you should be able to set things up so that the connecting system needs to have a valid client certificate where the client certificate is tied to a specific client (most likely based on MAC). The only problem with this approach is it will result in higher administration overheads as you will need to issue individual certificates for each staff machine, revoke them when machines are retired and issue new ones when staff get upgrades etc. How much of an overhead this is will depend on the number of staff and staff retention rates etc.

One area to research would be to google 'zero trust networks'. In a zero trust network, you ignore the local/external network distinction and instead use a combination of user and machine verification to determine access levels. Users are authorised to access services based on a combination of their personal credentials and the device they are connecting from.

Answer 4

If your company has an HIPS, application whitelist can be enforced centrally which can be used for this purpose.

The more complicated way is to use hashes for validating the client executable. Calculate the hash for the original file and verify the value each time you have to install it.