Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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

share|improve this question
    
I have exactly this problem with hostupdates.vmware.com but I managed to eventually convince our FW team that their kit could firewall based on DNS entries and after months of tests they finally implemented this. –  Chopper3 Jul 30 '10 at 13:34
    
Oh, our firewall can keep a DNS and IP in sync, but with TTLs of some sites at 30 seconds and the firewall doing the sync every hour, that still leaves a huge window of the DNS response for a client request for foo.microsoft.com not matching the firewalls notion of foo.microsoft.com. I could also poison DNS by overriding TTLs, but yikes, that's a dark road full of monsters... –  chris Jul 30 '10 at 13:40
    
I'm very interested in this as well. Could you use a proxy with a whitelist only permitting *.windowsupdate.microsoft.com and *.windowsupdate.com? –  gravyface Jul 30 '10 at 14:44
    
I must be missing something, but if Windows establishes its connections outbound to the update site, why poke a hole? Wouldn't outbound http/https connections be open by default unless a site is blacklisted? –  Paul Jul 30 '10 at 15:11
    
@paul: We're implementing NAC and requiring users to comply with a policy prior to being allowed to use the network. This means we're not allowing outgoing traffic until your system has been updated and is properly patched. Chicken, meet egg. –  chris Jul 30 '10 at 15:15

3 Answers 3

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.

share|improve this answer
    
I don't control the systems on the network -- it's a university. The helpdesk staff would lynch me if I required users to configure their browsers to use a proxy server. I have thought about using a reverse proxy server and poisoning DNS for these services, but that's adding a lot of moving parts to solve this problem. –  chris Jul 30 '10 at 14:59
    
Yeah, that's crazy. Good luck. –  gravyface Jul 30 '10 at 15:17
    
That "Force proxy configuration" link does look pretty useful. I'll have to examine that more. Thanks! –  chris Jul 30 '10 at 15:21

My recommendation is to install WSUS on a server in your DMZ, and give it unrestricted access to microsoft.com

Then, through group policy, I'd point all your other machiens to use your WSUS server. There are a few up-sides:

  1. Only one server has access through the "firewall hole"
  2. You can control which updates go to which server from a centralized control panel.
  3. Reduced bandwidth usage, since only one server downloads from the Internet, the rest download over your LAN.
share|improve this answer
    
I don't have control over the end-point systems. They're student / faculty computers that aren't on the domain and aren't owned or managed by the campus IT organization. –  chris Jul 30 '10 at 15:13
    
Ah... missed that bit. –  Nate Jul 30 '10 at 15:24
    
It does add a delightful twist to the problem... –  chris Jul 30 '10 at 15:27
    
Does your firewall support DNS lookups? I.e. can you do unrestricted traffic based on DNS? If so, you can see here for a list of domains from Microsoft -- technet.microsoft.com/en-us/library/bb693717.aspx –  Nate Jul 30 '10 at 16:39
    
bross: Yes, but the firewall looks up the record once per hour and the TTL on the records is usually around 30 seconds or less so there is a giant window where the firewall thinks the domain is at one address (and has a hole for that address) but the client gets a different record and their connections get blocked by the firewall. –  chris Jul 30 '10 at 21:12

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

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.