Re: Extending Snort to other protocols?

[Steven Sturges <ssturges () sourcefire com>]

Hi Joshua--

This is somewhat of a complex task as it touches many parts of
the code.

Beyond the decoder and parser, you'd have to do something to build
pattern matching engine groups and determine how to break them out
(ports/services work well for UDP/TCP -- not sure how IPX would
break down).  That would involve touching the fpcreate/fpdetect.c
files as well as the rule parsing, etc code.  Beyond that there
is code that evaluates the IPs and ports of the rule (aka the "otn"
in the code).

Overloading the rules language in a particular way may not be a good
idea since these are protocols that really serve completely different
purposes.

In some cases, it really depends on what you're looking to do with
the Snort rules.  I'm not sure it makes as much sense with IPX as
it does with SCTP.  IPX really is a different beast as you point
out... something that I wonder whether would be better covered
with specific decoders and related decoder rules or a simple
preprocessor.

Off and on over the years, we've had discussions of how we could
improve the rules language, and in particular the header pieces
of it -- protocols/IPs/ports.  Obviously when you go to define
a language, everyone has their opinions on syntax/grammar...
And backward compatibility to some degree is a must given the
large number of Snort users we have.

Adding rule options is definitely much easier, as they simply
chain to the previous option.  The basics for each rule option
are parsing, evaluation, some hashing of data structures and cleanup.

We haven't really explored adding additional layer 3 groups, nor
layer 2, as there haven't been too many requests for it given
Snort's typical deployment scenarios.

Cheers.
-steve

On 2/14/11 10:47 PM, Joshua.Kinard () us-cert gov wrote:
> Hi snort-devel,
>
> Forgive me if this question/thought process has been asked before, but
> what's the relative amount of work needed to extend Snort to other
> protocols?  Right now, Snort does TCP, UDP, and ICMP.  It allows 'ip' to
> be used for anything else, but at that point, you're slowing it down by
> operating on raw network traffic, as ip rules are very expensive.
>
> I'm not much of a coder, but I was looking through the parser.c and
> decoder.c files, and what stands out to me is that the support of these
> four core protocols is deeply ingrained in the code.  Adding one or more
> new protocols would involve tweaking things like various conditional
> blocks, adding new #define macros, new structs, etc.  I.e., a lot of
> plumbing.
>
> In contrast, adding new rule options looks a lot easier.  While I've not
> found any documented API, there is a notable amount of commonality in
> the Snort detection plugins.  Each rule option handles its own specific
> bits, and links into the higher-level code through a few aptly-named
> functions that correspond to a higher-level API.  Has something like
> this been considered for things like the protocols?
>
> Consider the SCTP protocol.  It supports the same format of ports
> alongside TCP and UDP, but pretty much everything else differs from that
> point onwards.  Adding the logic into the existing codebase to support
> scanning SCTP packets looks like it'd be a bit complicated, but not
> entirely difficult, assuming one fully understands SCTP (I don't).  But
> it could easily leverage the existing rule syntax.  I.e., alert sctp
> 203.0.113.57 :1024 ->  198.51.100.134 $HTTP_PORTS ( ... ), which would
> make adoption by rule writers fairly straight-forward.
>
> Then consider a protocol like IPX, which is a completely different
> animal.  Adding support for a protocol like that would be much more
> difficult than SCTP.  For IPX to leverage the existing rule syntax,
> you'd have to do things like redefine the nature of the address/port
> fields.  I.e., src/dst address becomes the src/dst network&  node, and
> src/dst port becomes the src/dst IPX socket.  And that's not even
> getting into the sub-protocols, like SPX or NCP.  I.e., alert ipx
> 00000001.001731e0d9f2 0x4004 ->  00000004.00015c24a371 0x0452 ( ... ).
> No idea if that's even valid IPX routing...finding PCAPs of it is really
> difficult since it's an obsolete protocol.  But it gets the idea across.
>
> Assuming a modular framework kind-of-thing, the parser could check the
> protocol first, then offload the remaining fields to a protocol module
> to handle the implementation-specific bits, and that can hand back to
> allow other rule processing logic to follow.  There already appears to
> be very high-level detection of various protocols in decoder.c in the
> form of the Decode*() functions.  But those just count the occurrence of
> such a protocol for statistics (as far as I can tell).  These could make
> for decent starting points for stub modules, at minimum allowing someone
> to easily write modules to report back the occurrence of different
> protocols on the network being monitored.
>
> This is all just late-night brainstorming...I'm uncertain of the actual
> feasibility of things, but seeing some of the more modular aspects of
> the Linux kernel internals got me wondering.  Thoughts?
>
> --J
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Snort-devel mailing list
> Snort-devel () lists sourceforge net
> https://lists.sourceforge.net/lists/listinfo/snort-devel

------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Snort-devel mailing list
Snort-devel () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-devel