Re: Snort Supports SCTP

[Joshua Kinard <kumba () gentoo org>]

On 05/16/2013 7:53 AM, Russ Combs wrote:
> It is on our radar, but there are no specific plans at this point.
>
> On Wed, May 15, 2013 at 5:06 AM, marwane azzouzi
> <azzouzi.marwane () hotmail fr> wrote:
> > Hello,
> >
> > My question concerns the support of the SCTP protocol by Snort in a mobile
> > context (SIGTRAN).
> > I see that there is no preprocessor to decode the SCTP protocol such like
> > SIP or HTTP preprocessors...
> > Did the team intend to develop that feature?
> >
> > Any information ?
> >
> > Thx
> >
> > marwane

Try the attached.  I have a strange fascination with SCTP, so back in 2011,
I copied the Stream5 UDP code and made a very generic SCTP Stream5 module,
as well as duplicated all the code points where UDP was parsed to parse
SCTP.  I also added a DecodeSCTP function and various helpers to decode.c,
and other bits that I'm not going to enumerate here.  I just updated all the
code today to work with snort-2.9.4.6, and tested it on both IPv4 and
IPv6-based packet captures that I managed to hunt down off of Google.

BIG NOTE: This DOES NOT perform ANY reassembly whatsoever.  It behaves
EXACTLY like Stream5 UDP.  Once it sees two packets in opposite directions,
it treats anything thereafter as a "stream" (session?) until the timeout
limit specified.  This means this is what the preproc config settings are
like (NEW denotes new items):

      preprocessor stream5_global: \
          track_tcp yes,           \
          track_udp yes,           \
          track_icmp yes,          \
NEW       track_sctp yes,          \
          max_tcp 1048576,         \
          max_udp 1048576,         \
NEW       max_sctp 1048576,        \
          max_icmp 1048576

NEW   preprocessor stream5_sctp:   \
NEW       timeout 600

NEW   config classification: sctp,SCTP Packet,1


I also added five new rule keyword options to control what you can alert on.
 Inspiration comes from the GTP preprocessor a wee bit on a few of them.
ALL of these are discrete options, too.  Put them before any payload
keywords for maximum firepower.

sctp_num_chunks:
Checks for the number of chunks bundled into a single SCTP packet.  Format
is exactly the same as dsize and friends:
    sctp_num_chunks:<value w/ or w/o range>;
    sctp_num_chunks:42;
    sctp_num_chunks:>13;
    sctp_num_chunks:10<>20;


