RE: [fw-wiz] Firewalls Compared

From: Ben Nagy (
Date: 07/01/04

  • Next message: Martin Mačok: "[fw-wiz] Firewalls "definitions" (RFC)"
    To: <>
    Date: Thu, 1 Jul 2004 10:32:44 +0200

    > -----Original Message-----
    > From:
    > [] On Behalf
    > Of Jim Seymour
    > But, you know
    > > what the vulnerability looks like and could look at traffic and
    > > identify malicious activity even without signatures.
    > I'm trying to reconcile "know what the vulnerability looks
    > like" with "even without signatures," and failing miserably.

    Well, a "buffer overflow vulnerability" looks like [stuff to fill up
    buffer].[code]. Per se, that's not a signature, but we can use it in several
    places to protect against not-yet-written attacks and not-yet-discovered
    vulnerabilities. For example if we know from the protocol rules that we're
    looking at any user supplied parameter. A format string vulnerability is
    pretty easy to spot - but if you can apply intelligent protocol context to
    where you look for it then you will do way better than using static
    signatures that just dump any packet with %n%n or %x or whatever.

    I think there's a word game here which might be confusing you - "signatures"
    are conflated with "looking for known attacks". In theory, you could call
    what I describe above a kind of signature, as well. It's just that "people"
    don't. :)

    > [...] Gartner, that organization's cache' has just
    > taken a *major* hit in my eyes.
    > Perhaps I'm missing/misunderstanding something. If so:
    > Somebody kindly enlighten me?
    > Jim

    Sure - you mistakenly assumed that Gartner was more than a predictor of
    upcoming market trends, and was instead a predictor of intelligent technical

    I feel kind of bad that we're all beating up Mr Stiennon again, though,
    since I actually think the core point he made is sound:

    "The future of network security is all about inspecting traffic"

    I'm going to start by unfairly straw-manning Devdas:

    "(generalisations follow, they might not be applicable everywhere) As I
    understand it proxies watch for known good traffic. They will filter out
    stuff which is not known to be good.

    IPS watches for known bad traffic. It only responds to that which is known
    to be bad. This is a lousy setup for a firewall.

    Firewalls MUST be in a default DENY mode."

    Now you're sounding curmudgeonly - reduce your dosage of Paul and mjr mails.

    Sure, lots of people claim application intelligence, but they lie. Vendors
    do that, we're weasels. Face it - everybody is already taking a "pick out
    stuff that looks bad" approach to application inspection, nobody is doing
    "completely understand the protocol and enforce security rules at all points
    to avoid every attack". I bet five beers that that last proxy that fully
    understood a protocol and could take a protocol equivalent of "only known
    good" to completely sanitise the application was probably HTML for the SEAL,
    and it wouldn't work with what we call HTML today.

    The key to the "future == inspecting traffic" approach is that it's actually
    _doable_ in real life, unlike fully default deny secure firewalls that use
    full application knowledge - positing that the world will not soon move to
    the mjr sponsored model of "stop using OSes and applications that suck".

    This "future" is just about more flexible ways to identify a lot of
    malicious traffic - instead of trying to get it _all_, failing, sulking, and
    then completely opening up your security (which is what companies do today).
    As I said before, it's pretty much a matter of what colour you paint the box
    - IPS, Deep Inspection Firewall or Inspectotron Fireweasel. However -
    whatever you want to call it, it's a good approach, and it works. It is NOT
    a more secure approach than running secure apps, using OSes that don't suck,
    not letting users browse or receive attachments, and having oldschool
    firewalls. However, it's a lot more realistic.



    firewall-wizards mailing list

  • Next message: Martin Mačok: "[fw-wiz] Firewalls "definitions" (RFC)"

    Relevant Pages

    • Re: Snort and Nessus Signature
      ... >> information for many of the snort signatures (CVE, BID, descriptions, ... we have found that there can be multiple CVE entries ... > exploitation of a vulnerability not an exploit. ... > bugtraq reference: 1565 ...
    • RE: Vulnerability & Exploit Signatures
      ... | Subject: Re: Vulnerability & Exploit Signatures ... companies who have built security "appliances", web interfaces on top of ... does make for an easier way to kick start your own security company. ... Obviously to sit down and truly write your own IDS/IPS and Vulnerability ...
    • RE: IDS vs. IPS deployment feedback
      ... the vulnerability was initially announced, the SNORT community (I do not ... know which exact group created these signatures) added approximately 300 ... SNORT engine itself, ...
    • Re: Article on WebDAV Vulnerability (MS03-007)
      ... >> Vulnerability, ... the reference to ISS for signatures to detect this exploit, ... With the WebDAV patch alone, ... there is a detection rule from the Nessus website. ...
    • Re: Article on WebDAV Vulnerability (MS03-007)
      ... >> Vulnerability, ... the reference to ISS for signatures to detect this exploit, ... With the WebDAV patch alone, ... there is a detection rule from the Nessus website. ...