Re: [fw-wiz] Firewalls Compared

From: Devdas Bhagat (devdas_at_dvb.homelinux.org)
Date: 07/02/04

  • Next message: Marcus J. Ranum: "RE: [fw-wiz] Firewalls Compared" 
    To: firewall-wizards@honor.icsalabs.com
Date: Fri, 2 Jul 2004 05:19:05 +0530

    On 01/07/04 10:32 +0200, Ben Nagy wrote:
    <snip>

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

    The whole base of network security has always been traffic inspection.
    That fundamental has never been challenged.

    The question has usually been one of implementation.
    Do we inspect this traffic? Do we do it in depth? How deep do we go?

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

    Which is just wrong. If this is valid, then we as a group need to stop
    and take a long look at what we are getting for our money.
    We *NEED* to make people^Wvendors understand that doing the "whack a
    mole" thing will not work.

    > "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
    First rule: Keep protocols simple, well defined and documented.
    Second rule: When in doubt, just say no.

    > 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.
    >
    So we need to learn that relying solely on a chroot for security is a
    bad idea. A sandbox is just a fancy chroot jail.

    > 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".
    Hey, I started doing that before MJR even mentioned it here.

    > 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

    On the other hand, the future should be about identifying valid traffic
    and stopping everything else.

    The identify malicious traffic and allow the rest is just bad design.

    > 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

    It goes somewhat to migitation of threats. It does not solve the
    problem. Curing the symptom is not a cure for the disease.

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

    No. This is like taking painkillers to "cure" RSI. The pain is just the
    symptom, but the real cure is in changing the way we work.

    The problem isn't users browsing, or recieving attachments. The problem
    is users doing so with applications that are not capable of restricting
    what happens when something does not match their expected worldview.
    (Boundary conditions of some sort not being tested for is one common
    reason.)

    Realistically, we *can* do a lot of things to fix issues. Continuing
    user education is the best solution, but when even educated users have
    issues remaining secure due to application bugs, it is time to fix the
    applications and make them not suck.

    Devdas Bhagat
    _______________________________________________
    firewall-wizards mailing list
    firewall-wizards@honor.icsalabs.com
    http://honor.icsalabs.com/mailman/listinfo/firewall-wizards

  • Next message: Marcus J. Ranum: "RE: [fw-wiz] Firewalls Compared"

    Relevant Pages

    • Re: Trying to find a good firewall
      ... > specific applications, only problem is, it has no MD5 or other scheme to ... Tiny is good, as is Kerio 2.1.5. ... what do you mean by "per-app and per-site configs"? ... And, like virtually all software firewalls, it ...
      (comp.security.firewalls)
    • Re: VMS cluster behind a *NIX firewall
      ... you are talking about homegrown firewalls rather than commercial offerings). ... growing market share and VMS is shrinking. ... I run VMS, Solaris, RHEL, and Windows XP at home. ... Applications, applications, applications, applications,... ...
      (comp.os.vms)
    • Re: Application logic and Business logic
      ... Without wanting to invalidate the rest of your post, ... > applications, schemae tend to be very heavily used. ... Putting firewalls ... and therefore makes the schemae more flexible. ...
      (comp.object)
    • Which firewall?: NetBSD/i386 vs Sygate Personal Firewall 5.0
      ... This is my first post to this newsgroup, so please forgive me if this ... I have a Linux installation at home in dual-boot with Windows on a PC ... on firewalls and ADSL setup. ... The intricacies of network security seem a little overwhelming ...
      (comp.security.unix)
    • Re: Hardware firewall - recommendation / advice
      ... >>fully customisable by web browser interface. ... >>you can forget about network security. ... >>firewalls for ages....you should too! ... I'm more comfortable with kit I can twiddle with to convince ...
      (comp.security.firewalls)