Bitcoin Forum

I'm sure you are all aware of the recent DDOS attacks on multiple pools and services in the crypto community.

Our Pool was one of the pools hit in these attacks. These attacks are damaging the reputation of crypto coins and causing mass panics.

i'm sure most pools have invested or are investing in some form of DDOS protection most of which will keep logs of any attack that happens on your pool. Now these are great but if you claim to be DDOS proof you would be lying nothing is DDOS proof if the attack is big enough some might even see it as a challenge.

We can all help to stop these attacks or at least shutdown some bots and i will tell you how right now.

Khaos and myself have developed a script that will analyse log files captured from a ddos attack split it up into subnets, find what company is in charge of those addresses and send them an email with the logs attached stating that a DDOS has come from those IP addresses.

The company's must act on these emails as doing a DDOS is a crime. I know it will not stop these DDOS attacks and they can get more bots quite easily but it will reduce their attack power and help make users aware that their machines are compromised and how to stop this happening.

If you would like a copy of the script you can find it here. http://pastebin.com/ZN0bqrKS

Thanks for reading

Rather impossible. Because somebody who has a botnet. With a 0day exploit or even a crappy older exploit, he can increase that botnet by 500-1000 bots in a week or two.

And your emails are going to shut down what? 200-300 of his bots in a week...

So it's a race.

You can't win.

And even if you shutdown one botnet, there will be 10 others to take the DDOSers place.

The only way to stop DDOS is to pay for DDOS protection :)

I would like to add, that from this first batch of emails sent (around 8000 emails), we have already received a huge number of reports stating servers "fixed" or simply disconnected for investigation. The problem affecting this machines was quite easy to fix.

That kind of prompt answer from SysAdmin teams should be praised and thanked.

Thanks!

../kha0S

Agreed with you 100%. This is not a solution to stop them per say not is it a replacement for ddos protection and it never will be. You are correct we can never stop them. but if we can take down some of the bots and make users aware of certain programs used for botnets it could make the attackers job that little bit harder.

Again this is not going to stop ddos attacks or is it a replacement for ddos protection. Its a simple way we can help make users aware of exploits and unwanted programs on their machines and servers.

Surely shutting down 200 - 300 a week is better then a extra 200 - 300 bots in their army.

We are not talking about a 0day exploit here. It's a misconfiguration on DNS servers allowing "attackers" to inflict a DNS amplification attack. In our case represented almost 10Gbps of unrequested UDP traffic.

Downtime caused: several hours
Time to fix: <1 minute

On the other hand:

Time to create the script: a couple of hours
Time to run it every time it happens from now on: 1 second

Cheers,
kha0S

Doesn't even need to a be DNS reflective attack.

1000-2000 bots can pump out about 25-50 GB/s without DNS reflective attacks :)

Champion effort guys ++

great job guys, always good to see people sharing this type of stuff with the community for the greater good.

Just publish the script right here. Lots of people will find it maybe years down the road and use it. There is really no reason to hide those behind PM's.

You can't protect yourself from a DDOS attack from running a script on your own server. You have to talk to the upstream providers. Make your own DNS server, block other DNS requests from other DNS servers, etc.

There's nothing you can do with an iptables script or anything of that matter to effectively stop DDOS on your servers.

Plus, 10 GB/s is very low :)

I guess you didn't read serraz email...
The script doesn't create automatic rules. The firewall rules are already there. That's not the point!
The script generates the attack reports emails and sends them to contact according to "whois" info for the attacking IP.
This emails are monitored by sysadmin/netadmin teams, who actually act really fast.

Cheers.
kha0S

P.S.: Yes, it's low. But for a pool it's the difference between finding a block or not...

Yacoin. It is not about stopping it. It is about reducing zombie nets so that they are weaker for the next victim/attack. And yes admins do read those emails and do act on them. I used to be one of those admins, I should know.

What did you administer?

Great point i will post it up here as soon as i have access to a machine with a decent connection.

Script has been added my original post

I am confused. You mean ppl who ddos do not even spoof their src ips from subnet related to the one they are on or random?
Sending out emails might mean sending emails to the wrong isps.

