Re: Blocking p2p via pf
On Oct 11, 2005, at 11:15 AM, David Elze wrote: Hi, I'm trying to block p2p traffic via pf on OpenBSD 3.x. Unfortunately, all new p2p-clients are able to use dynamic ports or even (ab-)use http-ports etc. so blocking well known p2p-ports is not enough. http://marc.theaimsgroup.com/?l=openbsd-pfm=104592911709710w=2 -- Jason Dixon DixonGroup Consulting http://www.dixongroup.net
Re: Blocking p2p via pf
On Tue, 11 Oct 2005, Jason Dixon wrote: On Oct 11, 2005, at 11:15 AM, David Elze wrote: Hi, I'm trying to block p2p traffic via pf on OpenBSD 3.x. Unfortunately, all new p2p-clients are able to use dynamic ports or even (ab-)use http-ports etc. so blocking well known p2p-ports is not enough. http://marc.theaimsgroup.com/?l=openbsd-pfm=104592911709710w=2 While auth/socks and accountability is your long term solution; for a quick stopgap: http://www.webweaving.org/kzdetect/ http://wleiden.webweaving.org:8080/svn/node-config/factory/trunk/kzdetect/ may help. Dw.
Re: Blocking p2p via pf
--On 11 October 2005 17:15 +0200, David Elze wrote:
Apart from blocking ports I just see two possibilities:
[..]
You might investigate how many source states users would normally use
for permitted protocols, how many states are involved with
non-permitted use, and (ab?)use max-src-states with an overload table
to try and contain the problem. Expect both false positives and false
negatives. beck@ recently suggested using overload tables in
conjunction with a http redirector to a website saying you've been
{evil|stupid} paraphrasing :) which may be appropriate depending on
your client base...
- slow connections down very hard on well known
p2p-ports, so the p2p-clients can connect but
don't get speed at all (still, other dynamic
ports could be used)
that's not a bad idea, but over time I'd not be surprised to see
software to test speeds on different ports in an attempt to circumvent
this type of thing.
Some other ideas involve proxies - either block everything except to
trusted proxies, or permit other traffic but heavily throttle it.
Re: Blocking p2p via pf
I don't know if pf can do this, but I've seen ISPs throttle connections
the longer they're open. This allows legitimate traffic like HTTP to get
their small webpage, but larger downloads (such as P2P, but also large
HTTP downloads) take exponentially longer.
This can still be circumvented by stopping and resuming p2p downloads, but
it catches the less savvy p2p users. I agree that the real long term
solution is to use a content proxy.
ml
On Tue, 11 Oct 2005, Stuart Henderson wrote:
--On 11 October 2005 17:15 +0200, David Elze wrote:
Apart from blocking ports I just see two possibilities:
[..]
You might investigate how many source states users would normally use for
permitted protocols, how many states are involved with non-permitted use, and
(ab?)use max-src-states with an overload table to try and contain the
problem. Expect both false positives and false negatives. beck@ recently
suggested using overload tables in conjunction with a http redirector to a
website saying you've been {evil|stupid} paraphrasing :) which may be
appropriate depending on your client base...
- slow connections down very hard on well known
p2p-ports, so the p2p-clients can connect but
don't get speed at all (still, other dynamic
ports could be used)
that's not a bad idea, but over time I'd not be surprised to see software to
test speeds on different ports in an attempt to circumvent this type of
thing.
Some other ideas involve proxies - either block everything except to trusted
proxies, or permit other traffic but heavily throttle it.
Re: Blocking p2p via pf
David Elze wrote: Hi, I'm trying to block p2p traffic via pf on OpenBSD 3.x. Unfortunately, all new p2p-clients are able to use dynamic ports or even (ab-)use http-ports etc. so blocking well known p2p-ports is not enough. yep. Apart from blocking ports I just see two possibilities: - slow connections down very hard on well known p2p-ports, so the p2p-clients can connect but don't get speed at all (still, other dynamic ports could be used) - try to look into each datagram and scan for typical p2p-stuff (what is typical, this approach would cost to much computing time) - think outside the traditional box. :) Any hints? Unfortunately, I didn't find a lot of stuff regarding this exept the well known 'iptables-p2p' which is a match module for iptables but hey, I love pf :-) If there are too many IP addresses and ports to effectively block, maybe look for something else...like, maybe mangle the DNS queries. One tiny little DNS block, and kazaa goes bye-bye. Two, and AIM is blocked. Theoretically, this is a weak solution. However, PRACTICALLY speaking, it's simple and very effective. Other than blocked services opening up alternative entry points, I've not actually seen anyone bypass this system in real life (for example, AOL offered a web-based IM alternative, that required an additional block). It isn't a secure solution, but it seems mighty effective. http://www.holland-consulting.net/tech/imblock.html Nick.
Re: Blocking p2p via pf
On Tue, 11 Oct 2005 20:24:01 -0400, Nick Holland wrote: David Elze wrote: Hi, I'm trying to block p2p traffic via pf on OpenBSD 3.x. Unfortunately, all new p2p-clients are able to use dynamic ports or even (ab-)use http-ports etc. so blocking well known p2p-ports is not enough. yep. Apart from blocking ports I just see two possibilities: - slow connections down very hard on well known p2p-ports, so the p2p-clients can connect but don't get speed at all (still, other dynamic ports could be used) - try to look into each datagram and scan for typical p2p-stuff (what is typical, this approach would cost to much computing time) - think outside the traditional box. :) Any hints? Unfortunately, I didn't find a lot of stuff regarding this exept the well known 'iptables-p2p' which is a match module for iptables but hey, I love pf :-) If there are too many IP addresses and ports to effectively block, maybe look for something else...like, maybe mangle the DNS queries. One tiny little DNS block, and kazaa goes bye-bye. Two, and AIM is blocked. Theoretically, this is a weak solution. However, PRACTICALLY speaking, it's simple and very effective. Other than blocked services opening up alternative entry points, I've not actually seen anyone bypass this system in real life (for example, AOL offered a web-based IM alternative, that required an additional block). It isn't a secure solution, but it seems mighty effective. http://www.holland-consulting.net/tech/imblock.html Nick. dsniff (IIRC a package, certainly a port) contains dnsspoof that will easily let you return 127.0.0.1 as the address for any wildcarded hostname you put in its dnsspoof.hosts file. A certain teenager next door was bewildered about what happened to Kazaa. Just install dsniff on your gateway and edit the file and shazam! BTW HUPping dnsspoof appears to have it not reread the hostlist. I use a script to pkill it and restart it. From the land down under: Australia. Do we look umop apisdn from up over? Do NOT CC me - I am subscribed to the list. Replies to the sender address will fail except from the list-server.
Re: Blocking p2p via pf
From: Nick Holland [mailto:[EMAIL PROTECTED] Theoretically, this is a weak solution. However, PRACTICALLY speaking, it's simple and very effective. Other than blocked services opening up alternative entry points, I've not actually seen anyone bypass this system in real life (for example, AOL offered a web-based IM alternative, that required an additional block). It isn't a secure solution, but it seems mighty effective. Simply for the sake of pointing it out, there is also the IDS method. This comes with the same disclaimer of it being an imperfect solution (false positives being one possible downfall) but carries the advantage that you don't need to focus on IP addresses or ports which can change - you focus on the protocol itself. While we haven't had great results with tracking P2P use with stock Snort signatures, we've found the Bleeding Snort collection to have a lot of capabilities for detection of P2P and spyware traffic. Throw this inline with the snort to pf utilities that were discussed recently in the archives and it makes a respectable way of blocking traffic. We haven't found the false positives level of this to be overly prohibitive either, actually. DS
