Inside Network Perimeter Security (2nd Edition) - page 88

Summary

Hardening the configuration of host computers allows us to reinforce the security of the network perimeter by following the principles of defense in depth. As with all components of a defense infrastructure, we rely on multiple security components to protect resources against attacks. This notion can be applied at the network and at the host level. The extent to which a system should be hardened depends on its role on the network and also accounts for the resources you have available to maintain the locked-down configuration. As we discussed in this chapter, default operating system installations rarely implement hardening best practices that allow us to build systems that are highly resistant to attacks. You can significantly improve the host's defenses if you take the time to disable or remove unnecessary services and applications, limit access to data, control user access and privileges, maintain logs, and apply patches.

Chapter 10. Host Defense Components

The host's perimeter, operating system (OS), and applications are our last line of defense against network attacks. If an attacker manages to get through or around your firewall, or if you are defending against malicious code or an insider, it is up to the host to limit the scope of the potential compromise. In Chapter 9, "Host Hardening," we explained how to configure the system's OS and related applications to help the host withstand local and network-based attacks. We locked down the file system, disabled unnecessary accounts and services, enforced strong passwords, fine- tuned group membership, and applied patches. This chapter builds on the concepts of hardening by demonstrating how hosts can play an active role in protecting data and services. In a layered security architecture, hosts that are configured according to the risks they might face and to the tasks they need to fulfill reinforce perimeter components such as routers, firewalls, and network intrusion detection systems.

In this chapter, we explain how to use hosts to help detect and isolate attacks, and we discuss tools and approaches that will help you strengthen the system's defenses. We look at differences in needs of host categories and describe best-fit roles for antivirus software, host-based intrusion detection products, and other host-based tools. We also talk about host-based firewalls and how they compare to the gateway firewalls you have seen in the book so far. We examine the strengths and weaknesses of each type of host defense component to allow you to effectively incorporate any of them into the design of the overall network security perimeter.

Hosts and the Perimeter

Any system that is operating as part of a network infrastructure has the potential of falling victim to a remote attack. A successful compromise might come as the result of a system misconfiguration or vulnerabilities in the OS or installed applications. As you know, administrators can help mitigate the risks associated with known vulnerabilities by routinely applying software patches and ensuring that hosts are hardened sufficiently. To effectively protect systems against attacks that might yet be unknown to us, we have been using the defense- in-depth approach, relying on multiple layers in the defense perimeter's architecture to reinforce its resilience.

Red Hat and the WU-FTPD "File Globbing" Vulnerability

An unknown vulnerability and one that has been announced to the world are different. For example, Red Hat issued a security advisory about a bug in the Washington University File Transport Protocol Daemon (WU-FTPD). ¹ The vulnerability could allow a remote attacker to obtain root access to the server running WU-FTPD, which is bundled with many Linux distributions. Unfortunately, the statement was erroneously published days before the date on which Linux vendors had agreed to issue the advisory and release appropriate patches. Red Hat's announcement accidentally undermined efforts to coordinate the announcement with the availability of the fix, leaving thousands of users of nonRed Hat distributions vulnerable. ²

Of course, the WU-FTPD vulnerability existed before Red Hat's announcement; those who were aware of its technicalities might have been quietly exploiting it. The security advisory, albeit unfair to Red Hat's competitors , allowed administrators to consider ways to protect against the vulnerability, possibly by disabling the vulnerable daemon until the patch became available. On the other hand, by prematurely publicizing the information, Red Hat increased the chances that a skilled attacker could develop an exploit to take advantage of the vulnerability before administrators could protect their hosts against it.

The nature in which the system is being used impacts the risks it might need to be protected against and the ways in which the host's defense components need to be deployed and configured. To help you understand the applicability of host-based security software, we have classified systems into two general categories:

Workstations
Servers

Although the distinctions between these types of hosts are often intuitive, let's formalize the security challenges associated with each category to lay groundwork for subsequent discussions.

Workstation Considerations

Workstations, which include laptops and desktops, are used by end users to interactively run local applications and to access services on the network. Workstations routinely interact with potentially unsafe resources on the Internet as users connect to external sites that provide services such as web, file sharing, and instant messaging. Because of the unpredictable nature of human behavior, it is difficult to foresee the problems that might arise when a user connects to an external system that is not under your control. The same workstations are also used to connect to resources that are more trusted: internal file and mail servers, Human Resources systems, and other applications that are specific to your organization's business. Interactions with partner and supplier networks carry a degree of risk as well. In these cases, although you cannot directly control the security of third-party resources, you can often define accountability and liability through the use of legal agreements with your partners and suppliers, as well as by inquiring about their security posture when formalizing the business relationship.

