Monday, July 30, 2007
For the first time - 4.1.2 CAM/CAS guides in HTML
http://cisco.com/en/US/docs/security/nac/appliance/configuration_guide/412/cam/412_cam_book.html
CAS Guide:
http://cisco.com/en/US/docs/security/nac/appliance/configuration_guide/412/cas/412_cas_book.html
Friday, July 27, 2007
NAC Version 4.1.2
Cisco NAC Appliance Software Download Page
Requires a valid Smartnet contract in order to download
4.1(2) Documentation Page
Some of the feature "enhancements" that i found interesting and useful:
- NEW Cisco NAC Network Module (NME-NAC-K9) Support
Release 4.1(2) introduces support for the Cisco NAC Appliance network module (NME-NAC-K9) on the next generation service module for the Cisco 2811, 2821, 2851, 3825, and 3845 Integrated Services Routers (ISRs).
The Cisco NAC Network Module for Integrated Services Routers supports the same software features as the Clean Access Server (CAS) on a NAC Appliance, with the exception of high availability. NME-NAC-K9 does not support failover from one module to another. The integration of CAS capabilities into a network module for ISRs allows network administrators to manage a single device in the branch office for data, voice, and security requirements. The NME-NAC-K9 network module is available as a single hardware module with 50-user and 100-user license options, and supports a maximum of 100 online, concurrent users.
Once initially installed, the Cisco NAC network module is managed in the CAM web console like any other Clean Access Server, and a single CAM can manage both CAS appliances and NAC network modules. To add the Cisco NAC network module to your network, at least one Clean Access Manager appliance (Lite, Standard or Super) must be already installed and configured.
Cisco ISR platforms need to run Cisco ISO software Release 12.4(11)T or later (IP Base image or above) in order to support the Cisco NAC network module.
If introducing the Cisco NME-NAC-K9 network module to an existing Cisco NAC Appliance network, you must upgrade all CAM/CAS appliances to release 4.1(2) for compatibility.
Look out for an upcoming blog entry to show how to deploy the Network ModuleUTILIZE THE GUI:
CAM web console:
Device Management > CCA Servers > Manage [CAS_IP] > Network > IP | new Platform field featuring either "APPLIANCE" or "NME-NAC"
CAS web console:
Administration > Network Settings > IP | new Platform field featuring either "APPLIANCE" or "NME-NAC"
The CAS CLI includes the new service perfigo platform command in release 4.1(2). The command allows you to determine whether the CAS is a standard Clean Access Server appliance or a new Cisco NME-NAC-K9 network module installed in a Cisco ISR router chassis. The command output includes either "APPLIANCE" or "NME-NAC" as the platform setting.
- Debug Log Download Enhancement
Beginning with release 4.1(2), you can now specify the number of days of collected debug logs to download in order to aid troubleshooting efforts when working with Cisco technical support. Previously, debug logs compiled to download to technical support included all recorded log entries in the CAM/CAS database. The default setting is one week (7 days).
To review all enhancement, caveats and upgrade procedures please read the following release notes:
Cisco NAC Appliance 4.1(2) Release Notes
Please note that it is best practice to follow the upgrade procedures to the "T" when upgrading your NAC Managers and Servers.
For those of you just getting into the land of NACA, there is a very good presentation on the features that came about in Release 4.1(0) located on CCO called "What's New in Cisco NAC Appliance 4.1" that should catch you up on the latest and greatest features.
Saturday, July 21, 2007
Configure and Troubleshoot the Active Directory Windows Single Sign On (SSO)
NAC Appliance (CCA): Configure and Troubleshoot the Active Directory Windows Single Sign On (SSO)
Friday, July 20, 2007
VPN Deployments with ASA 8.0
One common design challenge in the past was how to deploy NAC for VPN Users when the VPN device is also a corporate firewall. This entry will hopefully help you understand the existing ways of deploying NAC for VPN Users and also help you understand how to design NAC for VPN Users with ASA 8.X.
NAC For VPN Users with a standalone VPN Device:
This is the typical deployment for VPN Concentrators, PIX/ASA (for vpn only), and IOS VPN Routers(for vpn only). The CAS is typically and preferred to be deployed in Virtual Gateway Mode. VG allows for zero IP Address changes and only requires the addition of 1 Authentication/Untrusted VLAN. For more information on how to configure NAC for Standalone VPN Devices please see the NAC Appliance (Cisco Clean Access) In-Band Virtual Gateway for Remote Access VPN Configuration Example
Figure 1 - VPN Deployment with a Standalone VPN Device
With this deployment you need to ensure normal internet traffic from corporate users does NOT go through the CAS. In order to accomplish this, the CAS is deployed using Real-IP Gateway and policy based routing is used on the next layer 3 hop from the firewall to send VPN Users traffic to the CAS's untrusted interface.
Figure 2 - VPN Deployment with a 6.X/7.X Corporate Firwall & VPN Device without a DMZ
In this scenario the PIX/ASA has a DMZ interface that is hosting public servers. If we look to the same deployment option as before, it presents a problem: VPN Users are able to get to the DMZ without having to go through NAC. This leave us with a couple of options:
- Block all VPN Users from getting to the DMZ
- Only allow specific services from VPN Users to the DMZ
- Allow everything to get to the DMZ without going through NAC
- Advanced Workaround using NAT on the Core Router (Not recommended)

