Snort mailing list archives
Re: Snort Supports SCTP
From: Joshua Kinard <kumba () gentoo org>
Date: Mon, 20 May 2013 01:20:16 -0400
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!
Current thread:
- Snort Supports SCTP marwane azzouzi (May 15)
- Re: Snort Supports SCTP Russ Combs (May 16)
- Re: Snort Supports SCTP Joshua Kinard (May 19)
- Re: Snort Supports SCTP Joshua Kinard (May 20)
- Re: Snort Supports SCTP Joshua Kinard (May 19)
- Re: Snort Supports SCTP Russ Combs (May 16)