tickets #160403
closedVPN security regression
0%
Description
With https://progress.opensuse.org/issues/151492 the username/passphrase authentication layer was removed from our OpenVPN setup. I found a security regression with this.
We allow VPN certificate authentication for all users in the "vpn" group - this is done by OpenVPN being configured to enforce a user specific CCD file being present, and Salt managing these CCD files based on the group membership in LDAP.
Previously, if a user was locked/disabled, the certificate authentication would succeed, but the LDAP bind would fail, correctly preventing disabled users from connecting.
By having removed the LDAP username/passphrase layer, we removed this protection, allowing users to connect regardless of whether their account is active or disabled.
Of course, a process change should take place which revokes certificates and updates the VPN CRL for disabled users. But currently this is not the case, and we have a big discrepancy between user lock and certificate validity statuses, especially given old VPN certificates being valid for 10 years (new ones 3 years).
A first mitigation for this is amending our Salt states to only place CCD files for users which are both, in the "vpn" group and are not locked/expired. I followed up with @firstyear on how to fetch this data from LDAP.
Afterwards we should look into some tooling to hook the same information into easy-rsa revocations.
Updated by crameleon about 2 months ago
- Due date set to 2023-11-28
- Start date changed from 2024-05-15 to 2023-11-28
- Follows communication #151492: VPN Security Configuration added
Updated by crameleon about 2 months ago
- Due date deleted (
2023-11-28) - Category set to Core services and virtual infrastructure
- Priority changed from Normal to High
- Start date changed from 2023-11-28 to 2024-05-15
Updated by crameleon about 2 months ago ยท Edited
Per discussion in IRC it seems the expiry or lock status is currently not exposed through LDAP, meaning we can't use this data to programmatically exclude the CCD files for disabled users. We could of course remove all disabled users from the "vpn" group, but assuming someone might return, it'd be good to have the account in the same condition as before.
For mitigation of the issue at hand it means we have to prioritize revoking certificates. But it would still be good to find some logic to clean up CCD files of disabled users as well.
Updated by firstyear about 2 months ago
It's currently possible to retrieve these data with a service-account and an API token to verify the users expiry state. If you want an example of how to do it, I can show you :) (it will work via ldap and http apis if you want).
Updated by firstyear about 2 months ago
I made an account that can read these data for you (the account has no write permissions). You can make an API token for it with:
kanidm service-account api-token generate openvpn-account-status
ldapsearch -H ldaps://idm.infra.opensuse.org -x -b o=heroes -D dn=token -w "ey...." '(class=*)' account_expire name
Updated by firstyear about 2 months ago
user@infra.opensuse.org, heroes¶
dn: spn=user@infra.opensuse.org,o=heroes
name: user
other@infra.opensuse.org, heroes¶
dn: spn=other@infra.opensuse.org,o=heroes
account_expire: 1970-01-01T00:00:00Z
name: other
For example.
Updated by crameleon about 2 months ago
Thank you very much! And my bad, in the chat it sounded like it was currently not possible at all. :-)
I'll work on incorporating this later.
Updated by crameleon about 1 month ago
- Status changed from New to In Progress
- Assignee set to crameleon
Preliminary refactoring of the CCD handling: https://gitlab.infra.opensuse.org/infra/salt/-/merge_requests/1833
Updated by crameleon about 1 month ago
Would it be possible to have the same account also be allowed to read the cn=vpn member entries? Currently it seems to return return 80 for those.
Or shall I construct two separate lookups (one unauthenticated query for the group members, and one authenticated query the account expiries)?
Updated by crameleon about 1 month ago
On a second thought, I think I need to separate calls anyways because I cannot join the two queries.
Updated by crameleon about 1 month ago
Updated by crameleon about 1 month ago
- Status changed from In Progress to Resolved
- Private changed from Yes to No