User Tools
articles:segmentsmack
Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
|
articles:segmentsmack [2018/08/24 14:23] veera created |
articles:segmentsmack [2018/08/24 17:48] (current) veera [Tradeoff] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== Trisul Script to detect TCP SegmentSmack attack ====== | ====== 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 ===== | ===== 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. |
articles/segmentsmack.1535120603.txt.gz · Last modified: 2018/08/24 14:23 by veera
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
