Roger that, Exchange Server 5.5 and any user (remote or local) triggers it here. Thats a lot of false positives. Guess that means there'll be yet-another-update soon :(
Do you have any more details you can provide? What destination ports, patterns of activity, network traces, etc...? I'd like try and tweak this signature a bit more, and need some input from you guys in the field. MSRPC usage and traffic can be quite arbitrary at times.
YES; all valid traffic between exchange servers trigger this signature.
Perhaps it needs more fine tunning.im going disable
to wait for correction
Would it be possible for either of you to turn on packet capture or even better ipLogging of the signature? I have some guesses as to why this sig may be firing innappropriately, but if I had some sample of network traffic, I could nail it down.
There are also some alarms fired with the destination address of the Primary or secondary Domain Controller, destination port 1026.
We've addressed some of the false positives we've found with this sig. The fix will be in for S86 and is can be tracked with DDTS CSCee31185.
the bug workaround says " Upgrade to signature update S86 or later."
But the S86-readme.txt says "No signatures have been tuned in this update."
There are also no caveats mentioned.
So has the bug been fixed in S86 or not?
May I remove my filters safely?
Based on the feedback I have recieved here, the signature has been tuned and altered abit. It should now have a much better fidelity. Please go ahead and re-enable it. It should not be nearly as noisy now. And post back if you can and let me know how it goes.
Yes, the signature seems to be fixed.
But how can we rely on a signature update system when there is no notice of signature modification in the readme file?