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
though.
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
scripts.
.Seth
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@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
--
Seth Hall * Corelight, Inc * www.corelight.com
_______________________________________________
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
