Managing NFS and NIS, 2nd Edition - Mike Eisler [216]
# NFSwatch log file
# Packets from: all hosts
# Packets to: zeus
#
# begin
#
Date: Tue Aug 1 16:31:22 2000
Cycle Time: 5
Elapsed Time:
#
# total packets network to host dropped
#
Interval Packets: 2371 2371 0
Total Packets: 2371 2371 0
#
# packet counters int pct total
#
ND Read: 0 0% 0
ND Write: 0 0% 0
NFS Read: 166 7% 166
NFS Write: 346 15% 346
NFS Mount: 0 0% 0
YP/NIS/NIS+: 0 0% 0
RPC Authorization: 0 0% 0
Other RPC Packets: 1844 78% 1844
TCP Packets: 2 0% 2
UDP Packets: 2358 99% 2358
ICMP Packets: 1 0% 1
Routing Control: 2 0% 2
Address Resolution: 10 0% 10
Reverse Addr Resol: 0 0% 0
Ethernet/FDDI Bdcst: 13 1% 13
Other Packets: 0 0% 0
#
# nfs counters int pct total
#
/export/home: 512 100% 512 (0/0/5/0/12/0/154/0/
335/2/0/0/0/0/3/1/0/0)
#
# file counters int pct total
#
#
# nfs procs
#
Procedure int pct total completed ave.resp var.resp max.resp
CREATE 2 0% 2
GETATTR 0 0% 0
GETROOT 0 0% 0
LINK 0 0% 0
LOOKUP 12 2% 12
MKDIR 3 1% 3
NULLPROC 0 0% 0
READ 154 30% 154
READDIR 0 0% 0
READLINK 0 0% 0
REMOVE 0 0% 0
RENAME 0 0% 0
RMDIR 1 0% 1
SETATTR 5 1% 5
STATFS 0 0% 0
SYMLINK 0 0% 0
WCACHE 0 0% 0
WRITE 335 65% 335
The NFSWATCH log shows the distribution of NFS READ, NFS WRITE, NFS MOUNT, NIS, and RPC AUTHORIZATION packets among others. The NFS counters section indicates the total number NFS operations per filesystem exported (one in this case) during the interval. The operation distribution denoted by (0/0/5/0/12/0/154/0/335/2/0/0/0/0/3/1/0/0) indicates that the majority of the operations occurred in the middle of the interval. The packet counters and nfs procs indicate that there were close to twice as many writes as reads. The low lookup count leads us to believe that most writes occurred to the same file.
nfsbug
The nfsbug utility was written by Leendert van Doorn in the mid-1990s to test hosts for well-known NFS problems and bugs. nfsbug is available at http://www.cs.vu.nl/~leendert. Use it to identify (and consequently correct) the following problems:
Find worldwide exportable filesystems. This is a common occurrence in large organizations with hundreds or thousands of NFS clients. System administrators choose to export filesystems to all clients instead of grouping the hosts into netgroups and exporting the filesystems only to the netgroups that really need access to the filesystems.
Determine the effectiveness of the export list.
Determine if filesystems can be mounted through the portmapper.
Attempt to guess filehandles and obtain access to filesystems not exported to the test client.
Exercise the system for well-known bugs.[1]
SATAN
SATAN is a tool used to find well-known security holes in Unix systems. SATAN stands for Security Administrator's Tool for Analyzing Networks. At the time of this writing, none of the problems SATAN probes for are new. Each one has already been discussed in CERT bulletins and each can be countered either by installing the appropriate patch or fixing a system configuration flaw. SATAN is available at http://www.fish.com/satan.
SATAN was written by Dan Farmer and Wietse Venema and first released for general availability in April of 1995. The tool is intended to help system administrators identify several common network-related security problems, hopefully before someone else has a chance to exploit them. The tool provides a description of the problem, explains the consequences if no action is taken, and indicates how to correct the problem. Note that the tool itself will not exploit the security hole. At the time of this writing, SATAN can identify and fix the following problems related to NFS and NIS:
NFS filesystems exported to arbitrary hosts
NFS filesystems exported to unprivileged programs
NFS filesystems exported via the portmapper
NIS password file access from arbitrary hosts
An extensive discussion of SATAN and its features can be found in Martin Freiss' book titled Protecting Networks with SATAN