This report, written in 2001, presents results of a detailed security audit of UNIX systems belonging to a fictitious company. It describes discovered vulnerabilities and proposes a prioritized roadmap for addressing them. Any similarities to an actual company or computing environment are purely coincidental. This document was submitted to SANS GIAC to fulfill UNIX Security Administrator (GCUX) certification requirements. (A PDF version of this paper is also available.)

1. Executive Summary
2. Analysis of Findings
3. Prioritizing Issues
4. Recommendations
5. References

1. Executive Summary

1.1. Project Goals

The objective of this document is to provide GIAC Enterprises, a fictitious company invented for the purposes of creating this case study, with a security assessment of its publicly accessible computer systems. We were commissioned to perform this audit to allow GIAC Enterprises to prioritize its infrastructure advancement efforts and to define a plan of improving its security practices. Due to time and budget constraints, our study focused on weaknesses in design and implementation of systems accessible from the Internet, with the assumption that other aspects of the infrastructure will be examined in subsequent surveys.

This document presents our findings regarding the security of the organization's UNIX-based servers that provide DNS, Web, and mail services. We explore operating system, third-party and configuration vulnerabilities, outline problems with administrative and system maintenance practices, and describe issues relating to the organization's security policy. Finally, we provide a prioritized list of security concerns and propose methods of addressing discovered problems.

1.2. Summary of Findings

Our findings and recommendations concentrate on security aspects of the organization's two critical servers accessible from the Internet. Our biggest concern is that a large number of packages installed on these systems are outdated, and contain known vulnerabilities that could be exploited to remotely obtain unauthorized access to the servers. Besides presenting a risk to critical resources, this suggests that GIAC Enterprises does not place sufficient attention on tasks and costs of maintaining systems to ensure reliability and security of their operations. This is also evident from the lack of thoroughly documented security policies and procedures that should describe operational issues associated with security of the organization's systems.

Treating information security as a process requiring ongoing attention, we would have liked to see more resources devoted to anomaly detection. An anomaly, in this context, constitutes an event, whether malicious or not, that negatively impacts performance or availability of a computing resource. The organization does not presently have means of automatically monitoring the "health" of its critical systems, which may result in a prolonged downtime due to an event that could have been noticed earlier via log or process monitoring. Similarly, intrusion detection systems can be used to monitor critical networks and systems for potentially malicious activity, allowing administrators to respond to events during reconnaissance stages of attacks before they escalate into critical incidents. Additionally, the network infrastructure at the organization's corporate office was not designed to segment the environment into security zones that might dampen an attacker's actions once one of the internal systems was compromised.

We were also concerned with some of the tape backup practices employed by GIAC Enterprises. Specifically, test restores from tape are never performed, which will prevent the organization from discovering a fault in the backup mechanism, resulting in the inability to recover lost data. Additionally, all backup tapes are stored in the corporate office, and are never taken away for off-site storage. This may result in a scenario where a local or regional disaster will prevent the organization from recovering its data and resuming operations within a reasonable timeframe. Our findings and recommendation are described in greater detail in subsequent sections.

2. Analysis of Findings

2.1. Infrastructure Overview

Figure 2-1 below summarizes the current state of network infrastructure at GIAC Enterprises. The firewall is located behind the router, which connects the organization to the Internet. All computing resources hosted at the organization's corporate office are located on the same network behind the firewall; this is a significant concern, since a compromise to a publicly accessible system may spread to other corporate servers and workstations.

Figure 2-1

The router is Cisco 3660, and the firewall is Cisco PIX 515. Computing resources are interconnected using a Cisco Catalyst 4006 switch. The firewall provides Network Address Translation (NAT), dynamically mapping outbound connections to the Internet to a block of public IP addresses assigned to GIAC Enterprises by its ISP; inbound one-to-one NAT is performed for servers that need to be accessed from the Internet.

For the purpose of our assessment, we grouped these resources into systems required for the organization's internal needs: corporate workstations and servers, as well as into publicly accessible servers that provide Domain Name System (DNS), Web, and mail services. Our analysis concentrates on servers accessible from the Internet: these are implemented as two Dell PowerEdge 6450 servers running Red Hat Linux 7.0. DNS services are provided by a system known as bluewiz, while Web and mail services are hosted on a single system known as redrum, as shown in Figure 2 2 below.

Figure 2-2

2.2. OS Vulnerabilities

Both systems that we examined were running custom installations of Red Hat Linux 7.0 as the underlying operating system (OS). A large number of security-related updates to the OS issued by Red Hat were not installed on the organization's servers. Detailed information regarding relevant Red Hat Linux 7.0 security advisories is available at the Red Hat support site.1 Figure 2-3 below lists applicable advisories that impact the operating environment of the analyzed servers.

Figure 2-3

In Figure 2-3 above we listed only patches to OS components that were installed on the analyzed servers; advisories related to third-party applications are discussed further in the document. Additionally, in Section 4: Recommendations we describe specific procedures for patching up the systems in the most efficient manner.

2.3 Third-Party Software

When performing our assessment, we examined third-party software installed on the bluewiz and redrum servers. Figure 2-4 below lists software components that are required for fulfilling business needs associated with these systems. Our analysis showed that these applications have not been patched to address known vulnerabilities. Critical nature of several discovered vulnerabilities could allow a remote attacker to gain access to internal systems.

Figure 2-4

As mentioned in Figure 2-4 above, the version of UW imapd running on redrum server could be exploited by authenticated clients to obtain interactive access to the host. Furthermore, vulnerabilities present in installed versions of sendmail and procmail, when combined with the imapd exploit, could allow an authenticated remote user to obtain root-level access to redrum server. Vulnerabilities present in Apache and related SSL libraries on redrum are not critical, although they could leak sensitive information to a determined attacker.

We are also concerned that the version of BIND running on the bluewiz server is vulnerable to a number of denial of service (DoS) attacks. Additionally, one of the bugs may allow an attacker to obtain privileges of the user named that the Web server process is running as; this could be used as a launching pad for further attacking bluewiz server as well as other systems behind the corporate firewall. Specifics for BIND bugs are listed at the Internet Software Consortium site.2 The impact of each relevant BIND vulnerability is presented in Figure 2-5 below.

Figure 2-5

2.4 Configuration Vulnerabilities

When examining configurations of systems in question, we were pleased to see that packages installed on the servers were primarily limited to applications and utilities that were necessary for the servers to function. A notable exception to this was knfsd and portmap packages, which were installed on both bluewiz and redrum, but were not running; we suggest removing them since these servers do not need to provide NFS or RPC functionality. We also recommend removing the xinetd package, since none of the xinetd-based services are being used.

Additionally, both servers that we analyzed were running the XFree86 and GNOME packages. The X Window System, in combination with GNOME provides graphical user interface (GUI) for various interactive applications. While GUI utilities often streamline system administration, we suggest considering removing these packages from the systems to minimize the number of applications that could be exploited by a determined attacker. Based on our conversations with the system administration staff at GIAC Enterprises, we believe that they will feel comfortable administering the systems from the command line after an initial learning period.

Both servers also had the Netscape Communicator package installed. There are a number of vulnerabilities associated with browsing the Internet from a critical server. At the same time, the Web browser may be useful for system administrators when viewing HTML-based documentation or accessing Intranet servers. Pending further assessment of the administrators' needs, we suggest not performing any tasks associated with the use of the Web browser from production servers, and removing the Netscape Communicator package from bluewiz and redrum.

Even though the version of BIND running on the bluewiz server was vulnerable to a number of attacks, we were pleased to see that BIND was configured in a manner that minimized impact of a successful compromise. Specifically, the named process was running in a properly chroot'ed environment consistent with recommended industry practices.3 However, a number of files in named's "jail" were left world-readable, instead of being accessible only to the named user.

BIND configuration properly restricted zone transfers to take place only between bluewiz and the organization's ISP; in this configuration, bluewiz acts as the maser server, while the ISP's DNS server offers redundancy by acting as a slave server. One option that was notably missing from the server's named.conf file was the allow-query tag—we suggest utilizing this command to restrict which clients may query the DNS server for external domain information.

The Apache configuration file /etc/httpd/conf/httpd.conf on redrum server was world-readable. We recommend making this file accessible only to the root user to ensure that configuration specifics of the Web server remain confidential. Additionally, the Apache server is currently configured to allow CGI script execution in any public HTML directory. We suggest removing the globally placed Options ExecCGI directive and using the ScriptAlias directive to limit which directories can host executable content on the Web server.4

