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.

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.

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.

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.

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.

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:

SecRule REQUEST_URI "passwd" "pass,setvar:tx.hackscore=+5"
SecRule REQUEST_URI "<script" "pass,setvar:tx.hackscore=+10"
SecRule TX:HACKSCORE "@gt 10" deny

When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:

--e8d98139-B--
GET /login.php?password=****** HTTP/1.1

Host: bytelayer.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: JSESSIONID=4j4gl8be129l6

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."

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.

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.