Solaris Operating Environment Security: Updated for Solaris 9 Operating Environment

Like this article? We recommend 

Securing Network Services

Network services enable distributed computers and their users to communicate, access remote systems and information, transfer files, send electronic mail, print files on network printers, and manage remote systems. Multi-user operating systems such as the Solaris OE typically provide many network services.

In the standard Solaris OE configuration, even desktop systems offer some network services. Also, many third-party applications provide additional network services when deployed on the Solaris OE. These services are either necessary for the operation or management of the application (for example, VERITAS Volume Manager Storage Administrator, a web-based GUI management tool) or are essential to the service the application provides (for example, Netscape Enterprise Server, a web server). A standard Solaris OE installation with third-party applications may provide many different network services.

To facilitate rapid system deployment, by default the Solaris OE is designed to provide unrestricted access to many installed network services. This approach allows customers to quickly integrate Solaris OE systems into their computing environments with little effort and few administrative requirements. Most of the enabled network services are not necessary or even used in some environments. For security purposes, all unneeded network services should be disabled, and all required network services should be protected.

Installation and minimization of the Solaris OE are important to the security of the system. This section describes the network services provided when all Solaris OE bundled packages are installed (the Entire Distribution cluster). If a smaller installation cluster is used, some of these services are not installed. The Solaris OE Core cluster contains the fewest packages and services.

If the recommendations from the Sun BluePrints article "Solaris_ Operating Environment Minimization for Security: A Simple, Reproducible, and Secure Application Installation Methodology" are followed, then fewer network services are installed.

The network services a system provides are the entry points into that system. It is important to understand the default configuration of Solaris OE services and the methods used to disable them. Often, organizations need to use protocols or services that are not secure. For these commonly used insecure services (such as RPC, NFS, and Trivial FTP), we provide suggestions for improving security.

Services offered by a system should be protected by as many layers of security as possible. This protection starts at the network level. Refer to the Sun BluePrints OnLine article "Network Settings for Securing the Solaris Operating Environment." It describes actual network attacks, lists available Solaris OE configuration options, and makes recommendations to provide additional protection for the ARP, ICMP, IP, TCP, and UDP protocols at the network driver layer.

Network services may be attacked in many different ways. These services may contain programming flaws, use weak or no authentication, transfer sensitive data in unencrypted format, and allow connections from any network host. These weaknesses allow a system to be compromised by an attacker.

There are some simple methods to reduce the risk of successful attacks against a system. Administrators should disable unneeded services and apply all security patches. In addition, network services with security features (for example, encryption, strong authentication, etc.) should be used whenever possible.

This section contains the following topics:

• "Using Network Security Tools"
• "Securing Telnet Connections"
• "Securing Remote Access Connections"
• "Securing Remote Execution"
• "Securing FTP and Using Alternatives"
• "Enabling TCP Wrappers"
• "Enabling Trivial FTP"
• "Securing Managed Services"
• "Securing Remote Procedure Call (RPC) Services"
• "Disabling or Securing NFS Services"
• "Disabling or Securing Automount Services"
• "Securing sendmail Services"
• "Configuring Name Service Caching"
• "Securing Print Services"
• "Configuring IP Forwarding"
• "Configuring Network Routing"
• "Disabling Multicast Routing"
• "Minimizing inetsvc"
• "Modifying Network Service Banners"

Using Network Security Tools

The Solaris 9 OE is the first Solaris OE release to bundle several tools that can provide protection for network services. These are as follows:

• Solaris Secure Shell (based on the OpenSSH source)

• Kerberos Key Distribution Center (KDC) supporting version 5

• TCP Wrappers

These integrated tools simplify the protection of network services because administrators no longer need to integrate these tools into Solaris 9 OE.

For Solaris 8 OE and previous Solaris OE releases, SunScreen_ and SunScreen Lite are two products from Sun Microsystems that provide network protection. Both are firewall products that provide network-level access control and logging. The SunScreen Lite product is a feature-reduced version of the SunScreen software that is available for the Solaris 8 OE release at no cost. The SunScreen Lite product is limited to two network interfaces, but it still provides adequate protection for network services. Use the SunScreen software for systems where more than two network interfaces are required.

Solaris 9 OE includes the entire release of SunScreen 3.2 on the Solaris OE CDs at no cost. All the capabilities available in SunScreen are enabled and available through the installation of the software.

Firewall products like these can be deployed on servers and even desktops where IP forwarding is not required but network service protection is. Massive deployments and management of firewalls on many systems can be burdensome, so plan appropriately.

Additionally, there are well-regarded open source and commercial tools that allow Solaris OE administrators to add protection to Solaris 9 OE systems and to provide protection for earlier Solaris OE releases. These tools address security concerns by providing the following protection: access control, logging, strong authentication, and privacy through encryption.

OpenSSH (an open source toolkit) and SSH (a commercial product) are both suites of tools to replace unsafe UNIX_ network commands such as telnet, ftp, rlogin, rsh, and rcp and to provide secure tunnel X window network communications. The Secure Shell implementation in Solaris 9 OE is based on this software.

OpenSSH, SSH, and Solaris_ Secure Shell all provide strong authentication and privacy through encryption. When built with the TCP Wrappers library, OpenSSH benefits from TCP Wrapper access control, which is used with Solaris Secure Shell. Like TCP Wrappers, OpenSSH, SSH, and Solaris Secure Shell are straightforward to deploy on many systems. They are very valuable tools simply because of the number of unsafe commands they replace. Once deployed, the replaced network services should be disabled in favor of OpenSSH, SSH, or Solaris Secure Shell.

TCP Wrappers, an open source tool developed by Wietse Venema, provides TCP level access control, logging, and DNS hostname verification. With the release of Solaris 9 OE (tcpd), this functionality is integrated into the OS. TCP Wrappers can be used to protect network services managed by inetd. The TCP Wrappers tool provides a flexible configuration mechanism for controlling incoming connections based on pattern matching for hostnames, DNS domains, network addresses, and NIS netgroups. The tool provides better logging and detects DNS hostname discrepancies that may indicate an attack is in progress. TCP Wrappers are fairly straightforward to deploy on Solaris OE systems.

To Access the tcpd Man Page

• Enter the following command to access the tcpd man page:

  # man -M /usr/sfw/man tcpd

  Sun Microsystems has a more sophisticated product that provides strong authentication and privacy for intranet network services and systems, called the Sun Enterprise_ Authentication Mechanism. It is based on MIT's Kerberos V system. The Sun product provides centralized security management and interoperates with other heterogeneous Kerberos systems. For Kerberos to be used effectively and correctly, an entire infrastructure of Kerberos components must be deployed. This infrastructure adds additional administrative overhead that might not be desired. For additional information on Sun Enterprise Authentication Mechanism or Kerberbos, refer to the Sun BluePrints OnLine article "Kerberos Network Security."

Securing Telnet Connections

Telnet is a user-interactive service used to log into and access a remote system on the network. Unfortunately, this service provides little in the way of security. The only authentication information required is user name and password. Neither of these pieces of information are encrypted while in transit and are therefore vulnerable to a variety of attacks including man in the middle attack, session hijacking, and network sniffing. The Sun Enterprise Authentication Mechanism product provides a replacement telnet command that uses strong authentication and encryption. Tools implementing the Secure Shell protocol can also serve as an effective replacement.

If you must use a telnet daemon that does not support encryption, then use a product or technology such as One Time Passwords, host-based firewalls, or TCP Wrappers to secure the connections.

One Time Passwords protects against network sniffing by not transmitting the password over the network. Instead, a challenge issued by the server in combination with a secret phrase is used to generate the password for authentication.

Host-based firewalls and TCP Wrappers limit the hosts that might connect to a system. By restricting access to services based on IP addresses, a system can limit its exposure to network attacks.

Securing Remote Access Connections

Access control and accountability are critical to the security of a system. Access control should involve strong authentication for system access, while accountability information should provide tracking data relative to system changes.

