Lua Parser for NTLM SSP
Parses the Type-3 message string of the NTLM authentication scheme for HTTP. The message is assumed to be in the HTTP header 'Proxy-Authorization'.
(c) 2013: Johannes Bader (baderj@gmx.net)
licensed under the terms of the LGPL2
uses adapted base64 snippets from
Lua 5.1+ base64 v3.0
(c) 2009 by Alex Kloss <alexthkloss@web.de>
licensed under the terms of the LGPL2
I am currently running Netwitness Decoder software version 9.8.5.5. I know that the lua parser is supported on this software release, but I do not see any documentation for creating lua parsers except for the few excerpts from the "RSA NWUC 2012 - We're Going to a Lua" pdf. Where is the documentation for the Netwitness Lua Parser Api?
I am currently running Netwitness Decoder software version 9.8.5.5. I know that the lua parser is supported on this software release, but I do not see any documentation for creating lua parsers except for the few excerpts from the "RSA NWUC 2012 - We're Going to a Lua" pdf. Where is the documentation for the Netwitness Lua Parser Api?
When I asked the support for an API-documentation, they referred me to the presentation. It seems like although LUA is officially supported, the API is not fixed yet. The LanguageKey syntax, for instance, is different than shown in the slides.
Here you can see the new syntax for working with language keys. I also listed some API function that are exposed:
How to Define Language Keys in Lua Parsers
In my limited experience - I only wrote three parsers in Lua so far - it's very easy to write parsers in Lua. If your parser need isn't to complex, feel free to post the idea and I might be able to help.
Understood. This is an emerging product so subject to some growing pains. The docs are getting better and so is the overall function of the system.
All in all the NextGen system has tremendous potential albeit with some rough areas around the edges.
Question, I understand the logic now of the LUA parsing engine; however, where do I place my LUA parsing code in order to activate it.
Thanks for your input very much appreciated!
Just put the Lua parser in the parser directory of the decoder like you would do for Flex parsers. The extension needs to be .lua. Then do a 'parsers reload' via console of the NW Administrator. Alternatively, you can upload the parser using the 'upload feeds and parsers' option under 'files' in the Admin tool.
Maybe you need to enable Lua parsing in the config options, as it is disabled by default.
Thanks. Great information again!
I posted this in another forum but...
For example, pulled the idea from "We're going to Lua"
local AlertParser = nwcreateParser("AlertParser", "Alert Callback Example")
function AlertParser:onAlert(metaId, Value) nw:logDebug("Found alert!") end
local callbacksTable = {
[nw:LanguageKey("alert")] = AlertParser.onAlert -- meta callback function
}
AlertParser:setCallbacks(callbacksTable)
Not sure exactly how to test this yet but I'm getting there. So, this stub is showing what I'm trying to do. Build a parser to process alerts as they come into SA 10.x.
Three small changes and the parser should be good to go.
on Feb 15, 2013local AlertParser = nwcreateParser("AlertParser", "Alert Callback Example")
you forgot the dot after nw
local AlertParser = nw.createParser("AlertParser", "Alert Callback Example")
local callbacksTable = {
[nw:LanguageKey("alert")] = AlertParser.onAlert -- meta callback function
}
the API changed here, rewrite as:
local callbacksTable = {
[nwlanguagekey.create("alert")] = AlertParser.onAlert -- meta callback function
}
And finally,
AlertParser:setCallbacks(callbacksTable)
won't work, you either need to use the colon operator
AlertParser:setCallbacks(callbacksTable)
or, if you don't like syntactic sugar, add the Parser as the first argument:
AlertParser.setCallbacks(AlertParser,callbacksTable)
Thanks a lot! I will give this a shot today.
Just FYI for anyone using this (I still have an old Flex parse NTLM one running) - we see a lot of "Proxy-Authorization: Negotiate" but also a bunch of "Proxy-Authorization: NTLM" if anyone finds they are missing stuff...
Johannes,
I have a question. I'm attempting to implement this under 9.8, but the check for apptype == 80 is failing for some reason, despite the fact that the traffic I'm examining is showing up in Investigator as HTTP. I tried changing this check to one for the target port (as follows) and this succeeded, and does return the correct account name for the proxy traffic.
local transport, srcport, dstport = nw.getTransport()
if dstport == <our proxy port #> then
Can you tell me why the check failed as originally written?
Thanks
John
Netwitness provides a built-in base64 Decoder that you can call with:
I probably could have used this function too.