Snort table is nil error

TieT

Snort gives my the following errors …

snort[44920]: server /usr/pbi/snort-i386/etc/snort/appid//odp/lua/service_EIP.lua: error validating …/snort-i386/etc/snort/appid//odp/libs/DetectorCommon.lua:318: table index is nil

snort[67986]: AppInfo: AppId 4251 is UNKNOWN
snort[67986]: Invalid direct service AppId, 4251, for 0x29921150 0x35be6ac0
snort[67986]: AppInfo: AppId 4250 is UNKNOWN
snort[67986]: Invalid direct service AppId, 4250, for 0x29921150 0x35be6ac0

Doing a full update of the rule sets doesn't fix the problem.

bmeeks

@TieT:

Snort gives my the following errors …

snort[44920]: server /usr/pbi/snort-i386/etc/snort/appid//odp/lua/service_EIP.lua: error validating …/snort-i386/etc/snort/appid//odp/libs/DetectorCommon.lua:318: table index is nil

snort[67986]: AppInfo: AppId 4251 is UNKNOWN
snort[67986]: Invalid direct service AppId, 4251, for 0x29921150 0x35be6ac0
snort[67986]: AppInfo: AppId 4250 is UNKNOWN
snort[67986]: Invalid direct service AppId, 4250, for 0x29921150 0x35be6ac0

Doing a full update of the rule sets doesn't fix the problem.

That looks like some kind of error has been compiled into the Lua scripts for the AppID rules. It will be up to the Snort VRT guys to fix it. Check their mailing lists to see if anyone else is hitting this.

Bill

fsansfil

It comes from todays AppID update. Having same trouble.

http://blog.snort.org/

F.

bmeeks

@fsansfil:

It comes from todays AppID update. Having same trouble.

http://blog.snort.org/

F.

Thanks for the confirmation. The Snort VRT should get it ironed out assuming it has been reported to them.

Bill

TieT

thx guys,

I've reported the issue.

bmeeks

Here is the response from the Cisco/Snort guys on this error. Follow the link to a series of posts in the OpenAppID mailing list: http://sourceforge.net/p/snort/mailman/message/33504331/. They say it will be fixed in the next update of the OpenAppID detectors.

Bill

TieT

Still haven't heard anything..

Please fix/edit line 318 in DetectorCommon.lau

local function delFlowTracker(flowKey)
–print ("deleting flowkey " .. flowKey)
** gFlowTracker[flowKey] = nil**
end

TieT

Nervermind ..
I erased these lines

    --print ("deleting flowkey " .. flowKey)
    gFlowTracker[flowKey] = nil

Untill there is a fix I'm happy, the logs aren't flooded anymore ;)

bmeeks

The real problem is that their code is not first checking the value of the "flowKey" variable for null before trying to use it. I doubt they expect it to be null, but nonetheless prudent coding would be to check the value for null first and take appropriate action.

At any rate, the responsibility for the fix rests with the Snort OpenAppID team who produces the OpenAppID detector rules.

Bill

trvsecurity

My pfsense logs are filling up (about 20 per second) of the following errors.

snort[12893]: server /usr/pbi/snort-i386/etc/snort/appid/odp/lua/service_EIP.lua: invalid LUA …i/snort-i386/etc/snort/appid/odp/libs/DetectorCommon.lua:318: table index is nil

Is there any news on this? Anyone have a fix?

bmeeks

@trvsecurity:

My pfsense logs are filling up (about 20 per second) of the following errors.

snort[12893]: server /usr/pbi/snort-i386/etc/snort/appid/odp/lua/service_EIP.lua: invalid LUA …i/snort-i386/etc/snort/appid/odp/libs/DetectorCommon.lua:318: table index is nil

Is there any news on this? Anyone have a fix?

A temp fix is posted here: https://forum.pfsense.org/index.php?topic=89393.msg499494#msg499494. The problem is with the OpenAppID rule scripts and not something that can be fixed within the pfSense package.

Bill

trvsecurity

Sorry to be a pain, but where in the pfsense sirectory structure can I find that file so that I can edit it?

bmeeks

@trvsecurity:

Sorry to be a pain, but where in the pfsense sirectory structure can I find that file so that I can edit it?

It will be in /usr/pbi/snort-amd64/etc/snort/appid/odp/libs/DetectorCommon.lua. This is assuming you have a 64-bit install. If you are on 32-bit architecture, change the amd64 to i386 instead.

Remember that each time the auto-update process brings down a new version of OpenAppID rules, it will wipe that directory and reload it. So any edit to that file will be lost. On the other hand, maybe the VRT will actually fix the problem in the next update and hand editing won't be necessary.

Bill