Snort

See Below.

> > What about snort are you interested in? I have experience setting it up on both
> > Linux and Solaris as part of my job.
>
> Well...
>
> Is it a good idea to run it on a box that provides user services, or on
> it's own?

It is recommended that the box running snort not be running any user services.
This has to do with a couple of things.

1) Snort should be on a machine that can see all the traffic that you need it to
monitor, so if it needs to monitor more than just one machines traffic, then
having snort on a system running user processes will hurt the performance of the
machine.

2) The fewer things the NIDS box is running the less likely someone will be able
to compromise it and screw with the information it is collecting.

> What kind of resource requirements does it have?

That depends on how much bandwidth it is monitoring and what format it is
logging in. The systems I deal with are monitoring 2 Class B subnets with a
total aggragate bandwidth to the Net of around 200Mb/s. For this we ended up
using the Sun Netra T1's (AC200 model with the 500MHz Sparc IIe processor) to
handle the total traffic load. Less bandwidth, less horsepower.

Snort also allows a number of ways of logging alert events. Flat text, Binary
log, Syslog, Database, etc... I'm using the Database option logging to a remote
SQL server (not M$) and using a PHP based frontend called ACID (Analysis Console
for Intrusion Databases) to look at the information stored by Snort.

If you choose the flat text or syslog options, then you can use programs like
Snortsnarf to parse through your logs and generate flat html out of the alerts.
Or other options (go to www.snort.org).

> How often do you update it? Do you feel the need to write additional
> definitions/scripts for it?

Update the program or the rules?

The program gets updated anytime I see that the CVS/release has fixed
bugs/issues that I have been dealing with.

The rules get updated only for new exploits that could cause trouble (e.g. Code
Red/Nimda). The base rules are quite extensive and cover a lot of things that
may not be malicious, but might point to problems.

> Strategies for using/tracking the information it provides; what about Aris?

There are a number of sites that detail information on the alerts and what they
may mean including www.whitehats.com and the snort site itself. Since all my
alerts are stored in a database, the ACID frontend makes links from individual
alerts to these sites so that I can read up more information on that rule (so
does Snortsnarf and other options).

> I use portsentry/logcheck now. That gives me too much data, but not
> enough specific data.
>
> I'm torn between wanting to know everything funny on our network, and
> deploying something that could be a huge ongoing time suck. I know I'm
> going to deploy it, but I don't have enough info to be comfortable doing
> it.

Security is always a time consuming task.

> > > I'm mostly interested in Snort, and only slightly less interested in
> > > everything else you listed.