Performance vs. Rule Set Size

Performance vs. Rule Set Size

[David Cary Hart]

I realize that there are too many variables to answer this question with
great precision so consider this a reality check.

Our server has been under very heavy attack over the last few weeks. I
have been adding individual hosts who try to exploit either httpd or
smtp. I now have an input rule set of several hundred lines. Does that
seem terribly over-sized or is that fairly common?

Re: Performance vs. Rule Set Size

[Chris Brenton]

On Tue, 2004-07-27 at 22:11, David Cary Hart wrote:
>
> I realize that there are too many variables to answer this question with
> great precision so consider this a reality check.

So long as you understand what you are asking. ;-)

> Our server has been under very heavy attack over the last few weeks. I
> have been adding individual hosts who try to exploit either httpd or
> smtp. I now have an input rule set of several hundred lines. Does that
> seem terribly over-sized or is that fairly common?

I've run 400+ on old P-III hardware without a problem. I know others
have gone beyond even that.

One thing you might consider is leveraging custom chains. Something
like:

iptables -N http
iptables -A FORWARD -i eth0 -p tcp --tcp-flags SYN,ACK SYN -d
192.168.1.128/27 --dport 80 -j http

replacing "-i" with your external interface and "-d" with the IPs of
your Web servers. 

Now in the http chain you block all the nasty IPs. You can then either
permit access to your Web servers within that chain, or come back to the
forward chain and keep the rule there. What ever makes life easier for
you. 

Nice thing about the above is all non-http traffic no longer has to
traverse all your blocking rules. This should help speed up processing. 

HTH,
Chris
 

Re: Performance vs. Rule Set Size

[Alexander Samad]

[-- Attachment #1: Type: text/plain, Size: 1680 bytes --]

Hi

I have a BLOCKED chain that every packet go through (its before the
EST/RELA rule) and have about 3000 lines and I can still get around
4x200Kbs tcp streams on Telstra cables (about the same with out the
filtering) 

Alex

On Tue, Jul 27, 2004 at 10:35:11PM -0400, Chris Brenton wrote:
> On Tue, 2004-07-27 at 22:11, David Cary Hart wrote:
> >
> > I realize that there are too many variables to answer this question with
> > great precision so consider this a reality check.
> 
> So long as you understand what you are asking. ;-)
> 
> > Our server has been under very heavy attack over the last few weeks. I
> > have been adding individual hosts who try to exploit either httpd or
> > smtp. I now have an input rule set of several hundred lines. Does that
> > seem terribly over-sized or is that fairly common?
> 
> I've run 400+ on old P-III hardware without a problem. I know others
> have gone beyond even that.
> 
> One thing you might consider is leveraging custom chains. Something
> like:
> 
> iptables -N http
> iptables -A FORWARD -i eth0 -p tcp --tcp-flags SYN,ACK SYN -d
> 192.168.1.128/27 --dport 80 -j http
> 
> replacing "-i" with your external interface and "-d" with the IPs of
> your Web servers. 
> 
> Now in the http chain you block all the nasty IPs. You can then either
> permit access to your Web servers within that chain, or come back to the
> forward chain and keep the rule there. What ever makes life easier for
> you. 
> 
> Nice thing about the above is all non-http traffic no longer has to
> traverse all your blocking rules. This should help speed up processing. 
> 
> HTH,
> Chris
>  
> 
> 
> 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Performance vs. Rule Set Size

[Feizhou]

Alexander Samad wrote:
> Hi
> 
> I have a BLOCKED chain that every packet go through (its before the
> EST/RELA rule) and have about 3000 lines and I can still get around
> 4x200Kbs tcp streams on Telstra cables (about the same with out the
> filtering) 

That does not give any real meaning since your load is going to very 
different from what David gets. Besides data throughput is very 
different from packet throughput in the eyes of filtering.
>>>Our server has been under very heavy attack over the last few weeks. I
>>>have been adding individual hosts who try to exploit either httpd or
>>>smtp. I now have an input rule set of several hundred lines. Does that
>>>seem terribly over-sized or is that fairly common?
>>

It really depends on how much cpu it is costing you.

I only have a few hundred rules and I DO NOT use connection tracking but 
my boxes get like something like over 2k packets per second. With the 
2.6 kernel, you can run into two issues. At the packet rate I have to 
handle, filtering costs me about 10% cpu usage. If I had connection 
tracking turned on, I get at least another 20% hit in cpu usage (I say 
at least because I no longer could tell how much more it would chew 
since system cpu usage hit 99% after I turn on connection tracking) and 
so I ain't gonna try connection track related modules.

David, if you are using a 2.4 kernel, you might find the ipset module 
useful to cut down the number of rules you put into your netfilter 
configuration.