Once they are notified they can see if there was traffic or not and decide weather it was spoofed or actually coming from their machines. this just sends a notification for them to do internal investigating.

Booters cost like $5/month and the pools need corporate grade protection to counter them; it's not cheap (2-4k/month for TCP applications like Stratum). If we manage to knock off 50% of the nodes, the booter price might go to $10/month or something so it's still a losing battle. These aren't the sophisticated attacks that mtgox has to deal with, but a simple UDP flood. Most hosts that offer DDoS protection, from my shopping experience, max out at 10Gbit/1-5MPPS, and I consistently saw attacks stronger than that with CNC (peak was 22Gbit, 75% of the attacks were over 10).

Some prices for dedicated DDoS protection I found: (not shared like awknet or VPS)
Staminus     $1k/month for 10Gbit/1MPPS (not strong enough)
BlackLotus $675/month for 10Gbit/6MPPS
Some other  $1k/month + $4k setup for similar

The solution I've come up with is to just use a suite of reverse proxies:
buyvm/etc VPS (10Gbit/5MPPS)
Minecraft-oriented VPS/Dedicated (Varies)
Cloud Load Balancer

For example, I used an amazon elastic load balancer and some micro instances for forwarding. By using the ELB, amazon soaks up the packet floods and does some filtering. I also use cloudflare free, but there's a risk. If your site gets a http-layer attack, and you're not on the 200/m plan, cloudflare will change your DNS record and effectively direct the traffic to your server. The pro is a packet flood goes to the CDN node, and that's not associated with any single domain, so it blocks those (you can route longpolling through cloudflare since it's HTTP traffic)

paul21: yes I confirm that what you posted is consistent with my experience.

tl;dr get a decent sysadmin and treat him well and your DDOS issues can be solved to a large degree.

We do have protection in place. read up to my previous posts this is not going to stop DDOS attacks not by a long shot.

If enough people use this script we might be able to make their job that little bit harder by shutting down bots and spreading awareness of tactics they are using. In the end its up the the person if they want to use it or not i just figured others might also find this useful

Jesus, people apparently do not know how to read on this forum. The point of Khaos and serraz's script is to notify the netblock owner, and their associated Abuse/NOC team of malicious and abusive traffic.

Most respectable, and legitimate data centers(actual data centers, not some kid that is renting dedis pretending to BE a datacenter) have dedicated Abuse teams(I created one and ran it for quite some time) to handle these kind of complaints. As long as the script is directing the abuse complaints to the IP block owners abuse (Must have one registered with RIPE, ARIN, APNIC, etc..) contact, these zombie nodes will decrease. That doesn't meant that htey can't get more, that just means they are getting reported, and hopefully action taken.

Learn to read and not pretend like you know everything yacoin.

I often use report emails autogeneration. Sometimes this even could destroy the botnet, but usually makes it weaker.

100% what i was saying thanks balth

Definitely is good plan forward, if enough people use scripts such as yours it, it would reduce the over all number of compromised networks in the long run, which these DDOS attackers make use of. Not necessarily a cure, but certainly make them weak enough to be easier to deal with.

I don't run a pool, but I do run a few servers, so I'll probably rewrite this to make it work along side one of my other scripts which usually just blocks these IP address' in the 1st layer firewall.

Great please post your script here also to share with everyone :)

As long as the attackers' bandwidth exceeds the server's it would most probably down.

You clearly don't know much about DDoS' in general to make that such misinformed suggestion.

I will do, I plan to rewrite one of my pfsense packages. It might take a little while, but I can't rush it, it is a live production server.

You do realize 99% of ddos attacks are spoofed right, and the ones that aren't are usually reflection attacks.. ie, DNS amplification attacks.
Sending emails like that is just spamming a ton of innocent people most of the time.

Spamming innocent people?
We reported a problem to the network/system admin of the affected server?
From all emails sent, the common thing I see among all answers is: "Thank you for informing us about the problem".

And in the end, at least we try to do something. I would like to see your suggestions then...

 ;D ;D ;D

