Re: fully transparent ftp-proxy and other stories...
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:
nat on fxp1 from $NET_INTERNAL to any - { 1.1.1.1, 2.2.2.1 }
So that half the internally originated traffic will appear to come
from one address, and half from the other. The two addresses are from
different providers, and policy routing in the cisco routers will
ensure they're routed out of the correct leased line.
-roy
Re: fully transparent ftp-proxy?
i get the impression you thought i was suggesting rules to express embryo
states. my intention was that the embryo statement merely be an entry point
for traversal of embryo trees.
the syntax could look something like this (without the macros defined):
# an embryo tree addressable by the name ircproxy from userland that
# checks that the initial packet is in fact an initial packet and will
# modulate state on the connection
prestates for ircproxy flags S/SA modulate
# transparent irc proxy
rdr on $int_if from $int_addr to any port 6667 - 127.0.0.1 port 7666
# duh
block in all
block out all
# included so i dont get flamed
pass { in, out } quick on { lo0, $int_if } all
# proxied connections now look like theyre coming from the external
interface
pass out on $ext_if inet proto tcp from $ext_if to any port 6667 flags S/SA
keep state
David Gwynne
- Original Message -
From: 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
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 makes sense to me that they get checked
before the rules as well.
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
what already happens for each packet going through the packet filter, an
additional single comparison is just a tiny fraction. If we'd argue
about half a dozen cpu instructions, we could gain a lot more by
removing a single byte/packet counter. What does pfctl -si show for
'Counters, match'? 1000 rule set evaluations per second? That would mean
1000 additional pointer comparisons per second. Now benchmark how many
such comparisons you can do per second without increasing cpu load by
more than 1%, on a 486/133 if you like :)
The point of an embryonic state inserted by a proxy is that it's an
exception from the static filter policy. If you could allow these
connections using a static rule set, there would be no need for
embryonic states. If you can't, you also have troubles expressing,
statically, _what_ embryonic states to allow. A proxy making use of such
a feature would require access to /dev/pf and it would have to be written
as carefully as authpf, for instance.
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 own tree). you could specify
which
field of the state entry is variable (id still say that remote src port
would be th only one, but its nice to be flexible). you could specify
tcp
flags and state modulation. whatever is needed for connections created
by
the proxy.
I can't think of a case where anything but the source port is missing,
actually. And of course an embryonic state could hold any information a
normal state can (like address translations, timeout values, etc.) or any
information otherwise read from the rule that creates an ordinary state
(like modulation, route-to, etc.)
The proxy wouldn't need to do anything but insert an embryonic state (no
enumeration, reading or changing of tree nodes), specifying a timeout
value after which it's removed if not completed. The whole kernel part
shouldn't get larger than a couple of lines, and the only change
relevant for userland would be an additional ioctl.
There's another way of comparing performance: if you're using embryonic
states with a proxy, you're dealing with connections you want to allow.
You want the firewall to create state and pass the packets of that
connection. Creating a state entry from an embryonic state after doing a
normal state lookup (failing) and a lookup in the embryonic state table
is generally cheaper than walking the rule set and creating state in
that way (assuming you could express a pass keep state rule there for
such connections). If your embyonic state table constantly contains
several thousand entries, the lookup for each new connection will of
course have an impact. The question, in such a setup, is how many times
an embryonic state matches and becomes a normal state, saving a rule set
evaluation (which would always follow a failed state table lookup). I
guess it boils down to the ratio of expected proxy connections vs. newly
created normal states (or blocked connections) per second.
Daniel
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 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 makes sense to me that they get checked before the rules as well. 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 what already happens for each packet going through the packet filter, an additional single comparison is just a tiny fraction. If we'd argue about half a dozen cpu instructions, we could gain a lot more by removing a single byte/packet counter. What does pfctl -si show for 'Counters, match'? 1000 rule set evaluations per second? That would mean 1000 additional pointer comparisons per second. Now benchmark how many such comparisons you can do per second without increasing cpu load by more than 1%, on a 486/133 if you like :) The point of an embryonic state inserted by a proxy is that it's an exception from the static filter policy. If you could allow these connections using a static rule set, there would be no need for embryonic states. If you can't, you also have troubles expressing, statically, _what_ embryonic states to allow. A proxy making use of such a feature would require access to /dev/pf and it would have to be written as carefully as authpf, for instance. 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 own tree). you could specify which field of the state entry is variable (id still say that remote src port would be th only one, but its nice to be flexible). you could specify tcp flags and state modulation. whatever is needed for connections created by the proxy. I can't think of a case where anything but the source port is missing, actually. And of course an embryonic state could hold any information a normal state can (like address translations, timeout values, etc.) or any information otherwise read from the rule that creates an ordinary state (like modulation, route-to, etc.) The proxy wouldn't need to do anything but insert an embryonic state (no enumeration, reading or changing of tree nodes), specifying a timeout value after which it's removed if not completed. The whole kernel part shouldn't get larger than a couple of lines, and the only change relevant for userland would be an additional ioctl. There's another way of comparing performance: if you're using embryonic states with a proxy, you're dealing with connections you want to allow. You want the firewall to create state and pass the packets of that connection. Creating a state entry from an embryonic state after doing a normal state lookup (failing) and a lookup in the embryonic state table is generally cheaper than walking the rule set and creating state in that way (assuming you could express a pass keep state rule there for such connections). If your embyonic state table constantly contains several thousand entries, the lookup for each new connection will of course have an impact. The question, in such a setup, is how many times an embryonic state matches and becomes a normal state, saving a rule set evaluation (which would always follow a failed state table lookup). I guess it boils down to the ratio of expected proxy connections vs. newly created normal states (or blocked connections) per second. Daniel
Re: fully transparent ftp-proxy?
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 embryonic states (ie - embryonic list is null) there is a single pointer comparison. I'll buy that. Then again, if the feature is useful for proxies, it will probably eventually find its way into ftp-proxy, and there will be very few empty embryonic state tables out there. But again, I hate arguing against something based on performance data that is hypothetical. Thus, I'll reserve judgement. The point of an embryonic state inserted by a proxy is that it's an exception from the static filter policy. If you could allow these connections using a static rule set, there would be no need for embryonic states. If you can't, you also have troubles expressing, statically, _what_ embryonic states to allow. A proxy making use of such a feature would require access to /dev/pf and it would have to be written as carefully as authpf, for instance. Actually, now that I try to construct something, it is quite hard to get the block rules correct without some idea like templating. Consider a passive FTP Server protected by a pf firewall: The ephemeral rule is: pass in on $evil_if proto tcp from any port * to $ftp_server port $pasvport uid proxy keep state ephemeral How much can we lock down a rule like this, to limit the damage the proxy can cause? Ideally, we'd want to restrict things so that the source port must be ephemeral, and so that the list of ports acceptible for the $pasvport choice are limited to a fixed range. If the ftp server was on the firewall box, we'd also want to limit things so that only sockets owned by user proxy could be connected to. I can't see a way, short of templating. Now, having argued myself into a complete circle, I'm going to just sit down and shut up for a bit. -kj
Re: fully transparent ftp-proxy?
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 own tree). you could specify which field of the state entry is variable (id still say that remote src port would be th only one, but its nice to be flexible). you could specify tcp flags and state modulation. whatever is needed for connections created by the proxy. I can't think of a case where anything but the source port is missing, actually. I just did, but in a way this is entirely unrelated to the proposed idea. Filter rules are, in their own way, a lot like embryonic states. They contain some information that a state does, but not all. Their other significant difference is that matching a non-quick rule does not determine whether the packet matches. To me this suggests creating embryonic states corresponding to filter rules and arranging them in trees; it feels like it would simplest to have the trees rooted by interface, but that may not be true in practice. At each node of the tree would be an embryonic state. For a packet to progress through the tree, it must be compared to the embryonic states of the children of the node it is currently in. If it matches none of them, the block/pass rule of its current node applies. If it matches one of them, that node becomes the packet's current node. Processing ends when the packet reaches a terminal node or no child of the current node matches the packet. Quick rules would always be terminal nodes. The major difficulty, as far as I can tell, is in creating the tree. No two children of the same node could ever match the same packet or else the ruleset becomes ambiguous. Furthermore, the most efficient tree is probably difficult to determine. Even an inefficient tree would likely take a while to create with a large ruleset, and I don't have any idea how one would insert or delete rules into an existing tree. The advantage, however, is that ruleset evaluation becomes very fast. If the tree is balanced, evaluation should be O(log n). The worst case should be a tree with a root and only terminal children, but that should still be O(n). You lose skip steps with such a case, though, so performance would be worse than it is now. But it feels to me like it should be possible to avoid such a pathological case with good tree construction. -- Kyle R. Hofmann [EMAIL PROTECTED]
Re: fully transparent ftp-proxy?
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 solved with 'embryonic states', a separate list/tree of state entries that lack certain parts (like source ports, which are usually random and not known in advance). After the normal state lookup (if it fails), but before the rule set evaluation, a matching embryonic state would be completed and turn into a normal state. Proxies could insert embryonic states instead of listening for incoming connections, establishing connections and forwarding data between them. Also, embryonic states could include all sorts of address/port translations, so even connections established by the proxy (for instance the ftp control connection) could appear to originate from the real client address through a source address translation. There are many ways proxies could use this feature, potentially making the proxy code much shorter. But there are also security implications, as a state entry bypasses all filter rules. But it's definitely something I want to try. There are several problems to solve, like supporting different kinds of incomplete states while keeping lookups efficient. If they're solved, and the concept works and is safe, I guess ftp-proxy could (optionally, if necessary) use that to become fully transparent. Daniel
Re: fully transparent ftp-proxy?
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 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 still useful. Implemented correctly, it's a second line of defense: it won't allow any packets that I wouldn't otherwise have allowed anyway, but might block some that I am currently forced to allow. Put another way: the fact that you can't spot all invalid packets that might be sent to my FTP server isn't an argument for not blocking those that you can spot... -roy
Re: fully transparent ftp-proxy and other stories...
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 (see archive), and open the port range only on the firewall, which then forwards the data connections to the ftp server. And ensuring no vulnerable service starts listening on a port in that range on the firewall should be possible... Incidentally, the other big thing I get with iptables (that pf lacks, as far as I can tell) is the ability for a rule to match on both the interface that a packet was received on and the interface that it will be forwarded out on. Whilst not a showstopper, it makes the rules a lot simpler and maintainable in the case of a large network (otherwise you essentially have to duplicate your routing table in your filtering rules in order to gain the same effect). I don't understand how the ability to specify both interfaces in a single rule in iptables helps you there. If a connection always comes in through interface A but can leave through B or C, depending on the (dynamic) routing table, how do you write the rule set so it covers both cases and doesn't duplicate the routing table? How is that different from filtering on all three interfaces and allowing connection in on A and out of B and C statefully? Daniel
Re: fully transparent ftp-proxy?
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 still useful. I agree, it's better than no firewall at all. But it's worse than a firewall that reliably blocks access to some vulnerable ports, because the in-kernel proxy could be tricked into opening those ports. Of course, even a wet towel is better than no firewall. Daniel
Re: fully transparent ftp-proxy?
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 feature, there's no additional cost. In any case, I'd expect the number of active embryonic connections to be pretty low in non-pathological circumstances anyway. You would probably want to have a hard-limit though. -d
Re: fully transparent ftp-proxy?
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 baked state entries affects EACH and EVERY packet flowing through the firewall which doesn't match an existing state. If you don't use this facility then the performance impact will be negligible. nonsense. it's one lookup to the second table for EACH and EVERY packet flowing through the firewall which does not match an existing state. And if it's functionality that you need, then (like ftp-proxy) surely the CPU cost is worth the benefit? no. 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.
Re: fully transparent ftp-proxy?
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 comparison, so if someone is not using the feature, there's no additional cost. there is, you just wrote it: A lookup in an empty list/tree would of course equal a single pointer comparison ;-) And since the lookup happens after the ordinary state lookup (and only if that fails), the cost occurs only per connection, not per packet. Compare to the per packet cost of forwarding the connection through userland... well. there is additional cost. we need to take care. we start adding little nifty features here and there, and for itself they all don't cost much. a few doesn't cost much added together gives a noticeable additional cost. I question that it can be done secure at all. Aside from that: people using ftp-proxy in front of a ftp-server which is not NATed make a fault. it's not needed.
Re: fully transparent ftp-proxy?
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 is just plain wrong. please read about the recent problems wrt this in ipfilter and the linux packages.
Re: fully transparent ftp-proxy and other stories...
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 you believe to be secure, not just those you believe not to be. It might conceivably defeat a backdoor that a hacker plants should the FTP server have a vulnerability. Don't underestimate the effectiveness of this -- given that most compromises are made by script kiddies running exploit scripts, anything that stops the script from behaving as expected might save you. And if nothing else the firewall might protect you from configuration errors on your server... [...] you could use ftp-proxy with the reverse proxy diff (see archive) 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? I don't understand how the ability to specify both interfaces in a single rule in iptables helps you there. In my case the routing table is static, and it's largely just a syntactic convenience (but an important one) I currently (in ipchains) find myself doing the equivalent of: pass in on interface_A to long_list_of_networks_behind_interface_B ... which results in a rule that is far more complex than what I am conceptually trying to accomplish. It also means that the long list of networks behind interface B has to be maintained in two places, namely in my static routes and in my packet filters -- and there is a security risk if an error is made editing these lists. iptables allows me to neatly sidestep this issue by defining my rules in topological terms. I can write a rule that applies to packets sent from interface A to interface B without having to hardwire the list of networks into my packet filters. (And the explicit form gets really messy when you have a network routed out of one interface, except for a small subnet of it which sits on another interface.) -roy
Re: fully transparent ftp-proxy?
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 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 level of kernel support such a solution would require. -roy
Re: fully transparent ftp-proxy?
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
Re: fully transparent ftp-proxy and other stories...
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 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 client and forwards the data. If it's the ftp server behind the firewall, you want to modify 227 replies from the server and proxy passive data connections instead. iptables allows me to neatly sidestep this issue by defining my rules in topological terms. I can write a rule that applies to packets sent from interface A to interface B without having to hardwire the list of networks into my packet filters. 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 is annoying, but that's what macros are for. (And the explicit form gets really messy when you have a network routed out of one interface, except for a small subnet of it which sits on another interface.) That can be covered with two simple rules with one netblock each, the second overriding the first, no? Daniel
Re: fully transparent ftp-proxy?
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 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. msg00347/pgp0.pgp Description: PGP signature
Re: fully transparent ftp-proxy?
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 level of kernel support such a solution would require. 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. As far as I can tell, your complaint is logging, which can surely be handled by the ftp-proxy. It can do all sorts of logging. Feed them back to your loghost via a rotate script, or syslog. But at this point, I no longer see what problem you're trying to solve. -kj
Re: fully transparent ftp-proxy?
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 about IP networking and firewalling, I'm getting kind of tired of this. I understand how FTP works, and I understand firewalling. I am not familliar with OpenBSD, and am trying to understand how it would mesh with our requirements. Repeatedly implying that I don't understand IP networking and firewalling is not productive. I agree that your approach is probably adequate. I just feel happier only allowing passive data connections to the server after they've been negotiated on the control connection. Something that linux allows me to do. But on balance it's probably not a big deal. -roy
Re: fully transparent ftp-proxy and other stories...
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 client and forwards the data. If it's the ftp server behind the firewall, you want to modify 227 replies from the server and proxy passive data connections instead. The man page implies that ftp-proxy proxies passive mode data connections as standard (unless -n is specified). Are we talking at cross purposes here? The FTP server has a real, routable IP address. No NAT involved. I don't see why I would need to do anything special. -roy
Re: fully transparent ftp-proxy?
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 archives. As far as I can tell, your complaint is logging, which can surely be handled by the ftp-proxy. It can do all sorts of logging. Feed them back to your loghost via a rotate script, or syslog. Merging the ftp logs and the firewall logs is a workaround, certainly. But at this point, I no longer see what problem you're trying to solve. Not having to rewrite all the scripts that process the logs just because I'm using OpenBSD as my firewall... -roy
Re: fully transparent ftp-proxy and other stories...
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 is annoying, but that's what macros are for. My routing tables are static, so BGP doesn't come into it. The duplication is that I have to specify the same set of networks in the script that sets up the routes and in the filtering rules. Granted it's not the end of the world, I can live with it. But conceptually I'm firewalling domains of machines connected to physical interfaces. I still think it's much cleaner to be able to refer to those domains of machines by reference to the physical interface. I want to be able to say INSIDE, OUTSIDE, DMZ1, DMZ2, and have them guaranteed to correspond to what's physically plugged in to those ports. Curretnly it relies on my not screwing up with my macro definitions. -roy
Re: fully transparent ftp-proxy?
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 still need to have some form of permission given by the ruleset. To implement that however, for it to be effective, you would need to be able to give proxies access to some pf ioctl functions (like adding embrionic states), but not others (like adding rules). I'm guessing this could be accomplished with systrace, but I think some other check in pf_ioctl would be more secure. -- Rukh On Wed, 30 Oct 2002, Daniel Hartmeier wrote: 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 solved with 'embryonic states', a separate list/tree of state entries that lack certain parts (like source ports, which are usually random and not known in advance). After the normal state lookup (if it fails), but before the rule set evaluation, a matching embryonic state would be completed and turn into a normal state. Proxies could insert embryonic states instead of listening for incoming connections, establishing connections and forwarding data between them. Also, embryonic states could include all sorts of address/port translations, so even connections established by the proxy (for instance the ftp control connection) could appear to originate from the real client address through a source address translation. There are many ways proxies could use this feature, potentially making the proxy code much shorter. But there are also security implications, as a state entry bypasses all filter rules. But it's definitely something I want to try. There are several problems to solve, like supporting different kinds of incomplete states while keeping lookups efficient. If they're solved, and the concept works and is safe, I guess ftp-proxy could (optionally, if necessary) use that to become fully transparent. Daniel
Re: fully transparent ftp-proxy?
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 than if you added rules to match the same things. And if you don't like using embrionic states, then you would have an empty embrionic state tree and it would then only require one extra pointer comparison (and seeing that it's NULL), before moving on to evaluating the rule set. And if you were to follow my previous post, you wouldn't even have to evalutate the tree until you found a rule in the rule list that allowed you to do so. -- Rukh On Wed, 30 Oct 2002, Henning Brauer wrote: On Wed, Oct 30, 2002 at 10:24:29PM +0100, Daniel Hartmeier wrote: 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 solved with 'embryonic states', a separate list/tree of state entries that lack certain parts (like source ports, which are usually random and not known in advance). After the normal state lookup (if it fails), but before the rule set evaluation, a matching embryonic state would be completed and turn into a normal state. Uh well, this sounds like a massive performance penalty... I don't think I like that.
Re: fully transparent ftp-proxy?
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 states, then you would have an empty embrionic state tree and it would then only require one extra pointer comparison (and seeing that it's NULL), before moving on to evaluating the rule set. yes. extra cost. a little extra cost here, a little extra cost there, summarized is more than just a little extra cost. msg00358/pgp0.pgp Description: PGP signature
Re: fully transparent ftp-proxy?
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 than if you added rules to match the same things. Though I hate to make performance-based arguments without any code to make an evaluation on, I have to say this makes me feel uneasy. It seems to me the only time the filter would NOT have to search the embryonic state table is: 1) If an existing state is matched 2) If the entire embryonic rule list is empty. So basically, every potentially state-creating packet is going to have to traverse this list. Sure, you can use skip steps to minimize the cost of the traversal, but this still seems like a hell of a hit. And though I like the idea of rule templates, I can't help but wonder if we can't achieve the same thing (limiting what kind of rules a proxy can insert) just by some well-thought-out block [in/out] quick uid foo-proxy rules (assuming the proxy's dynamic rules are added at the end.) -kj
