|
|
Syslog is the de facto standard for event logging on UNIX systems. For years, system logging facilities have used syslog to store and manage system event notifications. This section takes logging and process accounting beyond the limitations of using the loginlog file for monitoring unsuccessful login attempts. In addition, we'll also look at ways to monitor and restrict superuser by means of the switch user (su) program.
As mentioned, you can monitor all unsuccessful logins whether they are from terminal sessions, CDE, or GNOME. All failed login attempts will be stored in a syslog file. The syslog file can and should be monitored closely on a regular basis to pinpoint potential intrusion attempts and other irregularities.
The syslog daemon launcher script that controls the logging facilities is located in the /etc/init.d/ directory as syslog. Following is the command syntax for starting and stopping the syslog daemon:
/etc/init.d/syslog start /etc/init.d/syslog stop
Let's look at the steps involved in monitoring all unsuccessful login attempts with syslog.
With full privileges, edit the /etc/default/login file and make sure that the SYSLOG=YES and SYSLOG_FAILED_LOGINS=0 entries are uncommented.
Create the log file (/var/adm/authlog) and assign the appropriate read/write permissions for root.
| Exam Watch |
Sun's exam may ask you which file to edit when setting up the system to monitor all failed login attempts. Remember that the login file is located in the /etc/default directory. To ensure that the system will monitor all denied logins, the SYSLOG=YES and SYSLOG_FAILED_LOGINS=0 entries should be uncommented. |
Change the authlog file group membership to sys.
Edit the syslog.conf file to send all failed login attempts to the authlog file with the following entry:
auth.notice<TAB>/var/adm/authlog
(Note that a tabbed-space, not a standard space, appears between the auth.notice and /var/adm/authlog attributes in this entry).
Stop and start the syslog daemon.
Customizing the System Logging Facility Optionally, you can customize the System Logging Facility not only to log failed login access attempts after some predefined number of tries, but to close the login connection after some predefined number of failures as well.
The first part is accomplished by simply editing the SYSLOG_FAILED_LOGINS=0 entry in the /etc/default/login file to some number such as this: SYSLOG_FAILED_LOGINS=3. At this point, the system will log access attempts only after the first three failures.
 |
