(csget cron check) Failed to retrieve latest version from ConfigServer

[bills]

Hello all,

After seeing my web server slowing down while my ModSecurity logs were filling with IPs from AmazonAWS, googleusercontent, Microsoft cloud users, DigitalOcean, Tencent, Alisoft, etc., I blocked the IP ranges for all of those services / server farms.

Now I see the message that I put in the subject line of this post next to the "Manual Check" button, in my implementation of ConfigServer Security & Firewall within cPanel WHM.

I checked csf.pl, and the 'doupdate' subroutine has a variable DOWNLOADSERVER that points to a file of the same name listing download.configserver.com and download2.configserver.com as the download sources. I can not trace the source of the update downloads further than that.

Can someone tell me if configserver.com's download servers then redirect to one of the services / server farms that I have blocked? If so, which one and its IP?

TIA.

[bills]

Hello again, everyone.

I am still trying to find the IP address I have blocked that generates the "(csget cron check) Failed to retrieve latest version from ConfigServer" notice.

Domaintools.com says that configserver.com is registered in the UK:

https://whois.domaintools.com/configserver.com

Domaintools.com reports the configserver.com is located at this IP: 66.165.246.164, which is part of the Hivelocity network:

https://whois.arin.net/rest/net/NET-66- ... 65.246.164

However, I do not have any blocks on that IP or the hivelocity.net IP range. Any insights about the csf notice would be appreciated.

TIA.

[thirdhost]

I'm only aware of two download servers for all CS products.

download.configserver.com - 94.130.90.175 - (94.130.0.0/16 - Hetzner DC)
download2.configserver.com - 54.36.165.115 - (54.36.0.0/16 - OVH DC)

Execute a CSF grep command against those two IP addresses to determine if they are matching any chain or IPSET list within your current ruleset, (e.x. csf -g 54.36.165.115). In your csf.conf if you're dropping outbound traffic for blocked IP addresses or subnets, an easy test would be to see if you can just ping those two IP addresses from your server. If you're receiving an "Operation not permitted", it is likely your blocking the remote IP or CIDR somewhere within your ruleset.

Would recommend exercising caution in outright blocking ISP traffic (AWS, DO, etc.). Lot of legitimate user traffic (i.e. VPNs, distribution/service mirrors, etc.) originate from these providers. The malicious traffic tends to be temporary for a few weeks.

[bills]

Thank you, thirdhost.

Good information, and a good testing strategy as well.