2.5 Security Patches

As described above, a number of software packages installed on the bluewiz and redrum servers were not patched against known vulnerabilities. The process of updating these packages can be automated through the use of the Red Hat Update Agent that is already installed on affected systems. Moreover, the Update Agent can be used to determine which of the installed software packages are outdated. For instance, Figure 2-6 below shows an excerpt from the output of the "up2date --nox --list" command that we executed on the redrum server to list packages that may need to be updated.

# up2date --nox --list

 Name Version Rel
 ---------------------------------------------
 XFree86-VGA16 3.3.6 38
 gnorpm 0.95.1 6.7x
 libstdc++ 2.96 85
 man 1.5i2 0.7x
 mount 2.10r 5
 netscape-common 4.77 1
 netscape-communicator 4.77 1
 nfs-utils 0.3.1 7
 openssh 2.5.2p2 1.7.2
 openssh-clients 2.5.2p2 1.7.2
 openssh-server 2.5.2p2 1.7.2
 openssl 0.9.6 9
 perl 5.6.0 10a
 popt 1.6.2 7x
 procmail 3.21 0.71
 rhn_register 1.3.2 1
 rhn_register-gnome 1.3.2 1
 xinetd 2.3.0 1.71

 The following Packages were marked to be
 skipped by your configuration:

 Name Version Rel Reason
 -----------------------------------------------------------
 kernel 2.2.19 7.0.8Pkg name/pattern
 kernel-doc 2.2.19 7.0.8Pkg name/pattern
 kernel-pcmcia-cs 2.2.19 7.0.8Pkg name/pattern
 kernel-source 2.2.19 7.0.8Pkg name/pattern
 kernel-utils 2.2.19 7.0.8Pkg name/pattern

Figure 2-6: Checking for Patches via the Red Hat Update Agent

We do not recommend using the Red Hat Update Agent to update major software packages that are not considered to be a part of the underlying system, specifically Apache, Sendmail, and UW imapd. This is because original distribution sites for these applications often distribute newer versions of the software than what is available from Red Hat. In general, it is a good idea to look for the latest version of the software when deciding whether to obtain the upgrade from Red Hat or from the original site. For instance, the Update Agent would retrieve version 2.5.2p2 of OpenSSH on redrum, even though the latest version of OpenSSH as of this writing is 2.9p2.5

2.6 Administrative Practices

The internal system administration staff at GIAC Enterprises consists of three administrators, one of which specializes in UNIX technologies and is responsible for installing, monitoring, and maintaining UNIX-based services on the corporate network. Given the organization's staff constraints, GIAC Enterprises does not currently provide computing support services for its critical systems on 24-hour basis.

At the time of our analysis, system monitoring was performed manually by the staff, relying primarily on the organization's users to detect and report anomalies. We highly recommend automating monitoring of critical systems, specifically of the redrum and bluewiz servers. Depending on the budget, GIAC Enterprises can choose from a number of fault monitoring packages, ranging from the freely available Big Brother6 to the feature-rich BMC Patrol7. Alternatively, the organization may consider outsourcing monitoring duties of its critical systems to an external company.

Additionally, we suggest deploying integrity verification software such as Tripwire8 to ensure integrity of critical files on the redrum and bluewiz servers. This software operates by comparing snapshots of the system's state to the expected configuration, altering administrators when an unauthorized change is detected. In addition to performing host-level intrusion detection, tools such as Tripwire can be used to maintain a historical log of changes made to the organization's critical servers—this information may prove useful in future internal and external audits as well as during routine system administration duties. It is generally recommended to complement host-based intrusion detection systems (IDS) with network-based intrusion detection systems. Network IDS monitor network communications and alert administrators when suspicious traffic is detected. Additionally, a carefully configured IDS can be used for forensic purposes when responding to an incident, allowing the organization to determine an event's severity and circumstances. Finally, an IDS can help the organization detect attacks during reconnaissance stages, before the attacker attempts to compromise a critical system.

2.7 Sensitive Data

GIAC Enterprises uses the redrum server for hosting its corporate Web site, which consists of static content and several Perl-based CGI scripts. OpenSSL libraries are currently installed on redrum without a valid SSL certificate, and this functionality of the Web server is not currently utilized. CGI scripts are being used to obtain contact information from potential customers and to gather feedback from the site's visitors. (Note that the organization's production systems are hosted at a co-location provider and are not subject to this audit.) This is the only information gathered by the Web server, and GIAC Enterprises does not deem it to be sufficiently sensitive to warrant the use of SSL. While such information does not necessarily require that it be encrypted during transport, we invite GIAC Enterprises to analyze the impact of a data intercept, and weigh it against the cost of setting up and maintaining an SSL certificate for the Web server.

We are concerned that the organization uses clear-text IMAP authentication for its remote mail users. This may result in login credentials intercepted en-route by an attacker, which can lead to a server compromise, especially in the light of other IMAP vulnerabilities discussed earlier. We suggest employing IMAPS functionality that is built into UW imapd, which will allow users to encrypt all IMAP sessions via SSL.9 For proper installation, this will require obtaining a server-side SSL certificate from a company such as VeriSign. On the client side IMAPS functionality is transparently supported by Outlook, which is being used by GIAC Enterprises.

2.8 Virus Protection

GIAC Enterprises employs Norton Anti-Virus software on all its Windows-based workstations. However, our analysis showed that approximately 60% of workstations had virus pattern definitions at least 2 months old. We suggest configuring automatic update functionality, available with Norton Anti-Virus, to ensure that virus definitions remain up to date and provide the expected level of protection. Norton Anti-Virus can be configured to automatically update itself by "pulling" software and virus definition updates from Norton's Web site. Alternatively, organizations can configure the corporate edition of Norton Anti-Virus, which GIAC Enterprises owns, to "push" updates to individual workstations from a central server. The latter is the recommended solution, since it offers the most control over the update distribution process.

Anti-virus software is not installed on the organization's UNIX servers, which is acceptable considering the industry's current practice relating to servers that are used solely by system administration staff. However, we recommend configuring the mail gateway to scan incoming and outbound mail messages for viruses, to ensure that malicious code does not enter or leave the corporate network. Such configuration will provide a level of redundancy, since virus checking will be performed at the network's perimeter, as well as at individual workstations.

2.9 Access Restrictions

The redrum and bluewiz servers are remotely administered through the use of OpenSSH and SFTP. SSH is a good protocol to use for this purpose, since it encrypted all aspects of the administrator's session with the server. The organization uses SecureCRT and SecureFX, a well regarded SSH client produced by Van Dyke Technologies,10 to connect to servers from Windows workstations. Unfortunately, administrators directly log in as root over the network, instead of connecting to the system using individual accounts and then using the "su" utility to obtain administrative access to the system. Logging in directly as root does not allow the organization to keep an audit track of who logged in to the system, and may allow attackers to brute-force root's login credentials. We recommend that this functionality be disabled on the servers by setting the "PermitRootLogin" value to "no" in the sshd_config file. OpenSSH can also be compiled with support for TCP Wrappers, which will allow the organization to limit which client systems are able to connect to the SSH server; this functionality is not currently enabled on redrum and bluewiz. Additionally, we suggest using the "sudo" utility to allow administrators that do not require full root access to execute privileged commands in a controlled manner.

2.10 Contingency Practices

Both servers that we examined are backed up to tape by performing daily incremental and weekly full backups; this is achieved using the UNIX "dump" utility. However, we are concerned that GIAC Enterprises does not perform periodic test restores to ensure that the tape unit is operating as expected. We are also concerned that while backup procedures are properly documented, there are no policies for performing system restores. We suggest that the organization draft detailed policies that will outline steps necessary to recover from system failures and other security incidents in a prompt and reliable manner. Additionally, the organization should consider making copies of its full backup tapes to be taken for secure off-site storage. This can be performed every week, or twice a month, to provide the organization with a way to recover from an event such as a regional disaster.

The redrum and bluewiz servers are not deployed in a cluster configuration, as the organization considers it an unnecessarily expensive solution. This is a reasonable assessment, considering that the decision was reached in a formal manner by analyzing the risk of downtime and the cost of recovery. The servers are currently using single disks for their partitions, and the organization is in the process of purchasing a RAID storage system that will introduce a level of redundancy to the servers' storage subsystem.

