Re: Cisco IDS

[Bamm Visscher <bamm.visscher () gmail com>]

Since you asked ;)

In sguil, we use p0f to identify the OS when a transcript [0] is
requested.  We've pushed around a couple of concepts for using it on a
larger scale (do we just run p0f as is and load the data into the DB
or can we gleen the information with sancp [1] and just add the needed
fields to an existing table [2]).

I like what Marty and crew is doing with RNA too.  Check out pads [3]
for a poor man's implementation.  Passive OS and application detection
(pads calls it passive asset detection) can help put an alert into
context.  Context is a huge piece of analysis, but often an
afterthought and/or not included with most commercial implementations.

Sguil is built around a process we call NSM [4], and collecting the
right data to put an alert into context is a big part of that process.
I believe in the 'Big 3':  alert data, sessions/connections/flows, and
raw pcap. All this data can be a pain to collect and a nightmare to
manage, but it pays huge dividends. Technologies like RNA, pads, p0f,
syslogs, FW logs, etc are an asset too, but if you can manage to get
the 'big 3' then it lessens the value and need for the others (IMHO). 
With that said, getting the 'big 3' isn't always easy, and sometimes
not even practical. If I could not get all the pieces of the 'big 3'
then I would definately use applications like RNA to help fill those
holes.

As far as Sguil being "a little young and a pain to get working":
Actually, the project isn't that young (feel free to call ME young
though).  Although it has "only" been on SourceForge and publicly
available for just over two years, the process it's built on has been
around since the dawn of IDS. I also wrote a similar, but proprietary
interface almost two years before Sguil, so I'd say the concept is
'proven'.  Like most opensource projects, the development goes in
bursts when I (and others) find/make time (I have to juggle the wife,
kids, work, UrT, wife, kids, riding, kids, honey do's, kids ;) ). The
install can be painful, but please understand you are talking about
three different collection apps (snort (ids), sancp, and snort (pcap
logging)) all working together (but seperately). You're not limited to
any specific hardware or operating system (each w/their own little
quirks). On the flip side, the community is very helpful and answers
questions on the mailing lists rather quickly. Analysts can also join
#snort-gui on irc.freenode.net and get help (we live to enlighten
people on the virtues of NSM).  After all, Sguil is built by Analysts,
for Analysts ;).

BTW, my production install consists six geographically seperate
sensors reporting to a single sguild and DB. I only get about 20,000
alerts/day with a total of just over 2.5 million alerts currently in
the DB. I load between 4-5 million rows of sancp data per day with 20
million total. My busiest sensor logs 1.5-2.0GBs worth of pcap data
every 15 minutes (during peak hours).  I'd probably consider this a
'small to medium' sized install. The largest Sguil implementation I
know of has ~25 sensors. Not sure on the complete stats. I also know
there are a couple of .edu installs that may not have a ton of
sensors, but they log a buttload (that's a technical term) of data
(and they get all the Cat I's too).

Bammkkkk

linkage:
[0]: http://sguil.sourceforge.net/images/0.5/transcript.png
[1]: http://www.metre.net/sancp.html
[2]: http://sguil.sourceforge.net/images/0.5/ssnqry.png
[3]: http://passive.sf.net
[4]: http://www.awprofessional.com/content/images/0321246772/samplechapter/bejtlich_chs.pdf



On Tue, 18 Jan 2005 23:08:45 -0500, John Hally <JHally () epnet com> wrote:
> Thanks Theodore,
>
> That wasn't so bad, I figured I'd get flamed for posing the question :-)
>
> Actually, I have no problem building Snort, and have used it since v1.8 with
> good results.  The main problem I have is a couple things.
>
> First, no real good mgmt interface.  Snort Center was great, but it's fallen
> on hard times, and you can't get anything but 2.0 to run on it without doing
> a lot of php hacking, and I just don't have the time.  For a php developer,
> I'm sure it can be done, but I'm the biggest hack, so it would take a lot
> more time for me.
>
> Second, ACID is good, but there's no real correlation/mitigation.  Sguil
> looks like it's going to be something, but its just a little young, and it
> can be a pain to get working.  I haven't tried BASE, though it looks like
> it's basically the same thing.
>
> I love the idea of RNA.  I've played around with p0f recently, and even at a
> low level, the idea of passive OS identification is slick.  I'm guessing at
> some point someone will hack up a version of p0f to attempt to detect
> applications as well.  Any of you Sguil guys out there, feel free to
> incorporate this in as well ;-)
>
> Defense Center would be OUTSTANDING at the price they want, if their snort
> agent allowed you to manage your home-grown sensors as well as accept their
> alerts, but it doesn't.  I guess at least I can't complain too much.  At
> least I could leverage what I have on some level.  They have to make money
> to, otherwise no one would by sensors.
>
> BTW - Sourcefire list pricing is comparible to Cisco, it's just that
> depending on your relationship w/cisco, they can practically give it away if
> they want.  They have purchased Okena, and I believe at least another
> security-centric company, so at some point I'm guessing that their ids
> solution will change for the better.
>
> I feel that snort/Sourcefire is better hands down, but wanted to see what
> the group had to say.
>
> Thanks again for the reply.


-- 
sguil - The Analyst Console for NSM
http://sguil.sf.net


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
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