|
Date |
Author |
Comments |
|
08 December 1999 |
R. Davies |
Original Draft |
This document is to be used as a guide for the configuration of the Solaris operating system in order to meet a specific security stance. The guiding principle for the security stance is all that is not explicitly allowed is absolutely denied.
This document covers configuration of the Solaris 2.6 HW 5/98 operating system running on SPARC systems. It does not deal with third party software or layered applications. When a system requires a service to be implemented that is the exception, it is indicated. This document does not cover the configuration of security parameters that are set by default in the operating system, as they will not be modified from the default secure stance they provide. The configuration of ‘ssh’ is beyond the scope of this document. This document is not the comprehensive discussion of all the Solaris exploits possible.
To control access to a system, staff must maintain the physical security of the computer environment. For instance, if a system is logged in and left unattended, anyone who can use that system can gain access to the operating system and the network.
The latest recommended security patches for Solaris 2.6 will be installed and are available from;
http://online.sunsolve.sun.co.uk
A number of security bugs are related to default executable stacks when their permissions are set to read, write and execute. While stacks with execute permissions set are mandated by the SPARC ABI and Intel ABI, most programs can function correctly without using executable stacks. The noexec_user_stack variable is available in the Solaris 2.6 release which enables the system administrator to specify whether stack mappings are executable or not. By default, the variable is zero, which provides ABI-compliant behavior. If the variable is set to non-zero, the system will mark the stack of every process in the system as readable and writable, but not executable. Once this variable is set, programs that attempt to execute code on their stack will be sent a SIGSEGV signal, which usually results in the program terminating with a core dump. Such programs also generate a warning message that includes the name of the offending program, the process ID, and real UID of the user who ran the program. For example:
a.out[347] attempt to execute code on stack by uid 555
The message is logged by the syslogd(1m) daemon when the syslog kern facility is set to notice level. This logging is set by default in the syslog.conf(4) file, which means the message is sent to both the console and to the /var/adm/messages file. This message is useful both for observing potential security problems, as well as to identify valid programs that depend upon executable stacks which have been prevented from correct operation by setting this variable. You can use mprotect(2) if you want programs to explicitly mark their as stack executable.
To disable programs from using executable stacks
Become superuser.
Edit the /etc/system file and add the following line:
set noexec_user_stack=1
Reboot the system
# init 6
Comment out ALL services in inetd.conf except FTP and telnet. The TCP wrappers can be used to protect the systems from telnet and FTP based exploits. Likewise, SSH can be installed to provide a secure tunnel for X11, telnet and FTP sessions.
The X windowing capabilities of the operating system should be disabled. This is done by changing S99dtlogin in /etc/rc2.d. to noS99dtlogin. The cluster workstations and the clusters themselves will be allowed to run X to support the management of the cluster and Veritas Volume Manager. The X11 traffic will be secure when run within the SSH environment. In the event that any other systems require X capabilities, the S99dtlogin script can be enabled.
The following startup scripts in /etc/rc2.d will be changed from Sxx<script name> to Nxx<script name>. Please note, this does not remove the binaries, it merely stops them from automatically starting when the system boots.
S15nfs.server (exception: jumpstart servers)
S21perf
S47asppp
S70uucp
S71rpc (exception: Cluster servers and workstations)
S73cachefs.daemon
S73nfs.client (exception: WWW/FTP servers)
S74autofs
S74xntp
S76nscd
S76snmpdx
S77dmi
S80lp
S80spc
S85power
S88sendmail
S89bdconfig
S91leoconfig
S91afbinit
S91agaconfig
S92rtvc-config
S92volmgt
S93cacheos.finish
S99audit
S99dtlogin
There is no requirement for any system to route from one interface to another, and the ability to do so can impose a security risk into the platform. All systems should have routing disabled.
To disable routing touch /etc/notrouter
It is important to set the path variable correctly; otherwise, a user may accidentally run a program introduced by someone else that harms the data or the system. This kind of program, which creates a security hazard, is referred to as a "Trojan horse." For example, a substitute su program could be placed in a public directory where the system administrator might run it. Such a script would look just like the regular su command; since it removes itself after execution, it is hard to tell that the user has actually run a Trojan horse. The path variable is automatically set at login time through the startup files: .login, .profile, and .cshrc. Setting up the user search path so that the current directory (.) comes last prevents the users from running this type of Trojan horse. The path variable for superuser should not include the current directory at all. The ASET utility examines the startup files to ensure that the path variable is set up correctly and that it does not contain a dot (.) entry.
Root shall have a umask setting of 077 or 027 and have a safe search path, as in /usr/bin:/sbin:/usr/sbin that does not end with a `.`
Many executable programs have to be run as root (that is, as superuser) to work properly. These executables run with the user ID set to 0 (setuid=0). Anyone running these programs runs them with the root ID, which creates a potential security problem if the programs are not written with security in mind. After all applications are loaded on the system ASET will be run, which logs the files that are setuid to root. Regular inspection of the ASET logs will ensure this risk is managed correctly.
Solaris system software includes the Automated Security Enhancement Tool (ASET). ASET helps you monitor and control system security by automatically performing tasks that you would otherwise do manually. The ASET security package provides automated administration tools that enable you to control and monitor your system's security. You specify a security level-low, medium, or high-at which ASET will run. At each higher level, ASET's file-control functions increase to reduce file access and tighten your system security.
There are seven tasks involved with ASET, each performing specific checks and adjustments to system files. The ASET tasks tighten file permissions, check the contents of critical system files for security weaknesses, and monitor crucial areas. ASET can safeguard a network by applying the basic requirements of a firewall system to a system that serves as a gateway system.
ASET uses master files for configuration. Master files, reports, and other ASET files are in the /usr/aset directory. These files can be changed to suit the particular requirements of your site. Each task generates a report noting detected security weaknesses and changes the task has made to the system files. When run at the highest security level, ASET will attempt to modify all system security weaknesses. If it cannot correct a potential security problem, ASET reports the existence of the problem. You can initiate an ASET session by using the /usr/aset command interactively, or you can also set up ASET to run periodically by putting an entry into the crontab file.
To Run ASET Periodically;
Become superuser.
If necessary, set up the time when you want ASET to run periodically.
You should have ASET run when system demand is light. The PERIODIC_SCHEDULE environment variable in the /usr/aset/asetenv file is used to set up the time for ASET to run periodically. By default, the time is set for midnight every 24 hours. If you want to set up a different time, edit the PERIODIC_SCHEDULE variable in the /usr/aset/asetenv file. See PERIODIC_SCHEDULE Variable for detailed information about setting the PERIODIC_SCHEDULE variable.
Add an entry to the crontab file using the aset command.
# /usr/aset/aset -p
-p Inserts a line in the crontab file that starts ASET running at the time determined by the PERIODIC_SCHEDULE environment variable in the /usr/aset/asetenv file.
Display the crontab entry to verify when ASET will run.
# crontab -l root
You can save failed login attempts by creating the /var/adm/loginlog file with read and write permission for root only. After you create the loginlog file, all failed login activity will be written to this file automatically after five failed attempts. The loginlog file contains one entry for each failed attempt. Each entry contains the user's login name, tty device, and time of the failed attempt. If a person makes fewer than five unsuccessful attempts, none of the attempts are logged.
How to Save Failed Login Attempts:
Become superuser.
Create the loginlog file in the /var/adm directory.
# touch /var/adm/loginlog
Set read and write permissions for root on the loginlog file.
# chmod 600 /var/adm/loginlog
Change group membership to sys on the loginlog file.
# chgrp sys /var/adm/loginlog
Make sure the log works by attempting to log into the system five times with the wrong password after the loginlog file is created. Then display the /var/adm/loginlog file.
# more /var/adm/loginlog
pmorph:/dev/pts/0:Fri Jan 13 08:55:23 1996
pmorph:/dev/pts/0:Fri Jan 13 08:55:31 1996
pmorph:/dev/pts/0:Fri Jan 13 08:55:39 1996
pmorph:/dev/pts/0:Fri Jan 13 08:55:50 1996
pmorph:/dev/pts/0:Fri Jan 13 08:56:00 1996
To display superuser (root) access attempts to the console:
Become superuser.
Edit the /etc/default/su file.
Uncomment the following line.
CONSOLE=/dev/console
Use the su command to become root, and verify that a message is printed on the system console.
You can start monitoring su attempts through the /etc/default/su file. Through this file, you can enable the /var/adm/sulog file to monitor each time the su command is used to change to another user. The sulog file lists all uses of the su command, not only those used to switch user to superuser. The entries show the date and time the command was entered, whether or not it was successful (+ or -), the port from which the command was issued, and finally, the name of the user and the switched identity.
To monitor who is using the su command:
Become superuser.
Edit the /etc/default/su file.
Uncomment the following line.
SULOG=/var/adm/sulog
After modifying the /etc/default/su file, use the su command several times and display the /var/adm/sulog file. You should see an entry for each time you used the su command.
# more /var/adm/sulog
SU 12/20 16:26 + pts/0 nathan-root
SU 12/21 10:59 + pts/0 nathan-root
SU 01/12 11:11 + pts/0 root-joebob
SU 01/12 14:56 + pts/0 pmorph-root
SU 01/12 14:57 + pts/0 pmorph-root
© 1999, Grenville Consulting Ltd.
© R. Davies. 1999, Grenville Consulting Ltd.