Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Save more on your purchases! discount-offer-chevron-icon
Savings automatically calculated. No voucher code required.
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Newsletter Hub
Free Learning
Arrow right icon
timer SALE ENDS IN
0 Days
:
00 Hours
:
00 Minutes
:
00 Seconds
ModSecurity 2.5
ModSecurity 2.5

ModSecurity 2.5: Prevent web application hacking with this easy to use guide

eBook
$28.99 $32.99
Paperback
$54.99
Subscription
Free Trial
Renews at $19.99p/m

What do you get with eBook?

Product feature icon Instant access to your Digital eBook purchase
Product feature icon Download this book in EPUB and PDF formats
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want
OR
Modal Close icon
Payment Processing...
tick Completed

Billing Address

Table of content icon View table of contents Preview book icon Preview Book

ModSecurity 2.5

Chapter 2. Writing Rules

ModSecurity is an extremely powerful and versatile web application firewall. However, to be able to utilize its power you need to learn how to tell ModSecurity what you want it to do. That is what this chapter is for—it will teach you all about writing ModSecurity rules, including some interesting uses for ModSecurity that extend beyond just blocking malicious requests (you will for example learn how to redirect requests for files to the closest server depending on where in the world a visitor is located, and you'll learn how to count the number of downloads of a binary file and store the resulting statistics in a MySQL database).

To give you a brief outline of the chapter, here is the order in which we will be looking at the business of writing ModSecurity rules:

  • The syntax of SecRule

  • What variables are available and how to use them

  • Operators, and how they relate to variables

  • Regular expressions—what they are, and why they're important when writing rules

  • Actions—denying...

SecRule syntax


SecRule is the directive that is used to create ModSecurity rules. Its syntax is simple, but don't let that fool you. For almost any scenario you can imagine where you want to process a request in a certain way (whether by denying it, forwarding it or doing some more advanced processing), there is a way to use SecRule to solve the problem.

The basic syntax of SecRule is as follows:

SecRule Target Operator [Actions]

Target specifies what part of the request or response you want to examine. In the basic example given in the previous chapter, we used the variable named REQUEST_URI, which contains the requested URI on the server, to identify and block any attempts to access the location /secret.html. There are over 70 variables that can be used to create rules, meaning there is likely to be a way to match a rule in almost any circumstance where you need to create a rule.

There is also a special kind of variable called a collection that can hold several values. An example of...

Creating chained rules


Sometimes you want a match to trigger only if several conditions apply. Say for example that our web site owner from the previous example wanted to block the troublesome downloader, but this downloader was also used by other clients where it wasn't misbehaving by downloading the same file over and over. Also, for the sake of argument let's assume that it wouldn't be possible to just block the client's IP address as he was on DSL and frequently appeared with a new address.

What we'd want in this case is a rule that denies the request if the user-agent string contains "Red Bullet" and the IP address of the client belongs to the subnet range of a particular ISP.

Enter the chain action. Using this, we can create a chain of rules that only matches if all of the individual rules in the chain match. If you're familiar with programming, you can think of chained rules as rules with a logical and operator between them—if a single one of them doesn't match then the rule chain...

Rule IDs


You can assign an ID number to each rule by using the id action:

SecRule ARGS "login" "deny,id:1000"

This allows the rule to be identified for use with:

  • SecRuleRemoveById (removes the rule from the current context)

  • SecRuleUpdateActionById (updates a rule's action list)

  • skipAfter:nn (an action—jump to after the rule with the ID specified)

The SecMarker directive should be mentioned here. Its purpose is to create a marker, which is essentially a rule with just an ID number, for use with the action skipAfter.

The following example checks to see if the ModSecurity version is at least 2.5, and skips over a set of rules in case an older version that may not support them is installed:

SecRule MODSEC_BUILD "@lt 020500000" "skipAfter:1024"
...
Rules requiring version >= 2.5
...
SecMarker 1024

An introduction to regular expressions


Regular expressions are an important part of writing ModSecurity rules. That is why this section contains a short introduction to them and why the book also has an appendix that describes them in more detail.

Regular expressions are a very powerful tool when it comes to string matching. They are used to identify a string of interest, and are useful for many different tasks, such as searching through large text files for a given pattern, or, as used in ModSecurity, to define patterns which should trigger a rule match.

Programming languages such as Perl come with regular expression support built right into the syntax of the language (in fact, the PCRE library that was mentioned in the previous chapter that is used by Apache and ModSecurity is a re-implementation of the regular expression engine used in Perl). Even Java's String class has the matches() method which returns true if the string matches the given regular expression.

Regular expressions are so...

Simple string matching


You may ask if there isn't a way to match a string that ends with a certain other sub-string, without having to bother with escaping dots and putting dollar signs at the ends of lines. There is actually an operator that does just that—it's called @endsWith. This operator returns true if the targeted value ends with the specified string. If, as in the example above, we wanted to block remote hosts from microsoft.com, we could do it by using @endsWith in the following manner:

SecRule REMOTE_HOST "@endsWith .microsoft.com" deny

If we wanted to negate the above rule, and instead block any domain that is not from Microsoft, we could have done it in the following way:

SecRule REMOTE_HOST "!@endsWith .microsoft.com" deny

It is good practice to use simple string matching whenever you don't need to utilize the power of regular expressions, as it is very much easier to get a regular expression wrong than it is to get unexpected results with simple string matching.

The following...

Matching numbers


Both regular expressions and the simple string matching operators work on character strings. As we saw in a previous example, using a regex to match against numbers can be error-prone, and regular expressions can often be cumbersome when you want to match against numbers. ModSecurity solves this problem by providing us with operators that can be used to compare numbers when we know that the arguments we are examining are numeric.

The following are the numerical operators ModSecurity provides:

Operator

Description

@eq?

Matches if the variable contains a number that is equal to the specified value.

Example:

SecRule RESPONSE_STATUS "@eq 200"

This rule matches if the response code is 200.

@ge?

Matches if the variable contains a number that is greater than or equal to the specified value.

Example:

SecRule RESPONSE_STATUS "@ge 400"

This rule matches if the response code is greater than or equal to 400. Since error codes are defined as having an HTTP status code...

More about collections


Let's look at some more things that can be done with collections, such as counting the number of items in a collection or filtering out collection variables using a regex.

Counting items in collections

You can count the number of items in a collection by prefixing it with an ampersand (&). For example, the following rule matches if the client does not send any cookies with his request:

SecRule &REQUEST_COOKIES "@eq 0"

You can also use the count operator to make sure that a certain field in a collection is present. If we wanted a rule to match if the User-Agent header was missing from a request we could use the following:

SecRule &REQUEST_HEADER:User-Agent "@eq 0"

The above will match if the header is missing. If instead there is a User-Agent header but it is empty the count operator would return 1, so it is important to be aware that there is a difference between a missing field and an empty one.

Tip

It is perfectly valid for a query string or POST request to...

Transformation functions


ModSecurity provides a number of transformation functions that you can apply to variables and collections. These transformations are done on a copy of the data being examined, meaning that the original HTTP request or response is never modified. The transformations are done before any rule matching is attempted against the data.

Transformation functions are useful for a variety of purposes. If you want to detect cross-site scripting attacks (see Chapter 6 for more on this), you would want to detect injected JavaScript code regardless of the case it was written in. To do this the transformation function lowercase can be applied and the comparison can then be done against a lowercase string.

To apply a transformation function, you specify t: followed by the name of the function and then put this in the action list for the rule. For example, to convert the request arguments to all-lowercase, you would use t:lowercase, like so:

SecRule ARGS "<script" "deny,t:lowercase...

Other operators


Let's look at some additional operators that can be used to operate on data. We have already seen the regular expression, simple string comparison and numeral comparison operators earlier, and here we take a look at some additional ones that are available for use.

Set-based pattern matching with @pm and @pmFromFile

We have seen how to write regular expressions that match one of several alternative words. For example, to match red, green, or blue we would use the regex (red|green|blue). ModSecurity has two "phrase matching" operators that can be used to match a set of words: @pm and @pmFromFile.

The @pm version of our color-matching example would look like this:

SecRule ARGS "@pm red green blue" deny

This will trigger if an argument contains any of the strings red, green, or blue. As with the regex operator, a partial match is enough, so a query string of the form ?color=cobaltblue would trigger a match since the argument value contains the string blue.

Set-based pattern matching...

Phases and rule ordering


It is important to understand in which order ModSecurity evaluates rules. This makes you more comfortable when creating your own rules and avoids situations where things are unexpectedly blocked or allowed even though you expect the opposite to happen.

We learned in Chapter 1 that the rule engine divides requests into five phases:

  1. REQUEST_HEADERS (phase 1)

  2. REQUEST_BODY (phase 2)

  3. RESPONSE_HEADERS (phase 3)

  4. RESPONSE_BODY (phase 4)

  5. LOGGING (phase 5)

Rules are executed strictly in a phase-by-phase order. This means that ModSecurity first evaluates all rules in phase 1 ("request headers") for a match. It then proceeds with phases 2 through 5 (unless a rule match causes processing to stop).

Within phases, rules are processed in the order in which they appear in the configuration files. You can think of the ModSecurity engine as going through the configuration files five times; one time for each processing phase. During each pass, the engine considers only rules belonging...

Actions—what to do when a rule matches


When a rule matches you have several options: You can allow the request, you can deny it or you can opt to take no action at the moment but continue processing with the next rule. There are also several other things you can do like redirect or proxy requests. In this section you'll learn in more detail about the options that are available.

Allowing requests

The way the allow action works differs depending on how a rule is written. An allow action can be configured to work in one of three ways:

  1. Allow access immediately and skip remaining phases (except for logging).

    This is the case if allow is specified on its own, as in SecAction allow.

  2. Allow access to the current phase only.

    Specify allow:phase to allow in the current phase. Rule processing then continues immediately with the next phase, and rules in this and subsequent phases may then override the allow with a deny action.

  3. Allow access to the request phases only.

    Specify allow:request to allow in...

SecAction


Using SecAction, you can execute any number of actions unconditionally. The syntax is:

SecAction Actions

As an example, the following SecAction logs a message to the HTTP error log file:

SecAction "pass,log,logdata:'Testing SecAction'"

It is important to specify pass in a SecAction directive, as the default action will be prepended to the action list just as with a normal SecRule. If the default action is to deny the request then the SecAction above would have denied all requests if pass was missing.

Using the ctl action to control the rule engine


The ctl action allows for fine-grained control of the rule engine. Using this action you can configure the engine on a per-transaction basis. The following parameters are supported:

Parameter

Description

Corresponding directive

auditEngine

Turn the audit engine on or off.

SecAuditEngine

auditLogParts

Define what data to include in audit logs.

SecAuditLogParts

debugLogLevel

Change the debug log level.

SecDebugLogLevel

ruleRemoveById

Remove a rule or a range of rules.

SecRuleRemoveById

requestBodyAccess

Turn request body access on or off.

SecRequestBodyAccess

requestBodyLimit

Set the request body limit.

SecRequestBodyLimit

requestBodyProcessor

Configure the request body processor.

N/A

responseBodyAccess

Turn response body access on or off.

SecResponseBodyAccess

responseBodyLimit

Set the response body limit.

SecResponseBodyLimit

ruleEngine

Turn the rule engine...

Macro expansion


You can include data from variables or collections in log messages or when you initialize other variables. This is called macro expansion, and is done by enclosing the variable or collection name in a percent sign and curly braces:

SecAction setenv:ADDR=%{REMOTE_ADDR}

It is important to note that when specifying a collection field in an action list you need to separate the collection name from the field name with a dot and not a colon:

SecRule "test" "log,msg:%{TX.0}"

Macro expansion is not currently supported in all circumstances (for example, the append and prepend actions currently don't support macro expansion).

SecRule in practice


Alright, now that we have had a look at the theory of writing rules, let's start doing some real work by writing rules for more real-life situations. In this section we will look at several examples of how to write rules and rule chains to accomplish a given task.

Blocking uncommon request methods

The three most commonly used HTTP request methods are GET, POST and HEAD. You might be surprised to learn that the HTTP specification actually implements many more methods—if a web server supports the WebDAV (Web-based Distributed Authoring and Versioning) extensions, the total number of methods becomes almost 30. As an example, here are the request methods implemented by the latest version of Apache:

GET

PUT

POST

CONNECT

OPTIONS

TRACE

PROPFIND

PROPPATCH

MKCOL

MOVE

LOCK

UNLOCK

CHECKOUT

UNCHECKOUT

DELETE

PATCH

COPY

VERSION_CONTROL

CHECKIN

UPDATE

LABEL

REPORT

MKWORKSPACE

MKACTIVITY

BASELINE_CONTROL

MERGE...

Executing shell scripts


ModSecurity can execute an external shell script when a rule matches. This is done via the exec action. This is a very powerful technique that allows you to invoke the full power of your favorite scripting language to take further action when a rule match occurs. You can in fact also invoke a binary program file, though most of the time a shell script will be more convenient to execute.

The invoked file must be executable by the Apache process, so make sure that you set the permissions on the file correctly. One catch when invoking a script is that the script must write something to stdout. If your script doesn't do this, ModSecurity will assume the execution has failed, and you will get the error message Execution failed while reading output in the Apache error log file.

Sending alert emails

As an example, suppose that we wanted to execute a script to email us an alert message whenever an attempted SQL injection exploit was detected. To do this, we need two things...

Injecting data into responses


ModSecurity allows us to inject data into the response sent back to the client if the directive SecContentInjection is set to On. This is possible because the rule engine buffers the response body and gives us the opportunity to either put data in front of the response (prepending) or append it to the end of the response. The actions to use are appropriately named prepend and append.

Content injection allows us to do some really cool things. One trivial example just to show how the technique works would be to inject JavaScript code that displays the message "Stop trying to hack our site!" whenever we detected a condition that wasn't severe enough to block the request, be where we did want to issue a warning to any would-be hackers:

SecRule ARGS:username "%" 
"phase:1,allow,t:urlDecode,append: 
'<script type=text/javascript>alert(\"Stop trying 
to hack our site!\");</script>',log,msg:'Potential 
intrusion detected'"

The above detects when someone tries...

Inspecting uploaded files


Another very useful ModSecurity feature is the ability to inspect files that have been uploaded via a POST request. So long as we have set RequestBodyBuffering to On we can then intercept the uploaded files and inspect them by using the @inspectFile operator.

To show how this works we will write a script that intercepts uploaded files and scans them with the virus scanner Clam AntiVirus. Clam AntiVirus is an open source virus scanner which you can obtain at http://www.clamav.net. Once you have installed it you can use the command clamscan <filename> to scan a file for viruses.

To intercept uploaded files we need to apply a few ModSecurity directives:

SecUploadDir /tmp/modsecurity
SecTmpDir /tmp/modsecurity

This specifies where ModSecurity stores the files it extracts from the request body. We need to make sure we create the temporary directory and that the Apache user has read and write access to it.

When using @inspectFile, ModSecurity treats the script output...

Summary


This chapter contained a lot of information, and you will no doubt want to refer back to it when writing rules. It will take a while to get used to the ModSecurity syntax if you haven't written rules before, so make sure you try out as many examples as possible and write rules of your own to get the hang of the process of creating new rules.

In this chapter we first looked at the basic SecRule syntax, and then learned how to match strings using either regular expressions or simple string comparison operators. We learned in which order the rule engine executes rules and why it's important to know about this to be able to write rules properly. We also learned about all the other things we need to know to successfully write rules such as transformation functions, macro expansion and the actions that can be taken when a rule matches.

In the second half of the chapter we looked at practical examples of using ModSecurity, including how to use a geographical database to locate visitors and...

Left arrow icon Right arrow icon

Key benefits

  • Secure your system by knowing exactly how a hacker would break into it
  • Covers writing rules in-depth and Modsecurity rule language elements such as variables, actions, and request phases
  • Covers the common attacks in use on the Web, and ways to find the geographical location of an attacker and send alert emails when attacks are discovered
  • Packed with many real-life examples for better understanding

Description

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.

Who is this book for?

This book is written for system administrators or anyone running an Apache web server who wants to learn how to secure that server. It assumes that you are familiar with using the Linux shell and command-line tools, but does its best to explain everything so that those who are not Linux experts can make full use of ModSecurity.

What you will learn

  • Compile ModSecurity from source and install it on a Linux system
  • Log any anomalous event and use the ModSecurity console to view log data online so that attempted break-ins can be quickly discovered and dealt with
  • Learn how a recent worm disabled Twitter and how it could have been stopped using ModSecurity
  • Guard against web site defacement by having ModSecurity scan for unauthorized changes to your web pages then alert you about issues via email.
  • Locate the geographical position of an attacker using ModSecurity applications
  • Know how attackers operate by learning about SQL injection, cross-site scripting attacks, cross-site request forgeries, null byte attacks, and many more
  • Put Apache in a chroot jail using ModSecurity ñ no more frustrating hours of tinkering to get everything working as it should
  • Prevent HTTP fingerprinting by flying your Apache server under a false flag
  • Protect against newly discovered vulnerabilities that don t have a vendor-supplied patch, using ModSecurity "just-in-time" patching
  • Prevent the source code of your web application being shown to the world if something goes wrong with your server configuration
  • Discover the real IP address of an attacker using ModSecurity, even if the attacker is behind a proxy server

Product Details

Country selected
Publication date, Length, Edition, Language, ISBN-13
Publication date : Nov 23, 2009
Length: 280 pages
Edition : 1st
Language : English
ISBN-13 : 9781847194756
Vendor :
Apache
Category :

What do you get with eBook?

Product feature icon Instant access to your Digital eBook purchase
Product feature icon Download this book in EPUB and PDF formats
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want
OR
Modal Close icon
Payment Processing...
tick Completed

Billing Address

Product Details

Publication date : Nov 23, 2009
Length: 280 pages
Edition : 1st
Language : English
ISBN-13 : 9781847194756
Vendor :
Apache
Category :

Packt Subscriptions

See our plans and pricing
Modal Close icon
$19.99 billed monthly
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Simple pricing, no contract
$199.99 billed annually
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Choose a DRM-free eBook or Video every month to keep
Feature tick icon PLUS own as many other DRM-free eBooks or Videos as you like for just $5 each
Feature tick icon Exclusive print discounts
$279.99 billed in 18 months
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Choose a DRM-free eBook or Video every month to keep
Feature tick icon PLUS own as many other DRM-free eBooks or Videos as you like for just $5 each
Feature tick icon Exclusive print discounts

Frequently bought together


Stars icon
Total $ 175.97
ModSecurity 2.5
$54.99
Metasploit Penetration Testing Cookbook
$54.99
Advanced Penetration Testing for Highly-Secured Environments: The Ultimate Security Guide
$65.99
Total $ 175.97 Stars icon

Table of Contents

9 Chapters
Installation and Configuration Chevron down icon Chevron up icon
Writing Rules Chevron down icon Chevron up icon
Performance Chevron down icon Chevron up icon
Audit Logging Chevron down icon Chevron up icon
Virtual Patching Chevron down icon Chevron up icon
Blocking Common Attacks Chevron down icon Chevron up icon
Chroot Jails Chevron down icon Chevron up icon
REMO Chevron down icon Chevron up icon
Protecting a Web Application Chevron down icon Chevron up icon

Customer reviews

Rating distribution
Full star icon Full star icon Full star icon Half star icon Empty star icon 3.7
(3 Ratings)
5 star 0%
4 star 66.7%
3 star 33.3%
2 star 0%
1 star 0%
str Jan 04, 2013
Full star icon Full star icon Full star icon Full star icon Empty star icon 4
Dieses Buch macht einen durchweg guten Eindruck. Aus meiner Sicht ist es als Einführung in ModSecurity, Nachschlagewerk und Rezeptesammlung gleichermaßen zu gebrauchen. Hier und da wären ein paar Erläuterungen mehr zu bestimmten Konfigurationen doch besser gewesen (daher "nur" 4 statt 5 Sterne).
Amazon Verified review Amazon
Russ McRee Jan 05, 2010
Full star icon Full star icon Full star icon Full star icon Empty star icon 4
ModSecurity 2.5 covers the latest release of ModSecurity, "a web application firewall deployed to establish an external security layer that increases security, detects, and prevents attacks before they reach web applications. With over 70% of all attacks now carried out over the web application level, organizations need every help they can get in making their systems secure."- ModSecurity makes full HTTP transaction logging possible, allowing complete requests and responses to be logged.- ModSecurity can monitor the HTTP traffic in real time in order to detect attacks.- ModSecurity can also act immediately to prevent attacks from reaching your web applications.- ModSecurity includes a flexible rule engine and can be deployed embedded or as a reverse proxy.Covering ModSecurity 2.5 comprehensively and intelligibly is no small feat, and Mischel has achieved the goal. His style is concise yet clear, technical but not overly verbose, and well organized.As "complete guides" go ModSecurity 2.5 meets the standard.All the expected content is present, from installation to configuration, audit logging to chroot jails, blocking and protection, Mischel is thorough and takes due care to be precise and accurate.I have already recommended this book to a vendor in dire need of improved protection for their web application. I'll give you one guess regarding why they said "We can't use ModSecurity." Yep, performance. To which I said, "Yeah, but how's your performance with the terrible code you've written and the resulting SQL injection attack that took your site apart?"All of which takes us to my favored highlight of ModSecurity 2.5; specifically an entire chapter dedicated to performance. This was a great decision of Mischel's part. Performance is an important variable when utilizing ModSecurity and Mischel covers the fundamentals. He recommends using httperf and establishing a baseline without rules loaded. Response time, memory usage, and CPU usage are key. Once you've gathered necessary metrics, the same testing pattern with rules loaded will give you all the data you need to optimize. Mischel offers optimization concepts including memory consumption, bypassing static content inspection (think image files, JavaScript, and binary downloads), and using the @pm and @pmFromFile phrase matching operators (new in ModSecurity 2.5) to significantly speed up tasks normally left to regex matching (think 200 times faster).My criticisms of this book are editorial in nature; there is one truly egregious editing flaw and another odd decision.First, the page heading for the entirety of Chapter 5 (Virtual Patching) reads as Chapter 9. That's an error that a high school newspaper editor would catch and is simply unforgivable.Additionally, where Mischel discusses writing rules at great length in Chapter 2, I would have chosen to immediately follow with the REMO (Rule Editor for ModSecurity) content as Chapter 3 rather than sticking it in Chapter 8.Magnus Mischel's ModSecurity 2.5 is a worthy read and a recommended purchase, and earns 3.5 stars out of 5 (very good).As the Web Application Security Consortium releases WASC Threat Classification v2.0, there is much to consider in the way of web application threats; ModSecurity 2.5 will certainly contribute to your protection arsenal. ModSecurity 2.5
Amazon Verified review Amazon
ഹൈപ്നോ🐸ടോഡ്‌ Jul 16, 2019
Full star icon Full star icon Full star icon Empty star icon Empty star icon 3
Book is 10 years old. Most of the details apply. But it recommended to get book which is based on new modsecurity. Author does a good job explaining . But what i have fond is just reading through modsecuity documentation from spider should do the job... This can be read after to see what evolved ...
Amazon Verified review Amazon
Get free access to Packt library with over 7500+ books and video courses for 7 days!
Start Free Trial

FAQs

How do I buy and download an eBook? Chevron down icon Chevron up icon

Where there is an eBook version of a title available, you can buy it from the book details for that title. Add either the standalone eBook or the eBook and print book bundle to your shopping cart. Your eBook will show in your cart as a product on its own. After completing checkout and payment in the normal way, you will receive your receipt on the screen containing a link to a personalised PDF download file. This link will remain active for 30 days. You can download backup copies of the file by logging in to your account at any time.

If you already have Adobe reader installed, then clicking on the link will download and open the PDF file directly. If you don't, then save the PDF file on your machine and download the Reader to view it.

Please Note: Packt eBooks are non-returnable and non-refundable.

Packt eBook and Licensing When you buy an eBook from Packt Publishing, completing your purchase means you accept the terms of our licence agreement. Please read the full text of the agreement. In it we have tried to balance the need for the ebook to be usable for you the reader with our needs to protect the rights of us as Publishers and of our authors. In summary, the agreement says:

  • You may make copies of your eBook for your own use onto any machine
  • You may not pass copies of the eBook on to anyone else
How can I make a purchase on your website? Chevron down icon Chevron up icon

If you want to purchase a video course, eBook or Bundle (Print+eBook) please follow below steps:

  1. Register on our website using your email address and the password.
  2. Search for the title by name or ISBN using the search option.
  3. Select the title you want to purchase.
  4. Choose the format you wish to purchase the title in; if you order the Print Book, you get a free eBook copy of the same title. 
  5. Proceed with the checkout process (payment to be made using Credit Card, Debit Cart, or PayPal)
Where can I access support around an eBook? Chevron down icon Chevron up icon
  • If you experience a problem with using or installing Adobe Reader, the contact Adobe directly.
  • To view the errata for the book, see www.packtpub.com/support and view the pages for the title you have.
  • To view your account details or to download a new copy of the book go to www.packtpub.com/account
  • To contact us directly if a problem is not resolved, use www.packtpub.com/contact-us
What eBook formats do Packt support? Chevron down icon Chevron up icon

Our eBooks are currently available in a variety of formats such as PDF and ePubs. In the future, this may well change with trends and development in technology, but please note that our PDFs are not Adobe eBook Reader format, which has greater restrictions on security.

You will need to use Adobe Reader v9 or later in order to read Packt's PDF eBooks.

What are the benefits of eBooks? Chevron down icon Chevron up icon
  • You can get the information you need immediately
  • You can easily take them with you on a laptop
  • You can download them an unlimited number of times
  • You can print them out
  • They are copy-paste enabled
  • They are searchable
  • There is no password protection
  • They are lower price than print
  • They save resources and space
What is an eBook? Chevron down icon Chevron up icon

Packt eBooks are a complete electronic version of the print edition, available in PDF and ePub formats. Every piece of content down to the page numbering is the same. Because we save the costs of printing and shipping the book to you, we are able to offer eBooks at a lower cost than print editions.

When you have purchased an eBook, simply login to your account and click on the link in Your Download Area. We recommend you saving the file to your hard drive before opening it.

For optimal viewing of our eBooks, we recommend you download and install the free Adobe Reader version 9.