[Snort-devel] Snort whit SS7/Sigtran

Russ rucombs at cisco.com
Wed Feb 21 08:18:15 EST 2018


Alejandro,

Would you be interested in trying to update this patch for Snort 3.0?  
The Snort 3.0 beta should be released this summer (ish).  We could 
certainly help out.

Russ

On 2/14/18 4:10 AM, Joshua Kinard via Snort-devel wrote:
> On 2/13/2018 1:49 PM, Joel Esler (jesler) via Snort-devel wrote:
>> Adding the snort-team on this one.
>>
>> *--*
>> *Joel Esler *| *Talos:* Manager | jesler at cisco.com <mailto:jesler at cisco.com>
>>
>>
>>> On Feb 13, 2018, at 8:27 AM, ALEJANDRO CORLETTI ESTRADA
>>> <alejandro.corlettiestrada.ext at telefonica.com
>>> <mailto:alejandro.corlettiestrada.ext at telefonica.com>> wrote:
>>>
>>> Hello,
>>>   
>>> My name is Alejandro Corletti Estrada, I am a  Engineering Doctor, I have
>>> been working in networks and security for many years (I have written 3 books
>>> in Spanish:  "Seguridad por Niveles",  "Seguridad en Redes" y
>>> "Ciberseguridad, una Estrategia Informático/Militar  - "Security by Levels",
>>> "Security in Networks" and "Cybersecurity, a Computer / Military
>>> Strategy").    With Snort I have been working for almost 20 years, in 2001 I
>>> published an article called "Nessus Methodology - Snort" and another one "
>>> Level of immaturity of the NIDS "(both in Spanish), were very successful in
>>> the Hispanic world.
>>>   
>>> Currently I am in the "Corporate Audit of Security in Networks and Systems"
>>> of the Telefónica Group.
>>>   
>>> I am writing to you, because there is a critical safety problem with the
>>> Signaling System 7 (SS7), more particularly in the "Sigtran" stack, which is
>>> responsible for transporting SS7 over IP. I have been studying the subject
>>> for months and now (with my team) we are analyzing traffic patterns of this
>>> family of protocols and looking for anomalous traffic in them. We are using,
>>> as we did before, Wireshark in combination with Snort.
>>>   
>>> Within the known vulnerabilities (which are several), to work with Snort
>>> there are two fundamental problems:
>>>   
>>> 1. The *SCTP* protocol (Stream Control Transmission Protocol) that replaces
>>> TCP in Sigtran.
>>> 2. _Absence of rules for SS7_ (this includes several protocols: MAP, TCAP,
>>> ISUP, CAMEL, etc ...)
>>>   
>>> I would like to open with you a new "work team" or committee that is
>>> responsible for this issue, because I believe that Snort could be the
>>> solution to this International problem. Currently, all the telephone
>>> operators in the world are suffering, and we at this moment (with my team)
>>> can do much about it, if we count on your support, because we have access to
>>> all the nodes and network elements that operate ss7 / Sigtran and access to
>>> this traffic.
>>>   
>>> Within this line of action there would be two aspects on which I would like
>>> to join efforts with the entire Snort community:
>>>   
>>> 1. Create the necessary library to be able to call rules with "SCTP" protocol
>>> (instead of ip, tcp, icmp .... etc) this would be very important.
>>> 2. Begin to SS7 develop rules for detecting anomalous traffic patterns.
>>>   
>>> Please tell me what steps or actions I should take to move forward on this topic.
>>>   
>>> With all sincerity, I can assure you that I am one of the few people who know
>>> this topic in depth (for in the 90's I was teaching the SS7 courses, before
>>> its integration with Sigtran), I have studied it in detail and I have access
>>> to all the traffic that is needed.
>>>   
>>> This project can be an international initiative to which undoubtedly, as it
>>> becomes public, all the telephone operators in the world will be added.
>>>   
>>> Regards and I am waiting for your response
>>> Alejandro Corletti Estrada.
>>>   
>>> PS: my English level is not very good (sorry)
> [snip]
>
> I got bored a couple of years ago and hacked together a basic SCTP support for
> Snort-2.9.5.x to 2.9.6.x.  It has enough logic to parse "alert sctp ..." rule
> formats, including using ports and IPv4/IPv6 addresses; should handle chopping
> up SCTP packets and placing the Snort offset pointers at the right spots; has a
> few protocol decoder rules; and includes a couple of new rule options to
> constrain a rule to only look at specific SCTP chunk types and their associated
> fields.  Can use stock Snort rule options alongside the new ones.
>
> I never took it beyond that point, so it doesn't support any stream reassembly
> beyond what Snort's existing UDP reassembler does (because I duped the code and
> search/replaced "udp" with "sctp" as appropriate).  Snort's internals for
> stream reassembly are terribly documented in 2.9.x.  I think this is one of the
> end-goals of Snort++, which has *much* cleaner code (but I am not a fan of the
> all-Lua approach).
>
> It doesn't even try to handle SCTP's multi-homing capability, since additional
> association pairs are set up in the middle of the handshake using optional
> parameters to the INIT chunk type.  Snort's only able to work out an address
> pairing by what's available in the OSI layer 3 header.  Pretty much everything
> else, if it's in the Layer 4 payload, is game for the fast-pattern matcher.
> Anything more SCTP-specific is going to require lots of additional code, such
> as new static or dynamic preproc modules, probably a few more rule keywords,
> etc.  Things I have no free time for.
>
> SCTP is the superior transport protocol in my opinion.  Multi-homing,
> multi-streaming, message-level framing, sensible extensibility via new chunk
> types, built-in DDoS protection, etc.  It's the only one of IANA's four general
> purpose transport protocols that is both artistic and functional at the same
> time.  If only we could get rid of TCP...
>
> I've attached the last patch I cut from a private git repo about two or three
> years ago, in case anyone wants to use it and make magic happen.  I think it'll
> apply against vanilla Snort-2.9.6, but try 2.9.5 or 2.9.7-alpha if not and then
> work up from there.
>
> Patch also includes the gcc compiler branch-optimizations "likely()" and
> "unlikely()", from the Linux kernel's "compiler.h" header, I think from the 3.x
> branch.  The function to deal with SCTP's padding alignment requirement is from
> Wireshark, along with the checksumming code for CRC32 and Adler32.
>
> I did not get around to drafting TeX syntax up in the manual for the new rule
> options, so one will need to read the source code to work out how I designed
> those to work.  The top of each *.c file for the new options includes a quick
> documentation comment.
>
> Can't really contribute anything beyond this right now.  But would be
> interested to know if this has any practical use to anyone.
>
> --------
>
> Basic configuration of "stream_sctp":
>
> preprocessor stream5_global:			\
> 	track_tcp yes,				\
> 	track_udp yes,				\
> 	track_sctp yes,				\
> 	track_icmp yes,				\
> 	max_tcp 1048576,			\
> 	max_udp 1048576,			\
> 	max_sctp 1048576,			\
> 	max_icmp 1048576
>
> preprocessor stream5_sctp:			\
> 	timeout 600
>
> --------
>
> Here's a few sample rules that detect traffic in some test PCAPs I dredged up
> for testing.  Should work against any basic SCTP traffic, though:
>
> config classification: sctp,SCTP Packet,1
>
> alert sctp any any -> any any (msg:"SCTP DECODE TEST 1"; sctp_chunk_type:DATA;
> sid:17000132; rev:1; classtype:sctp;)
>
> alert sctp any any -> any any (msg:"SCTP DECODE TEST 2"; flow:established;
> sctp_chunk_field:SACK,cuml_tsn_ack,>3000; sid:17000133; rev:1; classtype:sctp;)
>
> alert sctp any any -> any any (msg:"SCTP DECODE TEST 3"; flow:established;
> sctp_chunk_type:ABORT,ERROR; sctp_cause_code:12; sid:17000134; rev:1;
> classtype:sctp;)
>
> --------
>
>   doc/README.UNSOCK                                         |   12
>   doc/README.csv                                            |    5
>   preproc_rules/decoder.rules                               |   60
>   preproc_rules/preprocessor.rules                          |    8
>   src/active.c                                              |    7
>   src/compiler.h                                            |   43
>   src/decode.c                                              |  804 +++++++++
>   src/decode.h                                              |  472 +++++
>   src/detection-plugins/Makefile.am                         |    7
>   src/detection-plugins/Makefile.in                         |   19
>   src/detection-plugins/detection_options.c                 |  169 +
>   src/detection-plugins/sp_clientserver.c                   |    9
>   src/detection-plugins/sp_sctp_cause_code.c                |  340 ++++
>   src/detection-plugins/sp_sctp_cause_code.h                |   39
>   src/detection-plugins/sp_sctp_chunk_field.c               |  681 ++++++++
>   src/detection-plugins/sp_sctp_chunk_field.h               |  129 +
>   src/detection-plugins/sp_sctp_chunk_flags.c               |  481 +++++
>   src/detection-plugins/sp_sctp_chunk_flags.h               |   81
>   src/detection-plugins/sp_sctp_chunk_type.c                |  500 +++++
>   src/detection-plugins/sp_sctp_chunk_type.h                |   66
>   src/detection-plugins/sp_sctp_num_chunks.c                |  296 +++
>   src/detection-plugins/sp_sctp_num_chunks.h                |   47
>   src/dynamic-output/plugins/output_lib.h                   |    1
>   src/dynamic-output/plugins/output_plugin.c                |    1
>   src/dynamic-plugins/sf_engine/sf_snort_detection_engine.c |    3
>   src/dynamic-plugins/sf_engine/sf_snort_packet.h           |  219 ++
>   src/fpcreate.c                                            |  116 +
>   src/fpcreate.h                                            |    9
>   src/fpdetect.c                                            |  102 +
>   src/output-plugins/spo_alert_sf_socket.c                  |    7
>   src/output-plugins/spo_alert_syslog.c                     |    3
>   src/output-plugins/spo_alert_unixsock.c                   |    7
>   src/output-plugins/spo_csv.c                              |   21
>   src/output-plugins/spo_database.c                         |   35
>   src/output-plugins/spo_log_ascii.c                        |    5
>   src/parser.c                                              |  167 +
>   src/plugbase.c                                            |   16
>   src/plugin_enum.h                                         |    4
>   src/preprocessors/Stream5/Makefile.am                     |    3
>   src/preprocessors/Stream5/Makefile.in                     |   29
>   src/preprocessors/Stream5/snort_stream5_icmp.c            |    9
>   src/preprocessors/Stream5/snort_stream5_sctp.c            |  847 ++++++++++
>   src/preprocessors/Stream5/snort_stream5_sctp.h            |  287 +++
>   src/preprocessors/Stream5/snort_stream5_session.c         |   66
>   src/preprocessors/Stream5/snort_stream5_session.h         |    2
>   src/preprocessors/Stream5/stream5_common.c                |   63
>   src/preprocessors/Stream5/stream5_common.h                |   58
>   src/preprocessors/Stream5/stream5_ha.c                    |   10
>   src/preprocessors/perf-base.c                             |  191 +-
>   src/preprocessors/perf-base.h                             |   28
>   src/preprocessors/perf-flow.c                             |  178 +-
>   src/preprocessors/perf-flow.h                             |   20
>   src/preprocessors/perf.c                                  |    2
>   src/preprocessors/portscan.c                              |  186 ++
>   src/preprocessors/portscan.h                              |    7
>   src/preprocessors/spp_frag3.c                             |    9
>   src/preprocessors/spp_sfportscan.c                        |   76
>   src/preprocessors/spp_stream5.c                           |  610 ++++++-
>   src/preprocessors/stream_api.h                            |   19
>   src/preprocessors/stream_expect.c                         |    2
>   src/profiler.c                                            |    3
>   src/rule_option_types.h                                   |    5
>   src/sf_protocols.h                                        |    2
>   src/sfutil/Makefile.am                                    |    1
>   src/sfutil/Makefile.in                                    |    6
>   src/sfutil/adler32.c                                      |   59
>   src/sfutil/adler32.h                                      |   41
>   src/sfutil/crc32.h                                        |  130 +
>   src/sfutil/sfportobject.c                                 |    4
>   src/sfutil/sfportobject.h                                 |    3
>   src/snort.c                                               |    2
>   src/snort.h                                               |   27
>   src/target-based/sftarget_protocol_reference.c            |    6
>   src/target-based/sftarget_protocol_reference.h            |    1
>   src/util.c                                                |  117 +
>   src/util.h                                                |   20
>   82 files changed, 8019 insertions(+), 349 deletions(-)
>
>
>
> _______________________________________________
> Snort-devel mailing list
> Snort-devel at lists.snort.org
> https://lists.snort.org/mailman/listinfo/snort-devel
>
> Please visit http://blog.snort.org for the latest news about Snort!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20180221/60066f2c/attachment-0001.html>


More information about the Snort-devel mailing list