Essential Security

After a vulnerability announcement, a flaw is likely to become a cracking target. Often, in an attempt to defuse this inevitability, a vulnerability announcement is delayed in order to coincide with the release of a patch to reduce the time for an exploit to be developed. This practice produces a false sense of security, because the actual start of the vulnerability life cycle can begin long before the announcement.

The discovery of security issues occurs in many ways. In the worst case, crackers discover the vulnerability rather than security experts, so systems become compromised even before work to fix the vulnerability begins. In the best case, knowledge of the vulnerability is known only to the security researcher and the developer. The developer does not divulge the existence of the vulnerability to prevent crackers from exploiting it until a fix is available. Meanwhile, the developer quickly develops and thoroughly tests a patch. Unfortunately, when the announcement of a vulnerability coincides with the release of the patch, a new threat arises. Crackers are adept at reverse-engineering patches and producing exploits in a short 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.

The following three figures represent the vulnerability lifecycle, which is a depiction of the risks a single system faces over time due to a single vulnerability. The goal of security is to reduce the amount of exposure time a system experiences a risk, and to reduce the degree of exposed risk. Figure 5 represents the system risks over time for an unmitigated system, one that has not been hardened or had security patches promptly applied. Figure 6 represents the reduction of system exposure time due to the prompt application of security patches. Figure 7 represents the reduction of system risk from carefully hardening the system configuration

Figure 5 Threat Risks to Unmitigated System

Figure 6 Threat Risks to Timely Patched System

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. The failure to apply patches in a timely manner unnecessarily extends the window of opportunity for attackers to exploit vulnerabilities.

Patching otherwise reliable systems represents a degree of risk. Introducing new software through a patch represents an unknown effect to the reliability of computer systems. This risk should be weighed against the security risk represented by the unpatched software. Testing for undesirable side effects reduces the risk of patch side effects and should be mandatory for any critical systems. However, timing is also a factor because the delay between vulnerability disclosure and patch application increases security risk.

Unlike proprietary software produced by a single entity, cooperating entities manage open source software development. This allows the open source community to be agile during the development process because each package developer can work independently. However, there is no omnipotent overseer ensuring the proper management of security processes.

Knowing whether a particular system, component, or library is vulnerable is critical in determining the current risks a system faces. The downside of the open source independent infrastructure is the lack of easy management of software vulnerabilities. Though there are various agencies that track vulnerabilities, it is problematic to determine definitively if an individual system is vulnerable at any given moment.

For example, a search for a component by package name and version produces naming conflicts. The CERT database attempts to correct this issue. However, the latency between the first report of a vulnerability and the appearance in this database poses significant exposure to new exploits, such as zero day attacks.

The open source development process is observable, so one solution available to system managers is to monitor the developer bulletin boards for critical system components and track vulnerabilities as they flow through the layers of open source organizations. Typically, vulnerabilities begin with an initial bug report submitted to the package maintainer, who confirms the submission, produces a security vulnerability announcement, creates a patch, and adds it to the current stable stream. Linux distributions then apply this fix to the OS packages in their distribution and make their own announcement.

Waiting for this patch announcement can leave a system vulnerable for an unnecessary period. Learning of a vulnerability as quickly as possible enables the implementation of other countermeasures. For example, 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.

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.

Keeping track of all the critical configurations is complex. Increasing this complexity is the fact that a system’s configuration needs change over time. For example, secure configurations often turn up as a default in future package releases, so systems no longer need special configurations during deployment. Conversely, new releases offer new functionality, and might require new security modifications. Because of these changing requirements, using a configuration tool makes sense. Give the important task of keeping configurations current to professionals in the security field.

The Bastille Linux open source project is ideal for securely configuring a system. Bastille is an interactive script, which examines the configuration of a system and suggests hardening changes. Two important goals of Bastille are:

Bastille is also customizable for specific systems. You can harden an OSMS environment to match a default configuration file, or you can use an extension of the Bastille defaults for a specific system. Bastille can configure several systems in the same manner, and it can perform security regression testing after making changes to a system.

Bastille guides you through the hardening process by explaining each security issue, allowing you to choose whether to implement a hardening configuration, explaining the consequences of each choice, and suggesting preferred choices. Bastille detects default passwords, enables the implementation of the principle of least privilege, removes suid programs, and provides a local system firewall, and it also mitigates many other security issues.

Bastille adheres to many security best practices. Properly configuring a system is complicated and requires a considerable amount of knowledge. Using Bastille simplifies this task and provides access to a collaboration of effort from others in the security field. Systems configured using Bastille benefit by not being overly complicated and by conforming to a well-formed configuration script that has been reviewed by others in the security field.

For more details, see the Bastille Linux Web site at:

http://www.bastille-linux.org

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. Typically, firewalls limit inbound connections; however, filtering outbound connections is also possible. Outbound (known as an egress firewall) protection is useful for preventing unauthorized connections from unknown local processes (for example, Trojan programs and other malware) or connections to risky external networks. Firewall must be placed between the network and the systems that need protection.

Hardware firewalls are located on the network and have the main task of filtering traffic for a subnet. Software firewalls are processes that reside on local machines and filter the connections to the local services. Software firewalls are vulnerable to attacks originating from the local machine. If an intruder gains access, the intruder might be able to subvert the firewall. Hardware firewalls are isolated and limited to the sole task of filtering, so are less likely to be compromised in this manner.

Software firewalls can even reside on local systems, for example, Bastille and Red Hat Linux firewalls can work in conjunction with firewalls positioned at the network gateway.

Network topologies that employ a demilitarized zone (DMZ) approach (see Figure 8) have layers of firewalls that offer different levels of protection and availability to systems as needed. This approach can limit the damage done by a successful attack by isolating the exposure to other systems.

Figure 8 DMZ Approach

