RE: [fw-wiz] Firewalls Compared

From: Paul D. Robertson (
Date: 07/01/04

  • Next message: Shimon Silberschlag: "[fw-wiz] Geographically Distributed sites, layer 2 clusters and firewalls"
    To: Ben Nagy <>
    Date: Thu, 1 Jul 2004 15:14:47 -0400 (EDT)

    On Thu, 1 Jul 2004, Ben Nagy wrote:

    > 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

    Only sometimes. It's perfectly valid to fill up a buffer with random
    words instead of repeating the character A 248 times...

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

    Only when you know the application protocol- which is the same race
    condition ALGs had.

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

    This is how Anti-Virus works- we all know how effective that is.

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

    *mumble* *mumble* *mumble*

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

    No, that's "the future of the kind of crap people are going to buy in the
    future 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.
    > ;)

    That's never a good prescription, it's how we got where we are. :-P

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

    You owe me beers. FWTK with Claude Whathisname's patches (and maybe some
    tweaking) did a pretty good job of HTML sanitization, and ftp-gw wasn't
    half bad either. I recall seeing some good SMTP stuff at one point too,
    but I don't recall the product or project (arguably, most mail issues
    have been above the application layer for quite a while.)

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

    No, it really isn't actually doable in real life- you still have to do the
    per-application stuff, especially once we get past the stack/heap issues,
    which will happen on the OS or in hardware, not on the wire.

    > This "future" is just about more flexible ways to identify a lot of
    > malicious traffic - instead of trying to get it _all_, failing, sulking,

    "A lot of" isn't all. Which just begs for polymorphic attacks, which put
    us right back at AV.

    Sure, AV is great for macro viruses now- but it's not for executables, and
    a lot of trojans.

    > 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

    It's a so-so approach and it sort of works, which is the kind of security
    most companies have been buying, so Richard's right in one regard, it'll
    sell. Of course, it works for you if you're selling it ;)

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

    There's been a lot of interesting work in secure OS's lately, plus a lot
    of interesting work in virutalization. The confluence of those is the
    real future of security- if it's the future of the security marketplace
    remains to be seen. Done right, we're left with denial of application
    attacks as a worst-case.

    If Outlook and Outlook Express removed the execute permission from
    attachments, it'd have a greater effect on the e-mail virus problem than

    Paul D. Robertson "My statements in this message are personal opinions which may have no basis whatsoever in fact." Director of Risk Assessment TruSecure Corporation
    firewall-wizards mailing list

  • Next message: Shimon Silberschlag: "[fw-wiz] Geographically Distributed sites, layer 2 clusters and firewalls"

    Relevant Pages

    • [fw-wiz] UNSUBSCRIBE
      ... (Paul D. Robertson) ... > fixup protocol icmp error ... >> isn't about the security properties of the control, ... errors in the firewall, configuration errors, and it then takes physical ...
    • Re: [fw-wiz] Secure Computing Sidewinder?
      ... We are moving off Sidewinder G2 solely because of the price. ... There are many different approaches to designing a firewall, ... thorough than most other "application proxy" firewalls, ... packet, tear it apart, inspects it, and then depending on the protocol it ...
    • Re: Natted IP
      ... > useful if one trys to tunnel an exploit of one protocol inside a second ... but the router "firewall" will block all unsolicited packets unles they are ... If you send some kind of tunneled packet wrapped inside, ... > run only with JS enabled with Java applets disabled. ...
    • Firewall that blocks NetBEUI etc.
      ... Personal firewall functionality is mostly oriented toward TCP/IP protocol. ... I have NT4WKS and we have advanced Microsoft network - they have some tool ... I have tried to audit them with netstat or TCPview to see all network ...
    • Re: Ports getting hammered?
      ... >>> If your Watchguard can't stop outbound traffic... ... >>> Would not the Windows XP firewall do exactly the same work? ... >> protocol analysis to see if protocols are being broken only a IDS ... > permitted ports and protocols. ...