Things I will need to do if I use OpenVPN

Skaperen

I'm only in the planning stages for this project, so I have no configurations to provide right now. I haven't even committed to OpenVPN, yet. It's just the first choice I'm looking at.

It seems the authentication choices are between users having signed certificates (where the server has all the private keys used to sign them), or the password method. I read that the password method is not recommended. I tend to agree with that. But here is one of my constraints. I cannot use key revocation based on the nature of how users will be permitted. The problem with that is that revocation requires keeping all the revocations forever. Process recovery requirements here won't allow that. The security policy is that if any information is lost, it must not permit anyone that should be denied. So that means no users should be allowed in unless they are specifically authorized to be allowed in, even though they might have been allowed in in the past. My understanding is that revoking a certificate records the fact that a particular certificate is revoked. If the revocation list is lost, it could allow users in that should not be allowed.

In this case "users" means clients. Think of a user with his own laptop that has an OpenVPN client.

Alternatives I can envision to this (but am unable to determine if suitable from documents like the HOWTO, or a few posts read here) are:

1. An alternate means to identify which user certificates are to be allowed, and if the user's certificate is not known, the user will be denied. In theory, the user would not need have the certificate signed at all, since the server would know the user from having the matching public part. SSH uses this method in its .ssh/authorized_keys file.

2. Generate a separate signing CA key for each user. A user would be "revoked" by removing the CA key only their key was signed with. This would be more cumbersome to manage users with. It may have scaling issues with thousands of CA keys to check users with.

3. The password method.

Is number 1 even possible? Is number 2 practical?

Another issue I am trying to figure out is users forging an incorrect IP address. The documentation shows that the method of having each user be given a specific IP address is to push a configuration setting to the user's client software. But what if the user turns black hat and runs a hacked client that disregards the pushed configuration? Is there a way to filter ... on a per user connection basis ... any forged IP addresses?

Clearly, if there are many users, OpenVPN has to track their IPs enough to route packets destined for users to the correct client endpoint. But if this internal routing is set up by client announcements, that could also be at risk of IP forgery. Are there any other means to make a hard association between a user (by whatever they authenticated with) and enforcement of their IP assignment(s)? Note, some users may have more than just a 10.X.X.X/30.

Doing this in the host iptables would not work, because at that point, which user a packet comes from or goes to is not known (other than what the IP address is, and that's the element to be verified).

And the third issue is per-user filtering policies. Each user would have different rules about what they are allowed to access or not. But I don't think this could scale in iptables, since this will be hundreds, possibly eventually thousands, of users, with a great many of them having perhaps half a dozen rules (mostly a few permits and deny all else). Thousands of iptable rules is not what I want to deal with.

If there is a way to do rule based filtering, or some other kind of filtering, internal to OpenVPN, where it only needs to apply the small set of rules for a specific user once it knows where a packet is going, or where it came from (similar to interface specific rules, where users would be interfaces), that would likely solve this one.

yyy

Revocated certificate in revocation list does not needs to be kept forever, it only needs to be kept till the end of validity period (when certificate expires naturally). (Unless certificates have indefinite validity, but I have not seen such X509 certificates, only PGP).
Specifically allowing users, which are permitted is done at CA, by signing only their certificates (and not signing certificates of users which should not be permitted, and revoking certificates of users which should not be permitted anymore (and putting that CRL at server)).

Bebop

Skaperen wroteThe security policy is that if any information is lost, it must not permit anyone that should be denied. So that means no users should be allowed in unless they are specifically authorized to be allowed in, even though they might have been allowed in in the past

i've handled this in the past with:
server.conf

ccd-exclusive
client-config-dir /etc/openvpn/ccd

When a user is approved for access to the VPN, a script is executed:
new_user_approved.sh

touch /etc/openvpn/ccd/kate_perry

When a user is forbidden from the network, a script is executed:
user_terminated.sh

rm -f /etc/openvpn/ccd/kate_perry

No user without their name in the CCD will be allowed access to the VPN.

Skaperen

Bebop wrotei've handled this in the past with:
server.conf

ccd-exclusive
client-config-dir /etc/openvpn/ccd

When a user is approved for access to the VPN, a script is executed:
new_user_approved.sh

touch /etc/openvpn/ccd/kate_perry

When a user is forbidden from the network, a script is executed:
user_terminated.sh

rm -f /etc/openvpn/ccd/kate_perry

No user without their name in the CCD will be allowed access to the VPN.

This looks like it will work much better for my situation than the revocation. I can simply (re-)construct the ccd directory (for other reasons, I would move it to /var) from the master database nightly, with update pushes as needed.

Is there an opportunity for a script hook (plugin) to handle the per-user ccd file in lieu of reading it from that directory? E.g. if the script is configured, it will be invoked with pipe and waited for it to output what that file contents would be, and its exit status. If status is 0 and valid contents passed back via the pipe, the user would be permitted according to that contents. If status is not zero or contents is empty, the user would not be permitted and the VPN session would be closed.

janjust

you can use a 'tls-verify' script for this : this script will check the full certificate name of the incoming client and if the script returns non-zero then the client is denied access. Of course, an example on how to use this is provided in my book 😉