Re: Upgrading from Snort v2.3.2 to 2.8.3.1

[Joel Esler <eslerj () gmail com>]

On Dec 9, 2008, at 10:18 PM, Harry Hoffman allegedly wrote:
> On Wed, 2008-12-10 at 11:59 +0900, Ian Masters wrote:
> > Joel
> >
> > > Ian, I suggest that you output to unified.  Then use a third party  
> > > tool,
> > > like Barnyard or SnortUnified.pm to parse the Unified file and  
> > > insert
> > > into the db.  Inserting into the DB directly from Snort, is bad.
> >
> > Can you tell me why it is "bad"? That is the way our system was set  
> > up a
> > few years ago. There haven't been any problems that I'm aware of.
> >
> > If it would be better to do as you suggest, I'll need to do that on a
> > test system first.
> >
> > That might take quite some time.
> It's only bad in a few circumstances...
>
> 1) You use the alot of snort rules, in which case every time snort  
> does
> a insert, syslog, etc. is time it doesn't deal with incoming packets
> (and potentially drops them).

This is the bad part about using the direct DB insert.

> 2) You use a few snort rules but they are heavy on things like  
> regexs in
> which case see #1.

Well...  let me clarify this later.

> 3) You need to alert to several different endpoints (i.e. syslog, db,
> file, etc.). For each of these snort will wait on each alert.

Which is why you output via unified and let barnyard process all the  
different endpoint logging methods.

> I believe snort-3.x is meant to do away with this sort of issue.

Snort 3 will not have db output, afaik.

> There are several ways to get around this... use tcpdump (or equiv) to
> capture all packets and then run them through snort later (let's face
> it, IDS isn't real time and IPS is still lacking).

While this is a solution, like you said, its not realtime, and then  
you have to worry about tcpdump dropping packets instead of Snort.

> Get rid of the vast amount of snort sigs (both OSS and other rules)  
> and
> only keep what makes sense for you environment. To many FPs to be able
> to deal trying to keep up with everything.

This is a good practice anyway, but it has nothing to do with why you  
should use Unified (as outlined in #2) above.  You should only run  
rules on your network that are pertinent to your environment.

> Use pcap filters to limit the traffic you are looking at to only
> essential hosts/nets

Also good practice.  Using BPF's to get rid of vast amounts of traffic  
right up front before the engine even processes it is many times  
better than using a suppression or a threshold.  BPF is definitely the  
way to go if you are looking at reducing the amount of traffic you  
want to analyze.  But again, this has nothing to do with why you  
should use Unified.  As I outlined in #1 above.  Snort has to stop  
"analyzing" traffic and insert into the db.  This takes time.  Time  
that Snort needs to analyze traffic.  Let Snort be the IDS, and let  
barnyard be the backend processor.

Joel

------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users