Re: Off-topic venting of frustration (was: fully transparent ftp-proxy and other stories...)
> 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%. This is the funniest thing I have heard in a while. If you were planning on downloading the IMAGE and burning it to a CD, what exactly is preventing you from downloading the tarfiles and burning THEM to a CD? IT'S THE SAME FRIGGIN THING! > 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... In fact, it is EASIER to download a few 10's of megs worth of .tgz files than it is to download a 640M iso image. I can pull them down, burn the cd, and have the firewall installed in the time it takes be to pull down a single RedHat ISO. -kj
Re: Off-topic venting of frustration (was: fully transparent ftp-proxy and other stories...)
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 one of myriad ways, though preferably via a network mechanism. Piece of cake. Despite having CD media available, I, and many others, have done *hundreds* of installs precisely this way, on production machines. What is so difficult about this? Might not have inet access? Who cares?! Since this would presumably be a firewall for other networked machines, why can't you just install via one of them? Please don't complain. Many have gone before. jsyn
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
Off-topic venting of frustration (was: fully transparent ftp-proxy and other stories...)
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 an FTP install, and delay deployment to a future date, but there's no way I can deploy critical infrastructure without install media (particularly in the case of a piece of infrastucture the failure of which would take out my net access). Probably for the best anyway, I guess building a firewall on an unfamiliar OS in a hurry is not the best idea in the world... 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... -roy
Re: fully transparent ftp-proxy and other stories...
On Thu, 2002-11-07 at 21:45, Roy Badami wrote: > Unfortunately (or in reality, fortunately), the prospects of being > multihomed are looking at least possible in the near future, and so > there's a significant chance I'm going to want to do load balancing > NAT, for which I believe netfilter/iptables is pretty much my only > option at present (short of shelling out lots of cash :) > > It's quite tempting to use OpenBSD as my firewall and Linux as my load > balancer, but that's an extra machine and an extra point of failure, > not to mention significant extra complexity... :( 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). http://www.bsdshell.net/hut_vrrpimpl.html http://www.backwatcher.com/~matheny/ -J.
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 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?
> 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 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 Thu, 31 Oct 2002, Henning Brauer wrote: > 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. of course not > > 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. > first let me get some stuff clear in my head. an embryo state is required where we have almost all the information required for a state entry as determined by a userland proxy such as ftp-proxy or tircproxy (ftp and irc seem to be the only offenders i can think of). the most common bit of missing information being the remote hosts src port (this info could make code simpler). the fact that pf in its current state doesnt seem to address this problem well has led to this discussion. tne current idea seems to be having an embryo tree (like the state tree but with wildcards for certain fields) in between the state tree and the rule list. henning has correctly stated that this would give a performance hit. rukh has suggested that instead of having an embryo tree in between the states and the rules, you have a rule that lets pf traverse the tree. therefore, users that dont need it dont get affected by it. 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. 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. im sorry if i havent explained well. fatigue is not a friend when you're trying to be smart. or creative. which is why im going to stop typing now. thanks, David Gwynne.
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
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. 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?
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 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?
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...
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?
> 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?
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?
On Wed, Oct 30, 2002 at 11:45:02PM +, Roy Badami wrote: > I don't understand. Why is firewalling my FTP server a bad idea? I agree with filtering any ports not needed, like privileged ports where unneeded and potentially vulnerable services might listen which you can't disable. As for the port range used for passive ftp data connections, I think it's not worth the effort to achieve the little additional security by obscurity. And it's not more than that. If someone exploits your ftpd, he can easily transfer any data back and forth through the ftp control connection (using legal commands and replies, if the ftp proxy is clever), and tunnel anything through there. If all you want to achieve is break a stupid exploit script that insists on listening on port xyz (within the common range of ftp data ports), just move the range. 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 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?
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?
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 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 to ... 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 and other stories...
On Wed, Oct 30, 2002 at 10:26:24PM +, Roy Badami wrote: > Maybe it's worth it for the added security that a userland proxy gives no no no no. you totally misunderstand. there is no added security in this case. (filtering on the INNER interface, need to reverse in/out if you're filtering on the external one) #ftp.bsws.de - ftp sucks pass out quick on $main_if proto tcp from any to 213.128.133.139 port 21 \ keep state label "213.128.133.139:21" pass in quick on $main_if proto tcp from 213.128.133.139 port 20 to any \ keep state label "213.128.133.139:21" pass out quick on $main_if proto tcp from any to 213.128.133.139 \ port 5 >< 55000 keep state label "213.128.133.139:21" and tell your ftpd to use ports 5..55000 for passive connections. For pureftpd, this is "-p 5:55000" on the command line. then change net.inet.ip.port[|hi][first|last] to not cover the 5..55000 and you are absolutely fine.
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?
On Thu, Oct 31, 2002 at 12:06:26AM +0100, Henning Brauer wrote: > there is, you just wrote it: > > > A lookup in an empty list/tree would of course equal a single pointer > > comparison > > ;-) Yes, I'll go count the number of instructions that occur per packet already, it's Halloween :) > I question that it can be done secure at all. We'd not allow to insert completely blank state templates, of course. I think allowing only to leave out the source port would cover all useful cases, and the packet would have to match both addresses and the destination port to complete the state. And an attacker that spoofs at the right time might complete the state, but he doesn't gain much, as he can't complete the TCP handshake. > people using ftp-proxy in front of a ftp-server which is not NATed make a > fault. it's not needed. There are more uses than just ftp-proxy. In fact, I don't care all that much about servers wanting to log the real client ip, but other translations have interesting potential :) Daniel
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: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?
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: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 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?
> 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?
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. 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... Daniel
Re: fully transparent ftp-proxy?
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? If you don't use this facility then the performance impact will be negligible. And if it's functionality that you need, then (like ftp-proxy) surely the CPU cost is worth the benefit? -roy
Re: fully transparent ftp-proxy?
Minimal? Not even close. It requires the kernel to fully emulate TCP based on the information in the IP datagrams it is seeing. This is almost assuredly impossible to do correctly, and is the basis for just about every "open an arbitrary connection" attack on stateful firewalls that I can think of. so, no. There are no plans. Dangerous proxies like this one belong in userland, period. I think maybe you misunderstand. I'm not proposing a kernel ftp proxy -- I agree that there are conditions, such as commands or responses spanning packets, that are almost impossible to handle correctly. I'm asking whether anyone has considered modifying the userland proxy to fake the connection it makes to the server so that it appears to come from the originating host. Whilst it would (probably) require some kernel hackery to allow such a faked connection to be established, most of the kernel support for such a connection is already there. Once established, that connection is no different from the connection that already exists in the current implementation between the client and ftp-proxy. In both cases, OpenBSD is acting as the endpoint of a TCP connection that is not addressed to it. And due to the symmetric nature of TCP, both connections are indistinguishable, once established. -roy
Re: fully transparent ftp-proxy and other stories...
This could be solved with 'embryonic states' [...] Sounds interesting, and far more general than the simple hack I was envisioning. If there's some way of convincing the kernel to send the initial SYN and accept the SYN/ACK, then all that's needed (if it doesn't already exist) is a means for the userland proxy to create a state entry to simulate an established connection. In the absence of TCP connection state tracking, I image that this would be fairly easy... Anyway, good to see people are thinking about this, but at first sight this seems to be a show stopper for me, and pushes me towards my original plan of using linux and netfilter/iptables. Hmm, I guess maybe I can live with continuing to allow all high numbered ports into my ftp server. At the moment, using linux and ipchains, I have to allow this anyway, and ultimately it's pretty safe since I know that nothing else should be listening on those ports on my ftp server. Is that what everyone else does? Maybe it's worth it for the added security that a userland proxy gives me over my outgoing ftp connections (I don't fully trust anything that does packet-level snooping of the control connection, because of the potential to get confused when commands or responses span packets). 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 guess this functionality could be implemented in userland as a front-end in pfctl, assuming you only care about static routing tables... (I assume the antispoofing is done this way?) Finally (and I realise that this is probably the wrong place to ask this question) if I decide that pf is not ready for me should I be considering ipfilter as an alternative to linux? (Probably on FreeBSD since this is currently one of our infrastructure platforms.)
Re: fully transparent ftp-proxy?
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?
> Is this correct, and if so, are there any plans to enhance it to be > fully transparent? Without a fully transparent proxy, the logs on an > ftp server behind an openbsd firewall would be rendered useless. The proxy is not intended for an ftp SERVER behind the firewall. It is intended for FTP clients behind the firewall. > 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... Minimal? Not even close. It requires the kernel to fully emulate TCP based on the information in the IP datagrams it is seeing. This is almost assuredly impossible to do correctly, and is the basis for just about every "open an arbitrary connection" attack on stateful firewalls that I can think of. so, no. There are no plans. Dangerous proxies like this one belong in userland, period. -kj
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
fully transparent ftp-proxy?
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 be fully transparent? Without a fully transparent proxy, the logs on an ftp server behind an openbsd firewall would be rendered useless. 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... Thanks in advance, -roy
