On Wed, Oct 30, 2002 at 01:38:59PM -0300, Helio Alexandre Lopes Loureiro wrote:
How I said, keep state looks like not working properly
nonsense.
On Wed, Oct 30, 2002 at 07:13:17PM +0100, Per olof Ljungmark wrote:
At 18:42 10/30/2002 +0100, Henning Brauer wrote:
On Wed, Oct 30, 2002 at 01:38:59PM -0300, Helio Alexandre Lopes Loureiro
wrote:
How I said, keep state looks like not working properly
nonsense.
To make this a yes
On Wed, Oct 30, 2002 at 03:38:37PM -0300, Helio Alexandre Lopes Loureiro wrote:
A stateful firewall is not designed to keep a pass rule over all
interfaces?
no. in practice the state is hammered to the interface, which is a very very
very good thing (I rely on it for the firewalls in front of
no. in practice the state is hammered to the interface, which is a very very
very good thing (I rely on it for the firewalls in front of the server
networks here whoch has tons of vlan interfaces. on the external interface I
do spoof protection - out: src must be from an internal net, in:
Hello, All. I have two bridging firewalls that provide redundancy via stp. I
am looking for something that will give me statistics on how much traffic is
going through the bridge by IP. In other words I want to be able to tell who
(by IP address) is using what bandwidth. I have
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
NoRouteIPs={0.0.0.0/32, 10.0.0.0/8, 127.0.0.0/8, 169.254.0.0/16,
172.16.0.0/12, 192.168.0.0/16, 204.152.64.0/23, 224.0.0.0/3,
255.255.255.255/32 }
Note that 224.0.0.0/3 already includes 255.255.255.255/32.
Specifically, it encompasses the Class D (multicast) addresses
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
I've just read Daniel's interview (damn slashdotted server!!). And I
found that comented that load balancing was left out only because of
patents. A couple of monthes ago we discussed about making multi NAT
rules with the possiblility of turnin on and off some IP. Is this also
covered by such
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
