×

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!

The "Hail Mary Cloud" Is Growing

Soulskill posted more than 4 years ago | from the like-a-zombie-chia-pet dept.

Security 102

badger.foo writes "The Australian rickrolling of jailbroken iPhones only goes to prove that bad passwords are bad for you, Peter Hansteen points out, as he reports on the further exploits of the password-guessing Hail Mary Cloud (which we've discussed in the past). The article contains log data that could indicate that the cloud of distributed, password-guessing hosts is growing. 'With 1767 hosts in the current sample it is likely that we have a cloud of at least several thousand, and most likely no single guessing host in the cloud ever gets around to contacting every host in the target list. The busier your SSH deamon is with normal traffic, the harder it will be to detect the footprint of Hail Mary activity, and likely a lot of this goes undetected.'"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

102 comments

Why Is This The Linux Section?!! (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#30106722)

I don't see any relevant of this to Linux whatsover.

Are you guys really running out of news to put in there?

Re:Why Is This The Linux Section?!! (2, Informative)

Suzuran (163234) | more than 4 years ago | (#30107338)

Because it's trying to guess SSH passwords?

Re:Why Is This The Linux Section?!! (0)

Anonymous Coward | more than 4 years ago | (#30113618)

SSH is Linux specific? That is "Score:4, Informative"?

Re:Why Is This The Linux Section?!! (1)

Suzuran (163234) | more than 4 years ago | (#30114188)

No, but it's present on most linux server installations, and therefore relevant to linux. I don't see how it's irrelevant. If it bothers you, maybe we should have a "unix" super-section that covers OS X, Linux, BSD, etc. that stuff that affects everyone can go under.

What has to happen? (1, Flamebait)

Opportunist (166417) | more than 4 years ago | (#30106740)

Just was has to happen to make people realize (or make lawmakers force them to) that securing your boxes is a necessity?

What? Tell me, please, what has to happen? How much damage is needed? We'll see it happen, no matter how much damage is required. The question is only whether it's too late or whether we can repair it.

Re:What has to happen? (0)

Anonymous Coward | more than 4 years ago | (#30106832)

What? Tell me, please, what has to happen?

You have to start praying the Hail Mary obviously...

Hail Mary, full of grace
The LORD is with thee
Blessed art thou among women
And blessed is the fruit of thy womb, Jesus...

Re:What has to happen? (1)

Jeremy Erwin (2054) | more than 4 years ago | (#30107318)

Mary responds, curtly, to your half finished prayer

"What do you want?"

The full prayer is [quote]
"Hail Mary, full of grace, the Lord is with thee; blessed art thou among women, and blessed is the fruit of thy womb, Jesus. Holy Mary, Mother of God, pray for us sinners, now and at the hour of our death. Amen"[/quote]

The attack is called "Hail Mary", because it should take a miracle to break in to a foreign system by "guessing passwords".

Re:What has to happen? (1, Informative)

Anonymous Coward | more than 4 years ago | (#30107784)

The attack is called "Hail Mary", because it should take a miracle to break in to a foreign system by "guessing passwords".

The link the author provides in the story is about the Hail Mary pass [wikipedia.org]. Sure, the Hail Mary pass itself goes back to the prayer, but you're skipping a layer of analogy (and an interesting bit of trivia).

Re:What has to happen? (1)

Jeremy Erwin (2054) | more than 4 years ago | (#30108498)

I don't watch much football. Can the quarterback throw as many balls as he wants, in the hope that at least one of his receivers catches it?

Re:What has to happen? (0)

Anonymous Coward | more than 4 years ago | (#30106982)

Clearly, for most people the damage so far hasn't outweighed the costs of properly securing their systems, or at least hasn't outweighed the benefits of using Windows (or their goddamn iPhones, in this case).

This is just the free market at work.

That said, those of us who aren't fucktards are making use of OpenBSD, which actually takes security somewhat seriously, unlike virtually every other operating system out there.

Re:What has to happen? (0)

Anonymous Coward | more than 4 years ago | (#30109762)

I do apologise, I just wanted to edit a text file.

Re:What has to happen? (1, Insightful)

FunPika (1551249) | more than 4 years ago | (#30107172)

(or make lawmakers force them to)

I can't wait for the day that Congress passes a law to the effect of "If malware causes your computer to do something illegal, you will be held responsible for said illegal activities in court even if you can prove malware was the cause."

Re:What has to happen? (4, Insightful)

Opportunist (166417) | more than 4 years ago | (#30108464)

This is pretty much what I fear will happen eventually. Right after we'll all be equipped with "trusted" computers that will only run what we want if we jailbreak them, which will not only void their warranty but also open us up to trains of thought such as: If you didn't jailbreak and thus could only run software approved by The Powers That Are, you would not be susceptible to malware (or if, TPTA would have to take responsibility) and are thus fully liable.

Sounds far fetched? Think about it. Outlawing jailbreaking will probably not really work out, even if it was outlawed, who cares (how do you want to prosecute it)? But locked down devices that, in theory, cannot be harmful being spam chuckers will essentially mean you broke the lock. And then your lawmaker may choose, either he'll slap you for breaking the lock or, if he can't do that for some odd reason like a device that you own belonging to you, will catch you with the angle that you're causing damage with it and that can incur a hefty bill.

Don't tell me it ain't possible. If you haven't been asleep the last 10 years and when you look at the way things turned, it's anything but unlikely to become the next angle to ensure we only run what we're supposed to run.

And if at all possible, I'd like to avoid giving anyone a reason to follow that train of thought.

Re:What has to happen? (2, Insightful)

herojig (1625143) | more than 4 years ago | (#30112294)

Dude, I totally agree with you. We are being channeled into systems that will not be under our full control, and doing anything about going down that path (other then willingly) is to be deemed unlawful. But I am not sure if freedom-loving individuals have any choice at this point...talking about it on /. is not going to change anything, other then providing a record of the dissent. So as they say here, "Ke Garne" or what to do?

Re:What has to happen? (1)

Proteus Child (535173) | more than 4 years ago | (#30119324)

Just was has to happen to make people realize (or make lawmakers force them to) that securing your boxes is a necessity?

The Infocalypse?

Put in denyhosts... (2, Interesting)

Tangential (266113) | more than 4 years ago | (#30106762)

Denyhosts is available for most linux distros. You can tune its behavior and it will basically filter out requests coming from misbehaving hosts. From Wikipedia: "DenyHosts is a Python based security tool for SSH servers. It is intended to prevent brute force attacks on SSH servers by monitoring invalid login attempts in the authentication log and blocking the originating IP addresses. "

Re:Put in denyhosts... (1, Funny)

Anonymous Coward | more than 4 years ago | (#30106794)

denyhosts is security through obscurity much like changing the default port for SSH... or so I'm told.

Re:Put in denyhosts... (1)

Gerald (9696) | more than 4 years ago | (#30107124)

Using Denyhosts and changing your default port adds layers of obscurity on top of existing security. Both are damn useful for reducing the number of real-world intrusion attempts on your system.

Re:Put in denyhosts... (1)

fwarren (579763) | more than 4 years ago | (#30111226)

Right now changing the port number is getting the job done.

The average attack is just trying to connect to port 22 across an IP range. Once it connects it then trys to brute force the password. If you have a weak password you are sunk. If you have a 14 digit password like !))%L0553r-boy they are not getting in.

Any of the following will make it more difficult.

1) Denying hosts of there are to many log in attempts from an IP address.

2) Moving to a non-standard port.

3) Port knocking.

If you implement port knocking with a non-standard port and have a complex password are you safe?

Yes and No.

Yes, no one over the Internet randomly looking for hosts is going to find you let alone attempt to crack you.

No, because at that point anyone who wants into your network is going switch to more physical methods or social engineering. What is the cost of cracking a 9 digit password? 50,000? You could hire a decent thief for $50,000 who could disable an alarm, get past the cameras and guards, and mirror a hard drive. How much work would it be to find out where all your IT staff lives, and if any of them bring a laptop home from work. What would it take to break into their house and get access to the laptop? The possibility that you could have them "win" a set of tickets to a show and then "vist" there place while they are at a show. Or pay some chick to hit up on one of the techs. Be creative for $50,000 it would cost to use the cloud to break a password if you could even find an ssh port to attack, there are lots of "outside of the box" ways to get the password from the inside of the company.

Re:Put in denyhosts... (2, Informative)

sjames (1099) | more than 4 years ago | (#30108200)

Actually, no it isn't. It is a tool to limit the number of attempts at password guessing. Knowing it's there won't help the attacker at all (they still can't just blast away from a dictionary).

Re:Put in denyhosts... (4, Informative)

jofer (946112) | more than 4 years ago | (#30108330)

Denyhosts isn't security through obscurity in any way.

It just monitors /var/log/messages (or wherever your sshd is configured to log to) and blocks ip addresses with multiple failed logins.

I think you're thinking of port knocking, which is security though obscurity, though it's still damned useful.

Re:Put in denyhosts... (1)

Cozminsky (452030) | more than 4 years ago | (#30113110)

How is port knocking security through obscurity? It's putting a password on being able to connect to the ssh daemon. Admittedly upstream routers could easily grab the "password" if they know what it's for but they've just peeled back one layer of the onion.

Re:Put in denyhosts... (5, Informative)

Anonymous Coward | more than 4 years ago | (#30106826)

Denyhosts will *not* protect you from Hail Mary. Read the article...this particular botnet may send you only a single login from a single IP, but the cloud as a whole will send you hundreds of attempts.
The correct solution is to disable password login, and use pubkey auth instead.

Re:Put in denyhosts... (2, Informative)

masshuu (1260516) | more than 4 years ago | (#30106868)

I change the default port that SSH listens on and use Key login, just to be safe.

I assume theres not much more i can do to secure it.

I would imagine 90% of the people out there don't need to have ssh running on a standard port.

Re:Put in denyhosts... (5, Informative)

Predius (560344) | more than 4 years ago | (#30107822)

The nice thing about denyhosts is you can participate in the global shared DB, so one failed login on your machine, one on mine, etc, we all report the same IP, it gets flagged in the global DB, so we all block it. Machines that IP hasn't hit now won't allow login attempts from it.

Re:Put in denyhosts... (1)

Culture20 (968837) | more than 4 years ago | (#30109230)

If only denyhosts would open up the server portion. Some people want the functionality of the denyhosts server in their organization without having to participate in (or rely on) the global DB.

Re:Put in denyhosts... (0)

Anonymous Coward | more than 4 years ago | (#30109794)

Baww. Linux people don't give everything for free.

How unamerican of them.

Re:Put in denyhosts... (3, Interesting)

l2718 (514756) | more than 4 years ago | (#30106980)

Denyhosts ... "filter[s] out requests ... by ... blocking the originating IP addresses."

Unfortunately, these phones do not have fixed IP addresses. IP-based authorization won't work when half the time your IP address is assigned by the local WiFi LAN as is the address of the other phone -- after all, you might be using SSH at home where IP addresses are assigned from the same range as at the hostspot where you get attacked. You need host-based or user-based authentication that does not depend on IP addresses. For example, SSH supports user-based cryptographic keys.

I also think that blocking hosts is the wrong way to go. Most people do not run open-to-the-public login servers, either on their home computers or on their phones. If you must do host-based blocking then the correct approach is that of hosts.allow — deny all requests by default except for those that you trust.

Re:Put in denyhosts... (1)

ottothecow (600101) | more than 4 years ago | (#30107088)

This is difficult to do. I don't need to run a login server that is open to the public but I do need access that is open to me. I do this to account for unexpected situations.

By virtue of the unexpected nature, white listing is not a valid option in these situations. If I am somewhere and discover that I need access to my computer for some reason, I will not know in advance what IP I will be connecting from.

Re:Put in denyhosts... (3, Funny)

David Gerard (12369) | more than 4 years ago | (#30107134)

The main role of Denyhosts is to lock you out of your own box if you're using an ssh-based file system, which applies your incorrect password multiple times rather than once. I've spent way too much time going into my hosted box via somewhere else to let myself back in.

Re:Put in denyhosts... (4, Informative)

MrMr (219533) | more than 4 years ago | (#30107470)

Put the trusted host in hosts.allow, and it won't be locked out accidentally.
or fix your filesystem clients.

Re:Put in denyhosts... (-1, Troll)

Anonymous Coward | more than 4 years ago | (#30107756)

The main role of Denyhosts is to lock you out of your own box if you're using an ssh-based file system, which applies your incorrect password multiple times rather than once. I've spent way too much time going into my hosted box via somewhere else to let myself back in.

Dude, you're such a fucking genius. A normal person would have that happen one time and then they'd just learn how to correctly use an ssh-based file system. Or they'd remember their own passwords. But not you! No, you push the envelope and you defy the edge by letting that happen more than once so you can practice letting yourself back in. Brilliant! With all that practice I bet you can let yourself back in your own machine in half the time it would take me!

Re:Put in denyhosts... (1)

emurphy42 (631808) | more than 4 years ago | (#30107426)

I've long since gone the opposite route, my server rejects all requests unless /etc/hosts.allow has already whitelisted them. Granted, it's a home server and I'm the only one who ever uses SSH on it. (Hotel wifi is temp-whitelisted on the fly by remote-connecting to a whitelisted work client.)

Re:Put in denyhosts... (5, Informative)

jimicus (737525) | more than 4 years ago | (#30107472)

Very true, but it'll only keep out an absolute moron. Anyone with half a brain will use a distributed mechanism, which means DenyHosts will only see failed password attempts from a given host a few times.

There's plenty more to do:

- Don't allow root logins via SSH, or limit them to key-based logins (trivially easy in /etc/ssh/sshd.conf)
- Disable shell accounts unless they're really needed. rssh is useful here - limit what a user with SSH login authority can do.
- Lock down other services. What good does DenyHosts do you if SSH and a separate app which can't be locked with DenyHosts both use the same password mechanism?
- Lock accounts which have more than N failed logins. (Though if you've centralised logins such as in the above example, it'd probably be better to do this from whatever system deals with the authentication, eg. LDAP).

Re:Put in denyhosts... (2, Interesting)

v1 (525388) | more than 4 years ago | (#30107640)

It is intended to prevent brute force attacks on SSH servers by monitoring invalid login attempts in the authentication log and blocking the originating IP addresses. "

RTFA. From the looks of the logs he posted, it's deliberately only trying a couple times from any given IP, specifically to prevent this sort of detection.

I used to do this sort of thing with scripts on my server, after running into an occasional spurt of several hours of an IP address trying every username in the book, apparently hoping for a blank password or same-as-login password. I had it set to autoban the IP at 5 of any sort of failed attempts in a row. I had to do it this way unlike your above example because the guesses kept changing the username, and most traditional "delayed authentication failure" responses nowadays are only effective after multiple attempts on the same username, and they were running a username dictionary, not a password dictionary.

But your method is 100% worthless against this attack.

Nowadays, my servers listen on a nonstandard port, and rsa key login is manditory. End of problem.

How to ID an Infected Computer (1)

derrickh (157646) | more than 4 years ago | (#30106776)

So is there any way other than looking at the packets on your router to know if a system is compromised? This is a question thats been asked many times before but Ive yet to see a straight answer.

Re:How to ID an Infected Computer (1)

elsJake (1129889) | more than 4 years ago | (#30106804)

Sure , make a list of all your files and corresponding checksums , and once in a while take it offline and verify the checksums on another computer.If anything that you haven't modified has changed , you likely have a problem.

Re:How to ID an Infected Computer (4, Interesting)

geekboy642 (799087) | more than 4 years ago | (#30106886)

It's difficult to say whether or not a given system is infected, even if you inspect a complete packet log. Your checksum plan is one of the few ways to guarantee a lack of infection. Actually even that isn't always a guarantee, depending on where the hack is hiding. It could be in the MBR or even burned into the BIOS.

Luckily, in most cases the hackers aren't clever enough to hide their steps that well. There'll be oddly-named files in /var/www, ps and top will disagree about running processes, or you'll suddenly find yourself locked out of some system management tool.

Re:How to ID an Infected Computer (1, Funny)

certain death (947081) | more than 4 years ago | (#30106932)

You have a router in front of your iPhone?!? WOW! I have GOT to get that app.

Re:How to ID an Infected Computer (2, Informative)

ceoyoyo (59147) | more than 4 years ago | (#30107798)

Sure. Whenever I'm at home the phone connects via wifi through an Airport. When at work it connects via wifi through the university's secure wifi network.

Denyhosts (0)

EllisDees (268037) | more than 4 years ago | (#30106798)

I would think that anyone running an ssh server should also be running something like the Denyhosts daemon [sourceforge.net]. After a set number of failed logon attempts, it will automatically add the connecting ip address to hosts.deny and their hack attempt is over.

Re:Denyhosts (2, Insightful)

turtleshadow (180842) | more than 4 years ago | (#30106872)

The article noted that this is a vulnerability to cracked smartphones with ssh installed for which the user will likely not even know opens up such a vulnerability to their cell.

  I think that this is more serious for wi-fi and bluetooth enabled devices as the data charge is circumvented making it even harder to detect?

I'd hate to start streaming my smartphone's logs back to my IDS, but brute force is not a new reality but the environment is very precarious as the smartphone does a lot now but may not "do" enough to protect its own resources from attack.

Re:Denyhosts (1)

geekboy642 (799087) | more than 4 years ago | (#30106914)

The iPhone bit was a hook to draw eyeballs. The smartphones are no more or less susceptible than any other machine running SSH, all of whom should have a more sensible password policy.

Re:Denyhosts (2, Insightful)

ToasterMonkey (467067) | more than 4 years ago | (#30107606)

all of whom should have a more sensible password policy.

Why does a cellphone OS need a user authentication system in the first place? Maybe at the application level.. no, I can't see that either. Anyway, this phone has one, and it's not meant to be used this way. These things are not meant to have SSH running on them, and whomever released the SSH package for them is irresponsible for not taking that into account.
It doesn't even need to authenticate using system methods, it could generate a random password at install - display on screen, and do it's own authentication. Maybe even offer to pop up an accept dialog before allowing access? Just a thought..

Sorry, I just can't understand how the phone and users continue to be blamed because in free software land developers are void of any and all quality concerns. At some point.. not the developers involved, but "free software" is going to get rap it deserves. It is what everyone makes it. Look after your own, if you see a free turd, call it a turd.

why ssh on phones? (1)

reiisi (1211052) | more than 4 years ago | (#30113118)

Because today's phone is tomorrow's remote terminal.

You'd better believe I sometimes wish I could log into my personal server remotely from my phone to check the logs or something.

Now, I may not now need to log into my phone via sshd, but, actually, yes I do. Simple stuff. The phone company's mail software and user input stink. But that's trying to fix a different problem, really.

Re:why ssh on phones? (1)

Eunuchswear (210685) | more than 4 years ago | (#30115040)

Because today's phone is tomorrow's remote terminal.

You'd better believe I sometimes wish I could log into my personal server remotely from my phone to check the logs or something.

Tomorrow? I log in to my servers from my phone around 5-6 times a day.

You don't have putty on your phone? Why not?

Re:Denyhosts (1, Funny)

TheRaven64 (641858) | more than 4 years ago | (#30106960)

Yes indeed. You can always make a network-facing daemon that has been heavily audited more secure by putting a Python script between it and the public Internet.

Re:Denyhosts (0)

Anonymous Coward | more than 4 years ago | (#30107186)

Does Denyhosts actually sit between the public Internet and sshd, or are you just making stuff up?

Re:Denyhosts (2, Interesting)

causality (777677) | more than 4 years ago | (#30107240)

Yes indeed. You can always make a network-facing daemon that has been heavily audited more secure by putting a Python script between it and the public Internet.

What I will say here applies to password logins. For SSHD that is configured to accept only cryptographic/public-key authentication, the attacks that Denyhosts would block are only a nuisance (they fill up logfiles).

That heavily-audited network-facing daemon does not concern itself with password security. You can allow remote root logins and set your root password to "password" and that daemon will faithfully do what you told it to do. The heavy audits are designed to make sure that a person who does not have a valid login cannot get a shell without first guessing valid login credentials. The Python script makes it infeasible for a single host to brute-force those login credentials assuming a reasonably strong password. Thus, it addresses a security issue that is actually beyond the scope of SSHD.

Personally I prefer SSHGuard because it will use iptables to drop packets from offending hosts. In my opinion that's a better approach than adding the hosts to a hosts.deny file. A host listed in hosts.deny can still try to connect to your daemon; it will just be immediately disconnected. By contrast, anything firewalled by iptables and set to DROP won't even get so much as a momentary TCP connection. Not a big difference, but I say let them wonder if you're even online anymore. There's also no dependency on the robustness of tcpwrappers (well-tested though they may be).

Re:Denyhosts (2, Informative)

ceoyoyo (59147) | more than 4 years ago | (#30107824)

Over the last week my SSH server has gotten about one password guessing attempt every ten seconds. Presumably they're not all from different hosts, but a quick visual scan didn't show up any duplicates and the ones that are close in time are certainly all from different IP addresses.

Re:Denyhosts (2, Informative)

Web Goddess (133348) | more than 4 years ago | (#30112166)

try this

cat logfile | cut -d " " -f [fill in the field with the IP ] | sort | uniq -c | sort -n

(and if need be, add ' | tail -20')

This will show you whether there are repeat IP addresses in the log.

Webgoddess

Re:Denyhosts (1)

ceoyoyo (59147) | more than 4 years ago | (#30125194)

Not on OS X it doesn't. No cut -d.

A quick grep shows that a sample IP address does try about two or three times a day, which suggests several thousand unique addresses gracing me with their attention.

Bad or good matters not here... (0)

Anonymous Coward | more than 4 years ago | (#30106814)

...because if the password is pre-set, default, and known to everyone accessing the software, then, yeah, exactly, you dumb s**t of an article author.

Re:Bad or good matters not here... (1)

badger.foo (447981) | more than 4 years ago | (#30106882)

the rickrolled iphones were vulnerable because the password had been published. published password == bad

DenyHosts will not save you; disable passwords (4, Interesting)

Radhruin (875377) | more than 4 years ago | (#30106950)

This is a distributed effort, and any one host will not hit your machine more than once. You could configure it to block entire country's subnets, but that's still only marginal protection.

What you want to do is disable username/password authentication on your ssh hosts. This is one of the first things I do. Set up your machine's public and private key, copy your public key to all your other machine's authorized_keys file, and edit your sshd config and add the line "PasswordAuthentication no". Now, broken crypto libraries aside, you will be safe from this sort of attack.

Re:DenyHosts will not save you; disable passwords (1)

0123456 (636235) | more than 4 years ago | (#30107070)

Agreed: anyone of clue should disable password logins for SSH or require use of strong passwords (i.e. long and randomly generated) if they can't do so.

Still, it could be worse: my webcam came with a password on the http: front-end, but a passwordless root login if you telnet to the other open port that nmap found. At least they must have realised they'd made a mistake because the firmware update removed that insane security hole.

Re:DenyHosts will not save you; disable passwords (1)

marcansoft (727665) | more than 4 years ago | (#30108138)

The required password security for SSH is often overstated. The absolute number one never-ever-do-this thing is dictionary words (or user names or easily guessable information) with little to no mangling: that's a recipe for disaster. Besides that, any reasonable password length (8 characters or more) is fine. It doesn't even have to be random, it can be pronounceable gibberish or even something coherent to you, as long as it's very particular to you and obscured in a non-obvious way (e.g. don't just do 'standard' leetspeak on a dictionary word). Plain numbers are significantly weaker, but even an 8-digit number is unlikely to be guessed in a network SSH attack, though I wouldn't recommend relying on it.

Realistically speaking, 6 characters of pure random, 8 characters of pronounceable random, or 10-15 characters of something coherent but mangled are basically secure for SSH. SSH attacks are over the network, which means you can't get even close to the number of tries per second of local password hash cracking attempts. The number of passwords that are going to be tried are in the thousands or millions over the long term, not the billions of possible combinations.

I use public keys to access some remote systems and they certainly are a lot better security-wise, but I keep my home boxes and my main server accessible via passwords, since I don't usually carry my private keys around when I need to log in from another box.

user names, too (2, Informative)

reiisi (1211052) | more than 4 years ago | (#30113062)

Somebody posted a list of user names being tried above. Take a look at it for a little education on what not to use as a user name. No simple first names, no matter how romantic or aesthetic it feels. No names of servers (mysql, etc), especially not unadorned. "admin", of course, but also "manager" are out.

So, make the user names harder to guess. Root, of course, do not allow root to log in, period. Definitely not over the net, anyway. If you must log in as root, change the root user name, or add a synonym -- rename the root something obscure. Maybe the name of your favorite vegetable with some leetspeak thrown in, or turned backwards, or scrambled, or, think of you own way to make it obscure.

Use initials instead of single names. Or, better, use initials in combination with simple names, or job titles in combination with something like the first name and an initial. Or multiple names.

(If you might have someone specifically targeting your servers for something valuable, don't use names or initials or job titles at all, of course. Sometimes, you might even want to generate the usernames randomly, or at least partially randomly.)

In fact, if you disable, or just don't have root or admin or pguser or web, etc., you can be really, really sure that an attempt to log in with such names indicates someone who really shouldn't be allowed to even try to log in.

The point is, it's much harder to brute-force a system when the attacker doesn't even know what user names to start with, whether hail mary or machine-gun.

And then you make the password reasonably long and obscure, and you're pretty safe.

(User names, at least, usually won't need to be changed every six months.)

Re:DenyHosts will not save you; disable passwords (1)

Bert64 (520050) | more than 4 years ago | (#30113790)

One of the biggest issues is extremely weak enforcement of passwords...
Many devices come with default passwords, and do not force users to change them at all.
In corporate networks even when a password policy is implemented, it's usually extremely weak... Typically requiring one number, one uppercase letter and 8 characters or more. Password1 is a perfectly valid password in this scenario, and when forced to change it Password2 is equally valid.

And of course the unavoidable issue - people have too many passwords these days, and nothing stopping them from all being the same... And these passwords are stored, used and recovered in various ways...

Some places will store the password unencrypted (or reversibly encrypted) and happily email it to you in the clear, while others will do a proper one way hash and the only recovery procedure possible will set a new password.
Some places will ask security questions like "mothers maiden name" or "your first school" - which is easily available information...

There are a million and one ways to get users to disclose a password, the traditional attacks with a fake paypal/bank/ebay/etc website might be easy to detect, but how about a site that offers you something legitimate looking and free, which just requires you to give an email address and set a password so you can adjust your settings in future... How many people would use the same password/email here as they do elsewhere?

Re:DenyHosts will not save you; disable passwords (1)

RobertLTux (260313) | more than 4 years ago | (#30107350)

and you could also have a flash key with your SSH utility that could be used to login from any other computer (heck with the price of flashkeys these days you could have your entire software stack on the key and a good bit of data)

Re:DenyHosts will not save you; disable passwords (1)

ceoyoyo (59147) | more than 4 years ago | (#30107866)

My iPhone has my SSH key on it. If you REALLY need to log in to an SSH server from some random computer and don't have your key handy you could ssh in from your phone and turn on password authentication just long enough to log in.

Re:DenyHosts will not save you; disable passwords (1)

nurb432 (527695) | more than 4 years ago | (#30107740)

And if a machine that has your public key on it is compromised ?

Re:DenyHosts will not save you; disable passwords (2, Informative)

mr_flea (776124) | more than 4 years ago | (#30107936)

The public key doesn't matter. Anyone can have your public key and security is not affected. However, if they get your private key, that's another story... (But you can also password-protect your private key as a last measure of security.)

Re:DenyHosts will not save you; disable passwords (1)

nedlohs (1335013) | more than 4 years ago | (#30109216)

Do you know what the word "public" means?

Can you see how it makes that irrelevant?

Re:DenyHosts will not save you; disable passwords (1)

dkf (304284) | more than 4 years ago | (#30109530)

And if a machine that has your public key on it is compromised?

Either you are very very stupid, or you meant private key. If the former, you understand that the only reason I'm not publishing my public ssh keys here, on slashdot, is that I don't want some loony jerk giving me an account without my knowledge? I have more than enough of the damn things already. However, if you meant private keys then that's a fair point: they're best kept on machines that never run services. (OK, it would also be better if those machines never ran web browsers either given the general inability of javascript implementors to grasp what a sane security policy is, but sometimes you just have to compromise. Or carry two laptops around with you...)

Re:DenyHosts will not save you; disable passwords (1)

shentino (1139071) | more than 4 years ago | (#30108486)

What we really ought to do is start cracking down more on botnets.

Letting criminals sheperd up huge flocks of zombie computers is the root of two very serious problems: spam and DDoS attacks.

Forget electronic terrorism. These guys have a fucking ARMY of computers.

The cloud attack isn't new (3, Interesting)

damn_registrars (1103043) | more than 4 years ago | (#30107026)

I've mentioned [slashdot.org] distributed [slashdot.org] attempts [slashdot.org] against [slashdot.org] my own [slashdot.org] system [slashdot.org] before. The only thing that has changed over time is the number of systems involved in a cycle. I suspect my own system is currently (by nothing other than bad luck) the target of multiple concurrent cycles. I suspect this because I see different parts of the alphabet being cycled at different rates (in terms of attempts per user name) at the same time.

Although in spite of all the advice people offer to ward off the attacks, there are a couple of really simple things to do that will keep it at bay with excellent effectiveness:
  • Don't allow remote root login
  • Keep your list of allowed users as short as possible and practical
  • Avoid common login names (especially common first names) if possible
  • Make sure your users use strong passwords

If you keep to at least those precautions you just need to grep your messages log for the allowed user names periodically to make sure that there weren't any attempts on valid names. Then as a bonus your system will keep generating more log entries for you to post to slashdot journal entries as your observations of the attack attempts...

Re:The cloud attack isn't new (2, Insightful)

zigziggityzoo (915650) | more than 4 years ago | (#30107376)

I changed SSH to a nonstandard port and reduced attempts by 95%. Then I started a whitelist (hosts.allow) for SSH. That took care of the rest.

Re:The cloud attack isn't new (1)

damn_registrars (1103043) | more than 4 years ago | (#30109266)

I changed SSH to a nonstandard port and reduced attempts by 95%.

That is an option that has been suggested many, many, times. And indeed as you state it does work pretty well for most attempts. However it is not without trade-offs. I do a fair bit of traveling myself, and I sometimes don't know ahead of time what kind of equipment I might be using to access my home system; I would rather leave it on the standard ssh port.

Then I started a whitelist (hosts.allow) for SSH. That took care of the rest.

Again, for some people that would be a sub-par solution. If I don't know ahead of time what address or address block I might be logging in from next week, then a whitelist could result in me locking myself out of my own system when I need it most.

In short, your solutions may work well for you; and if so that is great. However some of us can't make use of those approaches practically.

Though in my case, I happen to enjoy watching the hack attempts fail. I find the resulting information interesting. I do after-the-fact armchair-quarterbacking on the logs to critique the botnets (or clouds) on how they failed to get into my system. I can also use the logs to see how their approaches are changing over time, to make sure that I am taking the correct precautions should they get more intelligent in their technique.

Re:The cloud attack isn't new (1)

Eunuchswear (210685) | more than 4 years ago | (#30115158)

I changed SSH to a nonstandard port and reduced attempts by 95%.

Sounds like made up numbers. You claim that one in 20 ssh login attempts was coming in on a non ssh port? Which port was it exactly?

Re:The cloud attack isn't new (1)

Daimanta (1140543) | more than 4 years ago | (#30107412)

I manage a server on my local university and I simply whitelist SSH access and all other ports are precisely controlled via whitelists too.

Users have basic access to standard ports like http and https but for any other port you need to be in a whitelist. Works like a charm and it allows me to see attacks very easily.

Re:The cloud attack isn't new (0)

Anonymous Coward | more than 4 years ago | (#30107680)

Run "John The Ripper" against your user list to detect poor passwords before someone else does.

Re:The cloud attack isn't new (1)

ceoyoyo (59147) | more than 4 years ago | (#30107922)

My logs show several different types of attack at the same time. One is the distributed guessing in the article, an attempt by a different host every ten seconds or so. There's another, from a single host name, that gets stopped in it's tracks because the address doesn't reverse map and yet another, from a variety of hostnames that do not reverse map.

Re:The cloud attack isn't new (1)

flyingfsck (986395) | more than 4 years ago | (#30109406)

Another effective protection is to change the default port of SSH from the standard 22 to something else. Even though a brute forcer could add a port scan to look for SSH elsewhere, the fact is that they don't.

Re:The cloud attack isn't new (1)

Bert64 (520050) | more than 4 years ago | (#30113864)

It's not worth the effort for them to do so...
Users could be using any port, meaning the attackers would now need to do 65534 times as much scanning to cover the same number of potential targets while only finding a handful more ssh services.
Also, the people who use non default ports will have explicitly done so and are therefore more likely to be aware of security issues and have stronger passwords, or other forms of authentication.

Re:The cloud attack isn't new (0)

Anonymous Coward | more than 4 years ago | (#30112012)

  • Make sure your users use strong passwords

In which alternate reality is brute-forcing RSA passwords possible? Do people there use roo>t accounts? Else, that single point is more than enough to protect your system.

What if I have a user called god, and they have a list that goes (root,john,ken,god,rms,...)?

Then their brute-forcing instead of taking more than the lifespan of our universe x nPossibleUserNames, it will take more than the lifespan of our universe x 4. I feel so insecure.

If you don't want to have the SSH server working overtime move it away from port 22 but as far as security goes it is only nPorts x better.

Re:The cloud attack isn't new (1)

TheEden (1213710) | more than 3 years ago | (#30142158)

Port forwarding is a great thing btw. I changed ssh port from 22 to something like 4254 or whatever, and that was really helpful in my case.

Re:The cloud attack isn't new (1)

damn_registrars (1103043) | more than 3 years ago | (#30143050)

No offense, but just here on slashdot I have seen at least a dozen suggestions to do that already. I have said before and I will say again that I'm not concerned enough about the attempts to change my ssh port; I actually rather enjoy parsing through the data generated by 100's of compromised systems failing in their attempts to access my home server. If I was runing a for-profit system and there was a genuine concern about accessibility problems coming from this then I would probably change my port just to slow down the traffic. However, as long as their methods remain the same I have nothing to worry about. And since I'm watching their attempts in real-time I can see if they ever improve.

How do these two parts relate? (1)

damn_registrars (1103043) | more than 4 years ago | (#30107062)

The summary starts by talking about jailbroken iphones getting rickrolled. It then goes on to discuss the growing hail mary cloud of compromised systems that are trying endlessly to find unsecured *nix boxes to log in to.

Re:How do these two parts relate? (1)

ceoyoyo (59147) | more than 4 years ago | (#30107946)

The iPhones are vulnerable not because of a software flaw but because of a default password that didn't get changed when the SSH server got started up. The hail Mary attempts are trying to exploit bad passwords.

The connection is tenuous but not entirely absent. It's also arguably a good point since a lot of press coverage of security issues focuses on software vulnerabilities.

Re:How do these two parts relate? (1)

Bert64 (520050) | more than 4 years ago | (#30113870)

Most likely the hail mary bots will have successfully compromised a few iphones with default passwords, tho their intrusion will be less obvious than a picture of rick astley.

Re:How do these two parts relate? (1)

ceoyoyo (59147) | more than 4 years ago | (#30123812)

You don't need a hail mary bot to compromise a well known default password.

Most likely a bunch of jailbroken iPhones are compromised, just like lots of routers with default passwords.

Translation for non-retards: (2, Insightful)

Hurricane78 (562437) | more than 4 years ago | (#30107230)

s/cloud/network/

There. Done it for ya. Was that so hard?

We should make a Greasemonkey script out of it. :)

Re:Translation for non-retards: (1)

wiredlogic (135348) | more than 4 years ago | (#30109366)

For the sake of tradition we should call it a Beowulf cluster. Imagine that.

Re:Translation for non-retards: (1)

Hurricane78 (562437) | more than 4 years ago | (#30110230)

Indeed. "Cluster" is a more fitting word. I just wrote the Greasemonkey script, and changed it to use that word: unCloudedThinking 0.1 [userscripts.org]
For the fun, I also throw in a replacement of "hacker" with "cracker" and some nice Unicode characters. Feel free to add more. :)

Re:Translation for non-retards: (1)

Hurricane78 (562437) | more than 4 years ago | (#30110298)

LOL. I just thought I had misspelled it as "unClusteredThinking", until I noticed that I already had the script installed. Just shows how well it works. ^^

Plaintext passwords over ssh (1)

m.dillon (147925) | more than 4 years ago | (#30107382)

Plaintext passwords over ssh have always bothered me. I always had a little program called 'sshlockout' which checks for failed password attempts via auth.log and lockout the IP, but that clearly won't work against something like this.

The only real solution is to disallow tunneled plaintext password logins entirely... simple enough, just set 'PasswordAuthentication no' in /etc/ssh/sshd_config (or wherever it lives). Problem solved.

Nobody should be using that sort of authentication any more anyway.

-Matt

DenyHosts is not security through obscurity! (0)

Anonymous Coward | more than 4 years ago | (#30107656)

It bans or denies connection to IPs that have repeatedly failed to login. That is real security, not obscurity. That being said, it is totally useless against today's threats.

Set sshd to listen on a non-standard port (0)

Anonymous Coward | more than 4 years ago | (#30108896)

I've try a number of things, ssh-anti-brute.pl worked well at least initially (when receiving multiple failed logins from the same destination address) but my drop chain was starting to get kinda lengthy.

I've recently moved sshd off port 22 and it seems to be doing the trick.

hairy business (0)

Anonymous Coward | more than 4 years ago | (#30109220)

Am I the only one who misread the title as "The 'Hairy Mail Cloud' is Growing"?

Disable Password Logins!! (0)

Anonymous Coward | more than 4 years ago | (#30116284)

Using an RSA or DSA Pubkey will effectively stop these..

Add on top of that a firewall rule blocking high volume of requests to your server (I have it set at 4 per minute :)) works well for this.

I *NEVER* setup an SSH server using password auth..

Oh, and of course TURNING OFF SSH on your iphone when not needed is ALWAYS a good idea.

Four simple things (1)

skeeto (1138903) | more than 4 years ago | (#30116338)

In my small amount of experience observing these types of ssh attacks, and even letting them into high-interaction honeypots to see what they do, there are four simple things that can be done to really cut down on the danger. Applying the first item, and any subset of the last three should be pretty good.

One, turn off root log in. Then they have to guess both a user name and a password. This would stop every single attack I have ever seen in my logs, since none of them have guessed a correct user account, let alone a correct password. It tries names like root, admin, apache, samba, so if you have these make sure they can't log in with ssh.

Two, use a decent password. A lot of people will tell you to take the inconvenient route of disabling password logins, saying they are dangerous. However, guessing over ssh is extremely slow, compared to a brute force attempt on a local machine. This means they really only get a chance to guess the most obvious passwords. If you trust all the passwords on the system to have decent strength, which is the case if, say, you are the only person logging into the machine, then you don't need to disable password logins.

Three, in case they did somehow figure out the name of an account that can log in, run DenyHosts. This will stop non-distributed attacks in their tracks, as they only get a few guesses.

Four, move the ssh port to something other than the default 22. I moved mine to 443 (https), since it's accessible from highly firewalled networks behind which I may be trapped, and people are already used to seeing encrypted traffic on that port. Ever since I did this, I haven't seen a single login attempt on my server other than myself. This means my server also wastes less time rejecting remote logins.

The ssh brute force bots I've seen are very stupid. I'm not really sure what the bot operators are doing. In my ssh honeypot where I have the root password set to "password", most bots won't ever guess it after thousands of attempts. Of the ones that do eventually guess the right password, most log out right away, then go right back to guessing root passwords again! Maybe trying to detect if it's a honeypot? Then there are ones that do log in and stop guessing, but they immediately log out and don't ever return (that is, no one has ever shown up and logged in without making guesses). Security researchers? Maybe marked my honeypot down for some future abuse? Maybe detected that it was a honeypot? I'm not sure what's going on with that.

I may be missing something (1)

k1773re7f (828030) | more than 4 years ago | (#30133992)

But it seems to me that key based authentication mediates this risk. Am I the only one that does this? What the heck does everyone think ssh is for? I use password authentication the very first time I access a server. I put my pub key there, then disable password authentication. My private key never leaves the thumb drive I wear around my neck. Being a CHL holder, it is very unlikely you'll get to that without leaving your DNA and most probably grey matter all over the place. Plus, my cat sets my passwords.
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...