The standard r* commands (rsh, rlogin, and rcp) break both of these requirements, because most implementations of r* commands involve "zones of trust." Within a zone of trust, all systems are trusted and no additional authentication is required. Hence, an intruder need only gain access to one server in order to gain access to all servers.

The default authentication mechanism of the r* daemons uses the host name or IP address of a system in combination with the user ID for authentication. No additional authentication is required. Considering the ease in which an IP address and user ID can be stolen or misused, this default is clearly not a secure mechanism. The r* commands should not be used in this manner and no servers should offer the service in this manner.

One way to secure r* daemons is with Kerberos; the Sun Enterprise Authentication Mechanism product provides the appropriate replacement for r* clients and servers through Kerberos.

Securing Remote Execution

The remote execution server daemon, in.rexecd, is started from /etc/inetd.conf when a connection request is made. This daemon provides remote execution facilities based on user name and password information.

Once authenticated, the daemon executes the command passed along with the authentication information. As with the in.telnetd daemon, neither the user name nor password is encrypted while transmitted over the network. This exposes the in.rexecd daemon to the same man in the middle, session hijacking, and network sniffing attacks as the in.telnetd daemon. For this reason, we recommend that you disable the in.rexecd entries in /etc/inetd.conf file.

Securing FTP and Using Alternatives

The ftp daemon has many of the same problems as the telnet daemon. All authentication information transmitted over the network is in clear-text, in much the same fashion as the Telnet protocol. This default exposes the FTP protocol to many of the same attack scenarios as telnet, including man in the middle, session hijacking, and network sniffing. For these reasons, alternatives to FTP should be considered when FTP transport functionality is required.

There are several alternatives to FTP that provide strong encryption and authentication. Sun Enterprise Authentication Mechanism provides a mechanism to secure FTP. Another alternative is to use Solaris Secure Shell implemented in Solaris 9 OE, or OpenSSH or SSH with earlier Solaris OE releases.

Solaris 9 introduces a variety of new capabilities to the in.ftpd daemon based on the Washington FTP (wu-ftp) implementation. These may include controlling FTP access through the /etc/ftpd/ftpaccess file, logging all ftp commands to SYSLOG, explicit definition of the control and data ports to be used, the ability to chroot the FTP session, in addition to other capabilities. Refer to the various FTP man pages for additional information.

In Solaris 9 OE, all FTP capabilities can be removed from a system by removing the SUNWftpr and SUNWftpu packages.

Solaris OE versions prior to version 9 have two capabilities in the in.ftpd daemon that can provide additional security. The first is the /etc/ftpusers file, which is used to restrict access to the system through FTP.

A default ftpusers file is included with Solaris OE versions 8 and 9. Solaris 8 OE stores it in /etc, and Solaris 9 OE stores it in /etc/ftpd. All accounts not allowed to use the incoming FTP service should be specified in this file. At a minimum, this should include all system accounts (for example, bin, uucp, smtp, sys, and so forth) in addition to the root account. Only intruders and individuals attempting to gain unauthorized access use FTP with these accounts. Frequently, root access to a server over Telnet is disabled and root FTP access is not. This configuration provides a backdoor for intruders who might modify the system's configuration by uploading modified configuration files.

The second security feature of the in.ftpd daemon is the ability of the daemon to log the IP addresses of all connections and commands issued to the ftp daemon through the SYSLOG service. Logging of IP addresses is enabled with the -l option. Commands issued to the ftp daemon are logged when the -d option is used. By logging FTP connection requests and commands to a log server for parsing, unauthorized access attempts can be tracked and resolved.

Enabling TCP WrappersTo Enable TCP Wrappers on a Solaris 9 OE System

1. Modify the ENABLE_TCPWRAPPERS in /etc/default/inetd as follows:

   ENABLE_TCPWRAPPERS=YES

