Re: Intrusion Detection Evaluation Datasets

[Joel Esler <eslerj () gmail com>]

Would this be an appropriate use for byte_test or byte_jump?

J

On Mar 18, 2009, at 6:16 PM, Paul Schmehl wrote:

> --On Wednesday, March 18, 2009 21:21:47 +0100 Damiano Bolzoni <damiano.bolzoni () utwente nl 
> > wrote:
>
> > Ok, I will reply to both using this message.
> >
> > > On Mar 18, 2009, at 2:31 PM, Paul Schmehl wrote:
> > > > I don't know if any IDS could do this. You'd have to capture the  
> > > > value
> > > > of Content-Length, insert that value into a variable, then compare
> > > > that variable against the number of bytes of a single value, all  
> > > > while
> > > > examining the same packet.
> >
> > Ok...so, it's not easy to catch any attack variation right? :)
>
> Not in http traffic, no, but in application traffic, yes.  The  
> problem with http traffic is that it's essentially freeform.
>
> > Btw, Snort did detect one attack instance, because a signature for  
> > IIS has
> > something like 100 times the same byte value in it.
>
> Yes, but the problem you posed was one signature to detect all  
> instances. That's easy to do in application traffic but much harder  
> to do in web traffic.
>
> > The problem is not only in catching the content length and storing it
> > somewhere, for later comparison...it would be already difficult to  
> > detect
> > that the same byte value is repeated over and over (and everytime is
> > different). Why? Because Snort (and in general any other signature- 
> > based IDS)
> > use regular expressions...in a regular expression you can only  
> > state that an
> > expression must not occur at all, could occur, can occur once or  
> > more, or it
> > can occur a number of times (but you cannot say how many times  
> > exactly)
>
> Well, conceptually, a regex could have the construct of /<the byte  
> value detected>{<the Content-Length}/.  The problem is detecting  
> those values to get them in to the regex.
>
> If, for example, you knew ahead of time you wanted to detect 100 A's  
> in a packet, pcre:/A{100}/; would do that for you.  Not knowing  
> ahead of time, both values would have to be captured and used as  
> variables in the expression so; pcre:/byte-val{c-l-val}/;
>
> --
> Paul Schmehl, Senior Infosec Analyst
> As if it wasn't already obvious, my opinions
> are my own and not those of my employer.
> *******************************************
> Check the headers before clicking on Reply.

--
Joel Esler T: 302-223-5974 (-) Gtalk: jesler () sourcefire com
[m]