NIST SP 800-44 Version 2 日本語訳

Special Publication 800-44 Version 2

Miles Tracy Wayne Jansen Karen Scarfone Theodore Winograd

Guidelines on Securing Public Web Servers

原本PDFの抜粋画像

Recommendations of the National Institute of Standards and Technology

Miles Tracy, Wayne Jansen, Karen Scarfone, and Theodore Winograd

COMPUTER SECURITY

NIST Special Publication 800-44 Version 2

原本PDFの抜粋画像

Computer Security Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899-8930

September 2007

U.S. Department of Commerce

Carlos M. Gutierrez, Secretary

National Institute of Standards and Technology

James Turner, Acting Director

The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the Nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analysis to advance the development and productive use of information technology. ITL’s responsibilities include the development of technical, physical, administrative, and management standards and guidelines for the cost-effective security and privacy of sensitive unclassified information in Federal computer systems. This Special Publication 800-series reports on ITL’s research, guidance, and outreach efforts in computer security, and its collaborative activities with industry, government, and academic organizations.

National Institute of Standards and Technology Special Publication 800-44 Version 2 Natl. Inst. Stand. Technol. Spec. Publ. 800-44 Ver. 2, 142 pages (Sep. 2007)

Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by the National Institute of Standards and Technology, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose.

原本PDFの抜粋画像

Acknowledgements, Version 2

The authors, Wayne Jansen and Karen Scarfone of NIST, Miles Tracy of Federal Reserve Information Technology, and Theodore Winograd of Booz Allen Hamilton, wish to express their thanks to colleagues who reviewed drafts of this document. In particular, their appreciation goes to Tim Grance, Bill Burr, Patrick O’Reilly, Ray Perlner, and Murugiah Souppaya from NIST, and Jason Butterfield, Kwok Cheng, and Jonathan Holleran of Booz Allen Hamilton, for their research, technical support, and written contributions to this document. The authors also appreciate the efforts of those individuals, agencies, and other organizations that contributed input during the public comment period.

Acknowledgements, Original Version

The authors, Wayne Jansen from NIST and Miles Tracy and Mark McLarnon from Booz Allen Hamilton, wish to express their thanks to colleagues at both organizations who reviewed drafts of this document. In particular, their appreciation goes to John Wack, Murugiah Souppaya, and Tim Grance from NIST, and Steve Allison, Scott Bisker, Alexis Feringa, Kevin Kuhlkin, and Jonathan Holleran of Booz Allen Hamilton for their research, technical support, and written contributions to this document. The authors would also like to express their thanks to all those who contributed input during the public comment period and who assisted with our internal review process.

Executive Summary

The World Wide Web (WWW) is a system for exchanging information over the Internet. At the most basic level, the Web can be divided into two principal components: Web servers, which are applications that make information available over the Internet (in essence, publish information), and Web browsers (clients), which are used to access and display the information stored on the Web servers. This document focuses on the security issues of Web servers.¹

Unfortunately, Web servers are often the most targeted and attacked hosts on organizations’ networks. As a result, it is essential to secure Web servers and the network infrastructure that supports them. The following are examples of specific security threats to Web servers:

Web servers may also face indirect attacks to gain information from their users. In these attacks, the user is persuaded or automatically directed to visit a malicious Web site that appears to be legitimate. The identifying information that is harvested may be used to access the Web site itself or form the basis for identity theft. Successful attacks can compromise confidential Web site resources or harm an organization’s image. These indirect attacks occur in two forms:

This document is intended to assist organizations in installing, configuring, and maintaining secure public Web servers. More specifically, this document describes, in detail, the following practices to apply:

The following key guidelines are recommended to Federal departments and agencies for maintaining a secure Web presence.

Organizations should carefully plan and address the security aspects of the deployment of a public Web server.

Because it is much more difficult to address security once deployment and implementation have occurred, security should be considered from the initial planning stage. Organizations are more likely to make decisions about configuring computers appropriately and consistently when they develop and use a detailed, well-designed deployment plan. Developing such a plan will support Web server administrators in making the inevitable tradeoff decisions between usability, performance, and risk.

Organizations often fail to consider the human resource requirements for both deployment and operational phases of the Web server and supporting infrastructure. Organizations should address the following points in a deployment plan:

Organizations should implement appropriate security management practices and controls when maintaining and operating a secure Web server.

Appropriate management practices are essential to operating and maintaining a secure Web server. Security practices entail the identification of an organization’s information system assets and the development, documentation, and implementation of policies, standards, procedures, and guidelines that help to ensure the confidentiality, integrity, and availability of information system resources. To ensure the security of a Web server and the supporting network infrastructure, the following practices should be implemented:

Organizations should ensure that Web server operating systems are deployed, configured, and managed to meet the security requirements of the organization.

The first step in securing a Web server is securing the underlying operating system. Most commonly available Web servers operate on a general-purpose operating system. Many security issues can be avoided if the operating systems underlying Web servers are configured appropriately. Default hardware and software configurations are typically set by manufacturers to emphasize features, functions, and ease of use, at the expense of security. Because manufacturers are not aware of each organization’s security needs, each Web server administrator must configure new servers to reflect their organization’s security requirements and reconfigure them as those requirements change. Using security configuration guides or checklists can assist administrators in securing systems consistently and efficiently. Securing an operating system initially would generally include the following steps:

Organizations should ensure that the Web server application is deployed, configured, and managed to meet the security requirements of the organization.

In many respects, the secure installation and configuration of the Web server application will mirror the operating system process discussed above. The overarching principle is to install the minimal amount of Web server services required and eliminate any known vulnerabilities through patches or upgrades. If the installation program installs any unnecessary applications, services, or scripts, they should be removed immediately after the installation process concludes. Securing the Web server application would generally include the following steps:

Organizations should take steps to ensure that only appropriate content is published on a Web site.

Many agencies lack a Web publishing process or policy that determines what type of information to publish openly, what information to publish with restricted access, and what information should not be published to any publicly accessible repository. This is unfortunate because Web sites are often one of the first places that malicious entities search for valuable information. Some generally accepted examples of what should not be published or at least should be carefully examined and reviewed before publication on a public Web site include—

Organizations should ensure appropriate steps are taken to protect Web content from unauthorized access or modification.

Although information on public Web sites is content that is intended to be public, assuming a credible review process and policy is in place, it is still important to ensure that information cannot be modified without authorization. Users of this information rely upon the integrity of such information even if the information is not confidential. Because of the public accessibility, content on publicly accessible Web servers is inherently more vulnerable than information that is inaccessible from the Internet. This vulnerability means that organizations need to protect public Web content through the appropriate configuration of Web server resource controls. Examples of resource control practices include—

Organizations should use active content judiciously after balancing the benefits gained against the associated risks.

Most early Web sites presented static information residing on the server, typically in the form of text-based documents. Soon thereafter, interactive elements were introduced to offer users new ways to interact with a Web site. Unfortunately, these same interactive elements introduced new Web-related vulnerabilities because they involve dynamically executing code on either the Web server or client using a large number of inputs, from Universal Resource Locator (URL) parameters to Hypertext Transfer Protocol (HTTP) POST content and, more recently, Extensible Markup Language (XML) content in the form of Web service messages. Different active content technologies have different associated vulnerabilities, and their risks should be weighed against their benefits. Although most Web sites use some form of active content generators, many also deliver some or all of their content in a non-active form.

Organizations must use authentication and cryptographic technologies as appropriate to protect certain types of sensitive data.

Public Web servers often support a range of technologies for identifying and authenticating users with differing privileges for accessing information. Some of these technologies are based on cryptographic functions that can provide an encrypted channel between a Web browser client and a Web server that supports encryption. Web servers may be configured to use different cryptographic algorithms, providing varying levels of security and performance.

Without proper user authentication in place, organizations cannot selectively restrict access to specific information. All information that resides on a public Web server is then accessible by anyone with access to the server. In addition, without some process to authenticate the server, users of the public Web server will not be able to determine whether the server is the “authentic” Web server or a counterfeit version operated by a malicious entity.

Even with an encrypted channel and an authentication mechanism, it is possible that attackers may attempt to access the site via a brute force attack. Improper authentication techniques can allow attackers to gather valid usernames or potentially gain access to the Web site. Strong authentication mechanisms can also protect against phishing and pharming attacks. Therefore, an appropriate level of authentication should be implemented based on the sensitivity of the Web server’s users and content.

Organizations should employ their network infrastructure to help protect their public Web servers.

The network infrastructure (e.g., firewalls, routers, IDSs) that supports the Web server plays a critical role in the security of the Web server. In most configurations, the network infrastructure will be the first line of defense between a public Web server and the Internet. Network design alone, however, cannot protect a Web server. The frequency, sophistication, and variety of Web server attacks perpetrated today support the idea that Web server security must be implemented through layered and diverse protection mechanisms (i.e., defense-in-depth).

Organizations should commit to the ongoing process of maintaining the security of public Web servers to ensure continued security.

Maintaining a secure Web server requires constant effort, resources, and vigilance from an organization. Securely administering a Web server on a daily basis is an essential aspect of Web server security. Maintaining the security of a Web server will usually involve the following steps:

The National Institute of Standards and Technology (NIST) developed this document in furtherance of its statutory responsibilities under the Federal Information Security Management Act (FISMA) of 2002, Public Law 107-347.

NIST is responsible for developing standards and guidelines, including minimum requirements, for providing adequate information security for all agency operations and assets; but such standards and guidelines shall not apply to national security systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130, Section 8b(3), “Securing Agency Information Systems,” as analyzed in A-130, Appendix IV: Analysis of Key Sections. Supplemental information is provided in A-130, Appendix III.

This guideline has been prepared for use by Federal agencies. It may be used by nongovernmental organizations on a voluntary basis and is not subject to copyright, although attribution is desired.

Nothing in this document should be taken to contradict standards and guidelines made mandatory and binding on Federal agencies by the Secretary of Commerce under statutory authority, nor should these guidelines be interpreted as altering or superseding the existing authorities of the Secretary of Commerce, the Director of the OMB, or any other Federal official.

The purpose of the Guidelines on Securing Public Web Servers is to recommend security practices for designing, implementing, and operating publicly accessible Web servers, including related network infrastructure issues. Some Federal organizations might need to go beyond these recommendations or adapt them in other ways to meet their unique requirements. While intended as recommendations for Federal departments and agencies, it may be used in the private sector on a voluntary basis.

This document may be used by organizations interested in enhancing security on existing and future Web server systems to reduce the number and frequency of Web-related security incidents. This document presents generic principles that apply to all systems.

This guideline does not cover the following aspects relating to securing a Web server:

This document, while technical in nature, provides the background information to help readers understand the topics that are discussed. The intended audience for this document includes the following:

This document assumes that readers have some minimal operating system, networking, and Web server expertise. Because of the constantly changing nature of Web server threats and vulnerabilities, readers are expected to take advantage of other resources (including those listed in this document) for more current and detailed information.

The practices recommended in this document are designed to help mitigate the risks associated with Web servers. They build on and assume the implementation of practices described in other NIST guidelines listed in Appendix E.

The remainder of this document is organized into the following eight major sections:

The document also contains several appendices with supporting material.

The World Wide Web is one of the most important ways for an organization to publish information, interact with Internet users, and establish an e-commerce/e-government presence. However, if an organization is not rigorous in configuring and operating its public Web site, it may be vulnerable to a variety of security threats. Although the threats in cyberspace remain largely the same as in the physical world (e.g., fraud, theft, vandalism, and terrorism), they are far more dangerous as a result of three important developments: increased efficiency, action at a distance, and rapid technique propagation [Schn00].

Compromised Web sites have served as an entry point for intrusions into many organizations’ internal networks. Organizations can face monetary losses, damage to reputation, or legal action if an intruder successfully violates the confidentiality of their data. Denial of service (DoS) attacks can make it difficult, if not impossible, for users to access an organization’s Web site.⁷ These attacks may cost the organization significant time and money. DoS attacks are easy for attackers to attempt because of the number of possible attack vectors, the variety of automated tools available, and the low skill level needed to use the tools. DoS attacks, as well as threats of initiating DoS attacks, are also increasingly being used to blackmail organizations. In addition, an organization can find itself in an embarrassing situation resulting from malicious intruders changing the content of the organization’s Web pages.

Kossakowski and Allen identified three main security issues related to the operation of a publicly accessible Web site [Koss00]:

In recent years, as the security of networks and server installations have improved, poorly written software applications and scripts that allow attackers to compromise the security of the Web server or collect data from backend databases have become the targets of attacks. Many dynamic Web applications do not perform sufficient validation of user input, allowing attackers to submit commands that are run on the server. Common examples of this form of attack are structured query language (SQL) injection, where an attacker submits input that will be passed to a database and processed, and cross-site scripting, where an attacker manipulates the application to store scripting language commands that are activated when another user accesses the Web page.

A number of steps are required to ensure the security of any public Web server. As a prerequisite for taking any step, however, it is essential that the organization have a security policy in place. Taking the following steps within the context of the organization’s security policy should prove effective:

The practices recommended in this document are designed to help mitigate the risks associated with public Web servers. They build on and assume the implementation of practices described in the NIST publications on system and network security listed in Appendix A.

When addressing Web server security issues, it is an excellent idea to keep in mind the following general information security principles [Curt01 and Salt75]:

The most critical aspect of deploying a secure Web server is careful planning prior to installation, configuration, and deployment. Careful planning will ensure that the Web server is as secure as possible and in compliance with all relevant organizational policies. Many Web server security and performance problems can be traced to a lack of planning or management controls. The importance of management controls cannot be overstated. In many organizations, the IT support structure is highly fragmented. This fragmentation leads to inconsistencies, and these inconsistencies can lead to security vulnerabilities and other issues.

Security should be considered from the initial planning stage at the beginning of the systems development life cycle to maximize security and minimize costs. It is much more difficult and expensive to address security after deployment and implementation. Organizations are more likely to make decisions about configuring hosts appropriately and consistently if they begin by developing and using a detailed, well-designed deployment plan. Developing such a plan enables organizations to make informed tradeoff decisions between usability and performance, and risk. A deployment plan allows organizations to maintain secure configurations and aids in identifying security vulnerabilities, which often manifest themselves as deviations from the plan.

In the planning stages of a Web server, the following items should be considered [Alle00]:

The choice of Web server application may determine the choice of OS. However, to the degree possible, Web server administrators should choose an OS that provides the following [Alle00]:

In addition, organizations should consider the availability of trained, experienced staff to administer the server and server products. Many organizations have learned the difficult lesson that a capable and experienced administrator for one type of operating environment is not automatically as effective for another. Although many Web servers do not host sensitive information, most Web servers should be considered sensitive because of the damage to the organization’s reputation that could occur if the servers’ integrity is compromised. In such cases, it is critical that the Web servers are located in areas that provide secure physical environments. When planning the location of a Web server, the following issues should be considered:

Because Web server security is tightly intertwined with the organization’s general information system security posture, a number of IT and system security staff may be interested in Web server planning, implementation, and administration. This section provides a list of generic roles and identifies their responsibilities as they relate to Web server security. These roles are for the purpose of discussion and may vary by organization.

The Senior IT Management/Chief Information Officer (CIO) ensures that the organization’s security posture is adequate. The Senior IT Management provides direction and advisory services for the protection of information systems for the entire organization. The Senior IT Management/CIO is responsible for the following activities associated with Web servers:

The Information Systems Security Program Managers (ISSPM) oversee the implementation of and compliance with the standards, rules, and regulations specified in the organization’s security policy. The ISSPMs are responsible for the following activities associated with Web servers:

Information Systems Security Officers (ISSO) are responsible for overseeing all aspects of information security within a specific organizational entity. They ensure that the organization’s information security practices comply with organizational and departmental policies, standards, and procedures. ISSOs are responsible for the following activities associated with Web servers:

Web server administrators are system architects responsible for the overall design, implementation, and maintenance of a Web server. Network administrators are responsible for the overall design, implementation, and maintenance of a network. On a daily basis, Web server and network administrators contend with the security requirements of the specific system(s) for which they are responsible. Security issues and solutions can originate from either outside (e.g., security patches and fixes from the manufacturer or computer security incident response teams) or within the organization (e.g., the security office). The administrators are responsible for the following activities associated with Web servers:

Web application developers are responsible for the look, functionality, performance, and security of the Web content and Web-based applications they create. As mentioned in Section 2, threats are increasingly directed at applications instead of the underlying Web server software and OSs. Unless Web application developers ensure that their code takes security into consideration, the Web server’s security will be weak no matter how well the server itself and the supporting infrastructure are secured. Web application developers should ensure the applications they implement have the following characteristics:

Appropriate management practices are critical to operating and maintaining a secure Web server. Security practices entail the identification of an organization’s information system assets and the development, documentation, and implementation of policies, standards, procedures, and guidelines that ensure confidentiality, integrity, and availability of information system resources.

To ensure the security of a Web server and the supporting network infrastructure, organizations should implement the following practices:

The objective of system security planning is to improve protection of information system resources.¹² Plans that adequately protect information assets require managers and information owners—directly affected by and interested in the information and/or processing capabilities—to be convinced that their information assets are adequately protected from loss, misuse, unauthorized access or modification, unavailability, and undetected activities.

The purpose of the system security plan is to provide an overview of the security and privacy requirements of the system and describe the controls in place or planned for meeting those requirements. The system security plan also delineates responsibilities and expected behavior of all individuals who access the system. The system security plan should be viewed as documentation of the structured process of planning adequate, cost-effective security protection for a system. It should reflect input from various managers with responsibilities concerning the system, including information owners, the system owner, and the ISSPM.

For Federal agencies, all information systems must be covered by a system security plan. Other organizations should strongly consider the completion of a system security plan for each of their systems as well. The information system owner¹³ is generally the party responsible for ensuring that the security plan is developed and maintained and that the system is deployed and operated according to the agreed-upon security requirements.

In general, an effective system security plan should include the following:

The greatest challenge and expense in developing and securely maintaining a public Web server is providing the necessary human resources to adequately perform the required functions. Many organizations fail to fully recognize the amount of expense and skills required to field a secure public Web server. This failure often results in overworked employees and insecure systems. From the initial planning stages, organizations need to determine the necessary human resource requirements. Appropriate and sufficient human resources are the single most important aspect of effective Web server security. Organizations should also consider the fact that, in general, technical solutions are not a substitute for skilled and experienced personnel.

When considering the human resource implications of developing and deploying a Web server, organizations should consider the following:

Once the organization has staffed the project and the Web server is active, it will be necessary to ensure the number and skills of the personnel are still adequate. The threat and vulnerability levels of IT systems, including Web servers, are constantly changing, as is the technology. This means that what is adequate today may not be tomorrow.

Although many organizations manage Web servers that operate over general-purpose OSs, there are instances in which an organization may wish to use one of the alternatives discussed below. Although these technologies are relatively new to the area of Web servers, they are based on sound technologies and have started to see broader use in the Web server environment.

Trusted operating systems (TOS) are security-modified or -enhanced OSs that include additional security mechanisms not found in most general-purpose OSs. They were originally created to meet the need of the Federal government for high security mandatory access control (MAC) systems. TOSs provide a very secure system-wide control policy, a finely defined set of access privileges, and extensive logging and auditing capabilities. Many TOSs are independently verified to ensure that they meet the requirements set forth in their design documentation.

TOSs are generally used in applications for which security is paramount. TOSs can securely control all aspects of a computing environment, including networking resources, users, processes, and memory. Specifically, TOSs can limit access to system resources in a manner that is not likely to be interfered with or compromised.

Using a TOS will generally produce a very secure Web server; however, some difficulties exist in using TOSs. A major drawback is that configuring and administering a TOS requires knowledge of each protected subsystem and its access needs. It may also require significant planning and administrative overhead to design and support a complex Web site on a TOS. However, even with these limitations, organizations that have very high security requirements should consider using a TOS on their Web servers.

Some manufacturers have begun bundling their OS offerings with most or all of the functionality of traditional TOSs for use in server or workstation environments. Organizations may benefit from such systems because much of the overhead in designing and configuring the Web server to run in a TOS environment has been performed by the manufacturer. Web servers benefit from the TOS’ MAC in that the system can explicitly deny the Web server process access to sensitive portions of the system even if an attacker has managed to take control of the process.

The following are some issues to keep in mind when considering a Web platform:

A Web server appliance is a software/hardware combination that is designed to be a “plug-and-play” Web server. These appliances employ the use of a simplified OS that is optimized to support a Web server. The simplified OS improves security by minimizing unnecessary features, services, and options. The Web server application on these systems is often pre-hardened and pre-configured for security.

These systems offer other benefits in addition to security. Performance is often enhanced because the system (i.e., OS, Web server application, and hardware) is designed and built specifically to operate as a Web server. Cost is often reduced because hardware and software not specifically required by a Web server are not included. These systems can be an excellent option for small- to medium-size organizations that cannot afford a full-time Web administrator.

The greatest weakness in these systems is that they may not be suitable for large, complex, and multi-layered Web sites. They may be limited in what types of active content they support (e.g., J2EE, .NET, PHP Hypertext Preprocessor [PHP]), potentially reducing the options available to an organization. An appliance may host the back-end database as well as the front-end Web interface, potentially preventing organizations from having separate servers for each. Finally, it may be difficult to configure appliances from different manufacturers to work together. Nevertheless, because they offer a secure environment and an easy-to-configure interface, small- to medium-size organizations may find appliances an attractive option requiring less administrative effort. Web server appliances are available from most major hardware manufacturers and from various specialized manufacturers that concentrate solely on Web server appliances.

In addition to Web server appliances, there are also a growing number of security appliances available for Web servers. These systems augment the security mechanisms on the Web server itself. In some cases, these systems can prevent attacks from reaching a Web server, which is especially helpful if the server has known vulnerabilities (e.g., new patches have not yet been applied). The most common types of security appliances are—

In many instances, most or all of the above-mentioned functionality is combined in a single device, which is frequently referred to as a reverse proxy.¹⁵

In organizations requiring complicated dynamic Web sites, the security appliance configuration may be complex, which could cause configuration errors that reduce the effectiveness of the appliance. It is important to practice defense-in-depth to ensure that any vulnerabilities present in the security appliance or its configuration do not adversely affect the organization as a whole.

An additional challenge presented by appliance devices is that they often employ commonly used open-source software. This is normally not a problem, but it can become one when a vulnerability is found in the underlying software because it is frequently not possible to use the patch released by the open-source software group. Common reasons for this inability to use the patch include possible violations of the licensing or support agreements with the appliance manufacturer, and technical problems in applying updates to the appliance (e.g., administrators often do not have OS-level access to appliances). Therefore, appliances can be open to attack for a longer period of time than non-appliance systems because of the additional delay involved in appliance manufacturers developing, testing, and releasing patches. Another possible problem with appliances is that they usually do not allow the installation of additional software for administration or for security, such as antivirus software or host-based intrusion detection agents.

The following are some issues to consider when contemplating the purchase of a Web appliance:

A growing number of pre-hardened OS and Web server packages are being distributed today. These packages include an OS and Web server application that are modified and pre-configured to provide high security. Some of these packages include the hardware platform, while others are software distributions that include only the OS and Web server application. These distributions are generally based on hardened and/or modified general-purpose OSs (e.g., Linux, Unix, Windows) that are specifically designed to support a secure Web server. The Web server application is also often based on a hardened and/or modified generally available Web server application (e.g., Apache, Internet Information Service [IIS]). These packages often include a greater number of security options and are designed to be easier to configure through the use of precompiled scripts and graphical user interfaces (GUI). Although each of these packages is different, they usually rely on one or more of the following to provide a higher level of protection and security:

These types of systems should be considered by organizations that face a significant threat level and/or have high-value Web sites (e.g., major Federal government organizations, banks, health insurance companies). These packages are available from some major hardware and software manufacturers in addition to various specialized manufacturers.

Some issues to consider when contemplating the purchase of a hardened Web appliance:

Virtual machine technology is being used more and more frequently for Web servers. Through virtualization, a single physical host computer can run multiple virtual machines, each with a distinct guest OS and associated applications. A guest OS need not be aware of other OSs—even that of the supporting host—running on the same physical platform. Virtual machine technology is improving constantly. New versions of mainstream OSs are being designed with virtualization in mind and new x86 64-bit processors provide hardware-level support for virtualization.

Virtualization allows organizations to reduce costs by running multiple Web servers on a single host computer and by providing a mechanism for quickly responding to attacks against a Web server. The list below defines the three main types of virtual machine technology. Note that some virtualization software may be a hybrid implementation, depending on the hardware and guest OSs.

Virtualization adds another layer of complexity to the Web server setup. Both the host OS and guest OS need to be secured. If the virtualization technology supports it, a copy of each guest OS and installed Web server application should be backed up to allow restoration if an attack or other disruption occurs. The Web server and its guest OS, the host OS, and the virtualization software should all be patched in a timely manner. It is important to note that if the guest OS or applications become compromised, the guest virtual machine can infect other hosts on the network as if it were a standalone physical host. Each guest OS and associated Web server software should be configured and maintained following the recommendations in this publication.

Protecting a Web server from compromise involves hardening the underlying OS, the Web server application, and the network to prevent malicious entities from directly attacking the Web server. The first step in securing a Web server, hardening the underlying OS, is discussed at length in this section. (Securing the Web server application and the network are addressed in Sections 5 and 8, respectively.)

All commonly available Web servers operate on a general-purpose OS. Many security issues can be avoided if the OSs underlying the Web servers are configured appropriately. Default hardware and software configurations are typically set by manufacturers to emphasize features, functions, and ease of use, at the expense of security. Because manufacturers are unaware of each organization’s security needs, each Web server administrator must configure new servers to reflect their organization’s security requirements and reconfigure them as those requirements change. The practices recommended here are designed to help Web server administrators configure and deploy Web servers that satisfy their organizations’ security requirements. Web server administrators managing existing Web servers should confirm that their systems address the issues discussed.

The techniques for hardening different OSs vary greatly; therefore, this section includes the generic procedures common in securing most OSs. Security configuration guides and checklists for many OSs are publicly available; these documents typically contain recommendations for settings that improve the default level of security, and they may also contain step-by-step instructions for securing systems.¹⁶ In addition, many organizations maintain their own guidelines specific to their requirements. Some automated tools also exist for hardening OSs, and their use is strongly recommended (see Appendix D).

Five basic steps are necessary to maintain basic OS security:

The first step is discussed in Section 3. The other steps are covered in Sections 4.1 and 4.2.

This section provides an overview of the second, third, and fourth steps in the list above. The combined result of these steps should be a reasonable level of protection for the Web server’s OS.

Once an OS is installed, applying needed patches or upgrades to correct for known vulnerabilities is essential. Any known vulnerabilities an OS has should be corrected before using it to host a Web server or otherwise exposing it to untrusted users. To adequately detect and correct these vulnerabilities, Web server administrators should do the following:

Administrators should ensure that Web servers, particularly new ones, are adequately protected during the patching process. For example, a Web server that is not fully patched or not configured securely could be compromised by threats if it is publicly accessible while it is being patched. When preparing new Web servers for deployment, administrators should do either of the following:

Administrators should generally not apply patches to Web servers without first testing them on another identically configured system because patches can inadvertently cause unexpected problems with proper system operation. Although administrators can configure Web servers to download patches automatically, the servers should not be configured to install them automatically so that they can first be tested.

Ideally, a Web server should be on a dedicated, single-purpose host. When configuring the OS, disable everything except that which is expressly permitted—that is, disable all services and applications, re-enable only those required by the Web server, and then remove the unneeded services and applications. If possible, install the minimal OS configuration and then add or remove services and applications as needed. Choose the “minimal installation” option, if available, to minimize the effort required in removing unnecessary services. Furthermore, many uninstall scripts or programs are far from perfect in completely removing all components of a service; therefore, it is always better not to install unnecessary services. Some common types of services and applications that should usually be disabled if not required include the following:

Removing unnecessary services and applications is preferable to simply disabling them through configuration settings because attacks that attempt to alter settings and activate a disabled service cannot succeed when the functional components are completely removed. Disabled services could also be enabled inadvertently through human error.

Eliminating or disabling unnecessary services enhances the security of a Web server in several ways [Alle00]:

Organizations should determine the services to be enabled on a Web server. Services in addition to the Web server service that might be installed include database access protocols, file transfer protocols, and remote administration services. These services may be required in certain instances, but they may increase the risks to the server. Whether the risks outweigh the benefits is a decision for each organization to make.

For Web servers, the authorized users who can configure the OS are limited to a small number of designated Web server administrators and Webmasters. The users who can access the public Web server, however, may range from unrestricted to restricted subsets of the Internet community. To enforce policy restrictions, if required, the Web server administrator should configure the OS to authenticate a prospective user by requiring proof that the user is authorized for such access. Even though a Web server may allow unauthenticated access to most of its services, administrative and other types of specialized access should be limited to specific individuals and groups.

Enabling authentication by the host computer involves configuring parts of the OS, firmware, and applications on the server, such as the software that implements a network service. Although not normally the case for public Web servers, in special situations, such as high-value/high-risk sites, organizations may also use authentication hardware, such as tokens or one-time password devices. Use of authentication mechanisms where authentication information is reusable (e.g., passwords) and transmitted in the clear over a network is strongly discouraged because the information can be intercepted and used by an attacker to masquerade as an authorized user.

To ensure the appropriate user authentication is in place, take the following steps [Alle00]:

For default accounts that need to be retained, change the names (where possible and particularly for administrator or root level accounts) and passwords to be consistent with the organizational password policy. Default account names and passwords are commonly known in the attacker community.

The choice to deny login is another situation that requires the Web server administrator to make a decision that balances security and convenience. Implementing this recommendation can help prevent some kinds of attacks, but it can also allow an attacker to use failed login attempts to prevent user access, resulting in a DoS condition. The risk of DoS from account lockout is much greater if an attacker knows or can surmise a pattern to your naming convention that allows them to guess account names.

Failed network login attempts should not prevent an authorized user or administrator from logging in at the console. Note that all failed login attempts, whether via the network or console, should be logged. If remote administration is not to be implemented (see Section 9.5), disable the ability for the administrator or root level accounts to log in from the network.

As mentioned earlier, attackers using network sniffers can easily capture passwords passed across a network in clear text. However, passwords are economical and appropriate if properly protected while in transit. Organizations should implement authentication and encryption technologies, such as Secure Sockets Layer (SSL)/Transport Layer Security (TLS), Secure Shell (SSH), or virtual private networking (VPN), to protect passwords during transmission. Requiring user-friendly server authentication to be used with encryption technologies reduces the likelihood of successful man-in-the-middle and spoofing attacks.

All commonly used modern server OSs provide the capability to specify access privileges individually for files, directories, devices, and other computational resources. By carefully setting access controls and denying personnel unauthorized access, the Web server administrator can reduce intentional and unintentional security breaches. For example, denying read access to files and directories helps to protect confidentiality of information, and denying unnecessary write (modify) access can help maintain the integrity of information. Limiting the execution privilege of most system-related tools to authorized system administrators can prevent users from making configuration changes that could reduce security. It also can restrict the attacker’s ability to use those tools to attack the system or other systems on the network.

OSs often do not include all of the security controls necessary to secure the OS, services, and applications adequately. In such cases, administrators need to select, install, and configure additional software to provide the missing controls. Commonly needed controls include the following:

Some Web server administrators also install one or more forms of host-based intrusion detection or intrusion prevention software on their servers. For example, file integrity checking software can identify changes to critical system files.

When planning security controls, Web server administrators should consider the resources that the security controls will consume. A server’s performance could degrade if it does not have enough memory and processing capacity for the controls.

Periodic security testing of the OS is a vital way to identify vulnerabilities and to ensure that the existing security precautions are effective. Common methods for testing OSs include vulnerability scanning and penetration testing. Vulnerability scanning usually entails using an automated vulnerability scanner to scan a host or group of hosts on a network for application, network, and OS vulnerabilities. Penetration testing is a testing process designed to compromise a network using the tools and methodologies of an attacker. It involves iteratively identifying and exploiting the weakest areas of the network to gain access to the remainder of the network, eventually compromising the overall security of the network. Vulnerability scanning should be conducted periodically, at least weekly to monthly, and penetration testing should be conducted at least annually. Because both of these testing techniques are also applicable to testing the Web server application, they are discussed in detail in Section 9.4.23

Testing generally should not be performed on the production Web server itself. As mentioned in Section 4.1.1, testing for patches and changes to the system should be performed on a separate system; this same testing environment should be used to perform security testing of the Web server.

Once the OS has been installed and secured, installing the chosen Web server software can begin. Before starting this process, read the Web server manufacturer’s documentation carefully and understand the various options available during the installation process. Also, be sure to visit the manufacturer’s Web site or a vulnerability database Web site, such as the National Vulnerability Database (NVD),²⁴ to determine whether there are known vulnerabilities and related patches available that should be installed or configured as part of the setup process. Only after these preliminary steps are accomplished should the installation be started. Note that this section discusses only generic installation and configuration procedures; specific directions for particular Web servers are available from Web server manufacturers and from security checklist repositories.²⁵

A partially configured and/or patched server should not be exposed to external networks (e.g., the Internet) or external users. In addition, internal network access should be as limited as possible until all software is installed, patched, and configured securely. Insecure Web servers can be compromised in a matter of minutes after being placed on the Internet. While it is ideal to fully harden the platform before placing it on the network, it is not always feasible. For example, some application development tool combinations cannot be installed, configured, and tested on top of a pre-hardened OS and Web server configuration. In such situations, stepwise or incremental hardening is a viable option to consider, with full validation of complete hardening occurring at production deployment.

In many respects, the secure installation and configuration of the Web server application mirrors the OS process discussed in Section 4. The overarching principle, as before, is to install only the services required for the Web server and to eliminate any known vulnerabilities through patches or upgrades. Any unnecessary applications, services, or scripts that are installed should be removed immediately once the installation process is complete. During the installation of the Web server, the following steps should be performed:

Organizations should consider installing the Web server with non-standard directory names, directory locations, and filenames. Many Web server attack tools and worms targeting Web servers only look for files and directories in their default locations. While this will not stop determined attackers, it will force them to work harder to compromise the server, and it also increases the likelihood of attack detection because of the failed attempts to access the default filenames and directories and the additional time needed to perform an attack.

Most Web server host OSs provide the capability to specify access privileges individually for files, devices, and other computational resources on that host. Any information that the Web server can access using these controls can potentially be distributed to all users accessing the public Web site. The Web server software is likely to include mechanisms to provide additional file, device, and resource access controls specific to its operation. It is important to set identical permissions for both the OS and Web server application; otherwise, too much or too little access may be granted to users. Web server administrators should consider how best to configure access controls to protect information stored on public Web servers from two perspectives:

The proper setting of access controls can help prevent the disclosure of sensitive or restricted information that is not intended for public dissemination. In addition, access controls can be used to limit resource use in the event of a DoS attack against the Web server. Similarly, access controls can enforce separation of duty by ensuring Web server logs cannot be modified by Web server administrators and potentially ensure that the Web server process is only allowed to append to the log files.

Typical files to which access should be controlled are as follows:

It is vital that the Web server application executes only under a unique individual user and group identity with very restrictive access controls.²⁶ New user and group identities should be established for exclusive use by the Web server software. The new user and new group should be independent from all other users and groups and unique. This is a prerequisite for implementing the access controls described in the following steps. During initialization, the server may have to run with root (Unix) or administrator/system (Windows) privileges to bind to Transmission Control Protocol (TCP) ports numbered below 1024 (80 and 443 are the default ports for HTTP and HTTPS). Ensure that the Web server is configured to reduce its privileges to those of the Web server user after performing its initialization functions.

In addition, use the Web server OS to limit which files can be accessed by the Web server’s service processes. These processes should have read-only access to those files necessary to perform the service and should have no access to other files, such as server log files. Use Web server host OS access controls to enforce the following [Koss00]:

It is also necessary to ensure that the Web server application cannot save (or, in some cases, read) files outside the specified file structure dedicated to public Web content. This may be a configuration choice in the server software, or it may be a choice in how the server process is controlled by the OS. Ensure that such directories and files (outside the specified directory tree) cannot be accessed, even if users perform direct browsing by accessing the URLs of those files or through directory traversal attacks against the Web server process.

To mitigate the effects of certain types of DoS attacks, configure the Web server to limit the amount of OS resources it can consume. Some examples include—

To some degree, these actions protect against attacks that attempt to fill the file system on the Web server host OS with extraneous and incorrect information that may cause the system to crash. Logging information generated by the Web server host OS may help in recognizing such attacks. As discussed in Section 9.1, administrators should store Web server logs on centralized logging servers whenever possible and also store logs locally if feasible. If an attack causes the Web server to be compromised, the attacker could modify or erase locally stored logs to conceal information on the attack. Maintaining a copy of the logs on a centralized logging server gives administrators more information to use when investigating such a compromise.

In addition to the controls mentioned above, it is often necessary to configure timeouts and other controls to further reduce the impact of certain DoS attacks. One type of DoS attack takes advantage of the practical limits on simultaneous network connections by quickly establishing connections up to the maximum permitted, such that no new legitimate users can gain access. By setting network connection timeouts (the time after which an inactive connection is dropped) to a minimum acceptable time limit, established connections will time out as quickly as possible, opening up new connections to legitimate users. This measure only mitigates the effects; it does not defeat the attack.

If the maximum number of open connections (or connections that are half-open—that is, the first part of the TCP handshake was successful) is set to a low number, an attacker can easily consume the available connections with illegitimate requests (often called a SYN flood). Setting the maximum to a much higher number may mitigate the effect of such an attack, but at the expense of consuming additional resources. Note that this is only an issue for Web servers that are not protected by a firewall that stops SYN flood attacks. Most enterprise-level firewalls protect Web servers from SYN floods by intercepting them before they reach the Web servers.

Do not use links, aliases, or shortcuts in the public Web content file directory tree that point to directories or files elsewhere on the server host or the network file system. If possible, disable the ability of the Web server software to follow links and aliases. As stated earlier, Web server log files and configuration files should reside outside the specified file directory tree for public Web content.

The following steps are required to restrict access to a specific Web content file directory tree:

Most Web server software vendors provide directives or commands that allow the Web administrator to restrict user access to public Web server content files. For example, the Apache Web server software provides a <Limit> directive, which allows the Web administrator to restrict which optional access features (such as New, Delete, Connect, Head, and Get) are associated with each Web content file; any HTTP method omitted from the <Limit> directive will be allowed. Within the <Limit> directive, administrators can specify the requirements that must be met for the Limited action to be allowed. The Apache Require directive allows the Web administrator to restrict available content to authenticated users or groups.

Many directives or commands can be overridden on a per-directory basis. The convenience of being able to make local exceptions to global policy is offset by the threat of a security hole being introduced in a distant subdirectory, which could be controlled by a hostile user. The Web administrator should disable a subdirectory’s ability to override top-level security directives unless that override is absolutely necessary.

In most cases, Web server file directory listings should be disabled. The HTTP specifies that a URL ending in a slash character be treated as a request for a listing of the files in the directory with that name. Web servers should be prohibited from responding to such requests with a file listing, even if the public can read all of the directory files. Such requests often indicate an attempt to locate information by means other than those intended by the Web administrator or Webmaster. Users may attempt this if they are having difficulty navigating through the site or if a link appears to be broken. Intruders may attempt this to locate information hidden by the Web site’s interface. Web administrators should investigate requests of this type found in the Web server log files (see Section 9).

Uniform Resource Identifiers (URI) are the address technology from which URLs are created. Technically URLs (e.g., http://www.mywww.gov) are a subset of URIs. There are a number of security issues that arise from URIs. Because URIs are sent in the clear, any data stored within them can be easily compromised. For example, URIs are recorded in numerous locations, including Web browser logs (i.e., browser history), proxy server logs, and third-party HTTP referrer logs. Thus, hiding sensitive data such as usernames and passwords or hidden server resources in URIs is not recommended. Security through obscurity is not secure.

URIs are often included with public Web content. Although these URIs may not display as Web content in a user’s Web browser, they can be easily discovered in the source code. Therefore, no publicly served Web content should include sensitive URIs hidden in the source code. Many attackers and malicious bots (see Section 5.2.4) search the source code for sensitive URI information, including—

A cookie is a small piece of information that may be written to the user’s hard drive when the user visits a Web site. The intent of cookies is to allow servers to recognize a specific browser (user). In essence, they add state to the stateless HTTP protocol. Because cookies are usually sent in the clear and stored in the clear on the user’s host, they are vulnerable to compromise. There are known vulnerabilities in certain versions of Internet Explorer, for example, that allow a malicious Web site to remotely collect all of a visitor’s cookies without the visitor’s knowledge. Therefore, cookies should never contain data that can be used directly by an attacker (e.g., username, password). OMB M-00-1327 explicitly states that Federal Web sites should not use cookies unless there is a compelling need to gather the data on the site, and only with the appropriate approvals, notifications, and safeguards in place. For Web sites that need to maintain session information, the session identifier can be passed as part of the URL to the Web site rather than stored as a cookie. Regardless of whether cookies are being used or not, SSL/TLS should be used to prevent attackers from retrieving information from the HTTP messages sent over the network and using it to hijack a user’s session.

Web bots (also known as crawlers or spiders) are software applications used to collect, analyze, and index Web content. Web bots are used by numerous organizations for many purposes. Some examples include—

Bots can present a challenge to Webmasters’ administration of their servers because—

Fortunately, Web administrators or the Webmaster can influence the behavior of most bots on their Web site. A series of agreements called the Robots Exclusion Protocol (REP) has been created. Although REP is not an official Internet standard, it is supported by most well-written and well-intentioned bots, including those used by most major search engines.

Web administrators who wish to limit bots’ actions on their Web server need to create a plain text file named “robots.txt.” The file must always have this name, and it must reside in the Web server’s root document directory. In addition, only one file is allowed per Web site. Note that the robots.txt file is a standard that is voluntarily supported by bot programmers, so malicious bots (such as EmailSiphon and Cherry Picker) often ignore this file.²⁸

The robots.txt file is a simple text file that contains some keywords and file specifications. Each line of the file is either blank or consists of a single keyword and its related information. The keywords are used to tell robots which portions of a Web site are excluded.

The following keywords are allowed:

An asterisk (“*”) indicates a “default” record, which applies if no other match is found. For example, if you specify “GoogleBot” only, then the “*” would apply to any other robot.

Note that “/do” matches any directory beginning with “/do” (e.g. /do, /document, /docs, etc.), whereas “/do/” matches only the directory named “/do/”. A Web administrator can also specify individual files for exclusion. For example, the Web administrator could specify “/mydata/help.html” to prevent only that one file from being accessed by the bots. A value of just “/” indicates that nothing on the Web site is allowed to be accessed by the specified bot(s).

At least one disallow per user-agent record must exist.

There are many ways to use the robots.txt file. Some simple examples are as follows:

User-agent: * Disallow: /images/ Disallow: /banners/ Disallow: /Forms/ Disallow: /Dictionary/ Disallow: /_borders/ Disallow: /_fpclass/ Disallow: /_overlay/ Disallow: /_private/ Disallow: /_themes/

User-agent: * Disallow: /

User-agent: GoogleBot Disallow: tempindex.htm

Note that the robots.txt file is available to everyone and does not provide access control mechanisms to the disallowed files. Thus, a Web administrator should not specify the names of sensitive files or folders because attackers often analyze robots.txt files to guide their initial investigations of Web sites. If files or directories must be excluded, it is better to use password-protected pages that cannot be accessed by bots.

Password protection is the only reliable way to exclude noncompliant bots or curious users. See Section 7 for more information on Web-based authentication methods.

Often, spambots ignore robots.txt and search for email addresses on the Web site and/or forms to which they can submit spam-related content. Spambots that merely scan the Web site typically do not affect its availability. Nevertheless, it may be beneficial to prevent them from harvesting e-mail addresses by performing address munging [Unsp06]—displaying e-mail addresses in an alternative human-readable format, such as listing name@mywww.gov as <name at mywww dot gov>. Unfortunately, these techniques do not stop all spambots. The best defense against address harvesting is not to display e-mail addresses.

Spambots searching for Web forms to submit spam-related content are a direct threat to the Web site. They can affect the organization’s image if visitors view the submitted content as an endorsement. They may also affect the Web site’s availability by making it difficult for users to find necessary content. There are several techniques available to reduce the amount of spam submissions, including—

These techniques all have benefits and drawbacks associated with them. For example, some CAPTCHA techniques, which can be implemented as an obscured word in an image, do not comply with American Disability Association (ADA) or Section 508 accessibility guidelines. Information about ongoing research on detecting spambots can be found through the Adversarial Information Retrieval on the Web (AIRWeb) workshops.²⁹

The two main components of Web security are the security of the underlying server application and OS, and the security of the actual content. Of these, the security of the content is often overlooked. Maintaining effective content security itself has two components. The more obvious is not placing any proprietary, classified, or other sensitive information on a publicly accessible Web server, unless other steps have been taken to protect the information via user authentication and encryption (see Section 7). The less obvious component of content security is avoiding compromises caused by the way particular types of content are processed on a server. As organizations have gotten better at protecting and hardening their network perimeters, OSs, and Web servers, attackers have increasingly turned to exploiting vulnerabilities in Web applications and the way information is processed on Web servers. These application layer attacks exploit the interactive elements of Web sites.

Too often, little thought is given to the security implications of the content placed on the Web site. Many organizations do not have a Web publishing process or policy that determines what type of information to publish openly, what information to publish with restricted access, and what information should be omitted from any publicly accessible repository. This is troublesome because Web sites are often one of the first places that malicious entities search for valuable information. For example, attackers often read the contents of a target organization’s Web site to gather intelligence before any attacks [Scam01]. Also, attackers can take advantage of content available on a Web site to craft a social engineering attack or to use individuals’ identifying information in identity theft [FTC06].

Absent compelling reasons, a public Web site should not contain the following information:

Organizations should not use public Web servers to host sensitive information intended to be accessed only by internal users. The compromise of a public Web server often leads to the compromise of such data.

To ensure a consistent approach, an organization should create a formal policy and process for determining and approving the information to be published on a Web server. In many organizations, this is the responsibility of the CIO and/or public affairs officer. Such a process should include the following steps:

Any policy or process for determining and approving the information to be published on a Web server can benefit from the use of automated tools. Tools can scan incoming content for keywords, formatting, or metadata, and flag it for review, easing the burden of those required to verify content. Similarly, an internal automated system that allows users to post potential material to an internal Web site and notifies approving personnel (possibly via e-mail) of the posting allows material to be reviewed and posted to the public Web site more quickly through a repeatable process. Using an automated system also aids accountability because logs track who submitted the document and who approved it.

An often-overlooked area of Web content is the information sometimes hidden within the source code of a Web page. This information can be viewed from any Web browser using the “view source code” menu option. The source code can, for example, contain points of contact and reveal portions of the directory structure of the Web server. Organizations often do not pay attention to the contents of the source code on their Web sites, even though this code may contain sensitive information. Attackers scour not only the obvious content of the Web site but also details within the source code. Thus, Web administrators or Webmasters should periodically review code on their public Web server.

Federal and state laws and regulations apply to the collection of user information on publicly accessible government Web sites. In addition, many government agencies have privacy guidelines that address the type of information that could be collected about users. Governmental organizations with Web sites should be aware of the appropriate and applicable laws, regulations, and agency guidelines. Private organizations may wish to use these guidelines and examples of sound security practices but should consult appropriate legal counsel and their privacy officials for the applicable legal and policy implications. However, Federal laws, regulations, and applicable agency guidelines do apply to commercial organizations that operate Web sites on behalf of Federal agencies. Organizations should be aware of changes to legal, regulatory, and contractual requirements and seek advice from knowledgeable legal and policy experts.

Federal agencies that collect PII must do so in accordance with Federal law and the Constitution. The Privacy Act, for example, requires agencies to minimize the information collected to that which is relevant and necessary to the business purpose,³³ and, in many cases, to collect information, to the greatest extent practicable, directly from the subject individual.³⁴ In addition, accepted practices (many of which are reflected in laws applicable to both private and public institutions) are to provide subject individuals:

The following are examples of personal information:

Federal agencies and many state agencies are also restricted in their ability to use Web browser cookies [OMB00a, OMB00b, OMB00c, and MASS99]. A cookie is a small piece of information that may be written to a user’s hard drive when a Web site is visited. There are two principal types of cookies:

Indirect content attacks are not direct attacks on a Web server or its contents; they involve roundabout means to gain information from users who normally visit the Web site maintained on the Web server. The common theme of these attacks is to coerce users into visiting a malicious Web site set up by the attacker and divulging personal information in the belief that the site they visited is the legitimate Web site. While customers of electronic commerce and financial institutions are often targeted, such attacks are not limited to those Web sites. Besides acquiring personal information related to the targeted Web site, attacks may also be directed against the user’s computer from the malicious Web site visited. The types of indirect attacks described in this section are phishing and pharming.

Phishing attackers use social engineering techniques to trick users into accessing a fake Web site and divulging personal information. In some phishing attacks, attackers send a legitimate-looking e-mail asking users to update their information on the company’s Web site, but the URLs in the e-mail actually point to a false Web site.³⁵ Other phishing attacks may be more advanced and take advantage of vulnerabilities in the legitimate Web site’s application.³⁶

Although phishing cannot be prevented entirely through technical means employed on a Web server, many techniques can reduce the likelihood that a Web site’s users will be lured into a phishing attack³⁷ [Ollm04]:

Most Web browsers provide some level of phishing protection. All Web browsers inform users when they visit a secured site via a padlock or some other GUI mechanism, and they also inform users if the Domain Name System (DNS) address visited does not match that of the Public Key Infrastructure (PKI) certificate. However, phishing sites often use DNS addresses that are similar to those of the original sites and that have a valid PKI certificate, making them harder to detect. In such cases, a Web browser would notify the user of the danger only if the site was a known phishing site. Browsers may either download a phishing blacklist from the browser manufacturer’s Web site periodically or check all Web requests against an anti-phishing database. Organizations should use Web browser-provided anti-phishing features where applicable. In addition, a number of vendors offer more advanced anti-phishing solutions and services [APWG07]:

When contemplating anti-phishing measures, it is important to consider the type of information being hosted on the Web site. Web sites with little or no sensitive information may not need to implement more advanced or costly anti-phishing measures. Web sites storing PII should strongly consider implementing more robust anti-phishing measures.

Pharming attackers use technical means, instead of social engineering, to redirect users into accessing a fake Web site masquerading as a legitimate one and divulging personal information. Pharming is normally accomplished either by exploiting vulnerabilities in DNS software, which is used to resolve human-readable Internet domain names into IP addresses, or by altering the host files maintained on a client computer for locally resolving Internet domain names. In either case, the affected system incorrectly resolves legitimate names to the malicious Web site address. Various techniques can help reduce the likelihood that a Web site’s users become involved in a pharming attack [Ollm05]:

URL, such as https://www.organization.org/, but then redirect them to another URL, such as https://www.secure-organization.org/. A user redirected to https://www.secured-organization.org/ may not notice the attack.

Many of the techniques used to prevent phishing attacks—particularly in commercial offerings—are relevant to preventing pharming attacks. As with anti-phishing solutions, when contemplating anti-pharming measures, it is important to consider the type of information being hosted on the Web site. Web sites with little or no sensitive information may not need to implement more advanced or costly anti-pharming measures. Web sites storing PII should strongly consider implementing more robust anti-pharming measures. Requiring strong authentication can greatly reduce the risk of successful phishing and pharming attacks.