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

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