Preventing Outbound DDOS - Infected VPS and Blocking Ports

[BlueVM]

We've noticed a massive increase in the amount of outbound DDOS attempted on our servers lately. Most of it seems to be coming from a script called 'cupsddh'. We came up with a script to monitor and stop this infection from sending ddos and we figured we'd share it with the community.

The infection appears to be caused by weak passwords and once the VPS is infected the infection sets up a cron job to keep itself installed and communicating with it's 'mothership'.

The script below should be run in a screen on each node you wish to prevent this particular infection from sending ddos on. It takes very little resources to run and it basically stops the DDOS in it's tracks without killing the VPS. The script scans process ids to find copies of the infection then finds out what port that infection is using. After finding the port it uses iptables on the VPS to block the DDOS.

http://pastie.org/pastes/8906293/text?key=3wdhkakgguyshkjeflkk3g

The script is in no way perfect, but it does a decent job at stopping DDOS from this particular infection. Feel free to do whatever you like with it.

This can also be applied to other variants like: "skysappd", "ks(a)appd", etc.

 

[rds100]

A compromised VPS should be turned off until the owner has time to secure it properly. Just filtering this obvious DoS is not enough, you don't know what other evil things it might do which you wouldn't detect immediately.

 

[BlueVM]

A compromised VPS should be turned off until the owner has time to secure it properly. Just filtering this obvious DoS is not enough, you don't know what other evil things it might do which you wouldn't detect immediately.

While true (and we do have other scripts which do shut down the VPS) many hosts don't want to turn off the VPS because they'd prefer not to have backlash from the client. If you want to shutdown the VPS it's quite easily done with a small change to the script.

This is purely an example to help the community, not the entire system we run to prevent DDOS.

I'd rather make an attempt to stop the DDOS than do nothing... if one host picks up this script and uses part/all of it then I consider it a success. It blocks the port and alerts the admin about the compromise... you could change it to shut down the VPS or you could change it to update the password...

 

[Magiobiwan]

If anyone wants a sample of the binaries to investigate/decompile/test, I've collected samples and tarballed them up. I highly recommend testing on an isolated environment. You can grab the tarball fromhttp://darkrai.unovarpgnet.net/BinarySamples.tar.gz and toy with it. Enclosed are the following files:
atddd: setuid setgid sticky ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.2.5, not stripped cupsdd: setuid setgid sticky ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.2.5, not stripped cupsddh: ELF 32-bit LSB executable, Intel 80386, version 1 (GNU/Linux), statically linked, stripped ksapdd: setuid setgid sticky ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.2.5, not stripped kysapdd: setuid setgid sticky ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.2.5, not stripped sksapdd: setuid setgid sticky ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.2.5, not stripped skysapdd: setuid setgid sticky ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.2.5, not stripped xfsdxd: setuid setgid sticky ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.2.5, not stripped

 

[splitice]

If only people could do this for compromised wordpress installations.....

 

[concerto49]

If only people could do this for compromised wordpress installations.....

I think people just need to move off Wordpress....................... prepares to get hit. Runs.

 

[MannDude]

Should enter this in the contest

 

[Nikki]

I agree with rds here, stopping the vps will prevent more damage, and also avoids the very sketchy territory of executing commands INSIDE a client's vps

 

[SkylarM]

This isn't the only compromised script that does this, and they regularly change the name. We've had our fair share of compromised accounts over the last few months and they all run different program names, sometimes it's IpTaBles (yes the letters are like that intentionally), and a few others. Sometimes they change sometimes they do not.

 

[WebSearchingPro]

I agree with rds here, stopping the vps will prevent more damage, and also avoids the very sketchy territory of executing commands INSIDE a client's vps

Every so often people go nuts about having their VPS turned off, its problematic both ways. If people just kept up and stayed secure and updated, this wouldn't even be a problem.

 

[Flapadar]

Every so often people go nuts about having their VPS turned off, its problematic both ways. If people just kept up and stayed secure and updated, this wouldn't even be a problem.

In an ideal world that would be the case. Unfortunately there are people who will set their root password to "password" on the default port - etc.

It isn't that hard to block automated mass SSH scanners though. 

 

[kaniini]

Every so often people go nuts about having their VPS turned off, its problematic both ways. If people just kept up and stayed secure and updated, this wouldn't even be a problem.

I'd rather have someone going nuts about being suspended than be facilitating network abuse I am unaware of.  This approach described by the OP clearly indicates the latter, no wonder they have multiple Spamhaus listings.

 

[Aldryic C'boas]

Their Spamhaus woes are less a consequence of poor administrative choices, and more due to poor business choices.

 

[splitice]

Its a complicated issue,

Suspending a VPS might be a bit harsh, at the same time facilitating DDoS attacks is very bad (trust me, it could be me on the other end).

Perhaps a half measure such as:

1. Open support ticket, notify staff and customers (staff can suspend if necessary)

2. Rate limit outgoing connections, packets and bandwidth. While this may be detrimental, it is arguably better than a suspension.

e.g rules could include:

• Limit Bandwidth to no more than 20mbit per dstaddr
• Limit PPS to no more than 1,000 pps per dstaddr, allow burst to 3,000
• Limit SYN to no more than 50 pps per dstaddr, allow burst to no more than 400 pps (possibly the most harmful).

The idea would be fore the rules to be a temporary measure until a decision (possibly rule tweaking) can be made by staff and / or the situation resolved by customer.

I do not own a VPS hosting company, so this is all just speculation as to procedures on my part.

 

[MartinD]

Just to note and be back on topic a little, it's more than just 'cupsdd'. Look for any process with a double-d in it as 99 times out of 100 they are dodgy. We use a similar script and it works quite well.

 

[eva2000]

For the initial compromise due to weak passwords, maybe a much stronger default passord policy would help https://www.digitalocean.com/community/articles/how-to-set-password-policy-on-a-centos-6-vps ?

 

[MartinD]

You can lead a horse to water... etc.

 

[eva2000]

You can lead a horse to water... etc.

well i meant for VPS at least add a stronger policy to the default provided ISO templates ? so it's in place out of the box at setup time