Selective connection tracking - to be or not to be? :)

[Stef telford]

> On Fri, Jul 07, 2000 at 01:14:35PM -0500, Stef telford wrote:
>   Hey... What you are talking about? :) I mean not tracking of log
>   files, _connection state tracking_ records in Netfilter :) Sure I
cannot
>   do this with awk etc...

damnation man...all this talking of benchmarking and logging got
us thinking that you were talking about the output into your logs
!gah! (thanks to daniel for pointing that out ;)

oh well. me bad. ;)

>   To be clear: I would like to have an option to turn connection state
tracking
>   on or off based on rules - like address, port, protocol etc.

well, connection tracking doesnt make sense due to some protocols
(udp for one) imo. due to its very nature you may not have a connection
TO track, but thats splitting hairs. 

adding in all sorts of rules would add complexity for a relatively
little trade off (imo). is it a 'worthy cause' to add in a feature that
99%
of people wont even know is there / use and add in more codebase
to what you (ideally) want to be a fast segment of code ?!

if you have the netfilter in a tight loop (and i cant speak from
netfilter
here jst experience) then you dont WANT a lot of conditionals. every
check will take some time. In most systems you are fine (say X) as its
already 'big and bloaty' (sorry xfree ;) but in embedded stuff every
micro (or pico ;) second counts. adding in conditionals to netfiltering
code when there is not really a HUGE call for it will jst add in
lagtime.
 
i +can+ understand +now+ _your_ need for the feature, but if its
something
that is specific to your wants/desires then you may have to bite the
bullet
if rusty isnt willing to put it in and code it yourself. (having to do
this as
we speak with some sbc's/embedded stuff and FreeBSD but thats another
story ;)

otherwise, it will probably fall down to someone else to write userland 
programs (or netfilter modules) to hook into the system and do it. Afaik
the netfiltering code allows modules to do this doesnt it ?! 

that may be your solution there ?! dont know for sure, but its jst a
thought.

>   Yes, you are missing :) May be you thought that I am talking about
>   logging, but I am not.

domo arrigato. ;)
 
> > (if you are using connection tracking as a 'security
> > measure'
> > for cracking attempts than you have missed the point of it somewhat
;)
>   Again, you misunderstood me :)

aaah...not this time, jst trying to illustrate that some people 
use the wrong tools for the wrong job (which ironically came
back to haunt me in that last email ... go figure ;)
 
>   In our case we are talking about protection ("cevlar vest"), not
about
>   guns. It does not matter who use it - but it matters _how_. You
cannot
>   hurt someone if you use vest in improper way - you only can hurt
>   yourself. Firewalls are _not_ guns (and I hope they will never be).

there was a thread all about 'active firewalls' not so long ago, the
reject vs drop arguement ;>, but hopefully thats died down now.

Basically, i would prefer (to further kill the analogy) to have a small
lightweight kevlar than full suit of armour. sure, full armour stops
more
than kevlar, but its huge, bulky and totally overkill for most of the
'normal' situations in modern life, plus if you put on armour wrong
then its actually worse than useless, it allows your enemies to focus
on your weak spots (achilles heel anyone?)

wow. that metaphor is dead, lets leave it alone ;)
 
>   I remember someone (not an idiot, though) who use ipfwadm -l to
store
>   all packets in log and then use them to perform _accounting_.
Stupid,
>   isn't? But...

icky ack! if nothing else, anyone getting the log could then see 
trusted hosts connecting. thats got to be a 'bad thing' (Tm).

>   No, I am realist, and I like when I have _full_ control over
software
>   and/or hardware - I cannot trust to "super puper smart intrusion
detection"
>   or "unbreakable firewall" from company XXX, supplied like a black
box
>   without source code of software and without decription of hardware.
>   
>   This is the reason why I use Linux, this is the reason why I use
Netfilter,
>   but I like to control it by _myself_, I still cannot trust to
software that
>   think that it can guess what I want and then do it properly :)

fair enough, but you do trust the VM and I/O subsystems to perform
'in your best interests'. a bit of a convulated point, maybe, but a
valid one.
Netfilter is jst anothr subsystem. if you want control of it to add
'features',
then maybe its time to get your hands dirty ;>
 
>   What I want is not additional feature (strictly speaking), it is
just an
>   option to turn _existing_ feature on or off - nothing more. Yes, it
would
>   require a little work - but not so much, I think. 

well, personally i think it +would+ require more work, but thats only
due to the amount of conditional or dialectric logick that you would
place into the code. of course, i may be wrong and happy to be proved
otherwise, but the amount of control you want isnt jst a simple 'on or
off'.
as you yourself stated, you want to control every 'address, port,
protocol etc.'

that DOES sound like a lot of work for a relatively small payoff imao ;)

> At least not so much
>   for Rusty or someone on the Core Team - because they know internals
very
>   well and don't need to spend time to study how it is implemented. If
I would
>   have a little bit more time I would implement this by myself, but -
the main
>   reason for my letter was: it seems that Rusty has something
_against_ this,
>   so why I should spend my time to implement something that would not
be accepted?

becuase then you can maintain a patch and keep submitting it to rusty
for addition. remember DevFS and all the debacle there, yet eventually
it got in, depsite all the objections raised by 'notable developers'.

so there IS a point in making a patch, if nothing else you can maintain
it for your system and update it as and when if anyone else uses it. 
its giving something back and all that jazz.

>   See above - why :) First I've to be sure that it will be accepted
:), but
>   it seems that development of netfilter (and kernel too) is going in
direction
>   "We are discussed and _I_ decided"...

well, thats the entire linux thing there in a nutshell, linus has final
say
over the entire linux kernel, rusty (if he has veto power) has it as he
wrote the netfilter subsystem. 

seems to make pretty purfect sense to me. *shrug* then again, NOT
writing
something cause you think it wont get accepted isnt the way to win
friends
and influence people ;P
   
> > of course i respect your opinions, jst please dont take it badly if
our
> > opinions 'clash' ;p
>   Sure :) It is just a discussion :)

thank god for a voice of sanity =)
most kernel discussions end up becoming religious affairs,
that normally get worse whenever I mention another *NIX ;)

deepest regards,
Stefs