Solaris 10 Hardening

Securing a Solaris 10 08/07 Operating System

Umakanta Samantaray
usamantaray@gmail.com
D-22nd Sep 2008

About this document:

This document provides recommended security settings for systems running the Solaris 10 8/07 operating systems. While many of the controls discussed in this document were available in earlier versions of the Solaris OS, some of the functionality discussed may not be present in those older versions.

OS Platform

The recommendations and actions described in this document are based upon a complete Solaris OS installation using the SUNWCXall “Entire Distribution Plus OEM” software installation cluster. Therefore, some actions may not apply to systems that have been installed with other installation clusters or fewer software packages.

System State

It is recommended that all actions be applied when the system is in a “quiet” state – one in which application and third party software and services are not active. Hardening services used by applications while they are active could have unpredictable results.

Test Actions

It is strongly recommended that all actions be first executed on a test or non-critical system before being performed on a production server. While the actions described in this document have been tested, there is no way to predict with certainty how they will affect a given environment.

Shell Environment

The actions listed in this document are written with the assumption that they will be executed by the root user running the /sbin/sh shell and without noclobber set.

Order of Operations

The actions listed in this document are written with the assumption that they will be executed in the order presented here. Some actions may need to be modified if the order is changed. Actions are written so that they may be copied directly from this document into a root shell window with a "cut-and-paste" operation.

Backup Key Files

Before performing the steps of this benchmark it is strongly recommended that administrators make backup copies of critical configuration files that may get modified by various benchmark items. If this step is not performed, then the site may have no reasonable back-out strategy for reversing system modifications made as a result of this document. You may want to consider performing a complete system backup to ensure that nothing is missed.

MAC Address
IP Address
Machine Name
Administrator Name
Date

Operating System Details:

Gather all the information about the Existing Operating System by executing the following commands as root user:

# uname -a

# cat /etc/release

# prtconf | grep “Mem”

# ifconfig –a

# format

# df –h (use df –k for Solaris 8 and below)

# cat /etc/vfstab

# cat /etc/system

# prtdiag –v

# svcs –a

# inetadm

Please install the following packages as root user which can be found on the Solaris 10 installation DVD:

SUNWi1cs
SUNWi15cs

If RAID is used, execute the following commands:
# metadb
# metastat –p
# metastat
# raidctl


Install latest patches and collect explorer output.

Restrict Services

While applying system patches helps correct known vulnerabilities, one of the best ways to protect the system against as yet unreported vulnerabilities is to disable all services that are not required for normal system operation. This prevents the exploitation of vulnerabilities discovered at a later date. If a service is not enabled, it cannot be exploited. The actions in this section of the document provide guidance on what services can be safely disabled and under which circumstances, greatly reducing the number of possible threats to the resulting system.

Disable Unnecessary Local Services

In Solaris 10 OS, several services are not disabled, however, but rather are placed into a 'local only' mode where they will accept connections only if they originate from the local system itself. This was done to strike a balance between security and also out of the box functionality for ease of use. If these services are not required, it is recommended they be disabled to guard against potential exploit by users and services that are operating locally on the system.

Disable Local CDE ToolTalk Database Server

Action:

svcadm disable svc:/network/rpc/cde-ttdbserver:tcp

Notes:

The ToolTalk service enables independent CDE applications to communicate with each other without having direct knowledge of each other. Applications create and send ToolTalk messages to communicate with each other. The ToolTalk service receives these messages, determines the recipients, and then delivers the messages to the appropriate applications. Unless your organization is specifically using the Tool Talk service, disable it.

Disable Local CDE Calendar Manager

Action:

svcadm disable svc:/network/rpc/cde-calendar-manager

Notes:

CDE Calendar Manager is an appointment and resource scheduling tool. CDE Calendar Manager can help you schedule and keep track of your daily appointments. Upon request, Calendar Manager can send you reminders in advance of your appointments.
If you place the Calendar manager in local only mode, users on other computers will not be able to attach to the system calendar manager and look at the user’s calendar. Unless your organization is specifically using the CDE Calendar Manager service, it can be disabled.


