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.
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
--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
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
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:
-
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.
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,
7 matches
Mail list logo
