10 ms·
A Linux botnet is launching crippling DDoS attacks in excess of 150Gbps
- elsjaako 11y agoWhat's the best way to make sure that your system isn't part of this?
- gameboy24 11y agohttps://www.stateoftheinternet.com/downloads/pdfs/2015-threat-advisory-xor-ddos-attacks-linux-botnet-malware-removal-ddos-mitigation-yara-snort.pdf https://www.stateoftheinternet.com/downloads/pdfs/2015-threa... Read Section 7.0
- doguozkan 11y agoI think monitoring your outgoing traffic would give you a clue. Also if what I read on Ars is correct, this botnet preys on weak root passwords, so disabling remote root or using keys would be great ways to protect yourself against this botnet.
- mirimir 11y agoThis! And also, in sshd_config, disable password-based authentication. But first, make sure that key-based authentication works ;)
- deleted 11y ago[deleted]
- digi_owl 11y agoMakes one ponder the issue of monoculture...
- johnchristopher 11y agoSorry, I tripped up.
- johnchristopher 11y agoI garbled my post :( Pull the plug /s Don't allow password-based SSH access. https://blogs.akamai.com/2015/09/xor-ddos-threat-advisory.html https://blogs.akamai.com/2015/09/xor-ddos-threat-advisory.ht... https://isc.sans.edu/forums/diary/XOR+DDOS+Mitigation+and+Analysis/19827/ https://isc.sans.edu/forums/diary/XOR+DDOS+Mitigation+and+An... example (first Google result)
- Tobu 11y ago`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 11y agoFrom 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 11y agoI still prefer "PermitRootLogin=no".
- ATsch 11y agoHowever unrealistic it is, I still wish that open source Projects would agree on what to call things. The /etc/sudoers NOPASSWD and sshd without-password sound like the same thing, but are far from that. I feel like they could have named it better.
- eikenberry 11y agoSudoers NOPASSWD means you don't have to type the password for that feature. Sshd without-password means passwords are disabled. Not the same thing.
- gingerlime 11y agoAs others mentioned, prevent password logins. I also recommend fail2ban[0] for completely blocking IPs after detecting repeat failed access attempts. [0] http://www.fail2ban.org/ http://www.fail2ban.org/
- IE6 11y agoFail2Ban is great - I've used it for more than just blocking brute force attacks on ssh (although a real security expert might say this is the wrong tool to use).
- gingerlime 11y agoYep, I also use it to detect repeat errors on our own application logs and block offending IPs. Fail2ban has a reasonably easy to tweak detection and blocking rules, plus lots of available ready-made ones that do the job. If you're comfortable with regular expressions (which most people on HN probably are), then it's really straight-forward to write your own rules. The only problem I encountered with it is when you start it up and you have a huge amount of data in your log files. It can cause 100% cpu usage for a long time until it digests the whole thing...
- upofadown 11y agoIf for some bizarre reason you allow remote root logins over ssh be sure that that password is as strong as possible. Machine generated random strings are good, at least 12 characters to be sure. If you turn off root logins but still allow user logins the remote attacking system will have no way to detect that fact and will still attempt to brute force you.
- tedunangst 11y agohttp://bartblaze.blogspot.com/2015/09/notes-on-linuxxorddos.html http://bartblaze.blogspot.com/2015/09/notes-on-linuxxorddos....
- skarap 11y agoUse a good password.
- Animats 11y ago"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
- LoSboccacc 11y agosame I saw on my servers, has been going on for more than two months. I disabled all ssh password accesses ever since. they're also testing rhosts, probably to jump from one compromised box to another, so I disabled that as well.
- broodbucket 11y agoIs this on a well-known cloud hosting provider? I assume so, unless "s3" indicates something else. There have been attacks against known cloud hosting IP ranges for a long time. I'm constantly getting attempts on my personal server on common ports (i.e. 3128 for a proxy to spam through), that's on DigitalOcean.
- 11y ago
- nchelluri 11y agoTo 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 11y agoSpeaking 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 11y agoI assume to gain an advantage in PvP? If so, how does the attacker identify the IP address they want to hit?
- tomtoise 11y agoOr to troll. A while ago, skype had a vulnerability that let people resolve skype names to IP addresses and since skype is the default communication of lazy gamers, it was pretty trivial to work out the correct IP address to poke. Other methods used to include hooking your Xbox360 up to your laptop and bridging your connection, running Cain and Abel and finding the addresses of opponents that way in games like Halo etc. No idea what the scene is like now that we're on xbones and ps4s, I pretty much exclusively game on PC now. There are plenty of services online that let you snatch IP addresses by sending a link to a 'friend', you could then keep tabs on them that way.
- oddevan 11y agoOK, 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.
- ryanlol 11y agoI'm pretty curious, why is this particular botnet noteworthy? There's a plenty of kids on efnet capable of pushing that
- lordnacho 11y agoHow do the botnets come to be named? Is it named by whichever security firm finds it?
- ryanlol 11y agoThere'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.
- pja 11y agoRate 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.
- andreasvc 11y agoI agree that defaults are crucial, but it's weak passwords not rate limiting which is the fundamental issue here. Rate limiting doesn't help if you get in with the first try of admin:admin. Passwords should be generated from a secure random source and specified on a label on the device.
- utefan001 11y agoI agree with both of your arguments. From my experience ethically cracking accounts, rate limiting, non-default usernames, and non-default passwords should be the #1 priority for Michelle Obama or the next first man/lady. It is a very serious problem.
- utefan001 11y agoreplying to my own post. Exhibit A. http://money.cnn.com/2015/09/30/technology/china-opm-hack-us-spies/index.html http://money.cnn.com/2015/09/30/technology/china-opm-hack-us...
- imaginenore 11y agoRate limiting on everything should be a default.
- espadrine 11y agoWhy doesn't Linux do it by default, by the way? It wouldn't hurt desktop Linux either.
- SixSigma 11y agoCalling 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!
- upofadown 11y agoLinux systems on the net tend to be servers with lots of available outgoing bandwidth. So Linux systems are very valuable targets for the DOS enthusiast and are quite common. So chances are that this attack only targets Linux systems. But, yeah, the headline is click bait. Linux systems are known to be quite secure so this is the old "Man Bites Dog" shtick.
- ibmthrowaway218 11y agoSure, 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 11y agoI wonder if Linux emulation on BSD / plan9 / cygwin will run it?
- deleted 11y ago[deleted]
- ChuckMcM 11y agoThis 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 11y agoMaybe, 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.
- illumen 11y agoGet 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%.
- johngunderman 11y agoWhile this is a good idea to prevent folks from brute-forcing their way into your machine, the article is talking about DDoS attacks. If you have 150G pointed at your network the issue isn't going to be your servers. It's going to be congestion at your network links. Your SSH settings and Fail2Ban won't help at all in this case. You'll need something like CloudFlare's DDoS protection to identify and block DDoS requests from ever reaching your network. EDIT: Oops, just saw that the article does talk about SSH brute-forcing. Your point is quite valid.
- toufka 11y agoThanks. That's very helpful information that's not easily gleaned by awanderin' around 'how to set up a server' tutorials. Simple things like, 'last -a' is a fantastic little hint. Almost would like to make run that command on every ssh session login.
- greyfade 11y agoIf 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.html https://stribika.github.io/2015/01/04/secure-secure-shell.ht... 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.
- thatusertwo 11y agoMy 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.
- z3t4 11y agoThe biggest attack surface is probably cgi scripts (php etc).