[Snort-users] Using Snort code base to make an intelligent firewall

Bill Marquette wlmarque at ...8...
Thu Nov 23 11:18:15 EST 2000

An along the same lines, I've set off snort by just downloading the rules files
:)  It's a good feature and I suspect would lead to a large amount of rule
refinement...which of course isn't bad either ;)  As for false positives, I wish
I could say I only see 3-400/day.  Between our firewall logs (60+), snort, and
other IDS we have deployed I'm lucky if I see less than 6,000 events a day (even
after filtering them down to a bare minimum) 98% of those are false positives I
can't do anything about unfortunately...of which snort generates maybe 300 false
positives.  As with you, the majority of the false (true before research)
positives are developers using some new product or forgetting what a DMZ is,
etc.  One of the many rules I have loaded on snort detects broadcast traffic
that hasn't yet been classified...it's rather amazing how much software out
there uses UDP broadcasts as a form of license management.


From: "Tom Whipp" <twhipp at ...63...> on 11/23/2000 08:32 AM

To:   snort-users at lists.sourceforge.net
Subject:  RE: [Snort-users] Using Snort code base to make an intelligent

Like everyone else I like the idea of a co-operative IDS and firewall, but I
don't think I could really trust it at the moment.  The some of the sites we
host are very large volume consumer retail sites - they can't afford to
block customers by accident they would consider it a direct loss of revenue.

Now I could (and do) tune the rules to cut out the majority of the false
positives - but I don't want to drop every rule which triggers because that
would kinda defeat the point of having an IDS in the first place.  The
developers are constantly updating the site - about once a month they manage
to call some component of the site something which is similar enough to one
of the rules to trigger a heap of alerts overnight.  Under a fully automated
scheme these pages would work fine in development but couldn't be viewed
when deployed to the live server - I also see a LOT of content rules being
tripped from the referrer field of the HTTP headers.

I can see what you are saying but my practical experience using snort here
shows far to many false positives for me to trust it to selectively kill
connections.  Don't get me wrong I'm no expert in IDS's (I've only been
using Snort for about 5 months) but I do know our customers - unless the
false positive rate dropped to around 5 per day (on a site with around 2.2M
hits per day) they wouldn't accept it - even with some extensive rule tuning
I'm running at around 3-400 false positives daily - I just couldn't sell
that and at these error rates I wouldn't want to.  Furthermore given the
dynamics of site development I don't believe I could ever guarantee those
sorts of error levels because I can't predict which rule is suddenly going
to have a run on it.

As a similar example last week (or maybe the week before) I got an email
from the incidents at ...35... which included a trace of a buffer
overflow.  Snort picked this out and flagged it as a possible attack due to
the NOP sled at the front of the exploit - using a fully automated system
that mail could not have been received which would have annoyed me somewhat.
I've had similar flags raised by perfectly innocent mails from our MD who
included an attached image to their mail - needless to say there would be
quite a lot of explaining to do if his email started being dropped.

I could understand a set-up where the console provides the analyst one click
updates of firewall policies on a temporary basis - but not as a auto

just thoughts


> -----Original Message-----
> From: snort-users-admin at lists.sourceforge.net
> [mailto:snort-users-admin at lists.sourceforge.net]On Behalf Of Mark Cooper
> Sent: 23 November 2000 12:31
> To: snort-users at lists.sourceforge.net
> Subject: RE: [Snort-users] Using Snort code base to make an intelligent
> firewall
> Folks,
> Sticking my neck *way* out, I think that some people may be missing one of
> the benefits of combining IDS and firewalling in one package.
> True, classic firewalling runs on a policy of "deny everything except that
> which is explicitly allowed". NIDS typically runs on a policy of "ignore
> everything except that which is explicitly listed". By combining f/w and
> IDS, we can use *both* policies to the greater good. I see it
> working thus:
> The firewalling "layer" (lets not get too hung up on terminology) provides
> the normal packet filtering. So, for a trivial example, it would allow web
> traffic in to our servers. However, all traffic that is allowed by the
> firewall layer would be passed via the IDS layer. It examines
> that traffic,
> say for dodgy CGI script probes, and drops that connection *only*, by
> sending a RST to *our* server. I think that this combination
> should prevent
> both an externally triggered DoS against our systems, and, as aleady
> suggested in this thread, will prevent us performing a RST-based
> DoS against
> other hosts.
> Just my random tuppence.
> Mark Cooper (GCIA)
> Mark.Cooper at ...839...
> www.rubus.com
> Any views or opinions presented are solely those of the author and do not
> necessarily represent those of Rubus.
> _______________________________________________
> Snort-users mailing list
> Snort-users at lists.sourceforge.net
> http://lists.sourceforge.net/mailman/listinfo/snort-users

Snort-users mailing list
Snort-users at lists.sourceforge.net

More information about the Snort-users mailing list