Chapter 3 Securing Machines (Tasks)

This chapter describes the procedures for securing machines in the Solaris environment. The procedures are introduced in the following section:

• Securing Machines (Task Map)

For overview information about machine security, see Chapter 2, Managing Machine Security (Overview).

Securing Machines (Task Map)

A computer is as secure as its weakest point of entry. The following task map shows the areas that you should monitor and secure.

Securing Logins and Passwords

This section describes how to control and monitor logins.

How to Display a User's Login Status

1. Become superuser or assume an equivalent role.

2. 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 appropriate password file to obtain a user's login status. The file can be the local /etc/passwd file , or a password database for the name service. For more information, see the logins(1M) man page.

Example—Displaying a User's Login Status

In the following example, the login status for the user rimmer is displayed.

# logins -x -l rimmer
rimmer       500     staff           10   Annalee J. Rimmer
                     /export/home/rimmer
                     /bin/sh
                     PS 010170 10 7 -1

How to Display Users Without Passwords

1. Become superuser or assume an equivalent role.

2. 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 can use the password databases on the local machine and on the network. The command can use the local /etc/passwd file. The command can use the password databases for the name services to obtain a user's login status.

Example—Displaying Users Without Passwords

The following example shows that the user pmorph does not have a password.

# logins -p
pmorph          501     other           1       Polly Morph
# 

How to Temporarily Disable User Logins

1. Become superuser or assume an equivalent role.

2. Create the /etc/nologin file by using an editor.

   # vi /etc/nologin

3. Include a message about system availability.

4. Close and save the file.

   Create this file to disallow user logins during system shutdown or routine maintenance. If a user attempts to log in to a system where the nologin file exists, the contents of this file are displayed. Then, the user login is terminated.

   Superuser logins are not affected. For more information, see the nologin(4) man page.

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.***

You can also bring 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.

How to Save Failed Login Attempts

1. Become superuser or assume an equivalent role.

2. Create the loginlog file in the /var/adm directory.

   # touch /var/adm/loginlog

3. Set read and write permissions for root on the loginlog file.

   # chmod 600 /var/adm/loginlog

4. Change group membership to sys on the loginlog file.

   # chgrp sys /var/adm/loginlog

5. 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 #

   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, no failed attempts are logged.

   The loginlog file might grow quickly. To use this file in a timely manner, you should check and clear its contents occasionally. A loginlog file that shows a lot of activity can indicate an attempt to break into the computer system. For more information, see the loginlog(4) man page.

How to Create a Dial-up Password

When you first establish a dial-up password, be sure to remain logged in to at least one port. Test the password on a different port. If you log off to test the new password, you might not be able to log back on. If you are still logged in to another port, you can go back and fix your mistake.

1. Become superuser or assume an equivalent role.

2. Create an /etc/dialups file that contains a list of serial devices. Include all the ports that are being protected with dial-up passwords.

   The /etc/dialups file should look like the following:

   /dev/term/a /dev/term/b /dev/term/c

3. Create an /etc/d_passwd file that contains the login programs that you are requiring to have a 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:

   You are going to add the encrypted password for each login program later in the procedure.

4. Set ownership to root on the two files.

   # chown root /etc/dialups /etc/d_passwd

5. Set group ownership to root on the two files.

   # chgrp root /etc/dialups /etc/d_passwd

6. Set read and write permissions for root on the two files.

   # chmod 600 /etc/dialups /etc/d_passwd

7. Create the encrypted passwords.

   1. Create a temporary user.

      # useradd username

   2. Create a password for the temporary user.

      # passwd username

   3. Capture the encrypted password.

      # grep username /etc/shadow > username.temp

   4. Edit the username.temp file.

      Delete all fields except the encrypted password. The second field holds the encrypted password.

      For example, in the following line, the encrypted password is U9gp9SyA/JlSk.

      temp:U9gp9SyA/JlSk:7967:::::7988:

   5. Delete the temporary user.

      # userdel username

8. 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.

9. Inform your dial-up users of the password.

   You should ensure that your means of informing the users cannot be tampered with.

How to Temporarily Disable Dial-up Logins

1. Become superuser or assume an equivalent role.

2. Put the following single-line entry into the /etc/d_passwd file:

   /usr/bin/sh:*:

Changing the Default Algorithm for Password Encryption

By default, user passwords are encrypted with the crypt_unix algorithm. In the Solaris 9 12/02 release, you can use a stronger encryption algorithm, such as MD5 or Blowfish, by changing the default password encryption algorithm. The next time that your users change their password, the algorithm that you specified encrypts the password.

The following procedures do not work if you are running a Solaris environment from an earlier release. This functionality works only on machines that are running the Solaris 9 12/02 release and later releases of the Solaris operating environment.

