We have implemented sophisticated brute force protection for Linode Manager user accounts that combines a time delay on failed attempts, forced single threading of log in attempts from a given remote address, and automatic tarpitting of requests from attackers.
These protections increase the time it would take for a successful brute force by a couple aeons, and significantly impede dictionary attacks.
This solution is preferred over locking accounts, since that’s annoying and someone else could get your account locked by making a bunch of failed log in attempts using your username. Our solution still lets legitimate users make attempts – albeit a little slower than usual.
-Chris
Comments (31)
I’m a little surprised this wasn’t a feature in the past but I’m more than happy you’re adding it now. Thanks for looking out for your customers!
I’d really appreciate 2-factor authentication; there are multiple apps that enable the M-OTP standard, so I could use e.g. Google Authenticator to log in, the way I do with GMail and AWS.
Sweet, time to downgrade to a three letter password. =)
Seriously though, thanks for watching out for your customer accounts!
Two factor auth with Yubikey would be nice.
Since we have some pretty sensitive production systems running under our account, it would be nice for us to turn off certain Linode Manager features across the board for our users. For instance, if one of my staff members’ accounts is compromised, it would be great if the attacker had no way to reset the root password on a box. I’d prefer if we didn’t have that ability at all and instead had to go through Linode customer service.
if you do 2-factor authentication, don’t make it obligatory. not everyone likes it
Thanks to Linode for adding this feature.
I’ll reiterate what Nathan said — two-factor authentication with Yubikey or with an SMS text message to your cell phone would be really, really, nice to have. Bank of America, Google, Amazon AWS, and Passpack are the companies I use that are all doing this already. It helps me sleep better at night.
Yeah, good point John, do not make two-factor authentication obligatory. Make it optional, and easy to turn on and off.
@MAq just thinking out loud here, but even without the root pass reset tool one can accomplish resetting the root password in other ways – like by booting into rescue mode, or deploying a distro along side and attaching the old images, or even by booting with init=/bin/bash mode…
Caker, what do you mean by “even without the root pass reset tool one can accomplish the same thing by booting into rescue mode” in your post?? You mean to say that someone can setup a mechanism similar to two-factor authentication?? Can you explain how to do this in more detail?? Thanks.
I second what sud0er said: 2-factor authentication with Google Authenticator (just like LastPass) would be great!
@Thomas, caker was replying to MAq’s request to lockdown certain features per-user.
Nice, thanks guys!
Thank you caker et al. Much appreciated. Overdue in my opinion, but I’m happy it’s there now. Thanks again!
@Arlen, Yes, I understand that caker was replying to MAq’s request to lockdown certain features per-user, but I don’t understand how “booting with init=/bin/bash mode” implements a pseudo-two-factor authentication mechanism. Could someone explain this to me? I understand how to edit my GRUB configuration files, but I don’t see how this GRUB command (or is it a kernel boot parameter?) implements a pseudo-two-factor authentication mechanism. I really appreciate your help!!
@Thomas – Did you read MAq’s question? He wasn’t in any way referring to two-factor authentication — he was asking for a way to disable a user’s access to the “Reset Root Password” utility. caker was simply advising that if the user has access grants to the Linode, there would be alternate ways to resetting the root password without the use of this utility, such as booting the Linode into init=/bin/bash or using the Finnix Recovery distribution.
Thomas, Caker was referring to disabling the option to reset the Root Password from the admin console as per MAq’s post, nothing to do with two-factor auth.
And thanks for the new security implementation. Linode!
Sounds great guys, keep up the good work!
I would also like to see two-factor authentication using something like Google Authenticator, VIP Access by Versign or even SMS. These mobile apps are typically free apps for smart phone users. Heck, you could even add the functionality to the Linode mobile app and of course make the functionality optional like name.com and ebay.com do.
+1 2-factor auth.
Google Autenticator is even better.
Got to say I would of thought you had this already (even prior to the bitcoin disaster), I was really expecting something or worth, as others have mentioned Google Authenticator etc..
Two factor with Google Authenticator would be nice. SMS isn’t too good when have multiple countries to deal with as some don’t work, some have delays etc.
if you considered the 2-factor authentication and later implement it, please don’t make it obligatory. Some people do not like it including me.
This looks great!
I definitely agree with many others here: it would be superb to have two-factor authentication via Google Authenticator or something similar.
These new features were featured, with approval, on Bruce Schneier’s blog. =)
http://www.schneier.com/blog/archives/2012/04/password_securi.html
Is this enabled on all Linodes?
I don’t see the “Brute Force Protection Enabled” even after a couple intentional login errors, so just double-checking.
Haven’t you converted a brute force attack into a DOS attack? Can’t an attacker keep anyone from the same IP address from logging in by keeping the “single thread” queue filled up? It seems like captchas, though inconvenient, at least allow the users to log in.
Thanks for your efforts at keeping us secure – combined with a decent random 16-digit password and ditto username, I guess we will be OK… 🙂
I agree with many others above that two factor using Google Authenticator or similar would be very comforting.
@Ami Goldi “Our solution still lets legitimate users make attempts – albeit a little slower than usual.”
The whole idea is not to let malicious activity block normal users. A slight additional delay is almost unnoticeable by a legitimate user logging it, but cripples brute forcing.
You guys may already do this but why not setup an ip restricted allow list via /etc/hosts.allow. It would restrict brute force attempts outside of the clients pre-approved allowed ip range. It can supplement anything you already have in place as an extra layer of protection.
I’d like to +1 the idea of offering Google Authenticator. I use it for the admin login on my site and it appears that the APIs aren’t all that tricky.