Re: Need advices regarding signature tunning...

[Jeremy Bennett <jeremyfb () mac com>]

On Sep 21, 2007, at 11:13 AM, Jason wrote:

> Jean-Pierre FORCIOLI wrote:
> > Hi,
> >
> > I reviewed several IDS/IPS products and I concluded that there is  
> > two kind
> > of signatures languages.
> > First one, the simplest, allows attack detection customization by  
> > changing
> > some value in the signature, or allows creating new attack by  
> > adding a one
> > line rule (snort rule).
>
> Simple snort rule.

I'd call this the pattern-matching approach, More to the point 'pure  
pattern matching.' These are often the easiest to understand and to  
write. You generate or otherwise conceive of the traffic you want to  
detect and you write a regular expression, or similar, to match it.   
More advanced pattern matching engines will allow you to set simple  
state variables based on patterns and to use those state variables as  
conditions in later patters. These are still basic pattern matchers,  
though.
The other advantage to this approach is that performance is often  
much easier to attain. Tons of research has gone into this are and  
just about every hardware designer has proposed a network-level chip  
that will do fast pattern matching on traffic.
However, as protocols become more complex and vulnerabilities move up  
the OSI stack simple pattern matching becomes limited. Each layer of  
the stack introduces its own ambiguities and can result in many  
different ways a single exploit can be transferred. Almost all IDS  
systems now do some form of URL normalizing for example but this is  
only the tip of the iceberg. You can, of course, overcome a lot of  
this by using more and more rules and generating more and more state  
but maintaining the rule sets becomes cumbersome and will,  
eventually, stretch the capabilities of even the best chips and systems.
The final challenge to this approach is that it is, inherently,  
stream-based. The system will analyze a TCP connection from start to  
finish in one direction or a set of UDP packets that have been merged  
(or not) into a single stream. Often these streams are unidirectional  
with only minimal state shared between the upstream and downstream  
sessions.
> > Second one, the hardest,  allows full signature or new protocol  
> > state machine
> > development. by mean of a complete programming language (N-code).
>
> Multiple Snort rules to model protocol state.

I'd say multiple snort rules fall into the category of pattern  
matchers. The other approach is code-based. Just like vulnerable  
clients and servers write their protocol parsers in full featured,  
turing-complete, languages this approach uses some programming  
language to implement bits of code that handle specific sets of  
traffic. Many approaches are possible here. Usually the system is  
built from some set of protocol engines. Each engine understands and  
processes a given protocol and will analyze it for exploits and  
vulnerabilities. Most vendors that take this approach use a custom  
designed language that continues to provide a strong pattern-matching  
platform as well as the ability to build complete engines.
Obviously, the strength here is in the flexibility and completeness  
possible when you can exactly mirror what is going on in a particular  
vulnerable client or server. Likewise this approach makes it very  
easy to implement a system that will find known exploits, attempts on  
known vulnerabilities, and even protocol or usage anomalies. Engines  
can be extremely high performance and can be mixed, matched, and  
layered to accurately model the real-protocol stacks in use.
The downside here is that these things are often hard to write. The  
power of a full programming language comes with the baggage of a full  
programming language. Subtle bugs can render a system useless. Poor  
programming can bring even the beefiest IPS processor to its knees.  
Finally, someone needs to maintain all of these engines as the  
protocols evolve and new servers and clients are released. Every  
update needs to be fully QAed to make sure it did not break anything,  
etc.


Finally, I should point out that ever IPS system really does both of  
these approaches. The difference is where in the OSI stack they stop  
writing engines and start writing patterns. Some use engines only at  
layers 2-3. Others take engines all the way up to layer 7 and beyond.

-J

------------------------------------------------------------------------
Test Your IDS

Is your IDS deployed correctly?
Find out quickly and easily by testing it 
with real-world attacks from CORE IMPACT.
Go to http://www.coresecurity.com/index.php5?module=Form&action=impact&campaign=intro_sfw 
to learn more.
------------------------------------------------------------------------