Catching up on very old email.
On 11/15/05, Lars Hansson <[EMAIL PROTECTED]> wrote:
> > And if, for any reason whatsoever, pfctl fails to run? The system
> > remains wide open.
>
> Becasue that happens a lot
> Oh come on now, this is a fringe case if there ever was one.
> What if your default
On Wed, Nov 16, 2005 at 10:21:47AM +0800, Lars Hansson wrote:
> > And if, for any reason whatsoever, pfctl fails to run? The system
> > remains wide open.
>
> Becasue that happens a lot
> Oh come on now, this is a fringe case if there ever was one.
The far more common case where exactly thi
On Tue, Nov 15, 2005 at 07:22:56PM -, mike scott wrote:
> Not currently an issue, as ipf is statically linked into my kernel, and
> set to block by default. I believe that's pretty well bomb-proof. I'm
> not even sure, come to think of it, that /pf/ can be statically linked
> into the freeb
On Tue, 15 Nov 2005 15:32:11 -
"mike scott" <[EMAIL PROTECTED]> wrote:
> And if, for any reason whatsoever, pfctl fails to run? The system
> remains wide open.
Becasue that happens a lot
Oh come on now, this is a fringe case if there ever was one.
What if your default block kernel has a
On 15 Nov 2005 at 18:40, Daniel Hartmeier wrote:
..
> It's worse than you suspect. If the pfctl binary is corrupt or missing
> and fails to run, pf won't ever get enabled at all. Forget about the
> fact that an empty ruleset means a default-pass policy. That's
I didn't say an /empty/ ruleset. I sa
On Tue, Nov 15, 2005 at 03:32:11PM -, mike scott wrote:
> > if [ "X${pf}" != X"NO" ]; then
> > RULES="block all"
> > RULES="$RULES\npass on lo0"
>
> > echo $RULES | pfctl -f - -e
> > fi
> >
> And if, for any reason whatsoever, pfctl fails to run? The system
> rema
--On November 15, 2005 10:25:44 AM -0700 "Eric S. Pulley"
<[EMAIL PROTECTED]> wrote:
> --On November 15, 2005 3:32:11 PM + mike scott
> <[EMAIL PROTECTED]> wrote:
>
>> On 15 Nov 2005 at 8:58, Peter N. M. Hansteen wrote:
>> ..
>>> The OpenBSD /etc/rc has this code to initialize PF before any
--On November 15, 2005 3:32:11 PM + mike scott
<[EMAIL PROTECTED]> wrote:
> On 15 Nov 2005 at 8:58, Peter N. M. Hansteen wrote:
> ..
>> The OpenBSD /etc/rc has this code to initialize PF before any
> interfaces
>> are up:
>>
>> if [ "X${pf}" != X"NO" ]; then
>> RULES="block all"
>>
On 15 Nov 2005 at 8:58, Peter N. M. Hansteen wrote:
..
> The OpenBSD /etc/rc has this code to initialize PF before any
interfaces
> are up:
>
> if [ "X${pf}" != X"NO" ]; then
> RULES="block all"
> RULES="$RULES\npass on lo0"
> echo $RULES | pfctl -f - -e
> fi
>
And if
"Travis H." <[EMAIL PROTECTED]> writes:
> Lots of things in the startup scripts will fail to work or hang
> indefinitely if you block outbound stuff. I find it necessary to
> allow at least outbound DNS in order for the machine to boot in
> reasonable time.
The OpenBSD /etc/rc has this code to
On Mon, Nov 14, 2005 at 11:49:40PM -0600, Travis H. wrote:
> 1) On UDP keep state rules, do they allow replies from other IPs? The
> DNS spec says that servers can respond from a different IP than the
> one they received the query on.
No, only replies coming from the expected IP address and UDP
Lots of things in the startup scripts will fail to work or hang
indefinitely if you block outbound stuff. I find it necessary to
allow at least outbound DNS in order for the machine to boot in
reasonable time. Fortunately pf is pretty good about allowing
outbound but not allowing inbound connecti
On Wed, Nov 09, 2005 at 11:41:27AM -, mike scott wrote:
> Background: I'm upgrading to FreeBSD 6.0-release and want to move from
> ipf to pf to get the extra flexibility pf offers.
welcome! :)
> However, I have concerns about the security of pf at system startup and
> when the config file
Hi, I've been directed here from a FreeBSD newsgroup about this
question. I've checked the archives, but found nothing relevant.
Background: I'm upgrading to FreeBSD 6.0-release and want to move from
ipf to pf to get the extra flexibility pf offers.
However, I have concerns about the security o
14 matches
Mail list logo
