[Bro-Dev] HTTP Sensitive POST bro policy

Jim Mellander jmellander at lbl.gov
Wed Apr 30 11:44:06 PDT 2014


Thanks for the input.

1. At some point in the past, ISTR bro did have a connection_end event - at
least thats what my failing memory tells me.  In any event, it seems like a
bug to not even give a warning if you have an event handler for a
non-existent event - a typo could cause difficult to detect errors.

2. Good catch, probably should have an expiration.

The minor inconsistency that I had in mind is the fact that the length of
the entity is checked whilst assembling the POST response without
unescaping, and checked unescaped in the http_end_entity..




On Wed, Apr 30, 2014 at 11:15 AM, Siwek, Jonathan Luke
<jsiwek at illinois.edu>wrote:

>
> On Apr 30, 2014, at 12:18 PM, Jim Mellander <jmellander at lbl.gov> wrote:
>
> > For a number of reasons, I elected to write the attached bro policy,
> which looks at http POSTs and performs regular expression matching on the
> posted data.
>
> Thanks for sharing.
>
> > Kudos to the first person who finds the minor inconsistency that I
> elected not to address.
>
> Maybe not what you were referring to, but I had two concerns:
>
> (1) “connection_end” doesn’t seem to be a defined event, maybe it's meant
> to be “connection_state_remove”.
>
> (2) Having the global “POST_entities” and “POST_requests” tables without
> &read_expire (or another expiry attribute) makes me nervous.  Though I
> think the clean up in “http_end_entity” should catch everything, if it
> doesn’t, that will lead to memory usage issues over time (especially since
> “connection_end” won’t be a cleanup safety net as intended).
>
> - Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20140430/591c452b/attachment.html 


More information about the bro-dev mailing list