Firewall rule to allow access to windows updates or other resources on a CDN?

What's the best way to poke a firewall hole in a border firewall to allow windows updates?

As far as I can tell, the windows update sites are hosted on a content distribution network that can potentially change IP addresses every 30 seconds.

If I "poison" our campus DNS with a static assignment for the sites, eventually I'll be pointing to sites that don't actually host the content anymore.

Are there any IP addresses that host the update content that are guaranteed to never change?

In a more generic sense, how do people configure firewalls to allow access to resources hosted on CDNs where the IPs are going to change constantly? The firewall just sees to/from packets and doesn't necessarily know what url (if https) the request is going to, so the firewall doesn't have a direct way to see that this packet is going to the symantec virus definitions update site while that one is looking at a world-cup stream.

And, in my situation, I don't have the ability to just mandate a specific configuration on the systems on the network. Ah, the joys of working at a university...


Solution 1:

While I haven't tried this (see my comment above), I'm thinking that the best solution is further up the stack: using a proxy server.

You could configure something like Squid in front of your Windows Update machine(s) (or WSUS server more likely) and permit *.windowsupdate.microsoft.com and *.windowsupdate.com (and so on) while denying everything else; this could then be enforced on your edge firewall by blocking TCP 80/443 to your WSUS server and forcing proxy configuration for the WinHTTP service on the server(s) in question.

I'm going to need to implement this for a soon-to-be hardened server in a data center in the short term and will likely use this to accomplish it.

Solution 2:

I somewhat solved this problem by setting up reverse proxy servers and poisoning DNS.

  1. for each service, provision an IP address and bind HAproxy to that IP and configure HAproxy to take requests seen on that IP and forward them to the DNS address of that service. (10.10.10.30 proxies requests to www.apple.com, 10.10.10.31 proxies requests to update.microsoft.com, 10.10.10.32 proxies to windowsupdate.com, etc)

  2. configure that HAproxy server to use a non-poisoned DNS server

  3. poison campus DNS to point those services to the internal HAproxy IPs (windowsupdate.com -> 10.10.10.32, 10.10.10.30 -> www.apple.com, 10.10.10.31 -> update.microsoft.com, etc)

  4. make sure the proxy server's not subject to the outgoing traffic restrictions on the border firewall.

I've tested this on a limited basis and it does work. If/When this is put into real production it'll probably be done using an F5 instead of HAproxy.

Nevertheless, this is far more complex than just making the firewall allow access, but sadly, that doesn't seem to be possible.

I'm hoping someone has a more elegant solution than mine...