SigID 3329, the Regex is protected?

[pbobby]

I've had this signature trigger a few times on one of my internal sensors. While we are waiting for the worm to hit, I turnedn on IPLogging for this signature so I could begin to determine what RPCSS overflow traffic looks like.

So far, I"m not sure what I am looking at. It appears that the beginning packets of the IPLog are related to the source executing printer traffic. False positive?

I took a look at the signature settings themselves (v4.1 of the sensor) but the regex was protected. Is it protected because you are privy to knowledge that could help someone generate a remote exploit?

[a.arndt]

I've got the same problem with SigID 3325 - RegexString value is hidden.

I know that when you make a "User Defined" signature using the TCP.STRING engine that the RegexString field is a mandatory field, so perhaps Cisco is hiding all mandatory fields in the signatures that they provide?

Just a thought...

[pbobby]

Yeah the only reason I asked was because in a previous post of mine, a Cisco rep stated that in v4 of the sensors, we could see/modify all parameters of signatures/engines.

Link as reference: http://forums.cisco.com/eforum/servlet/NetProf?page=netprof&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40%5E1%40%40.ee9c446/5#selected_message

[mcerha]

Yes, signature 3329 is protected due to an NDA agreement. This obviously makes troubleshooting false positives more difficult. If you are able, you can send the IP logs directly to me at mcerha@cisco.com. I can confirm if they are false positives or not.

[marcabal]

Just to clarify a few things.

In version 3.1 all of the regular expressions on the Cisco signatures were "hidden" along with some other parameters as well. Users wanting this information should upgrade to 4.x or view the signatures on a 4.x sensor (the regular expressions are usually the same between the 2 versions with a few exceptions where new engines were specially created in 4.x).

We received numerous user requests to be able to view the regular expressions.

So in version 4.0 we tried to make all of the fields user viewable and just "protect" them from being modified.

However, in doing so we realized that there were some signatures for which we could not make the regular expression viewable because of NonDisclosure Agreements (NDA) with other companies or because (as you stated) it would expose to much information about a vulnerability that was not public knowledge.

The signature you mentioned was because of an NDA with another company.

So for these few special cases the specific fields are marked as "hidden" and will not be released to customers and you would need the aid of Cisco's signature developers to diagnose for false positives.