[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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 -> 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
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
> > 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
> > 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
> > flags and state modulation. whatever is needed for connections created
> > 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