|
|
United States-English | |
|
|
 |
|
HP Open Source Middleware Stacks White Paper:: Security of Open Source Middleware Stacks
Advanced Security |
|
|
The previous sections describe a basis for configuring and maintaining secure systems. Configuring installed components in a secure manner, minimizing their exposure to network risks, and maintaining patches reduces the risks components face. The initial security practices described previously do not require tools outside of the main middleware stack, although tools such as Bastille help you to do the job right. This section describes a set of security tools and techniques that are secondary to the primary purpose of a middleware stack. These tools are extraneous to the installed components, yet they operate in support of the primary components by bolstering their reliability through security. This section includes the following topics: Intrusion management attempts to mitigate security breaches. To mitigate a breach, you must detect unauthorized system access as quickly as possible. Intrusion begins with a weakness. Theoretically, if there is no weakness, there can be no breaches. Unfortunately, weaknesses do exist and even apparently secure systems might contain unnoticed weaknesses that remain even after the most diligent audits. Moreover, new software, new hardware, or new personnel can introduce additional issues. The following are just some of the methods for mitigating an attack:
The section“Essential Security” described a bastion host, which is an isolated, fortified system that provides services to untrusted clients and is, therefore, exposed to risk of attack. Such a system is best isolated in a DMZ to reduce threats to other systems and to protect the other systems in case the bastion host is compromised. Using chroot, a standard command line tool, can provide a similar environment, only this time the isolation is within a system. The files available to processes are limited by isolating risky processes into what are known as “chroot jails.” Placing processes in a self-contained environment limits an intruder's access to a minimal subset of the system internals. In this way, the principle of least privilege is enforced. Protecting the contents of sensitive data stores is essential. Encryption can reduce the risk of exposing sensitive data. Tools such as GnuPG can encrypt files that need protection. A secure design of the encryption process, especially when working with the encryption keys, is essential. The resulting data store can contain information that is unreadable except by clients who possess the encryption key. The goal of intrusion detection is to detect the signatures of known attacks. Unfortunately, intrusion detection is ineffective against previously unknown attacks. Because intrusion detection cannot detect unknown attacks, it provides the same level of security as an up-to-date system. However, when you cannot patch a system due to patch conflicts, delays in testing the patch, or patch unavailability, an intrusion detection system can serve as a stopgap. However, from a security standpoint, it is better to patch vulnerabilities than to try to block their exploits. Several well-known intrusion detection projects exist within the open source community. One such project is Snort, a signature-based intrusion detection system. For more information, see the Snort Web site at: This section includes the following topics: You can secure only what you can control. This seems obvious, yet the UNIX file system design (hereafter called POSIX), upon which Linux is based, secures all files in the system at the discretion of the file owner. No system or policy control exists over a user's ability to change permissions for files the user owns. Users can even grant ownership permissions to their own files; thereafter, they themselves do not retain control of the file. Allowing users to set file permissions in this way is termed discretionary access control (DAC). The POSIX permission system also provides ultimate privilege to the root user to enable the administration of all system needs. However, the presence of the root user presents a paradox, because files might exist to which users with root accounts should not have privilege. For example, the system administrator should not be able to read personnel files containing employee medical information. The ability of a system to enforce access control policies on every user, including root, and to disallow users from changing permissions is called mandatory access control (MAC). POSIX uses access control lists (ACLs) to determine which users and process can access items on the system. These lists have limited ability to enable fine-grained permission schemas and advanced access control models. There are two types of lists: minimal ACLs, which have three entries and are the most familiar, and extended ACLs, which have more than three entries, provide a slightly finer-grained control, and are more complex to administer. There are many access control models that are not described in this white paper. Many of these models implement a Multi-Level-Security model (MLS), which is a MAC-based model with a military-like security and confidentiality level system. The role of MLS systems is to enforce the segregation of different categories of security types such as Top-Secret, Secret, Confidential, and Unclassified. Users, processes, and files are assigned these clearance levels and the system makes access decisions based on a comparison of the security level of each. For example, a user must have a Top-Secret clearance to access a Top-Secret file. Perhaps the most flexible access control model, which is a superset of all other models, is role-based access control (RBAC). This model enables the decoupling of various entities allowing them to be modified “on the fly” without extensive refactoring. For more information, see the NIST RBAC Web site at: Figure 9 is a classic view of the RBAC model, showing the relationships among permissions on operations and objects, and the sets of roles that have permissions for them. Roles are similar to UNIX groups, but they are more flexible. Adding and removing users has less of an impact. Advanced RBAC models include the ability to inherit permissions from other roles and to govern the abilities given to users during a particular session. The issues with the POSIX DAC model prevent absolute control over file access. A secure system should not allow users to change file access in a capricious manner. Additionally, the root user must be subject to access control. A secure access control method needs to supersede the controls given to users, including the root user, and it must enforce MAC, Multi-Level-Security, and even RBAC. Advanced access control systems, such as SELinux and AppArmor, provide this level of security. To enable fine-grained access control, eliminate the security issues surrounding the superuser, and provide MAC, the Linux permission model needed to be replaced. The new system needed to provide MAC, yet the DAC model found in most POSIX systems needed to remain for backwards compatibility. Additionally, other security projects needed support to align with the open source community’s commitment to modularity and diversity, and access control needed to occur at the kernel level for greater security. The solution for providing modularity is Linux Security Modules (LSM), which creates an agnostic base of kernel hooks. These hooks enable various access control policies to implement a similar, generic framework of kernel access control calls. The National Security Agency (NSA) funded research of the Security Enhanced Linux (SELinux ) to provide security for medium-need systems. SELinux implements the LSM kernel modules and provisions robust MAC and RBAC controlled systems managed by fine-grained, customizable security profiles. According to the NSA Security-enhanced Linux Team:
The downside of the SELinux virtually infinite fine-grained permission model is that a complex security policy is required to manage the system. For more information, see the NSA SELinux Web site at: As previously mentioned, the LSM design intentionally creates an agnostic framework, implemented by various access control designs. SELinux is one such implementation and AppArmor is another. As with SELinux, AppArmor implements the LSM and enforces MAC through the use of configurable security policies. AppArmor provides fine-grained control of the system access control. For more information, see the openSUSE AppArmor Web site at: The main difference between AppArmor and SELinux is the means by which each identifies items at the atomic level. AppArmor does so by using pathnames, whereas SELinux uses traditional POSIX inodes for identification. The pathname method provides a more human-friendly description of the items, but it is vulnerable to a carefully created symbolic link. Although using inodes for unique identification avoids the symbolic link risk, identifying items with inodes can be overly complex, leading to security holes due to misconfiguration. Red Hat currently includes SELinux, while the SUSE Linux distribution provides AppArmor. The order of complexity for the two LSM implementations is:
It is difficult to detect a compromised system. As soon as an attack succeeds, the attacker will attempt to keep access to the compromised system while avoiding detection. Systematic auditing is necessary to discover traces of attacks through unauthorized changes. For example, Tripwire is an auditing tool that checks for signs that an intrusion has occurred. For more information, see the Tripwire Web site at: Often an attacker will place a rootkit on the system to facilitate ongoing control and evasion of detection. Rootkits are sets of applications that alter the very nature of a system, and they are extremely difficult to detect and remove. Rootkits prevent a system from reporting the existence of the rootkit and other files, such as backdoors, key-logging tools, FTP servers, and spam engines left behind by the attack. To ensure that the tools you use are viable, you must not trust the tools on a system you suspect has been breached. A live CD solution enables you to examine the suspected system safely and accurately. Security Tools Distribution (SDT) is an example of a live CD that provides tools for forensic analysis. For more information, see the STD Web site at: |
|||||||||||||||||||||||||||||||||||||||||||||||||||
 Printable version |
|
|
|
|
|
|||||||||||||||
|
|||||||||||||||
