Issue Error: Failed to update the ModSecurity rule set.

[Azurel]

Only as notice: I see today this error message in plesk:

Error: Failed to update the ModSecurity rule set. details

Click on details go to "/admin/web-app-firewall/general" and show:

Error: Failed to update the ModSecurity rule set: modsecurity_ctl failed: <urlopen error ('_ssl.c:602: The handshake operation timed out',)>
Unable to download tortix rule set

Plesk Onyx Version 17.8.11 Update #35, last updated on Dec 24, 2018 03:35 AM

 

[Bitpalast]

This is a frequent error that is caused by inaccessbility of the ModSecurity servers to download their latest rules. Simply wait until the next day, normally next night during the nightly maintenance window the update will work again. There is not severe risk involved with a delayed update.

 

[Azurel]

Its now one week passed and this error still exists and its now a 403 forbidden error.

Error: Failed to update the ModSecurity rule set: modsecurity_ctl failed: HTTP Error 403: Forbidden
Unable to download tortix rule set

UPDATE: After updated Plesk today, the error message is gone.

Plesk Onyx Version 17.8.11 Update #36, last updated on Jan 15, 2019

 

[Azurel]

So, the update only kill the error message, was maybe is a bug? The error is still here:

Error: Failed to update the ModSecurity rule set: modsecurity_ctl failed: HTTP Error 403: Forbidden
Unable to download tortix rule set

I'm the only one with this?

 

[Bitpalast]

The same here and for some other users, see Issue - ModSecurity (once again) who has the same issue (and more, unrelated to the download issue). I think it is an ongoing download issue with ModSecurity since several weeks now. Not sure, but maybe @IgorG knows more about it?

 

[DieterWerner]

The same here and for some other users, see Issue - ModSecurity (once again) who has the same issue (and more, unrelated to the download issue). I think it is an ongoing download issue with ModSecurity since several weeks now. Not sure, but maybe @IgorG knows more about it?

And so I wonder why you marked the above mentioned thread as resolved

 

[Bitpalast]

The other thread is only partionally about the ModSecurity update. On that other system there are underlying difficulties with using ModSecurity that are probably the result of two installations of the same software in different paths, one by Plesk, the other one directly on the Linux OS level. I am sure it is not a Plesk issue there, but more an OS issue. It cannot be solved through this forum but will need an in-depth analysis on the system.

The case here is different. Here we are only discussing the failing ModSecurity updates while ModSecurity and all other aspects of the system are working. So this case here is purely about the failing update of the rule sets.

 

[DieterWerner]

On that other system there are underlying difficulties with using ModSecurity that are probably the result of two installations of the same software in different paths, one by Plesk, the other one directly on the Linux OS level.

I'm impressed of the accurancy of your glass ball.

The case here is different. Here we are only discussing the failing ModSecurity updates while ModSecurity and all other aspects of the system are working. So this case here is purely about the failing update of the rule sets.

Yes, but I started my thread because of the failing ModSecurity updates.
There are a lot of proposals/articles in the help databse of plesk - and I tried them step by step but the results where bad (see my other thread)
My impression is that atomic wants to get rid of the not-paying-plesk users - maybe I'm wrong.

 

[Bitpalast]

I'm impressed of the accurancy of your glass ball.
...
There are a lot of proposals/articles in the help databse of plesk - and I tried them step by step but the results where bad (see my other thread)

Please don't mind my assessment of the situation. It is not using a glass ball, but your own evidence. For one, a deinstallation of the ModSecurity component in Plesk does not crash a server that is otherwise correctly configured. Second, the failure to solve the issue by working through the FAQs indicates that there is a deeper issue, else you would have been successful in solving the issue. The system is simply misconfigured for some reason, but it is not a Plesk issue, but an OS issue. Even if websites don't start after deinstallation of ModSecurity, the Plesk web server, which is independent of the websites, would still have been accessible. The fact that nothing seemed to work after the deinstallation tells me that there must be a separate, much deeper problem. You will need an admin who takes a close look at your operating system installation. Another smart step could be to reinstall the system from scratch and import your sites from a backup afterwards. Also make sure that your local IPv4 address and localhost are both whitelisted in the fail2ban configuration.

 

[DieterWerner]

@Peter Debik
Neither you nor me, have a solution - so please let us stop the discussion now.

 

[Rene van Lieshout]

I've got the same problem on a brand new installation:

