Re: Snort Success!!!

["Shawn Truax" <Shawn.Truax () mbs gov on ca>]

Great to hear that you are loving snort.  I would definitely recommend going to at least an ACID and MySql combination 
in an enterprise environment.  Have the database and acid on a second machine and point snort to send the alerts to it. 
 This greatly reduces the load on the sensor itself and allows more resources for snort.  Having ACID also greatly 
improves the way you can look at alerts and report on alerts.

 As well once you are comfortable with snort look into spoolers such as "mudpit" or "barnyard".  In an enterprise 
environment your sensors are often separated from your central database by some distance, be it in a building next door 
or in another office in another city.  If for some reason your network link is broken between your sensor and your 
database, be it a network outage or ISP issues, the spooler program will allow you to retain any alerts generated 
locally on the sensor until your network link is back up.  This way you won't lose potentially important alerts.  I 
have personally experienced water flooding the local network exchange knocking out internet/network access for just the 
building that my database was in.  However once the water was cleaned up and the network restored my sensors sent all 
the collected alerts back to the database and I was able to go through them and see what I missed.

Shawn

> > > grant <grant () macaulayconsultants co uk> 10/16/03 04:54pm >>>

Snort Success!!!
 
 
I am new to Snort but it has been my only focus these past few weeks. This is due to the extra unusual network activity 
recently. I work within an enterprise environment in the UK and Snort has been tracing activity to infected host 
machines as far as Australia.
 
I would just like to say what a fantastic product this is, and share my experience.
 
I have a Microsoft back ground and therefore installed snort on Windows XP for my lab environment. As speed was a 
requirement I initially used IDSCenter to configure Snort. I downloaded the DCERPC rules from snort.org and added them 
to the netbios.rules file. That was us catching and cleaning FAST! However reporting was required, my college, John is 
a programmer and a day later we had a flat file with a single line per alert and automatically recorded the host name 
using nbtstat. Nbtstat was used rather than DNS as not all the devices are registered and most of the time you can 
obtain the users logon name, which is very useful for tracing the machine if it is removed from the network.
 
We have now had time to develop this into our long term solution. I have built a Compaq DL380 G1 server, 800 MHz, 
512Mbytes and three network interface cards. On this I am using Windows 2003, Snort 2.0.2 installed as a service, 
Snortsnarf 021111.1 for reporting utilising Active Perl Build 635. IDSCenter and IIS were not used in this case as I 
was trying to keep the CPU as free as possible for Snort.
 
This has been connected currently via two network cards. The first does not have TCP/IP bound and is used in 
promiscuous mode. This is the Snort sensor connected to a Cisco Catalyst switch with a spanning port setup on the VLAN. 
The second network card has five concurrent IP addresses bound to it. This is to make sure we catch any port scans.
 
I have bought and read the Snort 2.0 book and now always have it to hand.
 
Three batch files have been developed to allow reporting, these trigger Snortsnarf and create a weekly, daily and the 
last two hours report (Still under test to see if any packets are dropped due to CPU usage). The weekly report runs on 
Sunday night, it stops the Snort service, renames and moves alert.ids, creates a new alert.ids and restarts the 
service. Then the weekly report is compiled. The daily runs just before midnight for the last 23Hours 55 Minutes. The 
last two hours report runs every ten minutes. These reports are accessed by a read only network share for specific 
individuals.
 
Once the reporting was running I used this to tune the rules for this specific sensors location. I will not try to tune 
the rules again without reports; Life is just too short. This still took a whole day for initial tuning reducing the 
100,000+ alerts an hour down to five a day, now down to the odd one. For every rule removed or exclusion added I 
checked which system the alert was from and confirmed it was legitimate traffic.
 
I have yet to find a suitable method of alerting, IDSCenter was great on the test unit for triggering alerts, but as 
stated earlier I wish to keep the processor free for Snort. I was hoping to use the Snorts *E option to write to the 
Event log. This produces good events, but I can not find a way of logging the data to an alert file also. This is 
required for the reports; the reports are too good to lose. The Event logs allow BMC Patrol via WMI calls to alert the 
monitoring centre (a standard process in our company), who then read the report and act on the information. I think I 
will have to call upon the skills of John again to provide some sort of Swatch for windows that creates Event logs. I 
have tried using the syslog daemon which does create emails, but this does not seem reliable enough under extremely 
heavy load.
 
To the future I think I will try Redhat and ACID and see how that differs.
 
Overall I have had a Great Snorting experience!
 
Thank You
 
Grant Macaulay