How can I determine if the .lua scripting is being called by Suricata?

1

I’m trying to determine if a .lua script is being called by Suricata or just a normal call in the terminal (like I’m running it using lua script.lua. I am trying to figure out which global variables can be used in the script as a trial error but it does not seem to work like below:

if type(SURI_EVENT) == "table" then
  -- running within Suricata context
init() {
--
}

setup(){
--
}

log() {
--
}

denit() {
--
}

else
  -- not running within Suricata context
end

The variable type(SURI_EVENT) which I think might be the global variable from suricata always return nil. Is there a specific global variable or set of variables that can be used to identify if the script is being executed within the context of Suricata?

2

Anyone? Is it possible at all ? Not trying to ask how to implement this but is this possible and is there a global variable to handle this? For example if I manually run this code in the terminal lua script.lua:

if type(SURI_EVENT) == "table" then
  -- running within Suricata context
init() {
SCLogNotice("Suricata")
}

setup(){
--
}

log() {
--
}

denit() {
--
}

else
  print("hello")
end

It will output ‘hello’ as it did not run within Suricata context
But when suricata call this script (normally from /etc/suricata/lua-output/script.lua) it will output as ‘Suricata’ in the suricata.log and it will not print ‘hello’

That is what I’m trying to do but the above if statement will not run because SURI_EVENT is not the right variable to handle this.

3

Hi,

what version are you running and how do you run in with which config?

Keep in mind there are two ways to use lua in Suricata, one within signatures and one within the output.

4

I do not know much about Lua, but could you try to check if SCLogNotice function is defined when running ?

5

The problem is that when the Lua file is parsed first (at rule parse time), the Suricata-specific global functions (e.g. SCLogNotice) are not set yet (see DetectLuaSetupPrime()).

But, more subtly, one could use call stack depth to determine how the script is run. At least when compiling Suricata with LuaJIT on Debian and running the script alone with Lua 5.1.5, you can check for debug.getinfo(2) to be nil – if it is, the script is being executed to populate a Lua state from Suricata, if it is not nil then it is run from the Lua interpreter (which seems to add another call stack level)

Example:

$ cat ~/test.lua
if debug.getinfo(2) == nil then
    function init()
        return {}
    end
    function log()
        -- ....
    end
    print("in Suricata")
else
    print("not in Suricata")
end

$ lua ~/test.lua
not in Suricata

$ grep -B4 test.lua suricata.yaml
  - lua:
      enabled: yes
      #scripts-dir: /etc/suricata/lua-output/
      scripts:
         - /home/satta/test.lua

$ ./src/suricata -vvvv -c suricata.yaml -l /tmp -i lo 2&>1 | grep "in Suricata"
in Suricata

Note that this is a hack and will only work like that if the check is done outside of any function call in the Lua script.