Chapter 18 Securing Systems (Tasks)
This chapter describes the procedures for securing systems. This is a list of the step-by-step instructions in this chapter.
For overview information about securing systems, see "System Security".
Displaying Security Information
This section describes how to display user login information.
How to Display a User's Login Status
-
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 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(1M) command uses the local /etc/passwd file and the NIS or NIS+ password databases to obtain a user's login status.
Example--Displaying a User's Login Status
The following example displays login status for the user rimmer.
# logins -x -l rimmer
rimmer 500 staff 10 Arnold J. Rimmer
/export/home/rimmer
/bin/sh
PS 010170 10 7 -1
|
How to Display Users Without Passwords
You should make sure that all users have a valid password.
-
Become superuser.
-
Display users who have no passwords by using the logins command.
# logins -p
-p
Displays a list of users with no passwords.
The logins command uses the local /etc/passwd file and the NIS or NIS+ password databases to obtain a user's login status.
Example--Displaying Users Without Passwords
The following example displays that the user pmorph does not have a password.
# logins -p pmorph 501 other 1 Polly Morph # |
Temporarily Disabling User Logins
You can temporarily disable user logins by:
-
Creating the /etc/nologin file.
-
Bringing the system to run level 0 (single-user mode). See "Shutting Down a System (Tasks)" in System Administration Guide, Volume 1 for information on bringing the system to single-user mode.
Creating the /etc/nologin File
Create this file to disallow user logins and notify users when a system will be unavailable for an extended period of time due to 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(4) file is displayed, and the user login is terminated. Superuser logins are not affected.
How to Temporarily Disable User Logins
-
Become superuser.
-
Create the /etc/nologin file using an editor.
# vi /etc/nologin
-
Include a message regarding system availability.
-
Close and save the file.
Example--Disabling User Logins
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.*** |
Saving Failed Login Attempts
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. See "How to Save Failed Login Attempts" for detailed instructions.
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 may 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 may suggest an attempt to break into the computer system. For more information about this file, see loginlog(4).
How to Save Failed Login Attempts
-
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 rimmer:/dev/pts/4:Mon Jul 12 13:52:15 1999 rimmer:/dev/pts/4:Mon Jul 12 13:52:23 1999 rimmer:/dev/pts/4:Mon Jul 12 13:52:31 1999 rimmer:/dev/pts/4:Mon Jul 12 13:52:39 1999 #
Password Protection Using Dial-up Passwords
You can add a layer of security to your password mechanism 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 mechanism 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 contains a list of ports that require a dial-up password, and the second contains a list of shell programs that require an encrypted password as the additional dial-up password.
The dialups(4) file is a list of terminal devices, for example:
/dev/term/a /dev/term/b |
The d_passwd(4) file has two fields. The first is the login shell that will require a password, and the second is the encrypted password. The /etc/dialups and /etc/d_passwd files work like this:
When a user attempts to log in on any of the ports listed in /etc/dialups, the login program looks at the user's login entry stored in /etc/passwd, and compares the login shell to the entries in /etc/d_passwd. These entries determine whether the user will be required to supply the dial-up password.
/usr/lib/uucp/uucico:encrypted_password: /usr/bin/csh:encrypted_password: /usr/bin/ksh:encrypted_password: /usr/bin/sh:encrypted_password: |
The basic dial-up password sequence is shown in the figure below.
Figure 18-1 Basic Dial-up Password Sequence
The /etc/d_passwd File
Because most users will be running a shell when they log in, all shell programs should have entries in /etc/d_passwd. Such programs include uucico, sh, ksh, and csh. If some users run something else as their login shell, include that login shell in the file, too.
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:*:
How to Create a Dial-up Password
Caution - When you first establish a dial-up password, be sure to remain logged in on at least one terminal while testing the password on a different terminal. If you make a mistake while 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 terminal, you can go back and fix your mistake.
-
Become superuser.
-
Create an /etc/dialups file containing a list of terminal devices, including all the ports that will require dial-up password protection.
The /etc/dialups file should look like this:
/dev/term/a
/dev/term/b
/dev/term/c
-
Create an /etc/d_passwd file containing 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 this:
/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 user-name
-
Create a password for the temporary user.
# passwd user-name
-
Capture the encrypted password.
# grep user-name /etc/shadow > user-name.temp
-
Edit the user-name.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 user-name
-
-
Copy the encrypted password from user-name.temp file into the /etc/d_passwd file.
You can create a different password for each login shell, or use the same one for each.
How to Temporarily Disable Dial-up Logins
Restricting Superuser (root) Access on the Console
The superuser account is used by the operating system to accomplish basic functions, and has wide-ranging control over the entire operating system. It 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(1M) command to become superuser. See the section below for detailed instructions.
Note -
Restricting superuser login to the console is set up by default when you install a system.
How to Restrict Superuser (root) Login to the Console
-
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.
Monitoring Who Is Using the su Command
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. See "How to Monitor Who Is Using the su Command" for step-by-step instructions.
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.
Through the /etc/default/su file, you can also 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 is a good way to immediately detect someone trying to gain superuser access on the system you are currently working on. See the section below for detailed instructions.
How to Monitor Who Is Using the su Command
-
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
How to Display Superuser (root) Access Attempts to the Console
-
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.
Modifying a System's Abort Sequence
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 may not be implemented.
How to Disable or Enable a System's Abort Sequence
- © 2010, Oracle Corporation and/or its affiliates