Explicit allow to Microsoft Update services

[bhelman]

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. 

[BPry · Accepted solution]

@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. 

[bhelman]

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

[bhelman]

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.

[BPry]

@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.