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: John Wilson (tugwilson.co.uk)
Date: Tue Mar 07 2000 - 05:00:49 CST

----- Original Message -----
From: Martin Roesch <roeschhiverworld.com>
To: <snortbofh.kyrnet.kg>
Sent: 06 March 2000 21:56
Subject: Re: [snort] Scripting Snort (sort of)

> 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...)

Yes, that's a good point - there's also the issue of file system footprint.
We really don't want to stop Snort running on things like Trinux.

> 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.

I think you'd pick it up pretty quickly. The day I posted the original
message I have never written a line of Pyhton. I now have a working parser
which will process the rules file from Max's site.
>
> 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)

Agree about nocase!!

I now have a Python program which tokenises and parses Snort rules. It lacks
include, it will eat but not inderstand preprocessor lines and the $(...)
stuff is not implemented. Error reporting is minimal. It will happily
process the vision.conf file.

It appears that another advantage of grafting Python onto Snort is that we
could nmake the plugins dynamically loadable. That is to say that you would
not have to recompile the program to add a new rule option or preprocessor
as the Python run time handles load on demand C modules.
>
> Maybe it could become the basis of something different yet similar?
> What does everyone else think?

I don't think that's a good idea. If the idea isn't strong enough to be
include in the main Snort project we should can it.

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