RE: Kaaza 2 jammer.

RE: Kaaza 2 jammer.

[Darrell Dieringer]

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

> -----Original Message-----
> From: netfilter-admin@lists.netfilter.org
> [mailto:netfilter-admin@lists.netfilter.org]On Behalf Of
> Tomasz Wrona
> Sent: Thursday, January 09, 2003 11:04 AM
> To: netfilter@lists.samba.org
> Cc: lartc@mailman.ds9a.nl
> Subject: Kaaza 2 jammer.
>
>
> Hello,
>
> Some people asked about matching [blocking] Kaaza 2 sessions.
> So try this simple rule:
>
> iptables -I FORWARD -i $internal_interface -p tcp -m string
> --string "KazaaClient" -j REJECT --reject-with tcp-reset
> [Or maybe worth to try -j TARPIT]
>
> In above rule I don't specify separate ports due to dynamic
> port allocation.
> This rule works fine, catches and reset completly Kaaza 1 and 2
> versions.
>
>
> Regards,
> tw

Re: Kaaza 2 jammer.

[Joel Newkirk]

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

problem with ./runme in --batch mode. -- current p-o-m

[Alistair Tonner]

	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
	Alistair@nerdnet.ca