HP Open Source Middleware Stacks White Paper: Security of Open Source Middleware Stacks Printed in the US HP Part Number: 5991–7435 Published: October 2006 Edition: 1.
© Copyright 2006 Hewlett-Packard Development Company, L.P. Legal Notice Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor's standard commercial license. The information contained herein is subject to change without notice.
Table of Contents Introduction..............................................................................................................................................5 Executive Summary..............................................................................................................................5 Intended Audience...............................................................................................................................5 Scope and Purpose .............................
Introduction Executive Summary Deployed Linux-based HP Open Source Middleware Stacks (OSMS) is an individual system composed of various components, configurations, and services. OSMS are a viable alternative to proprietary computer systems. When deployed, each system faces unique vulnerabilities and threats. Therefore, security cannot be applied to every system in the same way. No single security solution applies to all systems.
Figure 1 Security Issues White Paper Organization Information is organized in general technology topics, such as security background, essential security information, and advanced security information. Additionally, each section contains links to both introductory and advanced material, when applicable. Examples that have direct application to securing OSMS are shown as follows: OpenSSL (http://www.openssl.
Defining Security Your first challenge is to understand what computer security means. This is important because security is often misunderstood. Often the term security is seen as an extension of reliability because insecure computers interrupt your dependency upon computers. Obviously, systems must be secure to be reliable, yet the term “secure” is often used incorrectly as an absolute measure of this reliability, as if nothing could ever go wrong. Security, like reliability, is not so black-and-white.
secure an OSMS environment, you must consider the threats to which both layers might be exposed, consider what risks these threats pose, and then determine which processes might reduce the risks to an acceptable level. Areas of Concern Confidentiality—Concerns controlling who may access particular information, such as limiting which employees are permitted to view confidential corporate information or preventing an eavesdropper from recording a network transaction.
security measures.
Steps for Securing Computer Systems After creating a security policy, you can begin the task of applying the policy. Perform the following steps on an ongoing basis to ensure the security policy is applied throughout the life of the systems. 1. Identify: Determine the required security level of each computer system, component, or service based on the item's importance (as specified in the security policy) and the degree of risk to which each item might be exposed in its deployed environment. 2.
• Follow the principle of least privilege: — This principle is to deny all privileges, except those that are explicitly allowed. In other words, deny access to users and processes first, and then grant privileges on a case-by-case basis only when needed, in accordance with the security policy. — Services that run under root privilege enable a compromised process to have authority over the entire system. Instead, create a user for each process and assign ownership of only the resources each user needs.
In view of this, secure software contains no risks, as defined by your policy, and it contains no issues that are exploitable. Therefore, truly secure software does not exist, because it is not possible to prove any software is void of flaw. You must always assume software contains undiscovered security issues. Proprietary and open source code are no different in this respect. This statement might appear rather bold; however, this is a perspective you must realize when securing computer systems.
Figure 4 Incidents Per Year Also, there are other exploits that are not yet widespread or well known, but are equally potent. For example, vigilant patching does not prevent a zero day attack. These exploits are too new, and a patch does not exist to fix the flawed software they exploit. Similarly, other security techniques that rely on the prior knowledge of vulnerabilities and exploit signatures cannot protect a system from zero day attacks.
amount of time. This period is continually shrinking, with time from the announcement to the time of discovering an exploit typically being less than one day , as shown in Figure 5. This grants crackers the luxury of not searching for vulnerabilities themselves; they can rely on the computer security infrastructure to inform them of the best targets.
Figure 7 Threat Risk to Hardened System It is unwise to assume that there is plenty of time to deploy security patches after they are available. The vulnerability life cycle can be well underway and unpatched systems are extremely vulnerable, so you should always apply security patches immediately. Unfortunately, significant numbers of systems remain unpatched after a patch is available.
vulnerable components or systems could be confined so they cannot access sensitive information or affect other computers. Timely vulnerability information is critical. To track important security issues related to OSMS components, subscribe to any security announcement mailing lists that may be available. The following are a few examples for you to consider: Red Hat— https://www.redhat.com/mailman/listinfo/enterprise-watch-list SuSE— http://www.suse.
Addressing Configuration Weaknesses Regardless of which operating system or components might be present, your system’s security depends on the state of its deployed configuration. A misconfigured system can undermine all other security designs. The following is a list of configuration “best practices.” Following these essential practices can help you avoid many common security pitfalls in newly installed systems. Password management tasks • • Do not retain default passwords for any component or account.
• Prohibit shared accounts and generic account names, which defeat non-repudiation. — Lost knowledge of exactly who is using an account prevents accountability from being a deterrent. — Accounts such as tester, guest, and admin defeat non-repudiation, and make user account names easy to guess. • Log failed login attempts. Auditing the logs alerts you to password-guessing attack activity. • Consider using certificate-based authentication.
used in a trusted network environment. In either case, remove them and use secure equivalents: SSH, SCP, SFS, and SFTP. • Remove all unneeded network services, which are services that are not explicitly used by the system. Also remove sub-component services that a particular configuration does not use. If services are needed only occasionally, you should stop them and prevent them from restarting upon system boot. Alternatively, use firewall rules to manage network access.
Additional Best Practices This section includes the following topics: • • • • “Use a Firewall” “Use Secure Communications” “Use Layered Security” (page 21) “Never Assume the System Is Secure” Use a Firewall Firewalls can explicitly limit network traffic using a variety of filtering methods. Often firewalls manage connections by port and network address, and only those connections explicitly granted access (through a white list) may pass through the firewall.
protection from a firewall, because you should never rely on any one defense in case the firewall is compromised. Trojans can thwart firewall security and attack from within the perimeter defenses. Linux is an ideal system with which to create a firewall. Using networking tools, such as iptables, any configured Linux machine is a firewall in its own right. However, it is best not to design and configure security alone, because any oversight leaves a system vulnerable.
attacker, and might provide enough time for the intrusion to be detected, or the multiple layers might provide enough protection that the system is difficult to breach. The following is an example Apache setup that has a layered security defense: • Require authentication to administer the host system, and provide non-repudiation and an audit trail. • Ensure that the Apache process does not run under root and also does not run using the same account that is used to administer Apache.
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.
Access Control Background 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.
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. Linux Security Modules To enable fine-grained access control, eliminate the security issues surrounding the superuser, and provide MAC, the Linux permission model needed to be replaced.
3. 4. Custom policy for AppArmor Custom policy for SELinux Monitoring and Forensic Tools 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.
DMZ Demilitarized zone. A firewall configuration that secures local area networks (LANs). exploits Tools and methods that prey upon a system's vulnerabilities. Viruses, worms, and Trojans are the automation of exploits. fingerprinting The unique information by which systems, components, OSs, and so on are identifiable. hacker A person interested in figuring out how things work by taking them apart and putting them back together in different, interesting, and (hopefully) better ways.