sctp_chunk_type:
Limits the rule to specific SCTP chunk types.  Chunk types should be
specified in UPPERCASE format (hey, it's what the RFC's do).  More than one
chunk type can be specified, up to the limit of 21 (the current number of
chunks defined by the various RFC's):
    sctp_chunk_field:<CHUNK_TYPE1>[,<CHUNK_TYPE2>,CHUNK_TYPE3>...];
    sctp_chunk_type:DATA;
    sctp_chunk_type:INIT,INIT-ACK,PAD;


sctp_chunk_field:
Checks a specific field in a given chunk.  This keyword DOES NOT require
'sctp_chunk_type', though since it contains duplicitive code, I should
probably have it rely on that keyword at some point in the future.  That
said, it's got a funky format right now, and I don't have a complete list of
the various chunk fields in mail-friendly format.  Check
SctpChunkFieldParse() in src/detection-plugins/sp_sctp_chunk_field.c for those:
    sctp_chunk_field:<CHUNK_TYPE>,<field_name>,<value w/ or w/o range>;
    sctp_chunk_field:DATA,tsn,42;
    sctp_chunk_field:FORWARD-TSN,new_tsn,>31337;
    sctp_chunk_field:INIT-ACK,num_out_streams,10<>20;


sctp_cause_code:
Check for a specific cause code ONLY in ABORT or ERROR chunks.  This keyword
requires that you specify 'sctp_chunk_type' beforehand and it must be either
'ERROR', 'ABORT', or both.  These are the only two chunk types that support
causes.  Currently, this only accepts a numeric value representing the
specific cause code.  There's a ton of those things, and I haven't gotten
around to creating unique string names for them just yet.  you can get the
current list here:
https://www.iana.org/assignments/sctp-parameters/sctp-parameters.xml#sctp-parameters-24
:
    sctp_cause_code:<value>;
    sctp_chunk_type:ABORT; sctp_cause_code:12;


sctp_chunk_flags:
Checks for various flag bits set or unset in specific chunk types.  This
keyword requires that you specify 'sctp_chunk_type' beforehand and it can
ONLY be one of the following chunk types: DATA, ABORT, SHUTDOWN-COMPLETE, or
PKTDROP.  The basic syntax is exactly like TCP's 'flags', but each of the
four (currently) supported chunk types each define their own flag bit.  See
src/detection-plugins/sp_sctp_chunk_flags.h for the current list:
    sctp_chunk_flags:<op><flag_bits>,<optional mask>;
    sctp_chunk_type:DATA; sctp_chunk_flags:*I;
    sctp_chunk_type:ABORT; sctp_chunk_flags:!T;
    sctp_chunk_type:PKTDROP; sctp_chunk_flags:*TB;


Also, a bit on the second patch that adds compiler.h.  This is borrowed from
the Linux kernel and an earlier version of this SCTP code used it to gain
some minor speed pickups in the decoder and rule options.  It defines the
likely() and unlikely() macros, which are gcc-specific, but they allow you
to "instruct" the compiler on the likely (or unlikely) conditionals.  I.e.,
everyone does a typical NULL check, if (foo->bar != NULL), but if you expect
a majority of cases will ALWAYS evaluate to true, wrap it in likely() and
gcc will save a few instructions on the assumption that foo->bar is never
NULL.  In the odd case where it is, well, you'll probably SIGSEGV anyways,
so what's the harm?  PS, never try to outsmart the compiler.  Just in some
cases, you can guide it a bit.

Snort devs should probably consider compiler.h and see what spots in the
decoder can make use of it for some small speed ups.  Well, for general
gcc-based builds that is.  With other compilers, these two macros are done
away with.

PS, yes, my copyright dates are all off.  No, I don't care.  If this were to
ever be accepted anyways, they'd all get changed.  Though, I DID borrow code
from WireShark (src/sfutil/adler32.{c|h} and crc32.h), and obviously,
compiler.h and BIT() from bitops.h in the Linux kernel.  So, however that
works.  Legal stuff, blah.

Sample rules (yes, these can use ports, too, I just wrote these up in a hurry):
alert sctp any any -> any any (msg:"SCTP DECODE TEST"; flow:established;
sctp_chunk_type:DATA; sid:42000132; rev:1; priority:1; classtype:sctp; )
alert sctp any any -> any any (msg:"SCTP DECODE TEST"; flow:established;
sctp_chunk_field:SACK,cuml_tsn_ack,>3000; sid:42000132; rev:1; priority:1;
classtype:sctp; )
alert sctp any any -> any any (msg:"SCTP DECODE TEST"; flow:established;
sctp_chunk_type:ABORT,ERROR; sctp_cause_code:12; sid:42000132; rev:1;
priority:1; classtype:sctp; )

Have fun!  I'll eventually update the patch to add the rule keywords to the
manual tex file.  Would definitely love some feedback.  Use my Gentoo
address for that.  Thanks!


-- 
Joshua Kinard
Gentoo/MIPS
kumba () gentoo org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Attachment: snort-2946-sctp-git.patch
Description:

Attachment: snort-2946-sctp-compiler_h-git.patch
Description:

Attachment: signature.asc
Description: OpenPGP digital signature

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

_______________________________________________
Snort-devel mailing list
Snort-devel () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-devel
Archive:
http://sourceforge.net/mailarchive/forum.php?forum_name=snort-devel

Please visit http://blog.snort.org for the latest news about Snort!