Solaris for ISPs Administration Guide

Chapter 3 Setup Guidelines

Solaris^TM for ISPs^TM provides a core infrastructure with a set of platform extensions and services for ISPs. This chapter discusses the guidelines for configuring your network host for the installation of Solaris for ISPs extensions and services. This configuration information is essential for successful installation. Please read carefully.

Install Scenario

You must design your network before installing Solaris for ISPs. This section discusses two tested examples of a Solaris for ISPs network hosts setup. You may use the network hosts setup example that most closely suits your environment.

Network Setups

This section describes a base and an expanded example network setup, and the requirements and recommendations for the hardware configuration of the setups.

Note -

We do not assume the existence of a firewall in our example network setups. If you are using an Internet firewall product to control network traffic to or from any Solaris for ISPs host, you should examine the security policy controlling this host to make sure the relevant types of communication are allowed. This document does not offer recommendations related to Internet firewalls.

Base Setup

This figure illustrates a base example setup.

Figure 3-1 Base Configuration

Base Hardware Requirements

Three high-end workstations.
Primary and secondary DNS servers.
The hosts must be on a network connected to the Internet.
You can use any server on the network to act as a client host.
You need a Web browser on the client host for Sun Internet Administrator and Sun Internet Services Monitor client software.

Base Example Setup Design

The three servers are referred to as Host A, Host B, and Host C. For example, the host servers may be configured as follows:

Host A: Configure this server to act as a service host. Install SWS, Sun Internet FTP Server, and configure the host as a primary DNS server.
Host B: Configure this server to act as a console host. Install Sun Internet Administrator, Sun Directory Services, and Sun Internet Services Monitor.
Host C: Configure this server to act as a service host. Install Sun Internet News Server and configure the host as a secondary DNS server.

Note -
The DNS server configurations discussed in this example setup are suggestions only. You need not install Solaris for ISPs extensions and services on a host acting as a DNS server. Most extensions and services only require the ability to perform name lookups regularly.

Expanded Setup

This figure illustrates an expanded example network setup.

Figure 3-2 Expanded Configuration

Expanded Hardware Requirements

Four high-end workstations
Primary and secondary DNS servers
The hosts must be on a network connected to the Internet.
You can use any server on the network to act as a client host.
You need a Web browser on the client host for Sun Internet Administrator and Sun Internet Services Monitor client software.

Expanded Example Setup Design

The four servers are referred to as Host A, Host B, Host C, and Host D. For example, the host servers may be configured as follows:

Host A: Configure this server to act as a service host. Install SWS, Sun Internet FTP Server, and configure the host as a primary DNS server.
Host B: Configure this server to act as a console host. Install Sun Internet Services Monitor, and configure the host as a secondary DNS server.
Host C: Configure this server to act as a service host. Install Sun Internet News Server.
Host D: Configure this server to act as a console host. Install Sun Internet Administrator and Sun Directory Services on this host.

Note -
The DNS server configurations shown in this example setup are suggestions only. You need not install Solaris for ISPs extensions and services on a host acting as a DNS server. Most extensions and services only require the ability to perform name lookups regularly.

Note -

After designing the network hosts setup, prepare the hosts for the installation of Solaris for ISPs. Refer to "Solaris for ISPs Platform Extensions" to prepare the hosts as designed.

Security Issues

Any network with Internet access exposes the network to some security risks. In addition, some Solaris for ISPs features introduce others. In every case, there are several security measures that can be implemented to protect your network. The following sections discuss some good system administration practices and Solaris for ISPs features that will enable you to secure your network from these risks.

Standard Internet Security Risks

Connecting the network to other networks on the Internet exposes your network to potential service interruptions, unauthorized intrusion, and considerable damage. This section discusses such standard network security risks that you must be aware of. Protections against these risks are discussed in "How To Tighten Security".

