Write For Us

Submit Tips

Subscribe to Print Edition

Search

HOME

REVIEWS

HOW-TOS

CODING

INTERVIEWS

FEATURES

OVERVIEW

BLOGS

SERIES

IT ADMIN

Securing Apache, Part 10: mod_security

By Arpit Bajpai on August 1, 2011 in How-Tos, Security, Sysadmins 2 Comments

Search for:

Search

Get Connected RSS Feed Twitter

Right from Part 1 of this series, weve covered the major types of attacks being done on Web applications and their security solutions. In this article, I will reveal the tremendous capabilities of the Apache mod_security module, covering just a small part of what it can do.
From the development perspective, implementing security against the many attacks on Web apps doesnt just require extra coding and stronger validation, but often also results in complex and messy code, which may sometimes cause yet another security loophole. Security is often compared to a football game, where success requires the defense to quickly adapt, outrun, and outplay the attackers. Such a dynamic defense cannot properly survive in complex and messy code. Here, Web application firewalls come to the rescue and what else is better than m o d _ s e c u r i t y . It is designed as an Apache module that adds intrusion-detection and prevention features to the Web server. In principle, its similar to an IDS that analyses network traffic, but it works at the HTTP level, and really well, at that. This allows you to do things that are difficult in a classic IDS. This difference will become clearer when we examine several examples. The attack prevention feature stands between the client and server; if it finds a malicious payload, it can reject the request, performing any one of a number of built-in actions. Some of the features of m o d _ s e c u r i t yare audit logging, access to any part of the request (including the body) and the response, a flexible regular expression-based rule engine, fileupload interception, real-time validation and also buffer-overflow protection.

How mod_security works

The modules functionality is divided into four main areas: 1. Parsing: Security-conscientious parsers extract bits of each request and/or response and store them for use in the rules. 2. Buffering: In a typical installation, both request and response bodies will be buffered so that the module usually sees complete requests (before they are passed to the application for processing), and complete responses (before they are sent to clients). Buffering is important, because it is the only way to provide reliable blocking.

3. Logging: Allows you to record complete HTTP traffic, logging all response/request headers and bodies. 4. Rule engine: Works on the data from the other components, to assess the transaction and take action, as necessary.

LINUX For You on

Follow

+2,513

Deployment architectures
m o d _ s e c u r i t ycan be deployed in two modes:

Embedded mode: Just add m o d _ s e c u r i t yas a module into your Apache Web server. However, in this mode, it is not able to inspect the content of server headers. Network gateway: In this mode (recommended since all the Web traffic goes through the proxy),
m o d _ s e c u r i t yis installed as a reverse proxy (see Figure 1). If you are using this mode, ensure

Find us on Facebook

Open Source For You

Like 254,807 people like Open Source For You.

you also add m o d _ p r o x yand m o d _ p r o x y _ h t t pin Apache. This gives a single point to monitor, higher speed, high anonymity of the internal network, and m o d _ s e c u r i t y can inspect the server header of the backend database.

F acebook social plugin

Popular

Comments

Tag cloud

August 13, 2013 42 Comments Diksha P Gupta

India has immense under-utilised talent in the cloud security space

May 6, 2013 6 Comments Priyanka Sarkar

PHP Development: A Smart Career Move

Figure 1: 'mod_security' as reverse proxy
June 20, 2013 3 Comments sophie-samuel

New and amazing features of Linux

June 20, 2013 3 Comments Priyanka Sarkar

Installation
Basically, m o d _ s e c u r i t yworks on configuration and rules. The configuration instructs it how to process the data it sees; the rules decide what to do with the processed data. The configuration directives can be directly added to h t t p d . c o n f , but to avoid cluttering that, include a separate m o d s e c u r i t y . c o n fwith this line in h t t p d . c o n f :
I n c l u d ec o n f / m o d s e c u r i t y . c o n f

What it Takes to be an Open Source Expert

May 6, 2013 1 Comments Deepti Sharma

