[Snort-devel] (no subject)

Peter Schmitz mosquitooth at ...224...
Wed Dec 27 05:45:25 EST 2006


Hi,

again, thanks for replying.
So, what it comes to would be this:

To do all the necessary payload checks, snort first initializes some pointers (base_ptr at the beginning of the payload, start_ptr at the beginning of the payload to search, end_ptr at the end of the payload/searchspace and doe_ptr). base_ptr and end_ptr shouldn't change when going through all the rules, but the other ones are resetted on every new rule that snort checks upon.
Now the search starts. If there is a byte_jump keyword, the doe_ptr is moved for some bytes (depending on payload) so that the next relative keyword would start the search at doe_ptr (in this case a byte_jump keyword that is NOT followed by any relative keyword - distance, R on pcre  etc. - would make no sense, is that correct?).

So basically, every time a content pattern (or any other payload option as there are pcre, isdataat, content, byte_test, byte_jump) matches on the payload, doe_ptr is moved to that location (+ the pattern length), just in case the next keyword would be relative and needed this as a starting place.

One last thing: What's the exact difference between doe_ptr and start_ptr?
Is start_ptr just a 'wrapper' for either the value of base_ptr (non- relative) or doe_ptr (relative)?

thanks - again - for any help,

Peter







-------- Original-Nachricht --------
Datum: Tue, 26 Dec 2006 20:39:04 -0500
Von: Steven Sturges <steve.sturges at ...402...>
An: Peter Schmitz <mosquitooth at ...224...>
Betreff: Re: [Snort-devel] (no subject)

> Hi Peter--
> 
> No, multiple contents are not relative to each other unless
> you specify a 'distance' (start x bytes from current
> position), 'within' (search no more than y bytes).  'offset' and
> 'depth' have similar meanings.
> 
> byte_test, byte_jump have a 'relative' option keyword, and PCRE
> has a 'R' modifier.
> 
> Order of rule options is only important for those that are relative
> to each other.
> 
> In your example, there is no difference... 1st line searches for
> "a", then, if found, start at the beginning and search for "b",
> and if found, start at the beginning and search for "c".  2nd one
> does the same for "b", then "a", then "c".
> 
> However, if you add 'distance:10' to the content:"c", the 1st
> would start looking for "c" 10 bytes after the first occurance
> of "b", while the 2nd would start looking for "c" 10 bytes after
> the first occurance of "a".
> 
> Cheers.
> -steve
> 
> Peter Schmitz wrote:
> > Thanks a lot for replying! This helped a lot!
> > 
> > One additional question: If there is a pointer like doe_ptr,
> > does that mean that e.g. several content keywords in a rule
> > are all 'relative' to each other? Does snort only look for
> > an additional content after the last matching pattern?
> > If so, is the order of all the keywords in one rule important? 
> > E.g. is content:"a";content:"b"; content:"c" different from
> >         content:"b";content:"a"; content:"c"?
> > To which keywords does this apply (pcre, byte_test, etc.)?
> > 
> > thanks a lot,
> > 
> > Peter 
> > -------- Original-Nachricht --------
> > Datum: Tue, 26 Dec 2006 13:43:35 -0500
> > Von: Steven Sturges <steve.sturges at ...402...>
> > An: Peter Schmitz <mosquitooth at ...224...>
> > Betreff: Re: [Snort-devel] (no subject)
> > 
> >> Hi Peter--
> >>
> >> Answers below... Hope this helps.
> >>
> >> Cheers.
> >> -steve
> >>
> >> Peter Schmitz wrote:
> >>> HI, 
> >>>
> >>> I'm currently struggeling through snort code and rules to fully
> >>> understand the system. When I came across the keyword byte_jump,
> >>> I - unfortunately - didn't understand something:
> >>>
> >>> In the latest snort documentation it says, that byte_jump would
> >>> set a doe_ptr to another destination (depending on the rule).
> >>> Now, what does this pointer really point to? Is this a position
> >>> in the payload? Does that mean, that if I jump some bytes all
> >>> later checking for content keywords will take place after the
> >>> destination doe_ptr now (after executing byte_jump) points to?
> >>>
> >>> If I - for example - would begin a rule like this: 
> >>>
> >>> byte_jump:4,36,align; 
> >>> content:"|00 00 00 01|"; offset:16; depth:4; 
> >>>
> >>> First, I'd jump some bytes (depending on the packet real payload)
> >>> - then I'd search for some specific content. If this content could
> >>> be found in the bytes I just skipped by byte_jump - will this
> >>> content be found?
> >> The interpretation of this is jump some bytes (depending on payload),
> >> then look for '00 00 00 01' 16  bytes from the result of the jump and
> >> only search the next 4 bytes.  So, this will only trigger if the
> >> content is found starting 16 bytes from where the byte jump 'landed'
> >> (the resulting doe_ptr).
> >>
> >> Think of the doe_ptr as a pointer to a place in the payload at the
> >> conclusion of each operation (be it byte jump, byte test, pcre,
> content,
> >> etc).
> >>
> >>> Another thing are the several pointers:
> >>>
> >>> What do base_ptr, doe_ptr, start_ptr, end_ptr really point to?
> >> Not looking at the code at the moment, but base_ptr is the start of
> >> the payload (usually).  start_ptr is a pointer to the beginning of
> >> the search space (after 'relative', 'offset', are taken into account.
> >> end_ptr is the end of the payload -- to prevent reading beyond the
> >> payload.
> >>
> >>> By the way, there are several keywords for the byte_jump keyword
> >>> itself, esp. from_beginning and relative...isn't this superficial?
> >>> Isn't relative == !from_beginning ?
> >> Good question... 'relative' means read the bytes to jump relative to
> the
> >> end of the last operation -- ie, use the doe_ptr to find how much to
> >> jump.  Then, jump from the end of those bytes.  DNS record parsing is a
> >> good example, where you'd want to skip the length of a given record.
> >>
> >> 'from_beginning' means jump from the start of payload.  The bytes that
> >> are read can still be relative to a earlier operation, but they are
> >> really an offset from the beginning of the payload, not from the
> >> current location -- this happens with DCE/RPC quite a bit.
> >>
> >> So, you could have both 'relative' and 'from_beginning' as options to
> >> the same byte_jump.
> >>
> >>> I know that some of my questions seem (and probably are) trivial, 
> >>> but I really want to understand and if someone could help me out
> >>> I'd be really grateful :)
> >>>
> >>> Thanks for any help on this matter, 
> >>>
> >>> Peter 
> >>>
> >>
> >>
> -------------------------------------------------------------------------
> >> Take Surveys. Earn Cash. Influence the Future of IT
> >> Join SourceForge.net's Techsay panel and you'll get the chance to share
> >> your
> >> opinions on IT & business topics through brief surveys - and earn cash
> >>
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> >> _______________________________________________
> >> Snort-devel mailing list
> >> Snort-devel at lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/snort-devel
> > 

-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer




More information about the Snort-devel mailing list