On Tue, Nov 15, 2005 at 05:11:25PM +1100, Damien Miller wrote:
Why is setting a block all before any interfaces are configured up not
sufficient?
I guess he recompiles all his kernels with 'options IPFILTER_DEFAULT_BLOCK'
on principle. The principle being that it sounds more secure.
It
Daniel Hartmeier [EMAIL PROTECTED] writes:
Believe it or not, we now survived more than four years without that
feature, and noone ever complained (much less called it a 'fatal flaw'),
so you'll have to excuse me for, well, *yawn*.
OpenBSD does not have a problem as far as I can see. The
Thanks to all for the comments on this issue.
Although several people have come up with alternative approaches, I
still feel very much that the basic situation remains that pf is 'open'
until something happens to close the firewall; and that while there
won't /normally/ be a problem,
On Mon, 14 Nov 2005, mike scott wrote:
I accept that this may not be an issue for some; for my own part,
although I would /very/ much like to use the extra flexibility pf
offers compared with the alternatives, nevertheless, I view this
startup issue as a fundamental and fatal flaw. I shall
On Tue, 15 Nov 2005 17:11:25 +1100 (EST)
Damien Miller [EMAIL PROTECTED] wrote:
Why is setting a block all before any interfaces are configured up not
sufficient?
IIRC, he's using it on freebsd and the freebsd /etc/rc doesnt do the default
block all rules.
---
Lars Hansson
On Wed, 9 Nov 2005, Peter N. M. Hansteen wrote:
Jon Hart [EMAIL PROTECTED] writes:
Unless I'm being completely mislead, this feature is already in place
with OpenBSD. See /etc/rc.
Now that you mention it, it does look like the good people who ported PF
over to FreeBSD did not bring with
Damien Miller [EMAIL PROTECTED] writes:
Why is setting a block all before any interfaces are configured up
not sufficient?
The original poster's problem is that it looks like the rc scripts on
FreeBSD do not include the PF initialization code which does that.
Probably not terribly hard to fix
Damien Miller [EMAIL PROTECTED] writes:
And the important thing to note is that this ruleset is applied before
any interfaces are activated. No active interfaces == no packets
making it to the kernel.
Yes, my point exactly. I probably did not write it that well, since OP
went off
Over in the comp.unix.bsd.freebsd.misc news group, there's a
discussion about what happens when PF loads, specifically a perceived
'window of opportunity' for an attacker in the interval between PF
getting enabled and the rule set loading, and what happens if the rule
set you load at boot time is
On 9 Nov 2005 at 9:57, Peter N. M. Hansteen wrote:
Over in the comp.unix.bsd.freebsd.misc news group, there's a
discussion about what happens when PF loads, specifically a perceived
'window of opportunity' for an attacker in the interval between PF
getting enabled and the rule set loading, and
On Wed, Nov 09, 2005 at 09:57:08AM +0100, Peter N. M. Hansteen wrote:
Over in the comp.unix.bsd.freebsd.misc news group, there's a
discussion about what happens when PF loads, specifically a perceived
'window of opportunity' for an attacker in the interval between PF
getting enabled and the
Jon Hart [EMAIL PROTECTED] writes:
Unless I'm being completely mislead, this feature is already in place
with OpenBSD. See /etc/rc.
Now that you mention it, it does look like the good people who ported PF
over to FreeBSD did not bring with them all of the PF related bits from
OpenBSD's
On 11/09/2005 02:57:08 AM, Peter N. M. Hansteen wrote:
Over in the comp.unix.bsd.freebsd.misc news group, there's a
discussion about what happens when PF loads, specifically a perceived
'window of opportunity' for an attacker in the interval between PF
getting enabled and the rule set loading,
13 matches
Mail list logo
