Technology Blueprint. Protect Your Web Servers. Reduce the attack surface according to each web server s risks

Transcription

1 Technology Blueprint Protect Your Web Servers Reduce the attack surface according to each web server s risks

2 LEVEL SECURITY CONNECTED REFERENCE ARCHITECTURE LEVEL Security Connected The Security Connected framework from McAfee enables integration of multiple products, services, and partnerships for SECURITY CONNECTED centralized, efficient, and REFERENCE ARCHITECTURE effective risk mitigation. Built on LEVEL more than two 1decades 2 3 of 4 5 proven security practices, the Security Connected approach helps organizations of all sizes and segments across all geographies improve security postures, optimize security for greater cost effectiveness, and align security strategically SECURITY with business CONNECTED initiatives. The REFERENCE Security Connected ARCHITECTURE Reference Architecture provides a concrete LEVEL path from 1 ideas 2 3 to 4 5 implementation. Use it to adapt the Security Connected concepts to your unique risks, infrastructure, and business objectives. McAfee is relentlessly focused on finding new ways to keep our customers safe. Reduce the attack surface according to each web server s risks The Situation The good news: every company has gotten jittery about web server security. The bad news: the catalyst has been destructive, expensive hacks, breaches, and downtime at companies like Sony, Nintendo, and Amazon. The Sony PlayStation Network (PSN) hack ultimately cost them an estimated $175 million just from downtime. Gene Spafford, a Purdue University professor of computer science, testified before the U.S. Congress that Sony was running an obsolete version of the Apache web server that was unpatched and had no firewall installed. 1 Prior to this incident, Sony was under a DoS attack from the hacktivist group Anonymous, because of a highly visible court battle with another hacker. Then, after the PSN was hacked and taken off line, the hacker group LulzSec breached Sony via what they said was a simple SQL injection. Sony is just one bruised brand on a long list of web hacking targets today. Hackers are not the only concern for website and web server administrators, just the most obvious. With tight budgets, most businesses struggle to keep up with the risks specific to web servers including HTTP fingerprinting, unauthorized access, denial of service, and code injection attacks. Few organizations implement appropriate countermeasures. Yet, every day, misconfigured, unpatched, insecure web servers lead to loss of data, defacement, and service disruption, as Sony can attest. Driving Concerns You must understand your existing web server infrastructure before you can start to mitigate its risks. Most organizations have many different types of web servers that serve different purposes and have different functionalities. The following factors need to be considered in order to assess the level of risk of a web server and determine what mitigating controls need to be put in place. Infrastructure. Many organizations have aging web servers that support mission-critical applications. Most of these older web servers were not set up with security in mind. Couple this with the fact that these older systems are no longer supported, and you have a recipe for abuse and downtime. It is important to know what versions of operating systems and web server software your company runs, for a couple of reasons. One reason is patching. For example, if you know your versions of Apache, then you can easily track bugs and apply the appropriate patches. Along this same line, another reason is support. The risks associated with running a server that is not supported by the vendor can be addressed by upgrading or by implementing mitigating controls. Take Sony s obsolete version of Apache as an example. Sony had at least two choices: either upgrade or deploy a mitigating control like a web application firewall. Sony is hardly the only company that is slow to upgrade. Upgrades are a challenge if the web application was developed on an old platform that cannot be easily ported over to a newer operating system. Also, many companies running older, unsupported web servers do not want to take their servers offline to upgrade or patch, fearing that these older systems may not come back on line. Functionality. The attack surface of a web server has broadened in the past 10 years. A web server serving up static pages does not have much of an attack surface, unlike a blog or even a web server serving up a banking or financial application. Understanding the purpose of each web server in your infrastructure will give you greater understanding of what risks need your attention first. For example, a university may have a class catalog web server that serves up information about all the departments and the classes that students can take, but this content may be static, with no input fields. Then there is the student loan website, containing information on how to apply for loans. This server does accept input. There are forms for students to fill out and even a student logon page. 2 Protecting Web Servers

