Selective connection tracking - to be or not to be? :)
Sat, 08 Jul 2000 03:31:20 +1000
> (i have tried to stay out of this, but heres my non-agressive 2cents
> worth anywayz ;)
> Al wrote:
> > All traffic between locations is routed through Linux, and all
> > are trusted, but (there is always but) - I would like to track
> > traffic that is going to _outside_, but _not_ traffic between
> > I am pretty sure this kind of network is not unique, so an option to
> > selectively turn off tracking would be useful. IMHO :)
> but if you want to do this sort of unique connection tracking, then why
> not simply setup awk (or sed or perl or etc etc etc) to jst parse out of
> the 'main log' the connections you want ?!
No, what he means is that connection tracking is simply tracking too many
connections that he does not need to track. This means that is overflowing
the buffer, and connections that he needs tracked, aren't tracked.
> This would seem to be the simplest method as
> a) it requires no code changes during a 'code freeze' (is the kernel
> in this or jst a feature freeze ?)
> b) rusty doesnt have to write any 'nouveaux' features
> c) you have the tools to do this already.
> d) it can be highly selective (more so than if it was a 'feature')
> am I missing something !? connection tracking (afaict) is pretty smart
> already, adding complexity for something that can be done (and in
> my arrogant opinion should be done) in userland is disobeying the
> 'KISS' method ;)
um. if it was selective, though (i.e. a "conntrack" table), it would be good
for situations exactly like this.
> The only thing you wont get by using awk or sed is second by second
> tracking, but since you seem more into the 'benchmarks' then this surely
> isnt a problem. ?! (if you are using connection tracking as a 'security
> for cracking attempts than you have missed the point of it somewhat ;)
> > Anyway you cannot make Netfilter "fool proof" - a lot of people will
> end up
> > in insecure configurations due to misunderstanding, lack of time or
> true (maybe) but there is something to be said between giving
> an 'idiot' a simple 'basic' gun and an advanced machine gun.
> with the first one, the 'idiot' can only (reasonably) hurt himself and
> would be pretty dumb to do so. it would take some doing.
> with a machine gun (or atom bomb) then they stand more chance
> of hurting others (the 'net' infrastructure).
> if you think that this may sound paranoidal, or even derogatory,
> then I advise you to spend more time on an IBM AIX level 2
> helpline ('so i did an rm -rf / to speed up the system' ...etc etc)
> > So, what I am trying to say? Easy - "Computers should not think,
> they should
> > do _exactly_ we want". No option in case of conntrack is something
> > "Users are too stupid to manage their computers". Yes, most of the
> time it is
> > true :), but usually firewalls are configured by someone who has
> > knowledge and/or experience to not misuse the power.
> you would like to think so wouldnt you ;)
> ( that isnt said in any way aggressively against you )
> it seems that you are an optimist in this regard, maybe rusty is
> jst more 'realist' than that.
> *polite shrug* i dont know if rusty will put it in, i dont speak for him
> whatever happens though, I personally would prefer to
> see the netfilter code 'freeze', get shaken about, see any bugs
> remaining squished, and THEN _+maybe+_ start to see new
> features go in.
> *mumble*code freeze*mumble*
> > That's all.
> > Any comments? :)
> one last thing (again said with total sincerity) :
> if you want a feature in the netfilter code, why not send a unified diff
> to rusty ?!
> > NB: May be I am totally wrong but at least I express my _own_
> > and I would like to get some feedback on it.
> of course i respect your opinions, jst please dont take it badly if our
> opinions 'clash' ;p
> deepest regards,
we're in a code freeze? shit!
*looks around frantically*
And remember, some people want/need features, but are unable to write the
code for themselves (must resist the urge to make a "stupid people" quote
... but they aren't</troll>).
Anyhows, it's 3:30am, and I've just read Rusty's netfilter hacking, kernel
hacking and kernel locking HOWTO and drawn all these nice diagrams of
netfilter's internals and stuck them up on my walls, and my pet dog (sorry,
Rusty, no hamster) is starting to appear in visions in my head in a penguin
suit and it's freaking me out.
Kernel Hacker (or at least has aspirations to be)