[Snort-users] alert suppression
Shawn.Jefferson at ...14448...
Wed May 6 17:38:54 EDT 2009
Further to this, I was able to figure out that the dcdrpc2 preprocessor seems to be causing these tagged packet alerts. Specifically one example is:
Sig 34: Dcerpc2: Connection-oriented DCE/RPC - Fragment length on last fragment less than maximum negotiated fragment transmit size for client.
Searching on the IP address in the tagged packet, like Greg suggested and then sorting them by timestamp shows that this alert and a couple of tagged packets all have the same src/dst IP and port and timestamp in BASE.
Now I know what they are, I don't want to get rid of them from showing up in BASE. ;)
From: Greg Bowser [mailto:topnotcher at ...11827...]
Sent: May 06, 2009 1:49 PM
To: Jefferson, Shawn
Cc: Joel Esler; snort-users at lists.sourceforge.net
Subject: Re: [Snort-users] alert suppression
>Yes I am running some of the emerging-threats rules, and grepping for "tag:" shows quite a few rules that use it.
> Is there no way to determine which rule is generating the "tag: tagged packet" alert? What is it for exactly?
Somtimes, it is nice to see the packets that follow the packet that triggered an alert. (i.e. the response). The tag keyword accomplishes this. Any of the rules you found that have the "tag" keyword will tag packets. (exactly which packets and how many is specified in the rule)
If you look at the traffic with the same src/dst ip pair (in either order) before the tagged packets, you should see the rule that started the tagging.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Snort-users