mod_http2 prevents "drop" action working in ModSecurity

[tunetheweb]

Just experienced this issue today on ModSecurity, where drop option does not work and wondering if you can help identify the cause, since it works fine on HTTP/1.1?

Background: ModSecurity is a WAF module which allows you to write rules to block access to a resource depending on attributes of the request (i.e. if you send some parameters that look suspicious it will intercept and block you with a 403 or 500). A more forceful option is to completely drop the connection if you are really, really sure the request is illegitimate and don't want to waste resources (e.g. serving up an error page).

For example the following rule will drop any requests for page requests beginning with /wp- if you don't use WordPress and are fed up with all the bots scanning your site for WordPress vulnerabilities clouding your logs with useless 404s:

SecRule REQUEST_URI /wp- "phase:1,id:1000,drop"

Issue: the drop option works on Apache on Linux (note not on Windows), under HTTP/1.1 but stops working when using HTTP/2 - when it reverts to a deny so the access is still blocked with a 403 (so still solves my 404 issue but not what was asked in config).

Here's the ModSecurity code to handle the drop (also opensource hence why comfortable posting here):

        case ACTION_DROP :
            /* ENH This does not seem to work on Windows. Is there a
             *     better way to drop a connection anyway?
             */
            #if !defined(WIN32) && !defined(VERSION_NGINX)
            {
                extern module core_module;
                apr_socket_t *csd = ap_get_module_config(msr->r->connection->conn_config,
                    &core_module);

                if (csd) {
                    if (apr_socket_close(csd) == APR_SUCCESS) {
                        status = HTTP_FORBIDDEN;
                        message = apr_psprintf(msr->mp, "Access denied with connection close%s.",
                            phase_text);
                    }

Any ideas why this would not work under HTTP/2? Note it DOES return APR_SUCCESS as does execute this piece of code, rather than the else loop I've not shown, but doesn't seem to actually drop the connection as it returns a 403 and the error page and resources instead of abruptly ending the connection like under HTTP/1.1.

Any hints as to what should be used rather than apr_socket_close for HTTP/2 connections to have the same effect? Will happily try a few changes to ModSecurity and feed back a fix to them if you can give me a steer in the right direction...

I attach some trace level logs for mod_http2 if that helps at all:
mod_http2_debug_log.txt

Thanks,
Barry

[covener]

For h2, the conn_rec is kind of virtualized. Could you try testing if c->master is non-null and using c->master->c to get the core module config / csd instead?

[tunetheweb]

This seems to work a treat for both HTTP/1.1 and HTTP/2 if that's what you meant:

                apr_socket_t *csd;

                /* For HTTP/2 there is a virtual connection so must go through
                 * master to get the main connection.
                 * For HTTP/1.1 master will not be defined so just go through
                 * Normal connection
                 */
                if (msr->r->connection->master) {
                        csd = ap_get_module_config(msr->r->connection->master->conn_config,&core_module);
                } else {
                        csd = ap_get_module_config(msr->r->connection->conn_config,&core_module);
                }

Pardon my C if I got any of the pointer assignments wrong, as been 20 odd years since I coded in it! But seems to work.

Thanks will suggest to ModSecurity team.

Thanks,
Barry

[covener]

looks reasonable, my shorthand was not so close!

[icing]

Wow, issues are now resolved in my sleep!