3 Both the class catalog and the student loan web servers are accessible from the public Internet. However, due to their different functionalities, each should be treated differently from a security perspective. Though this example is comparing two web servers at a university, almost every company or organization has similar scenarios. It could be that the company s main website has very limited functionality, yet their B2B server has extensive functionalities similar to the university s loan web server. Understanding your web servers functionalities will help you understand their criticality to the business or organization, and then you can determine the attention and security appropriate for each web server. Threat agent. The Open Web Application Security Project (OWASP) states that a threat agent is used to indicate an individual or group that can manifest a threat. It is fundamental to identify who would want to exploit the assets of a company, and how they might use them against the company. 2 For example, who or what the threat agent is will depend upon your company or organization and where or how the web server is accessed. US government agencies will have different threat agents than a big retail chain. The US government agencies have to consider international terror groups or hacktivists like Anonymous. A big retailer will have to be concerned with organized crime or hackers trying to steal PCI data or the personal information of their customers. Decision Elements These factors could influence your architecture: Does a third party host your web servers? Does a third party host your web applications? Are you using a web application firewall? Access to the web server from either the public Internet or your Intranet will also define the threat agent. The big retail store chain may have a web server that serves up human resource data to employees. An employee can log on and see insurance data and compensation information. The server also stores Social Security Numbers. However, this server is only accessible via the company s internal network. Though we could create an argument for external hackers, the threat agents in this scenario are employees. The internal threat can be split into unintentional or accidental or intentional or rogue. The unintentional threat agent might be an administrator who unknowingly changes the permissions on a directory from an exclusive group to everyone or does not remember to change a default password. A developer who makes a change to a code on the production system when she meant to make the change on the non-production web server is another example of an unintentional threat agent. In contrast, the intentional threat agent knowingly attacks a web server to gain information or bring a system down. Maybe it is an employee who has just been fired or one who wants to sell company data or employee personal information for his own profit. Since the perimeter requires many of our defenses and much of our attention, it is easy to overlook the internal or employee threat agent. Circumstances can change or create new threat agents. Hence, you need to be prepared to identify these threat agents on an ongoing basis. Staying informed of the public activities of your organization is important to understanding your threat agents. Sony is a good example of this. Their lawsuit against hacker GeoHot drew the attention of the hacker group Anonymous, which on April 4, 2011, staged a DoS attack on Sony s websites. If you have a legal department, ask them to keep you informed as to what legal actions they may be taking against public individuals or other companies or groups. Configuration and maintenance. Many web servers especially those with off-the-shelf operating systems and web server software are set up with unnecessary default and sample files, including applications, configuration files, scripts, and web pages. They may also have unnecessary services, such as content management and remote administration functionality, enabled by default. In addition, debugging functions may be enabled or administrative functions may be accessible to anonymous users. Each of these settings presents an open door to someone interested in abusing your web server. As you take the time to deactivate these settings, you need to be careful. A misconfigured web server also poses a risk to your organization. Server misconfiguration is number six on the OWASP Top 10.3 Misconfiguration can happen at any time during the lifecycle of the web server. Even the most securely configured web servers can quickly become vulnerable if not properly maintained. Protecting Web Servers 3

4 Assessing your web servers relative to the above factors will help you understand which of your web servers are at risk to the following attacks or exploits. This assessment of your infrastructure will also help you identify where you should concentrate your risk mitigation. Web Server Attacks Let s now look at the common attacks on web servers and see how the above concerns can make you more or less susceptible to these attacks. HTTP fingerprinting. This attack is aimed at determining what type and version of operating system and web server software your website or web application is running on, so the attacker can research and reuse any known exploits. For example, if your web server reveals that it is an IIS 7 web server, then the attacker can search the Internet for known exploits and target those vulnerabilities in your web server. It is very simple to attempt to fingerprint a web server. This can be done just by visiting and browsing a website because default landing pages, error messages, and forgotten test pages such as php.ini will cough up this information. Another very basic technique is to look at the server field in the HTTP header. Almost any free scanning tool will do this, including NetCat or nmap. Unauthorized access. The information gathered from HTTP fingerprinting will help the attacker to formulate other attacks. For example, imagine you left the phpinfo test page enabled. If an attacker figures out that your servers are running a web server consisting of Linux (operating system), Apache (web server software), MySQL, and PHP, then the attacker can try default usernames and logons to gain unauthorized access to your web server. Web servers have default passwords and sample functionality that make this job easy. There are also websites with default credentials for all web server software. For instance, the default administrator username and password for Apache Tomcat is admin and no password, or tomcat, tomcat or root, root. There are websites with default credentials for all web server software. Web servers also have sample functionality that can be easily used in the attacker s favor, perhaps by trying to step above the IISSAMPLES directory to access any sample scripts that have not been locked down or removed. There are other ways to get unauthorized access to a web server or web application, such as session hijacking, brute force, bad passwords (guessing passwords), and abusing password change or forgotten username and password functionality. Refer to the OWASP website ( for more details on these types of attacks. Denial of service (DoS). In a denial of service (DoS) attack, an attacker attempts to prevent legitimate users from accessing information or services on your web servers, potentially requiring extended downtime for your web server and web applications. The DoS attack on Sony by Anonymous led to Sony s websites being unavailable for weeks or months, depending on the region, which led to loss of revenue. 4 Code injection. The best known of the code injection attacks is SQL injection, but there is a whole host of these attacks: LDAP injections, OS command injections, XPath injections, the list goes on. OWASP has Injection as the number one vulnerability on their OWASP Top 10 for 2010 and states 4 Protecting Web Servers

5 Injection flaws occur when an application sends untrusted data to an interpreter. Injection flaws are very prevalent, particularly in legacy code, often found in SQL queries, LDAP queries, XPath queries, OS commands, program arguments, etc. 5 Each of these code injection attacks can have a book written about it; we will just look at two: SQL injection and OS Command Injection. A SQL injection attack tries to exploit the interaction between the web server and the backend database. Many websites use databases to store information. SQL commands are passed from the front-end web application being served up by the web server to the backend database. For example, a client may want to buy something from your company via your web server and may fill out a form requesting the widget. There will be a place for amount, total price, name of client, and more. At the end, the user will click on a submit button to complete the transaction, which will execute a SQL statement against the database. A SQL injection attack tries to exploit flaws in the web application to execute SQL statements and commands on the backend database for malicious reasons, such as to reveal personal data or inject code that can be run on another person s computer when they access the database. Like the interaction between web applications and databases, operating systems and web server software can be intertwined. Developers will write code to call operating system functions, such as listing out the directory structure on a system or the contents of a directory or the contents of a file. If the attacker can cat a file, then what would stop them from running the command cat /etc/passwd to list out the users on the system? Again, visit the OWASP web site to learn more: Main_Page. The above attacks will affect each of your servers differently, depending on your infrastructure, functionality, agent targets, and configuration and maintenance of your web servers. If your servers are not configured properly and well maintained, and your infrastructure is made up of older operating systems, a successful HTTP fingerprint attack could reveal that your web server is an unpatched IIS 5.0 system and target a well-known buffer overflow vulnerability in the indexing services (the CodeRed worm exploited this vulnerability). Unauthorized access and code injections also play upon misconfigurations in operating system and web server software, as well as the web application. However, these attacks may be irrelevant if your web servers do not have a backend database and you are serving up static pages of publicly available information. The only concern you may have will be OS command injection attacks that could lead to the web server being used for malicious purposes such as attacking another server or servers. This range of risks shows how important it is to understand each of your web servers relative to infrastructure, function, threat agent, and configuration and maintenance. Protecting Web Servers 5

6 Solution Description You must know what you have before you can protect it. Your web security solution should help you assess and implement the appropriate protection for each of your web servers. The management of the solution should bring together all the disparate data of your web servers into a central console for ease of analysis and the subsequent securing of these assets. Infrastructure. The infrastructure should be mapped out initially via a scan of all web servers. Scans can encompass the operating system, web server software, and web application or be targeted to a specific part of the web server infrastructure. During the scan, data should be collected centrally to allow an assessment of the current risk of the infrastructure. Detailed security decisions can then be made based on data such as existing versions of operating systems, web server software, and web applications, along with configuration information. For instance, on newer web servers you might deploy proactive protection against common web attacks, such as directory traversal, code injections, and denial-of-service (DoS) attacks. Unsupported older web servers might need to be locked down, so that unknown code cannot be executed on deprecated operating systems. However, known good code will be allowed to run. This process restriction can protect the web servers even though they cannot be patched. Functionality. A deeper, more targeted scan of the web servers can determine the functionality of each web server. This scan will go beyond the operating system and its configuration to target just the web applications and backend databases, if present. Web applications can then be grouped like assets according to each web server s functionality. The criticality of each web server can be added to the description of the asset in a central administrative console, making it easier for administrators to know if a business-critical web server is in need of attention. Deploy specific protections and levels of protection according to the specific functionality of each web server. For example, if not already protected by application firewalls, web servers hosting critical business applications can deploy local security against common web attacks such as directory traversal, code injections, and denial-of-service (DoS) attacks. This security can be added in the form of host intrusion prevention on the server itself. Use predefined shielding policies and rules to prevent attacks and loss of data. If the functionality of the web server includes interaction with a backend database, implement protection to examine database queries to prevent attacks (such as SQL injection) and then deploy policies and rules to ensure normal behavior and prevent tampering of data. Implement flexible antivirus built specifically for high performance, so it can keep up with web traffic. If end users can upload files to a web server, a database, or just a share directory, these uploads should be scanned for malware to protect the server from infected files or intentionally uploaded viruses. Threat agent. Use a vulnerability scan to test how a threat agent might exploit the web assets of a company. The assessment will not reveal the intent of the threat agent, but it will determine if the web server is vulnerable to exploitation. Intentional threat agents using code injection or denial of service attacks can be mitigated by deploying host intrusion prevention with proactive protection against these common web attacks. Unintentional threat agents, such as employees installing untested patches, can be alleviated by blocking changes outside the change process and any unwanted changes. 6 Protecting Web Servers

7 Configuration and maintenance. Each newly built web server should be scanned and checked for misconfiguration. A gold master template can be used to determine adherence to industry standards or your company s required hardening processes. After the web server has rolled out to production, a continuous scheduled scan should be used to assess the web servers. These automated maintenance scans test for misconfigurations, missing patches, vulnerabilities, and anything that could lead to exploitation of the web server or the hosted web application. Implement a change process based on a trust model. By only allowing trusted agents to make changes to your web servers, you gain control. Since changes can only occur within the change framework, you can prevent unapproved or unknown changes from introducing vulnerabilities or causing the image to drift from the approved, tested, compliant version. Whether the change is approved and allowed or unapproved and blocked, these actions should be tracked and administrators alerted, minimizing the chance of an error escalating to serious downtime. Technologies Used in the McAfee Solution The McAfee solutions are flexible to fit your web server security needs. The solution you choose for one web server may not be appropriate for another. Therefore, McAfee suggests the following solutions be considered individually or together: McAfee Vulnerability Manager with the Web Application Assessment Module (WAAM), McAfee Host Intrusion Prevention, McAfee Application Control, McAfee Change Control, and McAfee VirusScan Enterprise. These solutions are managed with McAfee epolicy Orchestrator (McAfee epo ). Internet Firewall McAfee Network Security Platform Enterprise Network McAfee Vulnerability Manager (MVM) McAfee epo Web Server McAfee Application Control McAfee Change Control McAfee Host IPS McAfee VirusScan Web Application Assessment Module McAfee products help reduce the attack surface of your web server with protections designed explicitly for web server risks. Protecting Web Servers 7

8 McAfee Vulnerability Manager and the Web Application Assessment Module (WAAM) McAfee Vulnerability Manager works with the McAfee Web Application Assessment Module (WAAM) to help organizations discover vulnerabilities in the underlying operating system, as well as the web server software and web applications, before the hacker does. McAfee Vulnerability Manager (MVM) will test the web server s operating system (Linux, UNIX, or Windows) against multiple checks and return results that administrators can use to fix or mitigate vulnerabilities. The Web Application Assessment Module (WAAM) will probe and test the web server software, such as IIS or Apache, as well as any web application for vulnerabilities, such as code executions or injections, and warn of any unpatched or vulnerable web servers. The Web Application scanner can take advantage of pre-built templates to perform a deep scan based on the required checks for PCI, the OWASP Top 10, or CWE/SANS Top 25, or home in on specific checks such as Cross Site Scripting or path traversals. Both MVM and WAAM will help IT security administrators proactively monitor web servers to discover vulnerabilities or unpatched systems. The Web Application Assessment Module is a completely integrated (user interface, reporting, engine, ticketing) module of McAfee Vulnerability Manager. MVM pulls the data together to give you actionable data so that risk can be calculated and mitigated. McAfee Host Intrusion Prevention McAfee Host Intrusion Prevention (IPS) is a host-based intrusion detection and prevention system that protects system resources and applications from external and internal attacks. It provides a manageable and scalable intrusion prevention solution for web servers. Its patented technology blocks zero-day and known attacks with robust buffer overflow protection. McAfee Host IPS uses signatures to protect specific applications and operating systems, for example, web servers such as Apache and IIS. The majority of signatures protect the entire operating system, while some protect specific applications. Signatures are also a collection of intrusion prevention rules that can be matched against a traffic stream. For example, a signature might look for a specific string in an HTTP request. If the string matches one in a known attack, Host IPS takes action. These rules provide protection against known attacks. Host IPS can also help protect against code injection attacks such as SQL injections. The Host IPS SQL engine intercepts incoming database queries before they are processed by the base engine. Each query is examined to see if it matches any known attack signatures, if it is well formed, and if there are telltale signs of SQL injection. Furthermore, SQL database signatures implement database shielding to protect the database s data files, services, and resources. In addition, database enveloping can be implemented to ensure that the database operates within its well-defined behavioral profile. McAfee Application Control Even the most security conscious enterprises have a hard time patching web servers. This may not be due to a flawed patching process, but to one or all three of the following: legacy unsupported systems, refusal by the business to allow the server downtime, or a vendor that has not approved the patches or service pack to run with their software. McAfee Application Control can alleviate these issues. McAfee Application Control protects the web server through dynamic whitelisting that only allows trusted applications to run on the web servers, along with memory and buffer overflow protection. For continuous control of the web server, McAfee Application Control also has change event transparency, which bridges protection with operational change policies. McAfee Application Control can be installed on legacy systems that are no longer supported, such as Windows NT 4.0. It has a light touch on system resources, which is important for legacy systems that lack extra capacity. Organizations that have implemented McAfee Application Control have been able to cut down on the number of times they patch, reducing downtime. 8 Protecting Web Servers

9 McAfee Change Control As we have discussed, change can be the downfall of a web server. Configuration and ongoing maintenance are critical processes. McAfee Change Control can be the basis for your change control process or be added to your company s existing process for better control of web servers. McAfee Change Control, like McAfee Application Control, tracks and validates attempted changes in real time on the web server. The two products can be used together to protect both the application and the data it depends on. Where Application Control is monitoring binaries, Change Control can target individual files or directories. Both McAfee Application Control and McAfee Change Control work on a trust model. If changes are attempted outside the approved channels of change (or Trust), the changes are not permitted. Yet if a trusted agent makes the change, it is allowed. Every change is tracked for further review. McAfee Change Control offers three distinct features: File Integrity Monitoring (FIM) Change Prevention Reconciliation (as an optional add-on) File Integrity Monitoring gives you details on who made which changes to which files, when, and how the changes were made. You get comprehensive visibility into attempts to modify critical files and registry keys. Change Prevention can write protect your critical files and registry keys from unauthorized tampering, such that changes are permitted only if the change is applied in accordance with the update policies. Finally, Reconciliation maps changes to their corresponding tickets in a Change Management System (CMS), providing an evidence trail for changes made in support of a Request for Change (RFC). 1. Authorized User Update 2. Authorized Administrators Enterprise Console 3. Authorized Third-Party Agents, e.g., Tivoli, SMS Secure Signal Updates McAfee Application Control and McAfee Change Control allow updates through a Trust Model Protecting Web Servers 9

10 McAfee VirusScan Some may think that running a virus scanner on a web server is not a good idea because of the potential performance impact, but the risks we have discussed make it smart to integrate the protection of McAfee VirusScan where possible. Most clients leverage VirusScan on web servers where users are uploading files to a directory. VirusScan can be integrated into the process so that files are scanned and either cleaned or denied from being written to the directory. There are two choices for VirusScan: Enterprise or Command Line scanner. VirusScan Enterprise and VirusScan Command Line scanner offer fast performance and protection of your web servers from: Viruses, worms, and Trojans Buffer overflows Potentially unwanted code and programs McAfee epolicy Orchestrator (McAfee epo ) McAfee epolicy Orchestrator is the single management console that collects and presents the data needed to understand the web servers security posture. It also controls the solutions needed to help mitigate the web servers risks. The following tasks can be performed within McAfee epo: View MVM and WAAM scans Analyze each web servers level of risk via data from MVM and WAAM as well as information on what security is on the web servers Deploy and manage McAfee VirusScan, McAfee Change Control, McAfee Host IPS, and McAfee Application Control on web servers Set up and automate scans, deployment, policies, and tasks McAfee epo is not only a central console to see all your web server assets within one pane of glass, but it has the ability to help you secure them more efficiently as well. 10 Protecting Web Servers

11 Impact of the Solution McAfee solutions will help you understand your web server infrastructure and protect each web server against the vulnerabilities, attacks, and threat agents that could disrupt it. McAfee Vulnerability Manger and the Web Application Assessment Module can test and identify whether or not your web servers are vulnerable to any or all of these attacks: HTTP Fingerprinting, Unauthorized Access, Denial of Service, and Code Injection. McAfee Host IPS can protect against most of these attacks via its signatures, such as IIS Site Server AdSamples Info Leak (HTTP Fingerprinting), Apache Shielding Configuration File Access (Unauthorized Access), IIS WebDAV Search Request DoS (Denial of Service), and MSSQL SQL Injection with DELAY (code injection). Where Host IPS may not be appropriate, such as on older web servers, McAfee Application Control and McAfee Change Control can be deployed. These systems can work together through a centralized management console for automated, efficient maintenance and visibility into changes and issues letting you take action before the damage is done. Protecting Web Servers 11

12 Additional Resources For more information about the Security Connected Reference Architecture, visit: About the Author Douglas Simpson has over 11 years in the IT industry. His experience includes designing, building, and managing networks with dedication to IT security, risk, and compliance. Doug is a graduate of Wittenberg University with a B.A. and holds current certifications in Information Systems Security Professional (CISSP), Ethical Hacker (CeH), IT Service Management (ITIL), and MCSE The information in this document is provided only for educational purposes and for the convenience of McAfee customers. The information contained herein is subject to change without notice, and is provided AS IS without guarantee or warranty as to the accuracy or applicability of the information to any specific situation or circumstance Mission College Boulevard Santa Clara, CA McAfee, McAfee Application Control, McAfee Change Control, McAfee epolicy Orchestrator, McAfee epo, McAfee Host Intrusion Prevention, McAfee VirusScan Enterprise, VirusScan, McAfee Vulnerability Manager, and the McAfee logo are registered trademarks or trademarks of McAfee, Inc. or its subsidiaries in the United States and other countries. Other marks and brands may be claimed as the property of others. The product plans, specifications, and descriptions herein are provided for information only and subject to change without notice, and are provided without warranty of any kind, express or implied. Copyright 2011 McAfee, Inc bp_protecting-web-servers-L3_1011