Windows Updates Versus Firewalls

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/help/globally-trust-listing-automox-through-epp-application-control

• 
  
• Local Agent and Log directories - Useful for configuring antivirus rules Location of Files Required By Automox
  
   

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:
    
     
  
  
   

docs.microsoft.com

Windows Update troubleshooting - Windows Deployment

Learn about troubleshooting Windows Update, issues related to HTTP/Proxy, and why some features are offered and others aren't.

* WSUS (if used in your environment)

• 
  
• Firewall considerations
  
   

Agent Firewall Whitelisting Rules

Tip: All managed systems will require access (and potential defined routing) to https://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.

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

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.

In the end we allowed the following url’s to allow updating to work properly for Microsoft systems but also adobe updates.

windowsupdate.microsoft.com
update.microsoft.com
windowsupdate.com
download.windowsupdate.com
download.microsoft.com
wustat.windows.com
ntservicepack.microsoft.com
prod.do.dsp.mp.microsoft.com
dl.delivery.mp.microsoft.com
delivery.mp.microsoft.com
tsfe.trafficshaping.dsp.mp.microsoft.com
microsoft.com
windows.com
nsatc.net
phicdn.net
windows.net
akadns.net
microsoft.com.nsatc.net
adobe.com
macromedia.com
packages.dmd.metaservices.microsoft.com
tlu.dl.delivery.mp.microsoft.com
au.download.windowsupdate.com