[Oisf-devel] lua (jit) script keyword

Martin Holste mcholste at gmail.com
Wed Sep 5 17:21:45 UTC 2012


I think there's a lot that can be done, and I like where Ignacio is
headed, but it's going to be tough to get very far until the HTTP data
is available, so I'm thinking that we can't do a whole lot with it
until then.

Here's a basic Lua question:  In this scenario, what kind of storage
does Lua have access while remaining fast?  Can it store info in
tables, and if so, are these available between threads?

On Wed, Sep 5, 2012 at 12:04 PM, Victor Julien <victor at inliniac.net> wrote:
> On 09/05/2012 06:55 PM, I. Sanchez wrote:
>> I think it is great addition and I would like to see it implemented for
>> HTTP streams.
>>
>> There are a thousand things you could do with lua scripting in suricata.
>> For example, if we had lua for HTTP streams, you could write a lua
>> script to implement some basic machine learning algorithm over the
>> useragents found in the HTTP requests (and some other http headers) to
>> detect malware C&C communications.
>>
>> Another possible use would be the creation of a lua script for the
>> monitoring of the parameters sent via GET or POST to your web
>> applications, with some machine learning to create a profile per
>> parameter and URL, so that it is able to understand that your id=xx
>> (?id=4, ?id=7, id=188) is always numeric, so it will trigger an alert if
>> somebody attempts id=1 and 1=0.
>>
>> You could do this for network security research or even as IDS/IPS for
>> production environments. Luajit was created with performance in mind, so
>> it should be fast enough to support such implementations.
>>
>> IMHO triggering a lua script per packet could be too excessive for
>> production environments, but triggering a lua script per HTTP
>> transaction (and in the future, per SMTP transaction) should be feasible.
>
> Thank Ignacio, this is exactly the type of innovative thinking we hope
> to trigger by adding such a feature. Now the big question is how to make
> it technically good enough to support use cases like what you describe
> above.
>
> So let's start testing :)
>
> --
> ---------------------------------------------
> Victor Julien
> http://www.inliniac.net/
> PGP: http://www.inliniac.net/victorjulien.asc
> ---------------------------------------------
>
> _______________________________________________
> Oisf-devel mailing list
> Oisf-devel at openinfosecfoundation.org
> https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-devel



More information about the Oisf-devel mailing list