OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: dr.kaos (dr.kaoskaos.to)
Date: Wed Jan 16 2002 - 18:02:53 CST

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    On Wednesday 16 January 2002 05:48 pm, Jason Dixon wrote:
    > ...
    > redirector service like that found at http://mydomain.com. They can point
    > your hostname to any non-standard url/port combination.

    Sure, but I have multiple external IP's and the firewall still only supports
    a single "red" interface without extensive customization. Thus even with port
    forwarding and a free redirector, I lose the ability to individually protect
    and/or access the machines that I would otherwise static nat to the
    corresponding legal addresses.

    > >2> Again, unless you buy the commercial version you are not able to
    > >administer policy for outbound traffic via the admin GUI, which should be
    > > a concern for any administrator, regardless of trust in internal users
    > > (should an attacker compromise an internal host, policies need to be in
    > > place to prevent outbound attacks from your own network).
    >
    > Reverse proxy?

    Right. Plausible, but hard to enforce. And some apps with no direct proxy
    support and no built-in support for socks wouldn't easily fly. Sure would be
    easier to add ipchains rules to the policy graphically as can be done with
    the existing web interface for inbound traffic.

    I'm not suggesting that outbound filtering can't be accomplished, only that
    it's _way_too_ difficult on a stock GPL Smoothie.

    > >3> Although Snort is implemented on the GPL version, there are no
    > >administrative facilities to add/modify/remove existing rules, nor are
    > > there tools for customization of IDS policy (i.e. to prevent false
    > > positive port scans from upstream DNS servers you have to manually modify
    > > the Snort config files, which defeats the point of having a
    > > GUI-administered facility in the first place).
    >
    > Again, I see no problem in implementing this internally, as long as your
    > network can support it.

    Again, I'm not suggesting it's impossible, just that in this area Smoothie
    provides little advantage over any other distro with a prepackaged Snort:
    it's still gonna require manual administration. The whole idea behind a
    product like Smoothie is to automate all of these functions.

    > >4> Smoothwall does not allow blocking traffic based on matches against
    > > Snort rules. Thus, the box will not use signature matching to eliminate
    > > malicious packets, as I think Mike intends to do.
    >
    > Agreed, no arguments there (yet).

    The post I was replying to was actually itself a reply to an individual
    specifically looking to drop packets with signatures matching Snort rules,
    thus I think this to be the most important point in the message. Again, I
    could certainly compile Hogwash and implement it on a Smoothie in order to
    achieve this, but with no distinct advantages over doing so on, say, a Redhat
    box.

    > I'm not at all promoting the SmoothWall product. They have (IMHO) taken a
    > promising product and limited it's usefullness through the licensing you've
    > touched on. There are quite a few other projects that offer the same
    > functionality as theirs, albeit with a bit more administrative
    > know-how. Still, I'm disappointed that you'd dig up the muck just to
    > further your points. If that was the determining factor in a product's
    > usefulness, would you still use OpenBSD, given Theo's history?
    >
    > Anyhoo, you've made some good points. However, as you can see, there are
    > yet further choices available to work around these shortcomings.

    Not trying to "dig up the muck," simply relaying information I think is
    pertinent to anyone considering implementing Smoothwall as a firewall for
    protection of thier network. I think knowing a products shortcomings before
    installing it is definately of benefit.

    In its favor, Smoothwall is extremely easy to setup and can be configured in
    less than 20 minutes if all goes well; thus one wouldn't waste much time
    determining these things for themselves should they desire. I just want to
    save everyone else the headaches I encountered in determining that the
    functions _I_ was most interested in are either implemented in a limited
    fashion, or simply not present at all.

    --
    ./dr.kaos