×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Distributed, Low-Intensity Botnets

kdawson posted more than 5 years ago | from the slow-probe dept.

Security 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."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

167 comments

First Post (5, Funny)

Luke727 (547923) | more than 5 years ago | (#25966827)

And I didn't even need to use a botnet!

Re:First Post (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#25966905)

A couple weeks ago, while browsing around the library downtown, I had to take a piss. As I entered the john, Barack Obama -- the messiah himself -- came out of one of the booths. I stood at the urinal looking at him out of the corner of my eye as he washed his hands. He didn't once look at me. He was busy and in any case I was sure the secret service wouldn't even let me shake his hand.

As soon as he left I darted into the booth he'd vacated, hoping there might be a lingering smell of shit and even a seat still warm from his sturdy ass. I found not only the smell but the shit itself. He'd forgotten to flush. And what a treasure he had left behind. Three or four beautiful specimens floated in the bowl. It apparently had been a fairly dry, constipated shit, for all were fat, stiff, and ruggedly textured. The real prize was a great feast of turd -- a nine inch gastrointestinal triumph as thick as his cock -- or at least as I imagined it!

I knelt before the bowl, inhaling the rich brown fragrance and wondered if I should obey the impulse building up inside me. I'd always been a liberal democrat and had been on the Obama train since last year. Of course I'd had fantasies of meeting him, sucking his cock and balls, not to mention sucking his asshole clean, but I never imagined I would have the chance. Now, here I was, confronted with the most beautiful five-pound turd I'd ever feasted my eyes on, a sausage fit to star in any fantasy and one I knew to have been hatched from the asshole of Barack Obama, the chosen one.

Why not? I plucked it from the bowl, holding it with both hands to keep it from breaking. I lifted it to my nose. It smelled like rich, ripe limburger (horrid, but thrilling), yet had the consistency of cheddar. What is cheese anyway but milk turning to shit without the benefit of a digestive tract?

I gave it a lick and found that it tasted better then it smelled.

I hesitated no longer. I shoved the fucking thing as far into my mouth as I could get it and sucked on it like a big half nigger cock, beating my meat like a madman. I wanted to completely engulf it and bit off a large chunk, flooding my mouth with the intense, bittersweet flavor. To my delight I found that while the water in the bowl had chilled the outside of the turd, it was still warm inside. As I chewed I discovered that it was filled with hard little bits of something I soon identified as peanuts. He hadn't chewed them carefully and they'd passed through his body virtually unchanged. I ate it greedily, sending lump after peanutty lump sliding scratchily down my throat. My only regret was that Barack Obama wasn't there to see my loyalty and wash it down with his piss.

I soon reached a terrific climax. I caught my cum in the cupped palm of my hand and drank it down. Believe me, there is no more delightful combination of flavors than the hot sweetness of cum with the rich bitterness of shit. It's even better than listening to an Obama speech!

Afterwards I was sorry that I hadn't made it last longer. But then I realized that I still had a lot of fun in store for me. There was still a clutch of virile turds left in the bowl. I tenderly fished them out, rolled them into my handkerchief, and stashed them in my briefcase. In the week to come I found all kinds of ways to eat the shit without bolting it right down. Once eaten it's gone forever unless you want to filch it third hand out of your own asshole. Not an unreasonable recourse in moments of desperation or simple boredom.

I stored the turds in the refrigerator when I was not using them but within a week they were all gone. The last one I held in my mouth without chewing, letting it slowly dissolve. I had liquid shit trickling down my throat for nearly four hours. I must have had six orgasms in the process.

I often think of Barack Obama dropping solid gold out of his sweet, pink asshole every day, never knowing what joy it could, and at least once did, bring to a grateful democrat.

Non Distributed Botnets (1)

LeadLine (1278328) | more than 5 years ago | (#25966845)

"the future of botnets, and it is distributed"

Were there ever any botnets that weren't distributed?

Re:Non Distributed Botnets (2, Insightful)

internerdj (1319281) | more than 5 years ago | (#25967069)

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.

Re:Non Distributed Botnets (0)

Anonymous Coward | more than 5 years ago | (#25967119)

I can't RTFA at work cause it is a blog

Can you read this [wikipedia.org] at work?

Re:Non Distributed Botnets (4, Insightful)

internerdj (1319281) | more than 5 years ago | (#25967249)

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.

Re:Non Distributed Botnets (3, Insightful)

flappinbooger (574405) | more than 5 years ago | (#25968219)

you can read slashdot, but not a blog?

Isn't slashdot basically a big overgrown blog?

Re:Non Distributed Botnets (4, Insightful)

ShaunC (203807) | more than 5 years ago | (#25969879)

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.

Re:Non Distributed Botnets (0)

Anonymous Coward | more than 5 years ago | (#25970433)

Yeah, but keep in mind it is the IT type folks that write and run the software that blocks the interwebs? Coincidence? I think not!

Re:Non Distributed Botnets (0)

Anonymous Coward | more than 5 years ago | (#25968321)

Distributed nets can also be centralized. Sorry, your guess is wrong.

Isn't that... (1)

mewshi_nya (1394329) | more than 5 years ago | (#25966887)

Isn't that what already do? Distributed, rather than monolithic, spamming?

Anyway, it's not that surprising...

Re:Isn't that... (2, Insightful)

davester666 (731373) | more than 5 years ago | (#25968285)

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.

Re:Isn't that... (4, Interesting)

Duckie01 (10586) | more than 5 years ago | (#25968895)

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.

Re:Isn't that... (1)

davester666 (731373) | more than 5 years ago | (#25969131)

Just changing the port ssh uses completely resolved the problem for me. It was just a stupid scripted attack, trying a couple of passwords for a couple of names, on port 22. Once the port was changed, no more attempts were logged.

Old news (0)

Anonymous Coward | more than 5 years ago | (#25966929)

I get 500-1000 failed ssh attempts a day on any server I open ssh which is why I restrict to only a few IP addresses. I'd get this many attacks 4 and 5 years ago and there is no real reason to attack us.

Re:Old news (5, Interesting)

Sancho (17056) | more than 5 years ago | (#25967257)

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.

Re:Old news (1)

X0563511 (793323) | more than 5 years ago | (#25967533)

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 (3, Informative)

Sancho (17056) | more than 5 years ago | (#25967687)

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:Old news (2, Interesting)

innocent_white_lamb (151825) | more than 5 years ago | (#25969173)

Since you've gone that far, why not use the "side door" as the main door and get rid of ssh password access completely?
 
I use static IP addresses listed in /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.

Re:Old news (1)

Sancho (17056) | more than 5 years ago | (#25969243)

Because I have users to think of, and most users can't be bothered to keep and carry around SSH keys. Hell, I can't either, so if I need to log in from an unfamiliar computer, I tend to use password-based authentication.

Re:Old news (1)

MichaelSmith (789609) | more than 5 years ago | (#25967543)

Same here. I wrote a script which gets called from syslogd. It gets lines from authlog and parses certain lines for the IP address. Each host gets one chance to fail, then goes into a file which pf treats as a list of IP addresses to block. I allow 10000 hosts in the pre-block list and 1000 in the blocked list.

Re:Old news (2, Interesting)

Sen.NullProcPntr (855073) | more than 5 years ago | (#25968297)

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.

Re:Old news (1)

Sancho (17056) | more than 5 years ago | (#25969047)

Pretty good idea on the user black list. You could probably even do some interesting things to detect common misspellings of your usernames and blacklist anyone using anything else after a single attempt.

Re:Old news (3, Interesting)

tcopeland (32225) | more than 5 years ago | (#25968303)

> 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.

Fail2Ban (1)

maz2331 (1104901) | more than 5 years ago | (#25969423)

I run fail2ban on every Internet-facing machine that I set up and/or manage. The policy I use is that 5 failed logins results in an iptables ban from any access to the box for 24 hours.

Fleas on a dog (4, Insightful)

try_anything (880404) | more than 5 years ago | (#25966949)

If the bad guys can siphon off what they need without being more than a mild annoyance, they can operate without fear of retribution.

Re:Fleas on a dog (1)

Nutria (679911) | more than 5 years ago | (#25967709)

Fleas on a dog ... without fear of retribution

Flea deterrence is a big business (at least in the USA).

Nothing abnormal about SSH probes... (5, Insightful)

knarf (34928) | more than 5 years ago | (#25967035)

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:Nothing abnormal about SSH probes... (1)

QuantumRiff (120817) | more than 5 years ago | (#25967161)

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:Nothing abnormal about SSH probes... (1)

basscomm (122302) | more than 5 years ago | (#25967179)

Seconded. My own low traffic website [crummysocks.com], gets hundreds, sometimes thousands of failed SSH logins every day, and has for nearly as long as it's been in existence. I usually end up just turning off SSH so I don't have gigantic logs to sift through every day.

Re:Nothing abnormal about SSH probes... (1, Insightful)

kithrup (778358) | more than 5 years ago | (#25967199)

The difference is a big one, and it should terrify you.

Instead of a single host doing a few dozen or hundred ssh attempts -- which can be easily blocked, even automatedly -- this is a bunch of different hosts doing a coordinated attack. Low-key for the moment, sure -- each host has attempted to only do one or two probes at a time. But still the coordination is undeniable.

And the part that should terrify you: if the coordinator, instead of having each host do a couple of probes in succession, chose instead to have all of the probes come in at once. From random hosts in the botnet.

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.

Re:Nothing abnormal about SSH probes... (3, Insightful)

X0563511 (793323) | more than 5 years ago | (#25967563)

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.

Re:Nothing abnormal about SSH probes... (3, Insightful)

MichaelSmith (789609) | more than 5 years ago | (#25967589)

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.

Re:Nothing abnormal about SSH probes... (0)

Anonymous Coward | more than 5 years ago | (#25968155)

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.

that's how successful parasites work in the real world: eg tuberculose which affects you very slowly, as opposite to ebola that kills you faster than you can spread it around ...

Re:Nothing abnormal about SSH probes... (1, Insightful)

Anonymous Coward | more than 5 years ago | (#25967705)

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.

That has existed pretty much since the popularity of the web, and there are ways around it, they are very expensive, but this changes nothing.

What we need is, against the better judgement of the white hats, someone to release a patch to permanently patch and firewall these botnets from the face of the earth. Yeah it'd break stuff, too bad.

Re:Nothing abnormal about SSH probes... (1)

Seakip18 (1106315) | more than 5 years ago | (#25967763)

Good point, but if he's got control over what traffic is routed his way, he should be able to handle low amounts.

It's folks running websites from home that have the most to worry about. Even then, their ISP should have a cut-off if someone tries to flood the host with incoming connections. Keyword there is *should*....and you're right that we should worry when that starts happening and ISPs don't move against it. I mean, if someone wanted, they could easily knock my SSH server out and kill my download/upload speeds.

Re:Nothing abnormal about SSH probes... (1)

jimmyhat3939 (931746) | more than 5 years ago | (#25968193)

Here's how I solve this problem. I use iptables to block inbound ssh except for from one highly secure IP address. Then, I have a simple perl daemon set up which requires you to attempt to connect to one port, then another, and then it will open ssh to new connections for the next 60 seconds. The daemon doesn't respond to those connection requests. Just notes them.

The result? Someone has to guess the two "knock knock" ports, which is basically impossible. I don't get zillions of logon attempts, because my site appears to be a black hole.

And, if the daemon dies, I just access the server from the aforementioned very secure server.

Re:Nothing abnormal about SSH probes... (1)

POTSandPANS (781918) | more than 5 years ago | (#25968261)

On most of my systems, I only allow a few IP ranges access to port 22. It's not a perfect solution for all situations, but its pretty easy to set up and clears up the problem quite nicely. I also don't allow root to login through ssh, so somebody will have to guess a login/password combo, then they can work on guessing the su password.

Re:Nothing abnormal about SSH probes... (1)

Johnny Mnemonic (176043) | more than 5 years ago | (#25968573)


And there would be nothing you could do about it.
Change the port that ssh listens on? Only listen for ssh on the intranet, and nothing external?

Re:Nothing abnormal about SSH probes... (1)

Jeremi (14640) | more than 5 years ago | (#25969129)

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.

Well, not nothing... you could always keep copies of your web site available on various hosts around the Internet, and when one of them gets DDOS'd, start serving from another one.

But how to set up a large number of mirroring servers for free? Your best bet is to use a botnet to do it...

Re:Nothing abnormal about SSH probes... (1)

Seakip18 (1106315) | more than 5 years ago | (#25967281)

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.

Re:Nothing abnormal about SSH probes... (1)

MartinSchou (1360093) | more than 5 years ago | (#25967293)

my one-man-and-a-dog site

Is it me or does that sound somewhat similar to "two girls and a cup"?

Re:Nothing abnormal about SSH probes... (1)

Dishevel (1105119) | more than 5 years ago | (#25967465)

my one-man-and-a-dog site

Is it me or does that sound somewhat similar to "two girls and a cup"?

my one-man-and-a-dog site

Is it me or does that sound somewhat similar to "two girls and a cup"?

Not similar at all. Doggie poo is way different than people poo.

Re:Nothing abnormal about SSH probes... (1)

tubapro12 (896596) | more than 5 years ago | (#25968065)

Precisely my thoughts on the matter. The handful of low bandwidth sites I've worked with that had SSH would have endless logs of failed attempts. And it seemed a large percentage of which even came from within the data center that hosted the servers (probably a sign we should've changed hosts, but that wasn't my call).

Run ssh on a non standard port (2, Informative)

kbahey (102895) | more than 5 years ago | (#25969179)

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... (1)

daybot (911557) | more than 5 years ago | (#25970051)

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.

Ditto. I saw a suspiciously high number of genuine accounts being attempted. I drew the conclusion that this was coming from bulk email lists.

1. Buy bulk email list, containing fred@foo.com and others.
2. SSH to foo.com as fred - try some common passwords. Maybe try fred@ftp.foo.com for good measure.
3. Profit!

My preferred term is "free radicals" (2, Interesting)

dword ZZork (1421463) | more than 5 years ago | (#25967099)

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?

Looks like the malware ecosphere is learning... (2, Interesting)

idontgno (624372) | more than 5 years ago | (#25967109)

the difference between parasitism [wikipedia.org] and commensal symbiosis [wikipedia.org]. 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?

SSH probes are nothing new (2, Informative)

coulbc (149394) | more than 5 years ago | (#25967127)

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:SSH probes are nothing new (1)

cdrudge (68377) | more than 5 years ago | (#25967411)

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:SSH probes are nothing new (1)

MichaelSmith (789609) | more than 5 years ago | (#25967649)

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 (5, Interesting)

ShaunC (203807) | more than 5 years ago | (#25967561)

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:SSH probes are nothing new (2, Informative)

DaveAtFraud (460127) | more than 5 years ago | (#25967825)

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

Nothing new, move along (4, Insightful)

girlintraining (1395911) | more than 5 years ago | (#25967171)

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 (0, Troll)

sexconker (1179573) | more than 5 years ago | (#25967273)

Security researchers?
Surely you mean insecurity researchers.

(And yes, they're useless.)

Re:Nothing new, move along (1)

dword ZZork (1421463) | more than 5 years ago | (#25967431)

I think the gravity of this post is the fact of the novel occurrence, that is to say, that a new technology is being used to do a fairly mundane thing. Though the thing is mundane, the means raise some questions, and hint at perhaps some subtle and largely unseen developments in the netsphere.

Scary? Just don't look inside the iPod ...

Re:Nothing new, move along (1)

theonewho (686963) | more than 5 years ago | (#25969477)

hi,

i agree -- the means do indeed raise questions -- the evidence hints at ... hmmm ... ?

it surely does seem like a feint ...

cheers,
kevin

yes new (0)

Anonymous Coward | more than 5 years ago | (#25969685)

The distributed attacks get past normal security measures which watch for attacks from a single IP.

So...something new.

Re:Nothing new, move along (5, Insightful)

ShaunC (203807) | more than 5 years ago | (#25970231)

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:

  • That I am among the pool of targets to be probed
  • That I am, at this precise second, the next target to be probed
  • That this particular bot hasn't probed me recently and is now eligible to probe me again
  • Which usernames have already been probed on my machine
  • The next username, in sequence, that should be attempted on my machine

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.

Go install fail2ban (2, Informative)

victim (30647) | more than 5 years ago | (#25967215)

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...

  • Have two different IPs you can come from. You will eventually ban yourself by being stupid. It took me a year, but I finally banned myself while working on some backup scripts.
  • It is written in python and uses 3M of RAM plus maybe 20M more virtual memory. Sure, you high end gamers have 100 times that in your video card alone, but if you are running on a 64M VPS or a 32M router it is something to think about.
  • You can have it watch much more than ssh if you wish.
  • If you forward the syslogs of all your machines to your firewall and run fail2ban out there you can protect all of your machines at the first transgression and only have to manage one copy of fail2ban.
  • If you are running virtual servers, consider running their syslogs out to the host box and running fail2ban there. Works well.
  • There should be a memory efficient alternative, maybe I'll have to write that.

Re:Go install fail2ban (0)

Anonymous Coward | more than 5 years ago | (#25967373)

How does it handle spoofing? Because if someone figures out you're running it they can have all sorts of fun.

Re:Go install fail2ban (1)

profplump (309017) | more than 5 years ago | (#25968143)

Only if you have it monitor unidirectional traffic -- it's pretty hard to spoof TCP because the connection doesn't open until you send packets in both directions. A TCP spoofer needs to be able to see and inject packets that are being routed along legitimate paths, which essentially means they need to be on the local network at your end or the local network of the legitimate remote host.

And if someone is on your local network attacking you an IP-based block won't work not matter what you do.

Re:Go install fail2ban (1)

X0563511 (793323) | more than 5 years ago | (#25967605)

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 (5, Informative)

Yath (6378) | more than 5 years ago | (#25967657)

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.

Re:Go install fail2ban (1)

MichaelSmith (789609) | more than 5 years ago | (#25967675)

There should be a memory efficient alternative, maybe I'll have to write that.

Mine uses 53 lines of ksh.

IPtables rate limiting is better (1)

flyingfsck (986395) | more than 5 years ago | (#25968191)

Actually, a simple one line IPtables rate limit on port 22 new connection attempts (or whichever port you use for SSH is better than Fail2ban or Denyhosts, because it will never lock yourself out.

I suspect that the author has such a limit on his firewall machine and that it is the reason why he sees the slow attack rates and that the slowness has nothing to do with the attackers!

Re:IPtables rate limiting is better (1)

Sancho (17056) | more than 5 years ago | (#25969627)

Most of the time, these limits are by source IP-address. This new attack self-limits the rate of connections from a single IP address, and instead hits the same destination from multiple sources. Rate limiting globally will work here, but will mean that legitimate SSH connections will be slowed down.

Re:Go install fail2ban (0)

Anonymous Coward | more than 5 years ago | (#25968769)

Someone else already mentioned it, but running ssh on a non standard port solves all your worries.

Sure an attack with some port probing and fingerprinting first will find the ssh port, but the normal kind of attacks that happen right now are blocked by that.

Probing went down from up to a few thousands a day to zero.

Re:Go install fail2ban (2, Informative)

ShaunC (203807) | more than 5 years ago | (#25970397)

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.

ssh login attempts (1, Informative)

Anonymous Coward | more than 5 years ago | (#25967221)

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.

Easy was to stop 90% of SSH attacks (1)

TrashGUY (966340) | more than 5 years ago | (#25967275)

I just block ssh access from anything with .ch .kr or .ru

Re:Easy was to stop 90% of SSH attacks (2, Interesting)

X0563511 (793323) | more than 5 years ago | (#25967641)

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.

Very interesting; this bypasses my auto-banning fw (3, Interesting)

Khopesh (112447) | more than 5 years ago | (#25967441)

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 (4, Informative)

Khopesh (112447) | more than 5 years ago | (#25967903)

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 [fail2ban.org] 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 [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:Solution - disable root ssh login, password aut (1)

maxume (22995) | more than 5 years ago | (#25969025)

It might make more sense to try to notice tens of thousands of attempted log ins to a single account and then do something proactive about that (I realize that this is less proactive than attacking user passwords, but it has the advantage of not requiring bothering them).

Re:Very interesting; this bypasses my auto-banning (1)

multipartmixed (163409) | more than 5 years ago | (#25969329)

If that product use the recent target, be careful what kernel you use it on. You'll find that after a few weeks the damned target starts matching stuff it shouldn't and you might lock yourself out of your server. IIRC the expiry time winds up becoming infinite.

Don't worry, it's a documented bug somewhere, and recent kernels aren't affected. 2-year-old kernels are for-sure though. I just can't remember the precise details; I've been bit by it trying to throttle SMTP.

Portknocking (3, Interesting)

Pvt_Ryan (1102363) | more than 5 years ago | (#25967463)

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 (2, Informative)

skeeto (1138903) | more than 5 years ago | (#25967509)

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:Nothing new here: use DenyHosts (2, Informative)

oGMo (379) | more than 5 years ago | (#25967981)

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:Nothing new here: use DenyHosts (0)

Anonymous Coward | more than 5 years ago | (#25968253)

> I like to run DenyHosts ...

The point of these new distributed attacks, is that DenyHosts won't normally detect them. That's the scarey part, and is why we recommend disconnecting SSH from outside access by default now.

A doorknocker sequence can be used to enable it for a one-shot one-IP access for 10 seconds at a time on a random port (or even on a single port).

This kind of protection makes it much harder to even discover that SSH is available, and pretty much defeats the new attacks.

Combined with certificate logins, it leaves things fairly safe again. For now..

Re:Nothing new here: use DenyHosts (1)

Sancho (17056) | more than 5 years ago | (#25969761)

Distributed attacks require distributed defenses. Newer versions of Denyhosts let you synchronize your block lists with other Denyhosts users. It's really quite excellent.

ssh -p !22 (1)

jannesha (441851) | more than 5 years ago | (#25968059)

I got pissed off with the rattling of my ssh doorknob years ago and moved it off of port 22. It's not that hard. The only downside is having to remember (and type) the port number.

Now my logs are nice a quiet and I'm the only username who ever even tries to connect. Not the solution for Enterprise, but it works at home.

Re:ssh -p !22 (2, Informative)

_LORAX_ (4790) | more than 5 years ago | (#25968603)

.ssh/config

Host hostname
    Port yourport

then you can ssh to hostname and not have to type the port everytime.

Change SSHd port (1)

mmxsaro (187943) | more than 5 years ago | (#25968099)

This is easy to do and will thwart kiddies/botnets off, just change the SSHd port to something else other than 22. Unless your server is being targeted directly (they'll nmap you...) this will stop most mass-scan brute-force attacks.

Repeat the above for FTPd, too.

Same time, same logins (0)

Anonymous Coward | more than 5 years ago | (#25968649)

The interesting thing is that, since Nov 23 06:48:34, I'm getting the exact same login names at virtually the same times as mentioned in TFA. This is in the 77.248.x.x netblock, the Netherlands. Anybody else noticing the same?

-JAB

Weak SSH keys (1)

kabloom (755503) | more than 5 years ago | (#25968849)

Wait until they combine this with Debian's 2^16 weak ssh keys. Do you think that will be easier or harder to crack than passwords?

This attack must balance reward and risk. (2, Interesting)

dweller_below (136040) | more than 5 years ago | (#25969153)

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

Time to switch to SSH keys and ban password auth (1)

caseih (160668) | more than 5 years ago | (#25969319)

I switched to only allowing keys a long time ago. This stops this attack dead, whether it is distributed or not. If I ever lock myself out, or use a computer where I don't have any keys already set up, I have a special, password-encrypted key that I can access over an authenticated https url.

On my VPS I took advantage of SSH's new configuration features to disable password authentication for outside connections, but allow password for connections coming from within my wide-area private network (openvpn rocks!). But with the stored, accessible, ssh key on the server itself, I rarely need to use a password directly, ever.

pf solves (0)

Anonymous Coward | more than 5 years ago | (#25969631)

table persist file "/etc/pf.blacklist"

block drop in log quick on $ext_if from

pass in on $ext_if proto tcp from any to ($ext_if) port ssh \
                flags S/SA keep state \
                (max-src-conn-rate 6/60, overload flush global)

I've Noticed It, Too (1)

ewhac (5844) | more than 5 years ago | (#25969683)

I run a FreeBSD box at the end of an ADSL line. Normally I would see a handful of SSH attempts. On a bad day I'd see a couple hundred. This last week, I've seen upwards of 1500 per day, all coming from different IP addresses. It's a straight dictionary attack, moving through in dictionary order. I think I'm in the G's right about now...

I long ago installed 'bruteblock' on my box, which plonks an IP address for N minutes after X failed attempts (both configurable). It's very small and efficient. But this obviously does nothing for distributed attacks. I should probably move the SSH port for a couple weeks... *sigh*

Schwab

Mail Admins like me are used to this already. (1)

TheNarrator (200498) | more than 5 years ago | (#25969891)

For about the last 2 years I Have been getting continuously hit with botnet hosts every 2 minutes trying every conceivable email address@mydomain. I tried writing a rule to autoblock them with iptables but the list grew into the 10s of thousands and slowed down my machine. I put a greylist on it and now they get greylisted but they keep coming and coming and coming. There must have been more than a million greylisted email attempts over the preceding two years. Far more than the amount of legit mail I get.

Lots of poor "solutions" here (1)

monkeySauce (562927) | more than 5 years ago | (#25969959)

Pretty lame, people.

Move sshd to another port?
Obscurity.

Rate limiting?
IP-based bans on failed logins?
Elaborate username based bans?
All reactive solutions.

Portknocking?
A more complex obscurity tactic, but very weak as an extra authentication layer.

TFA mentions ssh public key auth, and disabling password authentication. That would be much better/more effective than anything mentioned here.

If you're serious about security, then you aught to actually add another layer. Firewall off ssh completely and require a VPN connection first. eg: http://openvpn.net/ [openvpn.net]

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...