Linux Netfilter discussions
 help / color / mirror / Atom feed
* RV: optimizations for large rule sets
@ 2008-03-06 16:06 Alberto Díez
  2008-03-06 21:49 ` Grant Taylor
  0 siblings, 1 reply; 3+ messages in thread
From: Alberto Díez @ 2008-03-06 16:06 UTC (permalink / raw)
  To: netfilter

hi!
 
 I am trying to make use of a large number of rules
 with iptables. 
 
 I have seen there are some optimizations referenced
 like nf-HiPAC (www.hipac.org) , iptables with
 classifiers (www.geocities.com/hamidreza_jm) which
 appearently can deal with thousands of rules (thats
 what i need).
 
 I want per flow (orig addr,dst addr, orig port, dst
 port, proto) filtering thats why i don´t think i can
 use ipsets (or can i?)
 I also would like to have the nice iptables features
 like  mangle table and counters ..
 
 I dont really understand what the conntrack does, or
 if it can somehow helpme (where is the nice
 documentation about this??)
 
 What is the netfilter preferred way to have a large
 set of rules and still do packet filtering?  are
 HiPAC, iptables with classifiers or any other
 solution
 actual?
 
 is there a howto,manual,some kind of
 documentation, all that I find about this are quite
 old (3 years?) material in the mailing list ... Is
 this problem already solved? what was the solution
 taken?
 
 
 well if you could answer any of this questions i
 would
 be very thankful
 
 Alberto Diez
 
 
      



      ______________________________________________ 
Enviado desde Correo Yahoo!
Disfruta de una bandeja de entrada más inteligente. http://es.docs.yahoo.com/mail/overview/index.html

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

* Re: RV: optimizations for large rule sets
  2008-03-06 16:06 RV: optimizations for large rule sets Alberto Díez
@ 2008-03-06 21:49 ` Grant Taylor
  2008-03-07  8:33   ` G.W. Haywood
  0 siblings, 1 reply; 3+ messages in thread
From: Grant Taylor @ 2008-03-06 21:49 UTC (permalink / raw)
  To: Mail List - Netfilter

On 3/6/2008 10:06 AM, Alberto Díez wrote:
> I want per flow (orig addr, dst addr, orig port, dst port, proto) 
> filtering thats why i don´t think i can use ipsets (or can i?) I also 
> would like to have the nice iptables features like  mangle table and 
> counters ..

Ok...

> I dont really understand what the conntrack does, or if it can 
> somehow helpme (where is the nice documentation about this??)

I can't tell you exactly what it does but conntrack is used in 
maintaining state of connections.  So if you want to use the state match 
you will need conntrack.

> What is the netfilter preferred way to have a large set of rules and 
> still do packet filtering?  are HiPAC, iptables with classifiers or 
> any other solution actual?

I don't know what, or if there is, the netfilter preferred way is. 
However I think the best thing you can do is to intelligently write your 
rules.  Quite a few people just use a long list of rules that is 
processed linearly until a match is found.  I think you will have better 
luck with fewer rules that make one decision and then jump to a 
sub-chain where there are a few more rules to make another decision and 
then repeat the process.  I.e. if you are wanting to have a set of rules 
for a bunch of different clients, don't do this:

-d a.b.c.1 -p TCP --dport 22 -j ACCEPT
-d a.b.c.1 -p TCP --dport 25 -j ACCEPT
-d a.b.c.1 -p TCP --dport 80 -j ACCEPT
-d a.b.c.1 -p TCP --dport 110 -j ACCEPT
-d a.b.c.2 -p TCP --dport 22 -j ACCEPT
-d a.b.c.2 -p TCP --dport 25 -j ACCEPT
-d a.b.c.2 -p TCP --dport 80 -j ACCEPT
-d a.b.c.2 -p TCP --dport 110 -j ACCEPT
-d a.b.c.3 -p TCP --dport 22 -j ACCEPT
-d a.b.c.3 -p TCP --dport 25 -j ACCEPT
-d a.b.c.3 -p TCP --dport 80 -j ACCEPT
-d a.b.c.3 -p TCP --dport 110 -j ACCEPT

Packets for POP3 traffic to a.b.c.3 will have to traverse a lot of rules 
that it will never match before it gets to the one that it will. 
Instead write your rules like this.

-d a.b.c.1 -j IP_a.b.c.1
-d a.b.c.2 -j IP_a.b.c.2
-d a.b.c.3 -j IP_a.b.c.3

-A IP_a.b.c.1 -p TCP -j IP_a.b.c.1_TCP
-A IP_a.b.c.1 -p UDP -j IP_a.b.c.1_UDP
-A IP_a.b.c.1 -p ICMP -j IP_a.b.c.1_ICMP

-A IP_a.b.c.2 -p TCP -j IP_a.b.c.2_TCP
-A IP_a.b.c.2 -p UDP -j IP_a.b.c.2_UDP
-A IP_a.b.c.2 -p ICMP -j IP_a.b.c.2_ICMP

-A IP_a.b.c.3 -p TCP -j IP_a.b.c.3_TCP
-A IP_a.b.c.3 -p UDP -j IP_a.b.c.3_UDP
-A IP_a.b.c.3 -p ICMP -j IP_a.b.c.3_ICMP

-A IP_a.b.c.1_TCP -p TCP --dport 22 -j ACCEPT
-A IP_a.b.c.1_TCP -p TCP --dport 25 -j ACCEPT
-A IP_a.b.c.1_TCP -p TCP --dport 80 -j ACCEPT
-A IP_a.b.c.1_TCP -p TCP --dport 110 -j ACCEPT

-A IP_a.b.c.2_TCP -p TCP --dport 22 -j ACCEPT
-A IP_a.b.c.2_TCP -p TCP --dport 25 -j ACCEPT
-A IP_a.b.c.2_TCP -p TCP --dport 80 -j ACCEPT
-A IP_a.b.c.2_TCP -p TCP --dport 110 -j ACCEPT

-A IP_a.b.c.3_TCP -p TCP --dport 22 -j ACCEPT
-A IP_a.b.c.3_TCP -p TCP --dport 25 -j ACCEPT
-A IP_a.b.c.3_TCP -p TCP --dport 80 -j ACCEPT
-A IP_a.b.c.3_TCP -p TCP --dport 110 -j ACCEPT

For the same POP3 traffic to a.b.c.3 the packets now traverse 3 rules 
and jump and traverse 1 rule and then jump and then traverse 4 rules. 
As such, rules set up like this will require processing fewer rules (8) 
verses the other linear method with more rules(12).

This may be more complex on the surface, however most of this is 
repetition.  You can also have just about any rule set per stage per 
destination you want.  If you have a lot of destinations like you are 
alluding to, you can even make your earlier decisions based on 
destination IP and netmask to group a bunch of IPs in one jump and then 
subdivide after the jump while having fewer rules overall that the 
packets have to traverse.

Something else to keep in mind is that you don't want your rules to be 
overly complex.  The only reason I'm checking protocol at the final 
stage is that I have to to be able to check ports.  If it were not for 
that requirement I would not do the protocol check because the previous 
stage checked the protocol already and I know that the only way to get 
to the particular sub-chain at any given stage is to have passed through 
previous stages and rules.

> is there a howto,manual,some kind of documentation, all that I find 
> about this are quite old (3 years?) material in the mailing list ... 
> Is this problem already solved? what was the solution taken?

I'm sure there are other approaches.  However I've found that if you are 
smarter about how you go about what you want to do you will have better 
overall performance.  This same type of logic applies to IPTables and 
HiPAC and many other things too.

> well if you could answer any of this questions i would be very 
> thankful

Can we see an example of some of your rules (sanitized as need be) so 
that we can see where they might be optimized as well as what and how 
you are trying to filter.



Grant. . . .

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

* Re: RV: optimizations for large rule sets
  2008-03-06 21:49 ` Grant Taylor
@ 2008-03-07  8:33   ` G.W. Haywood
  0 siblings, 0 replies; 3+ messages in thread
From: G.W. Haywood @ 2008-03-07  8:33 UTC (permalink / raw)
  To: netfilter

Hi there,

On 3/6/2008 10:06 AM, Alberto Díez wrote:

> What is the netfilter preferred way to have a large set of rules and
> still do packet filtering?

I don't know if there's a "netfilter preferred way" and I don't know
what you mean by "a large set of rules".

Our iptables rules typically number about 200.  We use ipsets for
about 40,000 rules in about 30 sets, on fairly modest hardware.

People seem to run into performance issues with anything on the order
of a thousand iptables rules - obviously it will depend on the rules
and how they interact, and on the hardware, the processor load, etc.

--

73,
Ged.

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

end of thread, other threads:[~2008-03-07  8:33 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-03-06 16:06 RV: optimizations for large rule sets Alberto Díez
2008-03-06 21:49 ` Grant Taylor
2008-03-07  8:33   ` G.W. Haywood

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox