[Oisf-users] Is there any possible Suricata could support OpenAppId?

Wed Oct 14 19:20:07 UTC 2015

Yes, maybe I'm old-fashioned by I still think things like BIND RPZ,
split-horizon DNS and a web proxy are a better way to implement access
controls, vs. attempting to inline stuff right off the wire.

Especially these days with virtualization and open-source software.  All
these technologies are easy and free.

> And this is why i'm wondering why they even introduced openappid
> instead of using the existent decoder etc.
> Since it's not that special or difficult (besides some edge cases
> maybe).

Well, they are building their technology on snort, not suricata.

I haven't been keeping up with snort development since I migrated to
suricata, but apparently Sourcefire is working on Snort++, which will
become snort 3.0:

http://blog.snort.org/2014/12/introducing-snort-30.html

(which sounds very much like Suricata 1.0 !)

Re: OpenAppId, its clearly to compete with PaloAlto while leveraging the
open-source model.  I.e., it's competing with PA's App-Id, not suricata
or emerging threats, for the next-gen firewall market.  As I've
mentioned before, suricata isn't designed to be a next-generation firewall.

As to why they are doing it entirely with lua I'm not sure.  I was going
to write that suricata only supported lua for only http, but apparently
they allow packet and payload processing as well...

> https://redmine.openinfosecfoundation.org/projects/suricata/wiki/Lua_scripting

However, it's limited to a single packet or packet payload vs. an entire
stream.  There are also a collection of lua scripts already available
for testing:

> https://github.com/EmergingThreats/et-luajit-scripts

> But still something that is technically possible with suricata (and
> others)?!

Any trivial signatures can already be done using the basic suricata rule
syntax and I suspect they will be much faster than using compiled lua
rules.  On a big network *performance matters* and I really appreciate
that the ET guys release signatures with that in mind.

Any non-trivial lua signatures that are targeting http traffic should be
able to be implemented in suricata using the existing lua support.

Any non-trivial lua signatures that operate on an entire non-http stream
won't be possible in suricata for now, but I'm not sure such a thing
would even be feasible on a big network given the limitations of modern
hardware; unless perhaps they are integrated with the protocol decoders
(like http currently is).

> So it looks more sane to write a converter then to implement the
> "decoding" part, i guess.

Well, here's the thing.  The existing suricata rule engine is based on
regular expressions, which in turn are based on finite-state machines.
So the way the pattern-matcher works is to compile rules together into a
single FSM and then attach these to the protocol decoder in an efficient
manner.  So for example, rules that reference the http_user_agent are
merged and matched against the User-Agent: header only.  This will
result in a performance improvement vs. matching against the whole header:

> http://blog.inliniac.net/2012/07/09/suricata-http_user_agent-vs-http_header/

- From a computer science perspective, this is the right way to do things
in order to get both high and predictable performance.

On the other hand, Lua is a general-purpose programming language which
can "do anything" and isn't limited to simple pattern matching.  For
example, the existing suricata sigs use it to do fancy stuff like
unpacking PDF and Flash files.

Anyways, I think I'm interested enough to try converting these rules to
the standard suricata keywords where possible.  I'll send and update
when I have one.

- -- 
Cooper Nelson
Network Security Analyst
UCSD ACT Security Team
cnelson at ucsd.edu x41042
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJWHqrnAAoJEKIFRYQsa8FW7pgH/jtgZ3MbEHEWJjOVSMOAA0AV
d0HYIAOxnkn03qhrgP6Aumr5B3UN317KBVRqLt9BYPKMw5HqIekk3jW9lcFu2AY6
ASLWSHLGh4QHSfELKTl/3c/zVmC6H1aTvkR5YIjR27f+nFTcWQtXtzcv9trXb+Dr
vJUnWarDzF9bgFAkTGhXLOLbq0igaOZEZXYg85K6Z4mtLCPfUJGfku0BUy3/oX0h
blCfgzAuF1niusgA/FVXL8O9tW8es8giwmJUXqy5z1zigoVz3fOYKXiynSwGC43p
3duxNYsYsdURztqSgVwBR4h78CKB3qUNhBij/vYXci2p9dunHuF+1+NQ/FPVtGI=
=Cjvi
-----END PGP SIGNATURE-----