Bug#1108728: (No Subject)
reassign 1108728 modsecurity-crs retitle 1108728 owasp-crs.load overwritten during trixie upgrade, causing dependency loop affects 1108728 nginx libnginx-mod-http-ndk libnginx-mod-http-modsecurity thanks
Bug#1108728: (No Subject)
Hi Ervin, > > If this is what happened, I propose /usr/share is a poor location for > > the config file and owasp-crs.load should be located in /etc so that > > dpkg/apt can detect changes in the future. Otherwise it is sure to > > break everytime the package is updated (if running nginx). > > > yes. Let us figure out how can we solve this. > Thank you for the detailed explanations. If you agree there is a bug here, and I do think so based on the upgrade breakage, I propose the following which could be a low-impact quick fix to prevent future upgrade issues: The fix does not modify any source files in the upstream at all, but rather the way the Debian package is built. When I examine the package for modsecurity-crs, it declares the following as conffiles in the control archive: /etc/modsecurity/crs/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf /etc/modsecurity/crs/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf /etc/modsecurity/crs/crs-setup.conf When owasp-crs.load was added to the mix at some point, it never got added to the conffiles. From looking at the git repo, I don't see conffiles for this package explicitly declared anywhere. So I assume there is an auto- generation happening here, based on package files copied into /etc. Since the owasp-crs.load file is placed in /usr/share, the package build scripts ignore it and it never gets added - so every upgrade of the package, this file will get clobbered, even if it was modified by the user. I think if we added owasp-crs.load to the list as a conffile declaration the user will get an interactive prompt during package upgrade if the file is modified (and it surely will if using it in the scenario we discussed). Regards Lloyd
Bug#1108728: (No Subject)
On Fri, Jul 04, 2025 at 09:42:51PM +, Lloyd wrote: > Hi Ervin, please bear with me as it has been quite some time since I > set up modsecurity on this box and am not an expert. apologize if it seemed like I wasn't patient. I think I can say usually I am :) > I have attempted to reconstruct the events during the upgrade. > > My understanding is the "IncludeOptional" in the default owasp-crs.load > is not compatible with nginx. yes, exactly. Just one small correction: it's not an Nginx directive in this case, but a rule set directive. That's the libary's task, not the engine's (Nginx) task. > It's likely that I removed this reference > ages ago to get things working. However, with the file now having been > overwritten, it's impossible to know for sure. You're right, this is a bit weird situation. The "explanation" is simple: modsecurity-crs was made for Apache (for libapache2-mod-security), and the whole SecLang syntax was build on top of Apache configuration syntax. The library (libmodsecurity3) must have to understand this syntax, and there are some missing keywords - like "IncludeOptional". > During the upgrade from bookworm -> trixie, modsecurity-crs package was > updated from version 3.3.4 to 3.3.7: > > Preparing to unpack .../132-modsecurity-crs_3.3.7-1_all.deb ... > Unpacking modsecurity-crs (3.3.7-1) over (3.3.4-1) ... yes, this was my feeling. > During the upgrade I received a prompt due to file > /etc/modsecurity/crs/crs-setup.conf being modified by me: > > Setting up modsecurity-crs (3.3.7-1) ... > Installing new version of config file > /etc/modsecurity/crs/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf ... > Installing new version of config file > /etc/modsecurity/crs/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf ... probably because those are user maintained files. > Note I received no warning that /usr/share/modsecurity-crs/owasp-crs.load > was modified! I speculate this is because the file is located in /usr that > dpkg/apt simply overwrote my changes with the new package version. > Thus reverting any removal of the IncludeOptional that may have been there. probably yes. > If this is what happened, I propose /usr/share is a poor location for > the config file and owasp-crs.load should be located in /etc so that > dpkg/apt can detect changes in the future. Otherwise it is sure to > break everytime the package is updated (if running nginx). yes. Let us figure out how can we solve this. A side note: even the CRS 3.3 is still maintained, if someone has a new instance, I recommend to use CRS4. CRS4 does not have package in Debian yet, but the (CRS) team decided that they change the versioning: we don't increase patch level, only the minor version (excpet if it's really necessary - but since the change we have never used this). So the releases are 4.0.0, 4.1.0, ... 4.16.0. Almost in every month the team releses a new version, so actually I don't know how can we handle this in Debian. Moreover, the "product's" name also changed: it's not "modsecurity-crs" anymore, but just simple CRS or CRS4. Also: if you already use CRS 3.3, then I don't suggest to switch to CRS4, except if you have strong skills to review the rules and existing exclusions. Regards, a.
Bug#1108728: (No Subject)
Ervin Hegedüs wrote: > The problem is that libmodsecurity3 (the WAF library that Nginx > uses via libngnx-mod-http-modsecurity module) does not support > `IncludeOptional` directive. > > If someone install the package first, this issue comes always. > > Now you upgraded the system, and you upgraded modsecurity-crs > package too - which overrided your `Include` directive (I guess). > > I think we should replace the mentioned `IncludeOptional` > directive with the `Include`. Hi Ervin, please bear with me as it has been quite some time since I set up modsecurity on this box and am not an expert. I have attempted to reconstruct the events during the upgrade. My understanding is the "IncludeOptional" in the default owasp-crs.load is not compatible with nginx. It's likely that I removed this reference ages ago to get things working. However, with the file now having been overwritten, it's impossible to know for sure. During the upgrade from bookworm -> trixie, modsecurity-crs package was updated from version 3.3.4 to 3.3.7: Preparing to unpack .../132-modsecurity-crs_3.3.7-1_all.deb ... Unpacking modsecurity-crs (3.3.7-1) over (3.3.4-1) ... During the upgrade I received a prompt due to file /etc/modsecurity/crs/crs-setup.conf being modified by me: Setting up modsecurity-crs (3.3.7-1) ... Installing new version of config file /etc/modsecurity/crs/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf ... Installing new version of config file /etc/modsecurity/crs/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf ... Configuration file '/etc/modsecurity/crs/crs-setup.conf' ==> Modified (by you or by a script) since installation. ==> Package distributor has shipped an updated version. What would you like to do about it ? Your options are: Y or I : install the package maintainer's version N or O : keep your currently-installed version D : show the differences between the versions Z : start a shell to examine the situation The default action is to keep your current version. *** crs-setup.conf (Y/I/N/O/D/Z) [default=N] ? Setting up libldap-common (2.6.10+dfsg-1) ... Installing new version of config file /etc/ldap/ldap.conf ... Note I received no warning that /usr/share/modsecurity-crs/owasp-crs.load was modified! I speculate this is because the file is located in /usr that dpkg/apt simply overwrote my changes with the new package version. Thus reverting any removal of the IncludeOptional that may have been there. If this is what happened, I propose /usr/share is a poor location for the config file and owasp-crs.load should be located in /etc so that dpkg/apt can detect changes in the future. Otherwise it is sure to break everytime the package is updated (if running nginx). Regards Lloyd
Bug#1108728: (No Subject)
Hi, On Fri, Jul 04, 2025 at 07:11:52PM +, Lloyd wrote: > I gave this some fresh thought and I now suspect the root cause lies within > the modsecurity-crs package, which ironically is not mentioned anywhere in > the error messages. This may provide some important missing context. > > Once modsecurity was disabled and I was successfully able to reinstall all > the packages, I had to remove the following two offending lines from > /usr/share/modsecurity-crs/owasp-crs.load before nginx would start: > > IncludeOptional > /etc/modsecurity/crs/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf > > IncludeOptional > /etc/modsecurity/crs/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf > > I now suspect this issue may have cascaded and caused the error messages > which blocked the package upgrades. this is a very important information. After the first mail with this issue I thought the bug appears because of the OS upgrade. And yes, now I'm sure the reason is that - but not because of the connector. The problem is that libmodsecurity3 (the WAF library that Nginx uses via libngnx-mod-http-modsecurity module) does not support `IncludeOptional` directive. If someone install the package first, this issue comes always. Now you upgraded the system, and you upgraded modsecurity-crs package too - which overrided your `Include` directive (I guess). I think we should replace the mentioned `IncludeOptional` directive with the `Include`. a.
Bug#1108728: (No Subject)
I gave this some fresh thought and I now suspect the root cause lies within the modsecurity-crs package, which ironically is not mentioned anywhere in the error messages. This may provide some important missing context. Once modsecurity was disabled and I was successfully able to reinstall all the packages, I had to remove the following two offending lines from /usr/share/modsecurity-crs/owasp-crs.load before nginx would start: IncludeOptional /etc/modsecurity/crs/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf IncludeOptional /etc/modsecurity/crs/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf I now suspect this issue may have cascaded and caused the error messages which blocked the package upgrades.
