So, let me provide a bit of history since I’m the one who made the switch to 
Cloudflare.

Long-time ClamAV users will recall that we had a series of donated mirrors. 
People would mirror our content and make it available in their respective 
countries.

However, the issue with this setup was that the mirrors were always lagging 
behind. They would frequently go up and down, and people didn’t know how to 
configure them for different countries. Maintaining all the relationships with 
the mirror administrators was an incredibly tedious task. They would often face 
DDoS attacks and other issues.

In response, Cloudflare offered to assist us. We figured out how to push the 
updates to their POPs whenever we published new content. We encountered some 
challenges along the way, such as some mirrors not receiving updates because we 
didn’t realize we needed to flush the cache occasionally. Nevertheless, we 
overcame these obstacles.

Then, we discovered the significant bandwidth we were serving when we 
redirected all the in-country DNS records to a single DNS record 
(database.clamav.net). We realized that we were serving approximately 1.2 
Petabytes of data daily. That’s when I made the decision to start blocking old 
versions of ClamAV downloads, similar to how we handled Snort. (I still 
remember a customer in Japan who was still attempting to download the Snort 
rules database for Snort version 1.7 every minute or so.)

Next, I analyzed the frequency of downloads. We had thousands of people 
downloading the database every minute, every 5 minutes, every 30 minutes, every 
hour, and so on. (This was happening even though we only published the database 
once or twice a day.) Consequently, we implemented rate limiting. We 
incorporated it into the update scripts and the ClamAV team (notably:Val) 
created cvdupdate as a standalone utility. We established controls that allowed 
us to restrict certain aspects, such as rates, and this significantly reduced 
the 1.2 Petabytes of data to a more manageable 30 or so Gigabytes per day (it’s 
been about 5 years, and I don’t recall the exact figures).

However, it’s important to note that Cloudflare’s IP addresses of their local 
POPs may change occasionally. Individuals who implement per-IP controls may 
encounter difficulties with this, but that’s a decision they make when they 
choose to implement per-IP controls.


— 
Joel Esler
Former ClamAV Open Source Manager
Miss you guys!

> On Jul 30, 2025, at 11:05, Paul Kosinski <[email protected]> wrote:
> 
> How might I keep up to date on the *specific* IP addresses at Cloudflare for 
> ClamAV database updates? They seem to change now and then.
> 
> I use ClamAV for email scanning, but I have my firewall (iptables) set up to 
> block outbound off-LAN TCP from my local Dovecot server machine with special 
> exceptions for the ClamAV-DB Cloudflare IPs on port 443. (In other words, 
> defense in depth.)
> 
> I just discovered that the old IPs I was allowing stopped working a while 
> ago. Now I see two "new" IPs that were being tried but blocked by my firewall.
> 
> If I 'dig', I get:
> 
>       $ dig database.clamav.net
>       ;database.clamav.net.           IN      A
>       database.clamav.net.    60      IN      CNAME   
> database.clamav.net.cdn.cloudflare.net.
>       database.clamav.net.cdn.cloudflare.net. 300 IN A 104.18.203.90
>       database.clamav.net.cdn.cloudflare.net. 300 IN A 104.17.196.15
> 
> suggesting that the IP addresses have a TTL of only 5 minutes! This would 
> seem to make it impractical to update my firewall rules often enough. (Also, 
> if I do repeated digs on this URL, I see the TTL counting down -- and then 
> recycling! Very strange.)
> 
> 
> I suppose I could permit outbound TCP (port 443) to 104.17.0.0/16, 
> 104.18.0.0/16 etc., but who knows what potentially dangerous stuff might be 
> hosted on those subnets, compromising defense in depth. And what other 
> subnets might be needed (the old one was 104.16.0.0/16, after all).
> 
> So maybe my best bet would be to allow the two current IPs and monitor the 
> log files more carefully. After all, the previous two IPs (104.16.218.84 and 
> 104.16.219.84) worked for quite a long time.
> 
> Any thoughts?
> 
> Thanks
> Paul Kosinski

_______________________________________________

Manage your clamav-users mailing list subscription / unsubscribe:
https://lists.clamav.net/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/Cisco-Talos/clamav-documentation

https://docs.clamav.net/#mailing-lists-and-chat

Reply via email to