Securing access to a Solaris system
This document details some of the focus areas for security and provides suggestions to make it strong.
Limit Root Access
Limit direct root access by making sure the console entry exists and is not commented out in the file
# grep CONSOLE /etc/default/login CONSOLE=/dev/console
Then, even if you know the root password it will only let you login as root on the machine´'s keyboard, or via a serial line line connected directly to the machine.
Restricting su usage
To restrict the people who can
su to root, create the
wheel group in
/etc/group and add your admins to it, (it's a comma separated list). For example:
# grep wheel /etc/group wheel::11:jdoe,janed,fbar
Then issue the following commands to restrict
su to that group
# chgrp wheel /usr/bin/su # chmod 4750 /usr/bin/su
This will mean that only the people in the wheel group can
su to root.
You can check for other people trying to
su to root with the help of the following,
/etc/default/su contains the config file for
su, (for details of the file use the man su command) this will tell you where the logfile of attempts is made and if attempts are logged to syslog or not.
You may also want to change
/sbin/su.static also. This is the same command as
su but compiled with static libraries.
# chgrp wheel /sbin/su.static # chmod 0550 /sbin/su.static
You may want to look at
sudo as it allows you to give certain access to users or groups without giving root access. And it keeps a log.
Using secure shell (ssh)
If secure shell is being used to access the systems edit
ssh.config to disable root access:
Permit root login no Permit empty password no Allow hosts Allow users
Forward x11 no Password authentication no
Host based authentication is more secure as it is based on private keys and public keys and only user with the keys are allowed to connect . Password authentication is less secure as they can be guessed or cracked by some programs.
Remote Access files
hosts.equiv are the files that provides access to the remote systems and should be monitored carefully. They should be checked regularly for any unauthorized entry or if not needed can be made with zero permission. This will not allow creation of new file by the same name and put entries to gain access.
Keep access log
sulog file gives information about
su login attempts to the system similarly a login log file can be created by touching
/etc/loginlog which keeps all the login information . Besides
last command also give useful information about the persons accessing the system.
The sysadmin group
A user account that is a member of the
sysadmin group can perform a selection of system administration functions using
admintool without being granted full superuser privileges. As a result, more than one person can perform basic system administration (user admin, printer admin, software installation) without compromising system security.
Restrict SUID/SGID System Executables
Whenever SUID permission are set on executable files, anyone executing that command (file) will inherit the permissions of the owner of the file.
The SGID permission is similar to the SUID, except that the process's effective group ID (GID) is changed to the group owner of the file, and a user is granted access based on permissions assigned to that group.
There are valid reasons for SUID/SGID programs, but it is important to identify and review such programs to ensure they are legitimate.
A simple method of find such files is with the
find command. For example:
# find / -prune -type f \( -perm -4000 -o -perm -2000 \) -print
Read my post Special file permissions for a more overview on SUID/SGID.