Disable Local sendmail Service

Action:

svcadm disable svc:/network/smtp:sendmail

Notes:

If sendmail is set to local only mode, users on remote systems cannot connect to the sendmail daemon. This eliminates the possibility of a remote exploit attack against sendmail. Leaving sendmail in local-only mode permits mail to be sent out from the local system. If the local system will not be processing or sending any mail, then the sendmail service should be completely disabled. If you disable sendmail for local use, messages sent to the root account, such as for cron job output or audit daemon warnings, will fail to be delivered properly. Another solution often used is to disable sendmail’s local-only mode and to have a cron job process all mail that is queued on the local system and send it to a relay host that is defined in the sendmail.cf file.

Disable Local BSD Print Protocol Adapter

Action:

svcadm disable svc:/application/print/rfc1179:default

Notes:

The service is used to control local Berkeley system based print spooling. It listens on port 515 for incoming print jobs. Secure by default limits access to the line printers by only allowing print jobs to be initiated from the local system. If the machine does have locally attached printers, the service should be disabled. Note that this service is not required
for printing to a network printer.

Disable RPC Encryption Key

Action:

svcadm disable svc:/network/rpc/keyserv:default

Notes:

The keyserv process is only required for sites that are using Sun's secure RPC mechanism. The most common uses for secure RPC on Solaris machines are NIS+ and "secure NFS", which uses the secure RPC mechanism to provide higher levels of security than the standard NFS protocols. Note that "secure NFS" here should not be confused with sites that use Kerberos authentication as a mechanism for providing higher levels of NFS security. "Kerberized" NFS does not require the keyserv
process to be running.

Disable NIS Server Daemons

Action:

svcadm disable svc:/network/nis/server:default
svcadm disable svc:/network/nis/passwd:default
svcadm disable svc:/network/nis/update:default
svcadm disable svc:/network/nis/xfr:default

Notes:

These daemons are only required on systems that are acting as an NIS server for the local site. Typically there are only a small number of NIS servers on any given network.

Disable NIS Client Daemons

Action:

svcadm disable svc:/network/nis/client:default

Notes:

If the local site is not using the NIS naming service to distribute system and user configuration information, this service may be disabled.

Disable NIS+ daemons

Action:

svcadm disable svc:/network/rpc/nisplus:default

Notes:

NIS+ was designed to be a more secure version of NIS. However, the use of NIS+ has been deprecated by Sun and customers are encouraged to use LDAP as an alternative naming service.

Disable LDAP Cache Manager

Action:

svcadm disable svc:/network/ldap/client:default

Notes:

If the local site is not currently using LDAP as a naming service, there is no need to keep LDAP-related daemons running on the local machine.

Disable Kerberos TGT Expiration Warning

Action:

svcadm disable svc:/network/security/ktkt_warn:default

Notes:


While Kerberos can be a security enhancement, if the local site is not currently using Kerberos then there is no need to enable this service.
Disable Generic Security Services (GSS) daemons

Action:

svcadm disable svc:/network/rpc/gss:default

Notes:

The GSS API is a security abstraction layer that is designed to make it easier for developers to integrate with different authentication schemes. It is most commonly used in applications for sites that use Kerberos for network authentication, though it can also allow applications to interoperate with other authentication schemes. Note that since this service uses Sun's standard RPC mechanism, it is important that the system's RPC portmapper (rpcbind) also be enabled when this service is turned on. This daemon will be taken offline if rpcbind is disabled. Note that GSS does not expose anything external to the system as it is configured to use TLI (protocol = ticotsord) by default.

Disable automount daemon

Action:

svcadm disable svc:/system/filesystem/autofs:default

Notes:

The automount daemon is normally used to automatically mount NFS file systems from remote file servers when needed. However, the automount daemon can also be configured to mount local (loopback) file systems as well, which may include local user home directories, depending on the system configuration. Sites that have local home directories configured via the automount daemon in this fashion will need to ensure that this daemon is running for Sun’s Solaris Management Console administrative interface to function properly. If the automount daemon is not running, the mount points created by SMC will not be mounted. If there is no need to use automount, this can be disabled. Note that since this service uses Sun's standard RPC mechanism, it is important that the system's RPC portmapper (rpcbind) also be enabled when this service is turned on.

