DDoS protection module suggestion

Redd Vinylene reddvinylene at gmail.com
Thu Nov 4 11:48:29 MSK 2010


Just real quick:

What about one of the BSDs and pf? The latter is said to be the world's best
firewall. Real elegant syntax too:

block quick from <bruteforce>

pass in on $ext_if inet proto tcp from any to any port 80 keep state
(max-src-conn 100, max-src-conn-rate 15/5, overload <bruteforce> flush
global)

That takes care of all my DDoS protection needs. Some of y'all mentioned big
guns though, I don't know about that.

Thanks!

On Thu, Nov 4, 2010 at 3:30 AM, malte <nginx-forum at nginx.us> wrote:

> 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.
>
> Posted at Nginx Forum:
> http://forum.nginx.org/read.php?2,147105,147489#msg-147489
>
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://nginx.org/mailman/listinfo/nginx
>



-- 
http://www.home.no/reddvinylene
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20101104/c51bbbf4/attachment-0001.html>


More information about the nginx mailing list