Joel Newkirk wrote:
But newer implementations apparently support port-hopping, so it seems that the only confirmed way to stop it with iptables is with the STRING match from patch-o-matic, and block anything with the string "kazaa" (don't recall case requirements) in it. Compiling a custom kazaa-blocking kernel may be more than you want to do, though.
This strikes me as a pretty bad idea; it'll block more than just kazaa packets. For one thing, it would block a description of how to implement the block, unless it were obfuscated to get past itself, which seems silly to me. And maybe people talking about kazaa also. And even random binary sequences aren't that unlikely to have problems. The odds of a given seven random bytes matching are only 1/2^(5*8)=1/2^40. But if you transfer 1GB/day, multiply that by (2^30)/5. Then you're talking about odds of 5 in 1024 that you'll have at least one random packet blocked per day. I predict emails, compressed files, etc. that won't transfer for no apparently reason because part of it consistently won't transfer.
Also, if the primary bottleneck is outbound, you might find that using the mangle table in prerouting to set TOS for certain desirable traffic and enacting pfifo queuing discipline will help a great deal - IE change TOS to a favorable value (0x10 perhaps) for specific traffic like HTTP SMTP POP3 IMAP or any VNC or such and then setting TOS to a 'bulk traffic' value (0x02 for example) for the remainder, or for the P2P traffic if it is identifiable. The pfifo qdisc will always send the 0x10 traffic, and send 0x02 only if there is nothing else waiting to be sent.
I like this much more. It solves the real problem of bandwidth usage while still allowing them to do it. And I'll guess that the port hopping only moves on if it doesn't work, not if it has a less favorable TOS value. So it will stay on the easily-identifiable ports. Or like you said, you could increase the TOS for packets you're sure aren't P2P stuff if that doesn't work out. Scott
