HP OSMS white paper: Security of Open Source Middleware Stacks

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.com/us/private/support/online_help/mailinglists/
Apache—
http://httpd.apache.org/lists.html#http-announce
Systems run various versions of software, and distributions freeze the development stream for a given
distribution version. Unfortunately, a fix made at the beginning of the development stream might not be
compatible with all downstream versions of the vulnerable package. The fix might need to be backported
for earlier release versions. Different members of the community, from the package maintainer, to
distributions, to even members of the open source community at large might perform backporting to
release patches and patched binaries. This process can add confusion when you are trying to identify the
patches applied to a given binary version or determine a version's current vulnerability status. This situation
provides more impetus for tracking vulnerabilities “in process” instead of waiting for a patch alert.
Making Configurations Secure
A system must be prepared even for previously unknown attacks. Security hardening, confinement,
resource limitation, and other techniques protect systems from these unknown vulnerabilities. The following
sections describe the means by which you can minimize the risk a system faces from unknown attacks.
The second leading cause of system intrusion is misconfiguration. The initial installation of the system’s
operating system and components contain many defaults, such as account names, passwords, leftover
configuration scripts, and open file permissions, among other things. These loose ends represent a serious
security risk. You must perform further configuration to secure the system. Unfortunately, the leftover
defaults often remain for the life of the system and, because these defaults are common knowledge, they
provide an easy attack point for malicious intruders. The process of securely configuring a system is called
hardening. Hardening is so effective, it might even secure systems that host vulnerable software.
The best way to securely configure computer systems is to follow the guidance of experts in the security
community. One source of expert information is CERT, which provides a good overview of proper
configurations. After you understand the scope of the task, you apply specific security configurations to
each system. The Linux distributions and package maintenance security documentation provide details
about hardening.
Enterprise-grade open source components have security configuration guidelines within their
administration documents. Following these recommendations is paramount for securing each
component. For more information, see the following documents and Web page:
Red Hat Enterprise Linux 4 Security Guide:
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/security-guide/
Chapter 8. Security on JBoss of The JBoss 4 Application Server Guide:
http://docs.jboss.org/jbossas/jboss4guide/r1/html/ch8.chapter.html
“5.7. General Security Issues” section of theMySQL 5.0 Reference Manual:
http://dev.mysql.com/doc/refman/5.0/en/security.html
The Internet is rife with active attacks, so systems deployed without security configurations quickly
succumb to attack. Therefore, your security policy should require the secure configuration of all systems
before deployment to ensure that systems are not compromised while they await hardening.
Unfortunately, secure configuration is often done incompletely, done incorrectly, not maintained, or
avoided altogether. Deployed systems often have components that are accessible by default passwords,
unneeded services often continue to operate and respond to external network prompts, and an entire
system can be vulnerable through the breach of only one component.
16