I was afraid of that.
I have snort plugged into a Cisco 3560G Switch on a mirrored port. I am
mirroring 10 other ports on the switch currently. This is my core switch and
brings about 5 different network segments together. I am using the Official
Snort Rules and the Bleeding Snort Rules. Snort is setup to kick out the
Alerts via Syslog. The local Syslog function in Linux is setup to send the
Alerts to a Syslog appliance that parses all of my logs for me.
For testing I setup Snort to output Alerts via unified logging and that
didn't help any. I currently have both Tx and Rx being mirrored to my
monitoring port. I tried just Tx and just Rx and got the same result. The
monitor port is a Gigabit port and the monitoring ethernet port is running
at a Gigabit also. On the linux appliance that port is running in
promiscuous mode and has no IP. I have a management interface on the box
also that I use to send the syslog files across and that I log into to
manage the box.
Any thoughts or suggestions would be appreciated. This is the first
production Sensor I have setup. All my testing sensors apparently didn't
have enough traffic being pushed at them.
On 10/26/05, Richard Bejtlich <taosecurity@gmail.com> wrote:
Joseph Nicholson wrote:
I see that snort dropped 179457 packets because it couldn't process them.
Snort received 186246 packets
Analyzed: 6789(3.645%)
Dropped: 179457(96.355%)
My gut instinct is telling me that it dropped 179457 packets because it
felt there was no threat from them and that the 6789 it analyzed looked
suspicious.
Hi Joseph,
You have a serious problem with your Snort deployment. The packets
Snort dropped were never inspected, period.
Can you describe your configuration? Are you sending Snort alerts
directly to a database, without Barnyard? Are you running any odd
rules?
Sincerely,
Richard
http://www.taosecurity.com
--
Joseph Nicholson
