Travis H. wrote:
1) Lists be allowed to contain only one value, or none. Requiring
braces when > 1 value and requiring no braces when <2 values are
present is a pain for automated rule generation and should be very
easy to implement.
Lists with one item already work, e.g.
pass in on egress proto tcp to port { http } keep state
I agree with "no entries in a list would be nice" and suggested it some
time ago as well, but it's not as easy as it seems. It would either have
to generate no rule at all, or a nonsensical dummy-route that never
matches a packet. With the example above,
pass in on egress proto tcp to port { } keep state
.. what's that supposed to mean? A packet that goes to a port? Like,
every TCP packet, according to how pf works elsewhere in similar cases?
It's hard to justify a no-match behavior on logical grounds. It's also
hard to justify no expansion to any rule, given that there IS a rule
here and it should stay debuggable ("Dangit! Where are mah rules!").
IIRC it would also be a relatively large change to the pfctl parser, too.
Thinking about it, allowing empty lists may not be such a good idea.
Instead, how about a new keyword "none", which can act as a protocol,
host or port:
pass in on egress proto tcp to port { none } keep state
The advantages would be that it's both clear why this rule does not
match and that it shows up in the list of rules. However, even "none"
has issues... it'd be more than the opposite of "any". I don't consider
this inconsistency too serious, though, since "any" doesn't have any use
other than readability and it's pretty clear from the context what
"none" would mean in every case.
Wrt your item 4), right after my "block log" rule, I sanitize the
traffic with a few "block ... quick" rules before going back to regular
last-match-wins filtering. That way, I can do a
block in log quick to (dmz) label "$nr: block access to DMZ if"
and not care about that kind of traffic later. I think that's easier
than further extending the pf language in this area.
Other than that, interesting suggestions. I hope they are being
considered by TPTB as well. :-)
Moritz
