This chapter is from the book
This chapter is from the book
This chapter is from the book
NFS Server
A Solaris OE system can be either an NFS server, NFS client, both, or neither. From a security perspective, the best option is to neither provide NFS services nor accept them from any other systems. To disable all client and server NFS daemons, the following startup scripts should be disabled on the system:
- /etc/rc2.d/S73nfs.client
- /etc/rc3.d/S15nfs.server
The Solaris OE uses a different set of startup files to enable NFS server or NFS client services.
Frequently, business requirements mandate the use of the NFS server. There are several different levels of security available in the NFS server itself. In addition, careful configuration can greatly improve security. Here is a quick overview:
Explicitly list hosts allowed access to NFS server directories. Do not open access to all systems.
Export only the lowest directory necessary.
Export read-only whenever possible.
Use strong authentication methods such as AUTH_DES or AUTH_KERB whenever possible.
The NFS server and the various mechanisms available to secure it encompass more material then can be discussed here.
Automount
The automount service manages automated NFS mounts. NFS clients may need to mount file systems from many different NFS servers. The automount service mounts file systems automatically when they are needed and unmounts them after a specific amount of idle time. A table used by this service defines the file system mount points, mount options, and the associated NFS servers. Also, in order to centralize the management of automount, the configuration tables can be stored in a name service such as NIS or NIS+. A kernel-level service (autofs) interacts with the system daemon (automountd) to manage file system mount and unmount requests. The primary automount configuration table is stored in the /etc/auto_master file.
With the Solaris OE version 2.6 release, the automount software has been, for the first time, placed in separate Solaris OE packages. By removing these packages, all automount functionality is removed from the system. The two packages that include all the automount functionality are SUNWatfsr and SUNWatfsu.
The file /etc/auto_master file determines the locations of all autofs mount points. By default, this file contains four entries:
# Master map for automounter # +auto_masternet -hosts -nosuid home auto_home xfn -xfn
Ideally, automountshould be disabled because, not only does it run as a privileged daemon, but it also uses NFS and RPC. The automount system can be disabled by renaming /etc/rc2.d/S74autofs.
There are situations where the automountservice is needed for its ability to mount and unmount file systems automatically. In particular, both NIS and NIS+ environments make extensive use of auto_homeand auto_mastermaps to mount user home directories. In these situations, the configuration of the auto_master map should be carefully constructed to be as restrictive and secure as possible. This can be done by using NFS mount options and Secure RPC.
Frequently, NFS servers allow any system to mount the filesystems they export. This incorrect and all-too-common practice allows attackers to mount filesystems that may contain sensitive information. If the attacker would like to modify the contents of a particular file, they need only change their user ID or UID to that of the interesting file and modify its contents. This attack, and many other NFS-based attacks, can be avoided through the use of appropriate NFS exports and Secure RPC.
sendmail Daemon
sendmail is used on a Solaris OE system to forward and receive mail from other systems. Centralized mail servers should be used to receive mail rather than local servers. The local systems should, however, be able to generate mail and forward it to other servers.
Ideally, a more secure Mail Transport Agent (MTA) should be used instead of the MTA bundled with the Solaris OE. The sendmaildaemon, bundled with the Solaris OE, has been subjected to numerous denial of service, buffer overflow, and misconfiguration attacks. Alternative MTAs have been developed with smaller and more robust code. These other MTAs are more security conscious and, if configured properly, compromise the security of the server less than sendmail. If sendmail must be used, then the following recommendations should be followed to secure it as much as possible.
Outgoing sendmail
The sendmail daemon is not needed for email delivery to other systems. All messages that can be immediately delivered, are. Messages that cannot be immediately delivered are queued for future delivery. The sendmail daemon, if running, retries these messages again. It is recommended, for Solaris OE versions 7 and earlier, that a cron job be used to start sendmail every hour to process these undelivered messages. The following cron entry starts sendmail every hour to flush the mail queue:
0 * * * * /usr/lib/sendmail -q
Solaris 8 OE provides a new, undocumented way to have sendmailhandle queued mail without using cron. A new default configuration file can be named /etc/ default/sendmail. In this file create the following line:
MODE=ÓÓ
By defining the MODE to be a null string, sendmail will only process the outgoing mail queue and not accept incoming connections.
An example replacement /etc/default/sendmail file is available from the Sun BluePrints Online Tools page at http://www.sun.com/blueprints/tools, which documents the other sendmail options added to Solaris 8 OE.
Disable sendmail Daemon
If no sendmail functionality is required, it can be disabled in Solaris 2.6 OE and earlier Solaris OE releases by renaming the /etc/rc2.d/S88sendmail script. Once this script is commented out, sendmail will not be started during system startup. On systems running Solaris OE version 7 or 8, it is possible to remove all components of sendmail by removing the SUNWsndmr and SUNWsndmu packages with pkgrm.
sendmail.cf Recommendations
There is a wide variety of sendmailversions in use, and there are differences in the associated sendmail.cf configuration files. Because of this, a sample sendmail.cffile is not included with this chapter. Please refer to recommendations made at Sendmail Consortium in the Sendmail O'Reilly books and through the SunSolve OnLineSM service.
Name Service Caching (nscd)
The name service cache daemon (nscd) provides caching for name service requests. It exists to provide a performance boost to pending requests and reduce name service network traffic. The nscd maintains cache entries for databases such as passwd, group, and hosts. It does not cache the shadow password file for security reasons. All name service requests made through system library calls are routed to nscd. With the addition of IPv6 and RBAC in Solaris 8 OE, the nscd caching capability has been expanded to address additional name service databases.
It is recommended that the configuration of nscd, through the /etc/nscd.conf file, be modified to cache as little data as possible. Disabling nscd entirely, by commenting out the /etc/rc2.d/S76nscd startup script, is not recommended because there may be unexpected results. Problems have been encountered when using name services such as NIS, NIS+, and even Netscape when nscd is not running.
Tuning nscd to an appropriate minimal level can address potential security issues while maintaining a robust system configuration. In particular, the configuration should be modified so that passwd, group, and Solaris 8 OE RBAC information is not cached. Depending on what parts of nscd are disabled, there may be a performance impact on systems that have many users. The nscd -g option can be used to view the current nscd configuration on a server and is a helpful resource when tuning nscd.
A sample configuration file for an /etc/nscd.confsupporting Solaris OE versions 2.6 and 7 with passwd and group caching disabled is as follows:
enable-cache passwd no enable-cache group no positive-time-to-live hosts 3600 negative-time-to-live hosts 5 suggested-size hosts 211 keep-hot-count hosts 20 old-data-ok hosts no check-files hosts yes
To disable caching of the RBAC attribute databases in the Solaris 8 OE, add the following lines to the /etc/nscd.conf file:
enable-cache exec_attr no enable-cache prof_attr no enable-cache user_attr no
Print Services
When a Solaris OE system is installed using the End User, Development, or Entire Distribution cluster, the line printing packages are installed. Both the client and server components for print services are enabled by default on these Solaris OE installations.
The in.lpddaemon is only necessary for systems that provide network print queue services. If the system does not participate in print spooling, comment the following line in the /etc/inetd.conf file to disable this service:
printer stream tcp nowait root /usr/lib/print/in.lpd in.lpd
Conversely, the /etc/rc2.d/S80lp script is required both for a server providing print services to other systems and a system that requires access to printers hosted by other systems. If this functionality is not required, the packages for lpshould be removed from the system, and the in.lpd entry should be removed from /etc/inetd.conf.
The three packages for lpare SUNWpsr, SUNWpsu, and SUNWlpmsg. If all lp-related functionality is to be removed, the Solstice™ Print Client should also be removed. The Solstice Print Client is contained in the SUNWpcr and SUNWpcu packages.
Solaris 8 OE adds the Solaris Print Manager (printmgr[1M]), which is a graphical printer management interface for managing both local and remote printers. The package SUNWppm should be removed if this functionality is not required.
IP Forwarding
During the startup phase of a Solaris OE system, the /etc/init.d/inetinit script evaluates the configuration of the system. It determines whether the system will be configured as a router and have ip_forwarding enabled between the different interfaces. For more information on the ip_forwarding function, refer to Chapter 2. Solaris 8 OE adds an ability to set ip_forwarding on a per-interface basis. This topic is discussed in Chapter 2.