39,59 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
With more than 67% of web servers running Apache and web-based attacks becoming more and more prevalent, web security has become a critical area for web site managers. Most existing tools work on the TCP/IP level, failing to use the specifics of the HTTP protocol in their operation. Mod_security is a module running on Apache, which will help you overcome the security threats prevalent in the online world.
A complete guide to using ModSecurity, this book will show you how to secure your web application and server, and does so by using real-world examples of attacks currently in use. It will help you learn about SQL injection, cross-site scripting attacks, cross-site request forgeries, null byte attacks, and many more so that you know how attackers operate.
Using clear, step-by-step instructions this book starts by teaching you how to install and set up ModSecurity, before diving into the rule language with examples. It assumes no prior knowledge of ModSecurity, so as long as you are familiar with basic Linux administration, you can start to learn right away.
Real-life case studies are used to illustrate the dangers on the Web today ñ you will for example learn how the recent worm that hit Twitter works, and how you could have used ModSecurity to stop it in its tracks. The mechanisms behind these and other attacks are described in detail, and you will learn everything you need to know to make sure your server and web application remain unscathed on the increasingly dangerous web. Have you ever wondered how attackers figure out the exact web server version running on a system? They use a technique called HTTP fingerprinting, and you will learn about this in depth and how to defend against it by flying your web server under a "false flag".
The last part of the book shows you how to really lock down a web application by implementing a positive security model that only allows through requests that conform to a specific, pre-approved model, and denying anything that is even the slightest bit out of line.
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 363
Veröffentlichungsjahr: 2009
Ähnliche
Table of Contents
ModSecurity 2.5
Securing your Apache installation and web applications
Magnus Mischel
ModSecurity 2.5
Securing your Apache installation and web applications
Copyright © 2009 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
First published: November 2009
Production Reference: 1171109
Published by Packt Publishing Ltd.
32 Lincoln Road
Olton
Birmingham, B27 6PA, UK.
ISBN 978-1-847194-74-9
www.packtpub.com
Cover Image by Karl Moore (<[email protected]> )
Credits
Author
Magnus Mischel
Reviewers
Kai 'Oswald' Seidler
Daniel Cuthbert
Acquisition Editor
James Lumsden
Development Editor
Dhiraj Chandiramani
Technical Editor
Conrad Sardinha
Copy Editor
Sanchari Mukherjee
Indexer
Rekha Nair
Editorial Team Leader
Gagandeep Singh
Project Team Leader
Lata Basantani
Project Coordinator
Rajashree Hamine
Proofreader
Lynda Sliwoski
Graphics
Nilesh Mohite
Production Coordinator
Aparna Bhagat
Cover Work
Aparna Bhagat
About the Author
Magnus Mischel is the founder and director of Mischel Internet Security (http://www.misec.net), whose product TrojanHunter helps protect computers against malware. His long-time passion for computer security is what lead to him starting the company after realizing the threat that trojans and other malware pose to users. He currently lives in London, and when he isn't writing books or managing the company, he enjoys playing a game of chess at the Metropolitan Chess Club. He holds an MSc in Computer Science and Engineering from Linköping University, Sweden.
About the Reviewers
Kai 'Oswald' Seidler was born in Hamburg in 1970. He graduated from Technical University of Berlin with a Diplom Informatiker degree (Master of Science equivalent) in Computer Science. In the 90's he created and managed Germany's biggest IRCnet server irc.fu-berlin.de, and co-managed one of the world's largest anonymous FTP server ftp.cs.tu-berlin.de. He professionally set up his first public web server in 1993. From 1993 until 1998 he was member of Projektgruppe Kulturraum Internet, a research project on net culture and network organization. In 2002, he co-founded Apache Friends and created the multi-platform Apache web server bundle XAMPP. Around 2005 XAMPP became the most popular Apache stack worldwide. In 2006, his third book, Das XAMPP-Handbuch, was published by Addison Wesley.
Currently he's working as technology evangelist for web tier products at Sun Microsystems.
Daniel Cuthbert heads up Corsaire's Security Training and has over nine years of industry experience. During this time he has focused on Security Assessment for some of the world's largest consultancies and financial, telecommunication, and media institutions.
He holds a Masters Degree from the University of Westminster in IT Security and is both a founding member of the Open Web Application Security Project (OWASP) and previous UK Chapter Head. He has worked on helping companies adopt the Secure Development Lifecycle (SDLC) approach and has lectured extensively on the subject.
He has worked on a wide variety of books for the OWASP project.
Preface
Running a web service leaves you exposed in a lot of different ways. A security vulnerability in the web server software or any of the additional modules needed to run the site can result in a compromised server, lost data, and downtime. As a compromised server costs a lot to restore in terms of time and resources it pays to have the best security possible in place, and ModSecurity is an essential tool to protect your web service. This book aims to show you how to protect your server using ModSecurity as an important layer to prevent intrusions and detect intrusion attempts.
What ModSecurity is
ModSecurity is a web application firewall. Much like a traditional firewall, it filters incoming and outgoing data and is able to stop traffic that is considered malicious according to a set of predefined rules. It also has many advanced features such as HTTP transaction logging and content injection, which we will be covering later.
Rules are created and edited using a simple text format, which affords you great flexibility in writing your own rules. Once you master the syntax of ModSecurity rules you will be able to quickly write your own rules to block a new exploit or stop a vulnerability being taken advantage of. Make no mistake though, this text-based rule language is also very powerful and allows you to create very advanced filters as we will see in the later chapters.
Think of ModSecurity as a customs agent that sits at the border. Every request is examined to make sure no unauthorised payloads make it inside, to your web server. When an attack is discovered, the details can be written to a log file, or an email can be sent out to the administrator of the site to alert of the attempted intrusion.
Why you need ModSecurity
Imagine that you have your web server set up and chugging along nicely. It is serving requests without problems and not even straining under the load. Suddenly, it stops working—the web server port is closed and you can't even log on to it via SSH.
What you don't know is that there is a 0-day exploit for PHP, which you happen to be running on the server since most of the dynamic content is written in PHP. A malicious hacker has managed to use this new exploit to execute shell code on your server that added a new user account and allowed him to log on via SSH. Once inside, he proceeded to use a well-known privilege elevation exploit for the old version of the Linux kernel you are running to gain root privileges. As root he then had total control of the server and decided to gather whatever data he could off the server before panicking and deciding to cover his tracks by wiping the server's hard drive.
Does this sound far-fetched? It's not. Most compromised servers are attacked by using the web service to gain initial entry to it. You can't exploit a closed port, and port 80 is the one port that needs to be open to everyone for a web server to be able to function. Once inside, the attacker can then use other exploits to gain additional privileges, as in this example.
The difficulty in protecting a server is that new exploits appear all the time, and even if you patch them within a few days (which is something very few sites do!), there is still a certain time window where you are vulnerable to being attacked.
ModSecurity allows you to protect your server by writing generic rules that cover a broad range of possible attacking scenarios. Thus, ModSecurity is an additional layer that can protect you in a way that no patching, no matter how swift or meticulously done, can.
What this book covers
Chapter 1: Installation and Configuration shows how to compile ModSecurity from source, install and integrate it with Apache, and make sure it works.
Chapter 2: Writing Rules teaches you everything you need to know about writing ModSecurity rules.
Chapter 3: Performance takes a look at the performance of ModSecurity and what impact, if any, it has on the speed of your server and web application.
Chapter 4: Logging and Auditing teaches you how to configure logging and how to use the ModSecurity console to view logs online.
Chapter 5: Virtual Patching covers the technique of creating a "virtual" patch to fix any vulnerability which does not have a vendor-supplied patch, or where the source code to the web application is not available or easily patched.
Chapter 6: Blocking Common Attacks explains how common attacks on the web today work, and how to block them using ModSecurity.
Chapter 7: Chroot Jails is about creating a chroot jail for Apache, and how this can easily be accomplished using ModSecurity (usually it is a quite tedious task).
Chapter 8: REMO teaches you how to install and use the Rule Editor for ModSecurity (REMO), which is a graphical tool to create ModSecurity rules.
Chapter 9: Securing a Web Application takes a real-life web application and secures it using a positive security model, which means that only requests that correspond to a pre-defined pattern are allowed through; anything else is denied.
Appendix A: Directives and Variables contains a list of the directives available for use in your ModSecurity configuration file and also the variables available for use in rule writing.
Appendix B: Regular Expressions teaches you the basics of regular expressions so that you can make use of them when writing ModSecurity rules in a better way.
What you need for this book
This book is mainly targeted at Linux systems and as such most of the commands will be Linux commands. Many systems today run standard configurations such as LAMP (Linux, Apache, MySQL, PHP) and the book will put focus on those setups that are commonly used in real-world environments.
ModSecurity runs on many other platforms, such as FreeBSD, OpenBSD, HP-UX and Mac OS X. If you are familiar with the differences between Linux and your platform you should be able to use the advice in this book to get everything working on your particular platform.
As of the release date of this book the latest version of ModSecurity is 2.5. You can always find the latest release at www.modsecurity.org, which is the project's official web site.
Who this book is for
This book is aimed at the web server administrator who wishes to install and use ModSecurity on one or several web servers; either his own or those used by a company. The book does not assume the reader is an expert in Internet security and thus most vulnerabilities and exploits will be explained so that the reader is better able to understand the threat and the reason to guard against it.
There are many articles available online that cover ModSecurity; however most of them only examine one or two aspects of the module such as installation or how to write rules. This book aims to be a complete guide to the process of installing and deploying the module. You can also use this book as a reference guide when you need to create rules for a new or existing web server.
Once finished with the book, you will have a better idea of the exploits that are currently used by malicious hackers, and you will also know how to protect your servers against these and other exploits.
Some of the rules are aimed at specific application setups or languages such as PHP or SQL. However the book aims to explain the reason for creating the rules in as general terms as possible so that even readers who are not familiar with these languages will understand why certain rules will protect the server against attack.
Conventions
In this book, you will find a number of styles of text that distinguish between different kinds of information. Here are some examples of these styles, and an explanation of their meaning.
Code words in text are shown as follows: "Some collections have fixed fields, such as the GEO collection, which contains fields such as COUNTRY_NAME and CITY."
A block of code is set as follows:
When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:
New terms and important words are shown in bold. Words that you see on the screen, in menus or dialog boxes for example, appear in the text like this: "If necessary, you can change the protocol used to standard HTTP in the console settings under Administration | Web Server Configuration once you have logged in."
Note
Warnings or important notes appear in a box like this.
Tip
Tips and tricks appear like this.
Reader feedback
Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or may have disliked. Reader feedback is important for us to develop titles that you really get the most out of.
To send us general feedback, simply send an email to <[email protected]>, and mention the book title via the subject of your message.
If there is a book that you need and would like to see us publish, please send us a note in the SUGGEST A TITLE form on www.packtpub.com or email <[email protected]>.
If there is a topic that you have expertise in and you are interested in either writing or contributing to a book on, see our author guide on www.packtpub.com/authors.
Customer support
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
Tip
Downloading the example code for the book
Visit http://www.packtpub.com/files/code/4749_Code.zip to directly download the example code.
The downloadable files contain instructions on how to use them.
Errata
Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in the text or the code—we would be grateful if you would report this to us. By doing so, you can save other readers from frustration, and help us to improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/support, selecting your book, clicking on the let us know link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata added to any list of existing errata. Any existing errata can be viewed by selecting your title from http://www.packtpub.com/support.
Piracy
Piracy of copyright material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works, in any form, on the Internet, please provide us with the location address or web site name immediately so that we can pursue a remedy.
Please contact us at <[email protected]> with a link to the suspected pirated material.
We appreciate your help in protecting our authors, and our ability to bring you valuable content.
Questions
You can contact us at <[email protected]> if you are having a problem with any aspect of the book, and we will do our best to address it.
Chapter 1. Installation and Configuration
This chapter deals with the installation and basic configuration of ModSecurity. In this chapter you will learn about the following, among other things:
If you're new to ModSecurity I would recommend that you set it up on a test server while you get acquainted with the ins and outs of using it. You wouldn't want to deploy it on a production server only to find out a few days later that you've been blocking everyone in Europe from accessing your server because of a misconfiguration. (For more on blocking users from specific countries, see Chapter 2, Writing Rules.)
The installation instructions in this chapter show you how to compile ModSecurity from source. Some Linux distributions also make packages for ModSecurity available, but since compiling from source guarantees you will get the latest version of ModSecurity that is what we'll be doing in this chapter.
Versions
ModSecurity version 2.0 was first released in October 2006 and is a big improvement over the previous major version line. It is a substantial rewrite that changes the rule language and adds a lot of improvements such as:
At the time this book was published, the latest major ModSecurity version was 2.5, and this version line adds even more enhancements such as the ability to reference a geographical database, which allows you to create rules that take action based on the geographical location of the user. Another interesting new feature is credit card number detection, which can be used to detect and prevent credit card numbers from being exposed through your web server. Of course, all the other security features that make ModSecurity such a great web application firewall have been refined and are available in the latest version, and we will learn all about them in the coming chapters.
Since version 2 of ModSecurity is such a different beast to previous versions, this book focuses only on this latest major version branch. This means that you must run Apache 2.0 or later, as ModSecurity 2 requires this Apache branch to function.
As Apache 1.x is a legacy branch that is now only infrequently updated (and when updated, mostly to patch known security vulnerabilities), now might be a good time to upgrade to the 2.x branch of Apache if you're still running an older version.
Downloading
ModSecurity was originally developed by web application security specialist Ivan Ristic in 2002. He has also written the excellent book Apache Security (O'Reilly Media, 2005) which I highly recommend if you want a general book on hardening Apache. ModSecurity was acquired by Breach Security, a California-based web application security company, in 2006. The company chose to continue releasing ModSecurity as a free open source product (under the GPLv2 license), hiring Ivan and additional staff to work on the product, which is good news for all users of ModSecurity.
The ModSecurity source code is available at http://www.modsecurity.org/download/. The source is provided as a .tar.gz archive—to download it all you have to do is copy the link to the latest release and you will then be able to use wget to download the source archive to your server.
In the following text the name of the file used for the source archive is assumed to be modsecurity‑apache.tar.gz. Make sure you substitute the actual file name or web location (which usually includes the version number of the latest release) for this name when downloading or working with files.
Checking the integrity of the downloaded source archive
Checking the integrity of the downloaded archive file is always a good habit. This ensures that the file has not been tampered with in any way. There are two ways to do this—a less secure and a more secure way. The less secure way is to use the md5sum tool to calculate the MD5 sum of the downloaded file and then compare this MD5 sum to the one published on the ModSecurity website.
MD5 is an algorithm of a type called "cryptographic one-way hash". It takes an input of an arbitrary size (the source archive, in this case), and produces an output of a fixed length. A hash function is designed so that if even one bit changes in the input data, a completely different hash sum is calculated. The hash function should also be collision resistant. This means that it should be very hard to create two files that have the same hash value.
Using the MD5 sum to verify the integrity of the archive is less than optimal for two reasons: :
The better way to verify the integrity of the downloaded source archive is to use public key cryptography. In public key cryptography, encryption and decryption are performed using different keys. Encryption is performed using a private key, which only the person encrypting a file or document has access to. Decryption is done using a public key, which anyone can access and which can be published online.
When a file is signed using public key cryptography, a checksum for the file is first calculated, just like with the MD5 algorithm described above. The calculated hash is then encrypted using the signer's private key. You can then verify the integrity of the signed file by decrypting the hash (using the signer's public key) and comparing it to the calculated hash value. All of this is done automatically using a program such as PGP or Gnu Privacy Guard (GPG).
The developers of ModSecurity have signed the source code archive using their private key, which allows us to verify its integrity in the manner just described. The first thing we need to do in order to verify the archive is download the file that contains the signature:
We can then use the open source program GPG to verify the signature. GPG comes pre-installed on most Linux systems; however should the program not be installed on your system you can get it at http://www.gnupg.org.
When we try to verify the signature of the source archive using GPG we will encounter a problem, as we don't have the public key of the person who signed the file:
Fixing this is however easy. All we need to do is download the public key file used to sign the file, as specified by the key ID in the output above. The key is available on the server pgp.mit.edu, which is a repository of public key files.
Tip
If you have a firewall controlling outbound traffic, you need to enable connections to remote port 11371 for GPG to be able to download the key.
The following command is used to download the key from the server:
Now that we have downloaded the public key, all the required elements to check the signature are in place. Running the verification command again produces this output:
The verification of the source archive using the public key we just downloaded has succeeded, as evidenced by the line starting with Good signature from. However, what about the ominous-looking message Warning: This key is not certified with a trusted signature?
Public key cryptography tools such as GPG work using a concept called web of trust. In the same way that you might trust that your best friend's parents are the people he introduces to you as his parents, a public key can be trusted if other people you trust have verified that the key belongs to the actual person it is issued to. This verification of another key is called signing the key, and this can be done by many people (to continue our analogy, this would be like other people verifying that your best friend's parents are the people he introduced you to).
If you don't already have public keys installed on your system that build a chain of trust and verify that the key you just used really does belong to Brian Rectanus, there is a (very small) chance that someone could have forged his public key. Fortunately, for those who are very paranoid, or are working on a project that has high security demands, it is possible to verify that a public key belongs to a person. This is done by taking the key's fingerprint, and asking someone who knows Brian (or even Brian himself) to verify that his key has the fingerprint shown on your copy. You can show the fingerprints of all the keys you have imported into GPG by executing gpg --fingerprint.
Unpacking the source code
If you have downloaded the gzip file with the source code and saved it as modsecurity-apache.tar.gz you can use the following command to unpack it:
This will unpack the source code into a subfolder with the name modsecurity-apache. It will also create a directory structure in this folder where the different subfolders will hold the source code, documentation, and sample rules, among other things. A typical layout of the directories is as follows:
Contains the source code to ModSecurity as well as the files needed to build the binary module
modsecurity/docContains the ModSecurity reference guide in HTML and PDF format
modsecurity/rulesContains .conf files with pre-configured rules useful for stopping a variety of attacks. These rule files are known as the core ruleset, and this ruleset is continuously refined by Breach Security.
modsecurity/toolsContains supporting tools such as a Perl script to update rules (which is created during the compilation process).
Required additional libraries and files
ModSecurity requires the following additional components before you can compile it:
apxs is the APache eXtenSion tool and is used to compile extension modules for Apache. Since ModSecurity is an Apache module this tool is required to be able to compile ModSecurity. You can see if you have apxs installed on your system by running the following:
If apxs is available the above command will return its location, like so:
If you don't have apxs installed then it is available as part of a package called httpd-devel (or apache2-dev on Debian, Ubuntu, and related distributions). Use your favorite package manager to install this and you should then have apxs available on your system.
libxml2 is an XML parsing library. If you don't have this installed then you can get it by installing the package libxml2-devel (or libxml2-dev if you're using a Debian-based distribution).
Finally, mod_unique_id is an Apache module that generates a unique identifier for each HTTP request. (See http://httpd.apache.org/docs/2.0/mod/mod_unique_id.html if you are interested in the technical details on how this works.) Apache usually comes with this module pre-compiled, but you'll need to insert the following line in the module list of httpd.conf (you can find this list by looking for a bunch of lines all starting with the LoadModule directive) and restart the server for the module to be activated:
Note that this procedure for enabling the module is for Red Hat/Fedora-based distributions. On Debian/Ubuntu, for example, you would use the command a2enmod unique_id to enable the module.
To verify that mod_unique_id is indeed loaded into Apache you can run the following command and check for the presence of the line unique_id_module (shared) in the output listing:
Tip
On Debian-based distributions, use apache2 -t -D DUMP_MODULES instead of the above.
Compilation
As with other Linux software that comes as source, you need to compile ModSecurity to be able to use it. Compilation will result in a file called mod_security2.so, which is a binary shared module used by the Apache server in a plugin-like fashion. This module file contains all the functionality of ModSecurity.
Note
The fact that ModSecurity is an Apache module and not a stand-alone application (it could have been written as a reverse proxy server, filtering requests and then passing them to Apache) confers many advantages. One of these is the ability to inspect SSL connections and see data compressed using mod_deflate without having to write any additional code to decrypt or decompress the data first.
To get started compiling the source, change to the root user as you will require root privileges to install ModSecurity. Then change to the apache2 subfolder of the directory where you unpacked ModSecurity (for example, /home/download/modsecurity-apache/apache2/). This directory contains the source files and all the files needed to build the binary module.
To be able to compile the binary, you need a Makefile, which is a file that contains details of your particular server setup such as which compiler is available and what options it supports. To generate the Makefile, run the following command:
If the configure script stops with an error indicating that the PCRE library cannot be found, this is usually because you have compiled Apache from source and it has used the PCRE library that is bundled with the Apache distribution. Running configure --with-pcre=/path/to/apache-src/srclib/pcre should solve the problem (if it doesn't, edit Makefile and change the PCRE_CFLAGS and PCRE_LIBS variables to point to the pcre directory).
After this command has completed, check for the presence of a file called Makefile in the current directory. After making sure it exists you can go ahead and compile the binary:
You should see a fairly long list of messages written to the terminal as the compilation takes place, and if everything goes well there should be no error messages (though you may get a few compiler warnings, which you can ignore).
Integrating ModSecurity with Apache
The compilation process outlined in the previous section results in a file called mod_security2.so being created. This is an Apache dynamic shared object which is a plugin to Apache that adds functionality to the web server without requiring it to be recompiled. This file contains all the ModSecurity functionality, and integrating it like any other Apache module is, except for some basic configuration, all it takes to enable ModSecurity on your server.
The mod_security2.so file is output to the modsecurity-apache/apache2/.libs directory by the compiler. To let Apache know about ModSecurity, start by copying the mod_security2.so file to your Apache modules directory. Typically the modules directory will be something like /etc/httpd/modules, but the location will vary depending on your setup.
The next step is to edit the Apache configuration file and add a line to let the web server know about the new module. Start your favorite editor and open up httpd.conf (again, the location will vary depending on your setup, but assuming the same Apache base directory as in the previous section, the file will be in /etc/httpd/conf/httpd.conf). It's a good idea to create a backup copy of httpd.conf before you start editing the file, so that you can revert to the backup if anything goes wrong.
In httpd.conf there will be a fairly long list of configuration directives that start with the word LoadModule. Find this section of LoadModule directives and add the following line to the top of the list:
The security2_module string is known as the module identifier, and is declared in the source code of each module. It is used by Apache to later identify the module in such directives as IfModule, which turn on or off processing of configuration directives based on whether or not the module is loaded.
After adding this line, exit the editor and run apachectl configtest. This will test the new configuration file and report back any errors so you can fix them before attempting to restart the server. If all went well, run apachectl restart to restart the web server. This will load ModSecurity which means the fun part of writing rules can soon begin!
Configuration file
It is best to put all the configuration and security rules for ModSecurity in a separate file in the conf.d sub-directory of the Apache root directory. This prevents you from cluttering your main Apache configuration file with ModSecurity directives.
Simply start your favorite editor, create a file called modsec.conf in the conf.d directory, and enter the following to get started:
Make sure the IfModule directive uses the module identifier you provided in the LoadModule line in httpd.conf (security2_module in this case), otherwise Apache will ignore everything between the start and end of IfModule.
SecRuleEngine On turns on the rule engine so that it will start processing rules. For debugging purposes you can also set this to Off (which will turn off rule processing) or DetectionOnly, which will process rules but not take any action, even if a rule matches (which is helpful if you want to test that rules are working, but not block any requests should there be a problem with the rules).
The SecDefaultAction line above specifies what happens when a rule match occurs. In this case we want ModSecurity to deny the request with a status code 403 ("Forbidden"), and to write a log entry (which will show up in the Apache error log and the ModSecurity audit log). The default action is to allow requests even if a rule matches, so it is important to add this line to make sure any matching rule results in the request being denied.
You may be wondering what the phase:2 statement in the above directive does. ModSecurity divides the processing of a request into five phases—request headers, request body, response headers, response body and logging:
Phase number
Phase name
Phase occurs
1
REQUEST_HEADERS
Right after Apache has read the headers of the HTTP request.
2
REQUEST_BODY
After the request body has been read. Most ModSecurity rules are written to be processed in this phase.
3
RESPONSE_HEADERS
Right before the response headers are sent back to the client.
4
RESPONSE_BODY
Before the response body is sent back to client. Any processing of the response body to inspect for example data leaks should take place in this phase.
5
LOGGING
Right before logging takes place. At this point requests can no longer be blocked—all you can do is affect how logging is done.
As can be seen by the table, the most useful phase when we want to inspect incoming HTTP requests is the request body phase, in which all of the request headers, as well as the body, are available. By specifying phase:2 for the default action, subsequent rules will all be processed in phase 2 unless another phase is specified in a rule.
To override the default phase for a rule, you use the phase directive, as can be seen in this example, which stops processing and denies the request if the request header's user-agent field contains the string WebVulnScan, which is a script to find weaknesses in web servers:
This will cause the rule to be processed in phase 1—after the request headers have been received.
Completing the configuration
To complete the configuration we will introduce some additional directives. Here is the complete basic configuration file:
The SeqRequestBodyAccess On directive turns on processing of HTTP request bodies. This allows us to inspect uploads done via POST requests. When this directive is enabled, ModSecurity will buffer the request body in memory and process it before giving Apache access to it for the remaining processing.
Using the SecDebugLog directive, we specify the path to the debug log file. In this case it will be stored in the logs sub-directory of the Apache root. We set the SecDebugLogLevel to 0, meaning no debug data will be recorded. It's useful to have this in the configuration file so that the debug log level can be changed should we need to debug the ruleset.
Testing your installation
After completing the installation we need a way to test that the ModSecurity module has been loaded and is working as it should. The procedure described here can be used to test that ModSecurity is functioning correctly whenever you feel the need to verify this (such as after making changes to your Apache configuration file).
Creating a simple ModSecurity rule
To test that ModSecurity is working correctly we will create a simple HTML file and then deny access to it using a ModSecurity rule. Change to your web server's DocumentRoot directory and run the following command to create a file called secret.html containing our secret string:
Next, verify that you are able to access the file and see its content at the location http://yourserver/secret.html.
The main configuration directive used to create ModSecurity rules is called SecRule. You will learn all about using the SecRule directive in Chapter 2, but for now all you need to know is that this directive allows you to block content based on regular expressions.
We will now create a security rule to block access to this file. Enter the following in your modsec.conf file, below the configuration settings.
