[unisog] NAT'ing Quarantine Networks to Windows Update
Cooper F. Nelson
cnelson at ucsd.edu
Fri Jun 4 18:57:50 GMT 2004
I've been researching this process a bit more and discovered that the
actual service packs and hotfixes come from download.microsoft.com via a
standard http transfer, so what I wrote below is incorrect. SSL is only
used for the windowsupdate activeX control and some html content. This
actually works out well as squid will cache the hotfixes and speed
deployment to the local net.
Cooper F. Nelson wrote:
> Ah, sweet serendipity, I've just been working on the very same thing.
> The biggest problem I've had is figuring out the BIND magic needed to
> override the relevant host names.
> In the meantime I've faked this by adding entries for
> windowsupdate.microsoft.com and v4.windowsupdate.microsoft.com to the
> hosts file for my test XP box. Both hosts resolve to a virtual IP on
> the NAT firewall.
> I'm using the "Shorewall" firewall on a Linux box to handle all the
> proxying and NAT'ing. For both sites I redirect all http requests to
> a Squid proxy cache on the same server. The actual updates, however
> are transferred via https from the v4.windowsupdate.microsoft.com
> host. For that traffic I setup a DNAT rule on the firewall to forward
> all sessions directly to that host. This way even a machine that has
> had all egress traffic filtered can still get updates. I've tested
> this on Win2K and XP and it works fine, even when all other traffic is
> Some notes:
> The windowsupdate and v4.windowsupdate hosts are load balanced and
> will resolve to different IP's at times. And of course, these IP's
> probably will change at somepoint, as may the hostnames themselves
> when SP2 is released (SP2 uses v5.windowsupdate.microsoft.com at the
> present). Keep that in mind.
> I would be happy to post my Shorewall rules if there is interest.
> Phil Rodrigues wrote:
>> Hi all,
>> Like many of you, NYU is trying to get a full-featured vulnerability
>> detection and remediation system in production before students
>> return. Some of you lucky &@#$'s even have it working already. :-)
>> In brief, the plan is to have DHCP and DNS servers very similar to
>> NetReg forward clients to our registration system, where a scan will
>> be requested. We are using LVS to cluster a few pieces of hardware
>> into one virtual Nessus server, and will either use nessus::scanlite
>> or something very similar to request a fast scan from the cluster.
>> If the host passes they get registered, if they fail they get
>> forwarded to a remediation website that instructs them how to fix
>> their problem. This should all sound pretty familiar by now.
> unisog mailing list
> unisog at lists.sans.org
More information about the unisog