How to Specify an Algorithm for Password Encryption

In this procedure, the BSD-Linux version of the MD5 algorithm is the default encryption algorithm that is used when users change their passwords. This algorithm is suitable for a mixed network of machines that run the Solaris, BSD, and Linux versions of UNIX. See Table 2–1 for a list of password encryption algorithms and algorithm identifiers.

1. Become superuser or assume an equivalent role.

2. Specify the identifier for the encryption algorithm as the value for the CRYPT_DEFAULT variable in the /etc/security/policy.conf file.

   You might want to comment the file to explain your choice.

   # vi /etc/security/policy.conf … CRYPT_ALGORITHMS_ALLOW=1,2a,md5 # # Use the version of MD5 that works with Linux and BSD systems. # Passwords previously encrypted with __unix__ will be encrypted with MD5 # when users change their passwords. # #CRYPT_DEFAULT=__unix__ CRYPT_DEFAULT=1

   In this example, the algorithms configuration ensures that the weakest algorithm, crypt_unix, is never used to encrypt a password. Users whose passwords were encrypted with the crypt_unix module get a crypt_bsdmd5–encrypted password when they change their passwords.

   For more information on the syntax for configuring the algorithm choices, see the policy.conf(4) man page.

Example—Using the Blowfish Algorithm for Password Encryption

In this example, the identifier for the Blowfish algorithm, 2a, is specified as the value for the CRYPT_DEFAULT variable. The policy.conf entries that control password encryption would look like the following:

CRYPT_ALGORITHMS_ALLOW=1,2a,md5
#CRYPT_ALGORITHMS_DEPRECATE=__unix__
CRYPT_DEFAULT=2a

This configuration is compatible with BSD systems that use the Blowfish algorithm.

How to Specify a New Password Algorithm for an NIS+ Domain

1. Specify the password encryption algorithm in the /etc/security/policy.conf file on the NIS+ master.

2. To minimize confusion, copy the NIS+ master's /etc/security/policy.conf file to every host in the NIS+ domain.

When users in a NIS+ domain change their passwords, the NIS+ name service consults the algorithms configuration in the /etc/security/policy.conf file on the NIS+ master. The NIS+ master, which is running the rpc.nispasswd daemon, creates the encrypted password.

How to Specify a New Password Algorithm for an NIS Domain

1. Specify the password encryption algorithm in the /etc/security/policy.conf file on the NIS client.

2. Copy the modified /etc/security/policy.conf file to every client machine in the NIS domain.

3. To minimize confusion, copy the modified /etc/security/policy.conf file to the NIS root server and to the slave servers.

When users in an NIS domain change their passwords, the NIS client consults its local algorithms configuration in the /etc/security/policy.conf file. The NIS client machine encrypts the password.

How to Specify a New Password Algorithm for an LDAP Domain

When the LDAP client is properly configured, the LDAP client can use the new password algorithms. The LDAP client behaves just as a NIS client behaves.

1. Specify a password encryption algorithm in the /etc/security/policy.conf file on the LDAP client.

2. Copy the modified policy.conf file to every client machine in the LDAP domain.

