Slashdot Log In
Distributed, Low-Intensity Botnets
Posted by
kdawson
on Tue Dec 02, 2008 05:00 PM
from the slow-probe dept.
from the slow-probe dept.
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."
Related Stories
[+]
The Slow Bruteforce Botnet(s) May Be Learning 327 comments
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.
[+]
The Low-Intensity, Brute-Force Zombies Are Back 203 comments
Peter N. M. Hansteen writes "In real life, zombies feed off both weak minds and the weak passwords they choose. When the distributed brute-force attempts stopped abruptly after a couple of months of futile pounding on ssh servers, most of us thought they had seen sense and given up. Now, it seems that they have not; they are back. 'This can only mean that there were enough successful attempts at guessing people's weak passwords in the last round that our unknown perpetrators found it worthwhile to start another round. For all I know they may have been at it all along, probing other parts of the Internet ...' The article has some analysis and links to fresh log data."
[+]
Linux: Sloppy Linux Admins Enable Slow Brute-Force Attacks 391 comments
badger.foo passes on the report of Peter N. M. Hansteen that a third round of low-intensity, distributed brute-force attacks is now in progress — we earlier discussed the first and second rounds — and that sloppy admin practice on Linux systems is the main enabler. As before, the article links to log data (this time 770 apparently already compromised Linux hosts are involved), and further references. "The fact that your rig runs Linux does not mean you're home free. You need to keep paying attention. When your spam washer has been hijacked and tries to break into other people's systems, you urgently need to get your act together, right now."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
First Post (Score:3, Funny)
And I didn't even need to use a botnet!
Isn't that... (Score:2)
Isn't that what already do? Distributed, rather than monolithic, spamming?
Anyway, it's not that surprising...
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.
Parent
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.
Parent
Fleas on a dog (Score:5, Insightful)
If the bad guys can siphon off what they need without being more than a mild annoyance, they can operate without fear of retribution.
Nothing abnormal about SSH probes... (Score:5, Insightful)
I've seen SSH probes on my one-man-and-a-dog site for aeons. I don't think there's anything out of the ordinary, the scum has been trying (and failing) to get in for as long as I've had something listening on the 'net - and that is a long time. There's also nothing new in them trying to root FLOSS-sites as those sites - with their fixed IP addresses, good uptime, high reliability and abundance of crappy PHP-scripts to open the doors - make for good C&C hosts for their flock.
So all I read from this flog is that a grumpy BSD user should probably check his logs more often. This is nothing new.
Re: (Score:2)
Yeah, I had flashbacks to 2000. I remember setting something up (I think it was portsentry) that would put ip's in the hosts.deny file after too many bad logins, or was it hitting too many different ports on my PC? (probably both)
Re: (Score:2)
For real. I had my single-page-o'-html site up for a little more than a week with inbound 22/80 open before getting ssh probes. Heck, even when I had my dyndns domain, it was getting probed.
Nothing new at all.
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:Nothing abnormal about SSH probes... (Score:4, Insightful)
That's a DDoS, and would kick your one-man-and-a-dog site off the net. For a while, at least. And there would be nothing you could do about it.
How is this new? Botnets have had this capability for a looong time.
Parent
Re:Nothing abnormal about SSH probes... (Score:4, Insightful)
That's a DDoS, and would kick your one-man-and-a-dog site off the net. For a while, at least. And there would be nothing you could do about it.
The parasite doesn't want to kill the host, because it would die too. This thing will tick away, slowly getting bigger.
Parent
My preferred term is "free radicals" (Score:2, Interesting)
Looks like the malware ecosphere is learning... (Score:3, Interesting)
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.
Re: (Score:2)
I'm in pretty much the same boat with my home ssh server, except I would get 20-30 attempts an hour. Occasionally I would sift through some of the attempts just to see what they were trying to guess as usernames. Root and admin were usual attempts, but I would also see oracle, sa, mysql, etc as well as just random first names like John, Mary, Bob, etc. I eventually grew tired of it just filling up my log files so I switched to a non-standard port and haven't seen an attempt since.
Re: (Score:2)
I eventually grew tired of it just filling up my log files so I switched to a non-standard port and haven't seen an attempt since.
I keep ssh open on the standard port because I block offending hosts in pf. It is much easier to detect attacks on ssh, but I get attacked on other ports as well, such as pop3 and smtp.
I would rather know who the enemy is, than be completely blind.
If anybody is interested I would be happy to post my current list of blocked hosts.
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.
Parent
Re: (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 p
Nothing new, move along (Score:5, Insightful)
Okay, how is this different than previous patterns of hacking activity, other than the fact that they're aquiring compromised machines via a bot net? It's not! These "security researchers" remind me sometimes of my pothead friends. You can always tell someone who's new to smoking weed because they constantly ask the question, "but have you done it on WEED?" It's like somehow the idea that these people are using a botnet makes it all strange and new again. No, fail!
Re:Nothing new, move along (Score:5, Insightful)
Okay, how is this different than previous patterns of hacking activity, other than the fact that they're aquiring compromised machines via a bot net?
You're sort of missing the point, I think, in that what's different about this pattern of activity is precisely the fact that it's being done with a botnet.
For one thing, there's a new level sophistication, primarily in that this bruteforce campaign is not the least bit random. I'm being hit by thousands of distinct attackers, yet the progression of usernames being attempted is undeniably alphabetical. Occasionally a particular username is attempted more than once, but it's typically sequential. One attempt per username with the attacking hosts only making one attempt every few hours.
The level of coordination required for this sort of attack is unprecedented. Across thousands of bots, each one at any given moment is able to determine:
In the past, brute force SSH attacks have always been obvious. Typical hit and runs. One host will spew hundreds or thousands of attempts at a target, typically in quick succession, typically focusing on system accounts, and typically trying a shitload of passwords against each account. Firewalls and IDS deployments far and wide will now easily detect (and often block) these attacks immediately because they're so easy to recognize.
This attack is very different. It's not targeting system accounts, it's hoping to get lucky against a vast list of potential userland lognames. It's only trying once or maybe twice per account. And it's distributing these attempts, round-robin style, across an impressive number of sources, with enough logic so that bot B will not attack host H unless all other bots in the network have sequentially exhausted their "token" attempt on host H.
What we're seeing is flying under the radar of a shit-ton of IDS/firewall implementations, and is harder to fight.
I would love to get my hands on the C&C database being used to coordinate all of this. Much as I hate to admit it, the architecture of this attack is unique and innovative, and I'd like to see what makes it tick.
Parent
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...
Re: (Score:2)
Denyhosts does the same thing, but has a global synchronization method. If one person using the sync feature bans someone, they all do.
It only works for ssh though. fail2ban is flexible enough to monitor anything and do anything, in response to any pattern. Pretty damned powerful really.
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.
Parent
Re: (Score:2)
There should be a memory efficient alternative, maybe I'll have to write that.
Mine uses 53 lines of ksh.
Re: (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 f
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.
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.
Parent
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 da
Re: (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 secur
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.
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: (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.
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.
Re: (Score:3, Insightful)
Re:Non Distributed Botnets (Score:5, Insightful)
Parent
Re:Non Distributed Botnets (Score:4, Insightful)
Isn't slashdot basically a big overgrown blog?
Parent
Re:Non Distributed Botnets (Score:5, Insightful)
you can read slashdot, but not a blog?
This isn't surprising at all, even less so if he works in IT. Corporate management issues a new policy: "our computing resources are not to be used for [insert a huge list of time-wasting things employees have been caught doing in the office]." But keep in mind who's eventually tasked with implementing the policy. Given such an edict, network admins everywhere will happily block the most prolific productivity killers... Except for their own.
You'll find plenty of enterprises where MySpace, Facebook, Blogger, LiveJournal and friends all resolve to nowhere, yet geekier time pits like Slashdot and TechCrunch are wide open.
Parent
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.
Parent
Re: (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 b
Re: (Score:2)
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.
Parent
Re: (Score:2)
There is a danger though. What stops someone from spoofing a given address with the intention of putting it on 'the list'? Now all your systems have locked you out... what do you do?
(that said, I use denyhosts with it's sync feature)
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.
Parent
Re: (Score:2)
Re: (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
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.
Parent
Re:Easy was to stop 90% of SSH attacks (Score:5, Funny)
Parent
Re: (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: (Score:3, Informative)
.ssh/config
Host hostname
Port yourport
then you can ssh to hostname and not have to type the port everytime.
Re: (Score:3, Insightful)
So we are still user password-based SSH authentication?
The problem is that in any sort of working environment, where you have a very heterogeneous user base, it's really really hard to enforce anything else.
Users - even the most basic of users - can be trained to enter a username and a password. They do it on Hotmail, they do it on Google, they do it on MySpace, they're used to the idea that when they want to login somewhere, they have to enter a username and a password. "That's how the internet works." So when their job functions require that they PuTTY into a