[Snort-users] Tips for using ACID in a mult-admin environment ?
WilliamsJonathan at ...2134...
Fri May 30 12:36:06 EDT 2003
First, a quick thanks to everyone who's responded. Its good to know that
I'm not the only overworked Snort admin out there :-)
This comment brings up some interesting thoughts. We've actually done quite
a bit of tuning. Some sensors run almost exclusively a custom ruleset,
watching for signatures of things we suspect to be anomalies. For example,
we watch for TCP reset packets to common ports, servers initiating outbound
TCP sessions, IP addresses that shouldn't be on our networks, packets that
shouldn't ever be routed, things like that. Some of the rules are quite
noisy, like the TCP reset rules, but the act a bit like a mining canary: if
something is going wrong, they light up like a Christmas tree and we go from
our typical load of 5000-6000 alerts/day to 30k+ in a matter of minutes.
So, being a real smart guy, I used RRD-Tool (www.rrdtool.org) to poll the
event and iphdr tables to pull out the total number of alerts, total number
of unique source IPs, unique destination IPs, and unique signatures in the
database every 5 minutes. By looking at the line chart, we get an easy idea
of how quickly the alert world has changed.
Of course, being lazy, I wondered, has anyone thought about getting paged
when the rate of alerts changed? This includes not only if there's a sudden
spike in alerts where a sensor that usually generates 5/second starts doing
50/second, but also if there's an increase across all sensors or if a sensor
that's normally chatty suddenly stops alerting.
From: Anthony Kim [mailto:Anthony.Kim at ...9338...]
Sent: Friday, May 30, 2003 1:31 PM
To: Williams Jon
Cc: Snort-users at lists.sourceforge.net
Subject: Re: [Snort-users] Tips for using ACID in a mult-admin
If your situation is such that your alerts are a
neverending clickstream of deletia, then perhaps you might
reconsider what you are logging, tune your policies some more?
More information about the Snort-users