×

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 and the Lessons Learned

timothy posted about 6 months ago | from the not-so-full-of-grace dept.

Botnet 99

badger.foo writes "Against ridiculous odds and even after gaining some media focus, the botnet dubbed The Hail Mary Cloud apparently succeeded in staying under the radar and kept compromising Linux machines for several years. This article sums up the known facts about the botnet and suggests some practical measures to keep your servers safe."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

99 comments

HAHA !! FUNNY JOKE !! (-1)

Anonymous Coward | about 6 months ago | (#45045793)

You cannot be serious !! Linux owned ?? Never !!

Re:HAHA !! FUNNY JOKE !! (1)

Behrooz Amoozad (2831361) | about 6 months ago | (#45045853)

I havn't RTFA yet but it's always about dumb admins.

Re:HAHA !! FUNNY JOKE !! (-1)

Anonymous Coward | about 6 months ago | (#45046381)

Yes, admins who are so dumb that they run Linux.

Re:HAHA !! FUNNY JOKE !! (2)

GoblinKing (6434) | about 6 months ago | (#45047573)

Not quite. It's retarded admins that use password authentication on public facing SSH services. I have had a public facing SSH server for over 5 years now and it ONLY permits key-based authentication. I have NEVER had an unauthorized login. But them I'm an unpublished no-name IT guy who only follows those "best practices" that the so-called experts keep railing on about but don't seem to follow themselves.

I am certain you can also have a secure Windows server that has a public facing connection on the internet ... I've just never had the patience to try it.

Nothing you can do? (-1, Troll)

Anonymous Coward | about 6 months ago | (#45045915)

I think this article points to the fact the author is retarded.

There is nothing you can do he proclaims after exhausting ALL efforts! How about not permitting SSH at ALL except from known trusted source ip/subnets?!?!?!

Move your SSH port off from 22 TCP to 8222 or something high, since most automated brute force attackers won't spend time port scanning every host, they will go after the well known ports like 21, 22, 1433, 5060, etc (as evidenced by all the noise in my logs). Just use a DNAT rule in your FW.

Even better, use a VPN/IPSec concentrator approach where anything that access those resources on administrative ports must connect via the tunnel. Use really strong PSK's, or x.509 certs...

Then the obvious help for us all, don't permit root logins via SSH! How did this article even make it to Slashdot?

Re:Nothing you can do? (0)

Anonymous Coward | about 6 months ago | (#45046059)

It looks like you didn't read through TFA. The author did address higher port numbers. While they may not be attacked as much, they will still be attacked eventually. I have seen higher port numbers on a couple of my servers used for targeting SSH myself. Bad fix. Just puts off the inevitable.

As far as root logins being enabled... you would be amazed at how many "IT admin wannabes" never address killing off root access on SSH. I routinely turn this setting off on new client sites once to twice a month.

Re:Nothing you can do? (2)

HiThere (15173) | about 6 months ago | (#45046065)

Actually, not permitting root logins via SSH was one of the points he repeated several times. He also said, explicitly, "There's no safety in high port numbers anymore.". Perhaps he's wrong, but he did consider your point.

Personally, I don't feel very exposed, so I'm not willing to do much more than that, plus picking a secure password. I may have set things up so that no SSH logins are possible in any way, but I'd need to check again to find out. (I'm not much of an administrator, and my system isn't internet facing, but as I never use SSH except in a browser, there's no reason to allow it.)

But did you notice that not all of the attacks were attempts to log into root? (I don't know why anyone would replace root with admin, but apparently enough people do that that was a secondary target. If I changed the root account's name it would be to something like "doofus" or "notHere". (I.e., easy to remember and short, but not easily predictable. So you'd need a "dictionary attack" on the account name as well as the password.) I don't feel threatened enough, however, to bother with that.

Re:Nothing you can do? (0)

Anonymous Coward | about 6 months ago | (#45046183)

One of the reasons that "admin" may be highly targeted is due to its use on some customized distros. There was an asterisk distro, trixbox, that had an admin user account installed by default. While the password was changable, on installation I came across had a rather simple p$ssw0rd1 set by the original integrator. Access to a sip trunk and the security settings to boot would be a high commodity item.

Re:Nothing you can do? (3, Interesting)

icebike (68054) | about 6 months ago | (#45046303)

Not to mention several routers use admin and support ssh connections.

Router software virtually never gets updated.

Re:Nothing you can do? (1)

mjwalshe (1680392) | about 6 months ago | (#45046241)

not permitting direct login as root at all is a good idea - it what su was invented for (amongst other things)

Re:Nothing you can do? (1)

icebike (68054) | about 6 months ago | (#45046415)

not permitting direct login as root at all is a good idea - it what su was invented for (amongst other things)

Acually, on a new Freebsd install, out of the box, ssh to root was not permitted nor was su to root.
So on new installs, you have to pick your poison before you walk away from the console.

The rationale for not allowing su to root is because an attacker who (by what ever means) logs into some random account has a dramatically more advantageous position than one banging on the doors of ssh. That being said, unless you have convenient access to the console you are going to
have to choose ssh or su or something similar.

By far the easiest, and the one that most admins default to using is ssh with big keys, and don't allow password logins (or su to root).

(I make this claim without a shred of evidence to support it, other than knowing what I see among the Admins I work with. When an admin quits or moves on, its easy to remove his key from Authorized_keys but hard to remove a password from his head. I'm sure someone will school me on why this is wrong headed).

Re:Nothing you can do? (1)

Anonymous Coward | about 6 months ago | (#45046545)

This is one reason why people recommend sudo instead of su. The admin logs in as himself and gains root privilege using his personal password. There is no shared root password, so you only have to disable the old admin's account and sudo access. The root password can be set to something very unique/random and perhaps entered into a physical logbook that is kept under lock and key by the management, or just obliterated if you know you can recover systems through local physical access regardless of password.

We like the luks encrypted filesystems too, for a similar reason. We can enter multiple passphrases so that different attending admins can unlock an encrypted filesystem at boot using a personal passphrase, and these can be revoked individually, where we need encryption at rest for private data stores.

Of course there is a level of trust with admins no matter what. Did they install any backdoor software etc.? If you have to salt the earth every time staff changes, it is hard to get anything useful done...

Re:Nothing you can do? (1)

icebike (68054) | about 6 months ago | (#45046723)

This is one reason why people recommend sudo instead of su. The admin logs in as himself and gains root privilege using his personal password. There is no shared root password, so you only have to disable the old admin's account and sudo access.

The problem with sudo is that often the complexity of setting it up is time consuming when you have a fleet of admins for a large network, or even a small network with more than a couple admins. Not only do you have to kill the departing admin's account, you have to review the sudoers to make sure no other accounts crept in there as a root equivalent. Some middle management account it unlikely to ever discover they have sudo capability, so someone could simply add that account to sudoers as a root equivalent, steal a password or insert their public key into said person's authorized keys, and ssh in as job-Payroll, and su to root.

I like having only one door to guard.
SSH with key only access, no passwords, no su to root, no sudo, just seems more secure. Each admin has his own public key appended to authorized_keys for root in one place. Nobody has to actually know root's real password (or it can be kept in a vault as you mention).

So one line gets added to authorized keys for each admin, and one line gets deleted when they leave.

Re:Nothing you can do? (1)

ais523 (1172701) | about 6 months ago | (#45047159)

You have to do this no matter what privilege escalation method you use, because a rogue administrator might have left a random setuid binary around somewhere. Or has put a logic bomb in the script. Or something like that. Having only one door to guard is no use when the inside of the building carries a bunch of materials for building extra doors.

Re:Nothing you can do? (1)

leaen (987954) | about 6 months ago | (#45049231)

This is one reason why people recommend sudo instead of su. The admin logs in as himself and gains root privilege using his personal password. There is no shared root password, so you only have to disable the old admin's account and sudo access.

They recommend it as safer in theory.
In practice sudo is source of jokes like:
Q: H0w d0 I h4ck ubuntu?
A:
user
user
sudo
user

Re:Nothing you can do? (1)

mjwalshe (1680392) | about 6 months ago | (#45046753)

Sorry i meant to say only allow su to root only from the physical console

Re:Nothing you can do? (1)

icebike (68054) | about 6 months ago | (#45046803)

Sorry i meant to say only allow su to root only from the physical console

I didn't even know it was possible to limit su to a specific terminal. I suppose with SELinux it would be, or via pam.

Re:Nothing you can do? (1)

myowntrueself (607117) | about 6 months ago | (#45049167)

Sorry i meant to say only allow su to root only from the physical console

I didn't even know it was possible to limit su to a specific terminal. I suppose with SELinux it would be, or via pam.

I'm sure with SELinux you could permit su access only from the console (yours or the remote NSA one).

Re:Nothing you can do? (1)

fast turtle (1118037) | about 6 months ago | (#45048289)

the reason for seeing so many admin attempts is all those god damn cheap routers that have admin/pw setups by default.

Re:Nothing you can do? (0)

Anonymous Coward | about 6 months ago | (#45109685)

There was never any safety in using high port numbers for SSH.

That is security through obscurity at its worst.

Re:Nothing you can do? (1)

RightSaidFred99 (874576) | about 6 months ago | (#45046069)

Yeah, that's a great idea if you're a) a hosting provider or b) a security researcher. Ignore the problem and prevent your users from easily reaching their hosts.

You cracked the fucking case, Murder She Wrote's Angela Lansbury.

Re:Nothing you can do? (4, Insightful)

Noryungi (70322) | about 6 months ago | (#45046091)

I think this article points to the fact the author is retarded.

Considering the retarded author in question is someone who is a respected author on OpenBSD ''pf'', firewalls and security in general, I think your answer prove you are the retarded one.

Re:Nothing you can do? (0)

Anonymous Coward | about 6 months ago | (#45046283)

Doesn't matter what his reputation is; the article is banal, and the idea that he's basically written ten just like it and had them posted on slashdot is pathetic.

Re:Nothing you can do? (0)

Anonymous Coward | about 6 months ago | (#45046493)

Fully agreed, it's banal.
(I'm a different anonymous coward thatn the previous one)

Re:Nothing you can do? (1)

Anonymous Coward | about 6 months ago | (#45049901)

It's not just banal, it's insulting and contradictory. He takes time out of his busy writing schedule to pan port-knocking, says he could tell you how to do it easily but won't, and falsely equates it to just adding bits of complexity, when it in fact adds a time domain as well.

My favorite part is when he says:

There's nothing magical about TCP/UDP ports. It's a 16 bit number, and in our context, it's just another alphabet.

Like iterating over 16 bits multiplied by the password database is trivially fast. This is some real ivory tower shit, but I guess that's to be expected when you are hyping the botnet equivalent of the Model T.

Re:Nothing you can do? (0)

Anonymous Coward | about 6 months ago | (#45071253)

Who the fuck tries passwords against all the ports?

Are you retarded?

Re:Nothing you can do? (0)

Anonymous Coward | about 6 months ago | (#45047975)

OpenBSD fanboy then. Pfffft. Whatever.

Re:Nothing you can do? (1)

gmuslera (3436) | about 6 months ago | (#45046195)

Sometimes you have to access from other IPs, or don't have a known, fixed IP from where you could have to connect, or you could have to fix something when in a trip. I'd suggest a mix of several of those (no root access, non standard port, explicitely enabling in fw just the IPs you know that must enter by that service) but adding portknocking for the rest of the world (only if you could need to access from elsewhere), specially using Single Packet Authorization [cipherdyne.com] to prevent the chance of someone (specially 3-letters agencies) capturing/replaying how you entered there. And not just for ssh, every service that is not meant for the whole internet shouldn't be even visible for the rest of the world.

Re:NOT-Nothing you can do? (2)

icebike (68054) | about 6 months ago | (#45046617)

He actually mentions port knocking, but I think he mis-understands it. He makes a mathematical argument, without addressing the fact that the sequence of ports can be as long as you want. He seems to think port knocking is used to grant access, when most of the users I know who use it do so only to start sshd so that they can then log in via secure means.

But having to log in from a multitude of places is pretty common. Less common these days than in the past is having to log in from some random machine. Everyone has a cell phone or tablet or laptop. With those, you can store your private keys, and then totally disallow password logins via ssh.

You can then decide whether to allow root login via ssh or not as a separate issue.

Re:Nothing you can do? (0)

Anonymous Coward | about 6 months ago | (#45046709)

or you could have to fix something when in a trip.

I suggest you come down from your trip before attempting to fix the problem. God knows what kind of things you'll fuck up, otherwise.

Re:Nothing you can do? (2)

smash (1351) | about 6 months ago | (#45046731)

Or you could just set up key based authentication only. If you need to access devices that do not support key based auth, set up a server that DOES do key based auth as the only location they are accessible via SSH from.

Re:Nothing you can do? (2)

gmuslera (3436) | about 6 months ago | (#45047037)

That won't help if tomorrow someone finds a vulnerability in the openssh server that enables to bypass that (maybe something like this one from 2011 [exploit-db.com]). And that someone instead of announcing it worldwide (i.e. the NSA) start to use it to deploy their own backdoors in your server. Not having access to the service in the first place will avoid potential future exploits on it. Of course, could be exploits for the portknocker daemon, but as is simpler than the sshd (or any other service you have published that is not meant for the world) should be easier to check/audit it (only 2 vulnerabilities [cvedetails.com] were found so far that im aware of, and implies or already being logged in the system, or being successfully authenticated.)

And, btw, the Single Packet Authentication uses a certificate too to open the port for your IP. And then you can use your own ssh certificate or password to login.

yep, PermitRootLogin without-password (1)

raymorris (2726007) | about 6 months ago | (#45047501)

Yeah we always don't allow root login with a password, only with a key. In sshd config:

PermitRootLogin without-password

I wish the argument were named differently. I think some people have been scared that would allow roologin with no authentication . "require-secure-key" would more accurately describe what it does.

Re:yep, PermitRootLogin without-password (1)

smash (1351) | about 6 months ago | (#45048685)

Allowing any login with a password puts you at risk of a local privilege escalation.

true, but they brute "root", not "jeleay" (1)

raymorris (2726007) | about 6 months ago | (#45049677)

You don't see the bots trying a million passwords with user "jeleay", they are trying "root", so not allowing root via password is significant.

Re:Nothing you can do? (0)

Anonymous Coward | about 6 months ago | (#45046435)

If you're still allowing password-only auth AND you're not enforcing strong passwords, you deserve to get owned.

Anyone who's ever seen the logs after a dictionary attack already know how utterly dumb the average SSH brute force dictionary is. You literally have to as dumb as a bag of rocks to use a username and password that's likely to appear in any brute force dictionary.

Re:Nothing you can do? (1)

smash (1351) | about 6 months ago | (#45046761)

I'd go so far as to say if you are permitting password auth from the internet, you deserve to get owned. secure passwords or not. key based auth is available. use it. if your device doesn't support keys, block access to it from the internet. If you need to access it remotely, set up a secure launchpad type SSH server that does key auth and permit password based access only form that host. All this fucking about with cookies, state tables, and trying to match remote connection attempts is just dumping a turd in glitter to make it look better. it's still a turd.

Re:Nothing you can do? (0)

Anonymous Coward | about 6 months ago | (#45048443)

Yes. People who put trust in "password strength" limits don't seem to consider that you cannot prevent users from reusing passwords across multiple hosts and services to cut down the number of "strong" passwords they have to remember.

Password authentication opens you up to all kinds of attacks other than just brute force. If a password is divulged by any other trick on another service, the attacker can go around and try the same password on other servers including yours. When you have something like SSH known_hosts files for each user, it is trivial to discover a working set of target hosts to attack, after compromising a user's account somewhere. They might have used rainbow tables, keyloggers, or trojan horse attacks to get the initial password at a more vulnerable location.

Re:Nothing you can do? (1)

niftydude (1745144) | about 6 months ago | (#45046627)

Towards the end he actually mentions the solution: keys. Setting up sshd to not allow passwords solves the brute force issue pretty quickly. But he kind of glosses over it so that he can maintain his narrative.

Re:Nothing you can do? (1)

smash (1351) | about 6 months ago | (#45046721)

Use key authentication. Secure your private key. Job done.

Re:Nothing you can do? (1)

skids (119237) | about 6 months ago | (#45049057)

Problem with that is you cannot trust users to secure their keys any more than you can trust them to choose good passwords. Once you give them a keyfile they can change the password to whatever they want, or leave it naked.

Really if you want to excercise hard security, it should be both password and key. No, not password protected key, password stored on the remote host and require a key. What's truly retarded is the failure of most people including crypto software developers to see the use case for this, and endless arguments between the relative merits of one or the other.

Denyhosts (5, Informative)

mcelrath (8027) | about 6 months ago | (#45045955)

The solution to low-frequency brute force attempts is Denyhosts [sourceforge.net]. It just blocks any host with repeated failed login attempts. I've been using it for longer than I can remember, probably longer than this "Hail Mary" botnet has been in existence. I'm not sure why this author seems to have never heard of it.

Re:Denyhosts (5, Informative)

Anonymous Coward | about 6 months ago | (#45045997)

Another useful software for auto-banning bad accesses is fail2ban [fail2ban.org] which can also handle other services, like exim, vsftp, apache, etc.

Re:Denyhosts (3, Informative)

Noryungi (70322) | about 6 months ago | (#45046113)

I second that: DenyHosts is now mandatory on all the Linux servers I manage, and allows one to protect servers against that type of attacks with minimal effort.

Please note that the author did not mention Denyhosts since his servers run OpenBSD, which incorporates DenyHosts functionality through ''pf'', its packet filter/firewall software (see the brute-force configuration of pf for more details).

iptables -m limit (1)

SgtChaireBourne (457691) | about 6 months ago | (#45049415)

Please note that the author did not mention Denyhosts since his servers run OpenBSD, which incorporates DenyHosts functionality through ''pf'', its packet filter/firewall software (see the brute-force configuration of pf for more details).

You can do the same with iptables on Linux using the module "limit". See the manual page for "iptables-extensions" for the details. DenyHosts may have it's good points, but mostly it just complicates things. There is already a lot of functionality in the packet filter that you can use, whether on Linux or BSD.

However, what I see now, in contrast to years ago, are slower paced attacks. These come in steadily but at a rate that just passes under the threshold. One of these days I ought to look at what is blocked to see if it's just the slow ones getting through or if all the probes are now timed that way.

Re:Denyhosts (0)

Anonymous Coward | about 6 months ago | (#45046333)

History bound to repeat itself. Somehow everyone thinks that they are the first one to be hit with brute force login attempts and article needs to be written about it. This problem is a old as internet itself and was solved multiple times to date. Denyhosts is a very simple way to solve it and will work around the authors issues with configuring firewall. The autor seems to be most familiar with bsd pf so he tried (unsuccessfully) to solve the issue using that tool. To a guy with a hammer everything looks like a nail.

Re:Denyhosts (1)

jedidiah (1196) | about 6 months ago | (#45046719)

Even before fail2ban came along, it occured to me to code up something roughly equivalent to it. It was a rather sad looking shell script but it did the job. This is something so un-new that there are pre-packaged workarounds for it now.

Re:Denyhosts (0)

Anonymous Coward | about 6 months ago | (#45046393)

I think you missed the point, the purpose of a 'low intensity' botnet, is to stay below the threshold that denyhosts uses (i think the default is 5 failed attempts in 20 minutes). So 1 attempt every 30 minutes never trips the alarm.

Re:Denyhosts (1)

Tailhook (98486) | about 6 months ago | (#45046759)

(i think the default is 5 failed attempts in 20 minutes)

Ubuntu server 10.04 LTS from April, 2010 has this default:
AGE_RESET_VALID=5d

So 7200 minutes, not 20, in the case of my unmodified defaults.

So I think you're wrong about staying below the threshold of denyhosts. I've collected about 2400 IP addresses in /etc/hosts.deny since 2010. I suspect all of us that pay attention to log files and set up denyhosts back then have collected approximately the same set of 2400. Incidentally, about 50% of those IPs are Chinese, the last time I looked.

As for the article I had the same thought as the GP; this `problem' has been solved for a long, long time. His analysis of the attempt pattern is mildly interesting, but many of us defeated that stuff years ago.

I don't advise that anyone else do as we have done, however. If everyone starts reading log files and defending themselves the attackers will stop being simple minded and try harder.

"Please, feed yourself to the lions!" (0)

Anonymous Coward | about 6 months ago | (#45056877)

I don't advise that anyone else do as we have done, however. If everyone starts reading log files and defending themselves the attackers will stop being simple minded and try harder.

"Be a good sport and take the fall for the herd", eh? :-)

Re:Denyhosts (4, Informative)

module0000 (882745) | about 6 months ago | (#45046517)

If you like DenyHosts - look at fail2ban. It has all the functionality of the older DenyHosts project and more. You can ban based on more than failed ssh logins - but any type of logfile imaginable. With customized responses to X login failures per Y time units for Z service. You'll find it in the repo's for all debian/rhel based distributions.

Re:Denyhosts (0)

Anonymous Coward | about 6 months ago | (#45047915)

I've used them both and they're great. Right now I'm using pam_shield - thoughts? Experience?

Re:Denyhosts (0)

Anonymous Coward | about 6 months ago | (#45047979)

I've been using it for longer than I can remember, probably longer than this "Hail Mary" botnet has been in existence. I'm not sure why this author seems to have never heard of it.

Well, considering he knows about PF firewalls, could it be because he's an avid OpenBSD user? I mean, surely not a fanboy, but maybe he doesn't get out much...

Re:Denyhosts (1)

Dr.Dubious DDQ (11968) | about 6 months ago | (#45050267)

If I remember correctly, denyhosts relies on the old /etc/hosts.deny tcpwrappers functionality, which I thought had been deprecated for years now. (Still works in ancient "enterprise" distributions of course, up to at least RHEL5.x though). I see a few other mentions of fail2ban, which in my mind is the successor to denyhosts - it uses iptables directly to accomplish the same thing.

Low intensity ssh brute-forcing. (5, Insightful)

foobar bazbot (3352433) | about 6 months ago | (#45045957)

This is about the low-intensity password brute-forcing via ssh that's been going on for years -- the only difference between this and any other password brute-forcing via ssh is that fail2ban and such scripts are ineffective, because the attempts are so low-frequency that it's practically impossible to distinguish them from users fumbling their passwords.

The simple solution is to disable password authentication for all users, and make them use keys -- this renders you 100% safe from this botnet. If that's infeasible, be damn sure you've disabled password authentication for root (i.e. "PermitRootLogin no" or "PermitRootLogin without-password" if you still want key-based root logins). If you do allow password logins for any or all users, enforce strong password requirements.

Re:Low intensity ssh brute-forcing. (0)

Anonymous Coward | about 6 months ago | (#45045989)

While this is good advice I would add (from personal experience) "Don't try it for users that are behind a NAT interface !!" - SSHD then can't tell which user's key it should be checking.

Re:Low intensity ssh brute-forcing. (1)

tibman (623933) | about 6 months ago | (#45046559)

you still have a login name, just using a cert instead of a password.

Re:Low intensity ssh brute-forcing. (1)

Anonymous Coward | about 6 months ago | (#45046119)

low-intensity bruteforcing is not dangerous - therefore it does not matter that fail2ban doesn't help. Basically, all fail2ban does is turning a fast bruteforce attack into a low-intensity one anyway.

Tricky passwords is enough - they can't guess them in a lifetime with a low-intensity attack. Do not force people to change passwords (except if there ever is a security breach), that makes it much easier for them to put up with really long passwords. And if you live in a part of the world where your keyboard has more than ascii - stick some non-ascii in your password. Or even the username. This locks out english-centric bruteforcers. And if they try to adapt, their bruteforcing will be that much slower due to the much larger alphabets available.

To trip them up further - if they log in to a nonexisting account, pretend that the password works. Send back a greeting string as if the login succeeded, only to have usage "fail" on something banal - segmentation fault in the shell, or a faked unreliable internet connection. The botnet will think it has a correct password for an account, but will forever fail to utilize it. Maximum frustration!

Re:Low intensity ssh brute-forcing. (5, Interesting)

foobar bazbot (3352433) | about 6 months ago | (#45046355)

low-intensity bruteforcing is not dangerous - therefore it does not matter that fail2ban doesn't help. Basically, all fail2ban does is turning a fast bruteforce attack into a low-intensity one anyway.

Yes, of course -- what's dangerous is not the low intensity attack itself, but that they command enough bots to make low-intensity attacks have a reasonable chance of success against lousy passwords. And that's only dangerous in combination with the fact that you're permitting users to have lousy passwords.

Tricky passwords is enough - they can't guess them in a lifetime with a low-intensity attack.

Amen, brother. That's absolutely enough -- if you enforce it.

The main reason I suggested key-based auth first is because some fools' idea of "make sure users use strong passwords" is to force users to change their passwords frequently, and tell them to use strong passwords (e.g. not derived from a single english word), and maybe enforce silly requirements such as "must have at least one letter and one numeral"; this inevitably results in "password1" the first month, "password2" the next month, and so on.

Re:Low intensity ssh brute-forcing. (1)

Zero__Kelvin (151819) | about 6 months ago | (#45047221)

One thing that he seems to be assuming is that the botnet is a bunch of Linux boxes. I think that is a pretty poor assumption. Nothing stops a botnet of compromised Windows machines from trying to SSH into a Linux machine. Also, he runs BSD, so why did he not say "Linux, BSD, and Other OSes"? I'm sure it wasn't for sensationalism. Also why is he calling it a botnet? Isn't a botcloud ;-)

Re:Low intensity ssh brute-forcing. (1)

_Sharp'r_ (649297) | about 6 months ago | (#45048481)

why did he not say "Linux, BSD, and Other OSes

Maybe because the default setting in BSD [freebsd.org] is
          PasswordAuthentication = no
and
          PermitRootLogin = no

Could that be why he didn't mention the botnet logging into to lots of BSD boxes with password authentication?

Re:Low intensity ssh brute-forcing. (1)

Zero__Kelvin (151819) | about 6 months ago | (#45052333)

"Could that be why he didn't mention the botnet logging into to lots of BSD boxes with password authentication?"

No. No it could not. The first reason is because it is disingenuous to imply that the Hail Mary Cloud is succeeding in breaking into "lots" of Linux boxes. It is also the default on every decent Linux distribution out there that root logins via ssh are not allowed. Also, as you said, it is the default setting. Perhaps you were unaware of the word default and what it means, because the last time I checked you could change a default setting. Correct me if I'm wrong..

Re:Low intensity ssh brute-forcing. (1)

_Sharp'r_ (649297) | about 6 months ago | (#45053159)

This is really one of those literal RTFM situations...

Notice I was talking about password authentication?

As noted above, PasswordAuthentication defaults to no on FreeBSD.

How about some popular Linux flavors?
Ubuntu? Debian? Fedora?
Those are the top 3 in usage, right? So I checked those and guess what?
PasswordAuthentication defaults to yes.

So yeah, could that be why he didn't mention the botnet logging into to lots of BSD boxes with password authentication?

Correct me if I'm wrong..

Perhaps you could bother to read the whole comment you are replying to and reply in context of what is being discussed? Consider yourself corrected.

Re:Low intensity ssh brute-forcing. (1)

Zero__Kelvin (151819) | about 6 months ago | (#45053269)

"This is really one of those literal RTFM situations..."

No. It's really more of a "You're a troll who is misrepresenting the facts" situations. I did read what you wrote, and as I said: No!.

"PasswordAuthentication defaults to yes."

Who cares what PasswordAuthentication defaults to, when PermitRootLogin is no? The chances that they will brute force a root account password with "PermitRootLogin no" is just as equal to zero. Furthermore, with PermitRootLogin yes the chances are also zero if a strong password is used. Finally, it is disingenuous to use Ubuntu as an example distribution since Ubuntu is insecure, and was never designed as a real Linux distribution. It is aimed at the "Hey, I'm a Windows user and I'd try Linux but it's too hard to open a console and su to root!!!" crowd

"So yeah, could that be why he didn't mention the botnet logging into to lots of BSD boxes with password authentication?"

Your inability to understand the meaning of the word default is hereby officially acknowledged!

Re: Low intensity ssh brute-forcing. (0)

Anonymous Coward | about 6 months ago | (#45054267)

You realize this botnet is attempting non-root users, too? and that it seems to propagate by dumping a binary in /tmp/ of compromised systems, which doesn't require root access on a lot of Linux systems. So with root logins disabled, it can still have a fraction of success (obviously it's harder to guess both username and password correctly, but OTOH root passwords are likely to be stronger than other passwords, so it's not clear how much less success), but with password authentication disabled, it has no success.

Therefore, OpenBSD boxes in a default configuration won't be compromised, Linux boxes from many common distributions in a default configuration will be compromised. Yeah, some Linux admins will secure things tighter, and some BSD admins will loosen things up, but it's not at all unreasonable to assume that most boxes of either type will be running the default values of the relevant settings.

Re:Low intensity ssh brute-forcing. (1)

_Sharp'r_ (649297) | about 6 months ago | (#45055867)

You're totally off topic. If anyone is a troll, it's you. Sadly, it appears you're just an idiot who spouts off without even knowing the basics of what is being discussed.

The botnet being discussed tries to login with a series of usernames over time with each member of the botnet attempting to guess a different password for each username in the series.

So PermitRootLogin is irrelevant to defending against it, other than presumably it might eventually try root among all the other usernames it's attempting.

Having PasswordAuthentication set to no instead of yes so that it can't guess the password of a user it manages to guess the username for would be the only viable defense to the specific botnet that is under discussion.

If you have any honor at all, you'll now go read the article and then come back and admit your mistakes. I'm not holding my breath. Even an AC knows more about what we're talking about here.

Re:Low intensity ssh brute-forcing. (1)

Zero__Kelvin (151819) | about 6 months ago | (#45057727)

It's no mistake. In both cases a system with proper security (i.e. strong passwords) has no chance of being compromised. Period. Your argument is: If the system admin is a moron then they have a very slim chance of getting in, but it is still a chance." You can say that for both BSD and Linux. There is no fundamental difference. Even if I have a user whom I allow to set a password that isn't strong only that user will be compromised. They can try their local priv exploit all day; it isn't going to work. Whereas a local priv exploit will almost certainly work on every BSD box when they succeed in logging in to a non-priv'd account (yes, I know the default would have to be changed) the heterogenous nature of Linux makes it virtually impervious to non-targeted local priv escalation attempts.

If you have any honor at all you will just admit that a system run by an incompetent admin may be vulnerable, and one run by a competent admin regardless if it is BSD or Linux, is not.

Re:Low intensity ssh brute-forcing. (1)

_Sharp'r_ (649297) | about 6 months ago | (#45058087)

Now that you've changed your tune, it's obvious you realize you were wrong all along. Of course, with your posting history on other things, that's not much of a shocker, is it? You have a lot of these "misunderstandings".

The botnet doesn't need a privileged user. It can generally use the machine's resources for whatever it desires, including making outgoing connections to compromise more hosts, with just a non-privileged user.

Re:Low intensity ssh brute-forcing. (1)

Zero__Kelvin (151819) | about 6 months ago | (#45058991)

I didn't change my tune you frigging troll. I never said it needs a privileged user. I said it will never compromise an actual system, Linux or BSD, unless it is insecure. Your ridiculous claim is that BSD is magically secure and Linux is by default insecure. Just admit that you are a troll and a moron and move on with your life. Plonk.

Re:Low intensity ssh brute-forcing. (0)

Anonymous Coward | about 6 months ago | (#45064923)

Wow, Zero__Kelvin, you really put a lot of time and effort into your trolling, don't you?

Re:Low intensity ssh brute-forcing. (1)

illtud (115152) | about 6 months ago | (#45076969)

I'm just posting to say I haven't seen:

>... Plonk.

For years. As in 15, at least. Wow.
Note that this is judgement-neutral, I'm just saying 'hi' to once-familiar term, this is judgement-neutral!

Re:Low intensity ssh brute-forcing. (0)

Anonymous Coward | about 6 months ago | (#45046663)

(...) fail2ban and such scripts are ineffective, because the attempts are so low-frequency that it's practically impossible to distinguish them from users fumbling their passwords.

I'm sorry but that's just nonsense. Ordinary users don't often fsck up their login 3 or 4 times in a row. The boxes in the HM cloud will and so the operators will fairly quickly run out of usable host for their brute force attack. How's that ineffective?

I agree on you other points though.

Re:Low intensity ssh brute-forcing. (1)

HybridST (894157) | about 6 months ago | (#45047013)

I sure as hell... I mean, ordinary users, not I of course, but normal users certainly DO fsck up my seldom-used passwords... I mean their seldom... DAMMIT!

Re:Low intensity ssh brute-forcing. (1)

foobar bazbot (3352433) | about 6 months ago | (#45047127)

(...) fail2ban and such scripts are ineffective, because the attempts are so low-frequency that it's practically impossible to distinguish them from users fumbling their passwords.

I'm sorry but that's just nonsense. Ordinary users don't often fsck up their login 3 or 4 times in a row. The boxes in the HM cloud will and so the operators will fairly quickly run out of usable host for their brute force attack. How's that ineffective?

OK, in fairness, "practically impossible" was way too strong a wording -- calling it "nonsense" is exactly right. What I should have said is that the commonly deployed algorithms can't be made to reliably distinguish them by simply tweaking the parameters (time to remember, and allowed number of fails in that time). Better algorithms absolutely could block these, eventually, with no risk of bothering legitimate users. Specifically: distinguish between legitimate usernames (or conceivably-fumbled usernames) and names the botnet is guessing -- although if you have a username matching a known botnet guess (inevitable for e.g. root), deal with that accordingly. Instead of dropping further attempts by every known botnet member, let them proceed far enough to log what usernames they're trying now, and add those to the list we're watching out for...

But the botnet being discussed doesn't let one bot "fsck up their login 3 or 4 times in a row" -- they do a round-robin thing so you won't see the same one again for quite a while, and that one won't be trying for the same user account. Even with better algorithms, the risk is that, if you have weak enough passwords, a few thousand machines each trying once or twice could get one of them a hit first- or second- try by that specific bot -- so if you manage to ban them on the third fail, there's a non-negligible chance of them owning an account. IIRC fail2ban does allow to (but by default doesn't) join a distributed detection network; in combination with better algorithms as discussed above, this sort of distributed approach will let you do better.

Of course, the best answer is "don't permit weak passwords" -- either by disallowing passwords, or by enforcing realistic password strength requirements... but you're very correct that it's possible to do some automated detection and blocking. Mea culpa.

Funny quote from article (1)

Heretic2 (117767) | about 6 months ago | (#45045993)

"I'm not really in a mind to offer help or advice to the people running those scripts, but it might be possible to scan the internet from 255.255.255.255 downwards next time."

Yes, start with all the multicast addresses. That'll work for them! ;)

NSA Methods for FF infiltration ? (0)

JackDonovan (3381881) | about 6 months ago | (#45046089)

I am running FF 18.0.2 here and was in the process of advising somebody that proper symmetric crypto (IPSEC in this case) was actually providing REAL security, if the key is carefully transported so that they cannot copy it at some kind of police checkpoint (airport). Then I got a little crash of FF (with JS enabled). loading the core file and doing a stacktrace yielded:

oading symbols from /usr/X11R6/lib/libXss.so.5.0...done.
Loaded symbols for /usr/X11R6/lib/libXss.so.5.0
Reading symbols from /usr/local/lib/libsoftokn3.so.33.0...done.
Loaded symbols for /usr/local/lib/libsoftokn3.so.33.0
Reading symbols from /usr/local/lib/libnssdbm3.so.33.0...done.
Loaded symbols for /usr/local/lib/libnssdbm3.so.33.0
Reading symbols from /usr/local/lib/libfreebl3.so.33.0...done.
Loaded symbols for /usr/local/lib/libfreebl3.so.33.0
Reading symbols from /usr/local/lib/libnssckbi.so.33.0...done.
Loaded symbols for /usr/local/lib/libnssckbi.so.33.0
#0 0x03964c2d in kill () at <stdin>:2
2 <stdin>: No such file or directory.
in <stdin>
(gdb) bt
#0 0x03964c2d in kill () at <stdin>:2
#1 0x039d0826 in raise (s=11) at /usr/src/lib/libc/gen/raise.c:39
#2 0x06e79f8d in XRE_InstallX11ErrorHandler ()
from /usr/local/lib/firefox-18.0.2/libxul.so.37.0
#3 <signal handler called>
#4 0x08542420 in JS_DefineProfilingFunctions ()
from /usr/local/lib/firefox-18.0.2/libxul.so.37.0
gdb in realloc(): error: bogus pointer (double free?) 0x7462
Abort trap (core dumped)

We really need to record all bytes txmitted and then review the dumps when we get core files. Forward to Kaspersky for analysis. Stick it to them.

Executive summary (5, Informative)

Anonymous Coward | about 6 months ago | (#45046257)

"I've managed to get my name on slashdot a lot"

"Use key auth instead of passwords"

"My references are my own blog posts"

There's nothing interesting to see here. Don't allow password logins to your system, because you can't trust people to use good passwords. It's 2013, there's no cake for pointing this out.

Dumb *BSD guy (0, Troll)

Anonymous Coward | about 6 months ago | (#45046263)

I am writing this on a BSD machine, but this guy is a disingenuous SHILL. If you have a computer connected to the interwombs, just USE A FUCKING STRONG PASSWORD: NOT: Anna123, PeterPan, Fuckme, dumbass, microsoft, sleaze, shill, whore, foss USE: 767.211.856.543. Too much work for you ? Then don't have an ssh port open on the interwombs. Please don't reproduce either, because you are simply too retarded to get the obvious fix (strong password).

Re:Dumb *BSD guy (1)

smash (1351) | about 6 months ago | (#45046781)

No. If key based auth is available (for SSH, it is) do not allow password auth.

LAWL I THOUGHT MACS DON'T GET VIRUSES!!!! (-1)

Anonymous Coward | about 6 months ago | (#45046491)

oh wait, this article is about Linux....

simple fix (1)

Gravis Zero (934156) | about 6 months ago | (#45046679)

STOP USING PASSWORDS FOR AUTHENTICATION! why not only allow connections in authorized_keys??? if you feel so inclined, add a password on top of the authorized key.

there is only so much programmers can do to make it user friendly and secure.

Re:simple fix (1)

smash (1351) | about 6 months ago | (#45046793)

The passwords in keys are for a different purpose - they are in case the key gets stolen. You should password protect your keys unless they are single purpose, limited privilege for remote access by non interactive scripts.

Agree to simple fix, but this is OLD (1)

marienf (140573) | about 6 months ago | (#45047011)

Ow please.. This is so old.. haven't allowed pasword logins in the last decade or so..
Why on earth would anyone have allowed password logins for the last 10 years? Or: Ever?
Someone that's savvy enough to get a shell account is savvy enough to use a key pair.
It's 2013. I mean, seriously, PASSWORDS? for SSH?? You must be joking.

-f

Re:Agree to simple fix, but this is OLD (0)

Anonymous Coward | about 6 months ago | (#45047419)

You must be joking if you feel there's no application ever that would require this. I work for a relatively small startup. Our servers are generally protected by your run-of-the-mill, 20-character long, randomized passwords which are not stored on local machines by the what, 3 of us who have access. Everything's protected by fail2ban, but not having a 24/7 support staff, it's quite probable that the 1/3 of us who responds to a serious issue with the servers won't be on a device that's keyed and can't rouse the others.

We're holding literally no privileged information on public-facing servers or those accessible via public-facing. The likelihood that someone will have to do some patch-up work from an unknown interface (it's happened a good half-dozen times in 2 years) trumps a security threat that's even more potent via passwordless key than via the security-via-obscurity password storage we use.

TL;DR - I agree in principle, but nearly universally, if you exclaim "only idiots would do x" in IT, you're probably thinking about it wrong.

Re:simple fix (1)

fa2k (881632) | about 6 months ago | (#45047503)

Keys are good for security, but random passwords of 8 characters (and even less) are totally safe against online brute force attacks. Passwords are frequently needed when new systems are installed. After all, you can't go moving keys around on an USB stick every time a new host is set up.. Using passphrases on the SSH keys is fine, but if we neglect the security of the keys themselves, it turns an online attack into an offline attack: the keys are much easier to brute force, and it can be distributed

This is not a new game (2)

damn_registrars (1103043) | about 6 months ago | (#45046827)

I've seen these on my own home system going back at least as far as 2008 [slashdot.org]. That said, i don't think he has their entire plan correct. The writer's statement

Pick a host from our pool, assign a user name and password (picked from a list, dictionary or pool)

Implies that each host will, from a predefined directive, try certain user names. I have seen ones better coordinated than that, where they are going through the list alphabetically across a large number of systems. To me this implies a tighter degree of central control on the attack.

That said, the list of users that they try are almost always first names only, aside from the usual collection of system names (root, toor, admin, oracle, games ...). Any sane admin has root disabled for ssh access, in particular, so the number of attempts they make on that is irrelevant; and the rest shouldn't be allowed much of anything, ever.

At any rate, my point remains: this is an old game they've been doing. Interesting that we now have assigned a name to the botnet but otherwise not really news. It would be interesting to know more about the systems that are part of it, but they mostly come from the usual collection of countries and hence your likelihood of getting useful information on them is pretty well zero.

Re:This is not a new game (0)

Anonymous Coward | about 6 months ago | (#45047433)

I've always enjoyed hanging out at home with a tail -f going on my FTP logs. Probably a good 6000+ login attempts, nearly all for "Administrator" to an anon-only Pure-FTPd server, nearly all from China. I should really set an account for that and have a bit of fun.

Some more guidance on setting up SSH (1, Informative)

dweller_below (136040) | about 6 months ago | (#45046839)

Here is the guide we provide to the SSH users at our University: https://it.wiki.usu.edu/ssh_description [usu.edu]

Some of the major points:

  • We try to use multiple overlapping security layers to protect SSH:
  • * The firewall limits the vulnerable scope of SSH to a few trusted hosts.
  • * The firewall can also be used to prevent credential guessing by rate-limiting connections to the SSH port.
  • * The SSH Port is treated as a shared secret. Only interesting, targeted attacks find the SSH server.
  • * The SSH server should not allow known usernames including root. The attacker must find a username.
  • * The admin is trained to create good passwords for his usernames.
  • * SSH users are taught to verify the identity of their systems when they first connect.
  • * System admins must regularly review the activity of their SSH servers.
  • * USU IT Security monitors all SSH connections, including ones on non-standard ports. We follow up on interesting connections.
  • * USU has SSH Honeypots that help us respond to SSH attack.

Logs are cut off in blog (0)

Anonymous Coward | about 6 months ago | (#45047051)

I guess this guy never reads his own blog posts. Otherwise he'd see that the log files that he's included are cut off after about 59 characters making them useless for the reader.

Re: Logs are cut off in blog (0)

Anonymous Coward | about 6 months ago | (#45049303)

Bob Loblaw's Law Blog. Fin.

"what to do: keep your system up to date"... (0)

Anonymous Coward | about 6 months ago | (#45049383)

Sorry but what a (looong) and useless article. Thank you captain obvious.

But, but, but Open Source.... (0)

Anonymous Coward | about 6 months ago | (#45057573)

This is impossible. Everyone knows that Linux is so great because this can't happen. It is open source and there are no holes that allow thing like this because of the "many eyes" thing. This only happens on WinBlow$ boxes. ~

Re:But, but, but Open Source.... (0)

Anonymous Coward | about 6 months ago | (#45060511)

You are an idiot, must be Hairyfeet posting as AC.

This has nothing to do with software flaws and everything to do with weak passwords.
Check for New 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...