Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't trigger events in Bro_RPC.events.bif.bro #684

Closed
TheGodOfObelisk opened this issue Nov 12, 2019 · 5 comments · Fixed by #685
Closed

Can't trigger events in Bro_RPC.events.bif.bro #684

TheGodOfObelisk opened this issue Nov 12, 2019 · 5 comments · Fixed by #685
Assignees
Labels
Area: Protocol Analysis Type: Bug 🐛 Unexpected behavior or output.
Milestone

Comments

@TheGodOfObelisk
Copy link

Dear developers.
I am very sorry to disturb you. I use the old version of Zeek(Bro 2.x). And I use bro to analyze the data set LLDoS1.0(phase-2-dump), in which there are many RPC calls. But none of the events related to RPC are triggered.
Such as this:
event rpc_call(c: connection, xid: count, prog: count, ver: count, proc: count, call_len: count){ print "rpc_call!"; }
Are all of these RPC events implemented? Or there is something wrong with the codes? Thank you very much!

@TheGodOfObelisk TheGodOfObelisk changed the title Can't trigger events in Bro_RPC.events.bif.zeek Can't trigger events in Bro_RPC.events.bif.bro Nov 12, 2019
@jsiwek
Copy link
Contributor

jsiwek commented Nov 13, 2019

The RPC-based protocol analyzers (portmapper, nfs, mount) aren't enabled by default as mentioned in the docs for the events. You could enable, for example, the portmapper analyzer in a script like this (or use bro_init instead of zeek_init for older versions):

const pm_ports = { 111/udp };
redef likely_server_ports += { pm_ports };

event zeek_init()
	{
	Analyzer::register_for_ports(Analyzer::ANALYZER_PORTMAPPER, pm_ports);
	}

Others would need different port definitions to enable. But also looking at some of the pcaps you referenced and trying that, it seems like the RPC parser/analyzer is just not working correctly (at a glance the parsing logic in RPC_CallInfo::RPC_CallInfo() in RPC.cc seems to fail). Part of the reason these analyzer are disabled by default is they were never well-maintained or tested, but it may not be far of from getting it to work if you were interested in taking a look. Any bug fixes you figure out would be appreciated.

@jsiwek jsiwek added Area: Protocol Analysis Type: Bug 🐛 Unexpected behavior or output. labels Nov 13, 2019
@TheGodOfObelisk
Copy link
Author

TheGodOfObelisk commented Nov 13, 2019

The RPC-based protocol analyzers (portmapper, nfs, mount) aren't enabled by default as mentioned in the docs for the events. You could enable, for example, the portmapper analyzer in a script like this (or use bro_init instead of zeek_init for older versions):

const pm_ports = { 111/udp };
redef likely_server_ports += { pm_ports };

event zeek_init()
	{
	Analyzer::register_for_ports(Analyzer::ANALYZER_PORTMAPPER, pm_ports);
	}

Others would need different port definitions to enable. But also looking at some of the pcaps you referenced and trying that, it seems like the RPC parser/analyzer is just not working correctly (at a glance the parsing logic in RPC_CallInfo::RPC_CallInfo() in RPC.cc seems to fail). Part of the reason these analyzer are disabled by default is they were never well-maintained or tested, but it may not be far of from getting it to work if you were interested in taking a look. Any bug fixes you figure out would be appreciated.

Thank you for your suggestions! I tried the built-in analyzer called ANALYZER_CONTENTS_RPC and part of the code:

const pm_ports = { 111/udp };
redef likely_server_ports += {pm_ports};

event zeek_init(){
    # enable RPC-based protocol analyzers
    Analyzer::register_for_ports(Analyzer::ANALYZER_PORTMAPPER, pm_ports);
    Analyzer::enable_analyzer(Analyzer::ANALYZER_PORTMAPPER);
    # Analyzer::register_for_ports(Analyzer::ANALYZER_CONTENTS_RPC, pm_ports);
    Analyzer::enable_analyzer(Analyzer::ANALYZER_CONTENTS_RPC);
}

event rpc_call(c: connection, xid: count, prog: count, ver: count, proc: count, call_len: count){ 
    print "rpc_call!"; 
}

event rpc_reply(c: connection, xid: count, status: rpc_status, reply_len: count){
    print "rpc_reply!";
}

After executing the script, only the rpc_reply event was triggered.
I am sorry that I am not capable of fixing the bug in zeek's source code by myself. May I have some more hints? Thank you!

@TheGodOfObelisk
Copy link
Author

I saw these statements under RPC-based events' doc.

Zeek’s current default configuration does not activate the protocol analyzer that generates this event; the corresponding script has not yet been ported. To still enable this event, one needs to register a port for it or add a DPD payload signature.

Does adding a DPD payload work? If so, how can I add a DPD payload signature? I have loaded the scripts in path /share/zeek/policy/frameworks/dpd/.
Thank you.

jsiwek added a commit that referenced this issue Nov 13, 2019
The parsing logic that should be specific to the AUTH_UNIX credential
flavor was previously applied unconditionally to other flavors.
@jsiwek
Copy link
Contributor

jsiwek commented Nov 13, 2019

  • Adding a DPD signature won't change anything
  • The CONTENTS_RPC analyzer isn't meant to be added directly in user scripts, it's something that gets used internally only. The only available RPC-based analyzers are PORTMAPPER, NFS, and MOUNT. If you need other ones, then you may have to look into writing a plugin that does what you need.
  • The underlying bug your encountering I think should be fixed via Fix parsing of RPC calls with non-AUTH_UNIX flavors #685 if you want to give that branch a try.

@jsiwek jsiwek added this to the 3.1.0 milestone Nov 13, 2019
@jsiwek jsiwek self-assigned this Nov 13, 2019
@TheGodOfObelisk
Copy link
Author

Thanks!

0xxon added a commit that referenced this issue Nov 21, 2019
…ing'

* origin/topic/jsiwek/gh-684-fix-rpc-parsing:
  GH-684: Fix parsing of RPC calls with non-AUTH_UNIX flavors

Addresses GH-684
jsiwek added a commit that referenced this issue Nov 26, 2019
The parsing logic that should be specific to the AUTH_UNIX credential
flavor was previously applied unconditionally to other flavors.

(cherry picked from commit 37a478a)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: Protocol Analysis Type: Bug 🐛 Unexpected behavior or output.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants