nfs analysis

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. :frowning: 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 http://lists.freebsd.org/pipermail/freebsd-bugs/2006-November/021159.html).
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