Re: [mod-security-users] validating mod_security installation

[James B. M. <Jam...@hi...>]

Thank you for the suggestion. I changed the rule to:

SecRule REMOTE_ADDR "!^123\.456\.789\.123$"

Now the audit log contains lots of detail to review.

Looks like progress.
-James


-----Original Message-----
From: Peter BARABAS [mailto:pet...@gm...]
Sent: Wednesday, September 28, 2011 1:32 PM
To: James B. Muir
Cc: mod...@li...
Subject: Re: [mod-security-users] validating mod_security installation

Hello,


Just a tip: use IP addresses without zero padding. Your rule:

SecRule REMOTE_ADDR "!^123\.456\.789\.012$"


On Wed, Sep 28, 2011 at 19:19, James B. Muir <Jam...@hi...> wrote:
> Hi All,
>
>
>
> I've been trying for a few days to verify whether or not I've got
> mod_security installed properly by applying a single rule in a virtual host.
> I've been unable to convince myself that it is working. No doubt I am making
> some kind of stupid newbie configuration mistake. Can you help me out?
>
>
>
> I've got the recommended "base"  configuration copied from the mod security
> reference manual (see below) which includes:
>
>
>
> SecRuleEngine DetectionOnly
>
>
>
> The virtual host configuration is as follows:
>
>
>
> # Set Default Action to deny the request and report error "403 Forbidden"
>
> SecDefaultAction "phase:1,deny,log,auditlog,status:403"
>
>
>
> # Test Rule - pretend valid requestor IP address is 123.456.789.012
>
> SecRule REMOTE_ADDR "!^123\.456\.789\.012$"
>
>
>
> I include the base security configuration in the main body of httpd.conf,
> and I include virtual hosts configuration within the <VirtualHost>.
>
>
>
> When I issue a GET request to the server, the mod security Audit Log remains
> empty. I would have thought I'd see an error 403 produced.
>
>
>
> The Debug Log gives lots of detail which includes several instances of this
> disheartening message:
>
>
>
> This phase consists of 0 rule(s).
>
>
>
> Which leads me to believe that the REMOTE_ADDR rule is not being applied.
>
> What am I doing wrong?
>
> -James
>
>
>
>
>
> # security-base.conf - base mod_security directives.
>
> #
> ----------------------------------------------------------------------------
>
>
>
> # -- Rule engine initialization
> ----------------------------------------------
>
>
>
> # Enable ModSecurity, attaching it to every transaction. Use detection
>
> # only to start with, because that minimises the chances of
> post-installation
>
> # disruption.
>
> #
>
> SecRuleEngine DetectionOnly
>
>
>
>
>
> # -- Request body handling
> ---------------------------------------------------
>
>
>
> # Allow ModSecurity to access request bodies. If you don't, ModSecurity
>
> # won't be able to see any POST parameters, which opens a large security
>
> # hole for attackers to exploit.
>
> #
>
> SecRequestBodyAccess On
>
>
>
>
>
> # Enable XML request body parser.
>
> # Initiate XML Processor in case of xml content-type
>
> #
>
> SecRule REQUEST_HEADERS:Content-Type "text/xml" \
>
>      "phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=XML"
>
>
>
>
>
> # Maximum request body size we will accept for buffering. If you support
>
> # file uploads then the value given on the first line has to be as large
>
> # as the largest file you are willing to accept. The second value refers
>
> # to the size of data, with files excluded. You want to keep that value as
>
> # low as practical.
>
> #
>
> SecRequestBodyLimit 13107200
>
> SecRequestBodyNoFilesLimit 131072
>
>
>
> # Store up to 128 KB of request body data in memory. When the multipart
>
> # parser reachers this limit, it will start using your hard disk for
>
> # storage. That is slow, but unavoidable.
>
> #
>
> SecRequestBodyInMemoryLimit 131072
>
>
>
> # What do do if the request body size is above our configured limit.
>
> # Keep in mind that this setting will automatically be set to ProcessPartial
>
> # when SecRuleEngine is set to DetectionOnly mode in order to minimize
>
> # disruptions when initially deploying ModSecurity.
>
> #
>
> SecRequestBodyLimitAction Reject
>
>
>
> # Verify that we've correctly processed the request body.
>
> # As a rule of thumb, when failing to process a request body
>
> # you should reject the request (when deployed in blocking mode)
>
> # or log a high-severity alert (when deployed in detection-only mode).
>
> #
>
> SecRule REQBODY_ERROR "!@eq 0" \
>
> "phase:2,t:none,log,deny,status:400,msg:'Failed to parse request
> body.',logdata:'%{reqbody_error_msg}',severity:2"
>
>
>
> # By default be strict with what we accept in the multipart/form-data
>
> # request body. If the rule below proves to be too strict for your
>
> # environment consider changing it to detection-only. You are encouraged
>
> # _not_ to remove it altogether.
>
> #
>
> SecRule MULTIPART_STRICT_ERROR "!@eq 0" \
>
> "phase:2,t:none,log,deny,status:44,msg:'Multipart request body \
>
> failed strict validation: \
>
> PE %{REQBODY_PROCESSOR_ERROR}, \
>
> BQ %{MULTIPART_BOUNDARY_QUOTED}, \
>
> BW %{MULTIPART_BOUNDARY_WHITESPACE}, \
>
> DB %{MULTIPART_DATA_BEFORE}, \
>
> DA %{MULTIPART_DATA_AFTER}, \
>
> HF %{MULTIPART_HEADER_FOLDING}, \
>
> LF %{MULTIPART_LF_LINE}, \
>
> SM %{MULTIPART_SEMICOLON_MISSING}, \
>
> IQ %{MULTIPART_INVALID_QUOTING}, \
>
> IH %{MULTIPART_INVALID_HEADER_FOLDING}, \
>
> IH %{MULTIPART_FILE_LIMIT_EXCEEDED}'"
>
>
>
> # Did we see anything that might be a boundary?
>
> #
>
> SecRule MULTIPART_UNMATCHED_BOUNDARY "!@eq 0" \
>
> "phase:2,t:none,log,deny,status:44,msg:'Multipart parser detected a possible
> unmatched boundary.'"
>
>
>
> # PCRE Tuning
>
> # We want to avoid a potential RegEx DoS condition
>
> #
>
> SecPcreMatchLimit 1000
>
> SecPcreMatchLimitRecursion 1000
>
>
>
> # Some internal errors will set flags in TX and we will need to look for
> these.
>
> # All of these are prefixed with "MSC_".  The following flags currently
> exist:
>
> #
>
> # MSC_PCRE_LIMITS_EXCEEDED: PCRE match limits were exceeded.
>
> #
>
> SecRule TX:/^MSC_/ "!@streq 0" \
>
>         "phase:2,t:none,deny,msg:'ModSecurity internal error flagged:
> %{MATCHED_VAR_NAME}'"
>
>
>
>
>
> # -- Response body handling
> --------------------------------------------------
>
>
>
> # Allow ModSecurity to access response bodies.
>
> # You should have this directive enabled in order to identify errors
>
> # and data leakage issues.
>
> #
>
> # Do keep in mind that enabling this directive does increases both
>
> # memory consumption and response latency.
>
> #
>
> SecResponseBodyAccess On
>
>
>
> # Which response MIME types do you want to inspect? You should adjust the
>
> # configuration below to catch documents but avoid static files
>
> # (e.g., images and archives).
>
> #
>
> SecResponseBodyMimeType text/plain text/html text/xml
>
>
>
> # Buffer response bodies of up to 512 KB in length.
>
> SecResponseBodyLimit 524288
>
>
>
> # What happens when we encounter a response body larger than the configured
>
> # limit? By default, we process what we have and let the rest through.
>
> # That's somewhat less secure, but does not break any legitimate pages.
>
> #
>
> SecResponseBodyLimitAction ProcessPartial
>
>
>
>
>
> # -- Filesystem configuration
> ------------------------------------------------
>
>
>
> # The location where ModSecurity stores temporary files (for example, when
>
> # it needs to handle a file upload that is larger than the configured
> limit).
>
> #
>
> # This default setting is chosen due to all systems have /tmp available
> however,
>
> # this is less than ideal. It is recommended that you specify a location
> that's private.
>
> #
>
> SecTmpDir /tmp/
>
>
>
> # The location where ModSecurity will keep its persistent data.  This
> default setting
>
> # is chosen due to all systems have /tmp available however, it
>
> # too should be updated to a place that other users can't access.
>
> #
>
> SecDataDir /tmp/
>
>
>
>
>
> # -- File uploads handling configuration
> -------------------------------------
>
>
>
> # The location where ModSecurity stores intercepted uploaded files. This
>
> # location must be private to ModSecurity. You don't want other users on
>
> # the server to access the files, do you?
>
> #
>
> #SecUploadDir /opt/modsecurity/var/upload/
>
>
>
> # By default, only keep the files that were determined to be unusual
>
> # in some way (by an external inspection script). For this to work you
>
> # will also need at least one file inspection rule.
>
> #
>
> #SecUploadKeepFiles RelevantOnly
>
>
>
> # Uploaded files are by default created with permissions that do not allow
>
> # any other user to access them. You may need to relax that if you want to
>
> # interface ModSecurity to an external program (e.g., an anti-virus).
>
> #
>
> #SecUploadFileMode 0600
>
>
>
>
>
> # -- Debug log configuration
> -------------------------------------------------
>
>
>
> # The default debug log configuration is to duplicate the error, warning
>
> # and notice messages from the error log.
>
> #
>
> SecDebugLog /usr/local/apache2/logs/modsec_debug.log
>
> SecDebugLogLevel 9
>
>
>
>
>
> # -- Audit log configuration
> -------------------------------------------------
>
>
>
> # Log the transactions that are marked by a rule, as well as those that
>
> # trigger a server error (determined by a 5xx or 4xx, excluding 404,
>
> # level response status codes).
>
> #
>
> SecAuditEngine RelevantOnly
>
> SecAuditLogRelevantStatus "^(?:5|4(?!04))"
>
>
>
> # Log everything we know about a transaction.
>
> SecAuditLogParts ABIJDEFHKZ
>
>
>
> # Use a single file for logging. This is much easier to look at, but
>
> # assumes that you will use the audit log only ocassionally.
>
> #
>
> SecAuditLogType Serial
>
> SecAuditLog /usr/local/apache2/logs/modsec_audit.log
>
>
>
> # Specify the path for concurrent audit logging.
>
> #SecAuditLogStorageDir /opt/modsecurity/var/audit/
>
>
>
>
>
> # -- Miscellaneous
> -----------------------------------------------------------
>
>
>
> # Use the most commonly used application/x-www-form-urlencoded parameter
>
> # separator. There's probably only one application somewhere that uses
>
> # something else so don't expect to change this value.
>
> #
>
> SecArgumentSeparator &
>
>
>
> # Settle on version 0 (zero) cookies, as that is what most applications
>
> # use. Using an incorrect cookie version may open your installation to
>
> # evasion attacks (against the rules that examine named cookies).
>
> #
>
> SecCookieFormat 0
>
>
>
>
>
> My apache is:
>
>
>
> Server version: Apache/2.2.20 (Unix)
>
> Server built:   Sep 16 2011 10:16:58
>
> Server's Module Magic Number: 20051115:28
>
> Server loaded:  APR 1.4.5, APR-Util 1.3.12
>
> Compiled using: APR 1.4.5, APR-Util 1.3.12
>
> Architecture:   32-bit
>
> Server MPM:     Prefork
>
>   threaded:     no
>
>     forked:     yes (variable process count)
>
> Server compiled with....
>
> -D APACHE_MPM_DIR="server/mpm/prefork"
>
> -D APR_HAS_SENDFILE
>
> -D APR_HAS_MMAP
>
> -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
>
> -D APR_USE_PROC_PTHREAD_SERIALIZE
>
> -D APR_USE_PTHREAD_SERIALIZE
>
> -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
>
> -D APR_HAS_OTHER_CHILD
>
> -D AP_HAVE_RELIABLE_PIPED_LOGS
>
> -D DYNAMIC_MODULE_LIMIT=128
>
> -D HTTPD_ROOT="/usr/local/httpd-2.2.20"
>
> -D SUEXEC_BIN="/usr/local/httpd-2.2.20/bin/suexec"
>
> -D DEFAULT_PIDLOG="logs/httpd.pid"
>
> -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
>
> -D DEFAULT_LOCKFILE="logs/accept.lock"
>
> -D DEFAULT_ERRORLOG="logs/error_log"
>
> -D AP_TYPES_CONFIG_FILE="conf/mime.types"
>
> -D SERVER_CONFIG_FILE="conf/httpd.conf"
>
>
>
>
>
> IMPORTANT NOTICE REGARDING THIS ELECTRONIC MESSAGE:
>
> This message is intended for the use of the person to whom it is addressed
> and may contain information that is privileged, confidential, and protected
> from disclosure under applicable law. If you are not the intended recipient,
> your use of this message for any purpose is strictly prohibited. If you have
> received this communication in error, please delete the message and notify
> the sender so that we may correct our records.
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2dcopy1
> _______________________________________________
> mod-security-users mailing list
> mod...@li...
> https://lists.sourceforge.net/lists/listinfo/mod-security-users
> Commercial ModSecurity Rules and Support from Trustwave's SpiderLabs:
> http://www.modsecurity.org/projects/commercial/rules/
> http://www.modsecurity.org/projects/commercial/support/
>
>



--
'(Yours parenthetically
"peter barabas")

IMPORTANT NOTICE REGARDING THIS ELECTRONIC MESSAGE:

This message is intended for the use of the person to whom it is addressed and may contain information that is privileged, confidential, and protected from disclosure under applicable law.  If you are not the intended recipient, your use of this message for any purpose is strictly prohibited.  If you have received this communication in error, please delete the message and notify the sender so that we may correct our records.