From 5f09dbb3eed47ed5608a259e3d4b9d547403569e Mon Sep 17 00:00:00 2001 From: brectanus Date: Fri, 28 Mar 2008 17:06:44 +0000 Subject: [PATCH] Sync up trunk with changes from 2.5.x. --- CHANGES | 21 + apache2/Makefile.in | 3 +- apache2/apache2_config.c | 14 +- apache2/build/find_lua.m4 | 16 + apache2/configure.in | 34 +- apache2/modsecurity.c | 12 +- apache2/modsecurity.h | 11 +- apache2/re.c | 20 +- doc/modsecurity2-apache-reference.xml | 753 ++++++++++++-------------- 9 files changed, 458 insertions(+), 426 deletions(-) diff --git a/CHANGES b/CHANGES index 12f1f9d7..30ebd1f8 100644 --- a/CHANGES +++ b/CHANGES @@ -1,3 +1,24 @@ +19 Mar 2008 - 2.5.1-breach1 +--------------------------- + + * Allow HTTP_* targets as an alias for REQUEST_HEADERS:*. + + +14 Mar 2008 - 2.5.1 +------------------- + + * Fixed an issue where a match would not occur if transformation caching + was enabled. + + * Using "severity" in a default action is now just a warning. + + * Cleaned up the "make test" target to better locate headers/libraries. + + * Now search /usr/lib64 and /usr/lib32 for lua libs. + + * No longer treat warnings as errors by default (use --enable-strict-compile). + + 19 Feb 2008 - 2.5.0 ------------------- diff --git a/apache2/Makefile.in b/apache2/Makefile.in index 67274191..4acb2531 100644 --- a/apache2/Makefile.in +++ b/apache2/Makefile.in @@ -26,6 +26,7 @@ MODSEC_APXS_EXTRA_CFLAGS = @MODSEC_APXS_EXTRA_CFLAGS@ APXS = @APXS@ APXS_WRAPPER = @APXS_WRAPPER@ +APXS_INCLUDEDIR = @APXS_INCLUDEDIR@ APXS_INCLUDES = @APXS_INCLUDES@ APXS_CFLAGS = @APXS_CFLAGS@ APXS_LDFLAGS = @APXS_LDFLAGS@ @@ -112,7 +113,7 @@ mlogc-static: ### Experimental Test Framework (*NIX only right now) msc_test.lo: msc_test.c - $(LIBTOOL) --mode=compile $(CC) $(APXS_CFLAGS) $(EXTRA_CFLAGS) $(MODSEC_EXTRA_CFLAGS) $(CPPFLAGS) $(APR_CFLAGS) $(APU_CFLAGS) -o msc_test.lo -c msc_test.c + $(LIBTOOL) --mode=compile $(CC) $(APXS_INCLUDES) $(APXS_CFLAGS) $(EXTRA_CFLAGS) $(MODSEC_EXTRA_CFLAGS) $(CPPFLAGS) $(APR_CFLAGS) $(APU_CFLAGS) -o msc_test.lo -c msc_test.c msc_test: $(TESTOBJS) msc_test.lo @objs=""; \ diff --git a/apache2/apache2_config.c b/apache2/apache2_config.c index d7bb4857..6de2223a 100644 --- a/apache2/apache2_config.c +++ b/apache2/apache2_config.c @@ -1120,13 +1120,21 @@ static const char *cmd_default_action(cmd_parms *cmd, void *_dcfg, const char *p /* ENH: loop through to check for tags */ if ((dcfg->tmp_default_actionset->id != NOT_SET_P) ||(dcfg->tmp_default_actionset->rev != NOT_SET_P) - ||(dcfg->tmp_default_actionset->msg != NOT_SET_P) - ||(dcfg->tmp_default_actionset->severity != NOT_SET) - ||(dcfg->tmp_default_actionset->logdata != NOT_SET_P)) + ||(dcfg->tmp_default_actionset->msg != NOT_SET_P)) { return apr_psprintf(cmd->pool, "ModSecurity: SecDefaultAction must not " "contain any metadata actions (id, rev, msg, tag, severity, logdata)."); } + /* These are just a warning for now. */ + if ((dcfg->tmp_default_actionset->severity != NOT_SET) + ||(dcfg->tmp_default_actionset->logdata != NOT_SET_P)) + { + ap_log_perror(APLOG_MARK, + APLOG_STARTUP|APLOG_WARNING|APLOG_NOERRNO, 0, cmd->pool, + "ModSecurity: WARNING Using \"severity\" or \"logdata\" in " + "SecDefaultAction is deprecated (%s:%d).", + cmd->directive->filename, cmd->directive->line_num); + } /* Must not use chain. */ if (dcfg->tmp_default_actionset->is_chained != NOT_SET) { diff --git a/apache2/build/find_lua.m4 b/apache2/build/find_lua.m4 index 5a1842d6..759d8514 100644 --- a/apache2/build/find_lua.m4 +++ b/apache2/build/find_lua.m4 @@ -66,6 +66,14 @@ if test "${lua_path}" != "no"; then with_lua_lib="${x}/lib" lua_lib_name="lua5.1" break + elif test -e "${x}/lib64/liblua5.1.a"; then + with_lua_lib="${x}/lib64" + lua_lib_name="lua5.1" + break + elif test -e "${x}/lib32/liblua5.1.a"; then + with_lua_lib="${x}/lib32" + lua_lib_name="lua5.1" + break elif test -e "${x}/liblua.a"; then with_lua_lib="${x}" lua_lib_name="lua" @@ -74,6 +82,14 @@ if test "${lua_path}" != "no"; then with_lua_lib="${x}/lib" lua_lib_name="lua" break + elif test -e "${x}/lib64/liblua.a"; then + with_lua_lib="${x}/lib64" + lua_lib_name="lua" + break + elif test -e "${x}/lib32/liblua.a"; then + with_lua_lib="${x}/lib32" + lua_lib_name="lua" + break else with_lua_lib="" lua_lib_name="" diff --git a/apache2/configure.in b/apache2/configure.in index bcdf5179..4490d733 100644 --- a/apache2/configure.in +++ b/apache2/configure.in @@ -89,10 +89,22 @@ VERSION_OK [AC_MSG_NOTICE(httpd is recent enough)], [AC_MSG_ERROR(apache is too old, mmn must be at least $HTTPD_WANTED_MMN)]) fi - APXS_INCLUDES="`$APXS -q INCLUDES` `$APXS -q EXTRA_INCLUDES`" + APXS_INCLUDEDIR="`$APXS -q INCLUDEDIR`" + # Make sure the include dir is used + if test -n "$APXS_INCLUDEDIR"; then + APXS_INCLUDES="-I${APXS_INCLUDEDIR} `$APXS -q INCLUDES` `$APXS -q EXTRA_INCLUDES`" + else + APXS_INCLUDES="`$APXS -q INCLUDES` `$APXS -q EXTRA_INCLUDES`" + fi APXS_CFLAGS="`$APXS -q CFLAGS` `$APXS -q EXTRA_CFLAGS`" APXS_LDFLAGS="`$APXS -q LDFLAGS` `$APXS -q EXTRA_LDFLAGS`" - APXS_LIBS="`$APXS -q LIBS` `$APXS -q EXTRA_LIBS`" + APXS_LIBDIR="`$APXS -q LIBDIR`" + # Make sure the lib dir is used + if test -n "$APXS_LIBDIR"; then + APXS_LIBS="-L{$APXS_LIBDIR} `$APXS -q LIBS` `$APXS -q EXTRA_LIBS`" + else + APXS_LIBS="`$APXS -q LIBS` `$APXS -q EXTRA_LIBS`" + fi APXS_LIBTOOL="`$APXS -q LIBTOOL`" APXS_CC="`$APXS -q CC`" else @@ -126,6 +138,21 @@ sinclude(build/find_curl.m4) ### Configure Options +# Strict Compile +AC_ARG_ENABLE(strict-compile, + AS_HELP_STRING([--enable-strict-compile], + [Enable strict compilation (warnings are errors).]), +[ + if test "$enableval" != "no"; then + strict_compile="-Werror" + else + strict_compile= + fi +], +[ + strict_compile= +]) + # DEBUG_CONF AC_ARG_ENABLE(debug-conf, AS_HELP_STRING([--enable-debug-conf], @@ -203,7 +230,7 @@ AC_ARG_ENABLE(modsec-api, ### Build *EXTRA_CFLAGS vars -EXTRA_CFLAGS="-O2 -g -Wall -Werror" +EXTRA_CFLAGS="-O2 -g -Wall $strict_compile" MODSEC_EXTRA_CFLAGS="$debug_conf $debug_cache $debug_acmp $perf_meas $modsec_api" APXS_WRAPPER=build/apxs-wrapper @@ -227,6 +254,7 @@ AC_SUBST(EXTRA_CFLAGS) AC_SUBST(MODSEC_EXTRA_CFLAGS) AC_SUBST(APXS) AC_SUBST(APXS_WRAPPER) +AC_SUBST(APXS_INCLUDEDIR) AC_SUBST(APXS_INCLUDES) AC_SUBST(APXS_EXTRA_CFLAGS) AC_SUBST(MODSEC_APXS_EXTRA_CFLAGS) diff --git a/apache2/modsecurity.c b/apache2/modsecurity.c index c024d21f..f1092eb1 100644 --- a/apache2/modsecurity.c +++ b/apache2/modsecurity.c @@ -17,12 +17,12 @@ #include "msc_util.h" modsec_build_type_rec DSOLOCAL modsec_build_type[] = { - { "dev", 1 }, /* Development build */ - { "rc", 3 }, /* Release Candidate build */ - { "", 9 }, /* Production build */ - { "breach", 9 }, /* Breach build */ - { "trunk", 9 }, /* Trunk build */ - { NULL, -1 } /* terminator */ + { "-dev", 1 }, /* Development build */ + { "-rc", 3 }, /* Release Candidate build */ + { "", 9 }, /* Production build */ + { "-breach", 9 }, /* Breach build */ + { "-trunk", 9 }, /* Trunk build */ + { NULL, -1 } /* terminator */ }; /** diff --git a/apache2/modsecurity.h b/apache2/modsecurity.h index 38fcc53c..0c25c933 100644 --- a/apache2/modsecurity.h +++ b/apache2/modsecurity.h @@ -62,14 +62,17 @@ extern DSOLOCAL modsec_build_type_rec modsec_build_type[]; #define MODSEC_VERSION_MAJOR "2" #define MODSEC_VERSION_MINOR "5" -#define MODSEC_VERSION_MAINT "0" -#define MODSEC_VERSION_TYPE "" -#define MODSEC_VERSION_RELEASE "" +#define MODSEC_VERSION_MAINT "1" +#define MODSEC_VERSION_TYPE "-breach" +#define MODSEC_VERSION_RELEASE "1" #define MODULE_NAME "ModSecurity for Apache" + +#define MODSEC_VERSION_SUFFIX MODSEC_VERSION_TYPE MODSEC_VERSION_RELEASE #define MODULE_RELEASE \ MODSEC_VERSION_MAJOR "." MODSEC_VERSION_MINOR "." MODSEC_VERSION_MAINT \ - "-" MODSEC_VERSION_TYPE MODSEC_VERSION_RELEASE + MODSEC_VERSION_SUFFIX + #define MODULE_NAME_FULL MODULE_NAME "/" MODULE_RELEASE " (http://www.modsecurity.org/)" #define PHASE_REQUEST_HEADERS 1 diff --git a/apache2/re.c b/apache2/re.c index e6af7111..a5470253 100644 --- a/apache2/re.c +++ b/apache2/re.c @@ -231,6 +231,7 @@ msre_action_metadata *msre_resolve_action(msre_engine *engine, const char *name) msre_var *msre_create_var_ex(apr_pool_t *pool, msre_engine *engine, const char *name, const char *param, modsec_rec *msr, char **error_msg) { + const char *varparam = param; msre_var *var = apr_pcalloc(pool, sizeof(msre_var)); if (var == NULL) return NULL; @@ -251,6 +252,17 @@ msre_var *msre_create_var_ex(apr_pool_t *pool, msre_engine *engine, const char * var->name = name; } + /* Treat HTTP_* targets as an alias for REQUEST_HEADERS:* */ + if ( (var->name != NULL) + && (strlen(var->name) > 5) + && (strncmp("HTTP_", var->name, 5) == 0)) + { + const char *oldname = var->name; + var->name = apr_pstrdup(pool, "REQUEST_HEADERS"); + varparam = apr_pstrdup(pool, oldname + 5); + } + + /* Resolve variable */ var->metadata = msre_resolve_var(engine, var->name); if (var->metadata == NULL) { @@ -268,7 +280,7 @@ msre_var *msre_create_var_ex(apr_pool_t *pool, msre_engine *engine, const char * } /* Check the parameter. */ - if (param == NULL) { + if (varparam == NULL) { if (var->metadata->argc_min > 0) { *error_msg = apr_psprintf(engine->mp, "Missing mandatory parameter for variable %s.", name); @@ -283,7 +295,7 @@ msre_var *msre_create_var_ex(apr_pool_t *pool, msre_engine *engine, const char * return NULL; } - var->param = param; + var->param = varparam; } return var; @@ -735,6 +747,8 @@ void msre_engine_destroy(msre_engine *engine) { * transaction phase. */ #if defined(PERFORMANCE_MEASUREMENT) +static apr_status_t msre_ruleset_process_phase_(msre_ruleset *ruleset, modsec_rec *msr); + apr_status_t msre_ruleset_process_phase(msre_ruleset *ruleset, modsec_rec *msr) { apr_array_header_t *arr = NULL; msre_rule **rules = NULL; @@ -1986,6 +2000,8 @@ static apr_status_t msre_rule_process_normal(msre_rule *rule, modsec_rec *msr) { return -1; } if (rc == RULE_MATCH) { + match_count++; + /* Return straight away if the transaction * was intercepted - no need to process the remaining * targets. diff --git a/doc/modsecurity2-apache-reference.xml b/doc/modsecurity2-apache-reference.xml index a59dbe01..8c4a8742 100644 --- a/doc/modsecurity2-apache-reference.xml +++ b/doc/modsecurity2-apache-reference.xml @@ -1,10 +1,10 @@
- <trademark class="trade">ModSecurity</trademark> Reference + <title><trademark class="registered">ModSecurity</trademark> Reference Manual - Version 2.5.0 (February 19, 2008) + Version 2.5.1-breach1 (March 19, 2008) 2004-2008 @@ -17,12 +17,11 @@
Introduction - ModSecurity is a web - application firewall (WAF). With over 70% of attacks now carried out over - the web application level, organisations need all the help they can get in - making their systems secure. WAFs are deployed to establish an increased - external security layer to detect and/or prevent attacks before they reach - web applications. ModSecurity + ModSecurity is a web application firewall (WAF). With over 70% of + attacks now carried out over the web application level, organisations need + all the help they can get in making their systems secure. WAFs are + deployed to establish an increased external security layer to detect + and/or prevent attacks before they reach web applications. ModSecurity provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring and real-time analysis with little or no changes to existing infrastructure. @@ -34,34 +33,32 @@ useful for marketing analyses, but fall short logging traffic to web applications. In particular, most are not capable of logging the request bodies. Your adversaries know this, and that is why most attacks are now - carried out via POST requests, rendering your systems blind. ModSecurity makes full HTTP transaction - logging possible, allowing complete requests and responses to be logged. - Its logging facilities also allow fine-grained decisions to be made - about exactly what is logged and when, ensuring only the relevant data - is recorded. As some of the request and/or response may contain - sensitive data in certain fields, ModSecurity can be configured to mask these - fields before they are written to the audit log. + carried out via POST requests, rendering your systems blind. ModSecurity + makes full HTTP transaction logging possible, allowing complete requests + and responses to be logged. Its logging facilities also allow + fine-grained decisions to be made about exactly what is logged and when, + ensuring only the relevant data is recorded. As some of the request + and/or response may contain sensitive data in certain fields, + ModSecurity can be configured to mask these fields before they are + written to the audit log.
Real-Time Monitoring and Attack Detection - In addition to providing logging facilities, ModSecurity can monitor the HTTP traffic in - real time in order to detect attacks. In this case, ModSecurity operates as a web intrusion - detection tool, allowing you to react to suspicious events that take - place at your web systems. + In addition to providing logging facilities, ModSecurity can + monitor the HTTP traffic in real time in order to detect attacks. In + this case, ModSecurity operates as a web intrusion detection tool, + allowing you to react to suspicious events that take place at your web + systems.
Attack Prevention and Just-in-time Patching - ModSecurity can also act - immediately to prevent attacks from reaching your web applications. - There are three commonly used approaches: + ModSecurity can also act immediately to prevent attacks from + reaching your web applications. There are three commonly used + approaches: @@ -83,15 +80,14 @@ Known weaknesses and vulnerabilities. Its rule language makes - ModSecurity an ideal external - patching tool. External patching (sometimes referred to as Virtual - Patching) is about reducing the window of opportunity. Time needed - to patch application vulnerabilities often runs to weeks in many - organisations. With ModSecurity, applications can be patched - from the outside, without touching the application source code (and - even without any access to it), making your systems secure until a - proper patch is applied to the application. + ModSecurity an ideal external patching tool. External patching + (sometimes referred to as Virtual Patching) is about reducing the + window of opportunity. Time needed to patch application + vulnerabilities often runs to weeks in many organisations. With + ModSecurity, applications can be patched from the outside, without + touching the application source code (and even without any access to + it), making your systems secure until a proper patch is applied to + the application.
@@ -99,36 +95,33 @@
Flexible Rule Engine - A flexible rule engine sits in the heart of ModSecurity. It implements the ModSecurity Rule Language, which is a - specialised programming language designed to work with HTTP transaction - data. The ModSecurity Rule Language - is designed to be easy to use, yet flexible: common operations are - simple while complex operations are possible. Certified ModSecurity Rules, included with ModSecurity, contain a comprehensive set of - rules that implement general-purpose hardening, protocol validation and - detection of common web application security issues. Heavily commented, - these rules can be used as a learning tool. + A flexible rule engine sits in the heart of ModSecurity. It + implements the ModSecurity Rule Language, which is a specialised + programming language designed to work with HTTP transaction data. The + ModSecurity Rule Language is designed to be easy to use, yet flexible: + common operations are simple while complex operations are possible. + Certified ModSecurity Rules, included with ModSecurity, contain a + comprehensive set of rules that implement general-purpose hardening, + protocol validation and detection of common web application security + issues. Heavily commented, these rules can be used as a learning + tool.
Embedded-mode Deployment - ModSecurity is an embeddable - web application firewall, which means it can be deployed as part of your - existing web server infrastructure provided your web servers are - Apache-based. This deployment method has certain advantages: + ModSecurity is an embeddable web application firewall, which means + it can be deployed as part of your existing web server infrastructure + provided your web servers are Apache-based. This deployment method has + certain advantages: No changes to existing network. It only takes a few minutes to - add ModSecurity to your - existing web servers. And because it was designed to be completely - passive by default, you are free to deploy it incrementally and only - use the features you need. It is equally easy to remove or - deactivate it if required. + add ModSecurity to your existing web servers. And because it was + designed to be completely passive by default, you are free to deploy + it incrementally and only use the features you need. It is equally + easy to remove or deactivate it if required. @@ -139,10 +132,10 @@ Implicit load balancing and scaling. Because it works embedded - in web servers, ModSecurity - will automatically take advantage of the additional load balancing - and scalability features. You will not need to think of load - balancing and scaling unless your existing system needs them. + in web servers, ModSecurity will automatically take advantage of the + additional load balancing and scalability features. You will not + need to think of load balancing and scaling unless your existing + system needs them. @@ -154,9 +147,8 @@ No problem with encrypted or compressed content. Many IDS systems have difficulties analysing SSL traffic. This is not a - problem for ModSecurity because - it is positioned to work when the traffic is decrypted and - decompressed. + problem for ModSecurity because it is positioned to work when the + traffic is decrypted and decompressed.
@@ -164,32 +156,30 @@
Network-based Deployment - ModSecurity works equally - well when deployed as part of an Apache-based reverse proxy server, and - many of our customers choose to do so. In this scenario, one - installation of ModSecurity can - protect any number of web servers (even the non-Apache ones). + ModSecurity works equally well when deployed as part of an + Apache-based reverse proxy server, and many of our customers choose to + do so. In this scenario, one installation of ModSecurity can protect any + number of web servers (even the non-Apache ones).
Portability - ModSecurity is known to work - well on a wide range of operating systems. Our customers are - successfully running it on Linux, Windows, Solaris, FreeBSD, OpenBSD, - NetBSD, AIX, Mac OS X, and HP-UX. + ModSecurity is known to work well on a wide range of operating + systems. Our customers are successfully running it on Linux, Windows, + Solaris, FreeBSD, OpenBSD, NetBSD, AIX, Mac OS X, and HP-UX.
Licensing - ModSecurity is available - under two licenses. Users can choose to use the software under the terms - of the GNU General Public License version 2 (licence text is included - with the distribution), as an Open Source / Free Software product. A - range of commercial licenses is also available, together with a range of - commercial support contracts. For more information on commercial - licensing please contact Breach Security. + ModSecurity is available under two licenses. Users can choose to + use the software under the terms of the GNU General Public License + version 2 (licence text is included with the distribution), as an Open + Source / Free Software product. A range of commercial licenses is also + available, together with a range of commercial support contracts. For + more information on commercial licensing please contact Breach + Security. ModSecurity, mod_security, and ModSecurity Pro are trademarks or @@ -199,27 +189,24 @@
- <trademark class="trade">ModSecurity</trademark> Core Rules + <trademark class="registered">ModSecurity</trademark> Core + Rules
Overview - ModSecurity is a web - application firewall engine that provides very little protection on its - own. In order to become useful, ModSecurity must be configured with rules. In - order to enable users to take full advantage of ModSecurity out of the box, Breach Security, - Inc. is providing a free certified rule set for ModSecurity 2.x. Unlike intrusion detection - and prevention systems, which rely on signatures specific to known - vulnerabilities, the Core Rules provide generic protection from unknown - vulnerabilities often found in web applications, which are in most cases - custom coded. The Core Rules are heavily commented to allow it to be - used as a step-by-step deployment guide for ModSecurity. The latest Core Rules can be - found at the ModSecurity website - - ModSecurity is a web application firewall engine that provides + very little protection on its own. In order to become useful, + ModSecurity must be configured with rules. In order to enable users to + take full advantage of ModSecurity out of the box, Breach Security, Inc. + is providing a free certified rule set for ModSecurity 2.x. Unlike + intrusion detection and prevention systems, which rely on signatures + specific to known vulnerabilities, the Core Rules provide generic + protection from unknown vulnerabilities often found in web applications, + which are in most cases custom coded. The Core Rules are heavily + commented to allow it to be used as a step-by-step deployment guide for + ModSecurity. The latest Core Rules can be found at the ModSecurity + website - http://www.modsecurity.org/projects/rules/.
@@ -260,13 +247,11 @@
Installation - ModSecurity installation - consists of the following steps: + ModSecurity installation consists of the following steps: - ModSecurity 2.x works with - Apache 2.0.x or better. + ModSecurity 2.x works with Apache 2.0.x or better. @@ -297,8 +282,7 @@ - Unpack the ModSecurity - archive + Unpack the ModSecurity archive @@ -333,11 +317,15 @@ Optionally test with: make test + + NOTE: This is step is still a bit experimental. If you + have problems, please send the full output and error from the + build to the support list. Most common issues are related to + not finding the required headers and/or libraries. - Optionally build the ModSecurity Log Collector with: + Optionally build the ModSecurity Log Collector with: make mlogc @@ -348,9 +336,8 @@ - Install the ModSecurity module with: - make install + Install the ModSecurity module with: make + install @@ -370,9 +357,8 @@ - Install the ModSecurity module with: - nmake -f Makefile.win install + Install the ModSecurity module with: nmake -f + Makefile.win install @@ -392,19 +378,17 @@ httpd.conf) On UNIX (and Windows if you did not copy the DLLs as stated - above) you must load libxml2 and lua5.1 before ModSecurity with something like this: + above) you must load libxml2 and lua5.1 before ModSecurity with + something like this: LoadFile /usr/lib/libxml2.so LoadFile /usr/lib/liblua5.1.so - Load the ModSecurity module - with:LoadModule security2_module modules/mod_security2.so + Load the ModSecurity module with:LoadModule security2_module modules/mod_security2.so - Configure ModSecurity + Configure ModSecurity @@ -412,38 +396,35 @@ LoadFile /usr/lib/liblua5.1.so - You should now have ModSecurity 2.x up and running. + You should now have ModSecurity 2.x up and running. If you have compiled Apache yourself you might experience problems - compiling ModSecurity against PCRE. - This is because Apache bundles PCRE but this library is also typically - provided by the operating system. I would expect most (all) - vendor-packaged Apache distributions to be configured to use an external - PCRE library (so this should not be a problem). + compiling ModSecurity against PCRE. This is because Apache bundles PCRE + but this library is also typically provided by the operating system. I + would expect most (all) vendor-packaged Apache distributions to be + configured to use an external PCRE library (so this should not be a + problem). You want to avoid Apache using the bundled PCRE library and - ModSecurity linking against the one - provided by the operating system. The easiest way to do this is to - compile Apache against the PCRE library provided by the operating system - (or you can compile it against the latest PCRE version you downloaded - from the main PCRE distribution site). You can do this at configure time - using the --with-pcre switch. If you - are not in a position to recompile Apache, then, to compile ModSecurity successfully, you'd still need to - have access to the bundled PCRE headers (they are available only in the - Apache source code) and change the include path for ModSecurity (as you did in step 7 above) to - point to them (via the --with-pcre ModSecurity configure option). + ModSecurity linking against the one provided by the operating system. + The easiest way to do this is to compile Apache against the PCRE library + provided by the operating system (or you can compile it against the + latest PCRE version you downloaded from the main PCRE distribution + site). You can do this at configure time using the --with-pcre switch. If you are not in a + position to recompile Apache, then, to compile ModSecurity successfully, + you'd still need to have access to the bundled PCRE headers (they are + available only in the Apache source code) and change the include path + for ModSecurity (as you did in step 7 above) to point to them (via the + --with-pcre ModSecurity configure option). Do note that if your Apache is using an external PCRE library you - can compile ModSecurity with - WITH_PCRE_STUDY defined,which would - possibly give you a slight performance edge in regular expression + can compile ModSecurity with WITH_PCRE_STUDY defined,which would possibly + give you a slight performance edge in regular expression processing.
@@ -451,10 +432,9 @@ LoadFile /usr/lib/liblua5.1.so
Configuration Directives - The following section outlines all of the ModSecurity directives. Most of the ModSecurity directives can be used inside the - various Apache Scope Directives such as VirtualHost, + The following section outlines all of the ModSecurity directives. + Most of the ModSecurity directives can be used inside the various Apache + Scope Directives such as VirtualHost, Location, LocationMatch, Directory, etc... There are others, however, that can only be used once in the main configuration file. This information is @@ -468,20 +448,18 @@ LoadFile /usr/lib/liblua5.1.so rules, you should create a file called - modsecurity_crs_15_customrules.conf and place it in the same directory as the Core rules files. By using this file name, your - custom rules will be called up after the standard ModSecurity Core rules configuration file but - before the other Core rules. This allows your rules to be evaluated first - which can be useful if you need to implement specific "allow" rules or to - correct any false positives in the Core rules as they are applied to your - site. + custom rules will be called up after the standard ModSecurity Core rules + configuration file but before the other Core rules. This allows your rules + to be evaluated first which can be useful if you need to implement + specific "allow" rules or to correct any false positives in the Core rules + as they are applied to your site. It is highly encouraged that you do not edit the Core rules files themselves but rather place all changes (such as SecRuleRemoveByID, etc...) in your custom rules file. This will allow for easier upgrading as newer Core rules are released by - Breach Security on the ModSecurity - website. + Breach Security on the ModSecurity website.
@@ -540,8 +518,7 @@ LoadFile /usr/lib/liblua5.1.so This directive is needed if a backend web application is using a non-standard argument separator. If this directive is not set properly - for each web application, then ModSecurity will not be able to parse the + for each web application, then ModSecurity will not be able to parse the arguments appropriately and the effectiveness of the rule matching will be significantly decreased.
@@ -628,9 +605,8 @@ SecAuditLogStorageDir logs/audit this file will be used as an index, and contain a record of all audit log files created. If you are planning to use Concurrent audit logging and sending your audit log data off to a remote Console host or - commercial ModSecurity Management - Appliance, then you will need to configure and use the ModSecurity Log Collector (mlogc) and use the + commercial ModSecurity Management Appliance, then you will need to + configure and use the ModSecurity Log Collector (mlogc) and use the following format for the audit log: SecAuditLog "|/path/to/mlogc /path/to/mlogc.conf" @@ -682,10 +658,10 @@ SecAuditLogStorageDir logs/audit Version: 2.0.0 - Dependencies/Notes: At this time ModSecurity does not log response bodies of - stock Apache responses (e.g. 404), or - the Server and Dependencies/Notes: At this time ModSecurity + does not log response bodies of stock Apache responses (e.g. 404), or the Server and Date response headers. Default: ABCFHZ. @@ -704,9 +680,8 @@ SecAuditLogStorageDir logs/audit C - request body (present - only if the request body exists and ModSecurity is configured to intercept - it) + only if the request body exists and ModSecurity is configured to + intercept it) @@ -716,14 +691,13 @@ SecAuditLogStorageDir logs/audit E - intermediary response - body (present only if ModSecurity is configured to intercept + 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). + 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). @@ -873,8 +847,7 @@ SecAuditLogStorageDir logs/audit Concurrent - audit log entries will be stored in separate files, one for each transaction. Concurrent logging is the mode to use if you are going to send the - audit log data off to a remote ModSecurity Console host. + audit log data off to a remote ModSecurity Console host.
@@ -953,8 +926,7 @@ SecAuditLogStorageDir logs/audit Version: 2.0.0 Dependencies/Notes: The internal chroot - functionality provided by ModSecurity works great for simple setups. One + functionality provided by ModSecurity works great for simple setups. One example of a simple setup is Apache serving static files only, or running scripts using modules. Some problems you might encounter with more complex setups: @@ -994,7 +966,7 @@ SecAuditLogStorageDir logs/audit <literal>SecComponentSignature</literal> Description: Appends component signature to - the ModSecurity signature. + the ModSecurity signature. Syntax: SecComponentSignature "COMPONENT_NAME/X.Y.Z (COMMENT)" @@ -1009,11 +981,10 @@ SecAuditLogStorageDir logs/audit Version: 2.5.0 Dependencies/Notes: This directive should be - used to make the presence of significant ModSecurity components known. The entire - signature will be recorded in transaction audit log. It should be used - by ModSecurity module and rule set - writers to make debugging easier. + used to make the presence of significant ModSecurity components known. + The entire signature will be recorded in transaction audit log. It + should be used by ModSecurity module and rule set writers to make + debugging easier.
@@ -1097,8 +1068,8 @@ SecAuditLogStorageDir logs/audit
<literal>SecDebugLog</literal> - Description: Path to the ModSecurity debug log file. + Description: Path to the ModSecurity debug + log file. Syntax: SecDebugLog /path/to/modsec-debug.log @@ -1264,27 +1235,25 @@ SecAuditLogStorageDir logs/audit will defend against clients that send more than 120 requests in a minute, or more than 360 requests in five minutes. - Since 1.9, ModSecurity - supports a new directive, SecGuardianLog, that is designed to send all - access data to another program using the piped logging feature. Since - Apache is typically deployed in a multi-process fashion, making - information sharing difficult, the idea is to deploy a single external - process to observe all requests in a stateful manner, providing - additional protection. + Since 1.9, ModSecurity supports a new directive, SecGuardianLog, + that is designed to send all access data to another program using the + piped logging feature. Since Apache is typically deployed in a + multi-process fashion, making information sharing difficult, the idea is + to deploy a single external process to observe all requests in a + stateful manner, providing additional protection. Development of a state of the art external protection tool will be - a focus of subsequent ModSecurity - releases. However, a fully functional tool is already available as part - of the Apache - httpd tools project. The tool is called httpd-guardian and can - be used to defend against Denial of Service attacks. It uses the - blacklist tool (from the same project) to interact with an - iptables-based (Linux) or pf-based (*BSD) firewall, dynamically - blacklisting the offending IP addresses. It can also interact with - SnortSam (http://www.snortsam.net). Assuming httpd-guardian is already - configured (look into the source code for the detailed instructions) you - only need to add one line to your Apache configuration to deploy - it: + a focus of subsequent ModSecurity releases. However, a fully functional + tool is already available as part of the Apache httpd tools + project. The tool is called httpd-guardian and can be used to + defend against Denial of Service attacks. It uses the blacklist tool + (from the same project) to interact with an iptables-based (Linux) or + pf-based (*BSD) firewall, dynamically blacklisting the offending IP + addresses. It can also interact with SnortSam (http://www.snortsam.net). + Assuming httpd-guardian is already configured (look into the source code + for the detailed instructions) you only need to add one line to your + Apache configuration to deploy it: SecGuardianLog |/path/to/httpd-guardian
@@ -1437,11 +1406,10 @@ SecRule &REQUEST_HEADERS:Accept "@eq 0" \ Description: Defines the name of the token. The only reason you would want to change the name of the token is if you - wanted to hide the fact you are running ModSecurity. It's a good reason but it won't - really help as the adversary can look into the algorithm used for PDF - protection and figure it out anyway. It does raise the bar slightly so - go ahead if you want to. + wanted to hide the fact you are running ModSecurity. It's a good reason + but it won't really help as the adversary can look into the algorithm + used for PDF protection and figure it out anyway. It does raise the bar + slightly so go ahead if you want to. Syntax: SecPdfProtectTokenName name @@ -1464,8 +1432,7 @@ SecRule &REQUEST_HEADERS:Accept "@eq 0" \ <literal>SecRequestBodyAccess</literal> Description: Configures whether request - bodies will be buffered and processed by ModSecurity by default. + bodies will be buffered and processed by ModSecurity by default. Syntax: SecRequestBodyAccess On|Off @@ -1504,8 +1471,7 @@ SecRule &REQUEST_HEADERS:Accept "@eq 0" \ <literal>SecRequestBodyLimit</literal> Description: Configures the maximum request - body size ModSecurity will accept - for buffering. + body size ModSecurity will accept for buffering. Syntax: SecRequestBodyLimit NUMBER_IN_BYTES @@ -1527,16 +1493,16 @@ SecRule &REQUEST_HEADERS:Accept "@eq 0" \ <literal>SecRequestBodyNoFilesLimit</literal> Description: Configures the maximum request - body size ModSecurity will accept - for buffering, excluding the size of files being transported in the - request. This directive comes handy to further reduce susceptibility to - DoS attacks when someone is sending request bodies of very large sizes. - Web applications that require file uploads must configure - SecRequestBodyLimit to a high value. Since large - files are streamed to disk file uploads will not increase memory - consumption. However, it's still possible for someone to take advantage - of a large request body limit and send non-upload requests with large - body sizes. This directive eliminates that loophole. + body size ModSecurity will accept for buffering, excluding the size of + files being transported in the request. This directive comes handy to + further reduce susceptibility to DoS attacks when someone is sending + request bodies of very large sizes. Web applications that require file + uploads must configure SecRequestBodyLimit to a high + value. Since large files are streamed to disk file uploads will not + increase memory consumption. However, it's still possible for someone to + take advantage of a large request body limit and send non-upload + requests with large body sizes. This directive eliminates that + loophole. Syntax: SecRequestBodyNoFilesLimit @@ -1561,8 +1527,7 @@ SecRule &REQUEST_HEADERS:Accept "@eq 0" \ <literal>SecRequestBodyInMemoryLimit</literal> Description: Configures the maximum request - body size ModSecurity will store in - memory. + body size ModSecurity will store in memory. Syntax: SecRequestBodyInMemoryLimit @@ -1620,21 +1585,21 @@ SecResponseBodyLimit 524288 Description: Controls what happens once a response body limit, configured with SecResponseBodyLimit, is encountered. By default - ModSecurity will reject a response - body that is longer than specified. Some web sites, however, will - produce very long responses making it difficult to come up with a - reasonable limit. Such sites would have to raise the limit significantly - to function properly defying the purpose of having the limit in the - first place (to control memory consumption). With the ability to choose - what happens once a limit is reached site administrators can choose to - inspect only the first part of the response, the part that can fit into - the desired limit, and let the rest through. Some could argue that - allowing parts of responses to go uninspected is a weakness. This is - true in theory but only applies to cases where the attacker controls the - output (e.g. can make it arbitrary long). In such cases, however, it is - not possible to prevent leakage anyway. The attacker could compress, - obfuscate, or even encrypt data before it is sent back, and therefore - bypass any monitoring device. + ModSecurity will reject a response body that is longer than specified. + Some web sites, however, will produce very long responses making it + difficult to come up with a reasonable limit. Such sites would have to + raise the limit significantly to function properly defying the purpose + of having the limit in the first place (to control memory consumption). + With the ability to choose what happens once a limit is reached site + administrators can choose to inspect only the first part of the + response, the part that can fit into the desired limit, and let the rest + through. Some could argue that allowing parts of responses to go + uninspected is a weakness. This is true in theory but only applies to + cases where the attacker controls the output (e.g. can make it arbitrary + long). In such cases, however, it is not possible to prevent leakage + anyway. The attacker could compress, obfuscate, or even encrypt data + before it is sent back, and therefore bypass any monitoring + device. Syntax: SecResponseBodyLimitAction Reject|ProcessPartial @@ -1747,9 +1712,8 @@ SecResponseBodyLimit 524288 <literal>SecRule</literal> Description: SecRule is the main ModSecurity directive. It is used to analyse - data and perform actions based on the results. + moreinfo="none">SecRule is the main ModSecurity directive. It + is used to analyse data and perform actions based on the results. Syntax: SecRule VARIABLES OPERATOR [ACTIONS] @@ -1808,8 +1772,7 @@ SecResponseBodyLimit 524288 In the simplest possible case you will use a regular expression pattern as the second rule parameter. This is what we've done in the - examples above. If you do this ModSecurity assumes you want to use the + examples above. If you do this ModSecurity assumes you want to use the rx operator. You can explicitly specify the operator you want to use by using @ as the first character in the second rule @@ -1872,12 +1835,11 @@ SecResponseBodyLimit 524288 processing process, before Apache maps request to resource. Virtual host context can override phase 1 rules configured in the main server. - Example: The following example shows where ModSecurity may be enabled in the main Apache - configuration scope, however you might want to configure your - VirtualHosts differently. In the first example, the first VirtualHost is - not inheriting the ModSecurity main - config directives and in the second one it is. + Example: The following example shows where ModSecurity may be + enabled in the main Apache configuration scope, however you might want + to configure your VirtualHosts differently. In the first example, the + first VirtualHost is not inheriting the ModSecurity main config + directives and in the second one it is. SecRuleEnine On SecDefaultAction log,pass,phase:2 @@ -2012,10 +1974,9 @@ ServerAlias www.app2.com rule that executes a Lua script to decide whether to match or not. The main difference from SecRule is that there are no targets nor operators. The script can fetch any variable from the - ModSecurity context and use any - (Lua) operator to test them. The second optional parameter is the list - of actions whose meaning is identical to that of - SecRule. + ModSecurity context and use any (Lua) operator to test them. The second + optional parameter is the list of actions whose meaning is identical to + that of SecRule. Syntax: SecRuleScript /path/to/script.lua [ACTIONS] @@ -2034,9 +1995,8 @@ ServerAlias www.app2.com All Lua scripts are compiled at configuration time and cached in - memory. To reload scripts you must reload the entire ModSecurity configuration by restarting - Apache. + memory. To reload scripts you must reload the entire ModSecurity + configuration by restarting Apache. Example script: @@ -2152,9 +2112,8 @@ SecRuleUpdateActionById 12345 "t:compressWhitespace,deny,status:403,msg:'A new m
<literal>SecServerSignature</literal> - Description: Instructs ModSecurity to change the data presented in - the "Server:" response header token. + Description: Instructs ModSecurity to change + the data presented in the "Server:" response header token. Syntax: SecServerSignature "WEB SERVER @@ -2172,11 +2131,10 @@ SecRuleUpdateActionById 12345 "t:compressWhitespace,deny,status:403,msg:'A new m Dependencies/Notes: In order for this directive to work, you must set the Apache ServerTokens directive to - Full. ModSecurity will overwrite - the server signature data held in this memory space with the data set in - this directive. If ServerTokens is not set to Full, then the memory - space is most likely not large enough to hold the new data we are - looking to insert. + Full. ModSecurity will overwrite the server signature data held in this + memory space with the data set in this directive. If ServerTokens is not + set to Full, then the memory space is most likely not large enough to + hold the new data we are looking to insert.
@@ -2343,20 +2301,18 @@ SecAction setsid:%{REQUEST_COOKIES.PHPSESSID} In the two examples configurations shown, SecWebAppId is being used in conjunction with the Apache VirtualHost directives. What this achieves is to create more unique collection names when being hosted on - one server. Normally, when setsid is used, ModSecurity will create a collection with the - name "SESSION" and it will hold the value specified. With using - SecWebAppId as shown in the examples, however, the name of the - collection would become "App1_SESSION" and "App2_SESSION". + one server. Normally, when setsid is used, ModSecurity will create a + collection with the name "SESSION" and it will hold the value specified. + With using SecWebAppId as shown in the examples, however, the name of + the collection would become "App1_SESSION" and "App2_SESSION". SecWebAppId is relevant in two cases: - You are logging transactions/alerts to the ModSecurity Console and you want to use - the web application ID to search only the transactions belonging to - that application. + You are logging transactions/alerts to the ModSecurity Console + and you want to use the web application ID to search only the + transactions belonging to that application. @@ -2371,8 +2327,8 @@ SecAction setsid:%{REQUEST_COOKIES.PHPSESSID}
Processing Phases - ModSecurity 2.x allows rules to - be placed in one of the following five phases: + ModSecurity 2.x allows rules to be placed in one of the following + five phases: @@ -2397,8 +2353,7 @@ SecAction setsid:%{REQUEST_COOKIES.PHPSESSID} Below is a diagram of the standard Apache Request Cycle. In the - diagram, the 5 ModSecurity processing - phases are shown. + diagram, the 5 ModSecurity processing phases are shown. @@ -2445,11 +2400,9 @@ SecRule REQUEST_HEADERS:Host "!^$" "deny,phase:1"Rules in this phase can not leverage Apache scope directives (Directory, Location, LocationMatch, etc...) as the post-read-request hook does not have this information yet. The exception here is the - VirtualHost directive. If you want to use ModSecurity rules inside Apache locations, - then they should run in Phase 2. Refer to the Apache Request - Cycle/ModSecurity Processing Phases - diagram. + VirtualHost directive. If you want to use ModSecurity rules inside + Apache locations, then they should run in Phase 2. Refer to the Apache + Request Cycle/ModSecurity Processing Phases diagram.
@@ -2458,8 +2411,8 @@ SecRule REQUEST_HEADERS:Host "!^$" "deny,phase:1"This is the general-purpose input analysis phase. Most of the application-oriented rules should go here. In this phase you are guaranteed to have received the request arguments (provided the request - body has been read). ModSecurity - supports three encoding types for the request body phase: + body has been read). ModSecurity supports three encoding types for the + request body phase: @@ -2515,16 +2468,14 @@ SecRule REQUEST_HEADERS:Host "!^$" "deny,phase:1"ModSecurity - 2.5.0 and later versions. + configuration error in ModSecurity 2.5.0 and later versions.
Variables - The following variables are supported in ModSecurity 2.x: + The following variables are supported in ModSecurity 2.x:
<literal moreinfo="none">ARGS</literal> @@ -2565,9 +2516,8 @@ SecRule REQUEST_HEADERS:Host "!^$" "deny,phase:1"Using ARGS:p will not result in any invocations against the operator if argument p does not exist. - In ModSecurity 1.X, the - ARGS variable stood for - QUERY_STRING + POST_PAYLOAD, + In ModSecurity 1.X, the ARGS variable stood + for QUERY_STRING + POST_PAYLOAD, whereas now it expands to individual variables.
@@ -2822,8 +2772,7 @@ SecRule TX:MYMATCH "@eq ARGS:param" deny
<literal moreinfo="none">MODSEC_BUILD</literal> - This variable holds the ModSecurity build number. This variable is + This variable holds the ModSecurity build number. This variable is intended to be used to check the build number prior to using a feature that is available only in a certain build. Example: @@ -2886,25 +2835,23 @@ LF %{MULTIPART_LF_LINE}, \ SM %{MULTIPART_SEMICOLON_MISSING}'" The multipart/form-data parser was upgraded in - ModSecurity v2.1.3 to actively look - for signs of evasion. Many variables (as listed above) were added to - expose various facts discovered during the parsing process. The - MULTIPART_STRICT_ERROR variable is handy to check on - all abnormalities at once. The individual variables allow detection to - be fine-tuned according to your circumstances in order to reduce the - number of false positives. Detailed analysis of various evasion - techniques covered will be released as a separated document at a later - date. + ModSecurity v2.1.3 to actively look for signs of evasion. Many variables + (as listed above) were added to expose various facts discovered during + the parsing process. The MULTIPART_STRICT_ERROR + variable is handy to check on all abnormalities at once. The individual + variables allow detection to be fine-tuned according to your + circumstances in order to reduce the number of false positives. Detailed + analysis of various evasion techniques covered will be released as a + separated document at a later date.
<literal>MULTIPART_UNMATCHED_BOUNDARY</literal> Set to 1 when, during the parsing phase of a - multipart/request-body, ModSecurity encounters what feels like a - boundary but it is not. Such an event may occur when evasion of - ModSecurity is attempted. + multipart/request-body, ModSecurity encounters what + feels like a boundary but it is not. Such an event may occur when + evasion of ModSecurity is attempted. The best way to use this variable is as in the example below: @@ -3014,11 +2961,11 @@ SecRule XML "@validateDTD /opt/apache-frontend/conf/xml.dtd" REQBODY_PROCESSOR_ERROR at the beginning of phase 2. Failure to do so will leave the door open for impedance mismatch attacks. It is possible, for example, that a payload that cannot be parsed by - ModSecurity can be successfully - parsed by more tolerant parser operating in the application. If your - policy dictates blocking then you should reject the request if error - is detected. When operating in detection-only mode your rule should - alert with high severity when request body processing fails. + ModSecurity can be successfully parsed by more tolerant parser + operating in the application. If your policy dictates blocking then + you should reject the request if error is detected. When operating in + detection-only mode your rule should alert with high severity when + request body processing fails.
@@ -3216,8 +3163,7 @@ SecRule XML "@validateDTD /opt/apache-frontend/conf/xml.dtd" embedded-mode. Headers such as Server, Date, Connection and Content-Type are added during a later Apache hook just prior to sending the data to the client. This data should be available, however, either during - ModSecurity phase:5 (logging) or - when running in proxy-mode. + ModSecurity phase:5 (logging) or when running in proxy-mode.
@@ -3661,22 +3607,19 @@ SecRule XML:/xq:employees/employee/name/text() Fred \
Transformation functions - When ModSecurity receives - request or response information, it makes a copy of this data and places - it into memory. It is on this data in memory that transformation functions - are applied. The raw request/response data is never altered. - Transformation functions are used to transform a variable before testing - it in a rule. + When ModSecurity receives request or response information, it makes + a copy of this data and places it into memory. It is on this data in + memory that transformation functions are applied. The raw request/response + data is never altered. Transformation functions are used to transform a + variable before testing it in a rule. Note There are no default transformation functions as there were in - previous versions of ModSecurity. + previous versions of ModSecurity. The following rule will ensure that an attacker does not use mixed - case in order to evade the ModSecurity rule: + case in order to evade the ModSecurity rule: SecRule ARG:p "xp_cmdshell" "t:lowercase" multiple transformation actions can be used in the same rule, for example @@ -3820,9 +3763,8 @@ SecRule XML:/xq:employees/employee/name/text() Fred \ <literal><literal>none</literal></literal> This not an actual transformation function but an instruction to - ModSecurity to remove all - transformation functions associated with the current rule and start from - scratch. + ModSecurity to remove all transformation functions associated with the + current rule and start from scratch.
@@ -3938,8 +3880,8 @@ SecRule XML:/xq:employees/employee/name/text() Fred \ Disruptive actions - are those actions - where ModSecurity will intercept - the data. They can only appear in the first rule in a chain. + where ModSecurity will intercept the data. They can only appear in the + first rule in a chain. @@ -3979,12 +3921,12 @@ SecRule XML:/xq:employees/employee/name/text() Fred \ SecRule REMOTE_ADDR "^192\.168\.1\.100$" nolog,phase:1,allow - Prior to ModSecurity 2.5 the - allow action would only affect the current phase. An - allow in phase 1 would skip processing the remaining - rules in phase 1 but the rules from phase 2 would execute. Starting with - v2.5.0 allow was enhanced to allow for fine-grained - control of what is done. The following rules now apply: + Prior to ModSecurity 2.5 the allow action would + only affect the current phase. An allow in phase 1 + would skip processing the remaining rules in phase 1 but the rules from + phase 2 would execute. Starting with v2.5.0 allow was + enhanced to allow for fine-grained control of what is done. The + following rules now apply: @@ -4080,8 +4022,7 @@ SecAction phase:3,allow reverted back to the previous SecDefaultAction disruptive action. - In future versions of ModSecurity, more control and functionality + In future versions of ModSecurity, more control and functionality will be added to define "how" to block. Examples: @@ -4235,18 +4176,16 @@ SecRule REQUEST_CONTENT_TYPE ^text/xml nolog,pass,ctl:requestBodyProce one configuration directive and the usage is identical. The requestBodyProcessor option allows you to configure the - request body processor. By default ModSecurity will use the URLENCODED and MULTIPART processors to process an application/x-www-form-urlencoded and a multipart/form-data body, respectively. A third processor, XML, is also supported, but it is never - used implicitly. Instead you must tell ModSecurity to use it by placing a few rules - in the REQUEST_HEADERS processing - phase. After the request body was processed as XML you will be able to - use the XML-related features to inspect it. + used implicitly. Instead you must tell ModSecurity to use it by placing + a few rules in the REQUEST_HEADERS + processing phase. After the request body was processed as XML you will + be able to use the XML-related features to inspect it. Request body processors will not interrupt a transaction if an error occurs during parsing. Instead they will set variablesexec:/usr/local/apache/conf/exec.luaModSecurity - will assume execution didn't work. + stdout. If it doesn't ModSecurity will assume execution didn't + work.
@@ -4527,13 +4466,12 @@ SecRule REQUEST_URI "^/cgi-bin/script\.pl" \ - Please note that ModSecurity does not implement atomic - updates of persistent variables at this time. Variables are read from - storage whenever initcol is encountered in the - rules and persisted at the end of request processing. On busy servers - requests often run in parallel, leading to situations where one - request overwrites the changes made by another request. We anticipate + Please note that ModSecurity does not implement atomic updates + of persistent variables at this time. Variables are read from storage + whenever initcol is encountered in the rules and + persisted at the end of request processing. On busy servers requests + often run in parallel, leading to situations where one request + overwrites the changes made by another request. We anticipate implementing atomic updates of counter values in a future version. @@ -4554,7 +4492,7 @@ SecRule REQUEST_URI "^/cgi-bin/script\.pl" \ Note This action will log matches to the Apache error log file and the - ModSecurity audit log. + ModSecurity audit log.
@@ -4600,10 +4538,9 @@ SecRule REQUEST_URI "^/cgi-bin/script\.pl" \
<literal>multiMatch</literal> - Description: If enabled ModSecurity will perform multiple operator - invocations for every target, before and after every anti-evasion - transformation is performed. + Description: If enabled ModSecurity will + perform multiple operator invocations for every target, before and after + every anti-evasion transformation is performed. Action Group: Non-Disruptive @@ -4669,14 +4606,26 @@ SecRule ARGS "attack" multiMatch Action Group: Disruptive - Example: + Example1: SecRule REQUEST_HEADERS:User-Agent "Test" log,pass + When using pass with SecRule with multiple + targets, all targets will be processed and + all non-disruptive actions will trigger for + every match found. In the second example the + TX:test target would be incremented by 1 for each matching + argument. + + Example2: + + SecRule ARGS "test" log,pass,setvar:TX.test=+1 + Note - Transaction will not be interrupted but it will be logged (unless - logging has been suppressed). + The transaction will not be interrupted but a log will be + generated for each matching target (unless logging has been + suppressed).
@@ -4892,8 +4841,7 @@ SecRule REQUEST_HEADERS:User-Agent "Test" log,deny,status:403 Note - Severity values in ModSecurity follow those of syslog, as + Severity values in ModSecurity follow those of syslog, as below: @@ -5284,7 +5232,7 @@ SecRule ARGS:route "!@endsWith %{REQUEST_ADDR}" t:none,deny configuration file resides. Also as of v2.5.0, if the filename is determined to be a Lua script (based on its extension) the script will be processed by the internal engine. As such it will have full access to - the ModSecurity context. + the ModSecurity context. Example of using an external binary/script: @@ -5413,9 +5361,8 @@ end Note Regular expressions are handled by the PCRE library (http://www.pcre.org). ModSecurity compiles its regular expressions - with the following settings: + url="http://www.pcre.org">http://www.pcre.org). ModSecurity + compiles its regular expressions with the following settings: @@ -5478,10 +5425,9 @@ SecRule REQUEST_HEADERS:Ip-Address "!@streq %{TX.1}" - validateByteRange is similar to the ModSecurity 1.X SecFilterForceByteRange - Directive however since it works in a rule context, it has the following - differences: + validateByteRange is similar to the ModSecurity 1.X + SecFilterForceByteRange Directive however since it works in a rule + context, it has the following differences: @@ -5573,8 +5519,8 @@ SecRule XML "@validateSchema /path/to/apache2/conf/xml.xsd, Not enough bytes. UTF-8 supports two, three, four, five, and - six byte encodings. ModSecurity - will locate cases when a byte or more is missing. + six byte encodings. ModSecurity will locate cases when a byte or + more is missing. @@ -5631,14 +5577,13 @@ SecRule REQUEST_METHOD "!@within %{tx.allowed_methods}" t:l
Data Formats - This section documents the various data formats used by ModSecurity. + This section documents the various data formats used by + ModSecurity.
Alerts - Below is an example of a ModSecurity alert entry. It is always + Below is an example of a ModSecurity alert entry. It is always contained on a single line but we've broken it here into multiple lines for readability. @@ -5653,10 +5598,10 @@ is not allowed by policy"] [severity "CRITICAL"] [uri "/"] [unique_id against "REQUEST_PROTOCOL" required. The engine message consists of two parts. The first part tells you - whether ModSecurity acted to - interrupt transaction or rule processing. If it did nothing the first - part of the message will simply say "Warning". If an action was taken - then one of the following messages will be used: + whether ModSecurity acted to interrupt transaction or rule processing. + If it did nothing the first part of the message will simply say + "Warning". If an action was taken then one of the following messages + will be used: @@ -5900,19 +5845,16 @@ against "REQUEST_PROTOCOL" required.
Alerts in Apache - Every ModSecurity alert - conforms to the following format when it appears in the Apache error - log: + Every ModSecurity alert conforms to the following format when it + appears in the Apache error log: - [Sun Jun 24 10:19:58 2007] [error] [client 192.168.0.1] ModSecurity: ALERT_MESSAGE + [Sun Jun 24 10:19:58 2007] [error] [client 192.168.0.1] + ModSecurity: ALERT_MESSAGE - The above is a standard Apache error log format. The "ModSecurity:" prefix is specific to - ModSecurity. It is used to allow - quick identification of ModSecurity alert messages when they appear - in the same file next to other Apache messages. + The above is a standard Apache error log format. The " + ModSecurity:" prefix is specific to ModSecurity. It is used to allow + quick identification of ModSecurity alert messages when they appear in + the same file next to other Apache messages. The actual message (ALERT_MESSAGE in the example above) is in the same format as described in the @@ -5923,10 +5865,9 @@ against "REQUEST_PROTOCOL" required. Alerts in Audit Log Alerts are transported in the H section of - the ModSecurity Audit Log. Alerts - will appear each on a separate line and in the order they were - generated by ModSecurity. Each - line will be in the following format: + the ModSecurity Audit Log. Alerts will appear each on a separate line + and in the order they were generated by ModSecurity. Each line will be + in the following format: Message: ALERT_MESSAGE @@ -5941,7 +5882,7 @@ Message: Warning. Pattern match "(?:\\b(?:(?:s(?:elect\\b(?:.{1,100}?\\b(?:(?:le (?:(?:addextendedpro|sqlexe)c|(?:oacreat|prepar)e|execute(?:sql)?|makewebt ..." at ARGS:c. [id "950001"] [msg "SQL Injection Attack. Matched signature: union select"] [severity "CRITICAL"] Stopwatch: 1199881676978327 2514 (396 2224 -) -Producer: ModSecurity v2.x.x (Apache 2.x) +Producer: ModSecurity v2.x.x (Apache 2.x) Server: Apache/2.x.x --c7036611-Z-- @@ -5951,8 +5892,8 @@ Server: Apache/2.x.x
Audit Log - ModSecurity records one - transaction in a single audit log file. Below is an example: + ModSecurity records one transaction in a single audit log file. + Below is an example: --c7036611-A-- [09/Jan/2008:12:27:56 +0000] OSD4l1BEUOkAAHZ8Y3QAAAAH 209.90.77.54 64995 80.68.80.233 80 @@ -5982,7 +5923,7 @@ Message: Warning. Pattern match "(?:\\b(?:(?:s(?:elect\\b(?:.{1,100}?\\b(?:(?:le Apache-Error: [file "/tmp/buildd/apache2-2.x.x/build-tree/apache2/server/core.c"] [line 3505] [level 3] File does not exist: /var/www/EvilBoard_0.1a Stopwatch: 1199881676978327 2514 (396 2224 -) -Producer: ModSecurity v2.x.x (Apache 2.x) +Producer: ModSecurity v2.x.x (Apache 2.x) Server: Apache/2.x.x --c7036611-Z-- @@ -6047,17 +5988,15 @@ Server: Apache/2.x.x This problem is better known as Impedance Mismatch. It can be exploited to evade the security devices. - While we will continue to enhance ModSecurity to deal with various evasion - techniques the problem can only be minimized, but never solved. With so - many different application backend chances are some will always do - something completely unexpected. The only solution is to be aware of the - technologies in the backend when writing rules, adapting the rules to - remove the mismatch. See the next section for some examples. + While we will continue to enhance ModSecurity to deal with various + evasion techniques the problem can only be minimized, but never solved. + With so many different application backend chances are some will always + do something completely unexpected. The only solution is to be aware of + the technologies in the backend when writing rules, adapting the rules + to remove the mismatch. See the next section for some examples.
- PHP Peculiarities for <trademark - class="trade">ModSecurity</trademark> Users + PHP Peculiarities for ModSecurity Users When writing rules to protect PHP applications you need to pay attention to the following facts: @@ -6126,4 +6065,4 @@ Server: Apache/2.x.x
-
\ No newline at end of file +