In most companies, workstationsparticularly laptopsare no longer just located behind the reinforced security perimeter of your network. Traveling and telecommuting users may reach the company's network by first connecting to the Internet through dial-up, broadband, or wireless hot spots. In these cases, the workstations are not protected by the company's central security components, such as network firewalls and intrusion detection systems (IDSs). Chapter 13, "Separating Resources," discusses the need to apply different degrees of protective measures to systems based on their roles, from LAN-connected desktops to wireless clients .

The Qaz Worm and Microsoft

Around October 2000, an attacker was able to gain unauthorized access to Microsoft's internal systems and, reportedly, view source code for upcoming product releases. Investigators surmised that the attacker succeeded at compromising Microsoft's perimeter defenses by first infecting an employee's home workstation with the Qaz worm by emailing him a Trojanized attachment.

Qaz propagates by scanning the subnet for Windows shares that are not password protected. When a vulnerable system is found, Qaz copies itself to the system's Windows directory via NetBIOS as notepad.exe , while renaming the original notepad to note.com . The worm also modifies the infected system's Registry key to ensure that the host automatically launches the worm upon startup. The worm also establishes a backdoor on TCP port 7597 on the infected system, allowing the attacker to run arbitrary commands, upload new files, or terminate the worm's program. To announce the IP address that the attacker can use to access the backdoor, the worm sends an email message to 202.106.185.107, which corresponds to a system located in China. ³

The attacker probably used the backdoor the Trojan established to access Microsoft's systems when the employee connected to the company's internal network. If Microsoft's corporate firewall did not block inbound connections on TCP port 7597, the attacker also could have waited for Qaz to infect the company's internal systems and then connected to them directly.

{% if main.adsdop %}{% include 'adsenceinline.tpl' %}{% endif %}

One of the challenges in maintaining workstations is the sheer number of them, generally one per employee in a company. This makes it difficult to effectively monitor workstations for suspicious events, install OS and application patches, update virus definitions, and enforce security policies, in addition to other tasks .

A useful tool for determining the current patch level of systems distributed throughout your network is Microsoft Baseline Security Analyzer (MBSA), available as a free download from http://www.microsoft.com/technet/security/tools/mbsahome.mspx. For local or remote systems, MBSA can determine which patches are missing from several versions of Windows, as well as Internet Explorer, Exchange, SQL Server, Internet Information Server (IIS), and other common Windows components. By default, it operates by downloading from the Microsoft website a digitally signed file that contains information about available patches and then querying the Registry and the file system of the local system or remote machines to see whether the patches have been applied. It provides specific details on each issue, including its relative priority, corrective guidance, and pointers for more information, such as Microsoft Knowledge Base articles. Before using MBSA, you should first ensure that your environment supports its requirements. For example, MBSA must be able to log on remotely with administrative rights to target systems, and the systems must be running certain services. ⁴

Server Considerations

Server systems are typically dedicated to running services that are accessed by client systems over the network; they do not allow users to directly execute local processes. In such cases, only the server's administrators can log on to the system. This decreases the likelihood that a user who is logged on to the server will launch a local copy of Internet Explorer and start browsing through dubious websites . To further reduce that likelihood , your security policy should restrict the kind of actions administrators can take when maintaining such servers.

Dedicating a server to a particular task allows you to strip the system of many components, leaving only software that is required for the server to perform its business task. In this case, security of the local system can be improved because the usability of the server does not need to be as full featured as that of a workstation. For example, a Solaris 8 server with 64-bit support running Check Point FireWall-1 requires only 83 packages ⁵ , out of hundreds that would be needed if the system were used as a workstation.

Multiuser hosts form another class of servers, because they allow multiple users to be simultaneously logged in to and running interactive processes on the system. For example, such servers can be implemented by deploying Windows Terminal Services or by creating multiple accounts on a UNIX system and allowing users to log in using SSH. Universities frequently offer such services to students and faculty by allowing them to log in to the multiuser server and run shell-based as well as X Window System applications.

When defending against vulnerabilities that can be exploited over the network, you can deploy multiple firewalls, fine-tune packet filters on your routers, and configure network IDSs to detect the attacks. These measures are not effective, however, at defending the multiuser server against a user who already has local access to the system. For instance, incorrect path usage by stmkfont under HP-UX B.11 could allow a local user to execute arbitrary code (http://cve.mitre.org/cgi-bin/cvename.cgi? name =CAN-2004-0965). This condition could not be directly exploited over the network without first obtaining local access to the server. System hardening, patch management, host-based intrusion detection, and security policy are probably your best bets for protecting multiuser servers.

Servers are usually considered to be more sensitive than individual workstations. Whether the attacker compromises a multiuser server or a dedicated server, she is likely to have an immediate impact on numerous users who rely on the services of that host. Consider the influence an attacker might have if she manages to compromise a domain controller in a Microsoft Windows Active Directory. Another prominent attack of this sort is a web server defacement that announces to the world that the company's public web server has been compromised. Attacks on the more sensitive servers located within a company are likely to inflict larger financial harm to the victim, but are generally not widely publicized.