This chapter describes the procedures for securing systems in the Solaris environment.
This is a list of the step-by-step instructions in this chapter.
For overview information about securing systems, see System Security.
This section describes how to display user login information.
Display a user's login status by using the logins command.
# logins -x -l username |
-x |
Displays an extended set of login status information. |
-l username |
Displays the login status for the specified user. username is a user's login name. Multiple login names must be specified in a comma-separated list. |
The logins command uses the local /etc/passwd file and the name service password databases (if any) to obtain a user's login status. For more information, see the logins(1M) man page.
In the following example, the login status for the user rimmer is displayed.
# logins -x -l rimmer rimmer 500 staff 10 Arnold J. Rimmer /export/home/rimmer /bin/sh PS 010170 10 7 -1 |
You should make sure that all users have a valid password.
Become superuser or assume an equivalent role.
Display all users who have no passwords by using the logins command.
# logins -p |
The -p option displays a list of users with no passwords. The logins command uses the local /etc/passwd file and the name service password databases to obtain a user's login status.
The following example shows that the user pmorph does not have a password.
# logins -p pmorph 501 other 1 Polly Morph # |
You can temporarily disable user logins by doing either of the following:
Creating the /etc/nologin file.
Bringing the system to run level 0 (single-user mode). For information on bringing the system to single-user mode, see “Shutting Down a System (Tasks)” in System Administration Guide: Basic Administration.
Create this file to disallow user logins and notify users when a system will be unavailable for an extended period of time because of a system shutdown or routine maintenance.
If a user attempts to log in to a system where this file exists, the contents of the nologin file is displayed, and the user login is terminated. Superuser logins are not affected. For more information, see the nologin(4) man page.
Become superuser or assume an equivalent role.
Create the /etc/nologin file by using an editor.
# vi /etc/nologin |
Include a message about system availability.
Close and save the file.
This example shows how to notify users of system unavailability.
# vi /etc/nologin (Add system message here) # cat /etc/nologin ***No logins permitted.*** ***The system will be unavailable until 12 noon.*** |
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 automatically written to this file after five failed attempts. For detailed instructions, see How to Save Failed Login 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.
The loginlog file might grow quickly. To use the information in this file and to prevent the file from getting too large, you must check and clear its contents occasionally. If this file shows a lot of activity, it might suggest an attempt to break into the computer system. For more information about this file, see the loginlog(4) man page.
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 that the log works by attempting to log into the system five times with the wrong password. Then, display the /var/adm/loginlog file.
# more /var/adm/loginlog rimmer:/dev/pts/1:Wed Jan 16 09:22:31 2002 rimmer:/dev/pts/1:Wed Jan 16 09:22:39 2002 rimmer:/dev/pts/1:Wed Jan 16 09:22:45 2002 rimmer:/dev/pts/1:Wed Jan 16 09:22:53 2002 rimmer:/dev/pts/1:Wed Jan 16 09:23:01 2002 # |
You can add a layer of security to your password protection by requiring a dial-up password for users who access a system through a modem or dial-up port. A dial-up password is an additional password that a user must enter before being granted access to the system.
Only superuser can create or change a dial-up password. To ensure the integrity of the system, the password should be changed about once a month. The most effective use of this feature is to require a dial-up password to gain access to a gateway system.
Two files are involved in creating a dial-up password, /etc/dialups and /etc/d_passwd. The first file contains a list of ports that require a dial-up password. The second file contains a list of shell programs that require an encrypted password as the additional dial-up password.
If the user's login program (as specified in /etc/passwd) is not found in /etc/d_passwd, or if the login shell field in /etc/passwd is null, the password entry for /usr/bin/sh is used.
If the user's login shell in /etc/passwd matches an entry in /etc/d_passwd, the user must supply a dial-up password.
If the user's login shell in /etc/passwd is not found in /etc/d_passwd, the user must supply the default password. The default password is the entry for /usr/bin/sh.
If the login shell field in /etc/passwd is empty, the user must supply the default password (the entry for /usr/bin/sh).
If /etc/d_passwd has no entry for /usr/bin/sh, then those users whose login shell field in /etc/passwd is empty or does not match any entry in /etc/d_passwd will not be prompted for a dial-up password.
Dial-up logins are disabled if /etc/d_passwd has only the following entry: /usr/bin/sh:*:
When you first establish a dial-up password, be sure to remain logged in on at least one port while you are testing the password on a different port. If you make a mistake while you are installing the extra password and log off to test the new password, you might not be able to log back on. If you are still logged in on another port, you can go back and fix your mistake.
Become superuser or assume an equivalent role.
Create an /etc/dialups file that contains a list of serial devices, including all the ports that will require dial-up password protection.
The /etc/dialups file should look like the following:
/dev/term/a /dev/term/b /dev/term/c |
Create an /etc/d_passwd file that contains the login programs that will require a dial-up password, and the encrypted dial-up password.
Include shell programs that a user could be running at login, for example, uucico, sh, ksh, and csh. The /etc/d_passwd file should look like the following:
/usr/lib/uucp/uucico:encrypted-password: /usr/bin/csh:encrypted-password: /usr/bin/ksh:encrypted-password: /usr/bin/sh:encrypted-password: |
Set ownership to root on the two files.
# chown root /etc/dialups /etc/d_passwd |
Set group ownership to root on the two files.
# chgrp root /etc/dialups /etc/d_passwd |
Set read and write permissions for root on the two files.
# chmod 600 /etc/dialups /etc/d_passwd |
Create the encrypted passwords.
Create a temporary user.
# useradd username |
Create a password for the temporary user.
# passwd username |
Capture the encrypted password.
# grep username /etc/shadow > username.temp |
Edit the username.temp file.
Delete all fields except the encrypted password (the second field).
For example, in the following line, the encrypted password is U9gp9SyA/JlSk.
temp:U9gp9SyA/JlSk:7967:::::7988: |
Delete the temporary user.
# userdel username |
Copy the encrypted password from username.temp file into the /etc/d_passwd file.
You can create a different password for each login shell, or use the same password for each login shell.
The superuser account is used by the operating system to accomplish basic functions, and has wide-ranging control over the entire operating system. The superuser account has access to and can execute essential system programs. For this reason, there are almost no security restraints for any program that is run by superuser.
You can protect the superuser account on a system by restricting access to a specific device through the /etc/default/login file. For example, if superuser access is restricted to the console, you can log in to a system as superuser only from the console. If anybody remotely logs in to the system to perform an administrative function, they must first log in with their user login and then use the su command to become superuser. See the following section for detailed instructions.
Restricting superuser login to the console is set up by default when you install the Solaris release.
An alternative to using the superuser account is to setup role-based access control (RBAC). For overview information on RBAC, see Chapter 17, Role-Based Access Control (Overview).
Edit the /etc/default/login file.
Uncomment the following line:
CONSOLE=/dev/console |
Any users who try to remotely log in to this system must first log in with their user login, and then use the su command to become superuser.
Attempt to log in remotely as superuser to this system, and verify that the operation fails.
You can monitor su attempts by monitoring the /var/adm/sulog file. This file logs each time the su command is used. The su logging in this file is enabled by default through the following entry in the /etc/default/su file:
SULOG=/var/adm/sulog |
The sulog file lists all uses of the su command, not only the su attempts that are used to switch from user to superuser. The entries show the date and time the command was entered, whether or not the attempt was successful (+ or -), the port from which the command was issued, and finally, the name of the user and the switched identity.
Through the /etc/default/su file, you can set up the system to display on the console each time an attempt is made to use the su command to gain superuser access from a remote system. This method is a good way to immediately detect someone who is trying to gain superuser access on the system that you are currently working on. See the following section for detailed instructions.
Monitor the contents of the /var/adm/sulog file on a regular basis.
# 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 |
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.
Use the following procedure to disable or enable a system's abort sequence. The default system behavior is that a system's abort sequence is enabled.
Some server systems have a key switch that if set in the secure position, overrides the software keyboard abort settings. So, any changes you make with the following procedure might not be implemented.