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
