Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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?
----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.
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:
Jul 24 00:31:30 hendrix ovpn-client: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Jul 24 00:31:30 hendrix ovpn-client: TLS Error: TLS handshake failed
If I understand correctly, neither solution supports:
The client is a Windows system and the user is not a member of the Administrators group.
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!
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.
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.
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.
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.
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 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.