Re: [NSE] rpc library; Portmapper program list stored in the

[David Fifield <david () bamsoftware com>]

On Fri, Apr 30, 2010 at 12:13:03PM +0200, Patrik Karlsson wrote:
> Hi Djalal,
>
> I tested the patch against a Linux server running NFS and it works great.
> My virtual OS X server behaves as badly as last time, so I don't think
> it makes a good reference.
> If someone else has the possibility to try this patch out against OS X
> please let us know.

I have tried it against OS X 10.6.3 with the result

PORT    STATE SERVICE REASON
111/tcp open  rpcbind syn-ack
| rpcinfo:
|   100000  2            111/tcp  rpcbind
|   100000  2            111/udp  rpcbind
|   100003  2,3         2049/tcp  nfs
|   100003  2,3         2049/udp  nfs
|   100005  1,3          688/udp  mountd
|   100005  1,3         1023/tcp  mountd
|   100011  1,2          960/udp  rquotad
|   100021  0,1,3,4      902/udp  nlockmgr
|   100021  0,1,3,4     1022/tcp  nlockmgr
|   100024  1            831/udp  status
|_  100024  1           1021/tcp  status
| nfs-showmount:
|_  /Users/david 192.168.0.0
| nfs-acls:
|   /Users/david
|_    ERROR: Mount: RPC call failed: remote can't authenticate caller.
| nfs-dirlist:
|   /Users/david
|_    ERROR: Mount: RPC call failed: remote can't authenticate caller.
| nfs-statfs:
|   /Users/david
|_    ERROR: Mount: RPC call failed: remote can't authenticate caller.

I don't know what I have to do to get the authentication to work.

The caching patch looks fine and you can commit it, but I don't see the
reason to add dependencies on rpcinfo. This will have no effect when
rpcinfo isn't run. Since it's a cache, it seems whoever gets the
information first should cache it, whether it's an rpc or an nfs script.

> So, a weak keyed table, suggested by Patrick, is probably the best bet.

It sounds like a good idea. Again, this is just a cache, an
optimization, so it's not the end of the world if a weak key is removed
from the cache and we have to re-send a probe.

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/