Clamav update receives 429 error (to many requests)

I'm getting the same errors. They started on 8 March. I also see error messages about SSL certificates, which suggests this might be the underlying problem? (I ran update-ca-certificates on my machine but they were all up to date)

Thu Mar 11 23:10:00 2021 -> daily database available for update (local version: 26104, remote version: 26105)
[…]
Thu Mar 11 23:10:02 2021 -> WARNING: Download failed (51) Thu Mar 11 23:10:02 2021 -> WARNING: Message: SSL peer certificate or SSH remote key was not OK
Thu Mar 11 23:10:02 2021 -> WARNING: getpatch: Can't download daily-26105.cdiff from https://clamav.spod.org/daily-26105.cdiff
Thu Mar 11 23:10:02 2021 -> ERROR: Download failed (51) Thu Mar 11 23:10:02 2021 -> ERROR: Message: SSL peer certificate or SSH remote key was not OK
Thu Mar 11 23:10:02 2021 -> ERROR: getpatch: Can't download daily-26105.cdiff from https://clamav.spod.org/daily-26105.cdiff
Thu Mar 11 23:10:02 2021 -> WARNING: Incremental update failed, trying to download daily.cvd
Thu Mar 11 23:10:02 2021 -> ERROR: Download failed (51) Thu Mar 11 23:10:02 2021 -> ERROR: Message: SSL peer certificate or SSH remote key was not OK
Thu Mar 11 23:10:02 2021 -> ERROR: getcvd: Can't download daily.cvd from https://clamav.spod.org/daily.cvd
Thu Mar 11 23:10:02 2021 -> Giving up on https://clamav.spod.org…
Thu Mar 11 23:10:02 2021 -> ERROR: Update failed for database: daily
Thu Mar 11 23:10:02 2021 -> WARNING: fc_update_databases: fc_update_database failed: Connection failed (5)
Thu Mar 11 23:10:02 2021 -> ERROR: Database update process failed: Connection failed (5)
Thu Mar 11 23:10:02 2021 -> ERROR: Update failed.

Ah, I see that the daily update worked this morning (12 March). So it looks like this was just a temporary problem at their end which lasted a few days but has now been fixed.

indeed, update worked this morning here as well.
Case closed

I'm getting the same errors today March 14. For me they started yesterday.

Anyone else having this issue?

I'm still having problems. It failed for several days and then succeeded on the 12th at least once, but is failing again as of today.

It says it's a rate limit issue, but I haven't changed the frequency with which I'm requesting the updates. I'm wondering if they're aggregating Linode's addresses and rate limiting us as a group.

They do appear to have a certificate issue, it expired October of last year. I don't believe that is contributing to the 429 errors though. I'm looking into this myself to fix my broken updates. I'll post more if I find anything interesting.

