ADMIN

Nuts and bolts
ModSecurity
Figure 1: Once ModSecurity has been enabled, it will log suspicious activity at the detail level specified in SecAuditLogParts – in this case, an SQL injection attack.
The third instruction defines the auditlog
storage location relative to the
Apache installation path. Finally, the
SecAuditLogParts instruction defines
the information that ModSecurity logs
in the auditlog (Table 2). In this case,
this is the header and the content of
the request, along with the ModSecurity
reaction. The results are shown in
Figure 1.
After this preparation, you can add
the most important directive to your
configuration: SecRule. This defines
a filter rule and optionally an action
that the module will perform if it
discovers a match for the rule. If you
don’t define an action, the tool will
run the standard command defined in
the SecDefaultAction directive. Rules
always follow this pattern:
SecRule Variable Operator [Action]
The number of variables is huge, and
they cover every single element of the
client request (both for POST and for
GET), as well as the most important
server environment details [6]. Additionally,
you can use regular expressions.
For example, to investigate an
HTTP request to find out whether the
client requests the /etc/passwd string
in a GET method, you would use this
rule:
SecRule REQUEST_HEADERS: User‐Agent "nikto"
This example tells the web server to
refuse requests from the Nikto security
scanner [7]. If you want Mod-
Security to run a specific action for
a rule, you can overwrite the default
action:
SecRule REQUEST_HEADERS:User‐Agent "nikto" U
"phase:2,pass,msg:'Nikto‐Scan logged'"
This rule tells the module to write
a Nikto scan logged message to the
logfile when it detects the Nikto user
agent in a client request in phase 2.
The rule then overwrites the drop
default action, which is defined by
SecDefaultAction with the pass action.
This allows the client request
to pass. To test ModSecurity, Listing
1 gives you an overview of the basic
configuration discussed thus far.
Practice Session
After restarting Apache, a request
like http://www.example.com/index.
html?file=/etc/passwd would trigger
the sample rule in line 8. Then the
action defined in line 9 would block
the request. The client sees an HTTP
403 Forbidden error. At the same time,
lines 3 through 7 tell ModSecurity to
log the transaction in the auditlog and
send a detailed overview of the way
the client request was processed to
the debuglog. This means that your
Apache error_log file will contain a
note to the effect that a client request
was effectively blocked, as shown in
Listing 2. Once ModSecurity is working
correctly, you can start adding
rules and modifying them for the web
applications you want to protect.
The Art of Detecting
Attacks
To provide effective protection against
a huge assortment of attacks, system
administrators need to set up a robust
ruleset for ModSecurity. To formulate
rules that protect you against SQL
injection, cross-site scripting, or local
and remote file inclusion attacks, for
example, you need in-depth knowledge
of how attacks on web servers
work.
Of course, not every administrator
has this knowledge or the time to
re-invent the wheel. To address this,
the Open Web Application Security
Project (OWASP) offers a predefined
ruleset for ModSecurity [8] that relies
on anomaly detection to protect
web servers against a number of
SecRule REQUEST_URI "/etc/passwd"
If the request matches the rule, Mod-
Security runs the default deny action.
To filter by browser type, you would
do this:
Listing 1: Basic Configuration for ModSecurity
01 SecRuleEngine On
02 SecAuditEngine On
03 SecAuditLogType Serial
04 SecAuditLog logs/audit.log
05 SecAuditLogParts ABCFHZ
06 SecDebugLog logs/debug.log
07 SecDebugLogLevel 5
08 SecRule REQUEST_URI "/etc/passwd"
09 SecDefaultAction phase:2,log,auditlog,deny,status:403
Table 2: SecAuditLogParts Arguments
Abbreviation
A
B
C
D
E
F
G
H
J
K
Z
Description
Header for the entry (mandatory)
Request header
Request content; only available if content exists and ModSecurity is configured
to store it
Reserved
Temporary response content; only available if ModSecurity is configured for this
Final response header after possible manipulation by ModSecurity; Apache itself
writes the Date and Server headers
Reserved
Auditlog trailer equivalent to C, except where the request contains form data; in
this case, the software constructs a suitable request that excludes file content to
simplify matches
Reserved
Line by line list of all matching rules in the order of their application
End of entry (mandatory)
88 Admin 01 www.admin-magazine.com