Skip to main content
BlogLinodeLinode Manager Brute Force Protection

Linode Manager Brute Force Protection

brute

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)

  1. Author Photo

    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!

  2. Author Photo

    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.

  3. Author Photo

    Sweet, time to downgrade to a three letter password. =)

    Seriously though, thanks for watching out for your customer accounts!

  4. Author Photo

    Two factor auth with Yubikey would be nice.

  5. Author Photo

    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.

  6. Author Photo

    if you do 2-factor authentication, don’t make it obligatory. not everyone likes it

  7. Author Photo

    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.

  8. Author Photo

    Yeah, good point John, do not make two-factor authentication obligatory. Make it optional, and easy to turn on and off.

  9. Christopher Aker

    @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…

  10. Author Photo

    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.

  11. Author Photo

    I second what sud0er said: 2-factor authentication with Google Authenticator (just like LastPass) would be great!

  12. Author Photo

    @Thomas, caker was replying to MAq’s request to lockdown certain features per-user.

  13. Author Photo

    Nice, thanks guys!

  14. Author Photo

    Thank you caker et al. Much appreciated. Overdue in my opinion, but I’m happy it’s there now. Thanks again!

  15. Author Photo

    @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!!

  16. Author Photo

    @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.

  17. Author Photo

    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!

  18. Author Photo

    Sounds great guys, keep up the good work!

  19. Author Photo

    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.

  20. Author Photo

    +1 2-factor auth.

    Google Autenticator is even better.

  21. Author Photo

    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..

  22. Author Photo

    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.

  23. Author Photo

    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.

  24. Author Photo

    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.

  25. Author Photo

    These new features were featured, with approval, on Bruce Schneier’s blog. =)

    http://www.schneier.com/blog/archives/2012/04/password_securi.html

  26. Author Photo

    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.

  27. Author Photo

    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.

  28. Author Photo
    Mads Skovbjerg Paldam

    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.

  29. Author Photo

    @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.

  30. Author Photo

    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.

  31. Author Photo

    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.

Leave a Reply

Your email address will not be published. Required fields are marked *