2. After enabling wrappers, verify that inetd has either restarted or sent a HUP and that services listed in /etc/inetd.conf can use the capabilities of TCP Wrappers.

   A simple TCP Wrapper configuration could have the following configuration in its /etc/hosts.allow and /etc/hosts.deny files:

   # cat /etc/hosts.allow
   ALL: LOCAL 10.8.10.0/255.255.255.0 10.8.11.0/255.255.255.0
   in.ftpd: 10.8.31.100
   in.telnetd: 192.168.254.10
   sshd: 10.0.0.0/255.0.0.0 192.168.0.0/255.255.0.0
   
   # cat /etc/hosts.deny
   ALL: ALL

   This sample configuration restricts access to all /etc/inetd.conf started services to the local subnet and two class C IP ranges (10.8.10.0 and 10.8.11.0). In addition, ftp, Telnet, and SSH all allow other IP addresses to connect as well. For more information on TCP Wrapper capabilities, refer to its documentation.

Enabling Trivial FTP

The trivial FTP service (in.tftpd) exists to provide diskless systems with a way to access files on the network. The in.tftpd daemon has no authentication and only allows clients to access publicly readable files in a restricted directory. Diskless workstations, X-terminals, and some printers use this service to load files needed to boot. The in.tftpd is managed by the inetd server process and is configured in /etc/inetd.conf. By default, it is not enabled in the Solaris OE.

If this service is necessary, it should be configured securely. The default entry in the Solaris OE /etc/inetd.conf is configured correctly. When enabled, in.tftpd runs as the user nobody and restricts client access to the /tftpboot directory (the internal default) or a specified directory. The -s option provides additional protection by requiring that the /tftpboot directory exist. If it does, the in.tftpd changes the root directory, using chroot(), to /tftpboot. This option should always be used when TFTP functionality is required.

Securing Managed Services

The inetd daemon controls a majority of the minor network services available on a system. Its configuration file, /etc/inetd.conf, defines what services are managed by the inetd daemon.

An ideally secured server should neither have an /etc/inetd.conf nor run inetd, because the daemons started in the /etc/inetd.conf are frequently not needed.

The Solaris 9 OE is the first Solaris OE release that adds entries only to the /etc/inetd.conf file when specific packages are installed. For example, the /etc/inetd.conf entries for FTP are added only when the SUNWftpr package is added. Refer to the Sun BluePrints OnLine article "Solaris_ Operating Environment Minimization for Security: A Simple, Reproducible, and Secure Application Installation Methodology."

Solaris 9 OE implements an /etc/default/inetd to control the use of TCP Wrappers and connection logging. Also, connection logging can be enabled through the use of the -t inetd option in Solaris 9 OE, as with earlier Solaris OE releases.

Of the daemons started from the /etc/inetd.conf, the remote access FTP, TFTP, and Telnet services were described earlier. The RPC and print services are described later in this article. The remaining /etc/inetd.conf entries are as follows:

• in.tnamed – supports the DARPA Name Server Protocol. This daemon should be disabled.

• in.uucpd – supports UUCP connections over networks. This service should be disabled unless UUCP is used.

• in.fingerd – provides information on local system accounts. This service should be disabled unless needed.

• systat – provides anyone connecting to the system with the output of ps -ef. This service should be disabled because it provides too much system information.

• netstat – provides a list of current network connections via the output of the netstat command. This service should be disabled because it provides system information that can be used to launch attacks against the system.

• time – prints out the current time and date. Beginning with Solaris 2.6 OE, the xntp functionality is included with the Distribution cluster for time synchronization. The xntp daemon offers additional security and functionality improvements over rdate and time. Whenever possible, xntp should be used.

• echo – echoes back the incoming data stream. This service should be disabled.

• discard – discards the incoming data stream. This service should be disabled.

• chargen – generates a continuous stream of characters. This service should be disabled.

These entries in the /etc/inetd.conf file should be removed on most systems. Once removed, restart the system and test applications to verify that required functionality is not affected.

For restricted access servers, all connections to services managed by inetd should be logged.

• For Solaris 8 OE and older versions, this logging can be done by adding an additional option to the startup of inetd in /etc/rc2.d/S72inetsvc. By adding a -t option, the inetd daemon logs the IP address of all systems requesting inetd based services.

• For Solaris 9 OE and newer versions, this logging can be done by enabling the ENABLE_CONNECTION_LOGGING option in the /etc/default/inetd file.

