Trisul Network Analytics
Developer Zone

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Trisul Script to detect TCP SegmentSmack attack ======


SegmentSmack [[https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-5390|CVE-2018-5390]] is a vulnerability in the Linux TCP/IP stack. It can only be detected by traffic monitoring and not by a single signature.

We just released a [[https://github.com/trisulnsm/trisul-scripts/tree/master/lua/frontend_scripts/segmentsmack|PoC script on our Github page]] that shows you how you can use Trisul to detect the attack.

This article talks a bit about the programming aspects of the PoC code.

===== The script and LuaJIT =====

The script itself is a ''simplecounter'' script. These scripts have an ``onpacket`` method that is called on each packet with a pointer to that layer, in this case TCP. 

We then make use of `sweepbuf.lua`  in the [[https://github.com/trisulnsm/bitmaul|BITMAUL protocol dissection library]] to get the TCP and IP fields. 

For each flow direction we maintain a variable that contains the expected next sequence number, anything that doesnt match is treated as an out-of-order. A real reassembly engine would maintain all of the segments, but we arent interested in reassembly. Rather we just want to get a sense of whether the sequence numbers are increasing without holes. A proxy metric.

==== Optimization ====

The script is completely unoptimized, you can make several changes

  - only monitor the forward direction : attacker -> target side of each flow.
  - if you detect things are fine for say 500 segments , stop monitoring that flow. It is likely good
  - extreme optimizations can involve using LuaJIT FFI to parse the fields instead of BitMaul. But we can tell you this rule, never underestimate LuaJIT !! So this would be a last resort.  

===== Performance impact =====

The PoC script is unoptimized, which breaks up EVERY TCP packet even if encrypted into its fields. You might be wondering if the Trisul LuaJIT API can handle high-speed per packet analysis of this sort.  

We put this code in a testbed on a Single Core-i3 @ 3.2Ghz and 170Mbps there were no packet drops.

The following is output from our diagnostic tool RAT.  The system had 12 other rather big LUA APPs running, still we were able to do 180Mbps on a single i3 core.

To start rat 
<code>
source /usr/local/share/trisul-probe/trisbashrc
rat.rx
</code> 

{{:articles:rat2.png?800|}}


==== Tradeoff ====


We are very pleased with the [[https://www.trisul.org/docs/lua/index.html|Trisul LuaJIT API]] , while this is not the highest-performance as a native C/C++ module, it is super fast to develop safe detection code at maybe 90% of the speed.