portmapper
variablesThe standard script provides the following redefinable variables:
rpc_programs : table[count] of string
[100002]
entry is mapped to "rstatd"
.
Default: a large list of RPC services.
NFS_services : set of string
Default: the services mountd, nfs, pcnfsd, nlockmgr, rquotad, status.
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.
RPC_okay : set[addr, addr, string]
[1.2.3.4, 5.6.7.8, "rstatd"]
means that host 5.6.7.8
is allowed to access the rstatd
service on host 1.2.3.4
.
Default: empty.
RPC_okay_nets : set[net]
Default: empty.
RPC_okay_services : set[string]
Note that, like for RPC_okay_nets
, the trust does not
extend beyond GETPORT, because it should be the only portmapper
operation routinely invoked.
Default: empty.
NFS_world_servers : set[addr]
Default: empty.
RPC_dump_okay : set[addr, addr]
Default: empty.
any_RPC_okay : set[addr, string]
sun-rpc.mcast.net
[NFS_world_servers, NFS_services], [sun-rpc.mcast.net, "ypserv"]
The first of these allows access to any NFS service of any of the
NFS_world_servers
, using Bro's cross-product initialization
feature (See Initializing Tables). The second allows ypserv
requests to the multicast address reserved for RPC multicasts.1
suppress_pm_log : table[addr, string] of bool
const
but is modified at run-time to add
to it any host that invokes the walld RPC service, so that
such access is only reported once for each host.
Default: empty, but dynamic as discussed above.
[1] I don't know how much this type of access is actually used in practice, but experience shows that requests for ypserv directed to that address pop up not infrequently.