Windows Updates Versus Firewalls

Just wondering if there are others out here that have internet access disabled for servers and are having trouble getting windows updates allowed. We are struggling with this and notice an inconsistent Automox experience because of this.

We have allowed almost every known URL of windows updates and the packages URL of Automox but just wondering how you are handling this.

That is a great question. I’ve been gathering some tips/best practices. Take a look through these resources, and let me know if you have additional questions. I would love your feedback so I can improve the list. (Apologies for the formatting).

Agent Functionality and Communications

  • Environmental Considerations
    • EPP Application Control - Globally Trust-listing Automox

https://support.automox.com/en/articles/4368262-globally-trust-listing-automox-through-epp-application-control

Tip: To ensure uninterrupted functionality, please consider if EPP\antivirus rules are required in your environment.

  • Customize Script Execution Location - Useful if you need to control where processes run on your endpoints. Change Automox Script Execution Location

  • Update Sources - Each managed device will need access to all update sources when scans and when policies run. Notable updates sources are:

    • Windows Update sites:
* WSUS (if used in your environment)
  • Firewall considerations

Agent Firewall Whitelisting Rules

Tip: All managed systems will require access (and potential defined routing) to api.automox.com* port 443

Tip: IP addresses for the API change often and dynamically. If an IP list is required by your organization, the following article provides a suggestion on how to identify the current IP list. Please ensure to keep firewall exceptions up to date:

Tip: Required Applications or Worklets with uploaded content will be stored in Amazon s3. A rule should be configured to allow access to automox-policy-files.s3.us-west-2.amazonaws.com*

  • Proxy and routing

Using the Automox Agent With a Proxy Server

Tip: Starting with agent version 29, Windows will automatically identify proxy settings if they are set per the current user or set for the system.

Tip: devices behind a proxy may need a route to be configured (e.g. pac file or proxy application permissions). Add routing if needed.

2 Likes

This is great, the only downside the microsoft article is not up to date there are essential url’s missing. So far i came up with the following url’s

Windows URL’s (TCP/80-443)

microsoft.com windowsupdate.com nsatc.net phicdn.net windows.com

All Windows updates URL
*.delivery.dsp.mp.microsoft.com.nsatc.net *.dl.delivery.mp.microsoft.com* *.wac.phicdn.net *.windowsupdate.com* *dsp.mp.microsoft.com *dsp.mp.microsoft.com.nsatc.net *emdl.ws.microsoft.com* *geo-prod.do.dsp.mp.microsoft.com* *prod.do.dsp.mp.microsoft.com* *wac.phicdn.net* *windowsupdate.com* au.download.windowsupdate.com* cs9.wac.phicdn.net download.windowsupdate.com* fe2.update.microsoft.com* fe2.update.microsoft.com* fe3.*.mp.microsoft.com.* fe3.delivery.dsp.mp.microsoft.com.nsatc.net fe3.delivery.mp.microsoft.com* fe3cr.delivery.mp.microsoft.com fe2cr.update.microsoft.com v10.events.data.microsoft.com v20.events.data.microsoft.com fe3.update.microsoft.com geo-prod.do.dsp.mp.microsoft.com sls.update.microsoft.com* sls.update.microsoft.com* slscr.update.microsoft.com slscr.update.microsoft.com* tsfe.trafficshaping.dsp.mp.microsoft.com sls.update.microsoft.com fe2.update.microsoft.com fe3.delivery.mp.microsoft.com au.download.windowsupdate.com sls.update.microsoft.com.nsatc.net fe2.update.microsoft.com.nsatc.net fe3.delivery.dsp.mp.microsoft.com.nsatc.net audownload.windowsupdate.nsatc.net

Hey @Maikel, that is a good point. I think some of these links are delving into Windows 10 connection points in addition to Windows Updates. If that is the case, do these links help complete your list?

and for Office 365

1 Like

i have used those articles but also dns sniffing tools to get to this set of url’s still it’s tricky if your firewall is not really application aware.

I totally agree. I once worked for a large enterprise in the physical security sector. They had hundreds of firewall segregations with their own policy sets. At that time, each policy change required its own change request. When we rolled out Office 365, the firewall rule implementation was a nightmare. Microsoft was changing the endpoints very often at that point as well… That still makes me shiver, haha.

1 Like