84-10-11 Solaris TCP/IP Network Security Features
Previous screen
Carol Siegel
Payoff
Reviewing system security for UNIX is a difficult task. However, the new technologies
have made this task simpler because of the development of new client/server technology
and open systems. SUN Microsystems' Solaris (based on SUN-OS Release 5 and AT&T
Corporation's AT&T System V Release IV) has become a dominant player in the UNIX
arena. This article, addresses some of the Solaris Transmission Control/Internet Protocol
(TCP/IP) networking security features.
Introduction
As the location of data and programs move from servers to clients(i.e., desktop
workstations and microcomputers), security exposures increase exponentially. One of the
biggest areas of concern is network security. Wide Area Network as well as local area
network interconnectivity in conjunction with client/server technology translates into
significant network traffic and services. This increased traffic along the wire places
significant importance on creating an industrywide standard for secure transmissions.
Cryptology and message authentication methodologies are tools that will help resolve this
issue. In addition, TCP/IP network services that are offered in conjunction with UNIX
operating systems need to be closely controlled. Some of these services send unencrypted
ID and password information across the wire, others list them in plain text in files, while
others permit user log-in by requiring password authentication. Clearly, the use of these
services should be carefully considered.
Networking Security Features
Remote access through the TCP/IP protocol suite is regulated by the following local files:
·
/etc/hosts. This file correlates host names with IP addresses.
·
/etc/services. This file correlates service name with port number and protocol.
·
/etc/hosts.equiv. This file lists serverwide trusted hosts and users. If one host trusts
another host, any user that has the same ID on both hosts can log in from the trusted
host to the other computer without typing a password. A + sign means that all users are
trusted.
·
$HOME/.rhosts. This file contains user-specified trusted hosts and users that may log in
asuser without a password. These files are located in user's home directories and can be
created by end-users. A + sign means that all users are trusted. As shown in Exhibit 1,
/etc/hosts.equivfile is overridden by the use of the.rhosts.
·
/etc/inetd.conf. This file, as shown in Exhibit 2, matches service names with server
programs to be executed.
Telnet provides remote virtual terminal service. Telnet permits any user on any host on
the network to access the local host if a valid user name and password is supplied. It
permits users to act as if they are logged in locally with full-access privileges.
$HOME/.rhosts and /etc/hosts.equiv
Previous screen
#Examples
#
denies access to all users on host
#-@group
denies access to all users on hosts in group
#-@group1+@group2
allows access to users in group2 on hosts
in group1
#host user
allows acces to user on host
#+user
allows access to user on any host
# host-user
denies access to user on host
#-host
denies access to all users on host
#-@group
denies access to all users in hosts in group
The /etc/inetd.conf Command
#ident
"@(#)inetd.conf 1.13
92/12/07 SMI/*SVr4.0 1.5/
#Configuration file for inedt (8). See inedt.conf(5).
#
#To reconfigure the runnint inetd process, edit this file, then
#send the inetd proces a SIGNUP.
#
#Syntax for socket-based Internet services:
#< service_name >< socket_type >< proto >< flags >< user >
< server_pathname >< args >
#Ftp and telnet are standard internet services
#
ftp
stream
tcp
nowait
root
/usr/sbin/in.ftpd
in.ftpd
telnet stream
tcp
nowait
root
/usr/sbin/in.telnetd in.telnetd
#
#Tnamed serves the obsolete IEN-116 name server protocol.
#
#
name
dgram
udp
wait
root
/usr/sbin/in.tnamed
in.tnamed
#
#Shell,log-in,exec,comsat,and talk are BSD protocols.
#
shell
stream
tcp
nowait
root /usr/sbin/in.rshd
in.rshd
log-in
stream
tcp
nowait
root /rsr/sbin/in.rlogind in.rlogind
exec
stream
tcp
nowait
root /usr/sbin/in.execd
in.rexecd
comsat
dgram
udp
wait
root /usr/sbin/in.comsat
in.comsat
talk
dgram
udp
wait
root /usr/sbin/in.talkd
in.talkd
Certain commands called the r-commands permit remote access in some cases that do not
require password authentication. These commands are:
·
rlogin permits a user to log in to a remote machine.
·
rsh permits a user to spawn a shell on a remote machine.
·
rcp permits remote copying.
Exhibit 3 presents an example of the authentication process for rlogin, rsh, and rcp. Some
of the access paths for user A do not require passwords:
·
Previous screen
·
Path 1. When executing rlogin, rsh, or rcp, if the user is not root, and if user A from
host * is listed in the local password file, and host * is listed in the localhosts.equiv file,
access is allowed without a password.
Path 2. Similarly, if user A is listed in the local password file, but not in the local
host.equiv file, but the user A and host * combination is listed in user A's local .rhosts file,
no password is required.
In search order, first the hosts.equiv file is searched and then the .rhosts file. Therefore, if
end-users have created their own .rhosts files, they have control over certain remote access.
Remote Network Authentication
Remote Execution
Security considerations for remote execution are:
·
Network services that are determined to be unsafe(depending on the security policy of
the environment) should be disabled by removing or commenting out their entry in
the/etc/inetd.conf or the/etc/services file.
·
$HOME/.rhosts files in general are considered to be unsafe, and should not be permitted.
·
A + sign in the/etc/host.equiv file or any$HOME/.rhosts file means all known hosts(those
listed in /etc/hosts) are trusted. No+ signs should be found in these files.
·
$HOME/.rhosts files override entries in the /etc/host.equiv file and can be used as a
backdoor. As they are controlled by end users, they are difficult to prevent. Daily
system sweeps of end user's home directories are suggested.
File Transfer Services
The File Transfer Protocol (ftp) files to and from a remote network. It allows a remote
user to log into a remote system with valid account and password information on the local
system. After logging in, the user can get files, change directories, list directories, make
directories, and remove files or directories. A file called /$HOME/.netrc can be created by any
end user. The .netrc file contains valid host, user ID, and password information in clear
text. This file permits those users specified to use ftp commands without manual password
verification.
The trivial ftp, used primarily for booting diskless workstations, permits the copying of
world-readable files without logging in, thus not requiring adequate identification and
authentication.
Security Considerations for File Transfer
The following is a list of security considerations for file transfer:
·
The /etc/ftpusers contains a list of users that cannot access the system using ftp.If this file
is missing, any user may use ftp to access the system.
·
Because the $HOME/.netrcfile contains unencrypted password information, it is a serious
security exposure and should not be permitted. The system should be swept daily for
the existence of these files.
·
If the need exists for a$HOME/.netrc file, it should be read and write for the owner of the
file only. In addition, the remote target system should only allow ftp and no interactive
session (e.g., telnet orrlogin).
·
The ftpusers file should contain all /etc/passwd users, except those authorized to use ftp;
this file should be monitored regularly.
·
The ftp service should not be available unless expressly needed and should be
commented out in theinetd.conf or /etc/servicesfile.
Previous screen
X-Windowing Services
X is a popular network-based window system that allows many programs to share a
single graphical display. X-based programs display their output in windows, which can be
either on the same computer on which the program is running or on any other computer on
the network. Exhibit 4 shows the * server that controls a graphical screen allowing * clients
to display windows on it.
X-Windowing
Access to xhost is controlled through the use of access control lists (ACLs) that display
the remote hosts that have permission to display their windows on local workstations. The
use of these Audit Command Language must be monitored. By issuing the command
xhost+, an ACLs is created that permits any server to display on that client. If this command
is not used, specific servers must be listed.
A good X programmer can place a full screen window over the server's graphical
device that is not detectable to the end-user. In this fashion, the programmer can potentially
spoof production clients by displaying sign-on windows (or other data-gathering windows
such as trade input).
The xhost utility also has implications with respect to the physical and logical separation
of product life-cycle environments. Development areas must be separated from UserAcceptance Test areas and from production areas. If access to a development or useracceptance test (UAT) area is permitted from a production box by the use of thexhost utility,
certain risks are present. For example, a trader who might be performing a test of a
program or tool to analyze market data could display the resultant data on the production
workstation screen. By doing this, the risk exists that any trader, for example, will mistake
this data for true production data and base a decision on the erroneous data displayed.
The Network File System
The Network File System facility is designed to promote resource sharing by making
information located on a particular server available to multiple clients in a multivendor
networking environment. A processor can export file systems to, or import file systems
from, other processors running network file system (NFS). The directories that may be
exported and the permissions or restrictions associated with them are listed in the server's
/etc/dfs/dfstab file. Access can be restricted by host system name. The client system must
mount the exported directory into its local file system before it can use it. This service can
be used so that file systems are shared, eliminating the need to have them copied multiple
Previous screen
times. Exhibit 5 shows the directory /tools on the server is mounted at /usr on the client in a
virtual manner.
Network File System
The network file system (NFS) uses the authentication flavors supported by the
underlyingRemote Procedure Call layer. Sun remote procedure call (RPC) supports these
multiple authentication flavors:
·
AUTH_NONE. This is used by applications that have no authentication requirement. The
network file system (NFS) facility does not use this feature.
·
AUTH_SYS. This is the default for the network file system (NFS). The caller's
identification is included but not verified. Because this is not secured, most network file
system (NFS) implementations accept these credentials only if the client's network
address appears in a list of trusted hosts.
·
AUTH_DES. The caller's identification includes a Data Encryption Standard-encrypted
verifier. The DES key is exchanged through the Diffie-Hellman public key encryption.
The public keys for the client and server are obtained from a secure name service.
·
AUTH_KERB. LikeAUTH_DES, the caller's identification includes a DES-encrypted
verifier. The DES key is exchanged via the Kerberos private key encryption.
Security considerations for the network file system (NFS) faciltiy include:
·
The secure option on entries in the/etc/dfs/dfstab file should be used. This option requires
clients to use a more secure protocol (e.g., AUTH_DES). AUTH_UNIX is the default
authentication This feature is Solaris-specific.
·
The anon=-1 should be set. The anon option sets the user ID (UID) to be the effective
user ID of unauthenticated users, or to be the superuser ifAUTH_UNIX authentication is
used when accessing the directory. By setting anon=-1, root(UID=0) (i.e., superuser)
access is prohibited. The anon=0 entries should be avoided, which allow all remote hosts
local superuser access. An example of a secure entry would be: share -F nfs -o
rw=netgroup,secure,anon=-1 /export/home2 This feature is Solaris-specific.
·
It should be stated that the exported directory is read-only (ro). The default is read and
write(rw). In general, permissions to exported directories should be carefully assigned
to avoid possible worms.
·
All root=hostname options that allow remote host superuser access, which is Solarisspecific, should be avoided.
Network Information Services
Network information services (formerly known as Yellow Pages) is a distributed data
base that stores information that users, workstations, and applications must have to
communicate across the network. Without a Network Information Service, each
workstation would have to maintain its own copy of this information, most likely leading to
an inconsistent configuration throughout the network. The benefit is that users do not have
to remember different passwords for all the systems they need to log in to. The benefit to
Previous screen
the system administrator is that it has to maintain only one set of network control files
called maps (NIS) or tables (NIS+) for a group of systems. For an NIS+ environment, the
system provided tables are hosts, bootparams, passwd, cred, group,netgroups, mail aliases,networks,
netmasks,ethers, services,protocols, rpc,auto_home, and auto_master. Exhibit 6 illustrates how
the/etc/hosts file on the server is shared by multiple clients.
Workstation Request Map Information
A NIS+ namespace, as shown in Exhibit 7, is the arrangement of information stored by
NIS+. The namespace can be arranged to fit the functional and geographical needs of the
organization. An NIS+ domain consists of a directory object, itsorg_dir directory,
itsgroups_dir directory, and a set of NIS+ tables.
NIS+ Domain
Two types of servers support an NIS+ domain: a master and its replicas. The master
server of the root domain is called the root master server. A namespace has only one root
master server.
When a client sends a request to a server, it automatically includes the credentials of the
NIS+ principal making the request. (A principal can be either a client user or the client
workstation.) An NIS+ credential, as shown in Exhibit 8, is the authentication information
about an NIS+ principal that the client software sends along with each request. The
credential can be either LOCAL orDES.
Client Requests
Exhibit 9 shows that NIS+ has three security levels association with its implementation.
The access rights of an object, such as an NIS+ table, are stored as part of the object's
definition. They are displayed by the nisls -l org_dir command. They are displayed as a list of
16characters. Their breakdown is shown in Exhibit 10.The default owner of the object is
the NIS+ principal that created the object. The r stands for read, m represents modify, d
represents destroy, c represents create, and -represents no access rights.
NIS+ Security Levels
Previous screen
Level
-----
Description
-----------
0
Credentials are not examined. All requests are to be
unauthenticated and are placed in the Nobody category.
1
Credentials are examined; LOCAL or DES accepted.
However, requests that supply valid LOCAL credentials
are authenticated. Requests that supply invalid LOCAL
credentials or do not supply any at all are considered
unauthenticated and placed in Nobody.
2
This level looks for DES credentials. A request with valid
DES credentials is authenticated. Requests that supply
LOCAL credentials or none at all are considered
unauthenticated and placed in Nobody. Requests that supply
invalid DES credentials are denied.
NIS+ Access Rights
rmcd rmcd rmcd rmcd
: : : : : : : :
Nobody Owner Group World
Security considerations for NIS+ include:
·
Some well-publicized security holes within Network Information Service have existed,
as well as many Computer Emergency Response Team advisories about vulnerabilities
within the product itself. Probably, organizations should not use network information
service. However, NIS+ has fixed many of these holes, and it can be installed with
confidence. This feature is Solaris-specific.
·
In an network information service environment an intruder can useypcat to identify all
user names managed by thenetwork information service server. Once users have these,
they have obtained sensitive information, and can, for example, begin using cracking
programs on the password file. To avoid this situation, ypcat permissions should be changed
to prevent normal users from listing NIS-maintained information.
·
In an NIS+ environment, LOCALcredentials are easily forged. Therefore, Security
Level 1 should not be used; only Security Level 2 should be used. This feature is
Solaris-specific.
·
In an NIS+ environment, it should be ensured that the tables are protected properly.
The nis_grouptable should have this permission:——rmcdr—-r—-. This feature is Solarisspecific. The nis_passwd table should have this permission:——rmcdrmcdr—-. All the other
tables should have this protection:r—-rmcdrmcdr—-.
·
/usr/sbin/nislog displays the contents of the NIS+ server transaction log. This command
can be used to track changes in the namespace. The/var/nis/hostname.log file contains the
transaction log maintained by the NIS+ server. This feature is Solaris-specific.
Conclusion
In monitoring the system, it is essential that the data security administrator or manager
perform specific daily and weekly tasks. For a data security administrator to monitor a
Previous screen
system properly, it is recommend that certain files be looked at on a consistent
basis. Exhibit 11 suggests how often these files should be monitored or commands
executed. All files or commands have been explained in this article, excluding fopwck
andgrpck. The pwck command scans the password file and notes any inconsistencies. The
checks include validation of the number of fields, log-in name, user ID, group ID, and
whether there is a log-in directory and the program to use as a shell. The grpck command
verifies all entries in the group file. This verification includes a check of the number of
fields, group name, group ID, whether any log-in names belong to more than
NGROUPS_MAX groups and that all log-in names appear in the password file.
System Monitoring Table
Audit Logs
/var/adm/sulog*
last I more
nislog*
pwck
grpck
*(Solaris-specific)
Daily
x
x
x
x
Weekly
x
x
Author Biographies
Carol Siegel
Carol Siegel is director of information security for Chemical Bank Global Bank
information risk management in New York.