Selective connection tracking - to be or not to be? :)
Fri, 7 Jul 2000 14:27:48 -0500 (CDT)
> 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
> 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
> 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
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
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
i +can+ understand +now+ _your_ need for the feature, but if its
that is specific to your wants/desires then you may have to bite the
if rusty isnt willing to put it in and code it yourself. (having to do
we speak with some sbc's/embedded stuff and FreeBSD but thats another
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
> 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
> guns. It does not matter who use it - but it matters _how_. You
> 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
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
> all packets in log and then use them to perform _accounting_.
> 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
> and/or hardware - I cannot trust to "super puper smart intrusion
> or "unbreakable firewall" from company XXX, supplied like a black
> 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
> but I like to control it by _myself_, I still cannot trust to
> 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
Netfilter is jst anothr subsystem. if you want control of it to add
then maybe its time to get your hands dirty ;>
> What I want is not additional feature (strictly speaking), it is
> option to turn _existing_ feature on or off - nothing more. Yes, it
> 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
as you yourself stated, you want to control every 'address, port,
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
> well and don't need to spend time to study how it is implemented. If
> have a little bit more time I would implement this by myself, but -
> reason for my letter was: it seems that Rusty has something
> so why I should spend my time to implement something that would not
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
> it seems that development of netfilter (and kernel too) is going in
> "We are discussed and _I_ decided"...
well, thats the entire linux thing there in a nutshell, linus has final
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
something cause you think it wont get accepted isnt the way to win
and influence people ;P
> > of course i respect your opinions, jst please dont take it badly if
> > 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 ;)