For better security: always "block all" or "block in all" is enough?

Greg Hennessy Greg.Hennessy at nviz.net
Thu Jul 29 11:17:51 UTC 2010


"Ask anyone who has done commercial firewall work...."

<Rollseyes>
    Yes Peter, of course Peter
</Rollseyes>
 
Meanwhile in the real world....
There are Governance, Risk, and Compliance reasons for logging all attempts to bypass security policy by hitting the default deny rule.  
These reasons are both de-facto and de-jure obligatory. 



The Operational and Reputational risks of driving security control points blind, far outweigh the tiny residual risk of a putative DoS attack against a firewall policy with default block logging enabled. 


Having made PF on FreeBSD bleed in the past through various nefarious testing methods, I can't say that taking the firewall offline through resource exhaustion (CPU, Storage, Network) caused by logging was ever a primary cause of a test failing. 




Kind regards

Greg



From: allicient3141 at gmail.com [allicient3141 at gmail.com] On Behalf Of Peter Maxwell [peter at allicient.co.uk]
Sent: 29 July 2010 03:52
To: Greg Hennessy
Cc: Spenst, Aleksej; freebsd-pf at freebsd.org
Subject: Re: For better security: always "block all" or "block in all" is enough?





On 28 July 2010 20:39, Greg Hennessy <Greg.Hennessy at nviz.net> wrote:


> What disadvantages does it have in term of security in comparison with
> "block all"? In other words, how bad it is to have all outgoing ports always
> opened and whether someone can use this to hack the sysem?
>


It's the principle of 'least privilege'.  Explicitly allow what is permitted, deny everything else.

It should also be

       block log all

A default block policy without logging has a certain ass biting inevitability to it.




However not as much "ass biting" potential as with logging on.  Ask anyone who has done commercial firewall work and they'll tell you not to enable logging on the default deny/drop rule unless you are debugging/testing - think denial of service.


More information about the freebsd-pf mailing list