Denial of Service Attacks: These attacks disable the system from serving customers and make a service unavailable for the customer. For example, the attacks can flood the network with useless traffic resulting in inability to serve customers. Most often, such attacks could crash the system or just make the system really slow in serving customers.
Buffer Overrun Exploits: These include exploiting the software weakness to add arbitrary data into a program, which when run as root, may give the exploiter root access to your system. This may also result in a denial of service attack.
Snooping and Replay Attacks: The snooping attacks involve an intruder listening to traffic between two machines on your network. The traffic may include passing unencrypted passwords back and forth while using telnet, rlogin, or ftp. This might result in an unauthorized individual breaking into your network or reading confidential data.
IP Spoofing: Attacks based on IP spoofing involve unauthorized access to computers. The intruder listening to your network traffic finds an IP address of a trusted host, and sends messages indicating that the message is coming from that trusted host.
Internal Exposure: Most network break-ins are the result of a malicious or disgruntled present or former employee misusing access to information or breaking into your network.

Security Risks in Solaris for ISPs

This section discusses some Solaris for ISPs features that leave the software open to some security risks. Please refer to "How To Tighten Security" for protection against these risks.

Administration Products: Solaris for ISPs administration products for individual services, such as ftp or news, provides new paths for accessing privileged operations. This intruder, by knowing, guessing, or cracking the password of the administrator, may change the behavior of the services by exploiting their administrator interface through the network. However, Sunscreen^TM SKIP, bundled with Solaris for ISPs, authenticates incoming traffic and ensures that outgoing data is not viewed by others while in transit.
Remote Command Execution Mechanism: Sun Internet Administrator provides access to all of the command-line administration commands through its administrator console remote execution mechanism. An intruder may break this mechanism and gain access to those commands. However, access to these commands can be restricted, by root, to registered system administrators only.
Sun Directory Services: This Solaris for ISPs software can be used to store and manage passwords and information about other Solaris for ISPs extensions and services. An intruder may break in and exploit access to such privileged information. However, most passwords in Sun Directory Services are encrypted. Unencrypted passwords in Sun Directory Services require root access.

How To Tighten Security

To protect your system from unauthorized users accessing, corrupting, or changing information, and to make the network available to authorized users:

Regularly change passwords and encourage using not-easy-to-guess passwords. Solaris for ISPs software forces all passwords to change periodically if local files are used for password management.
Use public-key cryptography to encrypt all traffic between trusted hosts at the IP level. SKIP, bundled with Solaris for ISPs, authenticates incoming IP traffic and ensures that outgoing data is not altered or viewed by others while in transit.
Use routers that can identify trusted hosts and block spoofed IP addresses.
Fix vulnerabilities and bulletproof your software.
Disable unwanted services that open your network to security risks. Solaris for ISPs host configuration software, as part of the initial installation process, can disable some 'r' commands to ensure protection for passwords and to restrict access to hosts for unauthorized individuals.
Provide employees access only to the data or information their work requires.
Implement security mechanisms such as network monitoring and firewalls.

Things to Consider

This section discusses certain Solaris for ISPs default features that you must consider and address during host configuration. In this section, topics include:

Changes to Solaris--System files modified by Solaris for ISPs.
Log File Management--Resident daemon of Solaris for ISPs.
User-Defined Script--Creating post-installation scripts.
Default Administration Web Server Setting--Restoring AWS default setting.

Changes to Solaris

This section discusses the onetime only changes and the reconfigurable changes that may be made to Solaris services during host configuration. If you accept the default installation setting, these changes will be made on the host where Solaris for ISPs is installed.

Note -

You must review and may modify, if necessary, these changes to foundation Solaris during host configuration. These changes may not be incorporated in future releases of Solaris for ISPs.

Onetime Only Settings

Solaris for ISPs consists of a foundation configuration unit that runs only once to ensure security for passwords and to safeguard file permissions to the file owner. It makes a set of default changes as part of the initial installation process. The functionality of this unit is similar to the functionality of the script in ftp://ftp.wins.uva.nl:/pub/solaris/fix-modes.tar.gz. To undo these changes, go to "Undoing the Changes".

This section examines the initial installation steps automatically executed only once in the foundation package. You must address this section before installing Solaris for ISPs.

