Skip to main content

Modsecurity 2.9.6 [Fix Security]

Comments

57 comments

  • cPRex Jurassic Moderator
    @ciao70 - I'll reply when I have something to share.
    0
  • sparek-3
    Hi cPRex, Isn't it that the developers have forgotten? :)

    Don't feel too bad. I'm still awaiting resolution for the issue described at:
    0
  • ciao70
    Hi, I just point out that Modsecurity and OWASP CRS on Plesk 18.0.48 have been updated to 2.9.6 and 3.3.4, three days ago. If I remember correctly, from 2018 Plesk and Cpanel are practically cousins
    0
  • Saxtus
    That brings a new problem now: [root@host ~]# /usr/local/cpanel/scripts/modsec_vendor update --auto info [modsec_vendor] Updates are in progress for all of the installed ModSecurity vendors with automatic updates enabled. warn [modsec_vendor] The system could not add the vendor: The vendor metadata does not contain an entry for your version of ModSecurity, "2.9.6". The only versions of ModSecurity this rule set supports are "2.7.5", "2.7.7", "2.8.0", "2.9.0", "2.9.1", "2.9.2", "2.9.3", and "3.0.4". info [modsec_vendor] Restored modsec_cpanel_conf_datastore backup The system failed to update the vendor from the URL "https://files.imunify360.com/static/modsec/v2/meta_imunify360-full-litespeed.yaml": The vendor metadata does not contain an entry for your version of ModSecurity, "2.9.6". The only versions of ModSecurity this rule set supports are "2.7.5", "2.7.7", "2.8.0", "2.9.0", "2.9.1", "2.9.2", "2.9.3", and "3.0.4". warn [modsec_vendor] The system failed to update the vendor from the URL "https://files.imunify360.com/static/modsec/v2/meta_imunify360-full-litespeed.yaml": The vendor metadata does not contain an entry for your version of ModSecurity, "2.9.6". The only versions of ModSecurity this rule set supports are "2.7.5", "2.7.7", "2.8.0", "2.9.0", "2.9.1", "2.9.2", "2.9.3", and "3.0.4".
    0
  • vpsstore
    Our system was updated last night (~ 10pm GMT) and since paypal and Opayo/Sagepay transactions are failing for a mixture of reasons. Anyone else having problems?
    0
  • ciao70
    Our system was updated last night (~ 10pm GMT) and since paypal and Opayo/Sagepay transactions are failing for a mixture of reasons. Anyone else having problems?

    Hi, Do you use OWASP CRS?
    0
  • ciao70
    That brings a new problem now: [root@host ~]# /usr/local/cpanel/scripts/modsec_vendor update --auto info [modsec_vendor] Updates are in progress for all of the installed ModSecurity vendors with automatic updates enabled. warn [modsec_vendor] The system could not add the vendor: The vendor metadata does not contain an entry for your version of ModSecurity, "2.9.6". The only versions of ModSecurity this rule set supports are "2.7.5", "2.7.7", "2.8.0", "2.9.0", "2.9.1", "2.9.2", "2.9.3", and "3.0.4". info [modsec_vendor] Restored modsec_cpanel_conf_datastore backup The system failed to update the vendor from the URL "https://files.imunify360.com/static/modsec/v2/meta_imunify360-full-litespeed.yaml": The vendor metadata does not contain an entry for your version of ModSecurity, "2.9.6". The only versions of ModSecurity this rule set supports are "2.7.5", "2.7.7", "2.8.0", "2.9.0", "2.9.1", "2.9.2", "2.9.3", and "3.0.4". warn [modsec_vendor] The system failed to update the vendor from the URL "https://files.imunify360.com/static/modsec/v2/meta_imunify360-full-litespeed.yaml": The vendor metadata does not contain an entry for your version of ModSecurity, "2.9.6". The only versions of ModSecurity this rule set supports are "2.7.5", "2.7.7", "2.8.0", "2.9.0", "2.9.1", "2.9.2", "2.9.3", and "3.0.4".

    Hi, It seems your vendor does not support Modsecurity 2.9.6
    0
  • vpsstore
    Hi, Do you use OWASP CRS?

    Yes, it is the ruleset causing the issues AFAIK, previously no problems at all.
    0
  • ciao70
    Yes, it is the ruleset causing the issues AFAIK

    Check which rule is causing the problem. For example, I had to disable rule 920450: Restricted HTTP headers msg:'HTTP header is restricted by policy (%{MATCHED_VAR})
    0
  • vpsstore
    Thank you, there are quite a few - but you have to work back from 949110 which is the one that does the dirty work. eg. for Opayo/Sagepay (amongst other codes) 920600 980130 This must be affecting quite a lot of people - assuming we aren't the only people with it switched on!
    0
  • ciao70
    949100 ( absolutely must not be deactivated, it counts the anomalous score of the various rules) You need to disable only the individual rules that are creating the problem 920600 This rule restricts these to familiar charsets. (OK)
    0
  • vpsstore
    949100 ( absolutely must not be deactivated, it counts the anomalous score of the various rules) You need to disable only the individual rules that are creating the problem 920600 This rule restricts these to familiar charsets. (OK)
    0
  • ciao70
    These issues depend on the security changes that have been implemented in Modsecurity 2.9.6 and OWASP 3.3.4
    0
  • kitmancraig2
    Same problems with paypal and opayo. Tracked the various triggers and had the following list: 920600 920420 980130 Added these as global exemptions. Did not work. We have to add exemptions for 949110 for the 2 call back scripts which I understand to be very bad. I would appreciate a solution that does not involve disabling 949110.
    0
  • ciao70
    Same problems with paypal and opayo. Tracked the various triggers and had the following list: 920600 920420 980130 Added these as global exemptions. Did not work. We have to add exemptions for 949110 for the 2 call back scripts which I understand to be very bad. I would appreciate a solution that does not involve disabling 949110

    Hi, If only those 3 rules are the problem, once disabled, they should no longer trigger 949110. Maybe there is some other rule to disable, but not 949110 and 980130 (these exclude the detection of many other rules)
    0
  • Joe A
    Hi, the modsec ruleset update yesterday also caused havoc to our payment system. The temporary solution was to disable the offending ruleset trigger ID : 920600
    0
  • kitmancraig2
    Hi, If only those 3 rules are the problem, once disabled, they should no longer trigger 949110. Maybe there is some other rule to disable, but not 949110 and 980130 (these exclude the detection of many other rules)

    As I mentioned in my original post. These were the rules that were showing in the hitlist but disabling them and not 949110 did not work. I have tried again today and it does not work.
    0
  • kitmancraig2
    As I mentioned in my original post. These were the rules that were showing in the hitlist but disabling them and not 949110 did not work. I have tried again today and it does not work.

    These are the hits that occurred when I added the 3 rules to the exclusion of the script. You can see the top one is what happened when I removed the rules and added 949110 back. This is very serious and I cannot believe more people aren't affected.
    0
  • ciao70
    I don't know if I understood correctly, when you disable the 920600 rule you still have the problem? Once you deactivate a rule, it must be confirmed and published
    0
  • ciao70
    Hi,
    0
  • savoures
    Hello I have the same problem with 3-4 eshops under my hosting. After the upgrade to the newest version of mod security Paypal payments dont work. I had to disable it in these cpanels in order not to cause problems to my customers. Also Another problem is that when a customer tries to add new products with a name like "????????? ?????????? ????? 3XE15" When he writes something like 3XE15 in the title then the system locks his IP. I also had to disable it on that cpanel too
    0
  • ciao70
    Modsecurity 2.9.7 released
    0
  • cPRex Jurassic Moderator
    No, nothing yet.
    0
  • stormy
    So the Comodo ruleset for Litespeed has stopped working for good? Or is it temporary?
    0
  • xpy-xpy
    So the Comodo ruleset for Litespeed has stopped working for good? Or is it temporary?

    The story is old, and it looks like it is over: Is this project dead?
    0

Please sign in to leave a comment.