Re: Kaaza 2 jammer.

[Joel Newkirk <netfilter@newkirk.us>]

On Thursday 09 January 2003 01:58 pm, Darrell Dieringer wrote:
> 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.

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....

> Darrell Dieringer - Madison, WI

j