Issue Plesk Premium Antivirus update fails

[mjehlenz]

Server operating system version

CentOS 7.9

Plesk version and microupdate number

18.0.59 Update #2

Hi all!

Since a few days ago, Plesk Premium Antivirus fails to update on one server running Plesk 18.0.59 Update #2. The cronjob fails with the following message:

/etc/cron.daily/drweb-update:

ERROR: Dr.Web Updater: failed to download files !

The same message occurs when manually running /opt/drweb/update.pl.

In /var/log/messages I found the following corresponding entries:

update.pl[16199]: can not fetch http://update.geo.drweb.com/plesk/1100/unix/drweb32.lst
update.pl[16199]: failed to download files

Manually trying to access the URL http://update.geo.drweb.com/plesk/1100/unix/drweb32.lst results in an HTTP 451 (Unavailable For Legal Reasons).

The solution described in this support article does not help unfortunately.

Is anyone else experiencing this problem? How can we resolve this issue?

Thanks in advance!

Moritz

 

[mow]

I got a mail on Sunday and Monday, but not today, so maybe it was fixed?
Mail has one line more than yours:
/etc/cron.daily/drweb-update:
ERROR: Dr.Web Updater: failed to download files !
run-parts: /etc/cron.daily/drweb-update exited with return code 103

Side note: Mail comes from [email protected].

 

[mjehlenz]

Thanks for your reply. I just tried manually running the update script again and it seems to be working again.

 

[trialotto]

I got a mail on Sunday and Monday, but not today, so maybe it was fixed?
Mail has one line more than yours:
/etc/cron.daily/drweb-update:
ERROR: Dr.Web Updater: failed to download files !
run-parts: /etc/cron.daily/drweb-update exited with return code 103

Side note: Mail comes from [email protected].

@mow, @mjehlenz

The error 103 code is unknown and the drweb update behavior is quite unexpected.

However, there are some indicators of the root cause of the problem in /var/log/syslog (on Ubuntu) :

1 - notification : Can not update key file, trying to make update with old key file .......

2 - some requests to update.geo.drweb.com return 200 OK

3 - some request to update.geo.drweb.com return 404 Not Found

Nevertheless, there might also be other indicators of the root cause of the problem in /var/log/syslog (on Ubuntu) :

4 - notification : failed to download http://update.geo.drweb.com/plesk/1100/unix/drweb32.lst (Connection timed out)

5 - can not fetch http://update.geo.drweb.com/plesk/1100/unix/drweb32.lst


In addition, if /opt/drweb/update.pl is run manually, there is the ERROR notification

ERROR: Dr.Web Updater: Received unknown status 'no renew na' from server !
ERROR: Dr.Web Updater: failed to download files !

with the first error notification being unknown - at least to me the part "no renew na" is unknown to me and nowhere to be found in documentation.


In essence, /opt/drweb/update.pl does NOT renew and/or does NOT download files.

This is quite strange, since the requests to update.geo.drweb.com are able to pass, but do NOT always pass (404 codes, connection time outs etc).


This ISSUE occurs as from 30 March 2024.


ROOT CAUSE :
It seems to be the case that some instability on the server side at DrWeb causes some issues that are rather random and that differ from time to time.


WORKAROUND :
Follow this KB Article : https://support.plesk.com/hc/en-us/...ivirus-cannot-update-failed-to-download-files

NOTE :
The workaround is not a permanent fix, it is a "dirty" workaround and should be undone as soon as Drweb issues have been bugfixed!!

 

[Bitpalast]

The workaround does not work reliably at the moment either
And hey, I am soooo glad I see that you guys experience the same issue as I had been tweaking our firewall settings a lot lately and was afraid that it's due to blocking some malicious subnets. So probably it's due to a longer maintenance period of Dr.Web servers.

 

[trialotto]

The workaround does not work reliably at the moment either
And hey, I am soooo glad I see that you guys experience the same issue as I had been tweaking our firewall settings a lot lately and was afraid that it's due to blocking some malicious subnets. So probably it's due to a longer maintenance period of Dr.Web servers.

@Bitpalast

Strange to change the handle :-D

No, it has nothing to do with firewall settings and/or it is not even a Plesk bug : it is random behavior on the DrWeb side.

The workaround is - as admitted before - very dirty.

In essence, the dirty nature of this workaround is given by the facts that :

- "older" virus records are being used as the base of the updates - the "700" channel is being used
- "newer" virus records are being deleted with the workaround - the "1100" channel related files are gone, after applying the workaround
- the TOTAL number of virus records (added to DrWeb) is LOWER, when applying the workaround
- it is not yet proven or certain that the workaround is update persistent

So yes, the workaround should work, but is very dirty.

However, if you did test the workaround and it does not work for you, please post the results of the analysis!

After all, Plesk should alter the KB and mention that their KB is resulting in a reversion to "older" virus records (not desirable!) and/or that it might not be the solution for the current matter at hand.

Kind regards....

 

[mjehlenz]

@trialotto Unfortunately the workaround did not work for us.

 

[Bitpalast]

@Bitpalast
Strange to change the handle :-D

I had to let my work order expire to reduce my overall significantly high work load. The problem is that a week only has 168 hours, and when you fill the majority with work, it becomes unhealthy.

- "older" virus records are being used as the base of the updates - the "700" channel is being used
- "newer" virus records are being deleted with the workaround - the "1100" channel related files are gone, after applying the workaround
- the TOTAL number of virus records (added to DrWeb) is LOWER, when applying the workaround

Great additional info, thank you!

However, if you did test the workaround and it does not work for you, please post the results of the analysis!

Nay, didn't have the patience to wait until all them replacement servers were worked through, so I'll just wait on our servers here until it works again. I just realized that "most" of the alternatives also time out. In this case it's not such a big issue if some files are not up-to-date every single day.

 

[trialotto]

@trialotto Unfortunately the workaround did not work for us.

@mjehlenz

As stated before, the workaround does not always work - it is random behavior on the (server-)side of DrWeb.

I have experienced that the workaround did work, then it didn't, then it did with other settings and ....... it almost seems like a pattern, but it is not.

The best thing to do is to wait....... or use some test environment and retry the workaround every now and then.

Kind regards....

 

[trialotto]

@Bitpalast

Well, yes, as from your presence on the forum, it could already be concluded that you spent 250 hours per week on work

Moreover, I can personally understand your choice - it is good to do something for the community and it is easy to get absorbed by the work for the community, but in the end there is always other work to be done that is related to the own business and/or there has to be time for just simple relaxation (and all other daily things that have to be done).

I do appreciate the time that you have taken upon you that role, so my sincere thanks!

By the way, with respect to

Nay, didn't have the patience to wait until all them replacement servers were worked through, so I'll just wait on our servers here until it works again. I just realized that "most" of the alternatives also time out. In this case it's not such a big issue if some files are not up-to-date every single day.

it is safe to agree with you and state that it is not (yet) a big issue. Not yet.

We will see how this works out, there are a lot of factors playing a role here - it is not only ICT related.

Kind regards....

 

[enerspace]

Type:

nslookup update.drweb.com

Output:
Non-authoritative answer:
Name: update.drweb.com
Address: 209.160.32.82
Name: update.drweb.com
Address: 209.160.33.8
Name: update.drweb.com
Address: 195.133.219.93
Name: update.drweb.com
Address: 213.59.3.178
Name: update.drweb.com
Address: 153.120.15.43
Name: update.drweb.com
Address: 85.10.234.30
Name: update.drweb.com
Address: 153.120.15.42
Name: update.drweb.com
Address: 195.133.219.91
Name: update.drweb.com
Address: 195.161.158.50
Name: update.drweb.com
Address: 81.176.67.172
Name: update.drweb.com
Address: 153.120.15.41

Check if all addresses are reachable:

# Liste der IP-Adressen
ips=(
209.160.32.82
209.160.33.8
195.133.219.93
213.59.3.178
153.120.15.43
85.10.234.30
153.120.15.42
195.133.219.91
195.161.158.50
81.176.67.172
153.120.15.41
)

# Durchlaufen der Liste und Pingen jeder IP
for ip in "${ips[@]}"; do
    # Ping der IP-Adresse mit einer Anforderung, Timeout von 1 Sekunde
    ping -c 1 -W 1 $ip > /dev/null 2>&1
    # Überprüfen, ob der Ping-Befehl erfolgreich war
    if [ $? -eq 0 ]; then
        echo "IP-Adresse $ip ist erreichbar."
    else
        echo "IP-Adresse $ip ist nicht erreichbar und wird übersprungen."
    fi
done

Output:
IP-Adresse 209.160.32.82 ist erreichbar.
IP-Adresse 209.160.33.8 ist erreichbar.
IP-Adresse 195.133.219.93 ist erreichbar.
IP-Adresse 213.59.3.178 ist erreichbar.
IP-Adresse 153.120.15.43 ist erreichbar.
IP-Adresse 85.10.234.30 ist erreichbar.
IP-Adresse 153.120.15.42 ist erreichbar.
IP-Adresse 195.133.219.91 ist erreichbar.
IP-Adresse 195.161.158.50 ist nicht erreichbar und wird übersprungen.
IP-Adresse 81.176.67.172 ist nicht erreichbar und wird übersprungen.
IP-Adresse 153.120.15.41 ist erreichbar.

This means that if you enter /opt/drweb/update.pl, an IP address may be selected that cannot be reached.

Yesterday there were other IP addresses. Presumably the infrastructure is being updated without any precautions being taken... I think ....

 

[enerspace]

I've written the following script as a temporary solution to the issue. The script checks which IP addresses under update.drweb.com are reachable and which are not. Unreachable IP addresses are redirected to one of the reachable IP addresses using IPTABLES. Afterwards, the updater is run. Finally, the changes are reverted.

The script is designed for AlmaLinux 8. Use at your own risk!

#!/bin/bash
# copyright by enerspace.de

# Retrieve all IP addresses for update.drweb.com
ips=$(dig +short update.drweb.com)

reachable_ips=()

