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."
My preferred term is "free radicals" (Score:2, Interesting)
Looks like the malware ecosphere is learning... (Score:3, Interesting)
Re:Old news (Score:5, Interesting)
I've noticed a significantly increased number of brute-force attacks in the last week or so. They're also spacing the number of attempts per IP address out, however I'll get several attempts in a row for the same invalid username from several different IP addresses within seconds of each other. Then all of the addresses will back off for a couple of minutes, and then they'll retry with a new username.
It's gotten to the point where I have finally installed Denyhosts. Prior to this week, I got away with limiting the number of new connections to port 22 per IP address per minute, but with the backoff that they're doing now, that no longer works.
Denyhosts is fantastic, though. Since I last evaluated it, they've added the ability to sync with a centralized server, meaning that I can potentially block attackers before they even hit me. I wish that everyone would use it, now.
Very interesting; this bypasses my auto-banning fw (Score:4, Interesting)
I use Fail2ban [fail2ban.org] on all of my iptables-based SSH servers, as it eliminates the possibility of brute-force attacks from single IPs (fail2ban will ban any IP with five failed ssh logins in a ten minute period. The ban vanishes after ten minutes).
However, this new botnet attack distributes the attack over the IP-space and time. That bypasses fail2ban!
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. You run something that monitors your logs for failed logins (with a large scope for time, say ten failed attempts in a month). When an IP triggers it, you block that IP for a month and report it to the DNSBL. The DNSBL operates like Spamcop [spamcop.net], trying to verify the nature of the IP (and trying to address the issue), then adding it to the blocklist. Anything listed on a DNSBL gets permanently blocked after one failed authentication, and if your internal list grows too big, any positive IP gets blocked before the login attempt.
Portknocking (Score:3, Interesting)
Like the OP I was getting loads of hits on port 22. I just setup portknocking and it works a treat.. My other system that I use ssh on (its on the a sub domain of my main site) I just moved to a higher port and that has prevented it from getting the hits..
Normally I don't recommend Security through obscurity but in the case of automated attacks it is worth while. Just don't rely on it alone.
Re:SSH probes are nothing new (Score:5, Interesting)
Yeah, same here, except right now there's a rather humongous distributed bruteforce campaign going on. The 20-30 attempts I tend to see have skyrocketed to several thousand per day. It's actually pretty impressive - it's clearly a distributed sequential dictionary attack. Most of the IPs will only try once or twice, in an effort to avoid exactly the sort of reactive firewalling you mention.
Dec 1 11:17:57 shaunc sshd[35178]: Failed unknown for illegal user griffin from 196.211.53.74 port 20893 ssh2
Dec 1 11:18:17 shaunc sshd[35262]: Failed unknown for illegal user griffith from 92.50.243.18 port 40689 ssh2
Dec 1 11:18:30 shaunc sshd[35308]: Failed unknown for illegal user griffith from 82.207.103.151 port 60822 ssh2
Dec 1 11:18:33 shaunc sshd[35354]: Failed unknown for illegal user grizelda from 65.203.231.41 port 60602 ssh2
Many thousands of these, seconds apart, all day long. It got so bad that for the time being I've moved sshd to a different port.
Re:Easy was to stop 90% of SSH attacks (Score:3, Interesting)
Most of my attackers come from residential services all over the USA and UK, or don't resolve to an address at all. Those domains would be an exception.
Re:Old news (Score:3, Interesting)
I don't use the sync feature but do take advantage of the user black list. Grep the logs once a month and add the most popular names to the black list. I set it up to block the IP on the first attempt to login using any of the banned users.
Down to about 5-6 attempts a day now. This isn't even a static IP, can't imagine how bad it is for someone with one.
Re:Old news (Score:4, Interesting)
> Denyhosts is fantastic, though.
Indeed it is. Here are the RubyForge DenyHosts settings [blogs.com]. The comments on that post have a good suggestion about DENY_THRESHOLD_ROOT; makes sense to have that at 2 vs 1 to avoid blocking someone who accidentally hits the wrong box.
Re:Isn't that... (Score:5, Interesting)
Yeah these worms were attacking my home linux router as well, like a year ago or some.
Worms just tried to brute force ssh using "administrator" and such as username. I guess they were trying to get into badly (default) configured broadband routers. That's never going to work of course on my linux box but all the login attempts caused the hd to be busy *all* the time.
My sollution was to drop ssh packets by default in the firewall. Not that these attacks were likely to succeed but I didn't want my consumer grade hd to wear down in a year ;) I then created a small php script that'd insert a firewall rule to accept ssh connections from the IP it's called from. Finally I password protected the php script with .htaccess.
So now I can enable ssh to my machine wherever I am, while still blocking the rest of the internet.
This attack must balance reward and risk. (Score:2, Interesting)
This is not a game changing tactic. My institution has documented these style attacks on several past occaisions. There was some of this going around near the 4th of July. There was an extended bout this time last year. The attackers only use this tactic a few times a year. We have come to expect it on major holidays.
Economics can not be ignored. This attack must balance reward and risk.
In a normal SSH password guessing attack, the attacker risks a handful of computers. The committed computers do very noisy attacks and are probably lost to him.
In this SSH attack, the attacker risks hundreds of computers. This only pays off if the possibility of detection is greatly reduced or if the reward is greatly increased.
Fortunately, it is easy to detect this attack, and identify the attacking computers. You can use Cisco netflow data to characterize and identify the attackers. You can also identify the attackers with a SSH honeypot.
My institution takes the effort to document these attacks and report the attacking computers to their ISP's. It doesn't always work, but it works often enough to change the economics of attack. And each reported attacking machine is a possible pointer back to the hacker. Plus, it is the right thing to do.
Miles
Re:Old news (Score:2, Interesting)
Since you've gone that far, why not use the "side door" as the main door and get rid of ssh password access completely?
/etc/hosts.allow and have "ALL: ALL" in /etc/hosts.deny. That, plus key-only ssh access (no passwords allowed) seems to work rather well.
I use static IP addresses listed in
Re:Isn't that... (Score:5, Interesting)
You could also be interested in port knocking [wikipedia.org].
Turned out to be quite handy when I had that same issue with bots connecting to my ssh port all day long.
Re:Non Distributed Botnets (Score:3, Interesting)
Fun and interesting theory. I've noticed one of my really old XP installs is "busy (unresponsive or laggy) when it should be idle" for a while now.
I encapsulated it into a virtualbox vm on a linux machine, and created a firewall rule to deny and log all direct internet access requests.
Proxy access to a limit set of sites is available on squid, which also logs all traffic. It's never actually tried to go anywhere but vendor sites
for software updates, but I have my eye on it none-the-less. It could just be it's a really, really old install of XP.
The great thing about moving it off to virtualbox, and parking the image on ZFS is it'll far outlive the hardware it was originally installed upon.
In fact it already has which was the genesis of this project. It takes some effort to get XP moved to virtualbox (it really helps if you
have a record of your original MAC address), but once XP is reregistered with the new hardware profile it's effortless to move that VDI around
between vm server machines. As flash storage becomes cheaper and cheaper, I fully expect services to spring up which do all the hard
work of snapping off a copy of your old desktop and letting you run XP on XP, XP on Linux or Windows 7 in case you ever need it.
To tie it back to virri and worms it makes a nice forensics tool, particularly if you use ZFS snapshotting. You can always roll the FS back
external to the VM. Wouldn't be interesting to dust off an old XP VM in 5 years, apply the latest antivirus software and see what's been lurking?
I may have found their source for targets... (Score:4, Interesting)
Then it came back last month [slashdot.org] and I paid a little more attention to what I had been doing before. There was one significant thing that I did just before it (re)started:
I placed an ad on craigslist that had a link back to my own server for information on what I was selling.
We all know that of course the spamming botnets tend to troll craigslist looking for valid email addresses to add to their lists. I would say it appears that the botnets are now looking through craigslist for systems to attack as well.