Note -

The script will be executed. However, these changes will take place only if conflicting changes to the files have not already been set up by you.

It runs a script that make modes of files installed as part of Solaris packages more secure. These changes are as follows:
- Removes group and world read permissions for setuid and setgid.
- Removes group and world write permissions on all non-setuid files that meet any of the following criteria:
  - The file has group and world readable permission, but no world writable permission.
  - The file has world executable permission.
  - The file has identical owner, group, and world permissions.
  - It is a bin-owned directory or non-volatile file and has identical group and world read and executable permissions.
- Removes write permissions for owners on executables not owned by root.
It adds umask 077 to /.cshrc and /.profile. This makes the default file permission for files created under an interactive root shell readable and writable only by root.
It adds root to /etc/ftpusers to disable root's ability to ftp to the host.
It sets noshell as the default shell for sys, uucp, nuucp, and listen accounts to log unauthorized logging attempts. This makes it easier to detect intrusion on the system.
It sets MAXWEEKS=12 in /etc/default/passwd. If local files are used for password management, this forces all passwords to change periodically.
It creates S35umask to make default file permission for files created by system daemons writable only by the file owner.
It disables a denial of service attack by adding the line ndd-set/dev/ipip_respond_to_echo_broadcast 0 in the file /etc/rc2.d/S69inet.
It replaces /etc/syslog.conf with a new version for ensuring more granular logging and for detecting intrusion. This new version isolates messages by both facility and logging level and sends the high-level messages to a central logging server.
It executes bsmconv and configures /etc/security to log administrative actions, and logins and logouts. This enables C2 auditing, which may catch events missed by syslog.
All changes made by this unit are logged to /var/sadm/install/contents. This enables patch installation in the future.

Reconfigurable Settings

The installation of Solaris for ISPs platform extensions and services with their default configuration will override the default service behavior on the hosts where they are installed. This procedure creates a more secure server by disabling Solaris network utilities that are not essential to the Solaris for ISPs software installed on the system.

Note -

You must review and may modify, if necessary, the default configuration during host configuration.

If you accept the default installation setup, these Solaris services will be disabled, unless noted otherwise. Disabling of these services is not required, but we recommend disabling these services to avoid potential security holes and to conserve resources. To change the value of these services, inetd.conf will be modified, unless stated otherwise. To undo these changes, go to "Undoing the Changes"

Closing Potential Security Holes

We recommend disabling of the following services to ensure protection for passwords and to restrict access to hosts for unauthorized individuals.

Note -

If you accept the default setting, you will no longer be able to access the host with these disabled "r" commands.

rexecd: Disable this service to discontinue support for remote command execution via the rexec(3N) function, which passes passwords in the clear.
rlogind: Disable this service to ensure security for passwords because it relies on .rhosts and hosts.equiv for password-less authentication during remote logging.
rshd: Disable this service to protect password because it relies on .rhosts and hosts.equiv for password-less authentication during remote command execution.

Note -
If you accept the default setting, the following services will be enabled. You must review and may modify the setting.
telnetd: If you accept the default installation setting, note that this service is enabled as this enables remote login mechanisms.
ftpd: If you accept the default installation setting, note that this service is enabled because it provides support for file transfer to and from remote network sites in the least insecure manner. This service will be disabled if you select Sun Internet FTP Server for installation.

Note -
If you require security for telnet and FTP services, set up your network such that file transfer requests are made within the network.

We recommend disabling the following services to protect information from unauthorized users. Disabling these services will enhance system security and will restrict access to system information by preventing host responses to these network requests.

fingerd: Disable this service to safeguard information from a network-based finger request.
netstat: Disable this service to ensure that the contents of the various network-related data structures are not exposed by remote invocation of netstat.
rstatd: Disable this service to prevent access to system statistics.
rusersd: Disable this service to protect information about logged-in users.
systat: Disable this service to discontinue support for remotely running ps on the host.
routing: Disable this service to ensure that the host is not operated as a router. If disabled, the file /etc/notrouter is created.
sendmail: Disable this service to protect against denial of service attacks and to disable support for receiving and sending mail. S88sendmail is modified.
sprayd: Disable this service to discontinue support to test the network and record packages sent by spray.

