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 <[email protected]>wrote: > > On Apr 30, 2014, at 12:18 PM, Jim Mellander <[email protected]> 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
_______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
