Snort Success!!!

["grant" <grant () macaulayconsultants co uk>]

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