* RE: Kaaza 2 jammer. [not found] <565759501.20030109180351@wp.pl> @ 2003-01-09 18:58 ` Darrell Dieringer 2003-01-10 2:18 ` Joel Newkirk 0 siblings, 1 reply; 3+ messages in thread From: Darrell Dieringer @ 2003-01-09 18:58 UTC (permalink / raw) To: netfilter 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Kaaza 2 jammer. 2003-01-09 18:58 ` Kaaza 2 jammer Darrell Dieringer @ 2003-01-10 2:18 ` Joel Newkirk 2003-01-10 3:24 ` problem with ./runme in --batch mode. -- current p-o-m Alistair Tonner 0 siblings, 1 reply; 3+ messages in thread From: Joel Newkirk @ 2003-01-10 2:18 UTC (permalink / raw) To: Darrell Dieringer, netfilter 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* problem with ./runme in --batch mode. -- current p-o-m 2003-01-10 2:18 ` Joel Newkirk @ 2003-01-10 3:24 ` Alistair Tonner 0 siblings, 0 replies; 3+ messages in thread From: Alistair Tonner @ 2003-01-10 3:24 UTC (permalink / raw) To: netfilter 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2003-01-10 3:24 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <565759501.20030109180351@wp.pl>
2003-01-09 18:58 ` Kaaza 2 jammer Darrell Dieringer
2003-01-10 2:18 ` Joel Newkirk
2003-01-10 3:24 ` problem with ./runme in --batch mode. -- current p-o-m Alistair Tonner
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.