[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: blocking new version of kazaa



So many applications revert to trying port 80 in the event their primary
port fails, it really is tough.  Thought about queueing to deprioritize it,
and of course the dreaded company policy?  Given riaa's latest tactics, like
it or not, its not tough to imagine some potential legal risk.

    Brian

----- Original Message ----- 
From: "Oliver Bode" <oliver@x509security.com>
To: <nick@holland-consulting.net>; <misc@openbsd.org>
Sent: Saturday, August 30, 2003 5:31 PM
Subject: Re: blocking new version of kazaa


> This weekend I attempted to follow the advise on dns poisining to block
> Kazaa.... Well I actually used the 8 minute approach provided later in the
> thread by Oblek which I suspected does the same thing.
> http://archives.neohapsis.com/archives/openbsd/2003-07/2302.html
>
> It works fine for the web, but I use dansguardian proxy to filter anyway.
> Kazaa Lite doesn't use port 53 so I don't think this approach works? What
> resolved the problem with Kazaa Lite for me was the following:
> http://www.computing.net/networking/wwwboard/forum/14828.html
>
> The PF rule that kills Kazaa Lite on my local interface is:
>
> block in quick on $PrvIF inet proto { tcp, udp } from $PrivateIPs to any
port
> { 80, 1000 >< 4000 }
>
> Unfortunately this rule kills the web too so you have to use a web proxy
on a
> different port.
>
> At the end of the experiment I came to the conclusion that it is virtually
> impossible to prevent this type of activity altogether. The closest I
think
> you can come is by enforcing a strict firewall that only allows certain
> services and blocks everything else and strict organisational policies
which
> support it.
>
> Oliver