Hi All,
I have to provide for my system better security and I guess it would be better
to start pf.conf with the "block all" rule opening afterwards only those
incoming and outcoming ports that are supposed to be used by the system on
external interfaces. However, it would be easier for me to w
On Wed, Jul 28, 2010 at 2:55 PM, Spenst, Aleksej
wrote:
> Hi All,
>
> I have to provide for my system better security and I guess it would be
> better to start pf.conf with the "block all" rule opening afterwards only
> those incoming and outcoming ports that are supposed to be used by the syste
It's all about layers of defense, and whether the reduced convenience is
worthwhile.
Limiting outbound traffic from your system is a hassle, but I like to
think about this scenario:
Suppose an attacker did manage to find an exploitable method on your
system, and was able to open up a shell. What
> 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,
de
On 7/28/10 2:55 PM, Spenst, Aleksej wrote:
Hi All,
I have to provide for my system better security and I guess it would be better to start pf.conf
with the "block all" rule opening afterwards only those incoming and outcoming ports that
are supposed to be used by the system on external interfa
On 28 July 2010 20:39, Greg Hennessy 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
er
Maxwell [pe...@allicient.co.uk]
Sent: 29 July 2010 03:52
To: Greg Hennessy
Cc: Spenst, Aleksej; freebsd-pf@freebsd.org
Subject: Re: For better security: always "block all" or "block in all" is
enough?
On 28 July 2010 20:39, Greg Hennessy wrote:
> What disadvantag
; primary cause of a test failing.
>
>
>
>
> Kind regards
>
> Greg
>
>
>
> From: allicient3...@gmail.com [allicient3...@gmail.com] On Behalf Of Peter
> Maxwell [pe...@allicient.co.uk]
> Sent: 29 July 2010 03:52
> To: Greg Hennessy
> Cc: Spenst, Aleksej; fre
> If, as you say, there are "Governance, Risk, and Compliance reasons",
> perhaps you'd like to specify one or two for each category?
Start with an ISMS derived from 27k, add a soupcon of PCI DSS requirement 10,
Basel II, throw in SOX 404 or an SAS 70 type II audit, you get the picture.
> Lo
On 29 July 2010 20:08, Greg Hennessy wrote:
>
>
> > If, as you say, there are "Governance, Risk, and Compliance reasons",
> > perhaps you'd like to specify one or two for each category?
>
> Start with an ISMS derived from 27k, add a soupcon of PCI DSS requirement
> 10, Basel II, throw in SOX 404
block all" or "block in all" is
enough?
On 29 July 2010 20:08, Greg Hennessy
mailto:greg.henne...@nviz.net>> wrote:
> If, as you say, there are "Governance, Risk, and Compliance reasons",
> perhaps you'd like to specify one or two for each category?
Sta
On Thu, Jul 29, 2010 at 5:09 PM, Peter Maxwell wrote:
>
> An ISMS, is a company defined document so will likely have different entries
> or even none at all for that matter depending on the company. In a previous
> company I worked for, you would have just supported my point.
>
> And nice try, wh
On 30 July 2010 00:08, Chris Buechler wrote:
> On Thu, Jul 29, 2010 at 5:09 PM, Peter Maxwell
> wrote:
> >
> > An ISMS, is a company defined document so will likely have different
> entries
> > or even none at all for that matter depending on the company. In a
> previous
> > company I worked fo
13 matches
Mail list logo
