Oh well, having just learnt the astonishing truth that OpenBSD CD
images aren't available for download, the (probably unrealistic)
possiblity of deploying an OpenBSD based firewall this Saturday rather
than the planned Linux deployment has just dropped to precisely 0%.
Maybe I'll just play with
Check out the Hut project. It's a FreeBSD implementation of the VRRP
protocol, including Load Balancing via VIP's. There has been a port to
OpenBSD as well (no personal experience).
Looks interesting, but it's not what I'm after.
What I need to be able to do is the equivalent of:
On Fri, Nov 08, 2002 at 03:14:58AM +, Roy Badami wrote:
Sorry to complain, just feel the need to vent my frustration at the
fact that it appears I can't get hold of a copy of OpenBSD at short
notice...
Excuse me? Of course you can. You just grab a few tarballs and do an
install via any
: Daniel Hartmeier [EMAIL PROTECTED]
To: loki [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, November 01, 2002 2:59 AM
Subject: Re: fully transparent ftp-proxy?
On Fri, Nov 01, 2002 at 02:14:58AM +1000, loki wrote:
rather than having an embryo flag on a rule tho, id make it its own
On Fri, Nov 01, 2002 at 02:14:58AM +1000, loki wrote:
rather than having an embryo flag on a rule tho, id make it its own
directive and have it before the normal filter rules, therefore evaluated
before the normal rules. state is checked before rules. since embryo
states are almost states, it
I don't think adding such a mechanism to the rule set improves
performance, quite the opposite. A single pointer comparison (for an
empty tree of embryonic states) is about as cheap as it gets. Look at
Here's that infernal Single pointer comparison again. You mean, if
someone isn't using
On Thu, 31 Oct 2002 17:59:31 +0100, Daniel Hartmeier wrote:
On Fri, Nov 01, 2002 at 02:14:58AM +1000, loki wrote:
having such a rule (or rules) has several other advantages, you could
create several trees, one for each proxy that requires it (include a
mechanism for the proxy to talk to its
The documentation for ftp-proxy seems to imply that it's only
semi-transparent. ie that although it is transparent to the client,
the server sees the connection come from the proxy and not from the
true IP address of the client.
Is this correct, and if so, are there any plans to enhance it to
On Wed, Oct 30, 2002 at 08:41:12PM +, Roy Badami wrote:
It seems to me that whilst it might require a minimal amount of kernel
machinery to permit setup of the outgoing connection from the proxy,
once established it is identical in nature to the incoming
connection...
This could be
I'm not proposing a kernel ftp proxy -- I agree that there are
conditions [...] that are almost impossible to handle correctly.
Actually, I think I'm going to change my mind here (am I allowed to do
that? ;-)
An imperfect kernel FTP proxy (as provided by iptables or ipfilter) is
surely still
On Wed, Oct 30, 2002 at 10:26:24PM +, Roy Badami wrote:
Is that what everyone else does?
Yes. If you can't ensure that the ftp server never has a vulnerable
service listen on a port inside the range used for ftp passive data
connections, you could use ftp-proxy with the reverse proxy diff
On Wed, Oct 30, 2002 at 10:52:28PM +, Roy Badami wrote:
An imperfect kernel FTP proxy (as provided by iptables or ipfilter) is
surely still better than nothing when firewalling an FTP server. If
the userland FTP proxy can't easily be made fully transparent, then a
kernel FTP filter is
Daniel Hartmeier wrote:
On Wed, Oct 30, 2002 at 11:10:18PM +0100, Henning Brauer wrote:
Uh well, this sounds like a massive performance penalty... I don't think I
like that.
A lookup in an empty list/tree would of course equal a single pointer
comparison, so if someone is not using the
On Wed, Oct 30, 2002 at 10:38:09PM +, Roy Badami wrote:
Uh well, this sounds like a massive performance penalty... I don't think I
like that.
More massive than sending your data through a userland daemon?
YES YES YES and YES.
it only affects ftp, while a second table of half
On Wed, Oct 30, 2002 at 11:46:06PM +0100, Daniel Hartmeier wrote:
On Wed, Oct 30, 2002 at 11:10:18PM +0100, Henning Brauer wrote:
Uh well, this sounds like a massive performance penalty... I don't think I
like that.
A lookup in an empty list/tree would of course equal a single pointer
On Wed, Oct 30, 2002 at 10:52:28PM +, Roy Badami wrote:
An imperfect kernel FTP proxy (as provided by iptables or ipfilter) is
surely still better than nothing when firewalling an FTP server.
no it's not. again, you don't get the security implications. ftp connection
tracking in the kernel
Yes. If you can't ensure that the ftp server never has a vulnerable
service listen on a port inside the range used for ftp passive data
connections [...]
I would hope that I am always able to ensure this. But it's a matter
of 'security in depth': you may as well firewall the systems
ftp handling is fine as it is. it belongs into userland as it is.
you do not understand the security implications. read about the recent vulns
in packet filtering packages that have (WRONG WRONG WRONG)
in-kernel ftp connection tracking.
I understand the security implications. I
Aside from that:
people using ftp-proxy in front of a ftp-server which is not NATed make a
fault. it's not needed.
I don't understand. Why is firewalling my FTP server a bad idea?
-roy
On Wed, Oct 30, 2002 at 11:34:16PM +, Roy Badami wrote:
I have to admit that I can't immediately see why ftp-proxy should need
to be patched to allow this. Isn't this just the same as the usual
case?
The usual case is ftp clients behind a NATing firewall, allowing active
data connections
On Wed, Oct 30, 2002 at 11:43:36PM +, Roy Badami wrote:
I understand the security implications. I agree that FTP should be
handled in user space. I want a solution that can be used to firewall
FTP servers.
it is already there. ftp-proxy is not needed for that. you just need to
understand
When all you have is a hammer, everything looks like a nail:
I understand the security implications. I agree that FTP should be
handled in user space. I want a solution that can be used to firewall
FTP servers. I was proposing that this should be done in userspace,
and musing on what
it is already there. ftp-proxy is not needed for that. you just need to
understand how ftp works (and thus what for a fucking stupid protocol ftp
actually is). And heck, even given ftp-proxy is not needed, it does the job
if you insist on doing so.
Please don't assume what I know
The usual case is ftp clients behind a NATing firewall, allowing active
data connections back from the server to the client. ftp-proxy inspects
and modifies the control connection stream so the server makes active
data connections to the firewall's address, and then connects to the
You have a solution. ftp-proxy + reverse diff. (If you don't see the
need for the reverse diff, you're obviously not thinking of both
active and passive connections). Firewalling is achievable.
I admit that at this point I haven't a clue what reverse diff is -- I
will search the
I don't trust routing tables to influence filter rules. You set
securelevel = 2 to prevent filter rules modifications and then some BGP
fuckup opens your firewall wide open? Why do you need huge lists of
addresses in rule sets? I agree that duplicating them on multiple
interfaces
Interesting idea ;)
As I also pointed out, the security could be increased by linking
embrionic states with the filter rules. Like adding an embrionic keyword
or something similar, so that an embrionic state will only try to match if
it matches a permissive filter rule.
That way, the proxies
Actually, there wouldn't be any real performance penalty, because these
embrionic states are in effect only a tree sorted list of one shot rules.
When they match they're removed from the embrionic tree, filled in with
some other details, and moved to the normal state tree. It's just done
faster
On Thu, Oct 31, 2002 at 01:03:23PM +1000, Rukh wrote:
Actually, there wouldn't be any real performance penalty, because these
embrionic states are in effect only a tree sorted list of one shot rules.
oh yes, and the lookup is absolutely for free, sure.
And if you don't like using embrionic
Actually, there wouldn't be any real performance penalty, because these
embrionic states are in effect only a tree sorted list of one shot rules.
When they match they're removed from the embrionic tree, filled in with
some other details, and moved to the normal state tree. It's just done
30 matches
Mail list logo
