[Bro-Dev] Bro DCE-RPC Analyzer Questions

[Fernandez, Mark I]

Bro-Dev Group,

I am doing a little research into using Bro to log and analyze specific Microsoft DCE-RPC interfaces and methods.  I notice that the Bro events for 'dce_rpc_request' and 'dce_rpc_response' provide the length of the RCP data stub (aka 'stub_len').  I found reference that these events previously provided a byte string containing the stub data itself, but at some point it was reduced to just the stub_len instead.  I have a few questions that I hope you could answer:


  1.  What was the reason you decided to remove the stub data from the events and pass only the stub length?



  1.  On github, I see a BinPAC file for the RPC 'At' service (bro/src/analyzerprotocol/dce-rpc/endpoint-atsvc.pac), but there are no events generated by it.  I think this would be very useful for my project.  What is the reason that you have the analyzer, but no events for scriptland?



  1.  I have a use case, for a very few, limited number of RPC interfaces/methods, where I need to receive the stub data in scriptland for logging and analysis.  How do you recommend I approach this scenario?  I see a couple options:

  1.  I could customize the DCE-RPC analyzer to pass the sub data for *ALL* 'dce_rpc_request' and 'dce_rpc_response' events; or
  2.  I could customize the DCE-RPC analyzer to create new events specifically for the interfaces/methods (aka UUIDs/OpNums) that I care about.
  3.  Other ideas?

I think both (a) and (b) will achieve the desired result; but there are trade-offs, pros and cons.  I wonder which option would have a more negative impact on Bro performance? I imagine the reason you stopped passing stub data for all events was due to the performance hit, so I want to approach this in the best way possible.  I appreciate your feedback.

Cheers!
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20180125/d05eb044/attachment.html