Quick question: is the documentation regarding NFS on the Bro-wiki accurate?
"Deficiency: Bro's notion of NFS is currently confined to just
knowledge of the existence of these services. It does not analyze the
particulars of different NFS operations."
I am trying to extract some NFS file access events from a trace and
cannot seem to get the nfs_request_* nfs_attempt_* event handlers to
trigger. Should I be able to?
Thanks,
Mike
Hey Mike! I believe the documentation is once again misleading. 
Do
you get nothing at all when you load nfs.bro?
Cheers,
Christian
Sadly, yes I do not get any output from nfs.bro.
The tcpdump output for my trace looks like:
16:01:13.467628 IP client.host.name.4160508447 > server.host.name.nfs:
132 getattr [|nfs]
16:01:13.467879 IP server.host.name.nfs > client.host.name.4160508447:
reply ok 96 getattr DIR 40755 ids 10013/6007 sz 1024
16:01:13.467940 IP client.host.name.4177285663 > server.host.name.nfs:
148 lookup [|nfs]
16:01:13.468130 IP server.host.name.nfs > client.host.name.4177285663:
reply ok 128 lookup [|nfs]
...
So I would assume I have some valid NFS traffic there... but when I run
bro -r mytrace.pcap nfs.bro
I just get plenty of weird messages:
1190415715.190522 weird: bad_RPC
1190415715.190781 weird: unpaired_RPC_response
So, perhaps this is all the NFS traffic not getting recognized. Have
you seen this before?
I am running Bro 1.2.9... if that helps at all.
Thanks,
Mike
(I feel I won't be able to give the definitive answer to this one, so
others are very welcome to jump in.)
I wonder whether it could be that Bro doesn't read all of the traffic --
check whether the resulting filter looks decent by adding
print-filter.bro at the end of your invocation?
Also, I'm wondering how the source port can be 4160508447 in your
tcpdump!?
Cheers,
Christian
Hi Christian,
> Sadly, yes I do not get any output from nfs.bro.
>
> The tcpdump output for my trace looks like:
>
> 16:01:13.467628 IP client.host.name.4160508447 > server.host.name.nfs:
> 132 getattr [|nfs]Also, I'm wondering how the source port can be 4160508447 in your
tcpdump!?
Turns out this looks like a tcpdump bug that has an appropriate fix
(see bin/105334: Error in output of tcpdump).
So, I think my trace is actually fine.
I ran bro in gdb to trace out the execution. It seems the UDP.cc
analyzer gets called, but the analysis goes no further than that --
i.e. I get to UDP_Analyzer::DeliverPacket, but I never get to
RPC_UDP_Analyzer_binpac::DeliverPacket. I have tried running with the
--use-binpac option, but get the same result.
Any further ideas?
- Mike
Sorry for the delay on following up on this.
16:01:13.467628 IP client.host.name.4160508447 > server.host.name.nfs:
132 getattr [|nfs]
Whenever tcpdump displays "|xxx", it means that the packet was truncated
due to a snapshot limitation. Bro can't analyze such packets at the
application level. So you need to capture traffic using tcpdump -s 0 to
turn off the limited snapshot.
Note, the funky port number its showing is the NFS file handle (or maybe
it's the RPC transaction ID - I forget which) - a tcpdump feature. So
I'm not sure what to make about your later comment that this was a tcpdump
bug ...
1190415715.190522 weird: bad_RPC
1190415715.190781 weird: unpaired_RPC_response
These arise because Bro can't fully parse the RPC.
Vern