Re: [fw-wiz] A fun smackdown...

From: Paul D. Robertson (
Date: 05/19/05

  • Next message: Paul D. Robertson: "RE: [fw-wiz] A fun smackdown..."
    To: Chuck Swiger <>
    Date: Thu, 19 May 2005 15:11:20 -0400 (EDT)

    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

    > 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

    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.

    [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 which may have no basis whatsoever in fact."
    firewall-wizards mailing list

  • Next message: Paul D. Robertson: "RE: [fw-wiz] A fun smackdown..."