On 12/9/05, Forrest Aldrich <[EMAIL PROTECTED]> wrote:
> First, does there exist a tidy-like syntax checker for the pf.conf
> file. That would be handy.
pfctl -n
> What I'm trying to do is:
>
> rdr on $ext_if proto tcp from !<geoip>, !<spammers>, !<abuse> any \
> port { $tcp_services } tag INET_DMZ -> $server
I have doubts about negating tables. This syntax is totally wrong;
you cannot specify multiple criteria by seperating them with commas
(to my knowledge). The overall form is disjunctive (OR), you are
trying to make a conjunction (AND).
Perhaps you might make use of negation inside a table, as at the end
of this page:
http://www.openbsd.org/faq/pf/tables.html
Or, you could make packets which match the first criteria have a
temporary label, and have the second rule check for that label and if
they match the second criteria they get a different temporary label,
and so on, so that you use the internal label names to chain the rules
together.
Earlier I discussed making a virtual machine to match packets so that
these conflicts of form can be resolved. Basically the current
firewall model assumes that the rules are of a certain form, and it is
up to you to force them into that form. A virtual machine could take
arbitrary behavior. I know it's possible, since BSDi did it and BPF
is almost enough. It'd also be possible to optimize the rules in
userland, before they are loaded into the kernel --- doing
optimizations in kernelspace seems dangerous to me. In fact, I saw
just recently some work where people were uploading hand-tuned
assembly (with proofs of correctness) for matching packets in
kernelspace.
pf is not the first place where access control rules are forced into
one form or another. In apache, there is an "order" directive that
tells us whether deny or allow rules are processed first. This is
clearly less flexible than a virtual machine and coming up with one
for access control that can be embedded in other applications is among
my list of things to do (if keynote is insufficient, I have to look at
that in depth first).
It would be simple enough to specify arbitrary packet-classification
rules in LISP-like notation (or XML if you find LISP syntax too
simple, too terse, insufficiently arbitrary, or insufficiently
trendy).
One thing I have noted is that the pf syntax tries (and succeeds) in
disguising some of the stages of packet flow through the kernel. That
is, some things which seem simple enough when looking at pf.conf are
difficult or impossible due to the way it's implemented in the kernel.
This difference is especially apparent in the interaction of NAT and
filtering, and in comparison with Linux's netfilter (a/k/a iptables)
and the kernel source.
--
http://www.lightconsulting.com/~travis/ -><- Knight of the Lambda Calculus
"We already have enough fast, insecure systems." -- Schneier & Ferguson
GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B