NAC For VPN Users with a ASA 8.X Corporate Firewall/VPN Device with a DMZ:
This is what you all have been waiting for, how does VPN Deployment change with ASA 8.0? It all comes down to one new feature "Restrict Access to VLAN" (also know as VLAN Mapping).
Restrict Access to VLAN—(Optional) Also called "VLAN mapping," this parameter specifies the egress VLAN interface for sessions to which this group policy applies. The security appliance forwards all traffic on this group to the selected VLAN. Use this attribute to assign a VLAN to the group policy to simplify access control. Assigning a value to this attribute is an alternative to using ACLs to filter traffic on a session. In addition to the default value (Unrestricted), the drop-down list shows only the VLANs that are configured on this security appliance.
This configuration option is configured within the Remote Access Group Policy:
Please note that you must create an DOT1Q trunk and create the VPN DMZ interface using a subinterface for this option to appear. Now that we have a way to ensure VPN users get put onto a specific interface, we are able to deploy the CAS in Virtual Gateway mode and control complete access to VPN Users through NAC. This forces all users to go through NAC before they are allowed to do anything.
Summary:
Cisco's ASA 8.0 software has really made deployments with NAC for VPN Users a lot less complex. Utilizing the VLAN Mapping setting on the ASA is only going to open up doors down the road for even better seamless integration of NAC Appliance into your infrastructure.
Sources: CAS Admin Guide; ASDM Online Help
Wednesday, July 18, 2007
Cisco NAC Profiler Announcement
Great Bay Software Inc., the innovator of Endpoint Profiling for enterprise networks, today announced it has signed a worldwide OEM agreement with Cisco that adds the company's Beacon Endpoint Profiler solution to the award-winning Cisco Network Admission Control (NAC) product line. This agreement ensures that all network-attached endpoints, including non-PCs, meet the specified requirements for network access, creating the industry's most comprehensive NAC solution set.
As part of the agreement, Cisco will rebrand and sell the Beacon Endpoint Profiler as Cisco NAC Profiler. The Endpoint Profiling and Behavior Monitoring functions provided by NAC Profiler combined with the Cisco NAC Appliance solution will ease deployments and improve the security management of endpoints unassociated with specific users, such as network printers, medical imaging devices, IP phones, HVAC sensors and wireless access points. NAC Profiler can improve the return on investment for a NAC deployment by dynamically tracking the movement of these devices on the network.
The Cisco NAC Profiler provides a number of benefits both in the initial implementation of NAC and throughout the entire lifecycle of a deployment. Great Bay's Endpoint Profiling technology generates an automated inventory of all endpoints, significantly reducing the level of effort required in the implementation of NAC. The Cisco NAC Profiler informs the NAC system of critical endpoint data, including device address information, a type descriptor (printer, phone, AP, UPS, etc.), access type (a value that defines the appropriate level of access for that endpoint) and access to additional information about that device and its history in the network. This eliminates the need for manual inventories and data entry.
"We're excited to extend our collaboration with Cisco and to be part of an end-to-end NAC solution that provides a security model for all network-attached endpoints," said Steve Pettit, president of Great Bay Software. "Customers will benefit from Cisco's global business infrastructure and from the ongoing innovation this relationship will continue to deliver."
"Great Bay Software's endpoint profiling enhances an end-to-end NAC solution strategy," said Nick Chong, head of the NAC Appliance line of business for Cisco. "Cisco NAC Appliance, the leading NAC offering in the marketplace today, continues to represent the latest in technical innovation involving NAC, and adding Great Bay's profiling technology enriches our overall NAC solution."
Cisco's NAC Profiler will consist of two functional components in the NAC Appliance solution: the Profiler Server and the Collector Application. The Profiler Server will run on a dedicated appliance while the Collector Application will reside on the Cisco NAC Appliance Server. Cisco NAC Profiler is scheduled to be available in August 2007.
About Great Bay Software:
Great Bay Software Inc. is the innovator of Endpoint Profiling, a technology designed to rapidly establish and maintain a real time view of all network attached endpoints. The company's Endpoint Profiling technology has applications in enabling the deployment and administration of Network Admission Control and network-based authentication, in addressing compliance concerns related to unauthorized devices attaching to the Enterprise network, and in managing the endpoint lifecycle for all network attached devices.Summary:
I have been working with beacon for over a year now and have had nothing but success for deployments and the customers on-going operations. It is the fries with burger when it comes to NAC in an enterprise environment. Next time you are planning a NAC deployment for your integration or are sick of adding device filters every time a new phone or printer is brought up check out Beacon!
Sources: MarketWire; Great Bay Software
Sunday, July 15, 2007
Timers
Background:
Cisco NAC Appliance is a great method of threat containment by ensuring users' identity and posture, but at what point do you want to ensure that the user whom has once been compliant is still indeed compliant? This is the reason why timers are such an important aspect of any NACA Deployment. This entry will help you to understand the different options within NAC and ensure that you configure what is needed for your deployment.
The Options:
- Certified Device Timer
- Automatically Clear Certified Device List at specific intervals (X number of days)
- May clear devices based on particular CAS, User Role, Auth Provider
- May clear X amount of users at a time
- May create multiple timers to meet your needs
- Session Timer
- An Absolute Timer that is specific to the user role (X number of minutes)
- Applies to both IB & OOB
- Triggers after a preset time to kick users off the online user list
- Heartbeat Timer
- Number of minutes after which a user is logged off the network if a device is non responsive (in-band only)
- CAS sends an ARP request for the client for the set time (L2)
- CAS looks for traffic sourced from the user (L3)
- If proxy arp is enabled then the Heartbeat timer does nothing (L3)
- 5 Minute minimum
Best Practices for the use of Timers:
ALWAYS configure Certified Device Timers to enforce posture assessment after X amount of time for any Layer 2 or Layer 3 Deployment.
Use Heartbeat Timers to automatically remove inactive users when using IB.
Use User Role Session Timers for timeout of the Quarantine/Temporary User Roles and if you have a per role maximum connect time that is less than 1 day.
No matter where you are deploying NAC the discussion of how often you need to re-authenticate/posture assess a user should come up. Hopefully, you will understand the need and plan appropriately for you deployment.
For more information on how to configure these timers, please read the CAM Admin Guide or for hands on experience and instruction, please consider taking Priveon's Cisco NAC Appliance Special Operations Class.
Friday, June 22, 2007
Managed Subnets
The most misunderstood topic of the configuration of NACA is Managed Subnets. Every time I get a call about a LAN deployment, which is not working, the first thing I say is "Managed Subnets!". Hopefully, by reading this you will start to understand the taboo term and know when/where to configure Managed Subnets.
Managed Subnets Theory:
"For all CAS modes in L2 deployments (Real-IP/Virtual Gateway) when configuring additional subnets, you must configure Managed Subnets in the CAS so that the CAS can send ARP queries with appropriate VLAN IDs for client machines on the untrusted interface."
The first question you must ask during deployment is "are there more than one VLAN on the untrusted side of the CAS?" If so, you need to give the CAS "logical interfaces" so that the CAS can "manage" those vlans/subnets. The best way to think about managed subnets is to think about a "router on a stick" deployment; A single interface has multiple sub-interfaces in order to reduce the quantity of physical interfaces on the router. This concept can be applied to the CAS. The CAS uses DOT1Q trunking to logically manage multiple subnets. Why does the CAS need to do this? The CAS needs to be able to communicate with the clients on each of the subnets connected to it untrusted interface. This includes things like Web Redirection, SWISS Protocol, etc. The first step in communication is being able to arp and without managed subnets the CAS cannot arp for the clients off of its UnTrusted interface.
When to use Managed Subnets:
"Managed Subnets are only for user subnets that are Layer 2 adjacent to the CAS. For all CAS modes in L3 deployment, Static Routes must be configured for the user subnets that are one or more hops away. Managed subnets should not be configured for these subnets. "
Layer 3 Deployments = Static Routes
This logic can be used for In-Band/Out-of-Band, Real-IP/Virtual Gateway, Central/Edge Deployments. If you are a newbie to NACA please review the NACA ChalkTalks(CCO Login Required) before thinking too much into this.
How to configure Managed Subnets:
Managed Subnets are configured for each CAS at Device Management - Clean Access Server - manage X.X.X.X - Advanced - Managed Subnet
There are four configuration fields:
IP Address - This value varies based on the type of deployment:
- Real-IP Gateway: Think of router on a stick. This ip address will be the Default Gateway for the clients on the UnTrusted VLAN.
- Virtual Gateway: This needs to be an UNUSED IP address on the network.
VLAN ID - This is the VLAN ID of the UnTrusted VLAN. EVEN when using Virtual Gateway.
Description - Let remember that the next engineer might not understand managed subnets and needs to read this to get a better understand. Use best practice descriptions.
Summary:
Managed Subnets are something that are overlooked a lot, but after you take the time understand them, they really are just another check on the deployment checklist. Make sure that the next time you are practicing NACA, create a lab scenario that requires managed subnets! Cheers!
Source: CAS Admin Guide
Wednesday, June 6, 2007
Mapping Users to Roles using LDAP
NAC(CCA) 4.x: Map Users to Certain Roles Using LDAP Configuration Example
Make sure you check it out before your next LDAP auth server deployment.
Saturday, June 2, 2007
Cisco NAC Appliance Book
Cisco NAC Appliance: Enforcing Host Security with Clean Access
Book Description:
The ultimate reference guide for the Cisco NAC (Network Access Control) Appliance with easy-to-follow guides to major security applications
- Learn how Network Admission Control can make your network more secure
- Prevent security breaches by checking for and enforcing a host security policy at the network edge
- Master the design, configuration, deployment, and troubleshooting of the NAC Appliance solution
Cisco NAC Appliance from Cisco Press presents an overview of real world Cisco NAC Appliance (formerly known as Clean Access) deployment scenarios. The book provides best practices for communicating to the user community before deploying the NAC Appliance and how best to plan/design for the eventual merger of NAC framework and NAC Appliance solutions. The majority of viruses and worms in existence today would be successfully stopped using an up to date operating system along with an up to date anti-virus client. The concept of checking how up to date a host's operating system, antivirus client, and spyware removal tools are before they are given access to the network is relatively new. It is not so much the operating system's or anti-virus client's lack of ability to stop the majority of attacks so much as it is a company's lack of ability to enforce, at the network layer, security policies that require endpoint systems to have updated patches and AV software installed. This ability is the essence of what the Cisco NAC Appliance provides. This book is the ultimate reference to the Cisco NAC Appliance, and is an essential book in the library of any networking professional that works on host security or security policy enforcement.
About the Author:
Jamey Heary, CCIE No. 7680 is a Security Consulting Systems Engineer at Cisco. James also holds CISSP, CCSP, CCNP, CCDP, and Microsoft MCSE certifications, as well as a certified HIPAA Security Professional. He has a B.S. from St. Lawrence University.
Book Details:
Paperback: 550 pages
Publisher: Cisco Press; 1 edition (August 8, 2007)
Language: English
ISBN-10: 1587053063
ISBN-13: 978-1587053061
Saturday, May 19, 2007
Custom Checks – Personal Firewall Software
Background:
Many organizations require personal firewall software to be run on clients connecting into their network as a part of their security policy. This post explores how to create custom checks to enforce the use of personal firewall software on connecting clients. This is one of the most requested custom checks I receive and hopefully you will find it benefit.
Create Checks and Rules:
For this example, I am going to show how to create custom checks for 3 different types of Personal Firewall Applications. All of this software is free and can be downloaded. To create a custom check you must go to:
Device Management – Clean Access – Clean Access Agent – Rules – New Check
Windows XP Firewall Check
The most reliable way I have found to check for XP firewall is to use a Registry Check looking for the following Registry Value:
Registry Key:
HKLM\SYSTEM\ControlSet001\Services\SharedAccess\Parameters\FirewallPolicy\StandardProfile
Registry Value:
EnableFirewall
If the XP Firewall is on the Value will be = to “1”
Figure 1 – XP Firewall Check
Make sure to select the proper OS type and also “Automatically create a rule based on this check” so that you can use the rule later.
*** Please note that the registry value looked at does not distinguish between interfaces that the firewall is turned on, e.g. users could turn on the firewall for Wireless and be connected to the LAN and pass the check. If anyone finds a more reliable way, please let me know.
Zone Alarm Firewall Check
The status of Zone Alarm can be found by looking at services running on your MS OS. Zone Alarm creates service “vsmon” that can be checked using a Service Check to ensure it is running.
Figure 2 – Zone Alarm Firewall Check
Make sure to select the proper OS type and also “Automatically create a rule based on this check” so that you can use the rule later.
Comodo Firewall Check
Unlike Zone Alarm, Comodo does not create a service that we can monitor, but it does have a process running when it is turned on. When Comodo is running it runs a process called “cpf.exe”, which we can create an Application Check to ensure it is runnning
Figure 3 – Comodo Firewall Check
Make sure to select the proper OS type and also “Automatically create a rule based on this check” so that you can use the rule later.
These 3 Custom Checks should give you an idea of how to check for different type of personal firewall applications. I know this is only a list of 3 of many different SW vendors, but if you can understand how to find the information about your preferred software then you should be good to go.
Create a Requirement:
For this example I have chosen to create a Local Check to inform users that they do not have Personal Firewall Software running. Other options might be to send them to a Help-Desk website, Vendor Website or to present them with a preferred personal firewall software download. To create a new requirement go to:
Device Management – Clean Access – Clean Access Agent – Requirements – New Requirement
Figure 4 – Personal Firewall Requirement
Make sure to select the proper OS as all if you want to enforce it on all Windows OS.
Map Requirements to Rules:
Next, we must assign the rules we created from the custom checks to the new requirement. To Map Requirements-Rules go to:
Device Management – Clean Access – Clean Access Agent – Requirements - Requirement-Rules
Figure 5 – Personal Firewall Requirement-Rules Windows All
Figure 6 – Personal Firewall Requirement-Rules Windows XP
The most important notes about configuring the Requirement-Rules Mapping is to select “Any Selected Rule Succeeds” and making sure you map the rules on a per OS basis, e.g. the XP check is not applicable to Windows All, but it is applicable to Windows XP All.
Map Roles to Requirements:
Pick the role(s) that you want to enforce this requirement onto and check the new requirement. To map Roles to Requirements go to:
Device Management – Clean Access – Clean Access Agent – Role-Requirements
Then you must select the role and select the new requirement.
Summary:
Enforcement of the use of Personal Firewall Software is something that a lot of NACA deployment wants, and now you should be on the path of being able to do it.
Wednesday, May 16, 2007
Deployment Best Practices Series - Operations Acceptance of the Solution
Background:
Operations Acceptance of NACA is very important for a successful deployment. If Staff does not accept the solution than it will not be utilized to its capabilities or be maintained. This post is all about educating staff in order to ensure a successful deployment.
Introducing NACA to the Operations Staff:
NACA has to become an integral part of network and security operations in order to have a successful deployment. The following are some of the topics that Network Operations must be informed about:
- Clean Access Servers (CASs) act as an extension to the routers and switches in the network
- This causes network operations the need to understand how the CASs reside in the data path of users
- In an Out-of-Band (OOB) Deployment, netops has to understand the integration between the Clean Access Manager (CAM) and all access switches
- This requires the staff to have knowledge about SNMP Servers & SNMP Traps
- How to enforce security policy with NACA
- How to Review logs and report on users found non compliant
Introducing NACA to the Help Desk Staff:
Help Desk is the nerve center of a NACA deployment. Ensuring that the HD staff can help users when issues happen is imperative to making them successful. Keys to empowering your help desk staff are:
- Train them about common issues
- Ensure they have proper access and knowledge of how to access the information needed to troubleshoot or help users
- Have a documented escalation path (e.g. help-desk - operations -engineering - Cisco TAC)
Summary:
Operations & Help Desk Staff are sometime forgotten about, but their knowledge and support of the NACA deployment is critical to a successful deployment.
Tuesday, May 15, 2007
Deployment Best Practices Series – Deployment Expertise
NAC Appliance is a product that can looks very easy to install. For most people, this can be the start of many problems. It is important to realize that the product is made to be easy and that level can be obtained, but a lot of hours are required to realize the Ins and Outs of NACA. This post is all about the misconceptions about what level of knowledge a deployment engineer should have, as well as the steps engineers can do to get to that level.
Understanding the Learning Curve:
NAC Appliance is a product that does deploy very quickly. For smaller deployments, it can be stood up and working in just hours, but this is for engineers that have taken the time to understand it. The more hours you spend looking into the CAM GUI the easier things get. This product gets confusing in a few instances:
- Customization of Posture Assessment and Remediation
- Going above and beyond the normal of Windows HotFixes and AV Installation/Definitions
- Truly enforcing security policy with CCA
Deploying on a complex network - The network is not following best practice design methods
- There is not a deterministic Layer 2 or Layer 3 path from the client to a central point
Getting the most of NACA:
The reason that Expertise in deployments is so important for a successful rollout is the fact that the product has so many small caveats and non-publicized features that can truly make or break the deployment. I personally would like to advertise the interesting custom checks that an experienced NACA engineer can use to enforce security policy. A minor list of examples being Preventing Instant Messenger, Peer-to-Peer, Sniffer Applications or checking for Group Policy features.
Making sure you do not fall victim of lack of expertise:
The following are best practice ways to ensure that the deployment goes well by ensuring that you have the skills it takes to deploy NACA. Any one topic will help you get experience, but the more you perform the better the deployment will go:
Formal Training – Find a class that teaches NAC Appliance. Ensure that the content matches your deployment strategy and the instructor ACTUALLY has experience with NACA in the real world. Stay astray from the “cookie cutter” type classes. Priveon, a security training company, has really world class training program for this type of training or you can always request custom training from a local Cisco Partner.
Research – Use the resources available to you to inform yourself about NACA Deployments. This can be performed via the NACA Chalktalks, NACA Documentation, whitepapers, etc.
Lab Experience – Getting NACA into the lab so that you can test the features and functionality that you want to deploy in a controlled environment can give you the knowledge and experience to become prepared for the real deployment is key to a successful deployment. This phase should come before any pilots.
Consultant Help – There are many external resources available for you to either give you a turn key solution or assist in your deployment of NACA. The reasons behind this investment could be resources or technical expertise, but the key to using this resource to your ability is making sure you shadow and learn from the consult deploying NACA.
Summary:
Many organization fall victim to “I thought I could get it working” and then really do not receive the benefits of NAC Appliance. This is the reason why to have a successful deployment you must have experience with the product.