Hide Forgot
Description of problem: mod_security-2.5.10-1 has moved and removed some rulesets but the /etc/http/conf.d/mod_security.conf file was not updated to reflect these changes resulting in http failing to start the next time it is restarted. The moving and removal of the rulesets seems to be completely arbitrary and this package has clearly had no testing done. Version-Release number of selected component (if applicable): mod_security-2.5.10-1 How reproducible: Everytime. Tested it on a brand new sandbox vm to ensure my production webhosting setup was not at fault. Steps to Reproduce: 1. Install mod_security-2.5.10-1 or yum update to it and restart httpd 2. HTTP will fail to restart with error such as: Stopping httpd: [ OK ] Starting httpd: httpd: Syntax error on line 207 of /etc/httpd/conf/httpd.conf: Syntax error on line 14 of /etc/httpd/conf.d/mod_security.conf: Could not open configuration file /etc/httpd/modsecurity.d/modsecurity_crs_20_protocol_violations.conf: No such file or directory [FAILED] 3. Going checking for files and find some of them have been moved and some have plain gone. Actual results: http refuses to start Expected results: Config file pointing to correct files allow httpd to start in the default configuration Additional info: I did additional checks between mod_security-2.5.9-1 and mod_security-2.5.10-1 The mod_security.conf file does not diff between the two and has remained untouched. The rulesets however have been drastically changed: [root@firefly conf.d]# rpm -q mod_security mod_security-2.5.9-1.fc11.x86_64 root@firefly conf.d]# rpm -ql mod_security /etc/httpd/conf.d/mod_security.conf /etc/httpd/modsecurity.d /etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf /etc/httpd/modsecurity.d/modsecurity_crs_20_protocol_violations.conf /etc/httpd/modsecurity.d/modsecurity_crs_21_protocol_anomalies.conf /etc/httpd/modsecurity.d/modsecurity_crs_23_request_limits.conf /etc/httpd/modsecurity.d/modsecurity_crs_30_http_policy.conf /etc/httpd/modsecurity.d/modsecurity_crs_35_bad_robots.conf /etc/httpd/modsecurity.d/modsecurity_crs_40_generic_attacks.conf /etc/httpd/modsecurity.d/modsecurity_crs_45_trojans.conf /etc/httpd/modsecurity.d/modsecurity_crs_50_outbound.conf /etc/httpd/modsecurity.d/modsecurity_localrules.conf /etc/httpd/modsecurity.d/optional_rules /etc/httpd/modsecurity.d/optional_rules/modsecurity_crs_20_protocol_violations.conf /etc/httpd/modsecurity.d/optional_rules/modsecurity_crs_21_protocol_anomalies.conf /etc/httpd/modsecurity.d/optional_rules/modsecurity_crs_40_generic_attacks.conf /etc/httpd/modsecurity.d/optional_rules/modsecurity_crs_42_comment_spam.conf /etc/httpd/modsecurity.d/optional_rules/modsecurity_crs_42_tight_security.conf /etc/httpd/modsecurity.d/optional_rules/modsecurity_crs_55_marketing.conf [root@firefly conf.d]# rpm -q mod_security mod_security-2.5.10-1.fc11.x86_64 /etc/httpd/conf.d/mod_security.conf /etc/httpd/modsecurity.d /etc/httpd/modsecurity.d/modsecurity_crs_10_config.conf /etc/httpd/modsecurity.d/modsecurity_crs_10_global_config.conf /etc/httpd/modsecurity.d/modsecurity_localrules.conf /etc/httpd/modsecurity.d/optional_rules /etc/httpd/modsecurity.d/optional_rules/modsecurity_crs_20_protocol_violations.conf /etc/httpd/modsecurity.d/optional_rules/modsecurity_crs_21_protocol_anomalies.conf /etc/httpd/modsecurity.d/optional_rules/modsecurity_crs_40_generic_attacks.conf /etc/httpd/modsecurity.d/optional_rules/modsecurity_crs_42_comment_spam.conf /etc/httpd/modsecurity.d/optional_rules/modsecurity_crs_42_tight_security.conf /etc/httpd/modsecurity.d/optional_rules/modsecurity_crs_55_marketing.conf Note that most of the rulesets in mod_security-2.5.10-1 have been moved a further subdirectory down into optional_rules - not also that several of the rulesets have been removed completly meaning that even when you fix the config to point to the updated paths the webserver is now unprotected against several forms of attack, The proven lack of testing of the package update is deeply disappointing.
Looking at this again it appears most of the removed ruleset files are duplications - which is understandable. The main config being updated however is not.
It also appears as if an entire subdirectory of rules (base_rules) is missing when compared to the official core ruleset v2.0.2.
There is the same problem in Fedora 10. Web server down due to this.
I'm looking into this further and will push a new stable build once it's found to be OK. I've noticed that no one had commented on the package while in updates-testing - I would encourage users to do so in future (for all packages you'd consider important).
With all due respect. Your making the assumption that a regular user actually knows that they need to test mod_security from updates_testing. Also, that they have resources to test it. In my case, I only have my production environment to work with so I am updating my packages directly from updates. I realize that resources are limited for many. However, not doing the basic qa to make sure that the Web Server comes up... Its one of those things that make you go hmmm. :)
Updated builds are currently running through koji after a successful scratch build and install (EL-5). Will push out the new builds to stable when completed.
mod_security-2.5.10-2.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/mod_security-2.5.10-2.fc10
mod_security-2.5.10-2.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/mod_security-2.5.10-2.fc12
mod_security-2.5.10-2.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/mod_security-2.5.10-2.fc11
I was writing to say I had the same thing for FC11... but I got a "Mid-air collision detected!" as I went to submit! I am very pleased and thankful that this has been fixed quickly. Thank you!
mod_security-2.5.10-2.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.
mod_security-2.5.10-2.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
The new mod_security-2.5.10-2.fc10.i386 breaks bugzilla-3.2.5-1.fc10.noarch. I'm working on localrules to allow cgi in bugzilla to work, but wow, why should I?
Mr JG I do not understand what you are trying to say...
OK this seems to be fixed and httpd loads. BUT now it breaks nagios. :-( [msg "Transactional Anomaly Score (score 50): Detects JavaScript location/document property access and window access obfuscation"] [hostname "sysdoc.safespeak.com"] [uri "/nagios/cgi-bin//statusmap.cgi"] Do we need a new bug report on that???
Sorry. I was not clear. I was saying that the new mod_security breaks bugzilla, and that I was working on local rules to allow bugzilla to be able to search again, but it is my opinion that rules for things like bugzilla should be part of a package, either mod_security or Bugzilla. I know that is asking a lot, but to have a working production system and do an update and have services that were working no longer work is disconcerting and irritates the user base. Here are the local rules for allowing bugzilla to run. <Location /bugzilla/buglist.cgi> SecRuleRemoveById 959913 SecRuleRemoveById 959914 SecRuleRemoveById 960904 SecRuleRemoveById phpids-19 </Location>
Found more problems areas with cgi scripts from Bugzilla so the new local rules are: <Location /bugzilla> SecRuleRemoveById 950108 SecRuleRemoveById 959913 SecRuleRemoveById 959914 SecRuleRemoveById 960010 SecRuleRemoveById 960012 SecRuleRemoveById 960904 SecRuleRemoveById phpids-19 SecRuleRemoveById phpids-21 SecRuleRemoveById phpids-23 </Location> There may be more to come, but so far so good.
Good morning, this is your package maintainer speaking, This is a closed bug. Unless there's an issue directly related to the original report, it'll stay that way. If there is a separate package-related issue needing attention, please open a new bug with the appropriate info. Also bear in mind that I'm responsible for the packaging of the application, not the rulesets. I would encourage users - especially those running it in production - to join the mailing lists: https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set (for the Core Rules Set) https://lists.sourceforge.net/lists/listinfo/mod-security-users
mod_security-2.5.10-2.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.