ModSecurity Nginx 自定义禁止页面 + 日志 ID

Question

We are running the latest Nginx and Modsecurity, everything is working as expected, but we would like to be able to have a custom forbidden page (not the default 403) but that also includes the log ID, so in case a customer is getting denied, they could open a ticket with the support team and add the ID they got, so it will be easier for us to track in the log.

Answer 1

ModSecurity Core Rule Set Developer on Duty here. It may be possible, and potentially simplest, to configure Nginx with custom behaviour/pages when handling a 403 Forbidden response. I'm not an Nginx expert, so I can't comment on precisely how you would do this.

The alternative is to replace your usage of ModSecurity's deny action with the redirect action. Instead of responding to a blocking event with a simple 403 Forbidden status code you would instead perform a redirect to a location of your choosing. You can include the unique ID as a query string parameter, like so:

redirect:https://mysite.tld/blocked.html?uid=%{UNIQUE_ID}

If you're using the Core Rule set then the rule you want to look at is 949110, the inbound blocking rule. (If you're also inspecting response data then you'll also want to look at the outbound blocking rule, too.)

Below is something you could test and get started with. It amends the inbound blocking rule to redirect clients to Google, with the search parameter being the unique ID (so you can easily see this idea in action). It would need to be placed after your CRS includes, as it makes use of a configure-time rule modification: you can only modify a rule if it's already been defined.

# CRS Rule Modification: 949110 - Inbound Anomaly Score Exceeded
#
# When a request meets or exceeds the inbound anomaly score threshold, rather
# than replying with a 403 Forbidden status code, perform a redirect to send the
# client to a pre-determined location.
#
# The redirect URL includes the unique ID of the transaction as a parameter. If
# the redirect location is set up to do so, the unique ID can be displayed to
# the client in a friendly message, e.g. "Something's gone wrong. Please contact
# support@example.com quoting ID <ID_GOES_HERE>." As the unique ID appears in
# the logs it can be used to identify the log lines associated to a specific
# client's blocking event.
SecRuleUpdateActionById 949110 "redirect:https://www.google.com/search?q=%{UNIQUE_ID}"