General

Bolting the Back Door with NAC
Part 4: Deploying the Juniper Networks UAC 2.0
— continued

by Lisa Phifer VP Core Competence, Inc. [June 25, 2007]

Building a foundation
Next, we carved a lab network into discrete subnets and VLANs to implement our policy. The resulting topology is summarized below. Note the location of each TNC component (PDP, L3 PEP, L2 PEP, NAR) and the path taken by access requests and subsequent authorized traffic.

We used third-party L2 PEPs to separate VLANs from each other—for example, insulating staff from guest and non-compliant endpoints. Guest packets were tagged based on Ethernet port or Wi-Fi SSID, but UAC let us tag staff packets dynamically, based on 802.1X authentication results. In other words, while we could quarantine managed laptops at layer two, we had to redirect agentless hosts using IP/port filters.

Inside each VLAN, host-to-host traffic could be blocked on the switch, the AP, or the endpoint itself. This degree of isolation is important during remediation to stop quarantined endpoints from attacking each other. Authenticated UAC Agents can be partly protected by Juniper's IC-configured Host Enforcer (below, right), but that personal firewall cannot help agentless or quarantined users. Instead, we configured our Colubris AP to block unwanted intra-SSID communication (below, left).

We relied on Juniper's L3 PEP (the SSG) to redirect unauthenticated users to the IC4000's login portal and enforce all higher-layer resource policies. Both our HP 2626 and Colubris MSC-3300 offered local captive portals. But we felt that redirecting all unauthenticated traffic to the IC was a more consistent, secure way to support guest/customer access and staff UAC Agent installation through one common portal.

L2 PEPs can only enforce go/no-go decisions and VLAN assignments. For more granular L3 control, we could have hard-coded ACLs into upstream devices—for example, blocking non-web packets from the guest subnet at the next router. Instead, we used UAC to dynamically add TCP/IP filters to our firewall. As the IC maps each endpoint to roles and resources, it can automatically provision stateful packet inspection policies on the SSG. This feature is one of UAC's biggest strengths, but we found that using it effectively required some education.

Deciding where to place the IC in a test network was simple, but careful consideration is warranted in a production network to avoid leaks and bottlenecks. When deployed at L2, the IC must be trunked to every controlled VLAN. Instead, we chose to deploy the IC at L3, using the SSG to route traffic from all VLANs to the IC.

After all of this planning, actual IC installation was remarkably simple. Beyond the usual IP addressing and license activation, we just had to satisfy a few basic pre-requisites:

• To prove its own identity, the IC needs a server certificate. Don't be tempted to take a self-signed shortcut—that will only cause repeated user warnings. Instead, install an IC certificate that chains to a trusted root CA and is bound to a resolvable name.
  
  
• For L2 (802.1X) control, all switches and APs must be configured to send RADIUS access requests to the IC's embedded SBR server. The IC must in turn be configured to recognize those RADIUS clients, based on IP addresses and shared secrets.
  
  
• For L3 (portal/firewall) control, UAC Infranet Enforcers like our SSG5 must be connected to a trusted IC and configured to let non-802.1X endpoints get IP addresses, resolve the IC's hostname, and send HTTP to the IC's portal.

 

Page one: Assembling the pieces

Page two: Charting a course

Page three: Building a foundation

>Page four: Users, endpoints, and roles

Page five: Resource access and policy enforcement

Page six: Conclusion