Conserving Resources

We recommend disabling of the following CDE and OpenWindows services unless they are required in your environment. Disabling these services will enhance system performance.

cmsd: Disable this service as it is required only if CDE calendars are located on the host.
dtspcd: Disable this service to discontinue support for CDE sessions.
kcms_server: Disable this service to discontinue support for remote access to OpenWindows KCMS profiles.
ttdbserverd: Disable this service to discontinue support for Tooltalk database server required for proper CDE operation.

We recommend disabling the following network (inetd) services unless required in your environment. Disabling these services will free resources and enhance system performance. Modify the default configuration if you require any network utilities listed below.

chargen: Disable this service to discontinue support to test inetd and generate characters.
discard: Disable this service to discontinue discarding all input from testing inetd.
echo: Disable this service to discontinue support to echo back all input from testing inetd.
fs.auto: Disable this service to disable the font server.

Note -
If you accept the default setting, the following service will be enabled. You must review and may modify the setting.
time: If you accept the default installation setting, note that this service will be enabled as it keeps someone from querying the system's time remotely. It returns machine-readable time.
cachefsd: If you accept the default installation setting, note that this service will be enabled. This is the cacheFS daemon.

We recommend disabling of the following services unless they are essential for your environment. Disabling these services will enhance system performance. Please modify the default configuration if you require any services listed below.

automountd: Disable this service as this supports automounting only and not normal NFS mounts. To change its value, S74autofs will be modified.
comsat: Disable this service to discontinue biff(1) notification of new mail on the host.
daytime: Disable this service to discontinue support to return the time of day.
rquotad: Disable this service to ensure that the host is not operated as an NFS server supporting disk quotas on its file system.
sadmind: Disable this service to discontinue support for performing distributed system administration operations using Solstice AdminSuite.
talkd: Disable this service to discontinue support for running the interactive talk program.
tnamed: Disable this service to discontinue support for DARPA name server protocol.
lpd: Disable this service to ensure that the host is not operated as a BSD print server. This does not disable the system V print server.
uucpd: Disable this service and discontinue support for copying files named by the source-file arguments to the destination-file argument.
walld: Disable this service and discontinue support for sending messages by wall.
Xaserver: Disable this service and discontinue support for X-based audio.

Note -

You can also refer to the on line help during host configuration for help in enabling or disabling the Solaris services.

Undoing the Changes

The changes made during host configuration, to harden and fine tune the system for security and for performance, may not be incorporated in the next release of Solaris for ISPs. This section discusses the steps you can take to undo the changes made to foundation Solaris during host configuration.

Log into the computer where you want to undo the changes and give yourself root access. Determine the changes you want to undo and follow the instructions in the bulleted list:

The foundation Solaris services are tuned for security and optimum performance from the host configuration graphical user interface (GUI). These changes are reconfigurable and you can reset the values using the host configuration GUI. Refer Solaris for ISPs Installation Guide and host configuration on line help to reset Solaris service values.
The two additional boot files, S35umask and S68echo in /etc/rc2.d, created after installation are automatically removed when the Solaris for ISPs Platform component is uninstalled.

Note -
You must manually undo some of the one-time only changes made to the system configuration. To undo the hardening changes:
Enter: # /opt/SUNWfixm/bin/fixmodes -u to undo the one-time only changes.
Enter: # bsmunconv to switch from C2 auditing mode to C1 mode. This will turn off auditing turned on to catch events missed by syslog.
Compare the current version of /.cshrc, /.profile, /.zshenv, /etc/ftpusers, /etc/default/passwd, /etc/syslog.conf to the file.pre-hcfconfig version of the file. The current file contains the hardening changes and any other edits that may have been made after hardening was performed. Determine the changes made by the host configuration software and use a text editor to undo the changes.

Note -
Do not copy the file.pre-hcfconfig to the current version of the file without determining the changes made by and after the host configuration.

