All of lore.kernel.org
 help / color / mirror / Atom feed
* netfilter - DROP lists .. efficiency under DDOS?
@ 2005-03-14 21:34 cmbb
  2005-03-14 22:03 ` Sertys
  0 siblings, 1 reply; 2+ messages in thread
From: cmbb @ 2005-03-14 21:34 UTC (permalink / raw)
  To: netfilter

I had an experience with a DDOS attack comprising some 10,000 IPs.
Adding them individually as INPUT DROPS did not work because after 5000
or so IPs, the box became too slow to pickup new packets from the card
quickly enough, so we replaced one problem (flood) with another (random
overruns on the card).

The traffic was about 6mbit of small packets (SYNs and tiny data
packets). About 10,000 packets per second.

The more DROPs, the less packets per second could be handled. Removing
all DROPS meant all packets could be handled .. although that just
pushed the problem onto apache.

My question is this .. how many DROPS can the latest netfilter
adequately cope with before impacting the PPS speed of the linux box?
Would -t raw have been a much better solution here?

My network driver was e1000.o with NAPI compiled. Kernel was latest 2.4
smp kernel. Machine was dual xeon with 2gb of memory. Nothing else of
consequence running on the box.

thanks



^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: netfilter - DROP lists .. efficiency under DDOS?
  2005-03-14 21:34 netfilter - DROP lists .. efficiency under DDOS? cmbb
@ 2005-03-14 22:03 ` Sertys
  0 siblings, 0 replies; 2+ messages in thread
From: Sertys @ 2005-03-14 22:03 UTC (permalink / raw)
  To: Netfilter list

On Mon, 14 Mar 2005 16:34:45 -0500, <cmbb@dslr.net> wrote:

It really depends on the matches. It is stupid to have 10000 drops in the
filter table, cause each packet(SYN) has to be matched against each rule
and that's where your problem is.
You can(if you want) sector your traffic on smaller tables and drop there.
I.E everything in the range x.x.x.x - x.x.x.x2 going to table drop1,
y.y.y.y-y.y.y.y2 going to table drop2 and so on. This way you don't have
to traverse the whole rule tree everytime a packet hits your interface.
Normalization of rules is vital to you. If you're in front of fully random
IP's - that's a tough task to do. Log the flood packets and write a perl
parser to categorize them for you(i.e. sort them in classes). And the
enter them as rules in iptables or iproute2.

> I had an experience with a DDOS attack comprising some 10,000 IPs.
> Adding them individually as INPUT DROPS did not work because after 5000
> or so IPs, the box became too slow to pickup new packets from the card
> quickly enough, so we replaced one problem (flood) with another (random
> overruns on the card).
>
> The traffic was about 6mbit of small packets (SYNs and tiny data
> packets). About 10,000 packets per second.
>
> The more DROPs, the less packets per second could be handled. Removing
> all DROPS meant all packets could be handled .. although that just
> pushed the problem onto apache.
>
> My question is this .. how many DROPS can the latest netfilter
> adequately cope with before impacting the PPS speed of the linux box?
> Would -t raw have been a much better solution here?
>
> My network driver was e1000.o with NAPI compiled. Kernel was latest 2.4
> smp kernel. Machine was dual xeon with 2gb of memory. Nothing else of
> consequence running on the box.
>
> thanks
>



-- 
www.supportivo.org

I can't stop myself checking for pigs in the outlets. Everybody thinks i'm  
a punk, cause of the hairstyle(220V).
end


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2005-03-14 22:03 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-03-14 21:34 netfilter - DROP lists .. efficiency under DDOS? cmbb
2005-03-14 22:03 ` Sertys

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.