[prev in list] [next in list] [prev in thread] [next in thread] 

List:       focus-ids
Subject:    Re: Newbie IDS questions
From:       "dr.kaos" <dr.kaos () kaos ! to>
Date:       2002-01-17 0:02:53
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]