RE: iptables analyzer

RE: iptables analyzer

[Daniel Chemko]

In all honesty, the tool may have limited small scale benefits, but the
only way to scale into bigger projects would be to write a firewall
structural design before even implementing the rule structure.

1. The analyzer needs to be able to predict the load of each protocol /
rule match in order to 'order' the rules in the most effective manner.

EG:

Rule #1: 5% of the traffic
Rule #2: 10% of the traffic
Rule #3: 85% of traffic
This is a non-optimized ruleset, but unless the analyzer can use
historical data, the effectiveness of this optimizer is diminished.
Ideally, a history based ruleset analyzer would reorganize the rules in
the following order:

Rule #3
Rule #2
Rule #1
But! Now, this may break the actual logic of the program as well, so you
have to allow for making historical rule adjustments while taking into
account the correctness of the ruleset flow. Making this work for larger
set of rules and for dynamically adjusting based on short term forecasts
would start with head starting to hurt then my going to bed all dizzy
and such.


2. Complex rulesets with large numbers of branches and conditional rules
would cause killer complexity, and the changes to that structure would
blow away any non-trivial iptables ruleset creation tools.

EG:

A->B
A->C (!A->B)
A-R1 (!A->B & !A->C)
A-R2 (!A->B & !A->C & !A-R1)
A-R3 (!A->B & !A->C & !A-R1 & !A-R2)
B-R1 (A->B)
B-R2 (A->B & !B-R1)
B-R3 (A->B & !B-R1 & !B-R2)
B->D (A->B & !B-R1 & !B-R2 & !BR3)
C-R1 (!A->B & A->C)
C->D (!A->B & A->C & !C-R1)
D-R1 (((A->B & !B-R1 & !B-R2 & !BR3)) | (!A->B & A->C & !C-R1))

If you can parse the args, return the correct structural dependencies of
each rule throughout the path to the end of the ruleset then actually
optimize the ruleset for the best efficiency (which can vary depending
on the needs of the firewall), I will surely come visit whatever corner
of the world you are from and offer you a b33r, because you would surely
deserve it!

Remember, the dependencies of each rule are compounded with the existing
rules that did not pass the filter, which is assuming that the jumps
relinquished control over the packet, but as log, some rules pass
control back to the branch changing the packet's state and continues!
All this must be accounted for!


3. Programming in functionality that intelligently uses the iptables
extensions would bloat the program to a dramatic extent. 

Well, but now, I imagine you get the difficulty of this point as well.

Re: iptables analyzer

[Jeffrey Laramie]

