LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)
-   -   OpenVPN: client password security? (https://www.linuxquestions.org/questions/linux-security-4/openvpn-client-password-security-893264/)

catkin 07-22-2011 11:26 PM

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

ne pas 07-23-2011 05:44 PM

The next Howto section gives you the answer:
Quote:

source: OpenVPN Howto - Using alternative authentication methods

----8<----
Using username/password authentication as the only form of client authentication

By default, using auth-user-pass-verify or a username/password-checking plugin on the server will enable dual authentication, requiring that both client-certificate and username/password authentication succeed in order for the client to be authenticated.

---->8----
So if the client removes the auth-user-pass line from the configuration file, the authentication will fail.
I've check what messages he will get on client-side:
Quote:

Jul 24 00:31:30 hendrix ovpn-client[15907]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Jul 24 00:31:30 hendrix ovpn-client[15907]: TLS Error: TLS handshake failed
and on server-side
Quote:

Jul 24 00:26:20 herold ovpn-server[20083]: 172.23.4.100:46575 TLS Error: Auth Username/Password was not provided by peer
Jul 24 00:26:20 herold ovpn-server[20083]: 172.23.4.100:46575 TLS Error: TLS handshake failed
Jul 24 00:26:20 herold ovpn-server[20083]: 172.23.4.100:46575 SIGUSR1[soft,tls-error] received, client-instance restarting
Cheers, Chris

catkin 07-24-2011 11:03 AM

Thanks Chris :)

There had to be something like that and I appreciate you spelling it out for me.

scheidel21 07-24-2011 06:19 PM

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.

catkin 07-25-2011 04:49 AM

Thanks scheidel21 :)

If I understand correctly, neither solution supports:
  1. The client is a Windows system and the user is not a member of the Administrators group.
  2. Only at-risk client computers require authentication by password.
Regards the first item, AFAIK the only way to provide OpenVPN client to non-administrative users is to run it as a service, in which case there is no way for the user to provide the password for a password-encrypted key (unless it is in a file which defeats the object). There is an OpenVPN users mailing list thread on this topic starting in June 07 that does not identify a solution.

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.

scheidel21 07-25-2011 11:13 AM

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.

catkin 07-25-2011 11:20 AM

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.

scheidel21 07-25-2011 12:28 PM

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.

catkin 07-26-2011 01:58 AM

Quote:

Originally Posted by scheidel21 (Post 4424755)
Have you by any chance considered a batch or Vbscript running as a specified user instead of using the openVPN GUI?

No. Can you explain how it would work?

scheidel21 07-26-2011 08:57 AM

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.

catkin 07-26-2011 10:47 AM

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.
  • CPAU. The original but not actively maintained and has weak encryption so a 14 character Administrator password is recommended -- not something the sysadmins would like!
  • Encrypted RunAs (ERAS). Some nice design features but only price found on website was USD 200 (by starting order process). Puts me off when suppliers are not up-front about pricing.
  • RunasSpc. Rijndaels AES 256 Bit encryption (mentioned here, not confirmed on vendor's website). Free for private use (and presumably trial). 10 computer license Eur.30.
  • Steel RunAs. Multiple loop RC4 encryption with Pseudo Random Seed. 10 user license Eur.20. No info on site about trial version.
Have asked RunasSpc about encryption and Steel RunAs about a trial version.

scheidel21 07-26-2011 12:10 PM

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.

catkin 07-27-2011 04:10 AM

RunasSpc replied quickly and confirmed that they do use Rijndaels AES 256 Bit encryption so that will be the one I will evaluate.

scheidel21 07-27-2011 08:00 AM

Well hope it works out for you, please let us know.

scheidel21 07-28-2011 09:36 AM

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.