All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Preventing Outbound DDOS - Infected VPS and Blocking Ports
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.
Comments
For the record, this is a linux botnet.
And this is a Command & Control server that would be of great help to the netsec community if you reported it's IP and respective details to a malware tracker.
>looking/analyzing at VPS procs/data
>Blocking ports
>Legal
Yea... not here.
If you are in Europe/EU i can NOT recommend to do this at all - First make sure it's even allowed. Tos are in many countries not enough for this.
Is it even allowed in USA? Scanning customer servers for what they have? I mean maybe maybe if you detect high volume traffic on the ports or something you warn them / shut it off for abuse.
In which case you modify it to shut down the VPS. It's purely example code.
It's not port scanning. It's literally looking for a process on the host node (openvz) and preventing it from doing something nasty if it finds that process. It's easily updated so that you can shut down the VPS or actively remove the infection or whatever is legal in your country.
The 'scanning' portion is done host node side. It does block the port on the VPS itself if it finds the infection, but it could just as easily shut off the VPS.
In Austria even looking inside the VPS is already extremely questionable (and most likely illegal, just no precedence case yet).
hmm?
That part clearly violates client privacy in most of Europe:
Sure, you can remove it, but without looking at the procs it is still... not really detectable.
Technically it isn't looking inside the VPS. It's scanning processes on the host node... only when it finds the infection does it do anything to the VPS and no files on the VPS itself are read by this script.
Well, the script isn't really scanning the customer's server for anything - it's using the process list on the host node. I mean, it's OpenVZ - you're in a glorified chroot, there's no way to easily prevent yourself from seeing stuff like this. I can, however, see some people having a problem with this, though I personally don't. I do, however, take exception to the script adding an iptables rule in the VPS itself using vzexec. That's a big no-no, in my book. Block the IP/port combination on the HN itself.
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 from http://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
Therefore this has looked and made a change to a customer VPS. Don't see how that gets justified?
It should be questionable anywhere. That's equivalent of going inside someone's house without a warrant.
We shut off the VPS... I wrote this code purely as a modifiable example. You could block it on the host node... you could shut it off. Literally one line determines what the script actually does.
This script wasn't meant to be the "be all end all". It's meant to help someone along the road to preventing DDOS. If one host adopts a few of the suggestions on this page it's helped the world and the VPS community and that's the only reason I released this.
Once again we shut off the VPS instead of blocking the port. It's an example. That is all. Do whatever is legal and doesn't violate your TOS. The script is searching the process ids on the physical box. If you have a problem with the action the script actually takes when it finds the process change it... it's that simple.
some ideas for cleanup
1) No shebang
2) Don't use backticks use $()
3) "if [ "$pid" -eq "$pid" ] 2>/dev/null; then" use a regex or check the exit code $? of the pidof statement instead
4) netstat doesnt qualify against a particular VM, would it thus be possible to block a particular port on a non-matched VM if there were any legitimate use of cupssdd on non-infected VPS, could you not use netstat to filter against the pid, or alternatively pull the port from /proc/
5) cleanup isnt necessary
6) no sleep, reading out information from the kernel isnt expensive, calling pidof launches a process each time even on the false branch, insert at least a second sleep in loop
Decent ideas... this isn't the code we use on our servers though... just an example. If you want to make those improvements and re-release it I'll put the updated version in my original post.
it's illegal to stop people doing something illegal? WTF! the world has gone mad
Just out of curiosity, is this the same monitoring script that's shut down my container two weeks in a row for running Observium?
If you are preforming DDOS attack or lets say you are sending SPAM you will get suspended, but your VM will not be checked from the "inside". This basically means that in EU no one have right to log in into your VM except you, or with your agreement. Other words would be it is not 100% legal, you have no rights to preform any kind of illegal activity and your host has all rights to prevent you to do such things or to stop you in doing them. In the other way, your personal data are your personal data and no one have rights to do any thing with them without your permission.
Do you love to stalk your clients @BlueVM ?
This conclusion would seem to imply it is "illegal" for a host to run 'ps aux' on an OpenVZ node in Europe.
Pravail detects this traffic. Its always best to detect on a network level then there is no grey-area of entering customer VPS's or just the creator of this software making it rename its filename/process name dynamically
Yes, in some countries it is (See Polish criminal code, they back then even got AN ORDER to even look into my VPS (OpenVZ) (on the host and in the VPS) - In addition to the normal order to get my customer data, copy available)
I've made a sort of review of this backdoor functionality in february. It's in Russian, but if you're interested, you can read it here
http://habrahabr.ru/post/213973/
I've got newer version recently and going to write another review in English soon.
Can someone clarify/reference the EU law? Private persona/customer data, sure, that's data protection/privacy legislation. But what's specific about processes on a virtual machine?
https://github.com/ValdikSS/billgates-botnet-tracker