Version 1.4

Securing a Solaris Server - Initial Installation

  1. Introduction
  2. History of this Web Page
  3. Overview
  4. Network Topology
  5. System Hardware Configuration
  6. Initial Installation
  7. Minimizing Solaris
  8. Minimizing Network Services
  9. Remove the Solaris Installation Leftovers
  10. Install Necessary Third Party Packages
  11. Close the Doors
  12. Obscure the Tracks
  13. Post the Warnings
  14. Perform System Backups
  15. Watch for Changes
  16. Sources of Tools
  17. Bibliography


Purchase Policies Contact ACCS Aout ACCS Home Papers & Projects Services Products

6. Initial Installation

Before installing a Solaris server, disconnect all network interfaces to ensure that there are no intrusion attempts while the installation is occurring, before the system can be properly secured. To transfer data (patches, 3rd party packages and source) to the system being installed, use either CDROM, or tape (or any other non-networked, physically connected device).

Some of the newer SUN systems have neither a CDROM, nor an external SCSI connector. For these systems, you will need to perform the installation from the network. The best way to do this would be on a fully isolated build network. Additionally, there are several papers on the SUN BluePrints website that cover the JumpStart procedure.

When installing Solaris for a server, it is normally not necessary to start with more than the CORE installation. The current Solaris installation is on two CDROMs. Unfortunately, the installation script isn't smart enough to request the second CDROM, unless Java is installed, and Java isn't part of the CORE installation. For this reason, any additional packages must be installed manually. Fortunately, the entire CORE installation resides on the first CDROM.

Set minimum password length
In the /etc/default/passwd file, set the PASSLENGTH variable to 8. This will require that passwords be eight characters long. It should be noted that with the default password methodology, any portion of the password beyond eight characters is ignored.

Set default password changing parameters
In the /etc/default/passwd file, set the MAXWEEKS variable to the maximum number of weeks that can pass, before a user must change their password. If MAXWEEKS is too short, users will have a tendency to cycle through a list of passwords. This value is normally not set to less than 13 (3 months).

Also, set the MINWEEKS variable to the minimum number of weeks that must pass before a user is allowed to change their password. The purpose of this variable is to lessen the likelihood that a user will cycle through a password list, or change their password, then change it right back. For this reason, the MINWEEKS variable should not be set too small. On the other hand, if it is set too large, a user might not be able to change their own password, if it were to become compromised. I feel that a value between 2 and 4 is appropriate for this variable.

Finally, set the WARNWEEKS variable to the number of weeks that must pass since the last password change, before a user will receive password change warnings. This number should be slightly shorter than the value the MAXWEEKS variable was set to. If the difference between MAXWEEKS and WARNWEEKS is too small, users might return from a vacation, and find that they can't log in. I feel that the difference should be at least three weeks.

Add critical hosts
The critical hosts should be added to the /etc/hosts file. A critical host is one that is explicitly referenced in one of the other configuration files. Also, all the names for this host should be in the /etc/hosts file. This is done so that system critical issues do not need to have DNS or NIS functioning. Non-critical hosts can be retrieved through DNS.

If your network is small enough, and you don't need to log the host name of external hosts, or connect to external hosts by name, you might be able to use only the /etc/hosts file (preferable, if it can be done).

Add network names
Add the local networks to the /etc/networks file. Typically, you'd only be concerned about those networks you're directly connected to. This makes some of the netstat outputs easier to read and understand.

Configure DNS
Put the appropriate information into the /etc/resolv.conf file (only needed if you're running DNS).

Set hostname lookup
The /etc/nsswitch.conf file needs to be updated. The hosts line should have files as the first entry. Also, the networks line should have files as the only entry. Any references to NIS or NIS+ should be removed from the hosts line.

Update the login scripts
The files /etc/.login, /etc/cshrc and /etc/profile should be updated, as appropriate for your installation. These are the login script for the C-shell, and the startup scripts for the C-shell and the Bourne-shell, respectively.

Set available shells
The file /etc/shells should be updated to list all the commands that will be allowed to be used as shells by various system utilities. These utilities include ftp and sendmail.

Verify console settings
In the file /etc/default/login, ensure that the value for CONSOLE is set to /dev/console, allowing root logins only from the physical console. Solaris should make /dev/console the default, but it needs to be checked.

Use Journaling file systems
In the file /etc/vfstab, add the mount option logging on all mountable local file-systems. In case of a crash, use of a journaled file-system will minimize the corruption; very important for log files.

Install the patches
SUN comes out with a new recommended patch cluster about twice a month. In general, these should be installed as soon as possible after they come out. This is a task that never ends.

When performing the first patch install, the patches should come from a CDROM, or a tape because your network connection is still not connected; an important consideration, as Solaris (as delivered) is not well configured for security.

Prev Index Next

If you have any comments or suggestions, please E-mail

© 2004 - Ashford Computer Consulting Service