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
On Apr 30, 2014, at 12:18 PM, Jim Mellander <jmellander(a)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
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).