| Under Auditing and Security, you manage the security of your system. This is becoming an increasingly important aspect of system management. Some installations care very little about security because of well-known, limited groups of users who will access a system. Other installations, such as those connected to the Internet, may go to great pains to make their systems into fortresses, with firewalls checking each and every user who attempts to access a system. I suggest that you take a close look at all the ramifications of security, and specifically a trusted system, before you enable security. You'll want to review the "Managing System Security" section of the "Administering A System" chapter of the Managing Systems and Workgroups manual, which replaces the 10.x manual HP-UX System Administration Tasks Manual. Although SAM makes creating and maintaining a trusted system easy, a lot of files are created for security management, which takes place under the umbrella of Auditing and Security. Among the modifications that will be made to your system, should you choose to convert to a trusted system, is the /etc/rc.config.d/auditing file, which will be updated by SAM. In addition, passwords in the /etc/passwd file will be replaced with "*," and the encrypted passwords are moved to a password database. All users are also given audit ID numbers. Figure 11-20 shows the menu hierarchy of Auditing and Security. Figure 11-20. Auditing and Security Menu Structure  One choice to observe in Figure 11-20 is an Actions menu choice to Unconvert the System. This means to reverse the trusted system environment. I have tried this on various systems and it seems to work fine, but you should have a good idea of what a trusted system can do for and to you before you make the conversion. I hope that I have given you a reasonably good overview of Auditing and Security, because in order to investigate it yourself, you must first con-vert to a trusted system. Before you do, please read this section to get an idea of the functionality this will provide and then convert to a trusted system if you think there is adequate benefit. Audited Events and Audited System Calls Under Audited Events, you can select the particular events you wish to analyze and detect, which may cause security breaches. Under Audited System Calls, you can monitor system calls. This option is a function of the trusted system to which you must convert in order to perform auditing. You may have in mind particular events and system calls that are most vital to your system's security that you wish to audit, and not bother with the balance. There are a number of events and system calls that you may wish to keep track of for security reasons. Auditing these events gives you a detailed report of each event. The same is true of system calls. SAM uses the auditing commands of HP-UX, such as audsys, audusr, audevent, audomon, and audisp, to perform auditing. Audited Users Under Audited Users, you can use the Actions menu to turn auditing on and off for specific users. Since the audit log files, which you can also control and view through the Actions menu, grow large very quickly, you may want to select specific users to monitor to better understand the type of user audit information that is created. Authenticated Commands This security feature is the ability to perform authentication based on user, password, session, or account. This industry-standard authentication framework is known as the Pluggable Authentication Module, or PAM. The PAM framework allows for authentication modules to be implemented without modifying any applications. Authentication is currently provided for CDE components, HP-UX standard commands, trusted systems, and DCE (the Distributed Computing Environment), as well as third-party modules. System Security Policies The most important part of HP-UX security is the policies you put in place. If, for instance, you choose to audit each and every system call, but don't impose any restrictions on user passwords, you are potentially opening up your system to any user. You would be much better off restricting users and not worrying so much about what they're doing. Being proactive is more important in security than being reactive. Password Aging Policies, when enabled, allows you to set: Time between Password Changes Password Expiration Time Password Expiration Warning Time Password Life Time Expire All User Passwords Immediately
General User Account Policies, when enabled, allows you to specify the time at which an account will become inactive and lock it. In addition, you can specify the number of unsuccessful login tries that are permitted. Terminal Security Policies allows you to set: Number of unsuccessful Login Tries Allowed Delay between Login Tries Login Timeout Value in Seconds Required Login upon Boot to Single-User State
|
