1. Home
  2. Networking Firewalls
  3. Windows Updates: Firewall setting for outbound traffic

Windows Updates: Firewall setting for outbound traffic

I tried posting this (twice) in microsoft.public.windowsupdate, but no response.

I have a network of 50 servers and 400 users. The servers run Win2k and Win2k3 and sit behind a firewall. For obvious reasons, I limit outbound traffic from the servers to the internet. This includes HTTP. I don't want my servers to be accessible, and I don't want them accessing any unnecessary external resources.

For example, We've had a flood of trojans in the past few weeks. The trojans call a server (outbound traffic) via HTTP then download the virus back in to the network. If I allow all outbound HTTP, then this opens my servers to being vulnerable.

My problem: I need to update my servers with MS Critical Patches. This means that I must create outbound rules on my main firewall allowing HTTP access to specific URLS or SUBNETS. I've allowed the following based on the articles I've read in the groups and on MS, but there are other sites involved as well that are not documented, and the IP addresses are constantly changing.

activex.microsoft.com download.windowsupdates.com crl.microsoft.com v3stats.windowsupdates.microsoft.com v4.windowsupdates.microsoft.com v5.windowsupdates.microsoft.com

207.46.0.0/16 64.4.0.0/16 38.113.0.0/16 64.62.0.0/16 64.152.0.0/16

Does anypne out there have a comprehensive listing of URLS and SUBNETS that need to be included as destination addresses in an outbound HTTP firewall policy to make sure that Windows Updates will work consistently?

My work around is to create an oubound policy to allow all HTTP traffic. I enable the policy while doing the updates, and disable it otherwise. This is not an elegant solution.

Also, I do use SUS in my environment, but not for the servers. I tried it with the servers and had problems with auto reboots even though I had de-selected this option in the group policy.

Thanks!

Your help is appreciated.

Reply to
bstover
Loading thread data ...

There is only ONE way to do this the "Right-Way"!

Setup a Microsoft Software Update Services server, or the new Windows Update Services (still in beta but being distributed...)

formatting link
Then you have ONE server downloading the updates, you get to approve which ones are deployed throughout your organization, you determine when the updates are downloaded (both from Microsoft, and from your SUS/WUS server to your organization), and when they are installed.

Everything is included in the package you download (the AD Policy snap-in may not be, but they tell you where to get it).

Do yourself a favor and put this in. I use it in my organization and it works flawlessly!

HTH

Smooter

Reply to
smooter

I'd recommend that you write your own OS and see if that's just as easy. I was told today that rubbing banana pudding on your under-carriage was great! Write me back to ensure that you understand and if you don't, I'd recommend that you take the love lotion and rub it on your back. Palabra?

Reply to
Munpe Q

I do have an SUS server and it works great. I do not use it for the servers, however, because I want more granular control over the reboot process. I tried using SUS for the servers, but I found that the servers reboot unpredictably even though I have choose the "no reboot" option.

Does anyone out there have a valid response to the following question:

Does anyone out there have a comprehensive listing of URLS and SUBNETS that need to be included as destination addresses in an outbound HTTP firewall policy to make sure that Windows Updates will work consistently?

snipped-for-privacy@norcalmutual.com wrote:

SUBNETS

Reply to
bstover

Do you have a vanilla install of Win2003? Look in IE, the trusted sites will show the URLs you need.

Reply to
William Tasso

Does anypne out there have a comprehensive listing of URLS and SUBNETS that need to be included as destination addresses in an outbound HTTP firewall policy to make sure that Windows Updates will work consistently?

Reply to
bstover

I know this is not what you want to hear, but allow me to re-iterate the advice of others: Use SUS for your servers. The Group Policy options for the Automatic Updates client clearly allow you to specify that the updates should be downloaded but not installed. This allows

*YOU* to manually install them at *YOUR* convenience with complete control over the reboot schedule, while still centralizing the downloads and retaining control over outbound HTTP access.

This can be easily achieved by creating a separate OU for your servers (I generally create separate OUs for client workstations and member servers and don't use the built-in Computers container), and then apply separate policies to those OUs to control the behavior of the Automatic Updates client. This will remove any issues you are currently experiencing with erratic reboots, since the updates won't be installed until *YOU* install them. (This also allows you to apply other Group Policy settings separately to client workstations--like turning off the Computer Browser, Messenger, and other services--without affecting your member servers or domain controllers.)

HTH.

Reply to
Scott Lowe

Very sound advice. Thank you.

Reply to
bstover

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.