A Simple guide to building your own Linux Kernel

Installation is not straightforward, and also depends on the OS and Apache version you are using. But the slight trouble is negligible in comparison to the services m o d _ s e c u r i t yoffers. For detailed installation steps, refer to the documentation on modsecurity.org. A Windows version is also available, which has other customised versions of Apache and Apache modules.

Configuration
The basic m o d s e c u r i t y . c o n flooks like the following code:
< I f M o d u l em o d _ s e c u r i t y . c > #T u r nt h ef i l t e r i n ge n g i n eO no rO f f S e c F i l t e r E n g i n eO n #T h ea u d i te n g i n ew o r k si n d e p e n d e n t l ya n dc a nb et u r n e d #O no rO f fo nap e r s e r v e ro rp e r d i r e c t o r yb a s i s S e c A u d i t E n g i n eR e l e v a n t O n l y #M a k es u r et h a tU R Le n c o d i n gi sv a l i d S e c F i l t e r C h e c k U R L E n c o d i n gO n #U n i c o d ee n c o d i n gc h e c k S e c F i l t e r C h e c k U n i c o d e E n c o d i n gO n #O n l ya l l o wb y t e sf r o mt h i sr a n g e S e c F i l t e r F o r c e B y t e R a n g e12 5 5 #C o o k i ef o r m a tc h e c k s . S e c F i l t e r C h e c k C o o k i e F o r m a tO n #T h en a m eo ft h ea u d i tl o gf i l e S e c A u d i t L o gl o g s / a u d i t _ l o g #S h o u l dm o d _ s e c u r i t yi n s p e c tP O S Tp a y l o a d s S e c F i l t e r S c a n P O S TO n #D e f a u l ta c t i o ns e t S e c F i l t e r D e f a u l t A c t i o n" d e n y , l o g , s t a t u s : 5 0 0 " < / I f M o d u l e >

Now, lets look at some basic configuration directives:

S e c F i l t e r E n g i n e : When set to On (that is, S e c F i l t e r E n g i n eO n ), it starts monitoring

requests. It is O f f(disabled) by default.

S e c F i l t e r S c a n P O S T : When O n , enables scanning the request body/POST payload. S e c F i l t e r S c a n O u t p u t : When O n , enables scanning the response body also.

Similarly, to check URL encoding, you can use S e c F i l t e r C h e c k U R L E n c o d i n g ; to control request body buffering, use S e c R e q u e s t B o d y A c c e s s ; to control what happens once the response body limit is reached, use S e c R e s p o n s e B o d y L i m i t A c t i o n ; and to specify the response body buffering limit, use S e c R e s p o n s e B o d y L i m i t . The full list of configuration directives, their usage and syntax is at available on modsecurity.org.

Rules the basics

The m o d _ s e c u r i t yrule engine is where gathered data is checked for any malicious or particular content. Rules are directives in the configuration file that decide what to do with the data parsed by the configuration directives. The rule language is a vast topic; well only discuss basic rulewriting syntax, and rule directives to secure Web applications from all the attacks weve discussed so far. The main directive used to create rules is S e c R u l e , whose syntax is as follows:
S e c R u l eV A R I A B L E SO P E R A T O R[A C T I O N S ]

V A R I A B L E S : Specify which places to check in an HTTP transaction. m o d _ s e c u r i t y

preprocesses raw transaction data, making it easy for rules to focus on the logic of detection. Currently, variables are divided into request, server, and response variables, parsing flags and time variables. You can use multiple variables in a single rule with the |operator.
O P E R A T O R S : Specify a regular expression, pattern or keyword to be checked in the variable(s).

There are four types of operators: string-matching, numerical, validation and miscellaneous operators. Operators always begin with a @character, and are always followed by a space.
A C T I O N S : Specify what to do if the rule evaluates to true step on to another rule, display

