Forgot your password?
typodupeerror
Security IT

The Optimum Attack Rate For SSH Bruteforce? Once Every Ten Seconds 167

Posted by Unknown Lamer
from the and-that's-why-you-use-denyhosts dept.
badger.foo writes "Remember the glacially slow Hail Mary Cloud SSH bruteforcers? They're doing speedup tweaks and are preparing a comeback, some preliminary data reported by Peter Hansteen appear to indicate. The optimum rate of connections seems to be 1 per ten seconds, smack in the middle of the 'probably human' interval."
This discussion has been archived. No new comments can be posted.

The Optimum Attack Rate For SSH Bruteforce? Once Every Ten Seconds

Comments Filter:
  • by the eric conspiracy (20178) on Friday April 06, 2012 @02:27PM (#39600105)

    Anyone see these guys on a port other than 22?

  • Key AND Password (Score:5, Interesting)

    by XanC (644172) on Friday April 06, 2012 @02:29PM (#39600125)

    So what I've never understood is why it's not possible (as far as I know) for a server to require BOTH a key AND a password. Sure, I can put a password on my key, but that isn't the same at all. Is this possible yet?

  • by damn_registrars (1103043) <damn.registrars@gmail.com> on Friday April 06, 2012 @02:37PM (#39600219) Homepage Journal

    So unless you're allowing usernames such as "root" or "admin" or "administrator" AND using dictionary passwords wouldn't this fail? And be obvious in the logs?

    Yes, it would be obvious in the logs. However, most of the common hacks are now scripted and distributed. They'll use a dictionary attack that is spread over some number (dozens or more) of distinct botnet systems, making it very inconvenient for you the admin to try to block all those addresses.

    Although of course as you point out, it should fail if they are going for root or equivalent. That said from my experience the botnets usually seem to do a white pages type list of common usernames and then try either blank or extremely common user names to try to get in by. So you may also want to ensure that if you have users who use very common (English) first names as their login names, they are using strong passwords.

    Thankfully, ssh generally returns the same password prompt for a valid username as it does for a nonexistent one, and the same wrong password response regardless of whether or not the username exists, so at least your system won't be giving them useful information on which usernames are worth trying again with other passwords.

  • by ledow (319597) on Friday April 06, 2012 @02:41PM (#39600279) Homepage

    I have a portknocking setup. All your packets bounce when you touch my port 22 until you have touched a "magic sequence" of port numbers first. That sequence can be cryptographically strong, time-dependent, etc. but even a simple one-port knock is enough to stop all this random SSH spam and has been for years.

    And if you do "get lucky" and find the right ports and then detect that port 22 is open and then start a brute-force on that? Public-key-only authentication and no root logins allowed.

    Impact on me? Another line in a shell script that I use to connect (and hell, even Android has free port-knocking apps, not to mention them being standard-enough to be in Ubuntu/Debian). Impact on server? Greatly reduced number of fake connections bouncing off iptables and a tiny little daemon that does nothing but listen on the ports I need (and can ONLY open the SSH port even if compromised). Impact on brute-forcers? They might as well give up and go home.

    Even those remote companies that we do allow to port-forward direct to their device on my work network (e.g. telecoms providers, etc.) understand it and "knock" before they come in (which tells us exactly when they are about to log in), while everyone else in the world sees closed ports.

    Why everyone doesn't use it, I have no idea. Even our VPN users have an automated script that just knocks to open the VPN ports (and only the VPN ports) before they connect. Transparent to them, invisible to everyone else, no different if "compromised".

  • by Anonymous Coward on Friday April 06, 2012 @02:45PM (#39600335)

    Why go through all that just to leave your SSH server on port 22?

  • by sexconker (1179573) on Friday April 06, 2012 @03:13PM (#39600691)

    RSA key/pair is something you have... you still need something you are, and something you know... Once someone has your key, it's no more secure than your password. A trojan can read local files, just as easily, if not more so than snoop for a password.

    When you send bits out, everything in those bits is "something you know".

    You don't need to have the keyfob, you just need to know what it will output at any given time, or what a prior output was (as long as you use it within the time window for which it is valid - typically 30 seconds to 2 minutes). Yes, it's mathematically hard to get the key by brute forcing, but it's not impossible. When you log in with one of those, you're not proving that you have the thing, you're proving that you know what it output at a given time.

    Imagine if PS4 games had built in RSA shits right onto game discs. (Or the Vita game cards if you can't imagine a thing battery, cpu, and display on a disc.)
    Touch an area on the surface of the game disc (or card) and get a password on a little display. You have to put that password in within X time to access the game. This isn't secure because even if Bob holds onto the disc physically, Alica can call him up and ask him to read the code.

    Sony wants the disc to be in Bob's physical possession (and no one else's) at any given time, but they cannot rely on this type of security to ensure that. For all they know Bob is visiting Alice and brought his new game over.

  • Re:Key AND Password (Score:4, Interesting)

    by allo (1728082) on Friday April 06, 2012 @03:14PM (#39600707)

    yeah, or i once had a sshd with https://en.wikipedia.org/wiki/OPIE_Authentication_System [wikipedia.org] running. Nice thing, you generate a bunch of passwords and print it. Then you can login from everywhere without looking out for keyloggers.

  • by multimediavt (965608) on Friday April 06, 2012 @04:03PM (#39601253)
    I made it just a different port on my router at home; still points to port 22 on the internal address forward. That way I can just turn sshd on (after configuring max tries to '3') and not worry about port fiddling on the machine. Works. Haven't seen many attempts at it since I did that years ago.
  • Re:Key AND Password (Score:4, Interesting)

    by XanC (644172) on Friday April 06, 2012 @04:13PM (#39601359)

    There's no way for a server admin to require a passworded key for login.

  • by khasim (1285) <brandioch.conner@gmail.com> on Friday April 06, 2012 @05:01PM (#39601879)

    Do you have your system set up so that email names are not user names?

    At home? Yes.

    I think I seen where you're going with that and I don't think you understand. Collecting email login names is easy.

    But being able to login to an outward-facing server (email or ftp or ssh or whatever) should be limited to a certain amount of failed logins (no matter from which IP address) per time period.

    The crackers would have to go through an ADDITIONAL step to try to match email login names with ssh login names and an ADDITIONAL ADDITIONAL step to match that name to a different type of server (such as ssh).

    Let me see if I can illustrate this.

    1. Attacking ssh on server A.B.C.D with username aaron - if there's any chance that the cracker can do it then the sysadmin failed. Even more so with "root" or "admin" or such.

    2. Collecting username aaron.aaronson via email spammer and then trying to attack ssh on server mail.example.com - more work for the cracker than scenario #1 but still the same as #1. If there is any chance that the cracker can succeed then the sysadmin has failed. SSH should only be allowed on the mail server from the inside interface.

    3. Collecting username aaron.aaronson via email spammer and then trying to attack ssh on servers in the block A.B.C.D through A.B.C.Z (and one of those is your SSH server). And the cracker is using multiple machines to make multiple attempts (one per machine) within time period X. - Again, if it works then the sysadmin has failed. Too many attempts in time period X should lock out the account for a set number of minutes. No matter how many IP addresses are involved.
    -continued-
    And that depends upon aaron.aaronson being a LEGITIMATE USERNAME ON THAT SYSTEM. Once the sysadmin sees that attack in the logs then the logins to that should be changed (ssh.aaron.aaronson or such) to break that attack if they were not already such. Or change them AGAIN (aaron.aaronson.ssh) and be aware that something leaked somewhere.

    4. See #3 except the logins are from multiple machines but only 1 login attempt in time period X so it never triggers the account lockout. Again, change the login names (ssh.aaron.aaronson) to break that attack (and did they leak?).

    In summary, getting your system cracked via SSH means that your sysadmin failed so many times.

Real Users hate Real Programmers.

Working...