[-- Attachment #1: Type: text/html, Size: 5511 bytes --]

Re: iptables analyzer - but slightly OT

[SBlaze]

You would have to have a complete dataset from every packet that
passesnetfilter to run any kind of rule analysis. Knowing which rule droppeda
packet isn't the same as knowing exactly which condition of that rulecaused the
drop. Could be iface, dport, sport, etc. You would almosthave to duplicate the
logic of netfilter itself to do any meaningfulanalysis at this level. However I
think a simpler but still useful toolcould be created by using the packet and
byte count kept by netfilterto sort rules within chains
  

Jeff

I agree with Jeff here. In fact I have been thinking about this for some time..
I even attempted something with bash script to do this...but my scripting
capability is not up to par..

Upon really thinking about it.... if I could just do a continuous iptables
-vxnL   I would be happy. Perhaps some added counters for in which the the
differences are shown from the last time it is last checked... say like a 5-10
second delay?

Sort of a iptop heh.... an iptables in... top like display...

This is my dream!
SBlaze



=====
In the absence of order there will be chaos.

__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/

Re: iptables analyzer - but slightly OT

[Jeffrey Laramie]

SBlaze wrote:

>
>Upon really thinking about it.... if I could just do a continuous iptables
>-vxnL   I would be happy. Perhaps some added counters for in which the the
>differences are shown from the last time it is last checked... say like a 5-10
>second delay?
>
>Sort of a iptop heh.... an iptables in... top like display...
>  
>

I think this is a very cool idea that should be much easier to implement 
than any kind of rule analyzer. Even better, you could calculate the 
delta between -vxnL readings and drop it into a graph that updates at 
user defined intervals, kinda like the bar graph model used in spectrum 
analyzers. You could "see" traffic on each rule in real time and know 
instantly if a particular rule was getting pounded. Maybe set "alarm" 
limits based on % of historical traffic or a user defined level. Set a 
longer (daily) interval and it would produce the kind of output Chris 
Brenton could use with a bar for each of his reject rules. Perhaps an 
option to normalize average traffic to a straight line so that abnormal 
traffic would look like "static" with positive and negative deflection 
from the x-axis. Ooohhh, my head is spinning . . .

Jeff

Re: iptables analyzer - but slightly OT

[SBlaze]

--- Jeffrey Laramie <JALaramie@Loudoun-Fairfax.com> wrote:
> SBlaze wrote:
> 
> >
> >Upon really thinking about it.... if I could just do a continuous iptables
> >-vxnL   I would be happy. Perhaps some added counters for in which the the
> >differences are shown from the last time it is last checked... say like a
> 5-10
> >second delay?
> >
> >Sort of a iptop heh.... an iptables in... top like display...
> >  
> >
> 
> I think this is a very cool idea that should be much easier to implement 
> than any kind of rule analyzer. Even better, you could calculate the 
> delta between -vxnL readings and drop it into a graph that updates at 
> user defined intervals, kinda like the bar graph model used in spectrum 
> analyzers. You could "see" traffic on each rule in real time and know 
> instantly if a particular rule was getting pounded. Maybe set "alarm" 
> limits based on % of historical traffic or a user defined level. Set a 
> longer (daily) interval and it would produce the kind of output Chris 
> Brenton could use with a bar for each of his reject rules. Perhaps an 
> option to normalize average traffic to a straight line so that abnormal 
> traffic would look like "static" with positive and negative deflection 
> from the x-axis. Ooohhh, my head is spinning . . .
> 
> Jeff
> 
Again I concur with ya Jeff. The options I suggested would be great building
blocks for...further statistical and analytical advacnment of the
iptables/netfilter firewall. Let's face it, us geeks like numbers. I'm amazed
that this has never come up before or hasn't already become a part of iptables.
We want real time data... and be able to shape it however we want..be it
console display, SQL databases, or any other means. We like options and access
to data even if we don't use those options. 

However what we like and what we can get are sometimes very different. We have
all these really great ideas. Getting developers to acknoledge that this is a
nice feature and perhaps would be invalueable to some is not always easy. I
believe you said you don't program Jeff and neither do I. It may be difficult
to get deverlopers to take note of this..since they may not consider it "vital"
to the iptables core.

I will be the first to admit I really want this. I just hope what I want is
shared throughout the community so that in versions soon... iptables will have
easier  ways to analyze what it does. Jeff and I think the simplest point is
-vxL...anyone else out there post up on this. If we get enough support we can
go  about communicating to the developers a growing need. Otherwise Jeff and I
just might be on our own.

God Bless the OS Community and the makers of iptables/netfilter
SBlaze




=====
In the absence of order there will be chaos.

__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/

Re: iptables analyzer - but slightly OT

[Alistair Tonner]

On October 29, 2003 04:21 pm, SBlaze wrote:
> --- Jeffrey Laramie <JALaramie@Loudoun-Fairfax.com> wrote:
> > SBlaze wrote:
> > >Upon really thinking about it.... if I could just do a continuous
> > > iptables -vxnL   I would be happy. Perhaps some added counters for in
> > > which the the differences are shown from the last time it is last
> > > checked... say like a
> >
> > 5-10
	
	If you throw a -Z in there you clear the counters in iptables.
	you could accumulate the counters internally and map the differences.
	... You would have to do some fancy stuff with 
iptables-save/awk/sed/iptables-restore afterwards to put the counters back 
though.
	

> >
> > >second delay?
> > >
> > >Sort of a iptop heh.... an iptables in... top like display...
> >
> > I think this is a very cool idea that should be much easier to implement
> > than any kind of rule analyzer. Even better, you could calculate the
> > delta between -vxnL readings and drop it into a graph that updates at
> > user defined intervals, kinda like the bar graph model used in spectrum
> > analyzers. You could "see" traffic on each rule in real time and know
> > instantly if a particular rule was getting pounded. Maybe set "alarm"
> > limits based on % of historical traffic or a user defined level. Set a
> > longer (daily) interval and it would produce the kind of output Chris
> > Brenton could use with a bar for each of his reject rules. Perhaps an
> > option to normalize average traffic to a straight line so that abnormal
> > traffic would look like "static" with positive and negative deflection
> > from the x-axis. Ooohhh, my head is spinning . . .
> >
> > Jeff
>
> Again I concur with ya Jeff. The options I suggested would be great
> building blocks for...further statistical and analytical advacnment of the
> iptables/netfilter firewall. Let's face it, us geeks like numbers. I'm
> amazed that this has never come up before or hasn't already become a part
> of iptables. We want real time data... and be able to shape it however we
> want..be it console display, SQL databases, or any other means. We like
> options and access to data even if we don't use those options.
>
> However what we like and what we can get are sometimes very different. We
> have all these really great ideas. Getting developers to acknoledge that
> this is a nice feature and perhaps would be invalueable to some is not
> always easy. I believe you said you don't program Jeff and neither do I. It
> may be difficult to get deverlopers to take note of this..since they may
> not consider it "vital" to the iptables core.
>
> I will be the first to admit I really want this. I just hope what I want is
> shared throughout the community so that in versions soon... iptables will
> have easier  ways to analyze what it does. Jeff and I think the simplest
> point is -vxL...anyone else out there post up on this. If we get enough
> support we can go  about communicating to the developers a growing need.
> Otherwise Jeff and I just might be on our own.
>
> God Bless the OS Community and the makers of iptables/netfilter
> SBlaze
>
>
>
>
> =====
> In the absence of order there will be chaos.
>
> __________________________________
> Do you Yahoo!?
> Exclusive Video Premiere - Britney Spears
> http://launch.yahoo.com/promos/britneyspears/

-- 

	Alistair Tonner
	nerdnet.ca
	Senior Systems Analyst - RSS
	
     Any sufficiently advanced technology will have the appearance of magic.
	Lets get magical!