an error message, or any other task. Actions are divided into seven categories: disruptive, flow, metadata, variable, logging, special and miscellaneous actions. Here is a simple example of a rule:
S e c R u l eA R G S | R E Q U E S T _ H E A D E R S" @ r x< s c r i p t "i d : 1 0 1 , m s g :' X S S A t t a c k ' ,s e v e r i t y : E R R O R , d e n y , s t a t u s : 4 0 4

Here, A R G Sand R E Q U E S T _ H E A D E R Sare variables (request parameters and request headers, respectively); @ r xis the operator used to match a pattern in the variables (here, this pattern is < s c r i p t ) ;i d ,m s g ,s e v e r i t y ,d e n yand s t a t u sare all actions to be performed if the pattern is matched. This rule is used to avoid XSS attacks by checking for a < s c r i p tpattern in the request parameters and header, and generates an ' X S SA t t a c k 'message. The i d : 1 0 1is given to the rule; it will deny any matching request with a 4 0 4status response. Lets look at another example, for more clarity:
S e c R u l eA R G S : u s e r n a m e" @ s t r e qa d m i n "c h a i n , d e n y S e c R u l eR E M O T E _ A D D R" ! @ s t r e q1 9 2 . 1 6 8 . 1 . 1 "

This is an example of chaining two rules, and the transfer of control to another rule if the first rule holds true. The first rule checks for the string admin in the requests username parameter. If found, the second rule will be activated, which denies all such requests that are not from the 1 9 2 . 1 6 8 . 1 . 1IP address. Thus, chaining rules help to create complex rules. Now, writing filtering rules for each attack will be very cumbersome, and also prone to human error. Here, m o d _ s e c u r i t yprovides users with another directive, S e c F i l t e r . This looks for a keyword in the request. It will be applied to the first line of the request (the one that looks like G E T
/ i n d e x . p h p ? p a r a m e t e r = v a l u eH T T P / 1 . 0 ). In case of POST requests, the body of the request

will be searched too (provided request body buffering is enabled). All pattern matches are caseinsensitive, by default. The syntax for S e c F i l t e ris S e c F i l t e rK E Y W O R D .

Rules against major attacks

Lets look at some rules to prevent major attacks on Web applications.

SQL injection
Suppose you have an application that is vulnerable to SQL-injection attacks. An attacker could try to delete all records from a MySQL table, like this:
h t t p : / / w w w . e x a m p l e . c o m / l o g i n . p h p ? u s e r = a r p i t ' ; D E L E T E % 2 0 F R O M % 2 0 u s e r s -

This can be prevented with the following directive:

S e c F i l t e r" d e l e t e [ [ : s p a c e : ] ] + f r o m "

Whenever such a request is caught by the filter, something similar to the following code is logged to a u d i t _ l o g :
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = R e q u e s t :1 9 2 . 1 6 8 . 0 . 2 0 7--[ 0 4 / J u l / 2 0 0 6 : 2 3 : 4 3 : 0 0+ 1 2 0 0 ]" G E T/ l o g i n . p h p ? u s e r = t o m ' ; D E L E T E % 2 0 F R O M % 2 0 u s e r s -H T T P / 1 . 1 "5 0 01 2 1 5 H a n d l e r :( n u l l ) G E T/ l o g i n . p h p ? u s e r = a r p i t ' ; D E L E T E % 2 0 F R O M % 2 0 u s e r s -H T T P / 1 . 1 H o s t :1 9 2 . 1 6 8 . 0 . 1 0 0 U s e r A g e n t :M o z i l l a / 5 . 0( W i n d o w s ;U ;W i n d o w sN T5 . 1 ;e n U S ;r v : 1 . 8 . 0 . 4 )G e c k o / 2 0 0 6 0 5 0 8F i r e f o x / 1 . 5 . 0 . 4 A c c e p t :t e x t / x m l , a p p l i c a t i o n / x m l , a p p l i c a t i o n / x h t m l + x m l , t e x t / h t m l ; q = 0 . 9 , t e x t / p l a i n ; q = 0 . 8 , i m a g e / p n g , * / * ; q = 0 . 5 A c c e p t L a n g u a g e :e n u s , e n ; q = 0 . 5 A c c e p t E n c o d i n g :g z i p , d e f l a t e A c c e p t C h a r s e t :I S O 8 8 5 9 1 , u t f 8 ; q = 0 . 7 , * ; q = 0 . 7 K e e p A l i v e :3 0 0 C o n n e c t i o n :k e e p a l i v e m o d _ s e c u r i t y m e s s a g e :A c c e s sd e n i e dw i t hc o d e5 0 0 .P a t t e r nm a t c h" d e l e t e [ [ : s p a c e : ] ] + f r o m "a tT H E _ R E Q U E S T m o d _ s e c u r i t y a c t i o n :5 0 0 H T T P / 1 . 15 0 0I n t e r n a lS e r v e rE r r o r L a s t M o d i f i e d :F r i ,2 1O c t2 0 0 51 4 : 3 0 : 1 8G M T E T a g :" 8 2 3 8 4 b f 8 3 3 a 5 2 8 0 " A c c e p t R a n g e s :b y t e s C o n t e n t L e n g t h :1 2 1 5 C o n n e c t i o n :c l o s e C o n t e n t T y p e :t e x t / h t m l

