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.