3. Ensure that the client's /etc/pam.conf file does not use a pam_ldap module.

   Ensure that a comment sign (#) precedes entries that include pam_ldap.so.1. Also, do not use the new server_policy option with the pam_authtok_store.so.1 module.

The PAM entries in the client's pam.conf file enable the password to be encrypted according to the local algorithms configuration, and enable the password to be authenticated.

When users in the LDAP domain change their passwords, the LDAP client consults its local algorithms configuration in the /etc/security/policy.conf file. The LDAP client machine encrypts the password. The client sends the encrypted password, with a {crypt} tag, to the server. The tag tells the server that the password is already encrypted. The password is then stored, as is, on the server. For authentication, the client retrieves the stored password from the server. The client then compares the stored password with the encrypted version that the client has just generated from the user's typed password.

To take advantage of password policy controls on the LDAP server, use the server_policy option with the pam_authtok_store entries in the pam.conf file. Passwords are then encrypted on the server by using the Sun ONE Directory Server's cryptographic mechanism. For the procedure, see “Setting Up Clients (Task)” in System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).

How to Install a Password Encryption Module From a Third Party

A third-party password encryption algorithm is typically delivered as part of a software package. When you run the pkgadd command, scripts from the vendor should modify the /etc/security/crypt.conf file. You then modify the /etc/security/policy.conf file to include the new module and its identifier.

1. Add the software by using the pkgadd command.

   For detailed instructions on how to add software, see “Adding or Removing a Software Package” in System Administration Guide: Basic Administration.

2. Read the /etc/security/crypt.conf file to confirm that the new module and module identifier are in the list of encryption algorithms.

   For example, the following lines show a crypt.conf file that was modified by a package that installed the crypt_rot13 algorithm.

   # crypt.conf # md5 /usr/lib/security/$ISA/crypt_md5.so rot13 /usr/lib/security/$ISA/crypt_rot13.so # For *BSD - Linux compatibility # 1 is MD5, 2a is Blowfish 1 /usr/lib/security/$ISA/crypt_bsdmd5.so 2a /usr/lib/security/$ISA/crypt_bsdbf.so

3. Modify the /etc/security/policy.conf file to add the identifier of the newly installed algorithm.

   The following lines show excerpts from the policy.conf file that would need to be modified to add the rot13 identifier.

   # Copyright 1999-2002 Sun Microsystems, Inc. All rights reserved. # ... #ident "@(#)policy.conf 1.6 02/06/07 SMI" # ... # crypt(3c) Algorithms Configuration CRYPT_ALGORITHMS_ALLOW=1,2a,md5,rot13 #CRYPT_ALGORITHMS_DEPRECATE=__unix__ CRYPT_DEFAULT=md5

In this example, the rot13 algorithm is used if the current password was encrypted with the crypt_rot13 algorithm. New user passwords are encrypted with the crypt_sunmd5 algorithm. This algorithms configuration works on Solaris-only networks.

Monitoring and Restricting Superuser

An alternative to using the superuser account is to set up role-based access control. Role-based access control is called RBAC. For overview information on RBAC, see Chapter 5, Role-Based Access Control (Overview). For how to set up RBAC, see Chapter 6, Role-Based Access Control (Tasks).

How to Monitor Who Is Using the su Command

The sulog file lists every use of the su command, not only the su attempts that are used to switch from user to superuser.

1. Become superuser or assume an equivalent role.

2. 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-janedoe SU 01/12 14:56 + pts/0 pmorph-root SU 01/12 14:57 + pts/0 pmorph-root

   The entries display the following information:

   • The date and time that the command was entered

   • If the attempt was successful

     A + indicates a successful attempt. A - indicates an unsuccessful attempt.

   • The port from which the command was issued

   • The name of the user and the name of the switched identity

   The su logging in this file is enabled by default through the following entry in the /etc/default/su file:

   SULOG=/var/adm/sulog

How to Display Superuser (root) Access Attempts to the Console

1. Become superuser or assume an equivalent role.

2. Edit the /etc/default/su file.

3. Uncomment the following line:

   CONSOLE=/dev/console

4. Use the su command to become root.

   Verify that a message is printed on the system console.

   This method immediately detects someone who is trying to gain superuser access to the system that you are on.

How to Prevent Remote Login by Superuser (root)

Superuser login is restricted to the console by default when you install the Solaris release.

1. Become superuser or assume an equivalent role.

2. Edit the /etc/default/login file.

3. Uncomment the following line:

   CONSOLE=/dev/console

   When superuser access is restricted to the console, you can log in to a system as superuser only from the console. Any users who try to remotely log in to this system must first log in with their user login. After logging in with their user name, users then use the su command to become superuser.

4. Attempt to log in remotely as superuser to this system, and verify that the operation fails.

Securing the Hardware

You can protect the physical machine by requiring a password to boot the machine. You can also protect the machine by preventing a user from using the abort sequence to leave the windowing system.

How to Require a Password for Hardware Access

1. Become superuser or assume an equivalent role.

2. In a terminal, enter the PROM security mode. Type the following:

   # eeprom security-mode=command Changing PROM password: New password: password Retype new password: password

   Choose the value command or full. See the eeprom(1M) man page for more details.

3. If you are not prompted to enter a PROM password, the system already has a PROM password. To change the PROM password, run the command:

   # eeprom security-password=<Type the Return key> Changing PROM password: New password: password Retype new password: password

   The new PROM security mode and password are in effect immediately, but are most likely to be noticed at the next boot.

   ---

   Caution –

   Do not forget the PROM password. The hardware is unusable without this password.

   ---

How to Disable or Enable a System's Abort Sequence

Use the following procedure to disable a machine's abort sequence. The default system behavior is that a system's abort sequence is enabled.

Some server systems have a key switch. When the switch is set in the secure position, the switch overrides the software keyboard abort settings. So, any changes that you make with the following procedure might not be implemented.

1. Become superuser or assume an equivalent role.

2. Change the value of KEYBOARD_ABORT to disable.

   Comment out the enable line in the /etc/default/kbd file. Then add a disable line:

   # vi /etc/default/kbd … # KEYBOARD_ABORT affects the default behavior of the keyboard abort # sequence, see kbd(1) for details. The default value is "enable". # The optional value is "disable". Any other value is ignored. … #KEYBOARD_ABORT=enable KEYBOARD_ABORT=disable

3. Update the keyboard defaults.

   # kbd -i