Identifying User Login Status

The easiest way to determine which users are currently logged into the system is by issuing the who command at a terminal prompt with full privileges. Displaying user login status, on the other hand, is also painless with the logins command. Following is an extract from the command using the –x argument, which displays extended output:

# logins  x 
root            0       other           1       Super-User
                        /
                        /sbin/sh
                        PS 082587 -1 -1 -1 
nuucp           9       nuucp           9       uucp Admin
                        /var/spool/uucppublic
                        /usr/lib/uucp/uucico
                        LK 082587 -1 -1 -1 
j_public        101     staff           10      Sales
                        /home/j_public
                        /bin/sh
                        NP 051304 -1 -1 -1 
b_friedman      102     mail            6       Marketing
                        /home/b_friedman
                        /bin/sh
                        PS 051304 -1 -1 -1 
nobody          60001   nobody          60001   NFS Anonymous Access User
                        /
                        /sbin/sh
                        LK 082587 -1 -1 -1

As shown, the output is organized in ascending order by user ID. Using the b_friedman account as an example, let's break down the user status details:

• b_friedman is the user's login name.

• 102 is the user ID (UID).

• mail identifies the user's primary group.

• 6 is the group ID (GID).

• Marketing is the user description (in this case, the description indicates the user's work group within the organization).

• /home/b_friedman is the user's home directory.

• /bin/sh identifies the login shell.

• PS 051304 -1 -1 -1 specifies the following password aging information: the last date that the password was changed, the number of days required between changes, the number of days before a change is required, and the warning period.

Another logins command argument you should know for the exam is the -l username; where username is the user login name. For example, to display the extended user login status for Kelly Martin, whose login name is k_martin, you would issue the following command:

logins -x -l k_martin

One more critical argument you can use with the logins command is with the -p option. With this option, you can display which users do not have assigned passwords. For example, by issuing the logins -p command, you get the following output:

# logins -p
j_public         101        staff         10      Sales

Here we see that user name j_public, part of the staff group, does not have an assigned password. This is typically the case when administrators set up user logins without a temporary password (that is, selecting the User Must Set Password At First Login option when adding a user). This could lead to a security breach; thus, Sun recommends actively monitoring and disabling user logins without passwords on a regular basis—or, better yet, preventing them from being created in the first place.

Finally, another method used to view user login status is by accessing the /etc/ shadow file with full privileges (since the file is owned by root). A user account is currently disabled when a user record contains *LK* in the shadow file, such as in the following extract:

j_public:*LK*:12557

Additionally, when an account name is followed by a *NP*, that account currently is not assigned a password, as shown here:

adm:*NP*:6445

It's important to note that only root can view the contents of the read-only /etc/shadow file—and for good reason. User names with assigned passwords are followed by an encrypted password string, and if it were readable by anyone, intruders would have much easier access to utilize password-cracking utilities to guess them.

Disabling User Logins

At times during a security investigation, or perhaps during system maintenance, you'll need to disable user logins while performing forensics or routine tasks. Keep this in mind as well when you're running the Automated Security Enhancement Tool (ASET) tasks (see Chapter 8 for more information) to keep system utilization down to a minimum by blocking user access.

In this chapter, when we edit a system file, we'll be using the operating system's visual editor (vi), a text editor that enables you to enter or modify text in a file. Fundamentally, vi supports two modes of operation: a command mode and an insert mode. By default, when you start vi, you're in the command mode. While in command mode, vi accepts commands that correspond with specific actions. Table 4-1 shows a summary of the most common commands you should know. On the other hand, while in insert mode, you're allowed to enter text. While in command mode, you can enter insert mode by pressing the I key on your keyboard. To revert back to command mode, press the ESC key.

Inside The Exam–Manually Disabling User Logins

Following are steps for manually disabling user logins:

1. Log in with an account that has root privileges, or use the su command to become superuser.

2. Create the /etc/nologin file in your text editor by issuing the vi /etc/nologin command.

3. Insert a notification message (by pressing the I key on the keyboard) to be displayed when users attempt access by typing

   ***Performing System Maintenance. The system will be unavailable until 10pm.***

4. End insert mode by pressing the ESC key, and then save the file and exit the editor with the :wq command.

Using the vi text editor, the steps involved in disabling user logins temporarily are straightforward and relatively uncomplicated. To do so, you become superuser, create a /etc/nologin file, insert a notification message in the file (to be displayed when users attempt access), and then save and exit the file.

Alternatively, you can also disable logins by bringing down the system to run level S (single-user mode, as shown in Table 4-2). To do so, follow these three steps:

1. Become superuser.

2. Shut down the system with this command:

   shutdown -i init-level -g grace-period -y Where init-level is 0, 1, 2, 5, 6, or S (which is the default) and grace-period is the time (in seconds) before the system is shut down (default is 60 seconds). For example, to shut down the system to run level S and therefore disable all logins, you would use this command: shutdown -y

3. Enter the password for root at the system maintenance prompt request.

By issuing the init (Run Level #) command, you can switch between run levels to perform functions such as halting and rebooting the Solaris operating system. In essence, init is the process spawner, while a Run Level is a software configuration for a selected group of processes. As an example, to shut down the operating system and reboot the computer, you'd open a terminal session with the appropriate administrative privileges and type init 6.

Table 4-2 lists a summary of run levels that you should know.

If done correctly, when disabling user logins by bringing the system down and initiating single-user mode, you'll see output similar to the following:

Shutdown started. Thu May 13 11:30:32 CST 2004
   
Broadcast Message from root (console) on sun Thu May 13 11:30:33...
The system sun will be shut down in 1 minute
.
Broadcast Message from root (console) on sun Thu May 13 11:31:03...
The system sun will be shut down in 30 seconds
.
Broadcast Message from root (console) on sun Thu May 13 11:31:33...
The system sun IS BEING SHUT DOWN NOW!!!
.
INIT: New run level: S
The system is coming down for administration. Please wait.
Unmounting remote filesystems: /vol nfs done.
Shutting down Solaris Management Console server on port 898.
Print services stopped.
May 13 11:31:34 sun syslogd: going down on signal 15
Killing user processes: done.
INIT: SINGLE USER MODE
Type control-d to proceed with normal startup,
(or give root password for system maintenance): (you enter root password here)
Entering System Maintenance Mode ...
#

Lastly, you can also disable user accounts individually. The method that Sun recommends is uncomplicated and requires using the Solaris Management Console (SMC) interface. To disable accounts individually, simply follow these steps:

1. Log in with an account that has root privileges, or use the su command to become superuser.

2. Right-click on the desktop to open the Workspace menu.

3. Click the Tools/Solaris Management Console option to open the GUI interface.

4. In SMC, click to open This Computer in the Navigation panel.

5. Within This Computer, click the System Configuration option and then Users.

6. At the prompt, enter root's password and click OK.

7. Click to open the User Accounts option.

8. Click to open a particular user account and then select the Account Is Locked option at the bottom of the interface.

   

9. Click OK to disable and update the account.

10. Exit SMC.

    Exam Watch

    Remember how to disable all user logins with the exception of superuser. This can be done by creating a /etc/nologin file, bringing the system down to single-user mode (level S), and disabling user accounts individually using the Solaris Management Console (SMC) interface.

Monitoring Failed Terminal Session User Login Attempts

Solaris keeps track of each user login so that the next time a user logs in, the previous login is reported on the screen. Capturing unsuccessful login attempts is accomplished by creating a var/adm/loginlog file. The loginlog file should be owned by root with read and write permissions and belong to the sys group. Each failed login (after five unsuccessful attempts) is appended as a line entry containing the user's login name, TTY device, and time. Failed login attempts will be logged to the loginlog file, and therefore it should be utilized for potential intrusion detection and monitored regularly. The file contents can be viewed by issuing the more /var/adm/loginlog command.

The following extract displays a few entries from a loginlog file:

j_public:/dev/pts/9:Tue May 25 23:10:15 2004
j_public:/dev/pts/9:Tue May 25 23:10:17 2004
j_public:/dev/pts/9:Tue May 25 23:10:20 2004
j_public:/dev/pts/9:Tue May 25 23:10:21 2004
j_public:/dev/pts/9:Tue May 25 23:10:22 2004
b_friedman:/dev/pts/2:Tue May 25 23:14:11 2004
b_friedman:/dev/pts/2:Tue May 25 23:10:12 2004

Inside The Exam–Setting Up the loginlog File to Monitor Failed Logins

Following are five simple steps for manually setting up the var/adm/loginlog file to monitor failed user login attempts and then test its functionality:

1. Log in with an account that has root privileges, or use the su command to become superuser.

2. Create the var/adm/loginlog file with your vi text editor or by issuing the touch /var/adm/loginlog command.

3. Make the loginlog file part of the sys group with the chgrp sys /var/adm/loginlog command.

4. Set both read and write permissions for only the root user on the loginlog file with the chmod 600 /var/adm/loginlog command.

5. Test that the system is logging failed login attempts by unsuccessfully logging in to the system from terminal windows at least five times, and then view the loginlog file contents by issuing the more /var/adm/loginlog command.

You should note that the loginlog file records only failed login attempts from terminal sessions; therefore, it does not capture unsuccessful logins from CDE or GNOME. However, capturing all login types is possible using syslog, which is explained in the next section.

Monitoring All Unsuccessful Login Attempts  In the previous section, we used the loginlog file to record failed login attempts from terminal sessions; however, there are ways to monitor all unsuccessful logins as well as supervise root access whether they are from terminal sessions, CDE, or GNOME. In the next section, we'll do this by using syslog and sulog files and we'll discuss techniques to customize and control access logging and process accounting.