My thanks to all who have suggested solutions to my problem. I thought about
them a lot, and they helped me come up with what turns out to be a rather
different approach.
Rather than attempting to keep the firewall up-to-date on what IP addresses are
valid for ClamAV's Database, which always risks falling behind, or getting
excessively complicated, I just created a simple TCP proxy on the firewall
machine, and then *fake* the IP of "database.clamav.net" on the mail-handling
computer (while keeping it TCP isolated otherwise).
The details are as follows.
1. The firewall normally has on a single local IP address on the LAN. This
address is used by any local computers which want Internet access. So I added a
separate LAN IP address for the firewall (call it $FWIPCLAM). Its sole purpose
is to carry ClamAV database traffic. (This same IP could also be used for any
other "isolated" ClamAV-running computers if needed.)
-------------------------------
2. The "isolated" ClamAV computer has added to its "/etc/hosts" file the line:
$FWIPCLAM database.clamav.net
(I had never put such a blatant fake into "/etc/hosts" before, and was pleased
it worked!)
--------------------------------
3. I use xinetd a lot in the firewall -- it's a very good way to implement
simple services.
So I added to the "xinetd.conf" file the following service:
service freshclam
{
type = UNLISTED
port = 443
bind = $FWIPCLAM
only_from = $FRESHCLAM
socket_type = stream
protocol = tcp
wait = no
user = nobody
group = nogroup
server = /bin/netcat
server_args = database.clamav.net 443
instances = 1
}
In the above "only_from", $FRESHCLAM specifies the local IP address(es) of the
"isolated" computer(s) running ClamAV.
This helps reduce the load on the real "database.clamav.net".
Also, the "instances" parameter might have to be adjusted if more than one
client ClamAV uses this service.
--------------------------------
4. I chose the xinetd approach as opposed to simply running "netcat -l"
directly because the simpler approach would only resolve "database.clamav.net"
when the listener was initially started, which would defeat most of the purpose
of all this. The xinetd approach means the IP is looked up each time a new
connection is made
--------------------------------
5. It has been working quite nicely for a few days now!
========================================================================
On Wed, 30 Jul 2025 11:05:31 -0400
Paul Kosinski via clamav-users <[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
>
>
_______________________________________________
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
