Checking mod_security settings
  Checking for mod_security installation: installed        [OK]
  mod_security set to: enabled                             [OK]
  Server Signature set to: Apache                          [LOW]
  SecUploadDir set to: /var/asl/data/suspicious            [OK]
  SecUploadKeepFiles set to: on                            [OK]
  Logfile set to: audit_log                                [OK]
  Logging set to: Concurrent                               [OK]
  Audit Logging to: /var/asl/data/audit                    [OK]
  Logging elements set to: ABIFHZ                          [OK]
  SecRequestBodyInMemoryLimit set to: 131072               [OK]
  SecResponseBodyLimit set to: 2621440                     [OK]
  Enable debug log: yes                                    [OK]
  SecDataDir set to: /var/asl/data/msa                     [FAILED]
  SecTmpDir set to: /tmp                                   [OK]

 Checking rule class settings
    RBL Checks: on                                         [OK]
    Upload Scanner ruleset: on                             [OK]
    Anti-Malware ruleset: on                               [OK]
    Generic Attack ruleset: on                             [OK]
    Malicious Useragents ruleset: on                       [OK]
    Anti-Spam ruleset: on                                  [OK]
    Apache2 Generic ruleset: on                            [OK]
    Rootkit ruleset: on                                    [OK]
    Recon ruleset: on                                      [OK]
    Just In Time Patches: on                               [OK]
    Whitelist: off                                         [OK]

# ---------------------------------------------------------------
# Core ModSecurity Rule Set ver.2.0.3
# Copyright (C) 2006-2009 Breach Security Inc. All rights reserved.
#
# The ModSecuirty Core Rule Set is distributed under GPL version 2
# Please see the enclosed LICENCE file for full details.
# ---------------------------------------------------------------


# The directives within this file can be included within
# Virtual Host containers.
#
# Configuration contained in this file should be customized
# for your specific requirements before deployment.
#
# Next to each rule there is a description of what it does. Each
# location where customization is needed is marked with "TODO". It
# is recommended that you:
#
#  1) Keep a copy of the original file. This will allow you to use
#     the "diff" command to quickly see the changes. It will also
#     make upgrades to future rule sets easier.
#
#  2) Document your changes thoroughly.
#
# You are advised to start with ModSecurity in detection mode only.
# Switch to protection when you are comfortable with your rule set.
# For maximum protection monitor your logs on daily basis (or
# better).
#

# TODO You may want to provide an error friendly message to your
#      users when you start rejecting requests. You can do this using
#      the Apache ErrorDocument directive. You should also add
#      mod_unique_id to your configuration and display the unique
#      request ID on the error page. This would allow your users to
#      report the request ID back to you so that you can investigate
#      the false positive (if that's what it is). A nice error page
#      usually reduces the impact of false positives on the users.
#
#      The drawback of this user friendly approach is that it is
#      easier for the attackers to figure out there is an web
#      application firewall protecting the application.
#
#      ErrorDocument 403 /path/to/error_document.php
#
#      For more information see
#      http://httpd.apache.org/docs-2.0/custom-error.html


## -- Configuration ----------------------------------------------------------

# Turn ModSecurity on ("On"), set to monitoring only
# ("DetectionOnly") or turn off ("Off").
#
SecRuleEngine On

# Define which part of the HTTP transaction to inspect.
#
# Inspecting request body (SecRequestBodyAccess) should probably be always set
# to "on". Only very high volume sites that never use POST requests might want
# to set it to "off" to optimize performance.
#
# Inspecting response body is useful for monitoring for information leaks,
# or for signs of intrusion. However, it does require all responses to be
# buffered in memory. For most sites this should not be a problem, but special
# care must be taken to avoid buffering file downloads (through
# MIME type selection, as shown below).
#
# TODO If you decide to enable output filtering make sure to
#      review the list of scanned MIME types. If pages of the types specified
#      for outbound inspection are smaller than 512K in you application
#      (which is usually the case) you may reduce the SecResponseBodyLimit
#      to protect from potential denial of service attacks.
#
SecRequestBodyAccess On
SecResponseBodyAccess On
SecResponseBodyMimeType (null) text/html text/plain text/xml
SecResponseBodyLimit 2621440

