Kaaza 2 jammer.

I've always wondered something about the string matching, but never having used it, I haven't researched it enough to know...

Wouldn't netfilter also see the string "KazzaClient" in this email message? I can imagine how that might cause problems if the string matching rules aren't well crafted.

I see in the example posted by Tomasz Wrona that it only applies to tcp packets forwared from the internal interface, narrowing the focus qiute a bit. But wouldn't that also block an email message having that string if sent from an internal machine?

Of course, the sender of that message may have indeed sent it from a client on his internal network, and since I'm reading it, it must have worked as intended.

I imagine placing a string matching rule, like the example, _after_ rules which accept other legitimate traffic (like smtp) would work completely fine.

Looking for eduction on the topic.

Darrell Dieringer - Madison, WI

With any rules you're usually better off accepting 'normal' traffic and very precise matches before trying to catch others. This helps prevent the situation you mentioned, and it also helps with large rulesets to get the common traffic through the firewall with minimal testing necessary. (IE if all 3000 client machines have port 80 access, but only some have 110 and 25, don't waste time and power matching IP's for http)

There are surely counter-examples that will come to mind, but as a general rule putting the most important/common traffic and most specific matches earlier in the chain is better. Especially with things like DNAT to a DMZ, it is easy to break a service by putting a general rule ahead of a specific one, and if there are many rules (or subchains of rules) the cause may not be obvious. Also, with a default DROP policy and mostly ACCEPT rules, you have to be careful where you put a DROP rule in the sequence, unless it is a very specific match.

Finally, in the case of the string match, it takes quite a bit more to search for a string in the packet than to compare IPs in the header, so you DON'T want to have this rule early in the chain if speed is an issue. (and it usually is, isn't it? :^) As an experiment, try a site that measures bandwidth, (like http://bandwidthplace.com/speedtest/ ) then insert a string match rule (with no target, so the packets all continue past it) first in the INPUT chain and try again. I don't have p-o-m added in, so I don't have string match available to me. I'm curious though how much overhead this match actually incurs....

j

Hi folks:
Looking to minimize my time and general frustration levels, I set about
automating my kernel rebuild process ... including doing the *go get kernel*, go patch kernel, make dep, make modules, make bzimage.... its somewhat more complex than that but what I found is that there is a little hook in ./runme if one invokes ./runme with --batch one invokes a loop at line 749 as follows...

# Check to see if there is excluded patches
EXCLUDED=
while [ "$1" = "--exclude" ]; do

    EXCLUDED="$EXCLUDED $2"
    shift
    shift

done

--- Correct me if I'm utterly off base, but does that second shift not close
the loop by making $1 != --exclude for a long list of excluded suite/patches?

I'm trying to run this with patches I know that work (and install well) with a particular kernel .... and my little scripty b0rks at this and misapplies patches that I most definately do not want on my system ... and several that don't apply ...

Alistair Tonner
[email protected]