Error: Failed to update the ModSecurity rule set: modsecurity_ctl failed: <urlopen error timed out>. Retry<urlopen error timed out>. RetryERROR:root:Error
Traceback (most recent call last):
File "/usr/lib64/plesk-9.0/modsecurity_get_vendor_ruleset/modsecurity_get_vendor_ruleset.py", line 53, in main
File "/usr/lib64/plesk-9.0/modsecurity_get_vendor_ruleset/modsecurity_get_vendor_ruleset.py", line 35, in get_vendor_ruleset
File "/usr/lib64/plesk-9.0/modsecurity_get_vendor_ruleset/plesk_atomic.py", line 105, in download
with closing(urllib2.urlopen(url, timeout=15)) as fin:
File "/usr/lib64/python2.7/urllib2.py", line 154, in urlopen
return opener.open(url, data, timeout)
File "/usr/lib64/python2.7/urllib2.py", line 429, in open
response = self._open(req, data)
File "/usr/lib64/python2.7/urllib2.py", line 447, in _open
'_open', req)
File "/usr/lib64/python2.7/urllib2.py", line 407, in _call_chain
result = func(*args)
File "/usr/lib64/python2.7/urllib2.py", line 1243, in https_open
context=self._context)
File "/usr/lib64/python2.7/urllib2.py", line 1200, in do_open
raise URLError(err)
URLErrorWrapper: Error interacting with https://waf.comodo.com/doc/meta_comodo_apache.yaml: <urlopen error timed out>
Unable to download comodo_free rule set

It won't help that https://waf.comodo.com/doc/meta_comodo_apache.yaml doesn't seem to be responding currently. Also see Unable to activate or update the Comodo rule-set in ModSecurity: Error interacting with https://waf.comodo.com/doc/meta_comodo_apache.yaml:

 

[Babadan]

I've got the same problem.

Fehler: Der ModSecurity-Regelsatz wurde nicht aktualisiert werden: modsecurity_ctl fehlgeschlagen: <urlopen error [Errno 110] Zeitüberschreitung der Verbindung>. Wiederholen Sie <urlopen error [Errno 110] Zeitüberschreitung der Verbindung>. RetryERROR: root: Fehler
Traceback (letzter Anruf zuletzt):
Datei "/usr/lib/plesk-9.0/modsecurity_get_vendor_ruleset/modsecurity_get_vendor_ruleset.py", Zeile 53, in main
Datei "/usr/lib/plesk-9.0/modsecurity_get_vendor_ruleset/modsecurity_get_vendor_ruleset.py", Zeile 35, in get_vendor_ruleset
Datei "/usr/lib/plesk-9.0/modsecurity_get_vendor_ruleset/plesk_atomic.py", Zeile 105, im Download
mit dem Schließen (urllib2.urlopen (url, timeout = 15)) als fin:
Datei "/usr/lib/python2.7/urllib2.py", Zeile 154, in urlopen
return opener.open (URL, Daten, Zeitüberschreitung)
Datei "/usr/lib/python2.7/urllib2.py", Zeile 429, geöffnet
response = self._open (req, data)
Datei "/usr/lib/python2.7/urllib2.py", Zeile 447, in _open
'_open', req)
Datei "/usr/lib/python2.7/urllib2.py", Zeile 407, in _call_chain
Ergebnis = func (* args)
Datei "/usr/lib/python2.7/urllib2.py", Zeile 1241, in https_open
context = self._context)
Datei "/usr/lib/python2.7/urllib2.py", Zeile 1198, in do_open
URLError auslösen (err)
URLErrorWrapper: Fehler bei der Interaktion mit https://waf.comodo.com/doc/meta_comodo_apache.yaml: <urlopen error [Errno 110] Zeitüberschreitung der Verbindung>
Der Regelsatz comodo_free kann nicht heruntergeladen werden

 

[Bitpalast]

@Rene van Lieshout: It is possible that even on a new installation this happens if the Comodo servers are not responding. This is frequently the case and a "normal", not desirable behavior. It's not a Plesk error. The servers that provide the updated ruleset are simply unresponsive. Maybe they are capping the number of concurrent connections, maybe they are offline for other reasons. We don't know. Normally, the issue is resolved on future attempts, e.g. by tomorrow. There is not really a security threat through this, as the currently installed ruleset will still work.

 

[Rene van Lieshout]

I realised that. I just wanted to add a link to that post because I found this via Google