Re: pf "default deny" compile-time option?
On Sat, Jul 15, 2006 at 09:26:02AM -0500, Travis H. wrote: > On the FreeBSD pf list someone mentioned that they wanted the ability > to have a "default deny" policy with pf, like the old ipf kernel > option. FreeBSD is free to add this option, if they'd like. > That reminded me that I thought the same thing when I started > with pf. I know, I know, it's not a terribly useful setup until the > pass rules get loaded, but by enforcing "default deny" in both pf and > in the rules, you're less likely to forget it in one place or the > other. And yes, I'm aware that it is enabled in /etc/rc before > /etc/netstart is even called. We're not particularly interested in making this change on OpenBSD. http://www.benzedrine.cx/pf/msg07442.html If a user has the power to flush a ruleset (an operation that shouldn't generally take place during regular firewall operations) they can just as easily load a "pass all" ruleset. Root can do stupid things which compromise security. Obfuscation or needles complexity in an attempt to protect yourself from the root account will only make your system less secure. > BTW, the ruleset loaded in /etc/rc could use "set skip" on lo0, and > quick rules, Because the /etc/rc ruleset is only temporary, and quite small, I don't see the point in making performance-related changes to it (particularly performance-related changes that one would have a hard time measuring the effects of) > and make some allowance for DHCP. DHCP uses bpf(4), and is unaffected by pf rulesets.
controlling ext. inbound traffic on int. interface - few doubts/thoughts
Recently I've been writing rules for small router (2 internal interfaces, 1
external, few services running). Originally I didn't thought about
subqueuing (cbq) inbound traffic - I've just set 1 queue for the whole
inbound (1 mbit) on internal interface, so it won't get stalled by other
traffic from int. net to the server itself. Essentially:
altq on $if_100 cbq bandwidth 100Mb queue { if100_extbulk, \
if100_misc, if100_ack, ... other queues }
queue if100_extbulk on $if_100 bandwidth 1Mb cbq
..
other [sub]queues
..
+ appropriate other pf rules/queues/etc.
But then I recalled the 2nd example from PF faq, that actually used
subqueues to shape traffic of inbound traffic. But ... they all had 'borrow'
option - does it even have a chance to work as intended this way ? Inbound
bandwidth is by default limited - wouldn't PF adjust to whatever it receives
in that stream, thanks to 'borrow' ? For instance, consider:
queue if100_extbulk on $if_100 bandwidth 1Mb cbq { if100_eb_1, if100_eb_2 }
queue if100_eb_1 on $if_100 bandwidth 50% cbq(borrow)
queue if100_eb_2 on $if_100 bandwidth 50% cbq(borrow)
Let's assume that the external interface receives some data, routed to
internal interface, where traffic that would go to eb_1 is 5%, but would be
more if not for eb_2. In this case, wouldn't PF simply adapt - eb_2 would
borrow from eb_1, because as far as PF is concerned, there's only as much
eb_1 as it's coming in that 1mbit bulk from ext. interface (and the parent
queue covers all of it) ?
If borrow was ommited, then I guess it should work, assuming transferring
party behaved and slowed down.
Am I thinking right ?
pf "default deny" compile-time option?
Hey, On the FreeBSD pf list someone mentioned that they wanted the ability to have a "default deny" policy with pf, like the old ipf kernel option. That reminded me that I thought the same thing when I started with pf. I know, I know, it's not a terribly useful setup until the pass rules get loaded, but by enforcing "default deny" in both pf and in the rules, you're less likely to forget it in one place or the other. And yes, I'm aware that it is enabled in /etc/rc before /etc/netstart is even called. Also, it's right in line with OpenBSD's "default secure" ideology. BTW, the ruleset loaded in /etc/rc could use "set skip" on lo0, and quick rules, and make some allowance for DHCP. -- ``I am not a pessimist. To perceive evil where it exists is, in my opinion, a form of optimism.'' -- Roberto Rossellini http://www.lightconsulting.com/~travis/ -><- GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484