Enable Stack Protection

Action:

if [ ! "`grep noexec_user_stack /etc/system`" ]; then
cat <>/etc/system
* Attempt to prevent and log stack-smashing attacks
set noexec_user_stack = 1
set noexec_user_stack_log = 1
END_CFG
fi

Notes:

Buffer overflow exploits have been the basis for many of the recent highly publicized compromises and defacements of large numbers of Internet connected systems. Many of the



automated tools in use by system crackers exploit well-known buffer overflow problems in vendor-supplied and third-party software. Enabling stack protection prevents certain classes
of buffer overflow attacks and is a significant security enhancement. However, this does not protect against buffer overflow attacks that do not execute code on the stack (such as return-to-libc exploits).

Enable Strong TCP Sequence Number Generation

Action:

cd /etc/default
awk '/TCP_STRONG_ISS=/ { $1 = "TCP_STRONG_ISS=2" }; \
{ print }' inetinit > inetinit.new
mv inetinit.new inetinit
pkgchk -f -n -p /etc/default/inetinit

Notes:

The variable TCP_STRONG_ISS sets the mechanism for generating the order of TCP
packets. If an attacker can predict the next sequence number, it is possible to inject
fraudulent packets into the data stream to hijack the session. Solaris supports three
sequence number methods:

# 0 = Old-fashioned sequential initial sequence number generation.
# 1 = Improved sequential generation, with random variance in increment.
# 2 = RFC 1948 sequence number generation, unique-per-connection-ID.
The RFC 1948 method is widely accepted as the strongest mechanism for TCP packet
generation. This makes remote session hijacking attacks more difficult, as well as any
other network-based attack that relies on predicting TCP sequence number information.
It is theoretically possible that there may be a small performance hit in connection setup
time when this setting is used, but there are no benchmarks that establish this.

Disable Network Routing

Action:

routeadm -d ipv4-forwarding -d ipv6-forwarding
routeadm -d ipv4-routing -d ipv6-routing
routeadm -u

Notes:

Routing (in.routed) is disabled by default in all Solaris 10 systems, if there is a default router defined. If no default gateway is defined during system installation, network routing is enabled. This action is unnecessary unless it was manually enabled by the administrator or the system was previously used as a network gateway.

Enable inetd Connection Logging

Action:

inetadm -M tcp_trace=true

Notes:



If inetd is running, the "tracing" feature can be used to log information about the source of any network connections seen by the daemon. Rather than enabling inetd tracing for all services with "inetadm -M …", the administrator has the option of enabling tracing for individual

services with "inetadm -m tcp_trace=TRUE", where is the name of the specific service that should use tracing.

This information is logged via syslogd (1M) and is deposited by default in /var/adm/messages with other system log messages. If the administrator wants to capture this information in a separate file, simply modify /etc/syslog.conf to log daemon.notice to some other log file destination.


Enable FTP daemon Logging

inetadm -m svc:/network/ftp \
exec="/usr/sbin/in.ftpd -a -l -d"

Notes:

If the FTP daemon is enabled, it is recommended that the "debugging" (-d) and connection logging (-l) flags also be enabled to track FTP activity on the system. Note that enabling debugging on the FTP daemon can cause user passwords to appear in clear-text form in the system logs, if users accidentally type their passwords at the username prompt.
Information about FTP sessions will be logged via syslogd (1M), but the system must be configured to capture these messages.

Capture syslog AUTH Messages

Action:

Create a file with the correct permissions to hold the logging information. Create the authlog file in the /var/adm directory.

touch /var/adm/authlog

Set read-and-write permissions for root user on the authlog file.

chmod 600 /var/adm/authlog

Change group membership to sys on the authlog file.

chgrp sys /var/adm/authlog

Edit the syslog.conf file to log failed password attempts. The failures should be sent to the authlog file.

