Re: [Snort-users] threshold -- is it really deprecated?

[Joshua Kinard <kumba () gentoo org>]

On 01/23/2012 23:42, Jason Brvenik wrote:

> - the need for non-trivial parsing logic


Somewhat related, this could actually be handled better by Snort internally.
 I've run into a lot of duplicated parsing code scattered throughout the source.

For example, why is virtually the same parsing logic for ack, seq, sid, gid,
rev, priority, id, icmp_seq, icmp_id, count, and activated_by duplicated
within each keyword?  You're basically processing a simple numeric value in
all of those, with the only restriction really being the size of the numeric
value (and of that, mostly between signed/unsigned int16 and int32).

A centralized parser for just those options, with each option's *Parse()
function calling this central parser with the string to be parsed and the
valid numeric size, and getting a structure pointer passed back (probably
void *) with the parsed value would help to eliminate this duplicated code
and make maintenance easier, IMHO.

Other keywords that qualify for this are depth/offset/distance/within (which
already have the above, somewhat), and dsize/urilen/itype/icode, and at a
stretch, ttl (slightly different syntax).

I know C doesn't have the best support for string parsing in the world, but
I feel as-if the overall code size could be cut down a bit with something
like the above.


Although, I think this is largely just a result of new options being added
at random over time.  Like ttl and dsize.  They take basically the same kind
of syntax, but ttl uses a hyphen instead of '<>', and it supports <= and >=.
 whoever wrote ttl probably didn't think to look at dsize and borrow its
parsing logic.


> To sum it up. It needs to be well structured, easily parsed with
> existing tools, easily verified, signable, inheritable, overridable,
> understandable and usable by humans, editable with a simple text
> editor, automatable, encryptable, and facilitate sharing :)


Inheritable would be interesting.  That's almost like treating rules like
large C++-style objects (themselves being collections of smaller objects,
the rule keywords).  One actually finds that rules are "templatable" to a
certain extent.  Such as for a rule to alert on a DNS query that identifies
possible malware beaconing, that structure is very simple and largely
static.  You just simply drop in the domain to alert on, the message, a
SID/rev, and a few references, and that's it.

I could see a kind of "metarule" being created at a high level that defines
a common rule structure for a particular kind of network activity, and then
individual rules inherit the metarule and "fill in the blanks", so to speak.
 That way, you eliminate repetition of the common elements.


-- 
Joshua Kinard
Gentoo/MIPS
kumba () gentoo org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Attachment: signature.asc
Description: OpenPGP digital signature

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d

_______________________________________________
Snort-devel mailing list
Snort-devel () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-devel

Please visit http://blog.snort.org for the latest news about Snort!