[Discussion] Text in Msgs

[Victor Julien]

Frank Knobbe wrote:
> On Mon, 2008-10-27 at 12:46 -0400, Matt Jonkman wrote:
>   
>> We are not talking snort. This is totally different.
>>     
>
> Okay, then I don't have objections :)
>
> While you are add it, here's a feature I meant to add to Snort years
> ago: The ability to copy matched text into a variable used for further
> matching.
>
> My idea to implement two new keywords, one to store data into a temp
> variable, and one to match the temp variable against data that was valid
> for the lifetime of the session (and only available for that session).
> Too bad I don't remember the actual use case for it.... but it should
> have looked something like this:
>
> content:"http\://"; store:7,2,' ',1;
>
> Different rule (in the same session) could then use:
> content:"blah"; match:12,1;
>
> Parameters for store:
> 1st: Offset from last match (content, isdataat, etc)
> 2nd: Type of end match: 1: 3rd param is length
>                         2: 3rd para is ending char match
> 3rd: End match: Either a length (copy 10 bytes) or an end match (in
> above example, a space)
> 4th: Number of session variable.
>
> Parameters for match:
> 1st: Offset from previous match.
> 2nd: Variable number to match.
>
> Above example would store the domain name after http:// (until reaching
> a space) in variable 1. The second rule using match would check if the
> data contained in variable 1 is present 12 bytes after blah.
>
>
> I think one of the reasons it never got implemented (besides there being
> workarounds for the specific issue in the past) was that it could easily
> bloat the memory of session streams since any data matching the first
> rule would alloc memory for the variable and tag it into the data
> associated with the stream. It only would be removed if the stream data
> is discarded. Considering there could be dozens/hundreds/thousand of
> matches on the first rule, it would mean dozen/hundreds/thousand times
> the length of the variable (plus some pointers) of memory overhead.
>
>
> Anyway, since you working on something new, perhaps implementing the
> ability to save data from sniffed traffic for later matching could be
>   
This is quite similar to the stuff I wrote about last week. I think it
can be very useful to do so. One other way to do so would be using pcre
substring capturing. I'd like to extend your idea to being able to do
the capture and matching per packet, flow/stream, host and globally. And
be able to compare captured data with each other... Memory will be an
issue, yes. But we'll see how efficient it can be done. Quality of
rules/sigs will be a big factor there as well...

Cheers,
Victor

> implemented more efficiently.
>
> Cheers,
> Frank
>
>
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Discussion mailing list
> Discussion at openinfosecfoundation.org
> http://lists.openinfosecfoundation.org/mailman/listinfo/discussion
>