| Solaris Security Toolkit 4.2 Administration Guide |    
|
| Solaris Security Toolkit 4.2 Administration Guide |
|
| C H A P T E R 2 |
|
Securing Systems: Applying a Methodology |
This chapter provides a methodology for securing systems. You can apply the Solaris Security Toolkit process before securing your systems using the software.
This chapter contains the following topics:
Proper planning is key to successfully using the Solaris Security Toolkit software to secure systems. The planning phase constructs a Solaris Security Toolkit profile for the system, based on an organization's security policies and standards, as well as the application and operation requirements of the system. This phase is divided into the following tasks:
Although not covered in this book, other considerations for this phase might include understanding risks and exposures; understanding infrastructure and its security requirements; and considering accountability, logging, and usage auditing.
When hardening systems, special precautions must be taken to help ensure that the system is functional after the Solaris Security Toolkit software is implemented. It is also important that the process be optimized to ensure any downtime is as brief as possible.
This section presents considerations that must be clearly understood before you attempt to secure a system. Carefully weigh the risks with the benefits to determine which actions are appropriate for your organization.
1. Understand the requirements of the services and applications on the system.
You must identify the services and applications running on a system prior to running the Solaris Security Toolkit software. Any dependencies associated with the services and applications must be enumerated so that the configuration of the Solaris Security Toolkit software can be sufficiently adjusted. Failure to do so could disable services or prevent necessary services from starting. While the changes made by the Solaris Security Toolkit software can in most cases be undone, developing a correct profile before installation limits the potential downtime associated with the Solaris Security Toolkit software implementation.
2. Take into account that the system must be taken offline and rebooted.
For the changes made by the Solaris Security Toolkit software to take effect, the system must be rebooted. Depending on how vital the system is, the services that it provides, and the availability of a maintenance window, an organization might face difficulties implementing the software. A decision must be made after carefully weighing the cost of downtime versus the risks of not enhancing security.
3. A system might require multiple reboots to verify functionality.
Whenever possible, make all changes on nonproduction systems prior to implementing the systems in a mission-critical setting. This is not always possible; for example, due to lack of sufficient hardware or software that effectively mirrors the target environment. Testing must be conducted both before and after execution of the Solaris Security Toolkit software through hardening. There could still be unidentified dependencies that require troubleshooting after a system is hardened. In most cases, these issues can be resolved fairly quickly using the techniques described in this chapter. If functionality problems are discovered after the Solaris Security Toolkit software execution, additional platform reboots might be necessary to either undo the effects of the Solaris Security Toolkit software or to make further changes to the security configuration of the system to support and enable the missing functionality.
4. Platform security entails more than just hardening and auditing.
When considering retrofitting a system's configuration to enhance its security posture, it is critical to understand that platform hardening and auditing represent only a fraction of what can and should be done to protect a system, services, and data. A treatment of the additional measures and controls is outside the scope of this document, but you are encouraged to consider issues related to account management, privilege management, file system and data integrity, host-based access control, intrusion detection, vulnerability scanning and analysis, and application security.
5. The system might already have exploitable vulnerabilities or have been exploited.
The platform being hardened might have already been exploited by an attacker. The Solaris Security Toolkit software is probably being implemented too late to offer protection for an exploited vulnerability. In the case of an exploited vulnerability:
b. Install the Solaris Security Toolkit software.
c. Use the Solaris Security Toolkit software to enhance security.
The first task in securing a system is to understand your organization's relevant security policies, standards, and guidelines with respect to platform security. Use these documents as the foundation of your Solaris Security Toolkit's profile, because these documents communicate requirements and practices to be followed for all systems in your organization. If your organization does not have documentation, developing it increases your ability to customize the Solaris Security Toolkit software.
|
Note - When looking for these documents, keep in mind that some material might be listed in best practices or other documentation. |
For more information on security policies, refer to the Sun BluePrints OnLine article "Developing a Security Policy." This document can be used to gain a greater understanding of the role that security policies play in an organization's security plan.
The following two examples illustrate how policy statements can directly impact the way that the Solaris Security Toolkit's profile is configured.
Policy - All users are forced to change their passwords every 30 days.
Profile Impact - The Solaris Security Toolkit software can be configured to enable password aging. The secure.driver in the Solaris Security Toolkit software sets a password maximum age to 8 weeks (56 days). To comply with the policy, the Solaris Security Toolkit software's profile must be changed. Refer to the Solaris Security Toolkit 4.2 Reference Manual.
Although the secure.driver in the Solaris Security Toolkit software enables password aging when run on a system, this change does not affect existing users until they change their password. To enable password aging for existing users, invoke the passwd(1) command on each user account. To force existing users to change their passwords, you can use the passwd -f command. For more information about the passwd(1) command, refer to the Solaris 10 OS Reference Collection.
This task ensures that services remain functional after a system is hardened. This task is comprised of the following steps:
Inventory the applications, services, and operational or management functions. This inventory is necessary to determine the software that is actually being used on a system. In many cases, systems are configured with more software than is used and with software that does not support business functions.
Systems should be constructed minimally whenever possible. That is, software that is not required to support a business function should not be installed. Unnecessary software applications on a system increase the number of opportunities that an attacker can use to exploit the system. Additionally, more software on a system usually equates to more patches that must be applied. For information on minimizing the Solaris OS, refer to the Sun BluePrints OnLine article "Minimizing the Solaris Operating Environment for Security." For information on minimizing Sun Fire systems domains, refer to the Sun BluePrints Online articles ""Part I: Minimizing Domains for Sun Fire V1280, 6800, 12K, and 15K Systems," and "Part II: Minimizing Domains for Sun Fire V1280, 6800, 12K, and 15K Systems."
When building the inventory of software, be sure to include infrastructure components such as management, monitoring, and backup software in addition to applications residing on the system.
After you complete an application and service inventory, determine if any components have dependencies that could be impacted by the hardening process. Many third-party applications do not directly use services provided by the Solaris OS. For those applications that do, the following sections provide helpful information.
|
Note - All of the examples in this section are from the Solaris 9 OS. |
It is important to understand which libraries are needed to support an application. This knowledge is most useful in debugging circumstances, but also is useful in preparing a system to be hardened. When the state of a system is unknown, gather as much information as possible so that issues such as software dependencies are clearly understood.
You can use three methods to determine which libraries are used by an application, depending upon the Solaris OS version you install. This section shows a code example for each method.
To obtain information about a file system object, use the /usr/bin/ldd command.
For example, determine the libraries that are needed to support the Domain Name System (DNS) server software.
To collect the information from a running process, use the /usr/proc/bin/pldd command (available on Solaris OS versions 8, 9, and 10).
The pldd command shows the shared libraries that are loaded dynamically by the application, in addition to those against which the application is linked. This information can also be gathered using the following truss command.
This version of the output contains the process identifier, the system call (in this case, open) and its arguments, as well as the system call's return value. Using the return value, it is clear when the system call is successful in finding and opening the shared library.
Once the list of shared libraries is known, use the following command to determine the Solaris OS packages to which they belong.
# grep "/usr/lib/dns/cylink.so.1" /var/sadm/install/contents /usr/lib/dns/cylink.so.1 f none 0755 root bin 63532 24346 \ 1018126408 SUNWcsl |
The resulting output, indicates that this shared library belongs to the SUNWcsl (Core, Shared Libs) package. This process is especially useful when performing platform minimization, because it helps to identify the packages that are required to support an application or service.
Another way to gather requirements is through configuration files. This process has a more direct impact on how a system is hardened, because configuration files can be renamed or removed to disable services. For more information, refer to the Solaris Security Toolkit 4.2 Reference Manual.
To determine if a configuration file is in use, use the truss command.
In this example, the DNS service uses configuration files such as /etc/named.conf. As with the previous example, if the return value of a service indicates an error, there might be a problem. Carefully documenting the results both before and after hardening can help to speed the entire validation process.
This category includes frameworks or meta services on which larger, more complex applications are built. The types of frameworks typically found in this category are:
It is not always clear when an application depends on these types of services. When special adjustments are needed to configure an application, such as when adding it to a Kerberos realm, the dependency is known. However, application dependencies do not always require any added tasks, and the actual dependency might not be documented by the vendor.
One such example is the RPC port mapper. The secure.driver in the Solaris Security Toolkit software disables the RPC port mapper. This action might cause unexpected behavior in other services relying on this service. Based on past experiences, services abort, hang, or fail depending on how well the application's code is written to handle exception cases. To determine if an application is using the RPC port mapper, use the rpcinfo command. For example:
The service column is populated with information from the /etc/rpc file or a configured naming service, such as LDAP.
If this file does not have an entry for a service, as is often the case for third-party products, the service field might be empty. This makes it more difficult to identify applications registered by other applications.
For example, consider the rusers command. This command relies on the RPC port mapping service. If the RPC port mapper is not running, the rusers command appears to hang. The program eventually times out with the following error message:
This problem occurs because the program cannot communicate with the service. After starting the RPC port mapping service from /etc/init.d/rpc, however, the program immediately yields its result.
As another example, consider the case where the RPC port mapping service is running, and the rusers service is not configured to run. In this case, a completely different response is generated, and it is relatively straightforward to validate.
# rusers -a localhost localhost: RPC: Program not registered # grep rusers /etc/rpc rusersd 100002 rusers # rpcinfo -p | grep rusers <No output generated> |
Given that the rpcinfo command does not have a registry for the rusers service, it is safe to assume that the service is not configured to run. This assumption is validated by looking at the service entry in the /etc/inet/inetd.conf.
# grep rusers /etc/inet/inetd.conf # rusersd/2-3 tli rpc/datagram_v,circuit_v wait root /usr/lib/netsvc/rusers/rpc.rusersd rpc.rusersd |
The comment mark (#) at the beginning of the service line indicates that the rusers service is disabled. To enable the service, uncomment the line and send a SIGHUP signal to the /usr/sbin/inetd process as follows.
|
Note - The pkill command is only available in Solaris OS versions 7 through 10. For other versions, use the ps and kill commands respectively to find and signal the process. |
Another way to determine if an application uses the RPC facility is to use the ldd command described earlier.
The entry for librpcsvc.so.1 indicates, along with the file name, that this service relies on the RPC port mapping service.
In addition to the RPC port mapper, applications might rely on other common OS services such as FTP, SNMP, or Network File System (NFS). You can use similar techniques to debug these services and to determine if they are actually needed to support a business function. One method involves using the netstat command as follows.
This command returns a list of services that are or were recently in use, for example:
In this example, many services are in use, but it is unclear which ports are owned by which services or applications. This information can be collected by inspecting the processes using the pfiles(1) command (available on Solaris OS versions 8, 9, and 10). The pfiles command reports information for all open files in each process.
# for pid in `ps -aeo pid | grep -v PID`; do > pfiles ${pid} | egrep "^${pid}:|sockname:" > done |
A more effective and efficient way to determine these dependencies is by using the list open files (lsof) command.
Download the lsof source code from:
ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/
Download the lsof binaries from:
The lsof command determines which processes are using which files and ports. For example, to determine which processes are using port 35047 from the previous example, use the following command.
The output of lsof indicates that port 35047 is in use for communication between the dtexec and ttsession processes.
Using the lsof program, you might be able to more rapidly determine intersystem or interapplication dependencies that require file system or network usage. Nearly everything that is addressed in this section can be captured using various options of the lsof program.
|
Note - The methods described for determining dependencies might not find rarely used items. In addition to using these methods, review Sun documentation and vendor documentation. |
After you complete the planning and preparation phase, develop and implement a security profile. A security profile consists of related configuration, hardening, and secure drivers, for example, name-{config|hardening|secure}.driver, scripts, and files to implement your site-specific security policies.
Customize one of the security profiles provided with the Solaris Security Toolkit software, or develop your own. Each organization's policies, standards, and application requirements differ, even if only slightly.
To customize a security profile, adjust its actions through finish scripts, audit scripts, environment variables, framework functions, and file templates.
See the following chapters for more information:
As needed, see other chapters of the Solaris Security Toolkit 4.2 Reference Manual for information about scripts, framework functions, environment variables, and files. Two key environment variables you might want to customize are JASS_FILES and JASS_SCRIPTS.
To enforce standards across a majority of platforms while still providing for platform-specific differences, use a technique known as nested or hierarchical security profiles. For more information, refer to the Solaris Security Toolkit 4.2 Reference Manual. Compare the resulting security profile with the policies, standards, and requirements of your organization to ensure that changes are not inadvertently or erroneously made.
The installation of the Solaris Security Toolkit software is the same for both deployed and new systems that are being installed. For detailed instructions, see Chapter 3.
For deployed systems, a few special cases can make this process simpler and faster. These cases are not focused on the hardening process, but are focused on preinstallation and post-installation tasks.
Before hardening a deployed system, consider and plan two significant tasks:
These tasks help to determine the state of the deployed system and to work out any potential configuration problems before the system is hardened.
This task focuses on contingency planning. In the event of a problem, it is necessary to ensure that the system's configuration and data are archived in some form. You must:
Take these steps before making any significant change to a system's configuration.
The verification task is nearly as important as the backup task. Verification ensures that the system is in a stable and working state prior to the implementation of any configuration changes, such as those made by the hardening process. This verification process involves:
While having a well-defined test and acceptance plan is preferred, plans might not always be available. If that is the case, test the system in a reasonable way based on how it is used. The goal of this effort is to ensure that the running configuration, in fact, matches the saved configuration.
Investigate any error messages or warnings that are displayed when the system boots or an application starts. If you cannot correct the errors, log them so that during the hardening process they are not included as potential causes of problems. When looking at the log files, be sure to include system, service, and application logs such as:
This task is complete when you can restart the system without encountering errors or warning messages, or without encountering any unknown errors or warnings; all known ones have been documented. The system should restart to a known and stable state. If, during the course of verification, you discover that the running and stored configurations of the system differ, reassess your organization's change control policies and processes to identify the gap that leads to that condition.
The post-installation task is an extension of the preinstallation tasks. The goal is to ensure that the hardening process did not cause any new faults to the system or applications. This task is primarily conducted by reviewing system and application log files. The log files created after hardening and the subsequent reboot should be similar to those collected before the system was hardened. In some cases, there might be fewer messages, because fewer services are started. Most importantly, there should be no new error or warning messages.
In addition to reviewing log files, test the functionality, because some applications might fail without generating a log entry. See the following section for detailed verification information.
The final task in the process of securing a system involves verifying that the applications and services offered by the system are functioning correctly. This task also verifies that the security profile successfully implemented the requirements of the security policies. Perform this task thoroughly and soon after the reboot of the hardened platform, to ensure that any anomalies or problems are detected and corrected immediately. This task is divided into two subtasks: verifying security profile installation and verifying application and service functionality.
To verify that the Solaris Security Toolkit software installed the security profile correctly and without error, review the installation log file jass-install-log.txt. This file is installed in /var/opt/SUWWjass/runs under the directory that is unique to each hardening or audit run (start time of the run).
In addition to verifying that the profile is installed, assess the security configuration of the system. Perform a manual inspection or use a tool to automate the process.
To verify process applications and services, execute a well-defined test and acceptance plan. This plan exercises the various components of a system or application to determine that they are available and in working order. If such a plan is not available, test the system in a reasonable way based on how it is used. The goal of this effort is to ensure that the hardening process in no way affected the ability of applications or services to perform their functions.
If you discover that an application or service malfunctions after a system was hardened, determine the problem by reviewing the application log files. In many cases, you can use the truss command to determine at what point an application is having difficulty. Once this is known, you can target the problem and trace it back to a change made by the Solaris Security Toolkit software.
A common mistake that many organizations make is addressing security only during installation, then rarely or never revisiting it. Maintaining security is an ongoing process. System security must be reviewed and revisited periodically.
Maintaining a secure system requires vigilance, because the security configuration for any system becomes increasingly open over time. For example, system vulnerabilities become more known.
The following basic guidelines provide an overview of maintaining system security:
Solaris OS patches might install additional software packages as part of their installation and could overwrite your system configuration files. The Solaris Security Toolkit software can assist you with applying patches, because it supports repetitive runs on a system, so that you can secure the system after installing patches. Run the software after any patch installation, with the applicable drivers, to ensure that your configuration remains consistent with your defined security policies. In addition, perform a manual review of the system, because the version of the Solaris Security Toolkit software being used might not support the new features added by the installed patches.
The Solaris Security Toolkit software includes default security profiles for use as a starting point.
| Solaris Security Toolkit 4.2 Administration Guide | 819-1402-10 |
|
Copyright © 2005, Sun Microsystems, Inc. All Rights Reserved.