07-07-2009 12:38 PM - edited 03-10-2019 04:41 AM
Does anyone know what signature 7304 triggers on?
Solved! Go to Solution.
07-14-2009 06:19 AM
Certain signatures have hidden/encrypted parameters because we have an obligation to protect information disclosed to us. Yes, it has to be that way.
The signature which started this thread, was in fact 7304-1, which is retired and disabled by default. It's for a specific file, and this was in fact a false positive. A revised signature (7304-1) should be out in the next couple releases.
The preferred method to resolve these issues, would be to open a TAC case and if they need assitance, they engage us. Sometimes we'll pick these up off the forum, bandwidth providing.
Its helpful to provide alert output - preferably with "verbose alert" enabled - for the signature in question, and any other relevant information.
07-08-2009 03:51 AM
Due to non-disclosure agreements, we are not able to release details on exactly what the trigger is.
07-08-2009 04:07 AM
Can you give me an idea of the signature quality? or likelihood of false positives? My reason for asking...The signature was released and installed in early June. Over this past weekend (July) the signature began alerting (a lot). The attacker/trigger packet sources from my servers. My servers have a number of .doc files. Using my firewall logs (accessed URL - 304001) I can see that a good number of the my .doc files are triggering the IPS overflow alert (7304). Is there a way to determine if my .doc files are infected and causing visitors elevated risk? Most of the literature I have found focuses on the user opening an infected file.
07-09-2009 09:09 AM
go ahead and contact me direct, walter@cisco.com
from the data i have available, i don't see a single firing of that in the past 2+ months
so it has been clean, up until just recently... has that sensor seen traffic to/from that server since early june?
anything changed on your network over that weekend or just prior to it? just thinking here.
i'd be interested in seeing some verbose alerts from the sensor for that signature. you'd need to add verbose alert as an action, and then i'd be fine with cli output of that signature - ssh to the sensor, then "te len 0", then "sh ev al | in id=7304" would pick up only that alert.
07-14-2009 03:37 AM
I'm thinking that could be generic question.
We have the same problem. Also in this signature.
But the question is, how can I find (in generic) source of false positives when the signature is encrypted (protected) ?
Why are they protected ? and Is it necessary that they should be ?
07-14-2009 06:19 AM
Certain signatures have hidden/encrypted parameters because we have an obligation to protect information disclosed to us. Yes, it has to be that way.
The signature which started this thread, was in fact 7304-1, which is retired and disabled by default. It's for a specific file, and this was in fact a false positive. A revised signature (7304-1) should be out in the next couple releases.
The preferred method to resolve these issues, would be to open a TAC case and if they need assitance, they engage us. Sometimes we'll pick these up off the forum, bandwidth providing.
Its helpful to provide alert output - preferably with "verbose alert" enabled - for the signature in question, and any other relevant information.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide