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.

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.