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.
------------------------------------------------------------------------