0:> openssl s_client -connect database.clamav.net:443
CONNECTED(00000003)
depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO ECC Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO ECC Domain Validation Secure Server CA 2
verify return:1
depth=0 CN = ssl392509.cloudflaressl.com
verify error:num=10:certificate has expired
notAfter=Oct 13 23:59:59 2020 GMT
verify return:1
depth=0 CN = ssl392509.cloudflaressl.com
notAfter=Oct 13 23:59:59 2020 GMT
verify return:1
---
Certificate chain
 0 s:/CN=ssl392509.cloudflaressl.com
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO ECC Domain Validation Secure Server CA 2
 1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO ECC Domain Validation Secure Server CA 2
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO ECC Certification Authority
 2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO ECC Certification Authority
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIEmzCCBEGgAwIBAgIRAOcoTtfhKesE35V4auTNitAwCgYIKoZIzj0EAwIwgZIx
CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNV
BAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMTgwNgYDVQQD
Ey9DT01PRE8gRUNDIERvbWFpbiBWYWxpZGF0aW9uIFNlY3VyZSBTZXJ2ZXIgQ0Eg
MjAeFw0yMDA0MDYwMDAwMDBaFw0yMDEwMTMyMzU5NTlaMCYxJDAiBgNVBAMTG3Nz
bDM5MjUwOS5jbG91ZGZsYXJlc3NsLmNvbTBZMBMGByqGSM49AgEGCCqGSM49AwEH
A0IABAyyPeGgNUZ7DDCVxmIXXbGgBHEn9dcwS/r62+xfIMNY3BLMsmIx8R5emY/d
Q/T5GkUX46iIMTC98b6HvFrW8PKjggLhMIIC3TAfBgNVHSMEGDAWgBRACWFn8LyD
cU/eEggsb9TUK3Y9ljAdBgNVHQ4EFgQUDoWzRdCBadCYXWWDSWAscEtJd3IwDgYD
VR0PAQH/BAQDAgeAMAwGA1UdEwEB/wQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwEG
CCsGAQUFBwMCMEkGA1UdIARCMEAwNAYLKwYBBAGyMQECAgcwJTAjBggrBgEFBQcC
ARYXaHR0cHM6Ly9zZWN0aWdvLmNvbS9DUFMwCAYGZ4EMAQIBMFYGA1UdHwRPME0w
S6BJoEeGRWh0dHA6Ly9jcmwuY29tb2RvY2E0LmNvbS9DT01PRE9FQ0NEb21haW5W
YWxpZGF0aW9uU2VjdXJlU2VydmVyQ0EyLmNybDCBiAYIKwYBBQUHAQEEfDB6MFEG
CCsGAQUFBzAChkVodHRwOi8vY3J0LmNvbW9kb2NhNC5jb20vQ09NT0RPRUNDRG9t
YWluVmFsaWRhdGlvblNlY3VyZVNlcnZlckNBMi5jcnQwJQYIKwYBBQUHMAGGGWh0
dHA6Ly9vY3NwLmNvbW9kb2NhNC5jb20wggEGBgorBgEEAdZ5AgQCBIH3BIH0APIA
dwAHt1wb5X1o//Gwxh0jFce65ld8V5S3au68YToaadOiHAAAAXFQ1cDIAAAEAwBI
MEYCIQDsyk8sC5RyWGy8IEVyXG590W983+AnanXpC1TGZ7EOEgIhALJwTlB6+UnK
l0AhSyIXuPLsWGLnKHuq4umzaKEg9wVWAHcA5xLysDd+GmL7jskMYYTx6ns3y1Yd
ESZb8+DzS/JBVG4AAAFxUNXA+AAABAMASDBGAiEAm1MAO8N/IX73iGxj/bNjOlfN
5zQ3dGpnsWrZ41hKCp8CIQDcDNswJ13Zo87rokRpJmZIWl35jciE7AvhN/k9eMMW
LTAmBgNVHREEHzAdghtzc2wzOTI1MDkuY2xvdWRmbGFyZXNzbC5jb20wCgYIKoZI
zj0EAwIDSAAwRQIgcBkVX8OhulA2c9hAHUvhkJlUjRjVF2RGkx3ZkrM9GB8CIQDu
aTsI5rVaMQu1JV08ZWPTf21EJCis6L+HAmcTKZPt5g==
-----END CERTIFICATE-----
subject=/CN=ssl392509.cloudflaressl.com
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO ECC Domain Validation Secure Server CA 2
---
No client certificate CA names sent
Peer signing digest: SHA256
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 3584 bytes and written 415 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-ECDSA-AES128-GCM-SHA256
Server public key is 256 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-ECDSA-AES128-GCM-SHA256
    Session-ID: 08C51880623D7CB2354C7AAD2C58C6CA157C067565B1B75E581F737ED75B6DC1
    Session-ID-ctx:
    Master-Key: CE091AFA629065344829B9FE86DAAE43488952B4CA771A1C464613D35CBDC46100B40A6A2EE3C21BD190DFFF1033E4E5
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    TLS session ticket lifetime hint: 64800 (seconds)
    TLS session ticket:
    0000 - ba 5e 2a f4 6f c6 eb cb-8d 95 53 a3 3b fd 10 c3   .^*.o.....S.;...
    0010 - 8f 4c 9b 57 32 74 84 fd-fb a2 c7 51 b2 06 0d d7   .L.W2t.....Q....
    0020 - d8 5d 0c 42 72 43 c3 03-0b 38 ef de 45 e7 50 5a   .].BrC...8..E.PZ
    0030 - 1e e1 87 96 39 26 32 b2-79 0d 67 ad 53 ae f5 32   ....9&2.y.g.S..2
    0040 - 28 74 47 99 1e 3b 90 b0-be cf bb 7c f9 e6 4e ff   (tG..;.....|..N.
    0050 - 6e bd 37 fd a0 81 75 c7-52 1d c4 ee a9 39 10 9e   n.7...u.R....9..
    0060 - 53 17 2f d2 82 ea e9 0f-df 47 fe f0 7e 48 07 c7   S./......G..~H..
    0070 - 3e 4b e6 9f c8 d0 ea 78-72 d0 22 1f cd 11 08 7b   >K.....xr."....{
    0080 - 59 ff f5 e4 e5 d1 95 02-3b d0 6a 5e 4e 2b 5e 3c   Y.......;.j^N+^<
    0090 - 71 0a c3 a9 38 f5 cc 82-0c dc e7 43 93 24 3b cf   q...8......C.$;.
    00a0 - 5d 7b 2b 94 b7 9e d0 cd-5c c9 0e fa f6 41 0b 99   ]{+.....\....A..

    Start Time: 1615785381
    Timeout   : 300 (sec)
    Verify return code: 10 (certificate has expired)
---
^C

So @cdbunch hit on the issue. We appear to be getting rate limited, probably because they're rate limiting Linode's address space.

From FreshClam FAQ:

If you are receiving a 429, that means you are rate limited. You’re download too fast or too much. Please use Freshclam or cvdupdate. If you are using a shared hosting provider, like Amazon AWS, Google Cloud Computing, Oracle, Azure, etc, you will most likely be rate limted, however cvdupdate should handle this gracefully.

Agreed, and although this is a new issue, it has now persisted for a week. One option is for all of us to create our own private mirrors with cvdupdate. Another is to convince Linode to create one, and let us know where to point our local installs. How do we get Linode support's attention for such a request?

Thank you all for your reports and insight into this issue! For the past couple of weeks, we have been seeing an increase in 429 errors when using ClamAV. As many of you noted, this does appear to be a rate limiting issue, though it also appears to be intermittent as my colleague was able to use ClamAV successfully a few days ago. We're looking into workarounds, but in the meantime, you may want to consider using an alternative tool if you're unable to successfully download daily.cvd:

Linux Malware Detect

Rootkit Hunter

Chrootkit

The steps in ClamAV's FAQ, as JuliettKiloFoxtrot pointed out, are also good options to help prevent rate limiting errors.

If the problem is sharing the IPv6 address space, is there a way to force the queries to use IPv4? I did that with my mail server's access to RIPE's whois servers (for fail2ban's lookups) by adding an /etc/hosts entry:

193.0.6.135 whois.ripe.net whois.db.ripe.net

dig shows we could use this:

104.16.218.84 database.clamav.net

If you use Clam, you probably also use SpamAssassin. I noticed I was also getting errors for the sought rules in SpamAssassin, because I'm using CentOS 7 and the SA that comes with that still includes the obsolete sought channel. The server must have just gone offline recently, even though the channel has been deprecated for a long time.

We're also seeing update errors for both freshclam and SpamAssassin in the past few days. Is it just CentOS 7 on Linodes or is it wider than that?

I have had this problem with 429 errors for about a week. Has anyone come up with a preferred solution yet? Running Ubuntu 18.04.

Thanks everyone for the useful updates on this. Although I reported that updates were working again for me 5 days ago, they have since stopped working again. This morning I can't even view the ClamAV FAQ page at https://www.clamav.net/documents/freshclam-faq. I get the following:

Error 1020
Access denied
What happened?
This website is using a security service to protect itself from online attacks.

It looks like they have some wider issues there…

It looks like we're being blocked because they have https://database.clamav.net/daily.cvd behind Cloudflare. Cloudflare is most likely detecting our servers as a bot because we'll…it is.

F'ing Cloudflare… I suspected they might be the issue… I've had problems with them in the past… Is there any way to get these jerks to stop blocking clamav updates…??? An appeal to Clamav…? Let me know if you know where I can complain to Clamav…

Thanks,

Bill Speidel

For what it's worth i joined the clamav users list and sent them the following:

hi,

Clam AV has put it's database behind Cloudflare...  as a result the updates no longer work because Cloudflare is blocking Linode.com machines...  the updates are getting a 429 error saying that we are "rate limited"...  if this continues it will make Clam AV useless because eventually the database will be so out of date that new viruses will get through...

There should be some way for Clam AV to tell Cloudflare  to unhide the AV database and fix the 429 errors....

thanks,

~bill speidel~

Gentlemen,

I faced the same problem as you.

For me, the easiest/fastest way was to setup a proxy server outside of Linode, and use if for freshclam.

This solved my problem.

It is just setting freshclam.conf and change these two options:

HTTPProxyServer
HTTPProxyPort

That would be all.

Hope this helps!

I do not currently have access to a proxy server (e.g. squid) and didn't want to go to the trouble of setting one up. Instead I created a simple mirror website. Here's the brief write-up:

Clam AV database mirror for clamav databases and patch files

Configure DNS

• Create A/AAAA Record for clamav.yourdomainname. The IP address should be set to the address of the server hosting cvdupdate.

Setup directory

mkdir -p /path/to/website/directory/database &&
cd /path/to/website/directory &&
vim index.html

<html>
    <head>
        <title>Clam AV</title>
    </head>
    <body>
        <p>Clam AV</p>
    </body>
</html>

Setup cvdupdate

As non-root user:

python3 -m pip install --user cvdupdate

Configure Apache

cd /etc/apache2/sites-available &&
vim clamavwebsite.conf

Note: This configuration limits access to the update files to specific IP addresses. Modify to suit your needs.

<VirtualHost *:80>

    ServerName clamav.yourdomainname
    ServerAlias clamav
    ServerAdmin webmaster@yourdomainname
    ServerPath /

    DocumentRoot /path/to/website/directory/database

    <Directory /path/to/website/directory/database/ >
        Options +Indexes
        Require ip ip_address_of_clamav_installation
    </Directory>

    LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined_forward_for

    ErrorLog /path/to/log/directory/clamav_error.log
    CustomLog /path/to/log/directoryclamav_access.log combined

    # Possible values include: debug, info, notice, warn, error, crit,
    # alert, emerg.
    LogLevel warn

</VirtualHost>

• Enable the website
• Once the IP address for the server at clamav.yourdomainname is reflected in the output of dig clamav.javazen.com, run certbot (LetsEncrypt) and configure the URL for SSL.
• Create a cron entry for non-root user that installed cvdupdate with the following value (midnight):
  0 0 * * * cvd update
• Be sure the user cron job and the web server have proper access to the database directory.

Modify freshclam.conf and set the following value:

​ DatabaseMirror https://clamav.yourdomainname

This has been working for me for about a week now.

Updates

In response to @develec and @andysh, the key is to have the mirror on a server outside of Linode. In my case, it's on a VM located on a server at my workplace. Until recently, my workplace IP address had no history with Clam AV's servers.

Thanks tao5280.

It worked but cvd update still wouldn't download daily.cvd. (Too many downloads, again) I downloaded it manually to my PC from:

http://www.clamwin.com/content/view/58/27/

and then uploaded it to my new clamav website and freshclam now seems to work.

Hope this helps

Regards

Jeff

I've implemented similar solutions using the PrivateMirror option of Freshclam, but using object storage. (A web server running on a Linode may also be used.)

I created a bucket, and downloaded the following files on my laptop, and uploaded to the object storage bucket. I set permissions on these files to "public read" (as Freshclam won't do any authentication.)

• http://database.clamav.net/main.cvd
• http://database.clamav.net/daily.cvd
• http://database.clamav.net/bytecode.cvd

In freshclam.conf, uncomment one of the PrivateMirror lines and set the hostname to the object storage bucket DNS name:

PrivateMirror my-clamav-bucket.eu-central-1.linodeobjects.com

If running Freshclam as a service, restart it. You will see warnings for CLD files failing, but the CVD files should succeed.

Mar 22 16:05:53 systemd[1]: Started ClamAV virus database updater.
Mar 22 16:05:53 freshclam[33311]: ClamAV update process started at Mon Mar 22 16:05:53 2021
Mar 22 16:05:53 freshclam[33311]: WARNING: DNS Update Info disabled. Falling back to HTTP mode.
Mar 22 16:05:53 freshclam[33311]: Reading CVD header (daily.cld): WARNING: remote_cvdhead: file not found: http://my-clamav-bucket.eu-central-1.linodeobjects.com/daily.cld
Mar 22 16:05:53 freshclam[33311]: Reading CVD header (daily.cvd): OK
Mar 22 16:05:53 freshclam[33311]: daily.cvd database is up to date (version: 26116, sigs: 3964606, f-level: 63, builder: raynman)
Mar 22 16:05:53 freshclam[33311]: Reading CVD header (main.cld): WARNING: remote_cvdhead: file not found: http://my-clamav-bucket.eu-central-1.linodeobjects.com/main.cld
Mar 22 16:05:54 freshclam[33311]: Reading CVD header (main.cvd): OK
Mar 22 16:05:54 freshclam[33311]: main.cvd database is up to date (version: 59, sigs: 4564902, f-level: 60, builder: sigmgr)
Mar 22 16:05:54 freshclam[33311]: Reading CVD header (bytecode.cld): WARNING: remote_cvdhead: file not found: http://my-clamav-bucket.eu-central-1.linodeobjects.com/bytecode.cld
Mar 22 16:05:54 freshclam[33311]: Reading CVD header (bytecode.cvd): OK
Mar 22 16:05:54 freshclam[33311]: bytecode.cld database is up to date (version: 333, sigs: 92, f-level: 63, builder: awillia2)

I'll be looking to set up an automated procedure to keep these updated from my home machine, but for now, I'll keep it updated manually.

In response to @develec and @andysh, the key is to have the mirror on a server outside of Linode. In my case, it's on a VM located on a server at my workplace. Until recently, my workplace IP address had no history with Clam AV's servers.

@tao5280 true, only the machine that obtains the CVD/diff files needs to be off Linode. You could download the files elsewhere and SFTP them to a Linode, then point Freshclam to that Linode.

In my case I’m fetching the update files using my home internet (consumer broadband with a dynamic IP) and uploading it to an object storage bucket.

Freshclam is then “mirrored” to that bucket - so it’s a Linode accessing Linode object storage which of course is supported.

Inspired by @scratchmonkey, I tried putting one of the IPv4 addresses of database.clamav.net into my /etc/hosts file. This stopped the constant messages from cron telling me it failed with 429. I don't know whether they'll start rate-limiting our IPv4 addresses as a group as they apparently are our IPv6 addresses if more of us start doing this workaround.

I went to the following links and downloaded the files to my Win10 PC.
Just entering the pages below starts the download.
Then I uploaded them to one of my Linode servers web sites.
I ran chown clamav.clamav on the files and copied them to:
/var/lib/clamav

This seems to have worked. A bit of a hassle but it's done.

https://database.clamav.net/daily.cvd
https://database.clamav.net/bytecode.cvd
https://database.clamav.net/main.cvd

~bill~

Instead of that sort of hackery, I just procrastinated, and it's been working since yesterday (last failure was ~3PM EDT Tues Mar 23), so it might be worth trying the usual method again.

Andy

Hi ALl, have you all seen this to be resolved? I am getting 429 errors on a new install of clamav.

Best,

J

Hi all,

FYI, on the present date - 10 Aug 21 - the problem still pressits:

Tue Aug 10 10:25:04 2021 -> ClamAV update process started at Tue Aug 10 10:25:04 2021
Tue Aug 10 10:25:04 2021 -> ^Cool-down expired, ok to try again.
Tue Aug 10 10:25:04 2021 -> daily database available for update (local version: 26231, remote version: 26259)
Current database is 28 versions behind.
Downloading database patch # 26232…
Time: 0.2s, ETA: 0.0s [========================>] 16B/16B
Tue Aug 10 10:25:05 2021 -> ^downloadPatch: Can't download daily-26232.cdiff from https://database.clamav.net/daily-26232.cdiff
Tue Aug 10 10:25:05 2021 -> ^Incremental update failed, trying to download daily.cvd
Time: 0.1s, ETA: 0.0s [========================>] 16B/16B
Tue Aug 10 10:25:05 2021 -> ^Can't download daily.cvd from https://database.clamav.net/daily.cvd
Tue Aug 10 10:25:05 2021 -> ^FreshClam received error code 429 from the ClamAV Content Delivery Network (CDN).
Tue Aug 10 10:25:05 2021 -> This means that you have been rate limited by the CDN.
Tue Aug 10 10:25:05 2021 -> 1. Run FreshClam no more than once an hour to check for updates.
Tue Aug 10 10:25:05 2021 -> FreshClam should check DNS first to see if an update is needed.
Tue Aug 10 10:25:05 2021 -> 2. If you have more than 10 hosts on your network attempting to download,
Tue Aug 10 10:25:05 2021 -> it is recommended that you set up a private mirror on your network using
Tue Aug 10 10:25:05 2021 -> cvdupdate (https://pypi.org/project/cvdupdate/) to save bandwidth on the
Tue Aug 10 10:25:05 2021 -> CDN and your own network.
Tue Aug 10 10:25:05 2021 -> 3. Please do not open a ticket asking for an exemption from the rate limit,
Tue Aug 10 10:25:05 2021 -> it will not be granted.
Tue Aug 10 10:25:05 2021 -> ^You are on cool-down until after: 2021-08-10 14:25:05
Tue Aug 10 10:25:05 2021 -> main.cvd database is up-to-date (version: 61, sigs: 6607162, f-level: 90, builder: sigmgr)
Tue Aug 10 10:25:05 2021 -> bytecode.cvd database is up-to-date (version: 333, sigs: 92, f-level: 63, builder: awillia2)

• J

it is recommended that you set up a private mirror on your network using cvdupdate (https://pypi.org/project/cvdupdate/) to save bandwidth on the CDN and your own network.

Any Linode folks able to advise if this would be feasible, to host a ClamAV mirror on mirrors.linode.com?

@rdaniels, @tommydavidson, @jdutton, @jtoscani, @jyoo ?

@andysh that was something we discussed a bit back when this issue first arose, but in the end we worked directly with the folks at ClamAV to correct the issue that caused the blocking to begin with. While feasible, we aren't planning on hosting a mirror at this time.

@JayS would you mind opening a ticket or letting us know which data center (or even better, /24 IPv4 range) is showing that block? I was unable to reproduce from Linodes in Toronto and Mumbai, and I'd like to spin one up in your range to check.

Hey folks. Sorry this issue has popped back up (and thank you for sharing the feedback here). It seems like this was resolved last time after we worked directly with ClamAV.

We'll reach back out to ClamAV and see what can be done, then follow-up here when we have news.

@andysh: we looked into it a few months ago – we'll take another look at hosting our own mirror.

@JayS I wanted to follow up and let you know we've been in contact with ClamAV regarding the block of your Linode, and they let us know that they are now issuing blocks at the individual IP level rather than the ranges that originally prompted this thread.

This means that if your Linode was blocked from downloading an updated database with a 429 error, it was because either your Linode or the Linode that was just leased your IPv4 address prior was abusing the ClamAV service.

They also let us know that they are unable to manually remove the block, and that it will fall off in time after a period without abuse.