Re: A fun smackdown...

["Paul D. Robertson" <paul () compuwar net>]

On Thu, 19 May 2005, Chuck Swiger wrote:

> On May 19, 2005, at 9:04 AM, Paul D. Robertson wrote:
> > On Tue, 17 May 2005, Martin wrote:
> > > "Be liberal in what you accept; be strict in what you send."
> >
> > _All_ effective security controls break that tenet.  The more liberal
> > your
> > controls, the more risk you assume.
>
> There is more to an effective security control than only denying stuff!

No, there isn't in terms of the mitigation of risk.  Anything else isn't
about the security properties of the control, but about its operational
effectiveness.  _What_ you deny, _how_ well it's implemented, and where
you deny it is in fact the essence of security.  From guards with guns to
firewalls to anti-virus, default deny or default except- either one works
by blocking stuff (what you know is bad, or what you don't know is
acceptable.)

>   I think you're over-valuing the utility of "deep protocol inspection",

Um, what the heck does "deep protocol inspection" have to do with the fact
that security controls are a denial technology?  Where exactly did I say
anything about deep protocol inspection?

> Paul, and you seem to be ignoring the risks of denying legitimate
> connections which should have been permitted.

No, again- Security works by denying things.  That's got nothing to do
with falsely denying things, and everything to do with accepting risk.  If
I deny everything, my risk is lower than if I deny 90% of everything- but
in either case, the security factor is about denying.

> An effective security measure needs to implement the security policy.
> It needs to permit the types of access that legitimate users are
> allowed to have, for the system-- meaning the network, the firewall,
> and the server(s) or other equipment being used-- to work correctly.

That doesn't change the fact that it all works by denying things, not by
liberally accepting just anything that might come over the wire.

> This is just as important as denying access to stuff that is not
> permitted by the security policy.

That's not a security property though, it's an operational property.  Now,
you can argue that denying too much impacts business, and I'd agree,
because it doesn't conflict with what I said-

1.  Security things work by blocking stuff.
2.  The less stuff you block, the more risk you assume.

That's because once you're done getting rid of the "bad" stuff (or the
"not good" stuff) you're simply left with bad actors doing permitted
stuff, no matter if it's your browser, a rogue administrator, or some bad
guy come to crack the nuclear launch codes[sic].

> Has "fixup protocol smtp 25" actually done much to prevent a vulnerable
> M$ Exchange box from being owned, or helped control the flow of
> spammy/virusized traffic significantly?  Does it help control outbound

I don't know what it does, since I don't field PIXes and have only worked
on two in my entire life; but I _assume_ that it will block the
Microsoft-only SMTP extension that popped up a couple of months ago as a
vulnerability.

Now, *if* it does, it *breaks* something that Microsoft Exchange Server
does when talking- see- that's the point, protection comes at the cost of
breaking functionality once you get to the point where you've knocked out
the out-of-band stuff and you're just left with the in-band attacks.

> malicious SMTP traffic?  Has it ever happened that a firewall itself
> ends up with buffer overflow bugs in it's own code, trying to implement
> all the per-protocol stuff?

Again, my observation isn't about *how* things are blocked,
implementations of blocking, or at what level things are blocked, it's
simply that security flies in the face of liberal acceptance.

> If you want to manage SMTP securely, blocking port 25 in both
> directions while permitting only your MX box(es) through would do a
> heck of a lot more good than the protocol inspection does.

At which point you're left shoring up against in-band attacks- that's the
only risk left for that vector!  But again, nowhere did I mention a
particular method of blocking those attacks, just that the more you
block[1] the less risk you assume.

Paul
[1] This of course assumes you don't introduce more problems, as
complexity also increases risk.
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
paul () compuwar net       which may have no basis whatsoever in fact."
_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards