Slashdot Mirror

← Back to Stories (view on slashdot.org)

The Slow Bruteforce Botnet(s) May Be Learning

Posted by kdawson on from the knock-who's-there-knock dept.

badger.foo writes "We've seen stories about the slow bruteforcers — we've discussed it here — and based on the data, my colleague Egil Möller was the first to suggest that since we know the attempts are coordinated, it is not too far-fetched to assume that the controlling system measures the rates of success for each of the chosen targets and allocates resources accordingly. (The probes of my systems have slowed in the last month.) If Egil's assumption is right, we are seeing the bad guys adapting. And they're avoiding OpenBSD machines." For fans of raw data, here are all the log entries (3MB) that badger.foo has collected since noticing the slow bruteforce attacks.

7 of 327 comments (clear)

  1. Solution: Public Key Auth by slifox · · Score: 5, Interesting

    The obvious solution is to use public/private key authentication and disallow password logins.

    This is much safer anyways, since your private key and your passphrase stays on your local machine always, so even if the server is compromised and the SSHd is bugged, no one will have immediate access to your login token.

    1. Re:Solution: Public Key Auth by FugitiveMind · · Score: 5, Interesting

      Since changing my SSH ports to something really high (above 50000), I have had exactly *zero* failed password attempts in the last 14 months.

      I know the plural of 'anecdote' is not 'data', but this is the case across *all* my servers.

    2. Re:Solution: Public Key Auth by HeronBlademaster · · Score: 5, Interesting

      I didn't change my ssh port to something that high, but I changed it to something above 1024, and the botnet attacks have stopped, so you can add my anecdote to yours...

  2. Botnet solution by Anonymous Coward · · Score: 5, Interesting

    Bots were knocking on my door to the point I was worry about performance degradation. I know there are many ways to defeat these but here was my solution.

    In hosts.deny
    -----------------
    sshd:ALL EXCEPT /var/www/html/allow.txt
    -----------------

    Create a simple cgi-script (password protected and accessed via secret random url) that writes your browser IP address to the allow.txt file and all those nasty botnets and go to hell.

  3. Economics by jimpop · · Score: 5, Interesting

    Don't forget about the economies surrounding botnets. There are two sides, those that profit from the botnets (the operators), and those that profit fighting the botnets (the fighters). Additionally, there are those that profit from providing botnet remedial "solutions" whilst not being in either of the primary (operator or fighter) categories. If botnets ceased to exist, there would be a *lot* more lost on the fighter and solution side than on the operator side. So... like SPAM, this raises the question of just who actually benefits the most from botnet existing.

    1. Re:Economics by Opportunist · · Score: 5, Interesting

      As someone being in the latter group (to avoid confusion, the ones fighting them), yes, we make some money fighting that crap. Looking at the money being made on the other side, some are already wondering why we stay here.

      We stay on this side because we (well, most of us) hate botnets. Most people I met at various conventions and meets are somewhere between zealous, fanatic or outright crazy, but generally see the money as some sort of pleasant side effect.

      Believe me one thing: We know we cannot fight it, we know it's almost impossible to track them down and we know how it works. If we were in it for the money, we'd switch sides before you're done reinstalling your system. There's about ten times the money to be gained on the dark side.

      Conservatively estimating, that is.

      If spam and botnets ceased to exist overnight, we'd gladly return to more interesting and maybe also more profitable professions. Most of us are network experts. Some know more about the way Windows works on the "inside" than most people at MS. And if everything fails, we could actually maybe even create a copy protection system that is hard enough to break that nobody would willingly do it (after all, we spend a good deal of our time with disassembly). Do you really think that any of the (good) spam and botnet fighters would have a hard time finding a "honest" job that maybe even paid better than this?

      I could enjoy having a life again, instead of this sorta permanent on-call duty. Again, no christmas for me, because yes, this is one of the hottest times of the year (many people at home, many new computers needing infections, so many new opportunities for botherders...). I would also prefer to create something, like some new software to make people happy or more productive, instead of poking at malware and trying to find a sensible way to detect it. It's not really good for your ego if your product is seen as the necessary evil that steals valuable computer time instead of something that people actually want to have.

      Thanks for hearing out the rant. Now we're back to your scheduled program.

      --
      We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
  4. This is not a game changing tactic. by dweller_below · · Score: 5, Interesting

    I do computer and network security for a university.

    This distributed SSH password guessing is not a new tactic. We have seen and tracked this tactic off and on for over a year.

    If this tactic was a game changer, we would have seen it ramp up before now. It would occur all the time. But it doesn't. It only seems to occur during holidays.

    At it's heart, this tactic is not any more effective than non-distributed password guessing. Either way, the attacker has to enumerate the same number of guesses before finding a hit. If a machine is vulnerable, it will be successfully attacked by either approach to password guessing. If it is not vulnerable, neither approach will work.

    Modern hacking is a economic activity. It must balance risk and reward. This attack doesn't offer any more reward than conventional password guessing. It's main feature is to try to change the risk side of the equation.

    Conventional SSH password guessing is noisy. One machine will portscan for TCP/22. Then it rapidly guesses passwords against everything that responds. That one machine is usually lost to the attacker. Automated defense systems block it. Also, defenders report it to the owning ISP. The only way this works for the attacker is if he can harvest more that he loses.

    The distributed guessing attack is also noisy, but in a different way. Currently, we see the attacker start by sacrificing 1 computer to do a TCP/22 portscan. At this point, he has already risked as much as a conventional password guessing attack. Then he feeds the results to a bunch of bots. Each bot then takes turns guessing passwords. Each bot guesses 1 password at a time. However, each bot guesses against multiple SSH servers at the same time.

    This attack is inherently more risky that conventional password guessing. The attacker exposes many of his computers. If we can detect and respond, this attack is not as cost effective as conventional password guessing.

    It is easy for my university to detect and respond to these attacks. We detect it in three different ways.
    1) Each attacker has a distinctive network behavior pattern. We can automate detection by looking at aggregate Cisco netflow data.
    2) It is trivial to pick off this attack using a SSH honeypot.
    3) We use a network visualization tool to watch aggregate SSH activity. This password guessing is obvious on our visualization tool.

    Once we have detected the attackers, we respond to them in the normal way. We block them. We inform our peer institutions and the authorities. We inform the owning ISP.

    The main difference in this situation is that detection and response is easy if you have access to aggregate traffic or multiple SSH servers. It is difficult if you only manage 1 SSH server.

    I don't expect this form of attack to last much longer. I am sure that everybody else is adapting. Once the defenders adapt, this tactic is too expensive to be used.

    Miles