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

From: Chuck Swiger (chuck_at_codefab.com)
Date: 05/19/05

  • Next message: Devdas Bhagat: "Re: [fw-wiz] A fun smackdown..." 
    To: "Paul D. Robertson" <paul@compuwar.net>
Date: Thu, 19 May 2005 16:43:21 -0400

    On May 19, 2005, at 3:11 PM, Paul D. Robertson wrote:
    > 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.)

    "default accept", you mean? Sure, there are two general approaches:
    "deny all, and then have a list of stuff to permit", or "permit all,
    and then try to deny stuff known to be bad".

    The former approach is a lot more likely to result in a secure system,
    but both approaches do more than just deny everything: what you accept,
    how well it's implemented, and where you accept stuff [to paraphase] is
    also the essence of security.

    Choosing to provide remote shell access via SSH is better than using
    Telnet or a VPN. Choosing to provide POP or IMAP via SSL is better
    than choosing to provide remote mail access via plaintext with
    passwords passed in the clear. If you can live without either, by all
    means, forbid remote access.

    >> 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?

    You are disagreeing with a design principle from the RFC's which
    discusses how to create robust software protocols. One could provide
    other examples.

    >> 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.

    Paul, why *don't* people run their firewalls with a single "deny all"
    rule?

    >> 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.

    I didn't say, "accept anything", I said, accept the types of access
    that the security policy says are permitted.

    >> 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.

    If my key doesn't open my front door, it's blocking legitimate access.
    A security system which prevents legitimate access is a broken security
    system.

    >> 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.

    I used Cisco's proxying of SMTP as a well-known example of a "security
    feature" which breaks legitimate protocol extensions (ESMTP), yet
    doesn't seem to really improve security, but if you aren't very
    familiar with it, I won't insist on debating this particular example.
    :-)

    How about excessive ICMP filtering breaking path MTU discovery? 

    -- 
-Chuck
_______________________________________________
firewall-wizards mailing list
firewall-wizards@honor.icsalabs.com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
  • Next message: Devdas Bhagat: "Re: [fw-wiz] A fun smackdown..."

    Relevant Pages

    • RE: IDS and Spywares
      ... > a network based security control has better visibility than a host based ... Just as we do in IDS and network traffic analysis. ... > made spyware, or trojan, or any other kind of malware where you can install ...
      (Focus-IDS)
    • Re: How will PatchGuard change kernel programming?
      ... I don't agree that McAfee has been avoiding or even inhibiting Microsoft ... from producing APIs to permit better addon security products. ... engineering approach that will create and extend new kernel level APIs so ... the last I heard there are techniques to permit PatchGuard to be ...
      (microsoft.public.win32.programmer.kernel)
    • Re: For the AdaOS folks
      ... >> But the only need in firewall is the policy of trusting behind it. ... I intend to make the security mechanisms ... When somebody uses an internet service in AdaOS, they do so with a certain ... arranged to permit minimum necessary access by internet services. ...
      (comp.lang.ada)
    • Svchost.exe - program security - inbound/outbound
      ... an ADSL connection and my firewall (Norton Internet ... Security 2003) is always running. ... "A remote system is attemtping to access Microsoft ... Permit [other choices are "block" ...
      (microsoft.public.security)
    • Re: Utah rave harrassment
      ... permit through the Utah County Health Department about three weeks ago. ... Fullmer did not know that a similar permit, which requires a security ... plan and event details, needed to be acquired. ...
      (alt.gathering.rainbow)