In response to the attack, S e c F i l t e r D e f a u l t A c t i o nis applied (the request is denied, logged, and the attacker gets a 5 0 0error). If you want a different action to take place (like, redirect the request to a HTML page that can provide customised warning content), you can specify this in the rule, as follows:
S e c F i l t e r" d e l e t e [ [ : s p a c e : ] ] + f r o m "l o g , r e d i r e c t : h t t p : / / e x a m p l e . c o m / i n v a l i d _ r e q u e s t . h t m l

To prevent more SQL injection attacks, we can add a few other directives like:
S e c F i l t e r" i n s e r t [ [ : s p a c e : ] ] + i n t o " S e c F i l t e r" s e l e c t . + f r o m " S e c F i l t e r" d r o p [ [ : s p a c e : ] ] t a b l e " S e c F i l t e rc r e a t e [ [ : : s p a c e : ] ] + t a b l e S e c F i l t e ru p d a t e . + s e t . + = S e c F i l t e ru n i o n . + s e l e c t S e c F i l t e ro r . + 1 [ [ : s p a c e : ] ] * =[ [ : s p a c e : ] ] 1 S e c F i l t e r' . + S e c F i l t e rx p _ e n u m d s n S e c F i l t e rx p _ c m d s h e l l S e c F i l t e rx p _ r e g r e a d S e c F i l t e rx p _ r e g w r i t e S e c F i l t e rx p _ r e g d e l e t e k e y

The last five are particularly used for MS SQL server-specific injection attacks. The only problem with S e c F i l t e ris that it scans the whole request instead of particular fields. Here, S e c F i l t e r S e l e c t i v eis useful; it allows you to choose exactly what to search. The syntax is:
S e c F i l t e r S e l e c t i v eL O C A T I O NK E Y W O R D[ A C T I O N S ]

Here, L O C A T I O Ndecides which area of the request to be filtered. Hence, for SQL injection, you can also use:
S e c F i l t e r S e l e c t i v eS C R I P T _ F I L E N A M E" l o g i n . p h p "c h a i n S e c F i l t e r S e l e c t i v eA R G _ u s e r" ! ^ [ a z A Z 0 9 \ . @ ! ] { 1 , 1 0 } $ "

