Re: pf wish list
On 4/13/06, Eric Pancer [EMAIL PROTECTED] wrote: On Thu, 2006-04-13 at 01:26:06 -0500, Travis H. proclaimed... Just some suggestions. Sounds like you should get coding then. I'm developing my own projects, such as DFD, which uses pf. I can only split my time so many ways. Maybe when time permits, I'll submit some diffs. I'll probably start by clarifying some things in the documentation, first. -- Curiousity killed the cat, but for a while I was a suspect -- Steven Wright Security Guru for Hire http://www.lightconsulting.com/~travis/ -- GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484
Re: pf wish list
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
Re: pf wish list
On Thu, 2006-04-13 at 01:26:06 -0500, Travis H. proclaimed... Just some suggestions. Sounds like you should get coding then. 6) A way to simulate packets hitting the filter, so that I may create a regression-test suite for my firewall rules. tcpreplay? That's what I've been using.
Re: pf wish list
On 4/13/06, Travis H. [EMAIL PROTECTED] wrote: Just some suggestions. 2) Sticky queue assignments. Using tags for many purposes gets klunky. This has come up on the list a couple times in the past (at least once by myself). Using tags becomes an art when used for this and eventually you realize that you want tags for more than queues, then you start getting into some really really nasty logic (and end up with huge rulesets). The tricky part of this is the default behaviour. People expect that if they don't assign a queue, it goes into the default queue. Making queues sticky could change this behaviour. I don't have any good suggestions for this other than another keyword (sticky-queue or such...ick). 5) Rules symmetric to nat and rdr. I.E., change dst IP on outbound packets, change src IP on inbound packets. That would be nice, I've certainly found a few instances where I could have used something like this. I may decide to tackle #2 myself at some point - the easiest way to do it is to probably make another rule type other than pass/block and forget about the 'sticky' part as you could at least put the queue rules at the tail of your ruleset then. 'spose I oughta clean up the code I wrote to expose the queues in the state table and submit that diff for review first. --Bill
