Snort mailing list archives
Re: Snort whit SS7/Sigtran
From: Russ via Snort-devel <snort-devel () lists snort org>
Date: Wed, 21 Feb 2018 08:18:15 -0500
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 () cisco com <mailto:jesler () cisco com>On Feb 13, 2018, at 8:27 AM, ALEJANDRO CORLETTI ESTRADA <alejandro.corlettiestrada.ext () telefonica com <mailto:alejandro.corlettiestrada.ext () telefonica com>> wrote: Hello,My name is Alejandro Corletti Estrada, I am a Engineering Doctor, I havebeen 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 theSignaling 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 Snortthere are two fundamental problems:1. The *SCTP* protocol (Stream Control Transmission Protocol) that replacesTCP 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 isresponsible 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 liketo 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 knowthis 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 itbecomes public, all the telephone operators in the world will be added.Regards and I am waiting for your responseAlejandro 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 () lists snort org https://lists.snort.org/mailman/listinfo/snort-devel Please visit http://blog.snort.org for the latest news about Snort!
_______________________________________________ Snort-devel mailing list Snort-devel () lists snort org https://lists.snort.org/mailman/listinfo/snort-devel Please visit http://blog.snort.org for the latest news about Snort!
Current thread:
- Re: Snort whit SS7/Sigtran Joel Esler (jesler) via Snort-devel (Feb 13)
- Re: Snort whit SS7/Sigtran Joshua Kinard via Snort-devel (Feb 14)
- Re: Snort whit SS7/Sigtran Russ via Snort-devel (Feb 21)
- <Possible follow-ups>
- Re: Snort whit SS7/Sigtran Al Lewis (allewi) via Snort-devel (Feb 13)
- Re: Snort whit SS7/Sigtran Joshua Kinard via Snort-devel (Feb 14)