[Bro-Dev] UDP payload signatures

Robin Sommer robin at icir.org
Tue Jul 3 07:48:54 PDT 2012

On Mon, Jul 02, 2012 at 22:11 +0000, you wrote:

> payload and (2) the internals don't seem to support such an option
> that well because, internally, multiple patterns get compiled together
> into a DFA to check matching and the interface to it is geared towards
> checking if any pattern was matched, not checking if a given pattern
> didn't match.

That's indeed something hard to get around, and we wouldn't change
that. The performance savings would only kick in later (there's
potentially more logic that triggers upon a regexp match). However,
it's hard to say if that would change much, in particular with the 1K
buffer as you say.

So yes, assuming nobody is seeing signficant performance impact with
the recent changes (which I haven't in my tests on traces), we can
leave things as they are right now. As a test, we could create
something like a "worst-case trace" that only has traffic of the kind
relevent here and measure if the signature matching makes a noticable

> "Regular expressions are implicitly anchored, i.e., they work as if
> prefixed with the ^ operator. For reassembled TCP connections, they
> are anchored at the first byte of the payload stream. For all other
> connections, they are anchored at the first payload byte of each
> packet. To match at arbitrary positions, you can prefix the regular
> expression with .*, as done in the examples above."

This is indeed the intended behaviour.

> Changing the pattern to /YYYY/ or /^YYYY/ results in no match (but
> does match if I flip order of packets).  Is the bug in the docs or the
> code?

That looks like a bug in the code. Also reminds me that we should
really have unit tests for the signature engine ...


Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org
ICSI/LBNL    * Fax   +1 (510) 666-2956 *   www.icir.org

More information about the bro-dev mailing list