Securing access to a Solaris system

Published   Read time 3 min(s) 12 sec(s)   (2667 views).  Security  

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 /etc/default/login.

# 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 sshd.config and ssh.config to disable root access:

  • sshd.config 
    Permit root login no
Permit empty password no
Allow hosts
Allow users
  • ssh.config 
    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

.rhosts, .netrc and 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.