Center for Internet Security Benchmark for Apache Web Server
Pre-configuration Checklist
It is important to realize that “Web Security” extends beyond the Web Server itself. There are many different web security vulnerabilities, which do not directly involve the web server itself. In order to truly secure a web infrastructure, many different information technology divisions must work together. These include, but are not limited to Firewalls, Intrusion Detection Systems, DNS, Networks Branch, etc… Take the time to build relationships with these groups and discuss web security issues. Hopefully, you will be able to identify deficiencies in your environment and fix them prior to exploitation attempts. The benchmark reader should review this sample checklist prior to applying the CIS Apache Benchmark. Reviewed and implement my company’s security policies as they relate to web security. Implemented a secure network infrastructure by controlling access to/from your web server by using: Firewalls, Routers and Switches. Implemented a Network Intrusion Detection System to monitor attacks against the web server. Implemented load-balancing/failover capability in case of Denial of Service or server shutdown. Implemented a disk space monitoring process and log rotation mechanism. The WHOIS Domain information registered for our web presence does not reveal sensitive personnel information, which may be leveraged for Social Engineering (Individual POC Names), War Dialing (Phone Numbers) and Brute Force Attacks (Email addresses matching actual system usernames). Domain Name Service (DNS) servers have been properly secured to prevent domain hi-jacking via cache poisoning, etc… Harden the Underlying Operating System of the web server. This should include minimizing listening network services, applying proper patches and hardening the configurations. Educated developers about writing secure code.
o OWASP Top Ten – http://www.owasp.org/index.php/OWASP_Top_Ten_Project
o WASC Threat Classification – http://www.webappsec.org/projects/threat/
1 Level 1 Apache Benchmark Settings
The Prudent Level of Minimum Due Care
Level-I Benchmark settings/actions meet the following criteria.
1. System administrators with any level of security knowledge and experience can understand and perform the specified actions.
2. The action is unlikely to cause an interruption of service to the operating system or the applications that run on the system.
3. The actions can be automatically monitored, and the configuration verified, by Scoring Tools that are available from the Center or by CIS-certified Scoring Tools.
Many organizations running the CIS scoring tools report that compliance with a CIS “Level-1” benchmark produces substantial improvement in security for their systems connected to the Internet.
1.1 Installation
Question Are you planning to use the precompiled Apache httpd binary that is available by default with many Unix Operating Systems or a commercial version supplied by a Vendor (such as WebLogic or Oracle’s Application Server 9iAS/10G)?
If you answered yes, then continue with the section. If you answered no, or in the event vendor binaries are not available or suitable, recommended instructions for downloading, building from the source and installing are included this sample chapter from Apache Security[1] by Ivan Ristic – http://www.apachesecurity.net/download/apachesecurity-ch02.pdf. Description The CIS Apache Benchmark recommends using the Apache binary provided by your vendor for most situations. The benefits of using the vendor supplied binaries include[2]: Ease of installation as it will just work, straight out of the box. It is customized for your OS environment. It will be tested and have gone though QA procedures. Everything you need is likely to be included, probably including some third party modules. Many OS vendors ship Apache with mod_ssl and OpenSSL and PHP, mod_perl and ModSecurity for example. Your vendor will tell you about security issues in all those bits, you have to look in less places. Updates to fix security issues will be easy to apply. The vendor will have already verified the problem, checked the signature on the Apache download, worked out the impact and so on. You may be able to get the updates automatically, reducing the window of risk.
There are times when compilation from source code will be necessary or advantageous, however for most situations the vendor binaries will provide better security by ensuring that updates are applied according to the existing update process. Which Apache Version to use? There are currently three different Apache forks: 1.3.x, 2.0.x and 2.2.x. At the time of this writing, the current stable versions are 1.3.37, 2.0.59 and 2.2.4. There may be restrictions as to which version of Apache you must use, however if it is at all possible it is recommended that you use the 2.2.x fork. The main reasons are security related as this is the current branch where the majority of improvements are made. Additionally, in order to use the ModSecurity 2.x web application firewall package, you must be using either the 2.0.x or 2.2.x version. Action Install the Apache Software using vendor provided binaries if available For Red Hat/Fedora: # yum install httpd2 For Debian systems: # apt-get install apache2-mpm-prefork
1.2 ModSecurity Overview
Important Note ModSecurity has quickly matured over the years and has become the most widely deployed web application firewall. Due to the fact that is open source and free, coupled with its flexible rules language and extensive logging capabilities, the CIS Apache Benchmark highly recommends that all Apache deployments install it. We do however realize that not all deployments will be able to use this application. It is for this reason that many sections will be providing both an Apache and a ModSecurity setting that can be used to mitigate the issues. There were many previous benchmark sections that attempted to leverage Apache modules and directives to achieve a specific security goal. Some of these settings worked to a certain degree however some were not flexible enough to fully handle the issue. ModSecurity, on the other hand, is able to better address these issues. It is for this reason that most of these benchmark settings will include an analogous ModSecurity feature or ruleset in addition to the standard Apache directive or configuration. We will still provide the Apache directive examples, however we will include information about its limitations and a rationale for using ModSecurity. Description
ModSecurity is an open-source, free web application firewall module that integrates into the Apache web server. The project website is www.modsecurity.org. It is available under the open source GPL license, with optional commercial support and licensing
(from Breach Security – www.breach.com). There are two versions of the module, one for each major Apache branch, and they are almost identical in functionality. In the Apache 2 version, mod_security uses the advanced filtering API available in that version, making interception of the response body possible. The Apache 2 version is also more efficient in terms of memory consumption. In short, ModSecurity does the following: Intercepts HTTP requests before they are fully processed by the web server Intercepts the request body (e.g., the POST payload) Intercepts, stores, and optionally validates uploaded files Performs optional anti-evasion actions Performs request analysis by processing a set of rules defined in the configuration Intercepts HTTP responses before they are sent back to the client (Apache 2 only) Performs response analysis by processing a set of rules defined in the configuration Takes one of the predefined actions or executes an external script when a request or a response fails analysis (a process called detection) Depending on the configuration, a failed request may be prevented from being processed, and a failed response may be prevented from being seen by the client (a process called prevention) Performs audit logging
In this section, we will cover the essentials for installation and configuration. For a detailed reference manual, visit the project documentation area at http://www.modsecurity.org/documentation/. Action
In order to ensure that you are using the latest and greatest version, you should download the ModSecurity source code from the project website – http://www.modsecurity.org/download/index.html. As of this writing, the current version is 2.1.2. Follow the steps outlined in the Installation section of the Reference Manual – http://www.modsecurity.org/documentation/modsecurity-apache/2.1.2/modsecurity2-apache-reference.html#02-installation
If you run into any issues with installation, configuration or usage, you should sign up on the ModSecurity users mail-list here – https://lists.sourceforge.net/lists/listinfo/mod-security-users.
1.3 ModSecurity Core Rules Overview
Description
ModSecurity is a web application firewall engine. Being the Swiss army knife of application firewalls it can do everything but requires rules to tell it what to do. In order to enable users to take full advantage of ModSecurity out of the box, ModSecurity includes the Core Rule Set, an open source rule set licensed under GPLv2. ModSecurity Core Rule Set works with ModSecurity 2.1 and above.
Unlike intrusion detection and prevention systems, which rely on signature specific to known vulnerabilities, the Core Rules is based on generic rules in order to provide protection from zero day and unknown vulnerabilities often found in web applications, which are in most cases custom coded.
As a generic negative security rule set, the Core Rule Set is only one layer in your application protection. You can learn more about the pros and cons of a negative security model in the presentation “The Core Rule Set: Generic detection of application layer”, presented at OWASP Europe 2007. In addition to the Core Rule Set you may want to harden your Apache installation, for which you can consult Ivan Ristic’s book, Apache Security. You may also consider writing custom rules for providing a positive security envelope to your application or critical parts of it. Breach Security can provide you with training and professional services to assist you in doing that. On additional methodologies which complement the Core Rule Set including positive security and virtual patching you can read in Ryan Barnett’s book, Preventing Web Attacks with Apache Why The Core Rule Set? The focus of the core rule set is to be a “rule set” rather than a set of rules. What makes a rule set different than a set of rules? Performance – The Core Rule Set is optimized for performance. The amount and content of the rules used predominantly determines the performance impact of ModSecurity, so the performance optimization of the rule set is very important. Quality – While there will always be false positives, a lot of effort is put into trying to make the Core Rule Set better. Some of the things done are:
o Regression tests – a regression test is used to ensure that every new version shipped does not break anything. Actually every report of a false positive, once solved, gets into the regression test.
o Real traffic testing – A large amount of real world capture files have been converted to tests and sent through ModSecurity to detect potential false positives. Generic Detection – The core rule set is tuned to detect generic attacks and does not include specific rules for known vulnerabilities. Due to this feature the core rule set has better performance, is more “plug and play” and requires less updates. Event Information – Each rule in the Core Rule Set has a unique ID and a textual message. In the future rules are also going to be classified using a new tag action in ModSecurity, as well as longer information regarding each rule using comments in the files themselves. Plug and Play – The Core Rule Set is designed to be as plug and play as possible. Since its performance is good and it employs generic detection, and since the number of false positives is getting lower all the time, the Core Rule Set can be installed as is with little twisting and tweaking.
Content In order to provide generic web applications protection, the Core Rules use the following techniques:
Protocol compliance: HTTP request validation – This first line of protection ensures that all abnormal HTTP requests are detected. This line of defense eliminates a large number of automated and non targeted attacks as well as protects the web server itself. HTTP protocol anomalies – Common HTTP usage patterns are indicative of attacks. Global constraints – Limiting the size and length of different HTTP protocol attributes, such as the number and length of parameters and the overall length of the request. Ensuring that these attributed are constrained can prevent many attacks including buffer overflow and parameter manipulation. HTTP Usage policy – validate requests against a predefined policy, setting limitations request properties such as methods, content types and extensions.
Attack Detection: Malicious client software detection – Detect requests by malicious automated programs such as robots, crawlers and security scanners. Malicious automated programs collect information from a web site, consume bandwidth and might also search for vulnerabilities on the web site. Detecting malicious crawlers is especially useful against comments spam. Generic Attack Detection – Detect application level attacks such as described in the OWASP top 10. These rules employ context based patterns match over normalized fields. Detected attacks include:
o SQL injection and Blind SQL injection.
o Cross Site Scripting (XSS).
o OS Command Injection and remote command access.
o File name injection.
o ColdFusion, PHP and ASP injection.
o E-Mail Injection
o HTTP Response Splitting.
o Universal PDF XSS. Trojans & Backdoors Detection – Detection of attempts to access Trojans & backdoors already installed on the system. This feature is very important in a hosting environment when some of this backdoors may be uploaded in a legitimate way and used maliciously.
Other: Error Detection – Prevent application error messages and code snippets from being sent to the user. This makes attacking the server much harder and is also a last line of defense if an attack passes through. XML Protection – The Core Rule Set can be set to examine XML payload for most signatures. Search Engine Monitoring – Log access by search engines crawlers to the web site.
Action
Recent Comments