Differences

This shows you the differences between two versions of the page.

--- articles:segmentsmack [2018/08/24 19:53] – created veera
+++ articles:segmentsmack [2018/08/24 23:18] (current) – [Tradeoff] veera
@@ Line 1: / Line 1: @@
 ====== 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 but you may be wondering if the Trisul LuaJIT API can handle per packet analysis of this sort.  We put this in a testbed on a Single Core-i3 @ 3.2Ghz and 170Mbps there were no packet drops.
+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 ====
-{{:articles:rat2.png?400|}}
+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.