DDOS Attacks. What you can do to help stop them!

[fxmulder]

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.

[XRcode]

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 consider it SPAM, and I offer ddos protection services.
...
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.

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.

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

[kha0S]

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 consider it SPAM, and I offer ddos protection services.
...
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.

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.

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.

[efx]

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...

[Vladimir]

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?

[Lethos]

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/

[XRcode]

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.

[Lethos]

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.

[XRcode]

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?

[Lethos]

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?

[XRcode]

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).

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.

[XRcode]

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.

[escrow.ms]

Great script mate.

Good addon for ddos protection.

[Lethos]

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.

[XRcode]

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.

[legend]

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.

[peonminer]

Good work guys. +1

[serraz]

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.

[maz]

This thread has been really informative and taught me loads.