Microsoft Patches - firewall rules for bigfix server

Hi

Since this month we are having issues with downloading patches via BigFix Server. Generally download starts but then gets a timeout or connection rejected. I already talked with our Network Team and it looks like after download starts connection jumps to many different IPs including AWS. Since the rules are set to URLs as MS recommends and those IPs are not having anything set on rev lookup the connection is blocked.

Did anyone of you have similar issues? Any tips? Are there any recommendations from HCL what traffic should be opened to use different sites?

Thanks!

I’d recommend using a Proxy server to filter downloads by URL, rather than a firewall to block downloads by IP address. You’ll never stop trying to catch up with Microsoft, Red Hat, etc. updating their CDN and hosting networks.

Firewall is also set to filter by URL and everything worked till recently. From what I understood the issue is that when the download is initiated it connects to IP, rev lookup checks if URL is allowed, it is so download starts. Then the connection jumps to different IP which reverse lookup returns empty or not allowed so firewall blocks it :(. I was wondering if someone had similar issue.

Thanks for the proxy tip, not sure if possible but will try. Need to fix this quick as downloading patches manually as for a server in DMZ is painful :wink:

I guess the short answer in that case is no, we don’t track the IP addresses that Microsoft or any other vendor uses in their CDN or patch delivery systems.

Got it, will have to keep searching for a solution. Thanks for all the answers!

If anyone needs some links with recommended urls below. Didn’t help me but maybe someone else will be looking for that.

Just to circle back on this again for anyone trying to build a static list of IP addresses or URLs for downloads…in our work on Updates for Windows Extended, I’ve come across another case to consider - HTTP Redirects.

I’m working on a package now where the download file URL points to a url starting with https://github.com/, but the connection is redirected to https://objects.githubusercontent.com/github-production-release-asset.

That redirect is transparent to our content, but would not be transparent to a firewall/proxy. The ‘objects.githubusercontent.com’ link would not be retrieved by the session relevance queries we usually attempt to list download URLs, but might still be necessary to download the file.