[Snort-devel] Extending Snort to other protocols?

Joshua.Kinard at ...3108... Joshua.Kinard at ...3108...
Mon Feb 14 22:47:51 EST 2011


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




More information about the Snort-devel mailing list