# The following directive will not block large response bodies, but rather will
# only inspect data up to the size SecResponseBodyLimit setting.
SecResponseBodyLimit 2621440

# Initiate XML Processor in case of xml content-type
#
# TODO Uncomment this rule if you wish to parse
#      text/xml requests using the XML parser.  Note
#      that this may cause considerable overhead in processing
#      text/xml requests.
#SecRule REQUEST_HEADERS:Content-Type "text/xml" \
#"phase:1,pass,nolog,ctl:requestBodyProcessor=XML"


# What to do when an error is encountered.
#
# The default is to log the error and let the request go through.
# This is a reasonable setting to start with because you do not
# want to reject legitimate requests with an untuned rule set.
#
# The following line's settings will be inherited by rules that
# either do not specify an action at all, or if they use the
# "block" action. This will also allow the rules to use
# Anomaly Scoring (must use the
# modsecurity_crs_49_anomaly_scoring.conf file).
#
SecDefaultAction "phase:2,pass"

# If, after monitoring the performance of the rule set after a
# sufficient period, you determine the rules never (or rarely
# trigger on legitimate requests) you can change to something
# else, such as "log,deny,status:403". You can also leave the
# default setting here as is, but use per rule action configuration
# to only configure some rules to reject requests, leaving most
# of them to work in detection mode.
#
#SecDefaultAction "phase:2,deny"

## -- File uploads configuration -----------------------------------------------
# Temporary file storage path.
#
# TODO Change the temporary folder setting to a path where only
#      the web server has access.
#
SecUploadDir /var/asl/data/suspicious

# Whether or not to keep the stored files.
#
# In most cases you don't want to keep the uploaded files (especially
# when there is a lot of them). It may be useful to change the setting
# to "RelevantOnly", in which case the files uploaded in suspicious
# requests will be stored.
#
SecUploadKeepFiles on

# Inspect uploaded files.
#
# TODO If there is a danger of attack through uploaded files then it
#      is possible to configure an external script to inspect each file
#      before it is seen by the application. An example script is
#      included with ModSecurity (/util/modsec-clamscan.pl).
#
#      Inspecting uploaded files is especially important in a hosting, 
#      community or blogging environments where uploading files is permitted.
#
# NOTE the t:none action is required in order not to process the files names
#      passed to the script based on previously defined actions in a
#      SecDefaultAction directive.
#
# SecRule FILES_TMPNAMES "@inspectFile /opt/apache/bin/inspect_script.pl" \
#       "t:none"

## -- Logging ----------------------------------------------------------------

# Whether to log requests to the ModSecurity audit log.
#
# By default, only requests that trigger a ModSecurity events (as detected
# by) or a serer error are logged ("RelevantOnly"). This is a reasonable
# setting. Full logging can be set by using # "on". If the system is used
# for protection only and no logging is desired (not reccomended) logging can
# be turned of using "off"
#
# NOTE It is also possible to configure forensic logging on the
#      per request basis using the "auditlog" and "noauditlog" rule
#      actions.
#
# TODO The default rule set logs requests that generate a 404 "file not found"
#      response. These events are interesting, but may log a lot of information.
#      you may consider removing it by setting SecAuditLogRelevantStatus
#      to "^(?:5|4\d[^4])".
#
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^(?:5|4(?!04))"

# Log files structure
#
# You can select to log all events to a single log file (set SecAuditLogType to
# "Serial") or to log each request to a separate file (set it to "Concurrent").
# The former is usually easier to use, but if full logging is required or if
# the protected system supports a large transaction volume the later may
# be a better option.
#
# TODO Set the SecAuditLog (for "Serial" logging) or SecAuditLogStorageDir (for
#      "Concurrent" logging).
#
# TODO If you change from "Serial" to "Concurrent" uncomment the
#      SecAuditLogStorageDir directive and make sure the direcory specified
#      exists and has write permissions for the Apache user.

