Cisco Clean Access checks our users computers for Anti-Virus (Trend Micro) and Windows Patches (also check for many as well as forces sign on before access to the network can begin. Cisco Clean Access uses several applications and devices to make this all work:

• Clean Access Manager
• Clean Access Server
• Clean Access Agent
• Clean Access Stub
• SMS
• Policy Base Routes
• Traffic Control
• Microsoft Active Directory (Single Sign On, SSO)

Let’s touch on each of these and its role in enhancing our security posture.

Cisco Clean Access Agent

The Clean Access Manager (CAM @ 10.80.2.131) controls the Clean Access Server (CAS @ 10.90.2.2 & 10.90.2.10). When a user plugs into our network they are placed in an un-trusted VLAN – All traffic is Policy Base Routed (PBR) to the CAS while the user is in the un-trusted VLAN. This means all traffic must be read, routed and acted upon by the CAS. After authentication takes place the Cisco Clean Access Agent (CAA) scans the users registry settings and ensures Anti-virus is up-to-date as well as critical windows patches.

The Clean Access Stub allows non admin accounts to install patches. The Clean Access Stub should be installed prior to installing the agent. Using SMS to install the stub and client is highly recommended. If you can’t use SMS to install the full package then you need to install the stub and then let the CAS install the agent. The CAS will install the agent when a user accesses the untrusted VLAN and doesn’t have CAA installed.

Policy Base routes are used to “force” traffic to the CAS when users are in the un-trusted VLAN. So times PBR must be used to get traffic back to the clients.

Clean Access utilizes Traffic Control within the CAS to manage what users in the unauthenticated VLAN have access to. It’s used just like an access control list in a firewall or router.

When authenticating users Clean Access will first try to access Microsoft Active Directory and use the key acquired by the computer upon windows domain login. If this isn’t possible the user will be prompted with username and password authentication from the local DB on the CAM.

The flow is as follows:

Flow when no remediation required

User PC boots up  Cisco Switch puts them in un-trusted VLAN  CAA talks to CAM  CAA logs in user and checks updates  User PC passes validation  Cisco Switch places user PC in the normal VLAN

Flow when remediation is required

User PC boots up  Cisco Switch puts them in un-trusted VLAN  CAA talks to CAM  CAA logs in user and checks updates  PC gets updates  all traffic is passed through CAS and limited by CAS  User PC passes validation  Cisco Switch places user PC in the normal VLAN

Now when it comes to adding new offices or new devices you have to ask yourself, self, is this a layer 2 or layer 3 set up. Layer 2 is defined as any configuration where a device is connected to the CAM via Layer 2 hops only, IE no routers. Layer 3 setup is defined as any configuration where the PC is separated from the CAM by a router.

RetryDetection 5
PingArp 0
VlanDetectInterval 5

You’ll need to make these changes is you’re in an OOB layer 3 central server deployment with IP phones and can’t bounce the switch port after the certified device list is cleared.

example command

router(config)#ip route 14.2.3.198 255.255.255.255 null0

Why does this work? You’ll need to have something called “Unicast Reverse Path Forwarding” enabled on the border routers.  For every new flow that passes through the routers, they are verified against the route table to ensure that the traffic is coming into a valid interface for that route (an anti- spoofing mechanism).  Traffic that flows into an interface that doesn’t match a corresponding route in the route tables is dropped.

We leverage this by coupling it with /32 “null routes”.  When traffic flows into the border router, and we have a route to Null0 for the address, URPF looks at the route table, sees the entry for Null0, notices that the traffic is coming in on a different interface (OneNet connection), and drops the traffic.

Traffic initiated by one of our users toward a destination that has been “null routed” will just get dropped on the border router, as the router sends it to the Null0 interface (bit bucket) based on the information that we put into the routing tables for that destination address.

For more information on configuring URPF check out cisco’s website.

/perfigo/logs/perfigo-redirect-log0.log.0

This is where you will find CAS logs to display recent events on your clean access deployment.

There are three levels of logging

ALL – all logging

INFO – informational messages only

SEVERE – only severe messages (default)

To change the log level drive down to ADMINISTRATION –> CCA MANAGER –> Support Logs

Good luck with your NAC deployment

So if you feel you have to make that change, the file to look at is /perfigo/access/tomcat/webapps/auth/perfigo_login.jsp on the CAS. Look at the last few lines of this file.

Okay to modify perfigo_login.jsp just type

#vi perfigo_login.jsp

scroll down and find the lines mentioned below and hit the “d” key to remove the lines one at a time. Or you can modify them by pressing the “i” key

once finished hit the “esc” key and then type “wq!”

<%=btag%>
<font size=’1′>Powered by <a href=”http://www.cisco.com”>Cisco Clean Access</a></font>
<%=etag%>

Remove – <font size=’1′>Powered by <a href=”http://www.cisco.com”>Cisco Clean Access</a></font>

I also recommend removing the top of the html as follows

// @(#) perfigo_login.jsp Mon Feb 11 20:56:20 PST 2008
//
// Copyright 2006 Cisco Systems, Inc. All rights reserved.
// CISCO PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.
// Any unauthorized modification of this source code will be
// considered a violation of license terms and will void any warranty.