Type the following entry into the syslog.conf file.

Fields on the same line in syslog.conf are separated by tabs.

auth.notice /var/adm/authlog

Refresh the configuration information for the syslog daemon.


svcadm refresh system/system-log

Notes:

By default, Solaris systems do not capture logging information that is sent to the LOG_AUTH facility. However, a great deal of important security-related information is sent via this channel (e.g., successful and failed su attempts, failed login attempts, root login attempts, etc.). The above action causes this information to be captured in the /var/log/authlog file (which is only readable by the superuser.

Enable Login Records

Action:

touch /var/adm/loginlog
chown root:sys /var/adm/loginlog
chmod 600 /var/adm/loginlog
logadm -w loginlog -C 13 /var/adm/loginlog


Notes:

If the file /var/adm/loginlog exists, it will capture failed login attempt messages. This file does not exist by default and must be manually created as described in the action. The loginlog file should be reviewed on a regular basis.

Capture All Failed Login Attempts

Action:

cd /etc/default
awk '/SYSLOG_FAILED_LOGINS=/ \
{ $1 = "SYSLOG_FAILED_LOGINS=0" }; \
{ print }' login >login.new
mv login.new login
pkgchk -f -n -p /etc/default/login

Notes:

The SYSLOG_FAILED_LOGINS parameter in /etc/default/login is used to control how many login failures are allowed before log messages are generated—if set to zero then all failed logins will be logged.


Enable cron Logging

Action:

cd /etc/default

awk '/CRONLOG=/ { $1 = "CRONLOG=YES" }; \
{ print }' cron > cron.new



mv cron.new cron

pkgchk -f -n -p /etc/default/cron

chown root:root /var/cron/log

chmod go-rwx /var/cron/log

Notes:

Setting the CRONLOG parameter to YES in /etc/default/cron causes information to be logged for every cron job that gets executed on the system. This setting is the default for Solaris. Log data can be found in /var/cron/log and this file should be reviewed on a regular basis.

File/Directory Permissions/Access

File and directory permission control is one of the greatest challenges of secure system administration. The system administrator can and should monitor and secure permissions on system files and directories, but has little control over user-owned files and directories. This section provides guidance on how to secure system files and directories, set secure
defaults for users and monitor file permissions.

Set daemon umask

Action:

cd /etc/default
awk '/^CMASK=/ { $1 = "CMASK=022" }
{ print }' init >init.new
mv init.new init
pkgchk -f -n -p /etc/default/init

Notes:

The system default umask should be set to at least 022 in order to prevent daemon processes from creating world-writable files by default. The NSA and DISA recommend a more restrictive umask values of 077. This may cause problems for certain applications—consult vendor documentation for further information. The default setting for Solaris is 022.

Note that there are some known bugs in the following daemons:

6299083 picld initialises picld_door file with wrong permissions after JASS

4791006 ldap_cachemgr initialises ldap_cache_door file with wrong permissions
6299080 nscd initialises name_service_door file with wrong permissions

Verify System File Permissions

Action:

It is recommended that all packages on the system be checked by executing the
following command:

pkgchk –n


Notes:
This action will check the default owners and access permissions for all system
packages and their associated files as well as the file contents. If the files are not in
compliance, an error message similar to the following will be displayed:


ERROR: /etc/shadow
group name expected actual

To force the default setting, use the “-f” option as follows:

pkgchk -f -n -p /etc/shadow

Depending on the number of packages installed on the system, this command could take a long time to run and generate a lot of output to standard error. Not all of the errors generated reflect actual problems. You may want to save the output to a file for later review. You can also create a custom script to verify the integrity of critical files, such as the following:

pkgchk -n -p /etc/passwd
pkgchk -n -p /etc/shadow

Disable "nobody" Access for RPC Encryption Key Storage Service

Action:

cd /etc/default
awk '/ENABLE_NOBODY_KEYS=/ \
{ $1 = "ENABLE_NOBODY_KEYS=NO" }

{ print }' keyserv >keyserv.new
mv keyserv.new keyserv
pkgchk -f -n -p /etc/default/keyserv

Notes:

The keyserv process stores user keys that are utilized with Sun's secure RPC mechanism. The above action prevents keyserv from using default keys for the "nobody" user, effectively stopping this user from accessing information via secure RPC.

Restrict root Login to System Console

Action:

cd /etc/default
awk '/CONSOLE=/ { print "CONSOLE=/dev/console"; next }; \
{ print }' login >login.new
mv login.new login
pkgchk -f -n -p /etc/default/login

Notes:

Anonymous root logins should never be allowed, except on the system console in
emergency situations. This is the default configuration for Solaris. At all other times,
the administrator should access the system via an unprivileged account and use some

authorized mechanism (such as the su command, or the freely-available sudo
package) to gain additional privilege. These mechanisms provide at least some limited
audit trail in the event of problems. Note that in addition to the configuration steps included here, there may be other login services (such as SSH) that require additional configuration in order to prevent root logins via these services.



Change Home Directory for root Account

Action:

mkdir /root

passmgmt –m –h /root root
chmod 700 /root



Notes:

Changing the home directory for the root account provides segregation from the OS distribution and activities performed by the root user. A further benefit is that the root home directory can have more restricted permissions, preventing viewing of the root system account files by non-root users. Note that if the user logs into GNOME, the directories “Desktop” and “Documents” will also be created under “/”. If these exist, they should be moved into /root/.

Verify No UID 0 Accounts Exist Other than root

Action:

Run the following command and verify that only the word “root” is returned:

logins -o | awk -F: '($2 == 0) { print $1 }'

Notes:

Any account with UID 0 has superuser privileges on the system. The only superuser account on the machine should be the default root account, and it should be accessed by logging in as an unprivileged user and using the su command to gain additional privilege.

Set Default Group for root Account

Action:

passmgmt -m -g 0 root

Notes:

For Solaris 9 and earlier, the default group for the root account under Solaris is the "other" group, which may be shared by many other accounts on the system. Solaris 10 has adopted GID 0 (group "root") as default group for the root account to help prevent root-owned files accidentally becoming accessible to non-privileged users.



Check Permissions on User Home Directories

Action:

for dir in `logins -ox | \
awk -F: '($8 == "PS" && $1 != "root") { print $6 }'`
do
dirperm=`ls -ld $dir | cut -f1 -d" "`
if [ `echo $dirperm | cut -c6 ` != "-" ]
then
echo "Group Write permission set on directory $dir"
fi
if [ `echo $dirperm | cut -c8 ` != "-" ]
then
echo "Other Read permission set on directory $dir"
fi
if [ `echo $dirperm | cut -c9 ` != "-" ]


then
echo "Other Write permission set on directory $dir"
fi
if [ `echo $dirperm | cut -c10 ` != "-" ]
then
echo "Other Execute permission set on directory $dir"
fi
done

Notes:

Group or world-writable user home directories may enable malicious users to steal or modify other users' data or to gain another user's system privileges. Making global modifications to user home directories without alerting your user community can result in unexpected outages and unhappy users. Therefore, it is recommended that a monitoring policy be established to report user file permissions and determine the action to be taken in accordance with site policy.

Check User Dot File Permissions

Action:

for dir in `logins -ox | \
awk -F: '($8 == "PS") { print $6 }'`
do
for file in $dir/.[A-Za-z0-9]*; do
if [ ! -h "$file" -a -f "$file" ]; then
fileperm=`ls -ld $file | cut -f1 -d" "`
if [ `echo $fileperm | cut -c6 ` != "-" ]
then
echo "Group Write permission set on file $file"
fi
if [ `echo $fileperm | cut -c9 ` != "-" ]
then
echo "Other Write permission set on file $file"
fi
fi
done
done

Notes:

Group or world-writable user configuration files may enable malicious users to steal or
modify other users' data or to gain another user's system privileges. Making global
modifications to user home directories without alerting your user community can result
in unexpected outages and unhappy users. Therefore, it is recommended that a
monitoring policy be established to report user dot file permissions and determine the
action to be taken in accordance with site policy.


Check Permissions on User .netrc Files

Action:

for dir in `logins -ox | \
awk -F: '($8 == "PS") { print $6 }'`
do
for file in $dir/.netrc; do
if [ ! -h "$file" -a -f "$file" ]; then
fileperm=`ls -ld $file | cut -f1 -d" "`
if [ `echo $fileperm | cut -c5 ` != "-" ]
then
echo "Group Read permission set on directory $file"
fi
if [ `echo $fileperm | cut -c6 ` != "-" ]
then
echo "Group Write permission set on directory $file"
fi
if [ `echo $fileperm | cut -c7 ` != "-" ]
then
echo "Group Execute permission set on directory $file"
fi
if [ `echo $fileperm | cut -c8 ` != "-" ]
then
echo "Other Read permission set on directory $file"
fi
if [ `echo $fileperm | cut -c9 ` != "-" ]
then
echo "Other Write permission set on directory $file"
fi
if [ `echo $fileperm | cut -c10 ` != "-" ]
then
echo "Other Execute permission set on directory $file"
fi
fi
done
done

Notes:

.netrc files may contain unencrypted passwords which may be used to attack other
systems. Making global modifications to user home directories without alerting your
user community can result in unexpected outages and unhappy users. Therefore, it is
recommended that a monitoring policy be established to report user .netrc file
permissions and determine the action to be taken in accordance with site policy.


Check for Presence of User .rhosts Files

Action:

for dir in `logins -ox | \
awk -F: '($8 == "PS") { print $6 }'`
do
for file in $dir/.rhosts; do
if [ ! -h "$file" -a -f "$file" ]; then
echo “.rhosts file in $dir”
fi
done
done

Notes:

This action is only meaningful if .rhosts support is permitted in the file /etc/pam.conf.

Set Default umask for Users

Notes:

With a default umask setting of 077, files and directories created by users will not be
readable by any other user on the system. The user creating the file has the discretion
of making their files and directories readable by others via the chmod command.
Users who wish to allow their files and directories to be readable by others by default
may choose a different default umask by inserting the umask command into the
standard shell configuration files (.profile, .cshrc, etc.) in their home directories.
A umask of 027 would make files and directories readable by users in the same Unix
group, while a umask of 022 would make files readable by every user on the system.

Set Default umask for ftp Users

Action:

cd /etc/ftpd
if [ "`grep '^defumask' ftpaccess`" ]; then
awk '/^defumask/ { $2 = "077" }
{ print }' ftpaccess >ftpaccess.new
mv ftpaccess.new ftpaccess
else
echo defumask 077 >>ftpaccess
fi
pkgchk -f -n -p /etc/ftpd/ftpaccess

Warning Banners

Presenting some sort of statutory warning message prior to the normal user logon may assist the prosecution of trespassers on the computer system. Changing some of these login banners also has the side effect of hiding OS version information and other detailed system information from attackers attempting to target specific attacks at a system.


Create Warnings for Standard Login Services

Action:

echo "Authorized uses only. All activity may be \
monitored and reported." >/etc/motd
echo "Authorized uses only. All activity may be \
monitored and reported." >/etc/issue
pkgchk -f -n -p /etc/motd
chown root:root /etc/issue
chmod 644 /etc/issue

Notes:


The contents of the /etc/issue file are displayed prior to the login prompt on the system's console and serial devices, and also prior to logins via telnet. /etc/motd is generally displayed after all successful logins, no matter where the user is logging in from, but is thought to be less useful because it only provides notification to the user after the machine has been accessed.

Create Warning Banner for FTP daemon

Action:

echo Authorized uses only. All activity may \
be monitored and reported. >/etc/ftpd/banner.msg
chown root:root /etc/ftpd/banner.msg
chmod 444 /etc/ftpd/banner.msg

Notes:

The contents of the /etc/ftpd/banner.msg file are sent to clients before they log in.

Create Power On Warning

Action:

eeprom oem-banner="Authorized uses only. All activity \
may be monitored and reported."
eeprom oem-banner\?=true

Notes:

The OEM banner will be displayed only when the system is powered on. Setting this
banner has the side effect of hiding the standard Sun power-on banner, which normally
displays the system host ID, MAC address, etc.


Ensure the System Does not act as a Router

Action:

touch /etc/notrouter
chown root:sys /etc/notrouter
chmod 444 /etc/notrouter

Notes:

The server will not act as a router.

Configure Unique MAC Addresses

Action:

eeprom local-mac-address?=true

Notes:

Solaris assigns the same MAC address to all the NIC’s by default. This configuration has the potential to cause problems (i.e., collisions ). By executing this command you can avoid this problem.

Disable Telnet Services

Action:

svcadm disable telnet

Notes:

Telnet pass user ID’s and passwords “in the clear text”. This sensitive information can be picked up by a sniffer. In order to provide the secure connections (SSH) by encrypting the information in the network, this service to be disabled.

Disable Ftp Services

Action:

svcadm disable ftp

Notes:

Ftp pass user ID’s and passwords “in the clear text”. This sensitive information can be picked up by a sniffer. In order to provide the secure connections (SSH) by encrypting the information in the network, this service to be disabled.


Permit Root Login For SSH

Action:

vi /etc/ssh/sshd_config



PermitRootLogin yes
:wq!

Notes:

In order to permit root user login through SSH, change the PermitRootLogin parameter in /etc/ssh/sshd_cofnig to yes.

Disable Keyboard Abort sequence

Action:

vi /etc/default/kbd

#KEYBOARD_ABORT=disable

kbd -i

Notes:

Uncomment the KEYBOARD_ABORT line /etc/default/kbd to disable keyboard or serial device abort sequences.

Configure the Server as NTP Client

Action:

cp /etc/inet/ntp.client /etc/inet/ntp.conf

vi /etc/inet/ntp.client

#server 172.17.10.5 prefer
#server 172.17.10.3
server 172.17.12.30
driftfile /etc/ntp.drift
#tracefile /etc/ntp.trace
:wq!

touch /etc/ntp.drift
echo “0.0” > /etc/ntp.drift

svcadm enable ntp

Notes:
Configures the system as NTP Client, Which synchronizes the system time with the NTP server’s time.


Configure the System to send log’s to Centralized Server

Action:

# vi /etc/syslog.conf
#ident "@(#)syslog.conf 1.5 98/12/14 SMI" /* SunOS 5.0 */
# Copyright (c) 1991-1998 by Sun Microsystems, Inc.
# All rights reserved.
# syslog configuration file.
# This file is processed by m4 so be careful to quote (`') names
# that match m4 reserved words. Also, within ifdef's, arguments
# containing commas must be quoted.
*.err;kern.notice;auth.notice /dev/sysmsg
*.err;kern.debug;daemon.notice;mail.crit /var/adm/messages

*.alert;kern.err;daemon.err operator
*.alert root

*.emerg *

# if a non-loghost machine chooses to have authentication messages
# sent to the loghost machine, un-comment out the following line:
auth.notice ifdef(`LOGHOST', /var/log/authlog, @loghost)

mail.debug ifdef(`LOGHOST', /var/log/syslog, @loghost)

#
# non-loghost machines will use the following lines to cause "user"
# log messages to be logged locally.
#
ifdef(`LOGHOST', ,
user.err /dev/sysmsg
user.err /var/adm/messages
user.alert `root, operator'
user.emerg *
)
user.err @cbssysmon
auth.notice @cbssysmon
auth.notice /var/adm/loginlog
user.err @newsyslogmon
auth.notice @newsyslogmon


:wq!

svcadm refresh system-log

Notes:

Added the line in marked in blue to /etc/syslog.conf file which sends the corresponding log’s to the respective syslog server.


Configure the password policy

After editing /etc/default/passwd file, the file appears as follows:

After editing /etc/default/policy.conf, the file appears as follows:

Root Logins are permitted for root users logging using SSH protocol. The file appears as follows: