Problems Authorizing Windows Updates - Firewalls

This is a discussion on Problems Authorizing Windows Updates - Firewalls ; I'm having some problems with firewall authorizations for Windows Update access in a DMZ. In general, I have had good luck getting access to Windows Update when you authorize passage of HTTP, HTTPS, and FTP to these networks: 131.107.0.0 / ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Problems Authorizing Windows Updates

  1. Problems Authorizing Windows Updates

    I'm having some problems with firewall authorizations for Windows Update
    access in a DMZ. In general, I have had good luck getting access to
    Windows Update when you authorize passage of HTTP, HTTPS, and FTP to these
    networks:

    131.107.0.0 / 16
    207.46.0.0 / 16
    64.4.0.0 / 18
    65.52.0.0 / 14

    In addition, I normally authorize these URLs for both http: and https:

    *.microsoft.com
    windowsupdate.microsoft.com
    *.windowsupdate.microsoft.com
    download.windowsupdate.com

    The problem I am having is that occasionally the DNS name
    "download.windowsupdate.com" resolves to some IPs on a huge network from the
    Limelight load balancing farm. When the client behind the firewall
    resolves that DNS to an IP, it then connects to the IP and the IP does NOT
    reverse back to the DNS name download.windowsupdate.com. Instead it
    resolves to some arbitrary name at the Limelight Network. So the firewall
    has no way of knowing that the connection is authorized. Further
    complicating all of this, download.windowsupdate.com does not always resolve
    to the Limelight load balancers. Microsoft appears to have these IPs
    pointing to load balancers all over the world. Some of the IPs I saw the
    download.windowsupdate.com domain name resolve to:

    208.111.148.50
    8.12.217.124
    192.78.223.126
    209.84.2.124
    etc

    Microsoft provides a set of DNS names to use with the ISA firewall, and
    naturally that doesn't work for the IPs above because they don't reverse to
    Microsoft domain names.

    No way do I want to authorize the entire Limelight load balancing network
    into my DMZ. There are a huge number of IPs, and those are probably
    associated with many hundreds of different organizations. When I do a
    whois on the IPs Microsoft is using, nothing in the huge range of IPs
    returned suggests which subset of the range is reserved for Microsoft use.

    It would be really really nice for those of us who actually think about
    security if Microsoft would publish openly the range of IPs it is using for
    Windows Update. Failing that, I am open to ideas here about how can one
    set up a reasonable set of firewall rules to securely connect to this
    wideranging set of IPs.

    --
    Will



  2. Re: Problems Authorizing Windows Updates

    Am Sun, 23 Mar 2008 00:33:12 -0700 schrieb Will:

    > I'm having some problems with firewall authorizations for Windows Update
    > access in a DMZ. In general, I have had good luck getting access to
    > Windows Update when you authorize passage of HTTP, HTTPS, and FTP to these
    > networks:
    >
    > 131.107.0.0 / 16
    > 207.46.0.0 / 16
    > 64.4.0.0 / 18
    > 65.52.0.0 / 14
    >
    > In addition, I normally authorize these URLs for both http: and https:
    >
    > *.microsoft.com
    > windowsupdate.microsoft.com
    > *.windowsupdate.microsoft.com
    > download.windowsupdate.com
    >
    > The problem I am having is that occasionally the DNS name
    > "download.windowsupdate.com" resolves to some IPs on a huge network from the


    Why don't you use a proxy?

  3. Re: Problems Authorizing Windows Updates

    "Burkhard Ott" wrote in message
    news:fs5rtp$qve$01$1@news.t-online.com...
    > Am Sun, 23 Mar 2008 00:33:12 -0700 schrieb Will:
    >
    > > I'm having some problems with firewall authorizations for Windows Update
    > > access in a DMZ. In general, I have had good luck getting access to
    > > Windows Update when you authorize passage of HTTP, HTTPS, and FTP to

    these
    > > networks:
    > >
    > > 131.107.0.0 / 16
    > > 207.46.0.0 / 16
    > > 64.4.0.0 / 18
    > > 65.52.0.0 / 14
    > >
    > > In addition, I normally authorize these URLs for both http: and https:
    > >
    > > *.microsoft.com
    > > windowsupdate.microsoft.com
    > > *.windowsupdate.microsoft.com
    > > download.windowsupdate.com
    > >
    > > The problem I am having is that occasionally the DNS name
    > > "download.windowsupdate.com" resolves to some IPs on a huge network from

    the
    >
    > Why don't you use a proxy?


    We use NAT on the firewall for all outgoing connections, and a proxy isn't
    going to improve much on that. The thing we are trying to prevent is the
    ability to reach unauthorized IPs by any means. If Windows Update has
    download.windowsupdate.com resolving to half the Internet, you end up having
    to open up through the firewall outgoing connections to a lot of hosts that
    could be used to control a compromised host or to further the compromise.

    --
    Will



  4. Re: Problems Authorizing Windows Updates

    "Will" wrote in
    news:WPCdnfC-BKS1BHvanZ2dnUVZ_vyinZ2d@giganews.com:

    .....
    >
    > We use NAT on the firewall for all outgoing connections, and a proxy
    > isn't going to improve much on that. The thing we are trying to
    > prevent is the ability to reach unauthorized IPs by any means. If
    > Windows Update has download.windowsupdate.com resolving to half the
    > Internet, you end up having to open up through the firewall outgoing
    > connections to a lot of hosts that could be used to control a
    > compromised host or to further the compromise.


    I understand that IPCOP is a free firewall that will run on an old box with
    multiple NICS.

    I am told that it can cache windows updates [and other things] for you.
    You might look at what it does and how.





    --
    bz

    please pardon my infinite ignorance, the set-of-things-I-do-not-know is an
    infinite set.

    bz+csf@ch100-5.chem.lsu.edu remove ch100-5 to avoid spam trap

  5. Re: Problems Authorizing Windows Updates

    Will wrote, On 23/03/08 17:53:
    > "Burkhard Ott" wrote in message
    > news:fs5rtp$qve$01$1@news.t-online.com...
    >> Am Sun, 23 Mar 2008 00:33:12 -0700 schrieb Will:
    >>
    >>> I'm having some problems with firewall authorizations for Windows Update
    >>> access in a DMZ. In general, I have had good luck getting access to
    >>> Windows Update when you authorize passage of HTTP, HTTPS, and FTP to

    > these
    >>> networks:
    >>>
    >>> 131.107.0.0 / 16
    >>> 207.46.0.0 / 16
    >>> 64.4.0.0 / 18
    >>> 65.52.0.0 / 14
    >>>
    >>> In addition, I normally authorize these URLs for both http: and https:
    >>>
    >>> *.microsoft.com
    >>> windowsupdate.microsoft.com
    >>> *.windowsupdate.microsoft.com
    >>> download.windowsupdate.com
    >>>
    >>> The problem I am having is that occasionally the DNS name
    >>> "download.windowsupdate.com" resolves to some IPs on a huge network from

    > the
    >> Why don't you use a proxy?

    >
    > We use NAT on the firewall for all outgoing connections, and a proxy isn't
    > going to improve much on that. The thing we are trying to prevent is the
    > ability to reach unauthorized IPs by any means. If Windows Update has
    > download.windowsupdate.com resolving to half the Internet, you end up having
    > to open up through the firewall outgoing connections to a lot of hosts that
    > could be used to control a compromised host or to further the compromise.


    Set up rules so that only the proxy can access anything on ports 80 and
    443 then the proxy can be set to only allow access to specific URLs.
    Then the only way they can access anything the proxy does not allow is
    by poisoning your DNS or accessing through some other port you have left
    open on the firewall.
    --
    Flash Gordon

  6. Re: Problems Authorizing Windows Updates

    "Flash Gordon" wrote in message
    news:nbdlb5xa1n.ln2@news.flash-gordon.me.uk...
    > Will wrote, On 23/03/08 17:53:
    >> "Burkhard Ott" wrote in message
    >> news:fs5rtp$qve$01$1@news.t-online.com...
    >>> Am Sun, 23 Mar 2008 00:33:12 -0700 schrieb Will:
    >>>
    >>>> I'm having some problems with firewall authorizations for Windows
    >>>> Update
    >>>> access in a DMZ. In general, I have had good luck getting access to
    >>>> Windows Update when you authorize passage of HTTP, HTTPS, and FTP to

    >> these
    >>>> networks:
    >>>>
    >>>> 131.107.0.0 / 16
    >>>> 207.46.0.0 / 16
    >>>> 64.4.0.0 / 18
    >>>> 65.52.0.0 / 14
    >>>>
    >>>> In addition, I normally authorize these URLs for both http: and https:
    >>>>
    >>>> *.microsoft.com
    >>>> windowsupdate.microsoft.com
    >>>> *.windowsupdate.microsoft.com
    >>>> download.windowsupdate.com
    >>>>
    >>>> The problem I am having is that occasionally the DNS name
    >>>> "download.windowsupdate.com" resolves to some IPs on a huge network
    >>>> from

    >> the
    >>> Why don't you use a proxy?

    >>
    >> We use NAT on the firewall for all outgoing connections, and a proxy
    >> isn't
    >> going to improve much on that. The thing we are trying to prevent is
    >> the
    >> ability to reach unauthorized IPs by any means. If Windows Update has
    >> download.windowsupdate.com resolving to half the Internet, you end up
    >> having
    >> to open up through the firewall outgoing connections to a lot of hosts
    >> that
    >> could be used to control a compromised host or to further the compromise.

    >
    > Set up rules so that only the proxy can access anything on ports 80 and
    > 443 then the proxy can be set to only allow access to specific URLs. Then
    > the only way they can access anything the proxy does not allow is by
    > poisoning your DNS or accessing through some other port you have left open
    > on the firewall.


    The most secure solution would be if Microsoft published a list of networks
    and IPs it wants to use for download.windowsupdate.com. I guess that won't
    happen.

    I guess you are right the only other solution is to rely on URLs correctly
    passing the target hostname in the URL, and firewall rules focus on the
    URLs. As you mention you are vulnerable to a DNS redirection by poisoning
    the cache. I'll work out something a little more secure than relying on
    just the URL but in general I know where I need to go and thanks.

    --
    Will



+ Reply to Thread