topic Re: Explicit allow to Microsoft Update services in General Topics

Explicit allow to Microsoft Update services

bhelman — Fri, 21 Jul 2023 14:40:20 GMT

I've read through a dozen questions and the scores of answers to those questions, and I'm finding a mix of outdated information, bad information or just unrelated options... I suspect this is going to send down a rabbit hole, so I'll try to compartmentalize based on my testing. I never progressed far enough to get close to a resolution.

So, the end-goal -- I have some systems that we want to have extremely limited Internet access: Chrome updates, Microsoft updates, a single specific website (not pertinent to this conversation). I haven't looked at Chrome updates yet. But I've spent a considerable amount of time looking at Microsoft.

The issue likes in the fact that MS needs several domains open, some with wildcards, to access MS Updates. That removes a simple FQDN object (in the destination field) as an option. I tried suggestions for Custom URL Category objects. I tried this (for testing):

Custom URL Object Test-FQDN-01

*.microsoft.com/

www.microsoft.com/

I then put that in a policy that BLOCKS my computer from being able to ping that custom url object (ie placing the custom url object in the Service/URL Category tab config). Commit and ... pings still work (allowed by the next policy). I never see it hit this test policy, so something isn't matching. BTW, www.microsoft.com resolves to an akamai address (that never changed during my testing). I then tried to add that akamai FQDN to the custom url object and ... still able to ping.

I did play around with creating a dedicated profile .. allowing the microsoft urls and blocking everything else. That works, but then I lose the ability to use this same definition to track systems going to ms update. It's also odd to have both an allow and a deny in the same policy (ie explicitly allow access to ms update while explicitly denying access to all other websites).

Another thing that crossed my mind - a simple rule that allows any internal to any external with application ms-update. EXCEPT ms-update requires ssl, so because the policies are "ands" in the application field, I've just opened up any https website.

This shouldn't be so difficult.

Re: Explicit allow to Microsoft Update services

BPry — Fri, 21 Jul 2023 20:10:11 GMT

@bhelman,

URL categories will never work for limiting ICMP requests. That simply isn't how ICMP functions and there would be no way for your firewall to know that you're attempting to send ICMP requests to "microsoft.com" because your machine will just send the request to the resolved IP address. The only way to accomplish that specific task would be FQDN objects and hoping that the firewall and the client actually keep the resolved address in check.

That addressed, the following list will function for getting Microsoft updates as a custom URL category. It may not be complete, likely isn't complete, and can change at any time.

<entry name="Microsoft Updates"> <list> <member>windowsupdate.microsoft.com/</member> <member>*.windowsupdate.microsoft.com/</member> <member>update.microsoft.com/</member> <member>*.update.microsoft.com/</member> <member>*.windowsupdate.com/</member> <member>*.download.windowsupdate.com/</member> <member>download.microsoft.com/</member> <member>*.download.microsoft.com/</member> <member>wustat.windows.com/</member> <member>ntservicepack.microsoft.com/</member> <member>stats.microsoft.com/</member> <member>amupdatedl.microsoft.com/</member> <member>*.events.data.microsoft.com/</member> <member>*.data.microsoft.com/</member> <member>smartscreen-prod.microsoft.com/</member> </list> <description>Used to account for Microsoft Update Traffic</description> <type>URL List</type> </entry>

You can then setup a policy that uses that category and allows app-ids [ ms-update ssl ocsp web-browsing ] with the category applied. This would allow updates to function, but it should prevent normal browsing access.

Re: Explicit allow to Microsoft Update services

bhelman — Fri, 21 Jul 2023 20:15:14 GMT

Thanks. I'll take a look at this Monday. I think I had tried this, but my testing methodology was obviously faulty.

Re: Explicit allow to Microsoft Update services

bhelman — Tue, 25 Jul 2023 17:53:05 GMT

Ok, I marked this as Accept, but it actually didn't work. I created a Custom URL Configuration with:

*.windowsupdate.microsoft.com\
*.update.microsoft.com\
*.windowsupdate.com\
*.download.windowsupdate.com\
download.windowsupdate.com\
download.microsoft.com\
wustat.windows.com\
ntservicepack.microsoft.com\
go.microsoft.com\
dl.delivery.mp.microsoft.com\
windowsupdate.microsoft.com\

Then I created a policy allowing the target sources access to that Custom URL Category (with app's ssl, web-browsing, ms-update and ocsp). It appeared to work, but then when I inspected the logs more closely, I saw someone hitting bs.yandex.ru via that new policy. Clearly that is not correct so I reverted.

Re: Explicit allow to Microsoft Update services

BPry — Tue, 25 Jul 2023 19:16:26 GMT

@bhelman,

I'd be interested in seeing the detailed log information that you were seeing in this instance. The firewall will need to allow enough traffic to read the URL, but as soon as it's identified the connection should be reset if the policy is setup properly.

Re: Explicit allow to Microsoft Update services

V.Benfanti — Sun, 05 Jan 2025 19:46:27 GMT

Hello @BPry and thank you for posting this, it was very helpful! I just found this list of Microsoft domains on Microsoft Learn -> Configure your firewall to allow your first WSUS server to connect to Microsoft domains on the internet

This is what I put in the URL Category:
*.delivery.mp.microsoft.com/
*.download.windowsupdate.com/
*.update.microsoft.com/
*.windowsupdate.com/
*.windowsupdate.microsoft.com/
download.microsoft.com/
download.windowsupdate.com/
go.microsoft.com/
ntservicepack.microsoft.com/
windowsupdate.microsoft.com/
wustat.windows.com/

Re: Explicit allow to Microsoft Update services

JohanSGS — Mon, 10 Feb 2025 09:31:17 GMT

That list looks familiar, but allowing it via url category in a rule with ssl, web, msupdate, soap, does still not solve the issue. I've got ssl forward proxy, I have my local certificate on fw and client, yet the first thing windows does it try to verify some certificate against www.microsoft.com. Which isn't allowed as it gives way to much more than just windows updates 😞 So if anybody has actual working solution for allowing windows updates in a truly restricted network (not using sccm, wsus or other proxying software of course) I'd be happy to hear how you made it work without comprising the isolation.

Re: Explicit allow to Microsoft Update services

BrunoPyck — Fri, 20 Mar 2026 09:26:12 GMT

Hi,
Sorry to dig up an old post, but did you ever got this working? I'm in the exact same position ..

Re: Explicit allow to Microsoft Update services

kiwi — Fri, 20 Mar 2026 11:19:46 GMT

Hi @BrunoPyck ,

As far as I know the solution by @BPry should work.

Taking the yandex.ru example... I understand why seeing yandex.ru hit that policy is alarming! But you didn't do anything wrong; you actually ran into a very common "gotcha" in how Palo Alto Networks handles URL identification.

When a security policy is restricted to a Custom URL Category, the firewall has a "chicken and egg" problem. It can’t see the URL (like windowsupdate.com) until the SSL/TLS handshake happens.

To identify the URL, the firewall must allow the first 3–4 packets of any HTTPS session to pass through so it can read the Server Name Indication (SNI) or the Certificate. During those first few packets, the firewall "optimistically" matches the traffic to your Microsoft rule. If the site turns out to be yandex.ru, the firewall eventually realizes it doesn't match, but by then, the session has already been logged against that policy.

The access to yandex.ru will ultimately be blocked.

The "leak" the user saw isn't a permanent opening; it's a temporary mismatch that happens while the firewall is "waiting" to see the URL.

That's my understanding... are you seeing different behavior ?

Kind regards,