And how many emails go to admins of public DNS servers that they can't or won't reconfigure to not be open recursive??.
I get a shitload of emails everyday complaining about "my ip's attacking" when in reality, I deal with multigigabit DNS amplifaction attacks at my end.
I don't think emailing the world helps, DDOS needs to be mitigated, not complained about.

Deafboy, do you honestly think that only mining pools get DDoS attacks?

XRcode, spamming? When I was taking care of information security of an ISP I very much appreciated reports from third parties about any possible problems on my networks, whether it was manual or automatically generated. It, of course, was like a decade ago, but I do not think that much has changed since then. I'd say most modern day sysadmins will appreciate such reports and in fact the emails used for this according to relevant RFCs are specifically intended for such purposes.

I consider it SPAM, and I offer ddos protection services.
The reason for this... If you log a ddos attack, you get 99% false positives.
The emails won't do any significant damage to the threat, and are just an annoyance for most people.
As as a person who offers DDOS protection services and deals with a ton of these false positives every day, I know a thing or two about this.

As a person who offers DDOS protection services, you have a vested interest in not seeing actions like this having much effect. It's called a Conflict of Interest.

People need to understand the value of receiving third party email regarding problems on their network. I've been an admin for years, and some of the most effective tools for identifying servers that have been, to some degree, compromised are third-party notifications.

/Salute to KhaOS and Serraz for trying to do something positive, and then spreading it to the community.

Are there addresses that we could donate to, per chance? Maybe put it in the OP?

You are missing the point, you are sending emails to a source that has either sent nothing at all or is an open recursive DNS server MOST of the time.

Was that your educated guess? Sorry to tell you, but you are wrong!
From all emails sent only in 2 cases they really needed to have it open. But even som they were conscious about the problem and they even tightened the number of queries per minute they allow.
All the remaining cases, simply didn't know about the problem and where looking for malware/virus on their servers.

US-CERT as some nice info about this and how to fix it:
http://www.us-cert.gov/ncas/alerts/TA13-088A

Cheers,
khaos
 

I had to post this! 
Just received this email from NOC4 Abuse Support:


"Hi!
  You should not see any more of this traffic form our net now!, both the offending resolvers have had acl's placed on them now! ... and we have ~30mbit drop in our outbound traffic! "


I have dozens of emails like this...
And people still think this is annoying?!?!?!? Annoying is staying awake 20 or 30 hours trying to deflect an attack just because a stupid kid with a botnet decides your site/network is the next target. Annoying is paying 500USD/month to some company that will try to "protect" your network. But only if the attack is bellow 1Gbps.

Cheers!
A nice weekend to everyone!
../khaos

As a sysadmin involved in a network of over 20000 customers I can say we take these kinds of reports very seriously and I am sure many other network administrators do too.  I applaud your initiative.

Forget it :)
Thought you knew what real ddos attacks were... I guess you don't actually see real attacks you just have script kiddie crap you can fight off with a few netfilter rules on your little servers.
I protect people from attacks, while we receive complains from a ton of retarded admins saying that our clients are attacking their DNS servers...
They don't bother to check that the query is around 70 bytes and the bloody return is around 4000bytes and we are actually receiving 20gbps on our end.
Anyways if it helps... do whatever you want, but seriously 90%+ of attacks are spoofed and you are just sending mail to nowhere/wrongip/etc

I understand you. That's your job. Rest assured, that the world is full of idiots installing/configuring servers.
And my apologies for not contracting the "fantastic" service your company provide. I'm sure I would be much, much better protected now.

lol^

 

This is a great idea and it's already working, that's really all there is to it. Some of these 'experts'  posting here have a whiff of the script-child themselves...

Could it be that kind of "DDoS protection" service as in "pay us and DDoS will stop". Then their angst would be even more understandable. ROFL. Attack a "defended" and "retaliating" target and see you zombie/reflector army decimated, who would like that?

This is a quick simplified version of what I have used on my backend servers (for if it gets past my 1st firewall).
http://pastebin.com/CzVfr27P

