Re: Snort whit SS7/Sigtran
Russ via Snort-devel <[email protected]> Wed, 21 Feb 2018 08:18:15 -0500
| Newsgroups | gmane.comp.security.ids.snort.devel |
|---|---|
| Message-ID | <[email protected]> |
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 | [email protected] <mailto:[email protected]> >> >> >>> On Feb 13, 2018, at 8:27 AM, ALEJANDRO CORLETTI ESTRADA >>> <[email protected] >>> <mailto:[email protected]>> 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 > [email protected] > https://lists.snort.org/mailman/listinfo/snort-devel > > Please visit http://blog.snort.org for the latest news about Snort! _______________________________________________ Snort-devel mailing list [email protected] https://lists.snort.org/mailman/listinfo/snort-devel Please visit http://blog.snort.org for the latest news about Snort!