[Snort-users] dr's futuresnort wish list

Dragos Ruiu dr at ...50...
Sat Aug 19 01:40:02 EDT 2000


In order of importance IMHO:

-a way to extract non-word aligned IP source addresses from packets on Solaris
 without dumping core for the defragger.
-tcp session reassembly and feedback into main rule set 
-run-time, dynamically loadable plug-ins and preprocessors a la apache 
-mutliple addresses in all address along with negation (everything except these addresses)   
-snortnet 
-snortdog

And the real reason why I sent this e-mail.... because I have a good idea
for a new feature set:

-Registers, global persistent ones, and packet specific ones that are reset for
 every packet.  Registers can be set to a value by a rule (to a value specified
 in the rule) 
-Conditional rules, that are only evaluated when a register is a certain value. 

The above system would let you.... for example:
-Set a packet specific variable whenever you see the FTP protocol file GET request.  
-Set special content filters rules following that rule that search for sensitive filenames

Specifically I propose we implement a two banks of numeric
registers/flags/variables (one static [r1-rn], and one per packet [p1-pn] 
which is reset to zero/null with each new packet) and a rule-candy for the 
parser that lets you define symbolic names for the numeric register values
and their contents. I.e.

define FTPCOMMAND 	p1
define GET		1
define PUT		2

and two new keywords, set, and if, the format being:

set [register]=[value]
if [register]=[value]

I.e.

alert tcp any any -> any 21 (content:"GET"; set FTPCOMMAND = GET)
alert tcp any any -> any 21 (content:"PUT"; set FTPCOMMAND = PUT)
alert tcp any any -> any any (if FTPCOMMAND = GET; content:"passwd"; msg:"Password File FTP Transfer GET passwd") 
alert tcp any any -> any any (if FTPCOMMAND = GET; content:"shadow"; msg:"Password File FTP Transfer GET shadow")
alert tcp any any -> any any (if FTPCOMMAND = GET; content:"pwd.db"; msg:"Password File FTP Transfer GET pwd.db") 
alert tcp any any -> any any (if FTPCOMMAND = PUT; content:"passwd"; msg:"Password File FTP Transfer PUT passwd")   
alert tcp any any -> any any (if FTPCOMMAND = PUT; content:"shadow"; msg:"Password File FTP Transfer PUT shadow")   
alert tcp any any -> any any (if FTPCOMMAND = PUT; content:"pwd.db"; msg:"Password File FTP Transfer PUT pwd.db")

Later on you could get fancy and provide other if operators such as
!=, <, >,  and maybe even math expressions for if but that = should do for now.
This sustantially increases the analysis power of snort but has a flipside of
giving the user more rope to write massive rulesets that will choke processors
and cause packet loss in congestion. :-) But on the bright side it doesn't have
the learning curve of n-code, while providing most of the functionality that is
really needed for most sophisticated analysis.

And thus snort becomes stateful, if you want. The above is how I would
like it implemented, but I thought I should solicit some comments before
researching implementation.  I really like this system though, because 
it tremendously expands the power of the ruleset while not imposing
major learning curves or huge rule parsers, or most importantly, large
CPU processing requirements.  I've been thinking about the latter
and I think this system will let us build protocol parsing and other
stateful conditional rules while still staying true to the goal of low
CPU processing and rapid speed.  Implementation wise... each register
could have a chain of rules that are completely ignored by the
processing loop until that value in the register is set. (rather than
checking the register for each rule and processing the conditionals
rules all the time for each packet).

Later you could get fancy and allow registers to be loaded with values
or alphanumeric strings from specific locations in the packet itself and allow
register values to be printed in alert messages (I.e. store any HTTP urls
detected in a register, and print the offending url in any CGI alert message,
by including that register). The other add on I would put in later is
a "log" keyword that could be used in conjunction with conditional rules
(and TCP reassembly) to log to a file packets from sessions that have triggered
an alert.

I think it seems like the elegant solution for conditional rules and state
variables.... does anyone else have any opinions on this? Particularly those
of you that write a lot of rules.

cheers,
--dr


-- 
dursec.com ltd. / kyx.net - we're from the future
pgp fingerprint: 18C7 E37C 2F94 E251 F18E  B7DC 2B71 A73E D2E8 A56D 
pgp key: http://www.dursec.com/drkey.asc




More information about the Snort-users mailing list