Seth,
>> If you'd be interested in discussing that, I think that could be a huge >> addition to Bro (hundreds of new events!). Yes, I am interested in parsing IDL files, but I plan to do so very selectively. For example, for the At service, I don’t care about all four opnums it exposes... I just care about NetrJobAdd (which indeed is how you designed, too), and I want to log the command and the remote host to which the command was sent. Similarly, for the Server Service, I don’t care about all fifty opnums that it exposes... I just care about a handful of them, and I want to log key pieces of information associated with the function call. At this point, I have my eye on a few, maybe up to a dozen, specific RPC UUIDs. What is it you would be looking for? Would you want parsers for every opnum in the IDL file? Or just select functions? >> ...I'd prefer to see parsing done in the core. Architecturally we try to >> avoid passing unparsed data to Bro script land... Thank you. That is very important guidance, exactly what I was looking for. It gives me a definitive starting point. >> The At service parsing file is still there... but I think there was some >> slight >> architectural change that needed to happen before I could pass data to it. An architectural change? The sound of that makes me worry. I see a couple of approaches: 1. In ‘dce_rpc-analyzer.pac’ we could customize the function ‘process_dce_rpc_request’. We could have it lookup certain UUIDs, such as At-svc, and it if matches, then call InstantiateAnalyzer and DeliverStream, just like you do for RPC authentication with GSSAPI and NTLM. Pro: Could be implemented easily and quickly. Con: Need a new analyzer for each RPC UUID. 1. In ‘dce_rpc-protocol.pac’ we could customize the record ‘DCE_RPC_Request’ to change the ‘stub’ data element to be a big case statement switching on the UUID, akin to ‘SMB_PDU’ within the SMB analyzer, where the ‘message’ data element switches based on the SMB command. Pro: This is probably the preferred long-term solution. Con: It may be a little more challenging for me to code it correctly, take me a lot longer to implement. Am I close to the right answer for sending data to the at-svc parser? Thanks, Mark From: Seth Hall [mailto:s...@corelight.com] Sent: Wednesday, January 31, 2018 11:05 AM To: Fernandez, Mark I <mfernan...@mitre.org> Cc: bro-dev@bro.org Subject: Re: [Bro-Dev] Bro DCE-RPC Analyzer Questions 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: a. I could customize the DCE-RPC analyzer to pass the sub data for *ALL* ‘dce_rpc_request’ and ‘dce_rpc_response’ events; or b. I could customize the DCE-RPC analyzer to create new events specifically for the interfaces/methods (aka UUIDs/OpNums) that I care about. c. 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<mailto:bro-dev@bro.org> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev -- Seth Hall * Corelight, Inc * www.corelight.com<http://www.corelight.com>
_______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