The DMZ separates computers that face external hazards from other systems.

Remember, a secure system should not have access to unneeded services. This might mean that a service accessed only on the local network should have firewall rules denying access from connections that are not from the local network. If the service is not required at all, remove it instead of blocking access to it. Firewalls are just one defensive measure within a layered security approach. Do not rely solely on perimeter 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.

Firewall projects are active in the open source community. One firewall project designed for network deployment is the SmoothWall project, which is a hardened minimal Linux distribution expressly for use as a standalone firewall. SmoothWall holds a position in the network replacing the gateway router and performs many useful tasks in addition to firewalling, such as NAT, DHCP, logging, and even intrusion detection.

An additional means of containing an intruder through firewall protection is to not rely solely on the gateway firewall to prevent all attacks. This is done by enabling firewall rules on local systems that are behind the gateway provides an additional layer of protection. For this purpose, the Bastille project provides the means to filter access to services on individual machines. For instance, all connections to a MySQL database can be limited exclusively to those originating from the local Apache process, subverting remote MySQL attacks while enabling database services.

Cryptographically secure communication provides any or all of the following services: the confidentiality of network-transmitted data, integrity of the contents, and identity of senders or receivers. These services do not require concurrent use, so they should be deployed as needed.

The use of SSH is often mistakenly believed to be sufficient for achieving a secure system. Remember, a particular tool (even a well-known one) does not create a secure system. For instance, just because you notice that you are connecting to your bank across an encrypted connection does not mean that your personal data is not at risk. It might be true that the data cannot be discovered by listening to the connection, but the data is not protected if someone placed a key-logger on the computer you are using or you are “securely” connecting to a phishing Web site. SSH does not prevent the client from being attacked by the server it connects to or vice versa.

Sometimes, securing transmitted information entails ensuring that the information cannot succumb to eavesdropping attacks. Alternatively, the authenticity of entities might be required to ensure security and the integrity of transmitted information might need verification. All of these have cryptographic solutions, such as encrypted transmissions, authentication signatures, and content hashes.

To ensure the security of communication with a JBoss application server, you must implement point-to-point encryption of messages. Such methods typically use the Secure Socket Layer (SSL). OpenSSL is an open source project that implements SSL. Configuring JBoss with OpenSSL for secure message transactions, such as those used in shopping cart applications, is straightforward. However, do not forget to properly integrate a Public Key Infrastructure (PKI) system because without verifying certificates systems are still vulnerable to man-in-the-middle attacks.

Securing transmitted information might also involve the use of secure credentials and public or private key management techniques. Be aware that encryption relies greatly on proper key management. Using encrypted keys without a certification authority (CA) is a security risk. Using encrypted keys is similar to using passwords because it restricts access to only those who possess the keys. Encrypted keys must be generated carefully to ensure they are strong, and they must be carefully protected. Keys are used in many areas of security, including the confirmation of system and user identity during trusted transactions, locking and unlocking files for secure transfer, and providing password-like credentials. A valid CA, trusted by all agents in a transaction, must recognize the keys.

Using various techniques in a coordinated effort , often called security-in-depth, creates the most secure systems. Never depend on one layer of security; if a system has only one layer of security and that layer succumbs to penetration, the entire system is vulnerable to the security breach.

In a layered approach, if one layer fails, additional layers have the opportunity to contain the attack. The layers can augment each other, blanketing different weaknesses. A layered approach can slow down an 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. Use HTTPS for remote administration and commercial transactions, to guard against man-in-the-middle attacks through an encrypted communication protocol. Use a local firewall filter, which limits open ports and the set of IP addresses allowed for a connection. Do not display information about the serving protocol or platform to clients to avoid providing information for an attack vector. Refuse client connections after several unsuccessful logins to limit brute force attacks. Configure the Apache server within a chroot jail or run the www-data account to limit breaches.

It is tempting to believe that after all your configuration efforts, you have successfully created a secure system. However, the true test of whether your system is secure is when a hacker attempts to penetrate your carefully deployed defenses. You should try to break into the system and have someone who does not know the system do so, to simulate what an attacker might do to penetrate your defenses.

There are several open source tools to help you simulate hacker attacks. Two scanning tools effective in determining how robust your security implementation is are Nessus and Nmap. The Nessus tool uses a library of known exploit attack vectors to determine if a system is vulnerable to any of them. The library must be updated with new exploit vectors as soon as they are discovered, and it must be used periodically to ensure that systems continues to be secure.

The Nmap tool uses raw IP packets to determine available hosts on the network, what services (application name and version) those hosts are offering, what operating systems versions they are running, what type of packet filters and firewalls are in use, and other information. ^[3]

The problem with using scanning tools is that they can detect only known vulnerabilities. Exploits threaten a system for its life cycle, but unfortunately scanners cannot detect vulnerabilities that are not recognized. Therefore, although scanners are effective tools, other layers of security are required to ensure systems are less susceptible to unrecognized, yet real, vulnerabilities. For example, you could place exposed services in chroot jails and limit the privilege of their processes, which mitigates the risk of exposure to the rest of the system if they are compromised.

For more information regarding Nessus and Nmap, see the following Web sites:

http://www.nessus.org

http://www.insecure.org/nmap

Security is time sensitive. A system that appears to be secure can suddenly become insecure. This change can occur when change occurs in the Security Policy, a new package is installed, there are personnel changes, or configuration modifications are made. Additionally, a system that has no known vulnerabilities can suddenly become susceptible to attacks that use new methods to exploit a previously unknown vulnerability.

Security requires constant vigilance and maintenance. New vulnerabilities appear suddenly and the systems they affect must obtain patches or be removed from a risky environment at a moment's notice. Knowing the moment at which a system becomes vulnerable and having a predefined plan to deal with contingencies is critical.