
A Linux botnet is launching crippling DDoS attacks in excess of 150Gbps - testrun
http://www.pcworld.com/article/2987580/security/a-linux-botnet-is-launching-crippling-ddos-attacks-at-more-than-150gbps.html#tk.rss_all
======
pja
Rate limiting on password logins ought to be the default, not some optional
extra that only the security savvy know to install.

Defaults matter: not implementing rate limiting by default in sshd has left an
open door for these people to walk through & attack the net. Sure, you can
blame people for choosing poor passwords but, given the reality of the
millions of machines out there, as programmers we _know_ that some of them
will have poor passwords because people are people. Failing to code with that
expectation in mind is doing our users a disservice.

~~~
conceit
To make matters worse, the debian openssh .deb, that i installed to get the
client, configured an autostart for sshd, without asking.

~~~
dredmorbius
Debian's policy is that if you install a service, you intend for it to run by
default. Since services _aren 't_ installed by default, this is a fairly
defensible position, though it's been commented on many times.

It's possible and fairly straightforward to disable autostart of services
through either old-school SysV init or, I suspect, systemd.

Upshot: running complex systems _isn 't_ entirely trivial.

~~~
conceit
Yes, a desktop computer is a complex system, that's why I leave these not
entirely trivial plumbings to the system programmers. The downside of this is
the exploited systems that potentially everyone has to suffer.

------
Animats
_" Attackers install it on Linux systems, including embedded devices such as
WiFi routers and network-attached storage devices, by guessing SSH (Secure
Shell) login credentials using brute-force attacks._"

I'm seeing that - endless attempts to log in as root over SSH. It's apparently
aimed at random IP addresses - it was hitting a newly installed server that
wasn't even in DNS yet.

Here's what the attack looks like:

    
    
        Sep 30 00:06:39 s3 sshd[29144]: Failed password for root from 43.229.53.44 port 44450 ssh2
        Sep 30 00:06:42 s3 sshd[29185]: Failed password for root from 43.229.53.44 port 11229 ssh2
        Sep 30 00:06:42 s3 sshd[29188]: Failed password for root from 43.229.53.44 port 12106 ssh2
        Sep 30 00:06:44 s3 sshd[29185]: Failed password for root from 43.229.53.44 port 11229 ssh2
        Sep 30 00:06:44 s3 sshd[29188]: Failed password for root from 43.229.53.44 port 12106 ssh2
        Sep 30 00:06:46 s3 sshd[29185]: Failed password for root from 43.229.53.44 port 11229 ssh2
        Sep 30 00:06:46 s3 sshd[29188]: Failed password for root from 43.229.53.44 port 12106 ssh2
        Sep 30 00:06:48 s3 sshd[29201]: Failed password for root from 43.229.53.44 port 33446 ssh2
        Sep 30 00:06:49 s3 sshd[29212]: Failed password for root from 43.229.53.44 port 34570 ssh2
        Sep 30 00:06:50 s3 sshd[29201]: Failed password for root from 43.229.53.44 port 33446 ssh2
        Sep 30 00:06:51 s3 sshd[29212]: Failed password for root from 43.229.53.44 port 34570 ssh2
        Sep 30 00:06:52 s3 sshd[29201]: Failed password for root from 43.229.53.44 port 33446 ssh2
        Sep 30 00:06:53 s3 sshd[29212]: Failed password for root from 43.229.53.44 port 34570 ssh2

~~~
jasonoliveira
so fail2ban, disabling root logins, and key-based authentication are the
answer?

~~~
dredmorbius
A large portion of it, yes.

Limiting SSH to specific IPs or netblocks, and/or specifically _excluding_
those you're likely to never use, would also help cut down on the attack
surface. Not that hosts _within_ your perimiter don't get compromised, but
there are far fewer of them.

2FA including keyfobs is yet another option.

