Koozali.org: home of the SME Server
Contribs.org Forums => General Discussion => Topic started by: sektor on November 23, 2014, 01:05:35 AM
-
Hey guys I came across this from another forum and I thought it might be a really good idea for possibly as a patch or part of the future release and was wondering how easy would it be to implement on SME server. Please forgive me if I am not allowed to post links to other sites.
http://pbxinaflash.com/community/index.php?threads/secure-your-linux-desktop-and-ssh-login-using-two-factor-google-authenticator.15735/
-
Interesting idea in this application, and shouldn't be too hard to implement. I'd think, though, that public key authentication for SSH would be better yet (and the post you link to suggests the same). I guess if you couldn't guarantee that you'd always have access to a trusted device to ssh in, though...
-
Well it's not using public key you can still have a password and just add the additional authentication option where if you don't have access to the revolving password app or the predetermined keys you are not going to get in. I have 2 factor setup for both my facebook and gmail accounts and alot of companies are implementing something similar for vpn access, but hey anyway to increase security right? I think I was going to try it on my sme 9 virtual machine that I play around with and hey it would be cool if it could be factored in for the web portal as well.
-
Certainly security is a good thing. It looks like it's even possible to do public key auth with SSH or, if the public key isn't presented, require the authenticator token (see http://serverfault.com/questions/594938/public-key-or-password-google-authenticator-for-ssh-login). I'm still not sure how likely it is to be in a situation where you won't have access to a trusted device for ssh (my iPhone has a free ssh client with public key authentication), but this would give you both options, and be more secure than passwords alone. I tend to think of ssh public key authentication as more secure, but that doesn't seem to be universally accepted from what google search results are showing.
When I set up Joomla! a few weeks ago, it has an option for two-factor authentication, and I thought about suggesting to add it to the server-manager login at the time. Keep in mind, though, that the server-manager is only accessible from the LAN. SME Server generally assumes that the LAN can be trusted.
-
Actually mine I kind of have it on the outside as well just in case, but I may even try to setup vpn with that 2 factor authentication as well. See how far I can take it I'm not much of a developer but pretty good at figuring things out. I just have to figure out what handles server manager authentication to see if it can be tweaked and I'm sure for SSH a custom template can be created.
I know it's a no no, but from work I can't use ssh tunneling on a non standard port and if I leave ssh on port 22 I pretty much get a knock on my door from all over the world mainly the middle east, but I have blocked a bunch of those ip ranges in iptables. as well as ssh blocks them after a failed attempt.
-
I installed fail2ban (http://wiki.contribs.org/Fail2ban) a few weeks ago, and it's been pretty active in shutting down attacks against a number of sources, mostly ssh. Since I disabled password logins on ssh the other day, though, the ssh blocks have virtually disappeared--I expect because they don't even get that far.
If you've exposed the server manager on your installation to the internet, you're definitely more vulnerable than a stock system. Adding two-factor authentication would make that more secure, but using a VPN to access the server manager remotely would be more secure yet.
I don't know if it's possible to add two-factor auth to the built-in PPTP VPN. You might consider instead using OpenVPN (http://wiki.contribs.org/OpenVPN_Bridge), which uses public key authentication (optionally with a username and password as well) and is much more secure.
-
sektor
Having password access enabled for SSH access to your server is a bad security model. You are asking to be hacked & probably in time you might get hacked.
Even using a non standard port (ie something other than 22) does not enhance security at all, it might stop many junior hackers who do not bother to try other ports, but serious hackers can easily scan for other open ports eg SSH on port 221 or whatever & start their attacks.
While multiple layers of authentication may be an answer, SME server does not have that, & changing templates may introduce other security holes.
At present the use of public/private keys to access SSH is very secure (with password access disabled), without the key it is impossible (in real world practical terms) to access SSH. Maybe with a Cray computer you might hack the key after a few years, but most people do not have that resource available to them or the time, energy & dedication to keep up such a sustained attack on a personal or small business server.
As DanB35 says, & I use it also, you can configure key access on most smartphones using good quality free or at cost SSH apps.
Once you have secure SSH access established you can then use the text based server manager if you really need access to that, or create a SSH tunnel to then allow web browser GUI server manager access via http://localhost/server-manager
If your work LAN access blocks some of those, then try tethering your smartphone via USB & use the 3G/4G Internet connection to access your home server.
Also re your comments about using VPN, well that is no longer secure. There was comment in these forums some months ago about that, & you can google for upstream advisories.
I think there is a suggestion to remove the current VPN from SME server & replace it with a secure version (refer one of the current contribs).
The only secure SSH connection method is public/private keys. There is a very good Howto (see link at top of forums) & it is fairly straightforward to implement. You can export the key to your smartphone app & carry the key with you on a USB memory stick, & even have the Putty exe on the USB, to use wherever you are in the world.
-
Also re your comments about using VPN, well that is no longer secure.
The PPTP VPN protocol, which is what SME ships with, is not secure (see http://en.wikipedia.org/wiki/Point-to-Point_Tunneling_Protocol#Security for one review of security issues), and has been known to be insecure for at least a couple of years. VPN technology in general is not insecure, though--it depends on the protocol and implementation in question. The problem is that the secure VPN implementations like OpenVPN require some kind of public key infrastructure, which significantly complicates the configuration. Either you need to learn openssl from the command line to some degree of proficiency, or you need to install some sort of web or GUI PKI manager.
There's always tension between security and convenience. PPTP is convenient, in that it requires only a username and password. The implementation of OpenVPN currently available for SME is much less convenient, but much more secure. I think it could be better, but it would take some coding to integrate PHPki and the OpenVPN server-manager panel.
-
PPTP - Hence a couple of bugs open on this already :
http://bugs.contribs.org/show_bug.cgi?id=8677
http://bugs.contribs.org/show_bug.cgi?id=8667
Always good to have a look in the bug tracker as that is where new things tend to appear. Yes we are looking seriously at a PPTP replacement - however, we do appreciate that pure certificate based methods aren't always satisfactory for some so are considering alternatives.
Add yourselves to the bugs to see progress.
B. Rgds
John
-
Actually there is a web based pki manager for sme server that is local lan only I just haven't had time to play with it and I agree with your findings and if my server does eventually get hacked it's only a home based server, but now that I am on short term disability due to back surgery I do have some more time on my hands I will look into your suggestions. In regards to messing with templates I was only going to do on a test environment just to see how it would work out and maybe it can be eventually submitted as a possible future security enhancement and in actuality I was thinking about locking down server manager to only a couple of ip subnets that I normally access it from I just have to figure those out, my server is merely for me to toy around with and obviously I wouldn't open any holes in a major production server. Thank you for your input and suggestions though.
-
Google Authenticator, is that talking with any Google service in any way?
If so, NO GO area. US Patriot Act is in effect. Massive security risk by itself.
guest
-
Interesting that I will have to do more research on, but thank you for your input. Like I said it was just something I encountered out there is all.
-
Not sure some would like this due to privacy concerns amongst other things.
Personally I would never run it.
However, there is nothing to stop you building a contrib for those who may be interested.
B. Rgds
John
-
Not sure some would like this due to privacy concerns amongst other things.
Personally I would never run it.
However, there is nothing to stop you building a contrib for those who may be interested.
B. Rgds
John
I agree, it's a free world. But next to privacy concerns, corporate policies (the company you work for) may prevent the usage of external "gateways".
I would never use it.
-
IMVHO, ssh with keys is secure enough..
we should really work to replace pptp vpn with openvpn as the default vpn in SME
-
IMVHO, ssh with keys is secure enough..
we should really work to replace pptp vpn with openvpn as the default vpn in SME
again, depends on the security policies. Question remains, for a secure VPN solution, pure IPSEC or OpenVPN? Or I could be mistaking at all.
I am not in favor of any flavor, just want to make sure we choose an industry standard, deploy able in all kinds of scenarios. Where I *read* that pure IPSEC is "most compatible" with routers, gateways and such HW devices.
guest
-
Stefano,
check the bugs as a PPTP replacement is being looked at as we speak :-P
-
I have no doubt about it :-D
-
Google Authenticator, is that talking with any Google service in any way?
No, it isn't. Google Authenticator was developed by Google as an implementation of RFC 6238, and multiple open-source implementations for both the client side and the server side are available. By default, the Google code calls a Google site once, on account setup, to generate a QR code with the account details (username and host, but not password) and secret key, but if that bothers you, you can bypass the QR code entirely and enter those details manually. Or, no doubt, that can be generated locally as well.
There is no need to communicate with any external resource on login to verify the one-time password; that is done directly between the client and the server. The only requirement is that the client and server both have clocks that are pretty close to each other.
-
Thank you for clarifying that DanB and great conversation guys, btw I also wanted to say thanks for all you do as part of this great project I really like it, it's not difficult to use, has everything you need, easily customizable, great support and I like how several of you chimed in on a thought I had that I haven't had a chance to play with yet and all the suggestions are much appreciated.
BTW I hope you guys had a good thanksgiving if you celebrate it.
-
By default, the Google code calls a Google site once, on account setup, to generate a QR code with the account details (username and host, but not password) and secret key, but if that bothers you, you can bypass the QR code entirely and enter those details manually. Or, no doubt, that can be generated locally as well.
Thanks for clarifying that.
It also means that by creating an account with Google, I agree to the consolidated Terms of service of all Google services, including the fact that Google is required to comply with the US Patriot Act. Same for any Android device that registers with Google. (or any Apple device for that matter).
So for me a no go area. But good talk.
guest
-
BTW I hope you guys had a good thanksgiving if you celebrate it.
Thanks but in EU and November 28th here already. BLACK FRIDAY!! :wink:
-
Did you get your shopping done?
-
All HF wants for Xmas is a mustard seed grinder :-)
-
It also means that by creating an account with Google, I agree to the consolidated Terms of service of all Google services, including the fact that Google is required to comply with the US Patriot Act.
Please, enough with the FUD. There is no need to create an account with Google to use Google Authenticator. You don't even need to use Google's app, as there are others that will handle the client side too (I use Authy, for example).
I don't think this is something especially useful for SSH security, as public-key authentication is already there and is more secure. But let that decision be made on the facts, one of which is that Google isn't going to get any information about you, your site, or your account unless you specifically send it. You don't need a Google account; Google doesn't check your logins; and your login, hostname, and secret key are only sent to Google if you take the URL it gives you and put it in a web browser to get a QR code.
Here's the output of running google-authenticator:
bash-4.1$ google-authenticator
https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/dan@sme-test%3Fsecret%3DESIX2XUGQN2WJWW2
Your new secret key is: ESIX2XUGQN2WJWW2
Your verification code is 610810
Your emergency scratch codes are:
72938720
47270924
37045962
28597796
33967286
Do you want me to update your "~/.google_authenticator" file (y/n) y
Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n) y
By default, tokens are good for 30 seconds and in order to compensate for
possible time-skew between the client and the server, we allow an extra
token before and after the current time. If you experience problems with poor
time synchronization, you can increase the window from its default
size of 1:30min to about 4min. Do you want to do so (y/n) n
If the computer that you are logging into isn't hardened against brute-force
login attempts, you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting (y/n) y
As you see, the first thing it gives you is a URL. If you plug that URL into your browser, it will show you a QR code that you can use to set up the account on your smartphone. And you'll see that the URL goes to Google, so it's possible they could retain the user, hostname, and secret key (I have no idea whether they do or not, but they could). This is the only part of the process that communicates with Google at all, and it's optional. If that concerns you, you can instead enter the key manually into your smartphone or other app. If this were to be integrated with SME Server, the QR code could just as well be generated locally, so users could have the easy setup of the QR code and there would still be nothing in Google's logs.
ETA: Here's a pretty good writeup on how the system works: http://garbagecollected.org/2014/09/14/how-google-authenticator-works/
-
I'd like to bump this thread. Interesting topic to keep alive.
-
Holy necro-thread, Batman!
Several topics were discussed in this thread--which did you think were worth reviving? On a quick review, I see:
- 2FA for SSH
- 2FA for server-manager
- 2FA for VPN connections
- Relative merits of different VPN software/protocols
I don't really see any value in 2FA for SSH; public key authentication is a secure and mature technology. I don't see the value in it for access to the server-manager either; the LAN is presumed to be safe, so the extra layer would be unnecessary. I could see it for VPN connections, if they were otherwise secured with only username/password, but I'm not sure if it's feasible to implement.
-
I second Dan for ssh ( regarding public rsa key exchange is used and password disabled), vpn ( using correct keys and not passwords) and server manager (as it is on https on lan only or trusted external ip or over ssh or vpn)
This could however be nice for email client connexion (webmail and pops/imaps). From the outside of the LAN and for other similar http auth.
One point changing from the time of this thread is the possibility of accepted ssl certificate with letsencrypt, that ease the use and trust of https connexion to SME.
-
This could however be nice for email client connexion (webmail and pops/imaps). From the outside of the LAN and for other similar http auth.
That's certainly possible, at least in principle, with webmail (Horde doesn't currently support 2FA, but maybe an alternative webmail app does), but could it work with POP/IMAP? I admit I know very little about the internals of either protocol, but I don't know of a way that they could require a third login credential (user/pass/token) and validate it against the proper backend.
One point changing from the time of this thread is the possibility of accepted ssl certificate with letsencrypt, that ease the use and trust of https connexion to SME.
Definitely, and I look forward to LE support being part of the base distro.
-
This could however be nice for email client connexion (webmail and pops/imaps). From the outside of the LAN and for other similar http auth.
That is exactly what I am looking for, just not limited to webmail but for all (contrib) web applications. If at all possible.....
-
That is exactly what I am looking for, just not limited to webmail but for all (contrib) web applications. If at all possible.....
Then we should seek either a apache auth with this or a way to use it in lemon:ldap. Or both
-
once upon a time I used the OTP (http://www.cl.cam.ac.uk/~mgk25/otpw.html) approach
-
Then we should seek either a apache auth with this or a way to use it in lemon:ldap. Or both
I would opt for an Apache auth way of doing things. Nothing against lemonLDAP but it brings a lot of overhead for the specific task.