[Bro-Dev] Bro DCE-RPC Analyzer Questions

Seth Hall seth at corelight.com
Wed Jan 31 08:05:23 PST 2018

The original idea was to get extensive parsing in place for DCE-RPC 
messages by parsing the IDL files for those services.  Someone in the 
community had hoped to take it on, but hasn't had time yet to complete 
it.  If you'd be interested in discussing that, I think that could be a 
huge addition to Bro (hundreds of new events!).

The At service parsing file is still there because I didn't want to lose 
track of it but I think there was some slight architectural change that 
needed to happen before I could pass data to it.  I don't think that 
data is even going to that parser, it's not just that there aren't 
events.  I'd have to refer back to the code to see what exactly is wrong 

As for an approach to this problem right now, I'd prefer to see parsing 
done in the core.  Architecturally we try to avoid passing unparsed data 
to Bro script land because of performance concerns and we generally 
don't have the intrinsic tools to be able to do parsing well in Bro 


On 25 Jan 2018, at 12:28, Fernandez, Mark I wrote:

> 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

> _______________________________________________
> bro-dev mailing list
> bro-dev at bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Seth Hall * Corelight, Inc * www.corelight.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20180131/d5b67355/attachment.html 

More information about the bro-dev mailing list