unclepieman Wrote:
-------------------------------------------------------
> Hi,
>
> Agreed, what Ive done in the past to get around
> that issue is to setup a span port on our edge so
> it takes a packet and mirrors it to another
> server, say nic1. You run a script on that server
> that does all the number crunching, based on what
> it sees, you can have your script modify routing
> on the edge router, inject iptables rules into
> your server or any gw devices above the server.
> You can then not only provide a layer3-4
> protection (while taking away the immediate threat
> away) but now can allow the attack to go on for
> say 1-5 min, monitor the uri and log files and
> create a behavior for the traffic which then you
> can block dirty and allow good traffic back in.
>
> having a feedback loop system allows you to get
> rid of any false positives. If say a good ip is
> somehow redirected to localhost:81 (where there is
> a valid link with captcha saying "if you are in
> fact a GOOD user, answer the question and click ".
> Then have that action inject a cookie into the
> session which then gets matched at the edge and
> passes down to the proper segment.
>
> there are dozens of ways to mitigate the issue,
> just depends on how you want to go about it. Ive
> worked on designing advance ddos mitigation
> networks/software and server based appliances.

This would work to mitigate a small DDoS, but if they bring the bigger guns out, a massive problem using the DDoS deflate mechanism you describe here (blocking the attackers with IP tables, or other SW based firewall) becomes impossible, because the Linux kernel (in the case of IP tables) will spend HUGE amounts of cpu time scrutinizing all network traffic, making sure its not going to or from a blocked IP. I experienced this first hand after IP tables reached around 20k blocked IPs. The attack was getting blocked effectively, but the machines load was now higher than it was before the blocking began, due to all this processing the kernel is forced to do on behalf of the firewall.

So I found that it was a lot more effective to just use the nginx limit modules to deny the attackers ability to simply request any amount of pages they wanted. It still meant serving some pages to the attackers, but at least the kernel did not have to devote 90% of its time to IP table processing.

>
> Having said this, i do think that nginx requires a
> native ddos mitigation module, it would save a lot
> of time and effort in the long run! =)

I concur. I've seen a few DDoS attacks before which could easily be mitigated with DDoS deflate techniques, but a module like I described above sure would be helpful when the attack grows more serious.