COMPUTER AND NETWORK
SYSTEM ADMINISTRATION
Summer 1996 - Lesson 26
System Security
Excellent resource: ORA's Practical UNIX & Internet Security.
A. Hodge-podge of security concerns
1. sendmail pre 8.6.10 (and possibly later)
- sendmail is always a problem
- should set up a mail server which is not trusted
by other machines and has no other services
- must keep current, subscribe to some advisory list
or constantly check CERT's web site.
2. rshd trusts the world
- phoney due to + in hosts.equiv and all
targets trusted mu
+@lpdaemon
+@lpdaemon2
+@majorslab
- netgroup should have fully qualified host names, though
3. no X server access control
When the X server permits access from arbitrary hosts on the
network, a remote intruder can connect to the X server and:
- Read the user's keyboard, including any passwords that the
user types,
- Read everything that is sent to the screen,
- Write arbitrary information to the screen,
- Start or terminate arbitrary applications,
- Take control of the user's session.
Fixes:
Remove all instances of the xhost + command from the system-wide
Xsession file, from user .xsession files, and from any application
programs or shell scripts that use the X window system.
Don't allow X traffic across your firewall.
Use "xauth" (~/.Xauthority), along with an authenticating
X server. Start up your X server with "-auth" option.
See "man Xsecurity" for more details.
4. rexd is vulnerable
- outdated, unused, and insecure
A request for remote command execution contains, among others,
the command to be executed, and a user and group id. By default,
the rexd server believes everything that the client sends it.
- turn off in inetd.conf
5. NFS is insecure
- exports to everyone
> whoops
- exports via portmapper
In order to perform operations via the NFS network file system
protocol, a client host sends NFS requests to the NFS server
daemon with:
+ an NFS file handle that specifies the target of the operation,
+ the operation (lookup, read, write, change permissions),
+ the user on whose behalf the request is sent.
When an NFS client host wants to access a remote file system for
the first time, it first needs to obtain an NFS file handle. To
this end, the client host sends an mount request to the server's
mount daemon. The server's mount daemon verifies that the client
host has permission to access the requested file system (via
exportfs).
When the mount daemon grants access, it sends a (directory) file
handle back to the NFS client.
For efficiency reasons, most NFS export restrictions are enforced
by the mount daemon. Individual file access operations are handled
by the NFS daemon, and the origin of such requests is examined
only in special cases such as remote superuser access.
Instead of talking directly to the mount daemon, a malicious NFS
client can ask the server's portmapper daemon to forward the
request to the mount daemon. When the mount daemon receives the
request from the portmapper, the mount daemon will believe that
the request comes from the file server, and not from the malicious
client.
When the file server exports file systems to itself (for example,
because the server is a netgroup member) the mount daemon grants
access and replies with a file handle. The portmapper forwards
the handle to the malicious client. From now on, the client can
talk directly to the server's NFS daemon to access the directory
and all files below it.
Fix: Run a portmapper (or rpcbind program in case of System V.4)
that does not forward mount etc. request.
Block 111 (portmap) on your routers.
- exports to unprivileged programs
NFS server executes requests from unprivileged user programs
(port numbers). A malicious user can execute NFS file access
requests on behalf of any user.
When an NFS client host wants to access a remote file or directory,
its operating system sends a request to the NFS server. The request
specifies, among others, a file identifier, the operation (read,
write, change permission, etc.), and the identity of the user on
whose behalf the operation is to be done.
By default, the user identity is specified with the UNIX numeric
user and group ids. With this scheme, also called AUTH_UNIX, the
server simply believes anything that the client sends it.
An NFS request is nothing but a network message. Any user can run a
program that generates arbitrary NFS requests. Such programs have
been available for several years, and writing them does not require
unusual programming skills.
When an NFS server accepts requests with AUTH_UNIX authentication
from unprivileged user programs, a malicious user can execute file
access requests on behalf of any user. Reason: with AUTH_UNIX
authentication, the user identity is nothing but a few user and
group ID numbers in a network message.
The fix is to avoid AUTH_UNIX authentication and to use something
that involves cryptography. For example, secure NFS with DES or
Kerberos credentials. Unfortunately, many NFS implementations
support AUTH_UNIX authentication only.
A partial, but more common, solution is to configure the NFS
server, and where possible, the mount daemon, to accept requests
only from privileged system programs (such as UNIX kernels), and to
reject NFS requests that are sent by unprivileged user programs.
SunOS 4 administrators modify /etc/rc.local
rpc.mountd (no -n option)
echo "nfs_portmon/W1" | adb -w /vmunix /dev/kmem
SunOS 5 administrators modify /etc/system
set nfs:nfs_portmon = 1
Note: rejecting NFS requests from unprivileged user programs
does not protect your servers against malicious superusers or
against malicious PC programs.
A second partial solution: block port 2049 (nfs)
B. Common sense rules
1. don't make yourself a target
> advertise or boast about your security system
> avoid tempting names
> sometimes can't avoid being a target (nu as primary
campus name server is on a lot of lists)
2. scan your own system
> if you don't have time to scan then give a student a DIS
> if you don't have time to fix everything at least you
know your weak areas
> set up logging (or better yet - monitors)
> have summaries e-mailed daily to you so it forces you to
look at system activity
3. guest accounts, group accounts
> don't have guest accounts with shell privileges
> sure targets for hackery
Apr 11 23:01:11 xi telnet: REPEATED LOGIN FAILURES ON ttypb
FROM pc14 BY guest
Apr 11 23:01:20 xi telnet: REPEATED LOGIN FAILURES ON ttypb
FROM pc14 BY guest
Apr 11 23:01:32 xi telnet: REPEATED LOGIN FAILURES ON ttypb
FROM pc14 BY gopher
4. passwd selection
> get the source code
> write your own passwd binary
> force reasonable choice to increase
search space
> test it with crack
> script to look for accounts with no passwords
awk -F: '{ if ($2 == "") print $0 }' /etc/passwd
sync::1:1::/:/bin/sync
+::0:0:::
> script to look for root accounts
awk -F: '{ if ($3 == 0) print $0 }' /etc/passwd
root:93KotM6tHbIkQ:0:1:Operator:/:/bin/csh
sysdiag:*:0:1:Old System Diagnostic:/usr/diag/sysdiag:/usr/diag/sysdiag/sysdiag
sundiag:*:0:1:System Diagnostic:/usr/diag/sundiag:/usr/diag/sundiag/sundiag
+::0:0:::
5. programming guides for setuid programs
- avoid setuid root
> can often use setuid to daemon, or setgid to a special
group
> see CS dept. printer access
-rwxr-s--x 1 root printers 815 Dec 23 16:46 /usr/local/bin/lpinfo
-rw-rw---- 1 daemon printers 15 Apr 7 15:22 zhao
> note use of setgid, others can't even read lpinfo
- don't use library routines that invoke a shell
(system(), popen())
- avoid execlp, execvp - these versions of exec() use search paths
- use absolute pathnames when possible
- routinely look for setuid root programs
find / -user root -perm -4000
> find can walk down the file hierarchy and cross file systems
> there are currently about 40 suid root programs in the Sun
distribution
> really need to run checksums on these (ala tripwire)
ncheck -s /dev/sd0g
> only work for a single file system
- another way is to mount user files systems with nosuid flag
> this not only disallows suid program execution but
sends syslog message
6. machine trust
- user .rhosts files
> scan for these
- hosts.equiv
the + scandal
- don't trust any machine for which you do not have exclusive
root access
- all trusting machines should use the same passwd map (or a
carefully controlled set of uids)
- use fully-qualified hostnames
7. Packages that help
COAST - Excellent web site at Purdue that is a repository
for security tools and documents
Gene Spafford's excellent hotlist
SATAN - runs outside your system, as a real hacker would
got much press, but more hype than real concern
interesting Web-based interface
ISS - Internet Security Scanner
COPS - Computer Oracle and Password System
C programs & shell scripts that test for security weaknesses
crack - tries to crack your passwd file
tripwire - keeps log of checksums of important files
so you can see if they have been modified
tcpd - the tcpwrapper
> on your Linux box