Regardless of Solaris OE version, the IP addresses of all systems requesting services based on inetd are logged through the SYSLOG service.

To Disable a Service

1. Edit the /etc/inetd.conf file and place a comment character (#) in front of the line containing the service definition.

2. Send a HUP signal to the inetd process.

   This signal causes it to reread its configuration file.

Securing Remote Procedure Call (RPC) Services

The remote procedure call (RPC) mechanism provides a way for network services to communicate and make procedure calls on remote systems. When a new RPC service is started, it registers with rpcbind, the central RPC service agent. The rpcbind maintains a table of RPC services (listed by a program number) and the network address(es) on which RPC listens for clients to connect. A client first communicates with the rpcbind service to determine the network address it must use to contact a particular RPC service. Current RPC services can be listed using the rpcinfo command that communicates with the rpcbind service.

RPC services are used in many UNIX services including: NFS, NIS, NIS+, and Kerberos. RPC services are used also by many applications such as Solstice DiskSuite_ software, Sun_ Cluster software, and others.

When an RPC service is started, the service tells the rpcbind daemon the address where it is listening and the RPC program numbers it is prepared to serve. When a client wishes to make an RPC call to a given program number, it first contacts the rpcbind daemon on the server machine to determine the address where RPC requests should be sent. The rpcinfo command can be used to determine what RPC services are registered on a host.

RPC, by itself, can be used to provide an attacker with information about a system. While this may not be ideal, the real security problem is not with the rpcbind daemon itself, but rather with many of the services that use RPC. Many of these services do not make use of the stronger authentication mechanisms available to them and default to weak authentication. In particular, rpc.cmsd, sadmind (running without -S 2), and rpc.rexd use weak authentication by default. Network-based attacks against these services pose a significant threat to the security of a server.

The daemons and services that use RPC on a Solaris OE system include the following:

• cachefsd
• kcms.server
• kerbd
• keyserv
• nis_cachemgr
• rpcbind
• rpc.bootparamd.
• rpc.cmsd
• rpc.nisd
• rpc.nispasswdd
• rpc.rexd
• rpc.rstatd
• rpc.rusersd
• rpc.rwalld
• rpc.sprayd
• rpc.ttdbserver
• rquotad
• sadmind
• testsvc
• ufsd
• xaudio

Whether these services are included in Solaris 9 OE installation depends on the packages installed. Many of these services are only installed if their related packages are installed. Solaris 9 OE no longer installs a fully populated /etc/inetd.conf with the seven Core Solaris OE packages.

On almost all servers, the RPC services in /etc/inetd.conf can be removed. Many applications that use RPC services add entries to the /etc/inetd.conf in addition to using one of the RPC-based daemons. The RPC services in /etc/inetd.conf should be removed unless required.

The RPC daemons started in /etc/rc2.d and /etc/rc3.d are for rpcbind, keyserv, various naming services (for example, NIS and NIS+), and are used by both the client and server components of NFS. The keyserv daemon must be run when AUTH_DES is used for stronger host and user authentication. The use of NIS is not recommended due to its weak security models. NIS+ provides a much more robust security model.

The RPC protocol provides support for various authentication alternatives. These are as follows:

• AUTH_NONE – No authentication.

• AUTH_SYS or AUTH_UNIX – Traditional UNIX-style authentication.

• AUTH_DES – DES encryption-based authentication.

• AUTH_KERB – Kerberos encryption-based authentication.

Some RPC daemons and services provide options for an administrator to specify the security model (for example, NFS, sadmind, NIS+) while others do not. If RPC must be used, then only those services and daemons that provide support for AUTH_DES should be used. This combination of RPC and AUTH_DES authentication is called Secure RPC. Refer to "References and Related Resources" on page 56 for additional references to Secure RPC.

Disabling or Securing NFS Services

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 on Solaris 9 OE, remove the following fix packages with pkgrm:

• SUNWnfscr
• SUNWnfscu
• SUNWnfscx
• SUNWnfssr
• SUNWnfssu
• SUNWnfssx

On previous Solaris OE releases, the NFS services cannot be removed through pkgrm. Disable the following startup scripts 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 require an NFS server. Several different levels of security are 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 than can be covered here.

Disabling or Securing Automount Services

The automount service manages automated NFS mounts. NFS clients might 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 was, 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_master 
/net -hosts -nosuid 
/home auto_home 
/xfn -xfn

Ideally, automount should be disabled, because not only does it run as a privileged daemon, but it uses NFS and RPC. The automount system can be disabled by renaming /etc/rc2.d/S74autofs.

There are situations where the automount service is needed for its ability to mount and unmount file systems automatically. In particular, both NIS and NIS+ environments make extensive use of auto_home and auto_master maps 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. You can do this by using NFS mount options and Secure RPC.

Frequently, NFS servers allow any system to mount the file systems they export. This incorrect and all too common practice allows attackers to mount file systems that might contain sensitive information. If attackers want to modify the contents of a particular file, they need only change their user ID or UID to that of the file and modify its contents. These attacks, and many other NFS-based attacks, can be avoided through the use of appropriate NFS exports, Secure RPC, or Kerberized NFS.

Securing sendmail Services

The sendmail daemon is used on a Solaris OE system to forward and receive mail from other systems. Centralized mail servers should be used to receive mail instead of using local servers. These 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 sendmail daemon bundled with the Solaris OE has been subject to numerous denial of service, buffer overflow, and misconfiguration attacks. Alternative MTAs with smaller and more robust code are available. 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 refer to recommendations made at SendMail Consortium, in the Sendmail O'Reilly books, and through the SunSolve Online^SM service. There are a wide variety of sendmail versions in use, and there are differences in the associated sendmail.cf configuration files. Because of this, a sample sendmail.cf file is not included with this article.

Removing sendmail

If sendmail is not required, or only outgoing sendmail is required, we recommend that you remove, disable, or enable only outgoing sendmail. The options available vary according to the Solaris OE release you installed. TABLE 1 shows the methods available.

TABLE 1 sendmail Methods Available by Solaris OE Version

Methods	Solaris 2.6 OE and Earlier	Solaris 7 OE	Solaris 8 OE	Solaris 9 OE
Remove (pkgrm) Command	Not Available	Available	Available	Available
Disable Options	Disable startup scripts	Disable startup scripts	MODE option	Modify sendmail.cf file
Enable Outgoing Only	Add cron entry	Add cron entry	MODE option	Modify sendmail.cf file

The following subsections provide instructions and recommendations for removing or disabling sendmail.

To Remove sendmail

• If no sendmail functionality is required, remove it:

  • For Solaris 2.6 OE and earlier releases, comment out the /etc/rc2.d/S88sendmail script. After this script is commented out, sendmail is not started during system startup.

  • For Solaris OE versions 7, 8, and 9, remove all components of sendmail by removing the SUNWsndmr and SUNWsndmu packages with the pkgrm command.

Allowing Only Outgoing sendmail

The sendmail daemon is not needed for email delivery to other systems. All messages that can be are immediately delivered. Messages that cannot be immediately delivered are queued for future delivery. The sendmail daemon, if running, retries to deliver these messages again.

To Enable Only Outgoing sendmail

• Perform the following according to which Solaris OE version is installed.

  • For Solaris OE versions 7 and earlier, use a cron job to start sendmail every hour to process undelivered messages.

    The following cron entry starts sendmail every hour to flush the mail queue:

    0 * * * * /usr/lib/sendmail -q

  • For Solaris 8 OE releases, use the MODE option. Create the following line in a new default configuration file named /etc/default/sendmail:

    MODE=""

    By defining the MODE to be a null string, sendmail processes only the outgoing mail queue and does not accept incoming connections.

    An example replacement /etc/default/sendmail file is available from the Sun BluePrints Tools page at http://www.sun.com/blueprints/tools, which documents the other sendmail options added in Solaris 8 OE.

    NOTE

    The MODE option does not work with Solaris 9 OE. For previous Solaris OE versions, it was possible to start sendmail in queuing processing only mode. For Solaris 9 OE, it goes through an extra submission hop, sending to localhost. If you were to use the MODE option in this version, all outbound mail would stop because nothing is listening on the SMTP port on the local host. The mail would remain in the client mail queue.

  • For Solaris 9 OE releases, perform the following steps to disable incoming sendmail and allow outgoing sendmail.

    1. cd /usr/lib/mail/cf.

    2. cp subsidiary.mc hostname.mc.

    3. Edit the hostname.mc file, adding the following before the MAILER() lines:

       DAEMON_OPTIONS('Name=NoMTA4, Family=inet, Addr=127.0.0.1')dnl

    4. Enter one of the following commands:

       /usr/ccs/bin/make hostname.cf
       or /usr/ccs/bin/m4 ../m4/cf.m4 hostname.mc > hostname.cf

    5. cp hostname.cf /etc/mail/sendmail.cf.

    6. Enter the restart command as /etc/init.d/sendmail restart.

       The Solaris 9 OE sendmail implements RFC 2476 (Message Submission). For example, it can now listen on several different ports, notably port 587. Use of this port is enabled by default in m4-generated .cf files. RFC 2476 support and the use of port 587 can be disabled by adding FEATURE('no_default_msa') to the sendmail.cf file.

Configuring Name Service Caching

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 was expanded to address additional name service databases.

Because caching name service data makes spoofing attacks easier, it is recommended that the configuration of nscd be modified to cache as little data as possible. This task is accomplished by setting the positive ttl to zero in the /etc/nscd.conf file for the name service requests deemed vulnerable to spoofing attacks. In particular, the configuration should be modified so that passwd, group, and Solaris 8 and 9 OE RBAC information has a positive and negative ttl of zero.

The nscd -g option can be used to view the current nscd configuration on a server and is a helpful resource when tuning nscd.

Disabling nscd entirely is not recommended, because applications make name service calls directly, which exposes various bugs in applications and name service backends.

Securing 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.lpd daemon is only necessary for systems that provide network print queue services.

If the system does not participate in print spooling, comment out 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 lp should be removed from the system, and the in.lpd entry should be removed from /etc/inetd.conf.

The three packages for lp are SUNWpsr, SUNWpsu, and SUNWlpmsg. If all lp-related functionality is removed, also remove the Solstice_ Print Client. The Solstice Print Client is located 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.

Configuring 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 is configured as a router and if ip_forwarding is enabled between the different interfaces. Solaris 8 OE adds an ability to set ip_forwarding on a per-interface basis. For more information on the ip_forwarding function, refer to the Sun BluePrints article "Network Settings for Securing the Solaris Operating Environment."

Configuring Network Routing

The network router (in.routed) and router discovery (in.rdisc) daemons are used by a Solaris OE system to dynamically determine network routing requirements. Both in.routed and in.rdisc functionality are addressed in the Sun BluePrints article "Network Settings for Securing the Solaris Operating Environment."

Disabling Multicast Routing

Multicast is a method to send network data to many systems at the same time with only a single address. Unless the system must participate in a multicast application, it is recommended to disable the code that enables the multicast route assignment.

To Disable the Code for Multicast Remote Assignment

• For Solaris 7 OE and earlier, comment out the following lines in /etc/init.d/inetsvc:

  mcastif=´/sbin/dhcpinfo Yiaddr´ 
  if [ $? -ne 0 ]; then 
  			 mcastif=´uname -n´ 
  fi
  echo "Setting default interface for multicast: \c" 
  /usr/sbin/route add -interface -netmask "240.0.0.0" "224.0.0.0" "$mcastif"

• For Solaris 8 OE, comment out the following lines in /etc/init.d/inetsvc:

  (
  if [ "$_INIT_NET_STRATEGY" = "dhcp" ]; then
      mcastif='/sbin/dhcpinfo Yiaddr' || mcastif=$_INIT_UTS_NODENAME
  else
      mcastif=$_INIT_UTS_NODENAME
  fi
  
  echo "Setting default IPv4 interface for multicast:" \
    "add net 224.0/4: gateway $mcastif"
  
  /usr/sbin/route -n add -interface "224.0/4" "$mcastif" >/dev/null
  ) &

• For Solaris 9 OE, comment out the following lines in /etc/init.d/inetsvc:

  (
  if [ "$_INIT_NET_STRATEGY" = "dhcp" ]; then
      mcastif='/sbin/dhcpinfo Yiaddr' || mcastif=$_INIT_UTS_NODENAME
  else
      mcastif=$_INIT_UTS_NODENAME
  fi
  
  echo "Setting default IPv4 interface for multicast:" \
    "add net 224.0/4: gateway $mcastif"
  
  /usr/sbin/route -n add -interface 224.0/4 -gateway "$mcastif" >/dev/null
  ) &

  When the appropriate lines are commented out, the system should be restarted.

Minimizing inetsvc

Based on the recommendations made in this article, it is possible to construct a minimized /etc/init.d/inetsvc file to contain only essential components. Quite a few sections of this file can be commented out including:

• DHCP support
• Use named startup support
• Multicast support

To Minimize inetsvc

• For Solaris OE releases 7 and older, comment out all of the previously mentioned entries as follows:

  #!/bin/sh
  
  /usr/sbin/ifconfig -au netmask + broadcast +
  /usr/sbin/inetd -s -t

  The number of active lines in the inetsvc file decreases from 152 to 3 lines.

• For Solaris OE releases 8 and newer, comment out all of the previously mentioned entries as follows:

  #!/bin/sh
  
  /usr/sbin/ifconfig -auD4 netmask + broadcast +
  /usr/sbin/inetd -s -t

Modifying Network Service Banners

Some Solaris OE network services provide information on the operating system version when connections are made. This information usually includes a text string indicating the name of the OS and its version. This information may be useful to attackers with exploit programs for specific OS releases. The Solaris OE provides methods to change these messages in an attempt to hide OS information.

These methods provide only minor additional security. There are methods to determine a system's operating system type and version on a network. Several network auditing tools use a technique called "TCP/IP stack fingerprinting" to determine the operating system and version.

To Change Banner Messages for Incoming Telnet Connections

1. Create an /etc/default/telnetd file.

2. Add a line similar to the following, as appropriate for your environment:

   BANNER="Authorized Use Only"

To Change Banner Messages for Incoming FTP Connections for Solaris 8 OE and Older Versions

1. Create an /etc/default/ftpd file.

2. Add a line similar to the following, as appropriate for your environment:

   BANNER="Authorized Use Only"

To Change Banner Messages for Incoming FTP Connections for Solaris 9 OE

1. Review the /etc/ftpd/ftpaccess file to determine if the following entry is present:

   banner=/etc/ftpd/banner.msg

2. If the entry is not present, add it.

3. Replace the contents of the /etc/ftpd/banner.msg file with a line similar to the following, as appropriate for your environment:

   Authorized Use Only

4. Edit the /etc/inetd.conf file to add an -a option after the in.ftpd entry.

   If in.ftpd is started with the -a option, it parses the /etc/ftpd/ftpaccess file and displays the banner message listed. By default, this is the /etc/ftpd/banner.msg file.

   The following is an example of the modified /etc/inetd.conf file.

   ftp stream tcp6 nowait root /usr/sbin/in.ftpd in.ftpd -a -l

To Change Banner Messages for the Solaris 9 OE sendmail Daemon

• If you want to change the banner message that the sendmail process presents for incoming mail delivery connections, do the following:

  1. Search the /etc/mail/sendmail.cf file for the following line:

     O SmtpGreetingMessage=$j Sendmail $v/$Z; $b

  2. Change it to:

     O SmtpGreetingMessage=Mail Server Ready

To Change Banner Messages for CDE Connections

1. Create a system warning message in, for example, the /etc/motd file.

2. Enter the warning message text into the file.

To improve the resulting display of the text, you may want to center the text and enter hard returns to control line length.

1. Change directory as follows:

   cd /etc/dt/config/Xsession.d

2. Enter the following in your file:

   dtstart_hello[0]="/usr/dt/bin/dthello -bground white -file /etc/motd &"

3. Log out of CDE and log back in to implement the warning message.