mod_security update replaced 00_mod_security.conf
Posted: Wed Jul 02, 2014 4:57 pm
Why did the update (downgrade to 2.7.x) from 2.8 that occurred last night replace the Apache 00_mod_security.conf file? 2 bad things occurred as a result of the upgrade (Jul 01 13:53:28 Updated: mod_security.i386 1:2.8.0-24.el5.art).
The problem first was that Apache failed to restart after the mod_sec update. This happened because we updated the tortix_waf.conf file when Atomic released the update to 2.8 on June 19th. mod_sec 2.8 renamed "SecReadStateLimit" to "SecConnReadStateLimit " and would display an error each time Apache was restarted as a result.
The second problem was that the RPM replaced my customized 00_mod_security.conf file with a version that broke my configuration. The version installed loaded all the rules, of which we only use a subset, which caused mod_sec to fail to load because of missing files. For example the rule 01_asl_domain_blocks requires the file "/etc/asl/custom-domain-blocks" to exist.
The first problem was partially self inflicted. We did what any good admin would do and updated the config to match the current directive name. There's very little reason to believe you would ever regress to a previous version of the application. But the second issue should never have occurred. The update to 2.8 didn't replace the config file so why did the update back to 2.7 replace the file? The file we have in place was modified from the original mod_sec rpm we installed from the Atomic repo so if the new 2.7 based mod_sec RPM was built correctly it should have been able to determine that and should have left the file in place. I suspect the new 2.7 based RPM included a completely new version 00_mod_security.conf which would (given RPM rules) replace the existing file. That may have been fine for ASL subscribers but for rules only guys like me it broke Apache. What do I need to do to ensure my 00_mod_security.conf isn't replaced by future mod_sec updates?
The problem first was that Apache failed to restart after the mod_sec update. This happened because we updated the tortix_waf.conf file when Atomic released the update to 2.8 on June 19th. mod_sec 2.8 renamed "SecReadStateLimit" to "SecConnReadStateLimit " and would display an error each time Apache was restarted as a result.
The second problem was that the RPM replaced my customized 00_mod_security.conf file with a version that broke my configuration. The version installed loaded all the rules, of which we only use a subset, which caused mod_sec to fail to load because of missing files. For example the rule 01_asl_domain_blocks requires the file "/etc/asl/custom-domain-blocks" to exist.
The first problem was partially self inflicted. We did what any good admin would do and updated the config to match the current directive name. There's very little reason to believe you would ever regress to a previous version of the application. But the second issue should never have occurred. The update to 2.8 didn't replace the config file so why did the update back to 2.7 replace the file? The file we have in place was modified from the original mod_sec rpm we installed from the Atomic repo so if the new 2.7 based mod_sec RPM was built correctly it should have been able to determine that and should have left the file in place. I suspect the new 2.7 based RPM included a completely new version 00_mod_security.conf which would (given RPM rules) replace the existing file. That may have been fine for ASL subscribers but for rules only guys like me it broke Apache. What do I need to do to ensure my 00_mod_security.conf isn't replaced by future mod_sec updates?