[unisog] NAT'ing Quarantine Networks to Windows Update (M. Bertolani Out of Office (Automated Reply))

Michael Bertolani A00MJB1 at wpo.cso.niu.edu
Thu May 27 13:51:19 GMT 2004


I will be out of the office Thursday May 27, 2004.

If this is a matter that requires  immediate attention please call the
Customer Support Center at 752-8100 or e-mail them at helpdesk at niu.edu.

Thank You,
Michael

>>> unisog 05/27/04 07:44 >>>

We too are jumping onboard the Network-Registration boat. We're doing 
VLANs for our registration network and a "penalty box" network. When 
you're in the two private networks, your gateway points to a Linux box 
router. Using iptables, we allow all DNS traffic to pass through 
normally, but all other traffic is redirected to a local webserver. 
This way, we're not playing tricks with DNS. If you resolve yahoo.com, 
you'll actually get a yahoo IP address, but the traffic is stopped at 
the router.

Once you authenticate, we change your VLAN to the production network.

To do exceptions (Windows Update, Symantec, etc), we're using a 
combination of Squid and SquidGuard. They're configured not to cache 
anything, rather, to filter based on HTTP Hostname. For now, we're 
allowing anything to .microsoft.com or .symantec.com. This works to 
allow Windows Update traffic through, until WU switches over to HTTPS. 
At some point, WU traffic gets encrypted, meaning we can't examine the 
HTTP Hostname anymore, as it's part of the encrypted payload. To get 
around this, we're allowing all traffic to 443/tcp to flow through the 
router unaffected.

Hopefully this makes sense. I can elaborate more if needed,

Norman

------------------------------------------------------
Norman Elton
Information Technology - Network Engineering
College of William & Mary
757-221-7790


On May 26, 2004, at 6:09 PM, 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.
>
> My goal is to not have the clients install anything extra, but rather 
> to leverage the vendors pre-existing update mechanisms where possible:

> Microsoft's Windows Update, Symantec's LiveUpdate, Apple's Software 
> Updates, RedHat's up2date, etc.  In order to do this from their 
> private registration and/or quarantine networks we hope to enable PBR 
> on a Cisco 650x to route by source address (of those private networks)

> to a separate NAT network that connects the private IPs to the 
> Internet.  The NAT network can be a 7200 or a PIX or a well-tuned 
> Linux box.
>
> Jason Azze of Fairfield U already posted how they used (what BIND 
> calls) "selective forwarding" or "split DNS" to forward certain 
> domains to a public DNS server, and redirect all other requests to the

> internal registration / quarantine / remediation system.  His post can

> be found here:
>
> http://www.dshield.org/pipermail/unisog/2004-May/007203.php
>
> I know of at least one other University that also wants to do 
> something like this.  Has anyone else implemented this selective 
> forwarding successfully with the myriad of domains needed for Windows 
> Update?  How has it worked?  Is anyone else trying to NAT their 
> private registration / quarantine / remediation networks out to public

> update websites? Anyone figure out how to secure those NAT'd networks?
>
> And, the big question - anyone else want to help?  We already have a 
> few people working on different parts of this from different schools. 

> Final results will vary by school, but a lot of the infrastructure and

> methods should be very similar.  Anyone else in the same position that

> wants to throw their two cents in?  Anyone done with their design and 
> want to discuss the merits of their particular implementation?
>
> Thanks for your time, and good luck in all of your summer projects.
>
> Phil
>
> Sr Network Security Analyst
> New York University
>
> _______________________________________________
> unisog mailing list
> unisog at lists.sans.org
> http://www.dshield.org/mailman/listinfo/unisog

_______________________________________________
unisog mailing list
unisog at lists.sans.org
http://www.dshield.org/mailman/listinfo/unisog



More information about the unisog mailing list