Re: [mod-security-users] Trying out "early blocking"

[CM <ne...@pr...>]

I tried a couple other builds of mod_security2.so (2.9.8 from Ubuntu 25.04, and a couple of Debian versions), with exactly the same results, and then I compiled my own 2.9.8, still with the same results, so I guess I was barking up the wrong tree.

Next line of thought, is there a minimum Apache version to properly handle the early blocking feature?

I am running Apache 2.4.58-1ubuntu8.6 so it's not too old

or is there any specific Apache-side configuration that has to be added in order for early blocking to function properly, outside of the modsecurity/CRS configs?


Sent with Proton Mail secure email.

On Friday, May 9th, 2025 at 2:31 AM, Ervin Hegedüs <ai...@gm...> wrote:

> 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.