OpenVPN: client password security?
Hello :)
AIUI, OpenVPN without a password is essentially a computer-to-computer connection available to every user of the OpenVPN client computer who can start OpenVPN. In the case of a client computer to which an unintended user has physical access (for example a stolen laptop) and ruling out file system encryption, the assumption has to be that unintended users can start OpenVPN. I had hoped to tighten that up by requiring the user to enter a password but AIUI, based on the OpenVPN HOWTO, section Using alternative authentication methods the password requirement is controlled not by the OpenVPN server configuration but by the client configuration file including auth-user-pass. If that is correct, it does not help because an unintended user could simply remove it. That understanding seems improbable, being so easy to subvert. OpenVPN is nicely designed; surely (?) the password facility can be required per-client by the server configuration, no? Best Charles |
The next Howto section gives you the answer:
Quote:
I've check what messages he will get on client-side: Quote:
Quote:
|
Thanks Chris :)
There had to be something like that and I appreciate you spelling it out for me. |
I didn't go as far as username/pass, but you can also password protect the cert files that provide authentication, that what I do.
|
Thanks scheidel21 :)
If I understand correctly, neither solution supports:
Encouraging Windows users to use an Administrative logon for everyday work is unthinkable! :eek: Using auth-user-pass-verify in the server configuration would apply to all clients so does not suit the second item above. AFAIK no workaround is possible because OpenVPN does not provide any information about the client until the username and password is authenticated. At this point, auth-user-pass-verify is looking the most promising solution. It might not be a bad idea to require users of relatively secure computers to input a username and password anyway. Incidentally I stumbled on a good-looking book about OpenVPN: "OpenVPN, Building and Integrating Virtual Private Networks" by Markus Feilner. |
My users happen to be local admins, however, we run windows 7 which means they aren't truly running as full admins, but they can approve additional upgrade in permissions to perform actions or run things specifically as administrator. And have also had no trouble with the limited rights and being able to sign in except for pushed out routes. Of course I also run a bridged VPN, with a dedicated tap device, the creatign and breakdown of the tun device might be a problem I don't know.
Another option though is that they do have software for windows that will elt you specify credentials to run a program as, you could set that up then it would run with the appropriate admin privelages without them actually being an admin. |
Thanks scheidel21 :)
Yes -- would be OK with Windows 7 but we still have XP and Vista systems. The downside of using Run As or passwordless one-program equivalent is that the Openvpn GUI has potential for exploits. I might be being overly security conscious but the inconvenience of all users having to supply a user name and password seems worth it for a properly secure system. |
Well I haven't implemented full username and password log in, in addition to certs with passwords. I don't think you are being overly security conscience. Have you by any chance considered a batch or Vbscript running as a specified user instead of using the openVPN GUI? Otherwise username ans password is a good option.
|
Quote:
|
Well you could write a script that prompts for the cert password then runs starts openvpn via commandline and passes the password to the command. You use an application that allows the script to be run as admin with saved credentials so you do not provide the end user with admin credentials but the VPN connection will still work.
|
Thanks scheidel21 :)
Like a UNIX/Linux suid executable. Neat, like an automated "Run As" so the user does not have to know the Administrator's password. I found several programs that do this. Essentially they store the Administrator user name, password and script/command in a file. Alternatively some store the credentials etc. in a shortcut so the script/program itself does not have to be encrypted, providing security by running a CRC on the script/program to ensure that it has not changed. Limitations: the method means that the facility has to be re-configured whenever the Administrator password is changed (not nice to discourage changing passwords!) and if the target program is changed by an upgrade, the facility will break.
|
Steel RunAs is a popular one I know many people from the spiceworks community have used. But yea that's the idea, unfrotunately you are right about the password manually having to be changed, but you could use a local admin account to run it outside domain password policy, as long as you don't tell anyone the password it will be very secure.
|
RunasSpc replied quickly and confirmed that they do use Rijndaels AES 256 Bit encryption so that will be the one I will evaluate.
|
Well hope it works out for you, please let us know.
|
RunasSpc seems reasonably priced to me for business use. And I wouldn't worry too much about discouraging the password change, first I don't think that's their problem, it happens to be due to a limitation in Windows. Which actually leads me to one other idea, catkin have you considered trying to put the user into the powerusers group and seen if that will work? But I digress, if Windows handled privilege escalation and groups more like Linux this would all be moot. But I don't want to get into that discussion I just wanted to point it out.
|
All times are GMT -5. The time now is 10:42 AM. |