--On November 15, 2005 3:32:11 PM +0000 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"
>> RULES="$RULES\npass on lo0"
> ....
>> echo $RULES | pfctl -f - -e
>> fi
>>
> And if, for any reason whatsoever, pfctl fails to run? The system
> remains wide open.
>
> Yes, that would be an entirely abnormal circumstance. But I have
> for example had one freebsd crash ever(!); but this caused minor
> disk corruption losing a strange set of files. It could have been
> pfctl among them. It seems to me that a firewall needs to be
> designed to fail safe as far as is possible.
>
> I'm no kernel code writer. But surely, somewhere in the depths of
> the pf code there's currently a decision made rather like:
> if( got rules )
> obey rules
> else
> pass packet.
>
> It can't be rocket science to make the 'pass' a 'block' in which
> case everything is entirely watertight in the event of virtually
> /any/ system fault bar kernel corruption. And it can't be too much
> harder to make this a compiled-in option, which would keep happy
> the paranoid, while allowing those who want remote log-in on
> failure to do so.
>
> Sorry to labour the point; maybe I'm a lone voice, but I'm a lone
> voice that feels very strongly about this issue.
I can think of several ways to do this without messing with the
kernel. the quickest that comes to mind is in your rc scripts:
test to see if pf.conf loaded
if yes, fine
if not then
sysctl net.inet.ip.forwarding=0
echo "block all" | pfctl -f -
instead of "block all" you could just block your external port(s)
allowing you to login on the LAN and correct whatever the problem is
etc...