SecAuditLogType Concurrent
SecAuditLog logs/audit_log
# SecAuditLogStorageDir logs/modsec_audit

# Select what portions of the request to log
#
# Modify the string by adding any of the letter below to it:
# A - audit log header (mandatory)
# B - request headers
# C - request body (present only if the request body exists and ModSecurity is
#     configured to intercept it)
# E - intermediary response body (present only if ModSecurity is configured to
#     intercept response bodies, and if the audit log engine is configured to
#     record it). Intermediary response body is the same as the actual response
#     body unless ModSecurity intercepts the intermediary response body, in
#     which case the actual response body will contain the error message
#     (either the Apache default error message, or the ErrorDocument page).
# F - final response headers (excluding the Date and Server headers, which are
#     always added by Apache in the late stage of content delivery).
# H - audit log trailer
# I - This part is a replacement for part C. It will log the same data as C in
#     all cases except when multipart/form-data encoding in used. In this case
#     it will log a fake application/x-www-form-urlencoded body that contains
#     the information about parameters but not about the files. This is handy
#     if you don't want to have (often large) files stored in your audit logs.
# Z - final boundary, signifies the end of the entry (mandatory)

SecAuditLogParts ABIFHZ

# Create a separate log to monitor performance.
#
# TODO Performance monitoring only works with Apache 2.x. You need
#      to add mod_unique_id and mod_logio to your configuration. Then
#      uncomment the following two lines.
#
# LogFormat "%V %h %t %{UNIQUE_ID}e \"%r\" %>s %X | %I %O | %<{mod_security-time1}n %<{mod_security-time2}n %<{mod_security-time3}n %D" mperformance
# CustomLog logs/modsec_performance.log mperformance

# Custom application access log.
#
# TODO You should consider creating a custom access log. It could contain
#      the performance metrics from above, but should also record the
#      session ID for every request. That would make it possible to
#      list all requests performed as part of a session.
#
#      One custom log should be used per application but if you want
#      multiple applications to share one log file make sure each
#      line includes a unique application ID (unless the hostname is
#      sufficient for differentiation).

## -- Tuning and debugging

# This section include tuning and debugging directives that usually require no
# modifications unless

 
# Selects the cookie format that will be used in the current configuration
# context.
#
# Possible values are:
# 0 - use version 0 (Netscape) cookies. This is what most applications use.
#     It is the default value.
# 1 - use version 1 cookies.

SecCookieFormat 0

# Maximum size of the request body to keep in memory
#
# A higher value requires more server memory while a lower number would slow
# the server due to additional disk access. By default the limit is 128 KB:
SecRequestBodyInMemoryLimit 131072


# Whether to send ModSecurity messages to a separate debug log.
#
# Debug messages are very useful for, well, debugging. The default
# setting here copies (they always appear in the Apache error log)
# only the most important messages (errors and warnings).
#
# NOTE Debug logging is generally very slow. You should never
#      use values greater than "3" in production.
#
SecDebugLog             logs/modsec_debug.log
SecDebugLogLevel        3

# Configures the directory where temporary files will be created.
SecTmpDir /tmp
SecAuditLogStorageDir /var/asl/data/audit
SecResponseBodyLimitAction ProcessPartial

# Path where persistent data (e.g. IP address data, session data, etc) is to
# be stored. Must be writable by the web server user.
#
# TODO It is advisable to create a directory structure for ModSecurity such as
#      /var/log/msa and create sub directories for SecDataDir, SecTmpDir,
#      SecUploadDir, SecAuditLog and SecAuditLogStorageDir
#      underneath it and set the permission for read and write only by the
#      Apache user.

SecDataDir /var/asl/data/msa