Feature #346
closed
Added by Billy Haines over 12 years ago.
Updated over 11 years ago.
Description
A feature that may or may not have been discussed already is the addition of Lua scripting capabilities ie. a command shell with Lua and possibly a Lua traffic analysis module similar to Snort 3. This would be a long term feature if implemented at all but I wanted to mention it as many security tools other than Snort now offer Lua scripting support (Nmap and Wireshark for instance). Metasploit will probably see this support in the future as well in order to fully support Nmap's NSE since Nmap is now distributed with Metasploit.
Incidentally, another tool that may benefit Suricata down the line is the Perl Compatible Regular Expression project (PCRE), www.pcre.org. I believe the benefits of both are more or less obvious but wanted to mention them in the event that they had not been considered as I believe that some of the long-term goals of the project could benefit from their inclusion.
I think using lua could be interesting, a couple of other OSS security tools use it (snort3/snortsp, modsecurity, ironbee). I remember some people disliking lua for this purpose as well, but I can't remember exactly what their issue with it was.
Wrt pcre, what additional support in Suricata are you looking for? It's heavily used already.
A huge benefit of lua is the ease of use of the language, think I read that the first 80 pages of the book covers all syntax, as well as the ability to fully compliment Suricata functionality. Look at the incredible contributions that Nmap's NSE has received recently. Ditto for Wireshark... If implemented smartly then Suricata could receive open-source contributions from the lua community in addition to the application and rule support that it is receiving now. Just a thought.
One thought is that everything Suricata could be treated as a library and scriptable with lua. Not only modules, although the ability for the security admin to script/plug in modules would be huge, but also rules, protocol libraries etc. Since lua plays nice with C this provides a lot of flexibility. Of course Perl and Python are both awesome as well but I hold that lua would be a perfect fit here for the aforementioned reasons.
No worries regarding PCRE. It was covered in a GSoC project, upcoming. Thanks for the feedback.
What was covered in a GSoC project? What "worries" about PCRE are you referring to?
Victor Julien wrote:
What was covered in a GSoC project? What "worries" about PCRE are you referring to?
The google re engine?
- Assignee set to Victor Julien
- Priority changed from Low to Normal
- Target version set to TBD
Will and I had some discussions on LUA, where we'd keep it really simple. A scheme where we'd invoke a script from a rule where the rule keyword can indicate what buffer (pkt data, stream data, http uri, http request body, etc) will be inspected.
Something like:
lua:<buffer>,<script>;
so that would be:
alert http any any -> any any (msg:"lua example"; content:"some anchor"; http_client_body; filemagic:"PDF Document"; lua:http_client_body,inspect_pdf.lua; sid:1; rev:1;)
LUA jit is supposed to be quite fast.
- Status changed from New to Closed
- Target version changed from TBD to 1.4beta2
- % Done changed from 0 to 100
Initial support is implemented.
Also available in: Atom
PDF