Log File Management

This section describes the resident daemon, hclfmd,that performs log file management. This resident daemon runs as root. It starts at boot time and performs the following functions:

It parses the list of log files in /etc/syslog.conf for file paths that do not start with /dev (files associated with system devices) and performs a cleanup, journal, and cycle pass every day.

For every log file written by syslogd, it performs the following functions:
- It renames the existing log file and creates a new daily log.
- It sends the restart signal (-HUP) to the syslog daemon to create a new daily log.
- It generates a weekly archive by compressing daily log files every week and stores it as name.YYYYMMDD-YYYYMMDD.tar.z.
- It discards weekly archives that are more than a month old.
It obtains the location of audit logs from /etc/security/audit_control and performs a cleanup, journal, and cycle pass every day.

It performs the following functions for every locally mounted audit directory:
- It executes audit -n to create a new daily log. This signals the audit directory to close the current audit file and open a new audit file in the current audit directory.
- It generates a weekly archive by compressing daily log files every week and stores it as audit.YYYYMMDD-YYYYMMDD.tar.z.
- It discards weekly archives that are more than a month old.
It performs an intrusion detection check every 10 minutes.
- It detects and reports every failed authorization entry in syslog files.
- By default, /etc/opt/SUNWisp/hc/hclfmd.conf is configured to send mail to root for every failed authorization attempt entered in syslog.
  
  Note -
  You may re-configure this file. By default, it is configured as follows: /var/log/badauth:/usr/bin/mailx -s "%f" root < %c where:
  - /var/log/badauth is the file where the entries are made.
  - /usr/bin/mailx -s is the command to send mail to root.
  - "%f" is the subject-line of the mail, containing the name of the file where the entries were detected, and
  - "%c" is the new content of the syslog file.

Creating User-Defined Scripts

This section discusses certain installation and/or configuration updates you may provide to be executed after installation of Solaris for ISPs. These parameters can be written as a shell script. For example, you can write a command similar to: echo "foo" >> /etc/ftpusers

The path to this script that you create can be registered while configuring the host (Post-Configuration Command screen) for installation of Solaris for ISPs. Alternately, you may string these commands. This post-configuration command provided by you will be executed by Solaris for ISPs post-installation script during batch installation.

Note -

Creating this script is optional.

Some post-installation system setup examples that you may address in your script to be executed after installation are illustrated in the following. For example:

Write a program to verify and confirm changes to system setup.
Write a program to notify or print disk space availability after installation.
Write a program to re-configure notification messages from syslog for failed authorization entries. Refer to "Log File Management".
Write a program to configure other independent software.
Write a program to configure DNS host:
- Enter some DNS server IP addresses in /etc/hosts.
- Set up /etc/resolv.conf.
- Modify /etc/nsswitch.conf.
  
  Note -
  The DNS server configurations discussed in this section are suggestions only. You need not reconfigure your existing DNS server. Please refer to a relevant document to reconfigure your DNS server to support Solaris for ISPs extensions and services request for regular name lookups.

Restoring Default AWS Settings

Sun Internet Administrator uses a Web server for the administration funtions from its user interface. This Web server is referred to as the Administration Web Server (AWS). You can, if necessary, reconfigure the Administration Web Server to suit your requirements. Refer to on line help to reconfigure the Admin Web Server. To ensure that you do not lose the default configuration, this section discusses the location of the default Administration Web server configuration files and the method to restore the default settings.

The Administration Web Server default configuration files are located in /etc/opt/SUNWixamc/awsconf/default/* and /var/opt/SUNWixamc/awsconf. When reconfiguring the Admin Web Server, only the /var/opt/SUNWixamc/awsconf file configurations must be changed.

To restore the default settings, copy /etc/opt/SUNWixamc/awsconf/default/* to /var/opt/SUNWixamc/awsconf.

Note -

For the effective functioning of Sun Internet Administrator console, do not change the default settings in aws.conf, site.conf, map.conf, realms.conf, and access.acl.