The above code will validate the user parameter, and allow only the white-list of characters we have given. If for some reason you cannot take this approach, and must use a deny-what-is-bad method, then at least remove single quotes (' ), semicolons (; ), dashes, hyphens (), and parenthesis (( ) ).

XSS attacks
For XSS attacks, we can use the following directives:
S e c F i l t e r" < ( . | \ n ) + > " S e c F i l t e r" < [ [ : s p a c e : ] ] * s c r i p t " S e c F i l t e r" < s c r i p t " S e c F i l t e r" < . + > "

And also, some additional filters like:

S e c F i l t e r S e l e c t i v eT H E _ R E Q U E S T" < [ ^ > ] * m e t a * \ " ? [ ^ > ] * > " S e c F i l t e r S e l e c t i v eT H E _ R E Q U E S T" < [ ^ > ] * s t y l e * \ " ? [ ^ > ] * > " S e c F i l t e r S e l e c t i v eT H E _ R E Q U E S T" < [ ^ > ] * s c r i p t * \ " ? [ ^ > ] * > " S e c F i l t e r S e l e c t i v eT H E _ R E Q U E S T" < [ ^ > ] * i f r a m e * \ " ? [ ^ > ] * > " S e c F i l t e r S e l e c t i v eT H E _ R E Q U E S T" < [ ^ > ] * o b j e c t * \ " ? [ ^ > ] * > "

S e c F i l t e r S e l e c t i v eT H E _ R E Q U E S T" < [ ^ > ] * i m g * \ " ? [ ^ > ] * > " S e c F i l t e r S e l e c t i v eT H E _ R E Q U E S T" < [ ^ > ] * a p p l e t * \ " ? [ ^ > ] * > " S e c F i l t e r S e l e c t i v eT H E _ R E Q U E S T" < [ ^ > ] * f o r m * \ " ? [ ^ > ] * > "

Though these filters will detect a large number of XSS attacks, they are not foolproof. Due to the multitude of different scripting languages, it is possible for an attacker to create many different methods for implementing an XSS attack that would bypass these filters. Hence, here it is advised that you also keep on adding your own filters. To protect against an XSS attack done via PHP session cookies, you can use the following:
S e c F i l t e r S e l e c t i v eA R G _ P H P S E S S I D" ! ^ [ 0 9 a z ] * $ " S e c F i l t e r S e l e c t i v eC O O K I E _ P H P S E S S I D" ! ^ [ 0 9 a z ] * $ "

Command execution attacks

For command execution attacks, you can use the following directives:
S e c F i l t e r/ e t c / p a s s w o r d S e c F i l t e r/ b i n / l s

Here, the attacker may try to use a string like / b i n / . / s hto bypass the filter but m o d _ s e c u r i t yautomatically reduces / . /to /and / /to / , and also decodes URL-encoded characters. You can also use the white-list approach:
S e c F i l t e r S e l e c t i v eS C R I P T _ F I L E N A M E" d i r e c t o r y . p h p "c h a i n S e c F i l t e r S e l e c t i v eA R G _ d i r" ! ^ [ a z A Z / _ \ . 0 9 ] + $ "

This chained rule-set will only allow letters, numbers, underscore, dash, forward slash, and period in the d i rparameter. Filtering out command directory names is also a good option, and can be done as follows:
S e c F i l t e r S e l e c t i v eT H E _ R E Q U E S T" / ^ ( e t c | b i n | s b i n | t m p | v a r | o p t | d e v | k e r n e l ) $ / " S e c F i l t e r S e l e c t i v eA R G S" b i n / "

Session fixation
During session fixation, in one of its phases, the attacker needs to somehow inject the desired session ID into the victims browser. We can mitigate these issues by implementing the following:
#W e a k e rX S Sp r o t e c t i o n ,b u ta l l o w sc o m m o nH T M Lt a g s S e c F i l t e r" < [ [ : s p a c e : ] ] * s c r i p t " #P r e v e n tX S Sa t t a c k s( H T M L / J a v a s c r i p ti n j e c t i o n ) S e c F i l t e r" < . + > " #B l o c kp a s s i n gC o o k i e / S e s s i o nI D si nt h eU R L S e c F i l t e r S e l e c t i v eT H E _ R E Q U E S T" ( d o c u m e n t \ . c o o k i e | S e t C o o k i e | S e s s i o n I D = ) "

Directory traversal attacks

For path/directory traversal attacks, the following directives are mostly used:
S e c F i l t e r" \ . \ . / " S e c F i l t e r S e l e c t i v eS C R I P T _ F I L E N A M E" / s c r i p t s / f o o . c g i "c h a i n S e c F i l t e r S e l e c t i v eA R G _ h o m e" ! ^ [ a z A Z ] . { 1 5 , } \ . t x t "

The last two filters are chained, and will reject all parameters to the h o m eargument that is a filename of more than 15 alpha characters, and that doesnt have a . t x textension. Similarly, you can prevent predictable resource location attacks also, and protect against sensitive file misuse, with two recommended solutions. First, remove files that are not intended for public viewing from all Web server-accessible directories. After this, you can create security filters to identify if someone probes for these files:
S e c F i l t e r S e l e c t i v eR E Q U E S T _ U R I" ^ / ( s c r i p t s | c g i l o c a l | h t b i n | c g i b i n | c g i s | w i n c g i | c g i w i n | b i n ) / " S e c F i l t e r S e l e c t i v eR E Q U E S T _ U R I" . * \ . ( b a k | o l d | o r i g | b a c k u p | c ) $ "

These two filters will deny access to both unused, but commonly scanned for directories, and files with common backup extensions. Web pages that are dynamically created by the directory-indexing function will have a title that starts with Index of /. We can use this as a signature, and add the following directives to catch and deny access to this data:
S e c F i l t e r S c a n O u t p u tO n S e c F i l t e r S e l e c t i v eO U T P U T" \ < t i t l e \ > I n d e xo f/ "

Information leakage
Here, we are introduced to the OUTPUT filtering capabilities of mod_security, which you should enable by adding S e c F i l t e r S c a n O u t p u tO nin the configuration file. We can easily set up a

filter to watch for common database error messages being sent to the client, and then generate a generic 500 status code instead of the verbose message:
S e c F i l t e r S c a n O u t p u tO n S e c F i l t e r S e l e c t i v eO U T P U T" A nE r r o rH a sO c c u r r e d "s t a t u s : 5 0 0 S e c F i l t e r S e l e c t i v eO U T P U T" F a t a le r r o r : "

Output filtering can also be used to detect successful intrusions. These rules will monitor output, and detect typical keywords resulting from a command execution on the server.
S e c F i l t e r S e l e c t i v eO U T P U T" V o l u m eS e r i a lN u m b e r " S e c F i l t e r S e l e c t i v eO U T P U T" C o m m a n dc o m p l e t e d " S e c F i l t e r S e l e c t i v eO U T P U T" B a dc o m m a n do rf i l e n a m e " S e c F i l t e r S e l e c t i v eO U T P U T" f i l e ( s )c o p i e d " S e c F i l t e r S e l e c t i v eO U T P U T" I n d e xo f/ c g i b i n / " S e c F i l t e r S e l e c t i v eO U T P U T" . * u i d \ = \ ( "

Secure file uploads

m o d _ s e c u r i t yis capable of intercepting files uploaded through POST requests and multi-

part/form-data encoding through PUT requests. It will always upload files to a temporary directory. You can choose the directory using the S e c U p l o a d D i rdirective:
S e c U p l o a d D i r/ t m p

It is better to choose a private directory for file storage, somewhere that only the Web server user account is allowed access. Otherwise, other server users may be able to access files uploaded through the Web server. You can choose to execute an external script to verify a file before it is allowed to go through to the application. The S e c U p l o a d A p p r o v e S c r i p tdirective enables this, like the following example:
S e c U p l o a d A p p r o v e S c r i p t/ u s r / l o c a l / a p a c h e / b i n / u p l o a d _ v e r i f y . p l

RFI attacks
RFI attacks are generally easy to detect, with something like the following directive:

S e c R u l eA R G S @ r x( ? i ) ^ ( f | h t ) t p s ? : / / ( [ ^ / ] ) m s g : R e m o t eF i l eI n c l u s i o na t t a c k #T od e t e c ti n c l u s i o n sc o n t a i n i n gI Pa d d r e s s S e c R u l eA R G S" @ r x( h t | f ) t p s ? : / / ( [ 0 1 ] ? \ d \ d ? | 2 [ 0 4 ] \ d | 2 5 [ 0 5 ] ) \ . ( [ 0 1 ] ? \ d \ d ? | 2 [ 0 4 ] \ d | 2 5 [ 0 5 ] ) \ . ( [ 0 1 ] ? \ d \ d ? | 2 [ 0 4 ] \ d | 2 5 [ 0 5 ] ) \ . ( [ 0 1 ] ? \ d \ d ? | 2 [ 0 4 ] \ d # T od e t e c ti n c l u s i o n sc o n t a i n i n gP H Pf u n c t i o n i n c l u d e ( ) S e c R u l eA R G S" @ r x\ b i n c l u d e \ s * \ ( [ \ w | \ s ] * ( h t | f ) t p s ? : / / "" m s g : ' R e m o t eF i l eI n c l u s i o n ' " #T od e t e c ti n c l u s i o ne n d i n gw i t h ? S e c R u l eA R G S" @ r x( f t | h t t ) p s ? . * \ ? + $ "m s g : ' R e m o t eF i l eI n c l u s i o n '

Miscellaneous security features

You can also block IP addresses by the following command:
S e c F i l t e r S e l e c t i v e" R E M O T E _ A D D R "" ^ 1 9 2 . 1 6 8 . 1 . 1 $ "

If you have an input field URL in your comment form, and you want to scan the value of URL for the string c 9 9 , you do it as follows:
S e c F i l t e r S e l e c t i v e" A R G _ u r l "" c 9 9 "

The following configuration helps fight HTTP fingerprinting, and accepts only valid protocol versions:
S e c F i l t e r S e l e c t i v eS E R V E R _ P R O T O C O L! ^ H T T P / ( 0 \ . 9 | 1 \ . 0 | 1 \ . 1 ) $

The following configuration allows supported request methods only, and helps fight XST attacks:
S e c F i l t e r S e l e c t i v eR E Q U E S T _ M E T H O D! ^ ( G E T | H E A D | P O S T ) $

Often during the reconnaissance phase, attackers look for the Web server identity and version. Web servers typically send their identity with every HTTP response, in the Server header. Apache is particularly helpful here; it not only sends its name and full version, by default, but also allows server modules to append their versions. Here, you can confuse the attackers by using something like:
S e c S e r v e r S i g n a t u r e" M i c r o s o f t I I S / 5 . 0 "

PHP code cannot be injected directly, but it may be possible to have code recorded on disk to be executed later, using an LFI attack. The following rule will detect such an injection attempt, but will ignore XML documents, which use similar syntax:
S e c R u l eA R G S" @ r x< \ ? ( ? ! x m l ) "

Logging

There are three places where, depending on the configuration, you may find m o d _ s e c u r i t y logging information:
m o d _ s e c u r i t ydebug log: If enabled via the S e c F i l t e r D e b u g L e v e land S e c F i l t e r D e b u g L o gdirectives, it contains a large number of entries for every request

processed. Each log entry is associated with a log level, which is a number from 0 (no messages at all) to 4 (maximum logging). You normally keep the debug log level at 0, and increase it only when you are debugging your rule set. Apache error log: Some of the messages from the debug log will make it into the Apache error log (even if you set m o d _ s e c u r i t ydebug log level to 0). These are the messages that require an administrators attention, such as information about requests being rejected.
m o d _ s e c u r i t yaudit log: When audit logging is enabled (using the S e c A u d i t E n g i n eand S e c A u d i t L o gdirectives), m o d _ s e c u r i t ycan record each request (and its body, provided

request body buffering is enabled) and the corresponding response headers. Here is an example of an error message resulting from invalid content discovered in a cookie:
[ T u eJ u n2 61 7 : 4 4 : 3 62 0 1 1 ][ e r r o r ][ c l i e n t1 2 7 . 0 . 0 . 1 ] m o d _ s e c u r i t y :A c c e s sd e n i e dw i t hc o d e5 0 0 .P a t t e r nm a t c h" ! ( ^ $ | ^ [ a z A Z 0 9 ] + $ ) " a tC O O K I E S _ V A L U E S ( s e s s i o n i d )[ h o s t n a m e" 1 2 7 . 0 . 0 . 1 " ] [ u r i" / t e s t . p h p " ][ u n i q u e _ i d3 4 3 4 f v n i j 5 4 j k t y n v 4 5 f C 8 Q Q Q Q A B ]

The message indicates that the request was rejected (Access denied) with an HTTP 5 0 0 response because the content of the cookie sessionid contained content that matched the pattern ! ( ^ $ | ^ [ a z A Z 0 9 ] + $ ) . (The pattern allows a cookie to be empty, but if it is not, it must consist only of one or more letters and digits.) Note: I once again stress that neither LFY nor myself are responsible for the misuse of the information given here. Any attack techniques described here are meant to give you the knowledge that you need to protect your own infrastructure. Please use the tools and techniques sensibly. This article has just scratched the surface of m o d _ s e c u r i t y . For more details on rule writing and other important directives, please refer to ModSecurity Handbook by Ivan Ristic a must-read book for anyone interested in this topic. We will deal with other ways to secure Apache in the next article. Always remember: Know hacking, but no hacking.

Related Posts:
Secure Upload Methods in PHP Securing Apache, Part 11: Logs, et al. Puppet Data Centre Automation Solution, Part 2: User & Group Management Impress(.js) an Audience with Your Presentation Loading Library Files in C++
Tags: Apache, Apache HTTP Server, Apache module, apache web server, attack prevention, audit logging, buffer overflow protection, configuration files, dynamic defense, file upload, http, intrusion detection, LFY August 2011, malicious payload, messy code, mod_security, network traffic, regular expression, Securing Apache series, security loophole, security solutions, server attack, web applications, Web apps, Windows, WWW

Article written by:

Previous Post

Next Post

Storage Management using Openfiler, Part 1

Build Android Apps Using HTML with PhoneGap

AROUND THE WEB

ALSO ON LINUX FOR YOU

What's this?

Billionaires Dump Stocks, Prepare for Collapse Moneynews Protect Yourself in a Divorce: 9 Things You Must Do Citi Women & Co. Your #1 Fat Burning Hormone and How to Control It Early to Rise Avoid Alzheimer's Disease: Here's What May Cause It Newsmax Health

India has immense under-utilised talent in the cloud 42 comments Code Sport
1 comment

File Systems A Semester Project-II, Part-19 6 comments Linux Professionals in High Demand
10 comments

2 comments Leave a message...

Newest Community Devendra Jos hi
a month ago

Share

Daniel

Good Buddy.... Nice

Reply

Share

a year ago

Would you be so kind to update it with Mod_Security2 syntax?

Reply Share

C o m m e n t fe e d

Su b s cri b e vi a e m a i l

Reviews

How-Tos

Coding

Interviews

Features

Overview

Blogs

Search
Popular tags
Linux , ubuntu, Java, MySQL, Google, python, Fedora, Android, PHP, C, html, w eb applications , India, Microsoft, unix , Window s , Red Hat, Oracle, Security , Apache, xml, LFY April 2012, FOSS, GNOME, http, JavaScript, LFY June 2011, open source, RAM, operating systems

For You & Me Developers Sysadmins Open Gurus CXOs Columns

All published articles are released under Creative Commons Attribution-NonCommercial 3.0 Unported License, unless otherw ise noted. LINUX For You is pow ered by WordPress, w hich gladly sits on top of a CentOS-based LEMP stack.