Re: Trying out "early blocking"

Hi CM,


On Thu, May 08, 2025 at 09:45:48PM +0000, CM via mod-security-users wrote:
> I am testing out the latest CRS 4.14 because I was interested in the "early blocking" feature
> 
> I am using Ubuntu 24.04 using its libapache2-mod-security2 package (version 2.9.7-1build3)
> 
> I believe this version of modsecurity should be sufficient for running the latest CRS, however, I get various strange behaviors when turning on early blocking.
> 
> As I understand it, modsecurity has a "--enable-request-early" compile flag that needs to be turned on, however, I'm not sure how to tell if my mod_security2.so was compiled with this option or not.

If you take a look at the module's configure script, you can
check how it works:

https://github.com/owasp-modsecurity/ModSecurity/blob/v2.9.7/configure.ac#L412-L426

# Enable phase-1 in post_read_request
AC_ARG_ENABLE(request-early,
              AS_HELP_STRING([--enable-request-early],
                             [Place phase1 into post_read_request hook. default is hook_request_early]),
[
  if test "$enableval" != "no"; then
    request_early="-DREQUEST_EARLY"
    MODSEC_EXTRA_CFLAGS="$MODSEC_EXTRA_CFLAGS $request_early"
  else
    request_early=
  fi
],
[
  request_early='-DREQUEST_EARLY'
])

This means if you pass `--enable-request-early=no` (which is
equivalent with `--disable-request-early`), then you explicitly
DISABLE this feature. The default is on.

(Btw I've nver used this option, and now I checked my generated
Makefile, it contains this macro:

$ grep -rI REQUEST_EARLY *
apache2/Makefile:MODSEC_APXS_EXTRA_CFLAGS = -Wc,-DWITH_PCRE_STUDY ... -DREQUEST_EARLY
)


> My hypothesis is that because Ubuntu does not ship CRS 4.x yet, they might be compiling modsecurity with this functionality disabled.
> 
> I had an idea to try the libapache2-mod-security2 package from Ubuntu 25.04 (which would give me 2.9.8) however I haven't done so yet.
> 
> Is there a way to examine my mod_security2.so to determine if it was compiled with early blocking support or not?

You can check the package build flags - I can't link that
directly, but here is the package's debian/ directory:

http://archive.ubuntu.com/ubuntu/pool/universe/m/modsecurity-apache/modsecurity-apache_2.9.7-1build3.debian.tar.xz

After you download and unpack it, you can see the debian/rules
file:

16 build-stamp:
17 	dh_testdir
18 	dh_autoreconf
19 	./configure --prefix=/usr --with-apxs=/usr/bin/apxs2 --with-apr=/usr/bin/apr-config --with-lua=/usr/include/lua5.1 --with-pcre2 --enable-pcre-jit --enable-pcre-study CPPFLAGS='$(CPPFLAGS)' CFLAGS='$(CFLAGS)' LDFLAGS='$(LDFLAGS)'

As you can see there are no --enable-request-early=no nor
--disable-request-early flags.

> Here are some of the odd behaviors I'm encountering:
> 
> -  With early blocking enabled, requests that trigger an Apache redirect still get redirected, even though the audit log shows that they should have been blocked:
> 
> --992be21d-F--
> HTTP/1.1 308 Permanent Redirect
> ...
> --992be21d-H--
> Message: Access denied with code 403 (phase 1). [file "/usr/local/coreruleset/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "221"] [id "949111"] [msg "Inbound Anomaly Score Exceeded in phase 1 (Total Score: 12)"] [ver "OWASP_CRS/4.14.0"] [tag "anomaly-evaluation"] [tag "OWASP_CRS"]Action: Intercepted (phase 1)
> 
> -  If I try to update rule 949111 to do anything other than a 403, then that action gets applied to ALL requests, not just blocks,
> 
> for example with this:
> 
> SecRuleUpdateActionById 949111 "status:404"
> 
> then even requests with an anomaly score of ZERO get blocked:
> 
> Message: Access denied with code 404 (phase 1). [file "/usr/local/coreruleset/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "221"] [id "949111"] [msg "Inbound Anomaly Score Exceeded in phase 1 (Total Score: 0)"] [ver "OWASP_CRS/4.14.0"] [tag "anomaly-evaluation"] [tag "OWASP_CRS"]
> 
> but if I don't modify 949111, then this doesn't happen

I can take a look at this later.



a.
 


_______________________________________________
mod-security-users mailing list
[email protected]
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/