OpenVMS cuteness

220 xx.xx.xx.edu MultiNet FTP Server Process V5.2(16) at Thu 26-Mar-2009 8:19PM-EDT

ftp> site window-size 1073741824
200 TCP window size now 1073741824 bytes

Strangest ftp command competition, anyone?

OpenVPN: LDAP and ipset says you may.

Our ad-hoc authorization scheme proceeds. Adding custom schemas to OpenLDAP is pretty easy. (vpnaccess.schema)

ipset lets us define netfilter rules against named, dynamic sets of ips, like:

ipset -N bofhirc iphash
iptables -m set --set bofhirc src -d bofhirc.example.org -p tcp \
-m tcp --dport 22 -j ACCEPT

adds a rule giving only ips added to the bofhirc set access to bofhirc.example.org port 22. How ips are added to that set is up to you (Port knocking, messenger pigeon, ocr on a piece of paper held up in front of a webcam...) but involves ipset -A bofhirc <ip> at some point. And hopefully ipset -D bofhirc <ip> at some other point to revoke that access again. All without disturbing your carefully-tuned iptables config on every login.

A touch of the swiss army chainsaw with Net::LDAP to OpenVPN --client-connect (accesses-from-ldap-open.pl) and --client-disconnect (accesses-from-ldap-close.pl). Et voila. Adding accesses is now as easy as adding a named set of firewall rules, and adding:

objectClass: vpnAccessPerson
vpnAccess: bofhirc

to the relevant user in ldap. The ips involved are private and assigned by OpenVPN, so there's no risk of aliasing for multiple users behind a NAT.

OpenVPN: Hooked!

Authorization.

OpenVPN 2.x provides a bunch of script hooks. Which ones are most useful for authorization?

--up, --down ... mostly used on the client side. Restoring network settings on vpn disconnect with a --down hook, for example. Not suitable.

--route-up ... we don't have the user common_name at this point. Not suitable.

--ipchange ... discouraged in server mode.

--auth-user-pass-verify ... authentication. Too early. The client is untrusted and doesn't have an assigned ip yet.

--tls-verify ... pre-authentication. Too early.

--client-connect, --client-disconnect... straight after authentication, before client-specific config is read. Good enough, if we're a bit careful (i.e. don't change ip address assignments in client-specific config files), and easy to understand triggering conditions. Has all the parameters we need.

--learn-address ... perhaps the architecturally correct place to put it. Somewhat harder to understand the triggering condition. Documented as "Run script or shell command cmd to validate client virtual addresses or routes."

I know, I know, I promised perl hacking here... next time.

OpenVPN: May I?

I was recently asked to look at an existing road-warrior OpenVPN implementation, and see how it could be improved to differentiate network access levels per-user. Some users should have basic access, some should have access to their department's privileged systems, some should have usual department accesses plus temporary specific access to a customer system for setup and upgrades. Fun!

In computer security parlance, this is an authorization issue. Authentication is working, we know who you are, we don't know yet what you should have access to.

Users on this network is stored in LDAP, and the third-party OpenVPN Auth-LDAP plugin is used for authentication. RADIUS is not used anywhere, and adding it to the mix would add complexity and, strangely, not seem to gain us much - the third-party OpenVPN Radiusplugin only does authentication and accounting, and not really the "third A".

The Auth-LDAP plugin has some *BSD-specific code for interacting with PF. I considered rewriting that code to match requirements, but it's written in a pretty unfamiliar language (Objective-C) and has a number of limitations. A user can only be a member of one group (first-match) and group membership can only give access to one set of resources.

Thankfully, OpenVPN has lots of hooks for scripting. Perl hacking will ensue in next installment. Until then.