2.11 Miscellaneous Concerns

We are concerned with the apparent lack of security policies in the organization. Although there exists some documentation elating day-to-day computing operations, we would like to see the organization formalize its procedures in writing. This will ensure that all critical areas of the computing infrastructure are addressed in a thought-out and consistent manner, and will create a baseline against which GIAC Enterprises will be able to compare the state of its security practices through internal and third party audits. Effective security policies should address most issues discussed in this document, and define procedures, roles, and responsibilities of the company's personnel and computing resources. Additionally, we highly recommend documenting configuration parameters of the organization's critical systems—this documentation should be maintained separately from the security policy, and will help ensure that proper information about computing infrastructure is always available to authorized personnel.

Prioritizing Issues

3.1 Severity Metrics

When prioritizing our concerns, we looked primarily at the impact that a successful exploitation of the vulnerability or misconfiguration will have on the organization's resources, as shown in Figure 3 1 below. We consulted GIAC Enterprises staff when defining severity metrics, to ensure that our discussion is relevant to the organization's concerns and priorities. Note that criticality of the affected service was not considered in depth, since all services and systems analyzed during our audit were deemed to be critical.

Figure 3-1

3.2 Lists of Concerns

Here we present prioritized lists of vulnerabilities and concerns that we described in greater detail earlier in the document. Proposed resolutions to these issues are presented in the next section. Figure 3-2 below lists concerns to which we assigned the priority of "high."

Figure 3-2

Figure 3 3 below presents concerns to which we assigned the priority of "medium."

Figure 3-3

Finally, Figure 3 4 below presents concerns to which we assigned the priority of "low."

Figure 3-4

Recommendations

4.1 Risk Mitigation Strategy

In the previous section we outlined priorities for our concerns relating to information security of the organization's redrum and bluewiz servers. When deciding which of those concerns to address first, GIAC Enterprises should take into account the severity value we assigned to the issue, and weigh the cost of mitigating the issue against the value of the targeted resource. This section proposes an action plan for mitigating discovered risks that is based on our perception of resources' value, while taking into account the approximate cost of implementing our recommendations. As a general rule, we placed the most importance on mitigating concerns marked as "high", with the assumption that the organization may be willing to rapidly implement these recommendations at the cost of possibly delaying the mitigation of issues of "low" priority. (Budget constraints were articulated to us in the beginning of the project, and have been guiding our efforts throughout this engagement.)

4.2 Proposed Action Plan

Figure 4-1 below outlines the proposed action plan for addressing our concerns described earlier in the document. We listed suggested actions in the order of importance that we assigned to them, starting with the most important action. We also included the estimated cost of performing suggested action; however, our calculations do not include the cost of maintenance that might be associated with some of the items.

Figure 4-1

References

1 Red Hat. "Red Hat Linux 7.0 Security Advisories." URL: http://rhn.redhat.com/errata/rh7-errata-security.html (January 2005).

2Internet Software Consortium. "BIND Vulnerabilities." URL: http://www.isc.org/index.pl?/sw/bind/bind-security.php (January 2005).

3Holt Sorensen. "Secure Installation of BIND." 8 February 2001. URL: http://www.securityfocus.com/infocus/1361 (January 2005).

4Apache HTTP Server. "Module mod_cgi." URL: http://httpd.apache.org/docs/mod/mod_cgi.html (January 2005).

5OpenSSH. "OpenSSH Homepage." URL: http://www.openssh.com (January 2005).

6Big Brother System and Network Monitor. URL: http://www.bb4.org (January 2005).

7BMC Software. URL: http://www.bmc.com (January 2005).

8Tripwire Homepage. URL: http://www.tripwire.com (January 2005).

9UW IMAP Server Documentation. "SSL Build and Installation Notes for UNIX." URL: http://www.washington.edu/imap/documentation/SSLBUILD.html (January 2005).

10Van Dyke Technologies, Inc. URL: http://www.vandyke.com (January 2005).

11Thawte. "Digital Certificate Centre." URL: http://www.thawte.com/pricing (January 2005).

Post-Scriptum

This paper was written in 2001. I revised it in January 2005 to update some of the links that were no longer valid.