Maybe I am overlooking something -- but it doesnt appear that I can view specifically the strings that Cisco is using to alarm on their signatures. For example, if I wanted to see the specific packet data that Cisco is flagging for smb authorization failure, how would I do that? I am running Director 2.2.3 and sensor 3.0s11.
I should be able to write my own binary payload matches with SILVER by escaping the octal or hex patterns, correct? Is this what Cisco is doing internally? Why don't we get any visibility into the Cisco provided alarms?
*grin* It's great that this thread has been left untouched.
Anyway, IDS companies are guard their signature secrets very closely.
Take a look at Snort, and you'll see open source signatures, and the byte patterns they match.
The good and bad of proprietary information is that Cisco can protect their product, but they can't troubleshoot as well. All we do is say "it gives false alerts", but we have no idea why. The whole debug process is quite laborious indeed.
Anyway, you wont be seeing the internal signatures any time soon. My suggestion is to look at Snort to get an idea of what byte patterns can be used. The majority of bugs/signatures look for essentially the same thing.
The truth of the matter is that many of our signatures are far more involved than simple pattern matches. It is true that you can write SMB signatures that will alarm using binary matches, but you will find them to be very noisy. SMB in particular is a difficult protocol to decode. We are in the process of writing an SMB engine that conforms to SILVER, but for the time being that particular decode is still buried in our binary. That is why you can't see them.
We are considering opening up the entire set of signature parameters for all of the SILVER based signatures. It does present a unique problem though. There are things that we have done to differentiate ourselves from some of our competitors and if we disclose completely we do run the risk of them being able to more easily discern what it is that we are doing. But as you say it also makes it much more difficult for the users to know exactly why a signature fired and to help us to tighten up signatures that may be loose.
So I open it up to this forum would the bulk of you prefer that all of the parameters for our internal signatures be readable.? (We can not make them configurable because of TAC considerations. If there is a broken signature we need to be certain that it is our signature and not one that some one has mucked with and then had a problem.) Respond to this thread and I will take your requests under advisement.
As far as converting snort is concerened be prepared for a deluge of events as many of the snort signatures are in duplicate and triplicate and are fairly easily evaded. We are considering writing a SNORT to SILVER converter to be placed in the open source community though for those who want it. Since I'm asking for input, I'll ask for more here on this. Who would like to see such a beast? Once again this would be an open source tool that would be freely available, but would not be supported by CIsco. Also important to note is that any signatures generated would not be the subject of TAC support.
I would like to see the data -- yes. I would also be interested in a snort -> silver conversion utility.
Re: evasion of snort signatures. I said I wanted to convert some of the signatures over, not do a bulk import. There are some very specific things that I am looking for. ALso, ALL signature based IDS is vulnerable to evasion via obfuscation in one way or another. Cisco isn't doing any heuristics magic juju. I just want to be able to better position my sensors to protect my enterprise, and feel that I can do that if I can get more visibility into the current signature set, and the ability to create my own comparably granular sigs.
You are correct that all IDS's (signature based, heuristic based, or those like ours which is a composite) are vulnerable to evasion. I am definitely not trying to beliitle the efforts of others and I freely admit that we have short comings.
My main point was to try and bring attention to the fact that the rulesets that are placed on the SNORT forums are typically developed in response to a specific exploitation of a vulnerability. In some cases this is sufficient as the amount of variability in launching a successful attack is minimal. In others however an unwary user might feel that they have a vulnerability covered when in fact they do not. As an examle almost all of the snort rulesets for buffer overflows rely on simple pattern matches. In most cases they are simply looking for the NOP sled or some other binary pattern that was present in a particular exploit of the vulnerability. NOP sleds are easily manipulated by programs such as ADM Mutate and the binary patterns that they are looking for could easily be replaced by other executable patterns. Cisco typically does not perform simple pattern matches for buffer overflows, we go to the root of the problem (in cases where an immediate solution is needed we will resort to this as an interim solution). The protocol is decoded and the command and the arguments being passed to it are analysed to insure that the contents are within the bounds of what is expected by the program. If they exceed the size expected by the program an alert is generated.
Currently we have only exposed a fraction of what we do under the covers via SILVER. In many cases we are having difficulty in finding an easy way to expose it.
In closing I would like to say that I understand your desire for both visibility and flexibilty in the way in which you protect your network. I think that the open source tools provide a valuable resource to the entire community and I hope that we will be able to produce a tool for you that will allow you to have the ability to capture that resource. I applaud you for actively pursuing it.
Although the direction of this thread is going elsewhere, I will answer your specific question about SMB. SMB signatures are not pattern match signatures. There is a full SMB decoder that looks for specific SMB messages and data therein.
As Kevin notes elsewhere in this thread, we are in the processes of porting it (SMB protocol decoder) to a parameterized engine (e.g. SILVER capable engine). SMB is a hairy, ugly protocol...been there, done that, hoping there isn't a sequel.
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...
[toc:faq]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 and UDP are I...