Following are the steps for setting up syslog to monitor all failed user logins attempts:
Log in with an account that has root privileges or use the su command to become superuser.
auth.notice /var/adm/authlog Edit the /etc/default/login file by uncommenting the SYSLOG=YES and SYSLOG_ FAILED_LOGINS=0 entries: # # SYSLOG determines whether the syslog(3) LOG_AUTH facility should be used # to log all root logins at level LOG_NOTICE and multiple failed login # attempts at LOG_CRIT. # SYSLOG=YES # # These entries were clipped for brevity. # # The SYSLOG_FAILED_LOGINS variable is used to determine how many failed # login attempts will be allowed by the system before a failed login # message is logged, using the syslog(3) LOG_NOTICE facility. For example, # if the variable is set to 0, login will log -all- failed login attempts. # SYSLOG_FAILED_LOGINS=0 #
Create the log file in the /var/adm directory:
touch /var/adm/authlog
Assign the appropriate read/write permissions for root to the log file:
chmod 600 /var/adm/authlog
Change the authlog file group membership to sys:
chgrp sys /var/adm/authlog
Edit the syslog.conf file to send all failed login attempts to the authlog file:
Stop and start the syslog daemon. To stop
/etc/init.d/syslog stop
To start
/etc/init.d/syslog start
You can test to determine whether the system is logging failed login attempts by unsuccessfully logging in to the system and then viewing the /var/adm/authlog file contents by issuing this command:
|
The second part involves closing connections after some number of retries—for example, after five unsuccessful login attempts. This is a common configuration for enterprises, as many security policies mandate this rule. To do so, simply uncomment the RETRIES entry in the /etc/default/login file, and make sure the value is either set to 5 (which is the default value) or some other reasonable mandated value. Upon saving the file, the changes will take effect immediately; after five failed login attempts in the same session, the system will close the connection. Following is an extract of this entry:
# # RETRIES determines the number of failed logins that will be # allowed before login exits. # RETRIES=5 #
Role-Based Access Control (RBAC), which we'll visit later in Chapter 9, is Sun's recommended alternative to using the switch user (su) program and the superuser account. With superuser access permissions, a user will have full control over the system commands and functionality. With full privileges, superusers can wreak havoc on the integrity of the operating system and potentially damage critical data. Therefore, monitoring and controlling superuser access is critical. In this section, we'll look at steps to use not only to monitor who is using the su program but also how to control superuser access.
The su program usage, by default, is already monitored through the /etc/default/su file as SULOG=/var/adm/sulog, and the syslog logging facility will determine whether or not all su attempts are logged with the SYSLOG=YES entry. As a result, monitoring the output is as simple as running the command more /var/adm/sulog from the terminal. The su logging in the /var/adm/sulog file entries display useful information including the date and time that the command was executed, whether or not the su attempt was successful (+ means success, - means failure), the port from which the su program was executed, and the user name that ran the program as well as the user name to which the user switched.
Following is an extract from the sulog file with regard to superuser (root) account access:
SU 05/26 10:18 + pts/0 j_public-root SU 05/26 12:02 + pts/0 j_chirillo-root SU 05/26 15:09 + pts/0 j_public-root SU 05/26 15:43 + pts/0 b_friedman-root SU 05/26 16:52 - pts/0 guest-root
| Exam Watch |
The su program is monitored by default. The configuration can be found in the /etc/default/su file. |
This file should be monitored on a regular basis to pinpoint potential malicious access attempts.
Displaying Superuser Access Attempts Optionally, for hands-on monitoring, you can set up the system so that it will detect and display superuser access attempts directly on the console. To do so, follow these steps:
Log in with an account that has root privileges, or use the su command to become superuser.
Edit the /etc/default/su file by uncommenting this entry: CONSOLE=/dev/console
Save and exit, and then log in as superuser again using the su command.
After issuing the su command to become superuser, a message will appear on the console. This is a granular approach to monitoring and is typically used when administrators are actively monitoring superuser access attempts. Also, security professionals often deploy this technique, among others, when observing a real-time attack against the operating system.
When you install the Solaris operating system, by default, remote superuser (root) logins are disabled. In other words, users typically have to log in as some user account (other than root) and then issue the su command to become a superuser with full privileges. However, if you detect that remote superuser login access is enabled, follow these steps to mitigate risks associated with it:
Log in with an account that has root privileges, or use the su command to become superuser.
Edit the /etc/default/login file by uncommenting this entry: CONSOLE=/dev/console
Save and exit, and then attempt to log in as superuser remotely.
At this point, remote superuser login access should be denied. Subsequently, to become superuser remotely, simply log in with a standard user account and then issue the su command followed by root's password.
Here are some of the key points from the certification objectives in Chapter 4.
Issue the logins command and view the /etc/shadow file to determine which accounts are locked or disabled and which do not currently have assigned passwords. These techniques are useful when identifying user login status.
You can disable user logins by either creating a /etc/nologin file, bringing the system down to single-user mode with the command init S, or disabling user accounts from the Solaris Management Console (SMC) interface.
Solaris keeps track of each terminal session user login and records login attempts in the var/adm/loginlog file if it exists and has the correct permissions.
Failed login attempts from terminal sessions are stored in the var/adm/loginlog file.
Syslog can monitor all unsuccessful login attempts. To make this happen, edit the /etc/default/login file and make sure that the SYSLOG=YES and SYSLOG_FAILED_LOGINS=0 entries are uncommented.
You can customize the System Logging Facility to log failed login access attempts after a predefined number of tries by editing the SYSLOG_FAILED_LOGINS=0 entry in the /etc/default/login file to some number such as this: SYSLOG_FAILED_LOGINS=3. At this point, the system will log access attempts only after the first three failures.
You can customize the System Logging Facility to close the login connections after some predefined number of failures by uncommenting the RETRIES entry in the /etc/default/login file (make sure the value is set to some number; 5 is the default value). By default, after five failed login attempts in the same session, the system will close the connection.
The su program usage is monitored through the /etc/default/su file as SULOG=/var/adm/sulog, and the syslog logging facility will determine whether or not to log all su attempts with the SYSLOG=YES entry.
In real time, you can display superuser access attempts on the console by uncommenting the CONSOLE=/dev/console entry in the /etc/default/su file.
To disable remote superuser login access attempts (which is disabled by default), simply uncomment the CONSOLE=/dev/console entry in the /etc/default/login file.
The following questions will help you measure your understanding of the material presented in this chapter. Read all the choices carefully, because there might be more than one correct answer. Choose all correct answers for each question.
|
Which of the following techniques is used to identify user login status with regard to logins without assigned passwords?
|
|
|
|
Which of the following are part of Sun's required password policy?
|
|
|
|
Failed login attempts from terminal sessions are stored in which file?
|
|
|
|
Which of the following techniques can be used to identify current user login status?
|
|
|
|
Which of the following commands can be executed to switch between run levels and to perform functions such as halting and rebooting the Solaris operating system?
|
|
|
|
Which of these commands can be executed to display only the extended user login status for Becky Blake, whose login name is b_blake?
|
|
|
|
Which of these is a common run level used to stop the operating system and reboot?
|
|
|
|
Which of these is a common run level used to go into single-user state for administrative functions?
|
|
|
|
To perform system maintenance, you must bring system resources down to minimum levels. Which of these techniques can be used to disable user logins?
|
|
Answers
|
þ C. The logins command with the -p option is used to display which users do not have assigned passwords. ý A is wrong because the logins command will display general information concerning all login accounts organized in ascending order by user ID. B is incorrect because the -x argument will display extended information regarding all login accounts. D is wrong because Solaris keeps track of each user login and records login attempts in the var/adm/loginlog file. |
|
|
þ B and C. Sun's policy mandates that passwords must be composed of between 6 and 15 letters, numbers, and special characters, and must have at least 2 alphabetic characters and at least 1 numeric or special character within the first 6 characters. ý A and D are wrong because they are part of industry-recognized security recommendations for creating passwords and are not mandated by Sun's password policy. |
|
|
þ D. Solaris keeps track of each terminal session login attempt in the var/adm/loginlog file. ý A is wrong because /etc/default/login involves syslog and monitoring all unsuccessful login attempts. B is wrong because /etc/nologin is used when disabling user logins. C is incorrect because the /etc/shadow file can be accessed to determine which accounts are locked or disabled and which do not currently have assigned passwords. |
|
|
þ A and B. Identifying user login status—by issuing the logins command and viewing the /etc/shadow file—is important for determining which accounts are locked or disabled and which do not currently have assigned passwords. ý C is wrong because the init S command is used to bring down the system to run level S (single-user mode). D is wrong because the /var/adm/loginlog file is used to log failed terminal session user login attempts. |
|
|
þ D. All of the answers are correct. By issuing the init (Run Level #) command, you can switch between run levels and perform functions such as halting and rebooting the Solaris operating system. Additionally, you can 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 (the 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 |
|
|
þ D. To display the extended user login status for a particular user, issue the logins - x -l user command. ý A is incorrect because the logins command will display general information concerning all login accounts organized in ascending order by user ID. B is incorrect because the logins user command will display only general information about a particular user account. C is wrong because the logins -p command will display user accounts that currently do not have assigned passwords. |
|
|
þ E. By issuing init 6 you will stop the operating system and reboot. ý A is incorrect because init S is used to enter single-user state for administrative functions. B is wrong because init 0 is used to enter firmware maintenance mode. C is wrong because init 2 is used to enter multi-user state where NFS is not running. D is wrong because init 5 is used to shut down the operating system altogether. |
|
|
þ A. By issuing init S you will enter single-user mode. ý B is wrong because init 0 is used to enter firmware maintenance mode. C is wrong because init 2 is used to enter multi-user state where NFS is not running. D is wrong because init 5 is used to shut down the operating system altogether. E is incorrect because by issuing init 6 you will stop the operating system and reboot. |
|
|
þ F. All of the answers are correct. Disabling user logins can be accomplished by creating a /etc/nologin file, bringing the system down to single-user mode (by issuing the init S or shutdown command with the default init state), and disabling user accounts individually with the Solaris Management Console (SMC) interface. |
|
The switch user (su) program usage (by default) is monitored.
|
|
|
|
Which of these techniques is used to detect and display superuser access attempts actively on the console?
|
|
|
|
The syslog daemon is located in which directory?
|
|
|
|
Which of these techniques can be used to capture unsuccessful login attempts?
|
|
Answers
|
þ A. True. The su program usage, by default, is already monitored through the /etc/default/su file as SULOG=/var/adm/sulog, and the syslog logging facility will determine whether or not to log all su attempts with the SYSLOG=YES entry. |
|
|
þ B. To detect and display superuser access attempts actively on the console in real time, uncomment the CONSOLE=/dev/console entry in the /etc/default/su file. ý C is wrong because by uncommenting the CONSOLE=/dev/console entry in the /etc/default/login file, you will disable remote superuser login access. The rest of the answers don't make sense. |
|
|
þ B. The syslog daemon that controls the logging facilities is located in the /etc/init.d directory as syslog. ý A and E are wrong because device-specific files are stored in the /etc and /devices directories, which are common targets for attackers to attempt to gain access to the operating system, especially for creating backdoors to the system. C is wrong because /usr/local is an example of a typical download directory used to store files and programs by the current user. D is wrong because /usr/asset is the working directory for ASET. |
|
|
þ B and C. Capturing unsuccessful terminal session login attempts is accomplished by creating a var/adm/loginlog file. To monitor all failed login attempts, edit the /etc/default/login file and make sure that the SYSLOG=YES and SYSLOG_FAILED_LOGINS=0 entries are uncommented. ý A is incorrect because by uncommenting the RETRIES entry in the /etc/default/login file and editing the SYSLOG_FAILED_LOGINS=some number you'll force the system to close the login connection after some predefined number of unsuccessful login attempts. |
|
ABCD Inc. is a chemical distribution firm that hired you to set up syslog on its Solaris 10 server to monitor all failed user login attempts as well as monitor uses of the switch user (su) program. What steps would you perform to provide the requested services? |
|
Answers
|
The first task that ABCD Inc. hired you to perform is to set up syslog to monitor all failed user login attempts. To do so:
The second task that the client requires of you is to monitor uses of the switch user (su) program. The su program usage, by default, is already monitored through the /etc/default/su file as SULOG=/var/adm/sulog, and the syslog logging facility will determine whether or not to log all su attempts with the SYSLOG=YES entry. Therefore, you must ensure that the SYSLOG=YES entry is uncommented in the /etc/default/login file. At that point, monitoring the output in the sulog file is accomplished by viewing the file with a command such as more /var/adm/sulog from the terminal. The su logging in the /var/adm/sulog file entries displays useful information, including the date and time that the command was executed, whether or not the su attempt was successful, the port from which the su program was executed, and the user name that ran the program as well as the user name to which the user switched. This file should be monitored on a regular basis to pinpoint potential malicious access attempts. |
|
|