------
illumen
Get a range of ip addresses where you will log in from (your DSL address
ranges from home for example), and block all other ip addresses on that port.
You may want to add some other hosts you control to that whitelist as well as
a backup in case your ISP changes addresses. If you are the only one that is
supposed to access some ports, then block everyone else. (use last -a to see
all the places you've logged in recently to start making your whitelist).

You can also rate limit new connections to ssh depending on your use cases. So
even if your whitelist is beaten you limit the number of attempts.

Now add fail2ban, so that even at 10 new rate limited connections per minute
they get banned after X failed attempts.

Change the default port of ssh, to make it harder to find.

Remove password authentication, and make sure you have good secure keys.

You can also disable sudo, and root logins perhaps. As well you could try 2
factor auth, and perhaps move your keys to a secure(encrypted) USB drive.

But really, whitelisting who can connect to ssh in the first place will stop
99% of the automated brute force attacks, with all the rest stopping the
remaining 0.99%.

~~~
greyfade
If you configure your SSH server for a limited, secure set of ciphers and
HMACs, these automated attacks won't even get to the point of attempting
authentication.

[https://stribika.github.io/2015/01/04/secure-secure-
shell.ht...](https://stribika.github.io/2015/01/04/secure-secure-shell.html)

Since following the above guide, my auth log has been filled with nothing but
this:

    
    
        Sep 30 09:46:00 myserver sshd[74033]: fatal: no matching mac found: client hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,hmac-ripemd160,hmac-ripemd160@openssh.com server hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com [preauth]
    

Of course, I can't use old SSH clients to connect, but it's a good tradeoff,
IMO.

~~~
illumen
That's very good hint, thanks.

There's only been a couple of remote ssh exploits (that I'm aware of) and both
of them were stopped by white listing. If you can figure out your address
ranges, I think it still makes sense to white list. I guess also the bots will
catch up with modern ciphers.

------
nchelluri
To what end would people do this?

> The most frequent targets have been companies from the online gaming sector,
> followed by educational institutions, the Akamai team said in an advisory...

Doesn't seem like you'd ever make any money doing that. I suppose one
competitor could target another. Not sure if its a valuable thing to do. I
just dunno what the point of DDoS is besides ransom-type stuff.

~~~
tomtoise
Speaking from experience (Of getting hit, not running one of these services!)
- Gaming is a particularly juicy target, you can set up a basic front-end that
allows people to 'hit' certain IP addresses offline for x amount of time in
exchange for money. Its use is quite common in certain games like League of
Legends, CS:GO etc.

~~~
twoodfin
I assume to gain an advantage in PvP? If so, how does the attacker identify
the IP address they want to hit?

~~~
oddevan
OK, DDoSing and lagswitching has been a big deal in the Destiny community
recently, so here's what I know:

In Destiny, there's often a weekend-long PvP showdown with top-tier in-game
rewards. The game type is 3v3 with no matchmaking, so you must bring your own
team; the best rewards are for winning 9 in a row. If your team disconnects,
it counts as a loss (no cowards here!).

The way Destiny is set up, one player's console is considered the "host" and
all the other players connect to it. So if you or someone on your team (a
50-50 chance) is the host, you can see the IPs of everyone in the game by
monitoring network traffic. If not, you can still see the host's IP.

Find out IP of any opposing player, aim the botnet, fire. Boom. You've
instantly got a one-player advantage. Repeat ad nauseam. Suddenly going 9-0
isn't so daunting.

The worst part? Unlike other network manipulations, this one is a lot harder
for Bungie to prove. But you can bet they're working on it, and they aren't
shy about wielding the banhammer if they find cheating.

------
SixSigma
Calling it a Linux security issue is a bit erroneous, a weak Ssh password on
BSD will get you hijacked too. Or Osx, or even Windows!

~~~
ibmthrowaway218
Sure, but if the payload in this example is a Linux binary then it won't do
anything to an OSX/BSD/Windows machine.

If the payload is an interpreted script, or something that's compiled (if it
can find a compiler, etc) then it may be able to infect different OSes.

~~~
SixSigma
I wonder if Linux emulation on BSD / plan9 / cygwin will run it?

------
ChuckMcM
This is, in my experience, another interesting and unintentional side effect
of a free OS.

When the OS is free, the engineers I've talked to who have been tasked with
using it to implement their product are generally less experienced (which is
to say less expensive). And the entire impression I get is that there is some
cost minimization going on. Some sort of psychological trick that if its an
expensive OS you need some expert engineer to bend it to your will, but if its
free and seems to be everywhere, well you can hire an intern to do all your
integration, development, and testing.

~~~
drzaiusapelord
Maybe, but out of the box a typical linux distro is fairly unsecure. There's
no rate limiting of password guessing, no default password policy, no default
fail2ban behvaiors, usually no firewall enabled by default, no auto-updating
service on by default (or any at all), etc.

Some popular linux services are scary unsecure. Samba runs as root, which is a
security nightmare considering its that poorly implemented reverse engineered
crapfest with a long history of security problems.

Popular FOSS projects hosted on linux are bad too, like the recent massive
hole in Drupal and the endless Wordpress holes (I bet this recent one is WP
related). Not to mention heartbleed, shellshock, etc.

I don't think there's anything wrong with a cheap and common OS for junior
people to use, its just the OS needs to be shipped with sane defaults. This
will never happen in the typical world of FOSS for fear of breaking things and
"keeping things simple" and "you should know what you're doing." The problem
is many people don't know what they're doing, at least in terms of security.
An authoritarian attitude regarding security that would tie developer's hands
is the antithesis of FOSS culture.

I think the status quo of endless hacking is just the way its going to be
until everyone gets serious about security. What that means exactly is hard to
say, but shifting to some type of memory managed language (Rust perhaps?) and
sacrificing some performance for security are probably what its going to look
like. Even then, botnets aren't going to go away, but might be small enough
where they aren't able to do DDOS's like this regularly.

------
thatusertwo
My VPS had a default username/password called testuser, I never actually
noticed it existed till my server got taken over by some chinese bruteforce
attack. Every time I rebuilt the server that user account was created,
apparently it is part of the image used by my ISP.

My point is that many people probably have their servers taken over in a
similar way without even realizing it.

------
ryanlol
I'm pretty curious, why is this particular botnet noteworthy? There's a plenty
of kids on efnet capable of pushing that

------
elsjaako
What's the best way to make sure that your system isn't part of this?

~~~
Tobu
`PermitRootLogin = without-password` in /etc/ssh/sshd_config

Same thing for non-root: `AuthenticationMethods = publickey`

And when buying a router, buy something that will get regular security
updates, or where you can put OpenWRT.

~~~
bkor
From openssh 7.0 release notes:

    
    
      * PermitRootLogin=without-password/prohibit-password now bans all
        interactive authentication methods, allowing only public-key,
        hostbased and GSSAPI authentication (previously it permitted
        keyboard-interactive and password-less authentication if those
        were enabled).
    

It mentions that previously without-password it would still allow keyboard-
interactive logins. Should be fairly easy to fake for a botnet!

~~~
mirimir
I still prefer "PermitRootLogin=no".

------
lordnacho
How do the botnets come to be named? Is it named by whichever security firm
finds it?

~~~
ryanlol
There's no official rules on this, usually the botnets are named by their
developers and renamed by AV developers for marketing purposes.

This results in stupid shit like kaiten.c which is a *nix bot from 20 years
ago now being known (and detected) as "OSX/Tsunami".

This is actually harmful as it makes researching whatever infection you got
harder when every AV vendor decides to give a very well known malware a
different name.

------
z3t4
The biggest attack surface is probably cgi scripts (php etc).

