1.689 Modsecurity - can we please have inheritance back?

S

Selcal

New member
Joined
Nov 10, 2025
Messages
5
Hi all,

So, since 1.689 Modsecurity is now non-inherited, only configured per subdomains, or using global configuration.

Am I correct in that there is no way to get the previous behaviour back?
I host for several users, several domains which each have many subdomains.

The current setup doesn't allow me as administrator nor users at their level to easily view all blocked requests, as we now have to go through each and every subdomain manually. At least, I can't find a way to see the combined log in DA now?

Configuring exceptions is the same problem...
Using global configuration is not appropriate here as the rule exceptions vary per services which are each on a domain. So before, the exceptions were set per domain.
Now, it means having to go through the separate config for each and every subdomain to set the same config.

Of course, a bash script can sync the settings but I love the beauty of working in the GUI.

Am I misunderstanding how to use the new setup? Or is the use case of my users (exceptions per domain, with many subdomains per domain) that exceptional?
I'm just posting this here, as I've found usually changes work well (even if change is hard to deal with for the human brain ;) ), but in this case it's really broken the workflow on my server and I wonder what I'm missing.

Thanks!
 
Hi @Selcal. Thanks for the feedback.

Here is the key reasons for removing the domain to subdomain modsecurity configuration inheritance.

The web applications hosted on main domain and subdomains are usually completely different systems. For example main domain can host a company website. Subdomains could be used for internal CRMs, wiki, forum, e-shop, hobby projects, etc. Fine tuning ModSecurity rule exceptions is targeting a specific software that might actually use requests that look like hacking attempts.

If the subdomain runs a different software that is used on main domain or other subdomains and we use configuration inheritance it means that:
  • It can inherit rule exceptions that are not applicable to it (maybe it was added for software on main domain).
  • It can require extra rule exceptions that will be on the main domain even if main domain or other subdomains does not really need it.
The second reason for removing the inheritance is to make the whole configuration easier to understand.

Imagine the following situation, user have two domains with two subdomains each:
  • domain example.com (uses server default modsecurity configuration, admin disabled 2 common modsecurity false positive rules)
  • domain example.org (has 5 modsecurity rules disabled)
  • subdomain sub1.example.org (uses default configuration, inherited from main domain)
  • subdomain sub2.example.org (has 3 modsecurity rules disabled)
The configuration for `example.com` and for `sub1.example.org` looks identical. Both has no configuration, but first uses 2 excluded rules, while the second uses 5 excluded rules inherited from domain.

If you know exactly how many levels of inheritance is there and how they interact it is understandable. But if you are not aware of it then it might extremely hard to understand why identically looking configuration are behaving differently.
We are not eliminating inheritance completely. The server administrator can provide good server default configuration so that users would not need to bother with modsec configuration at all. However, if user does want to change it, we think the best way is to treat all domains and subdomains as different web applications with different configuration. That is why we use term hostname in the modsecurity pages. The hostname can mean either domain or a subdomain.
If you are adding modsecurity exceptions as server administrator I would recommend adding them to the global modsecurity configuration. It would get applied for all users and all domains and all subdomains that have not customised the modsecurity configuration.
 
Thanks for the reply -- indeed I can follow the thinking even though in my use case it has certainly made management harder. Global configuration is not appropriate as different users need different rules for specific domains and all their subdomains. In this case, things have become more complicated and will pretty much need to go through a ticket so I can copy the rules to all subdomains.

Anyway, I can see the thinking and if my use case is a minority the change is understandable. I also like the update to the name for user level, it is more understandable.

For any future update, I would really faviour, at least, to have a way for the administrator level to see the modsecurity log combined? As opposed to per (sub)domain separate (which has many use-cases as well, for sure, so I like having that option).

Anyway thanks for the information!
 
The global ModSec log is still available, but a bit hard to find in the latest release. Go to Admin level -> Server Manager -> ModSecurity -> Global Configuration (button on the page) -> Full audit log (button that does not look like button). We are planning to make it more easily accessible in the upcoming releases.

1763571033102.png


The full log will include everything (blocked request to non-existing domains, server hostname, requests to literal server IP address, etc.).
 
Personally, I think the inheritance feature being deprecated/removed isn't a bad idea. It helps a lot with certain setups as you've mentioned above. For example, on one server I have various software in different subdomains that have different needs and OWASP can be very aggressive at times. Being able to fine tune different pieces of software at different levels does help me now and i'll be looking into this in a bit, although I do understand others who may have to go in now and sort out their settings that just "worked" with inherited security rules.

As with any change you make to DA, you're not going to please everyone as control panels aren't a one size fits all setup, along with client's software they use. I haven't liked some changes in the past, but have welcomed others. In short, all I ask for in a panel is a community driven model, that is safe, and above all secure. Stale projects can quickly fall behind and develop security holes. I'm glad DA is constantly evolving
 
fln said:
The global ModSec log is still available, but a bit hard to find in the latest release. Go to Admin level -> Server Manager -> ModSecurity -> Global Configuration (button on the page) -> Full audit log (button that does not look like button). We are planning to make it more easily accessible in the upcoming releases.

View attachment 9476

The full log will include everything (blocked request to non-existing domains, server hostname, requests to literal server IP address, etc.).
Click to expand...
Great, thanks for that!

@DrWizzle , fully agree!
Drifting on the topic, but we did have the possibility to tune per subdomain before? At least, I could always select a subdomain specifically, I thought it allowed subdomain specific tuning. It was with this in mind that I was surprised at the current change.
If before it was only per domain, and now per subdomain, certainly makes the change more understandable as it's just a choice of one or the other use case.
Of course, as always and everywhere, you'll get people like me that want both 😜.

But as I said before, I appreciate choices have to be made and I agree overall DA gets better over time, not worse!
 
You must log in or register to reply here.
Back
Top