I modified it quickly. While I'm working on one for PFSense, I figure someone can enjoy the use of this regardless of what server setup they have (within reason).

Similar to this is also this one, which is a little nicer since it comes with a few extras.
http://deflate.medialayer.com/

-j REJECT --reject-with tcp-reset

You should replace this with -j DROP

In the event of a DDOS attack, you don't want to be sending anything out at all... This leads to more resources being used on the server and also causes a lot of network back-scatter.

Also, if you are using conntrack on the server, you may want to look at dropping them in the raw table PREROUTING chain.... This will stop the connections from entering the conntrack table and save you a ton of resources.

In my experience DROP isn't what you want in this case. DROP leaves the tracking burden on all the stateful gear between you and the endpoint - which doesn't fix the problem. But if you wish to change it, by all means. I gave a simple code example for easy tweaking.

Drop discards packets silently.
If you are receiving a ddos attack, you certainly don't want to be sending tcp resets to all the spoofed ips that attack..
This creates backscatter, and burns resources on your end.

A TCP reset should be sent only when it's purpose is to legitimately notify the connecting IP that there is no services at the given ip/port.

Also, there should not be any stateful gear between you and the endpoint.

It's quite simple, if someone sends a SYN flood from random IP's is it better to tell all the IP's who never sent anything in the first place to reset the connection they didn't try to make? Or just drop the packet immediately upon receipt and be done with it?

I really believe the important lesson here is that rejecting packets instead of dropping them can help the surrounding network get a hint of what's going on and mitigate the situation, even though dropping the packets may superficially seem more effective (because it does not create any more traffic on an already heavily burdened network, REJECT does).

So I can understand some of your points, but the difference between the two in terms of resources in negligible. The benefit of being able to keep a good view on these attacks and know how progress is going and when to clear out the IP address' out ways it's negatives in my experience.

For me personally it helps me move large numbers of "Bad" IP address' to the 1st layer firewall if they are a persistent problem, which is after all designed to have a large number of IP's on it block list. If they are not, they get cleared out so most of my backend servers have a relatively clean list.

But we are all entitled to our own methods. Drop is a fine alternative, so why don't you suggest the simple change?

Actually, sending the resets will do nothing to mitigate the attacks, and why does the rest of the internet need to know you are being attacked?
Rules like this just cause network backscatter, that's all they do.
There is no case in which sending a TCP reset out, for a spoofed syn packet can ever help you.. You are just letting them use more resources at your end.
You can get a tremendous gain in firewall performance if you DROP these packets, and again if you are using conntrack you should try to drop these in the raw table PREROUTING chain, before they enter the conntrack table.

I deal with large-scale attacks on daily basis, we fend off SYN attacks for our clients at over 10mpps.. At these rates, sending tcp resets out for each packet received only puts a massive increase on the network load, burns a ton of egress bandwidth and accomplishes nothing.
The advice I am giving you is very sound, do your research if you don't believe me.

Also, a skilled attacker can use you in a reflection attack just because of this rule.
Example, if Villain wants to send a DDOS to google's public DNS 8.8.8.8
All he needs to do is spoof his syn packets to 8.8.8.8, and send them to you.
You are going to participate in a reflection attack now, because your rules are not well thought out.

Great script mate.

Good addon for ddos protection.

Since you are rather persistent in putting me down, without actually being constructive.

http://pastebin.com/vRxmpFbc

Updated using DROP instead.

Guess this is why I don't give out quick example code, I should of learnt from last time.
To be clear I don't use just this in my production servers, so before you get judgemental, assess it for what it is, rather than assuming.
I'll keep my code to myself if I get this sort of reception.

I am not trying to put you down, I am offering advice based on my past experience.

I actually offered 60Gbit UDP protection and sufficient layer 7 protection reverse proxies but it seemed like no one was interested so I stopped selling.

Good work guys. +1

So far great. I've lost count of the amount of infected machine that have been shutdown not to mention open and servers. I hope you are all spreading the round and using it every little bit helps.

I know I've learned from the responces. A thanks goes out to all those sys admins for prompt action in this matter.

This thread has been really informative and taught me loads.