Re: pf default deny compile-time option?
Damien Miller [EMAIL PROTECTED] writes: Mismatches between pfctl and the kernel happen on -current from time to time, and I think being locked out is better than falling back to permit all... .. if you have physical access to the machine in question. Then again, if you run -current on something mission critical a continent away, 'glutton for punishment' comes to mind. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://www.blug.linux.no/rfc1149/ http://www.datadok.no/ http://www.nuug.no/ First, we kill all the spammers The Usenet Bard, Twice-forwarded tales 20:11:56 delilah spamd[26905]: 146.151.48.74: disconnected after 36099 seconds
Re: pf default deny compile-time option?
On Sun, Jul 16, 2006 at 07:02:00PM -0500, Travis H. wrote: On 7/15/06, Ryan McBride [EMAIL PROTECTED] wrote: 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. If every ruleset needs to put a rule in to default to blocking packets, then that's needless complexity to me. No, needless complexity is a compile time option that makes it impossible to know whether a given installation needs the block rule or not. 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) I doubt it could hurt. and make some allowance for DHCP. DHCP uses bpf(4), and is unaffected by pf rulesets. Ah, learn something new every day. I suppose the outbound packets are passed by the ruleset, so it makes no difference that they have a SRC IP of 0.0.0.0... packets are sent using bpf(4) so ruleset does not really matter. Can
Re: pf default deny compile-time option?
On 7/18/06, Can Erkin Acar [EMAIL PROTECTED] wrote: No, needless complexity is a compile time option that makes it impossible to know whether a given installation needs the block rule or not. Good point. packets are sent using bpf(4) so ruleset does not really matter. Every day a school day! -- ``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
Re: pf default deny compile-time option?
On Tue, 18 Jul 2006, Can Erkin Acar wrote: On Sun, Jul 16, 2006 at 07:02:00PM -0500, Travis H. wrote: On 7/15/06, Ryan McBride [EMAIL PROTECTED] wrote: 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. If every ruleset needs to put a rule in to default to blocking packets, then that's needless complexity to me. No, needless complexity is a compile time option that makes it impossible to know whether a given installation needs the block rule or not. I'd just prefer that deny-all was the default and not an option at all. Mismatches between pfctl and the kernel happen on -current from time to time, and I think being locked out is better than falling back to permit all... -d
Re: pf default deny compile-time option?
On 7/15/06, Ryan McBride [EMAIL PROTECTED] wrote: 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. If every ruleset needs to put a rule in to default to blocking packets, then that's needless complexity to me. 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) I doubt it could hurt. and make some allowance for DHCP. DHCP uses bpf(4), and is unaffected by pf rulesets. Ah, learn something new every day. I suppose the outbound packets are passed by the ruleset, so it makes no difference that they have a SRC IP of 0.0.0.0... -- ``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
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.
