OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: [snort] Scripting Snort (sort of)
From: Martin Roesch (roeschhiverworld.com)
Date: Mon Mar 06 2000 - 15:56:39 CST

Woah. This is an interesting idea, certainly not out of the realm of
possibility. My major concerns with it would be:

a) Complexity. Now people have to have Python, libpcap, gcc, etc
installed on their machine. I know that if people have the other
things, installing Python shouldn't be a big issue, but it's one more
thing to worry about (and a lot of other apps use the other pieces as
well...)

b) Cluelessness. I'd like to learn Python, but I don't know it right
now. I do know C pretty well, so I'm able to develop things on my own
most of the time. If we did a major chunk of the system in Python, I
could become rather ineffective as a maintainer of some largish
sections. I'm not sure that that would be a good thing.

Other than that, I certainly wouldn't mind seeing what you can come up
with! (Right now I'd like to know what's happening with the nocase rule
more, though)

Maybe it could become the basis of something different yet similar?
What does everyone else think?

     -Marty

John Wilson wrote:
>
> I'd like to toss an idea into the list for general discussion:
>
> It appears to me that there might be a benefit in enclosing the Snort
> detection engine in a Python wrapper.
>
> I am *not* suggesting that the detection engine should be rewritten in
> Python! Rather I think that there might be benefits in the initialisation
> code, the rule parser and (perhaps) the alerting framework be rewritten in
> Python.
>
> The idea is that the wrapper does all the nasty work in reading the
> parameters, the rules file and builds the rule tree. It then sets the
> existing detection engine running (probably in a separate thread). It would
> seem to me to be possible to use a second Python thread to handle alerts
> generated by the detection engine (possibly using C code wrapped in Python
> if there's a performance issue with this).
>
> This approach might allow is to introduce some gentle multi threading into
> Snort without us having to get too deeply enmeshed in the characteristics of
> platform specific thread behaviour (the Python people have done that work).
> Python also seem to be better suited to doing the rule file munging stuff (I
> have about 60% of a Snort rule file parser written in Python - it looks
> pretty good so far.
>
> I know that Python is not to everybody's taste (it's not my first choice but
> Java doesn't really have good enough support on enough platforms of
> interest) but it does seem to be pretty ubiquitous and I think it will do
> the job.
>
> I'm very interested in people's reaction to this. If there's a general
> feeling that it might be worth a try I'd be happy to have a go a doing a
> rough and ready prototype over the next few weeks.
>
> John Wilson
> The Wilson Partnership
> 5 Market Hill, Whitchurch, Aylesbury, Bucks HP22 4JB, UK
> +44 1296 641072, +44 976 611010(mobile), +44 1296 641874(fax)
> Mailto: tugwilson.co.uk 

-- 
Martin Roesch                      <roeschhiverworld.com>
Director of Forensic Systems     http://www.hiverworld.com
Hiverworld, Inc.               Enterprise Network Security
Network Forensics, Intrusion Detection and Risk Assessment