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?
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?
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 email@example.com. I can confirm if they are false positives or not.
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.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...