# Check each IP address for reachability
for ip in $ips; do
    if ping -c 1 -W 1 $ip > /dev/null 2>&1; then
        reachable_ips+=($ip)
    fi
done

# Choose a reachable IP address as the target if available
if [ ${#reachable_ips[@]} -eq 0 ]; then
    echo "No reachable IP addresses found."
    exit 1
else
    destination_ip=${reachable_ips[0]}
    destination_port=80
    echo "Using $destination_ip as the target for unreachable IP addresses."
fi

# Redirect traffic from unreachable IPs to the selected reachable IP
for ip in $ips; do
    if ! ping -c 1 -W 1 $ip > /dev/null 2>&1; then
        echo "Redirecting $ip to $destination_ip."
        sudo iptables -t nat -A OUTPUT -p tcp --dport 80 -d $ip -j DNAT --to-destination ${destination_ip}:${destination_port}
    fi
done

# Execute the update script
echo "Starting /opt/drweb/update.pl..."
/opt/drweb/update.pl
echo "/opt/drweb/update.pl completed."

# Revert the iptables rules
for ip in $ips; do
    if ! ping -c 1 -W 1 $ip > /dev/null 2>&1; then
        echo "Removing iptables rule for $ip."
        sudo iptables -t nat -D OUTPUT -p tcp --dport 80 -d $ip -j DNAT --to-destination ${destination_ip}:${destination_port}
    fi
done

echo "iptables rules have been removed."

 

[enerspace]

V2

#!/bin/bash
# copyright by enerspace.de

# Retrieve all IP addresses for update.drweb.com
ips=$(dig +short update.drweb.com)
reachable_ips=()
unreachable_ips=()

# Check each IP address for reachability
for ip in $ips; do
    if ping -c 1 -W 1 $ip > /dev/null 2>&1; then
        reachable_ips+=($ip)
    else
        unreachable_ips+=($ip)
    fi
done

# Choose a reachable IP address as the target if available
if [ ${#reachable_ips[@]} -eq 0 ]; then
    echo "No reachable IP addresses found."
    exit 1
else
    destination_ip=${reachable_ips[0]}
    destination_port=80
    echo "Using $destination_ip as the target for unreachable IP addresses."
fi

# Redirect traffic from unreachable IPs to the selected reachable IP
for ip in ${unreachable_ips[@]}; do
    echo "Redirecting $ip to $destination_ip."
    sudo iptables -t nat -A OUTPUT -p tcp --dport 80 -d $ip -j DNAT --to-destination ${destination_ip}:${destination_port}
done

# Execute the update script
echo "Starting /opt/drweb/update.pl..."
/opt/drweb/update.pl
echo "/opt/drweb/update.pl completed."

# Revert the iptables rules for unreachable IPs
for ip in ${unreachable_ips[@]}; do
    echo "Removing iptables rule for $ip."
    sudo iptables -t nat -D OUTPUT -p tcp --dport 80 -d $ip -j DNAT --to-destination ${destination_ip}:${destination_port}
done

echo "iptables rules for unreachable IPs have been removed."

 

[AlmaWalters]

For future references, you can try switching the server Dr.Web uses for updates. Just open its config file (you'll usually find it at /etc/drweb/drweb32.ini or /etc/drweb/drweb_handler.conf) and look for the line that says UpdateServer. Change the website address there to a different one. At least it helped in my case.

 

[mow]

I've written the following script as a temporary solution to the issue. The script checks which IP addresses under update.drweb.com are reachable and which are not. Unreachable IP addresses are redirected to one of the reachable IP addresses using IPTABLES. Afterwards, the updater is run. Finally, the changes are reverted.

Would probably be easier to just put one of the working IPs in /etc/hosts.

 

[AYamshanov]

A new KB article to help to solve the issue has been prepared,

• https://support.plesk.com/hc/en-us/...failed-to-download-files-Connection-timed-out

 

[AlmaWalters]

A new KB article to help to solve the issue has been prepared,

• https://support.plesk.com/hc/en-us/...failed-to-download-files-Connection-timed-out

It's actually pretty helpful. Just checked it out! Thnx for sharing it!

 

[trialotto]

A new KB article to help to solve the issue has been prepared,

• https://support.plesk.com/hc/en-us/...failed-to-download-files-Connection-timed-out

@AYamshanov

Could you be so kind as to develop a simple "button" in Tools & Settings > Server-wide mail settings that allows to activate drWeb (or other antivirus) for ALL mailboxes present on the server?

After all, at this moment, drWeb is not activated by default for a newly created mailbox .........

.......... and when reinstalling (or changing) antivirus, drWeb (or other antivirus) are not activated on already existing mailboxes.

This is not a bug, but a desirable feature!

Kind regards.....

 

[Bitpalast]

You can post feature requests here: Feature Suggestions: Top (2022 ideas) – Your Ideas for Plesk

 

[enerspace]

Would probably be easier to just put one of the working IPs in /etc/hosts.

Why should that be easier? My script does it fully automated without the need to manually adjust anything. Additionally, the script can be used for the future as well.

Moreover, only the IP addresses that are not working are redirected. After the script is finished, the changes are reverted.

My solution is just something for experienced users.