On 29/02/2004, Ed White [EMAIL PROTECTED] wrote To [EMAIL PROTECTED]:
Until the state created by the above rule is in the table, PF will behave like
if the following rule had been added.
pass in inet proto tcp from $server to $user
this is like 'related' in iptables, tho those ppl try to do
On Sun, Feb 29, 2004 at 11:14:53PM +0100, Ed White wrote:
At the moment PF needs the help of a proxy to accept connections that start
from an external source. This means that we use ftp-proxy (for active ftp) to
analyze the control connection (from the client to the server) to accept the
It's an interesting idea. It's kind of a philosophical issue. Do you only
allow what's most secure, or do you setup a framework that allows more risks
to be taken if desired. I tend to like the latter, but setting up and
maintaining an entire framework is a lot of work...
It would definitely
Hi,
I'm not sure whether Ed's idea would be the best way to do it, but it
raises a very good question that makes pf sometimes not useful as it should be.
When one setups a firewall, I agree that it can be globally the same whether
FTP is transparent proxified through user space proxy or directly
I think part of the bigger issue are applications other than FTP. I
personally would love to host servers for games that dynamically assign
outgoing ports to clients after the client authenticates via a static port
(example: Tribes 2 uses port 25000 for initial authentication, but after
that the
* David Chubb [EMAIL PROTECTED] [2004-03-01 21:36]:
As it is I can force Tribes 2 to use a range of ports for players and I have
poked holes for that range...this is by far not the best security method
though and not all applications allow for forcing a static range of ports.
so?
the only
* Julien Bordet [EMAIL PROTECTED] [2004-03-01 21:35]:
However, when one does bridge traffic shaping, this is not the same thing
at all : proxifying means that your are not bridging any more, using a IP
address for the bridge, and so on. I really think it is a very dirty
solution. The kernel
Henning Brauer wrote:
* Julien Bordet [EMAIL PROTECTED] [2004-03-01 21:35]:
However, when one does bridge traffic shaping, this is not the same thing
at all : proxifying means that your are not bridging any more, using a IP
address for the bridge, and so on. I really think it is a very dirty
On Mon, 1 Mar 2004, Julien Bordet wrote:
In fact, even if it does not really matter to you in fact, I'm not
talking about a kernel proxy here. I'm talking about something smart
enough to tag packets related and so to pass them. If we go on with
FTP, a piece of code that attach data
On Monday 01 March 2004 22:22, Henning Brauer wrote:
the only place to solve this is obviously writing a proxy.
wether that is in kernel or not doesn't change a shit.
well, except for the tiny detail that a security problem in your
userland proxy doesn't give the attacker remote root... and it
* Julien Bordet [EMAIL PROTECTED] [2004-03-01 23:31]:
Henning Brauer wrote:
* Julien Bordet [EMAIL PROTECTED] [2004-03-01 21:35]:
However, when one does bridge traffic shaping, this is not the same thing
at all : proxifying means that your are not bridging any more, using a IP
address for the
* Ed White [EMAIL PROTECTED] [2004-03-02 00:11]:
On Monday 01 March 2004 22:22, Henning Brauer wrote:
the only place to solve this is obviously writing a proxy.
wether that is in kernel or not doesn't change a shit.
well, except for the tiny detail that a security problem in your
userland
[EMAIL PROTECTED] wrote:
A piece of kernel code smart enough to inspect packets comprising
a partular protocol, and extract enough information to determine if
they are, in fact related is exactly what Henning is referring to
as a kernel proxy
Ok, that is what Henning calls a proxy. But this is
On Mon, Mar 01, 2004 at 11:21:55PM +0100, Julien Bordet wrote:
As I said, there may a user land solution. Some kind of global user
space advisor daemon, helping packet filter to make complicated
decisions, for example.
Having a userland program doing blocking operations on kernel packet
flow
On Mon, Mar 01, 2004 at 11:21:55PM +0100, Julien Bordet wrote:
Again, I agree. But that does not resolve the issue. Please consider the
case I'm talking about (Bridge, ...). What we need is a OpenBSD
solution. We do one of the best packet filter available, make bridging
surprisingly easy,
On Tue, 2 Mar 2004, Kory T wrote:
I'm sure portknocking has been discussed in this list before but has
anyone actually tried it with pf? At first I didn't think it was a
good idea since the patterns can be sniffed until I viewed the whole
concept of it on portknocking.org and the example
Kory T wrote:
I'm sure portknocking has been discussed in this list before but has
anyone actually tried it with pf? At first I didn't think it was a
good idea since the patterns can be sniffed until I viewed the whole
concept of it on portknocking.org and the example perl source they
have
17 matches
Mail list logo
