Cisco NAC Appliance

From Wikipedia, the free encyclopedia

Cisco NAC Appliance, formerly Cisco Clean Access (CCA) is a network access control (NAC) solution developed by Cisco Systems that helps ensure a secure and clean network environment -- the NAC appliance is however still referred to as Cisco Clean Access by some in the industry. Originally developed by Perfigo and marketed under the name of Perfigo SmartEnforcer, this network admission control device analyzes systems attempting to access the network and prevents vulnerable computers from joining the network. The system usually installs a small application known as the Clean Access Agent on a computer. This application, in conjunction with both a Clean Access server and a Clean Access Manager, has become quite common in many universities and corporate environments today. It is capable of managing wired networks in an in-band or out-of-band configuration mode, or Wi-Fi and Virtual Private networks (VPN) in an in-band only configuration mode.

Contents

[edit] Clean Access Agent

The Clean Access Agent (abbreviation: CCAA, "Cisco Clean Access Agent") resides on the client's machine, authenticates the user, and scans for the required patches and software. Currently the Clean Access Agent application is only available for Windows operating systems (Windows 98, Windows ME, Windows 2000, Windows XP, Windows XP Media Center Edition, and Windows Vista); most network administrators allow clients with non-Windows operating systems (such as Mac OS X, Mac OS 9, Linux, and FreeBSD) to access the network without any security checks (authentication is still required and is usually handled via a Web interface).

Beginning with version 4.1.0 of Cisco Clean Access, a Mac OS X agent has been added which supports authentication only, allowing for Mac users to utilize the single sign on capability offered by the CA solution. This is the initial release of the Mac OS X agent and further functionality is expected in future releases.

[edit] Authentication

After successfully authenticating via a web interface, the Clean Access Server will direct new Windows based clients to download and install the Clean Access Agent application (at this time, non-Windows based clients need only authenticate via the web interface and agree to any network terms of service). Once installed, the Agent software will require the user to re-authenticate. Once re-authenticated the Agent software will typically check the client computer for known vulnerabilities to the Windows operating system being used, as well as for updated anti-virus software and definitions. The checks are maintained as a series of "rules" on the Clean Access Manager side. The Clean Access Manager (CAM) can be configured to check, install, or update anything on the user's system. Once the Agent application checks the system, the Agent will inform the user of the result - either with a success message, or a failed message. Failed messages inform the user of what category(s) the system failed (Windows updates, antivirus, etc.), and instruct the user on how to proceed.

Any system failing the checks will be denied general access to the network and will probably be placed in a quarantined role (how exactly a failed system is handled depends entirely on how the Clean Access Manager is configured, and may vary from network to network. For example: a failed system may simply be denied all network access afterwards). Quarantined systems are then typically given a 60-minute window where the user can try to resolve the reason(s) for quarantine. In such a case the user is only allowed connectivity to the Windows Update website and a number of antivirus providers (Symantec, McAfee, Trend Micro, etc.), or the user may be redirected to a Guest Server for remediation. All other traffic is typically blocked. Once the 60-minute window expires, all network traffic is blocked. The user has the option of re-authenticating with Clean Access again, and continuing the process as needed.

Systems passing the checks are granted access to the network as defined by the assigned role on the Clean Access Manager. Clean Access configurations vary from site to site. The network services available will also vary based on Clean Access configuration and the assigned user role.

Systems usually need to re-authenticate a minimum of once per week regardless of their status; however, this option can be changed by the network administrator. Also, if a system is disconnected from the network for a set amount of time (usually ten minutes), the user will have to re-authenticate when they reconnect to the network.

[edit] Windows Updates

Clean Access normally checks a Windows system for required updates by checking the system's registry, and looking for the existence, nonexistence, or values of certain keys within said registries. A corrupted registry may keep a user from being able to access the network. In some cases, though, .INI files can be checked.

Systems currently authenticated via Clean Access will not be scanned until their next login attempt.

[edit] Security Issues and Concerns

[edit] Gaming consoles and MAC spoofing

Several universities allow game consoles, such as Microsoft's Xbox and Xbox 360, Sony's PlayStation 2, Playstation 3 and PlayStation Portable, and Nintendo's GameCube, Wii and the DS, as well as the TiVo digital video recorder, to access their networks. However, most of these devices do not have a web browser with which to authenticate. These devices are often exempted from authentication via Clean Access.

Many universities allow a gaming device to be registered via its MAC address, and any device with that MAC address will be allowed to access the network without authentication or review. Several possible security holes open up as a result:

  • The MAC address belongs to a computer, not a gaming console; this is likely done by people who don't want to install Clean Access, or be subjected to the annoyances of authentication and a check by the Agent application.
  • The MAC address was provided incorrectly, and will thus grant an unknown device immediate full access. (However, with the billions of possible MAC addresses, this is a very unlikely occurrence).
  • A user could change the MAC address of their own computer to match the gaming device's (a classic MAC spoof attack).

In response to this, the Clean Access Server can typically automatically detect if a device on the network is a gaming device (accomplished by looking up the manufacturer of the network interface by MAC address, in conjunction with a port scan).

The penalties for abusing the privilege of gaming devices (as described above) can be stiff, and often include banning the offender from the network. Punishment varies from institution to institution.

[edit] Device Posture Spoofing

At Blackhat 2007, Michael Thumann demonstrated how the security posture and asessment of a device by the Cisco Trust Agent can be spoofed programatically. As Thumann suggested in his presentation NACATTACK, the fundamental problem with Cisco's approach to Access Control is that in essence an untrusted device/user is being asked to validate its own posture.[1] Cisco took the unusual step and officially answered those allegations by pointing out that the NACATTACK presentation only dealt with posture spoofing and left out the authentication step into a network.[2]

While it is possible to simulate the connection between CTA and Cisco Secure ACS and spoof posture information, it should be noted that this affects posture validation, not authentication. Customers can use user authentication, as well as device authentication through IEEE 802.1x. If authentication is used, users will not be able to bypass authentication using the approach described in the presentation. Accordingly, unauthorized users (i.e., users with no credentials or invalid credentials) will not be able to gain access to the network using such approach.[3]

[edit] User Agent Spoofing

The Clean Access Server (CAS) determines the client's operating system by reading the browser's user agent string after authentication.[4] If a Windows system is detected, then the server will ask the user to download the Clean Access Agent; on all other operating systems, login is complete. To combat attempts to spoof the OS in use on the client, newer versions of the Server and Agent (3.6.0 and up) also probe the host via TCP/IP stack fingerprinting and JavaScript to verify the machine's operating system:

By default, the system uses the User-Agent string from the HTTP header to determine the client OS. Release 3.6.0 provides additional detection options to include using the platform information from JavaScript or OS fingerprinting from the TCP/IP handshake to determine the client OS. This feature is intended to prevent users from changing identification of their client operating systems through manipulating HTTP information. Note that this is a "passive" detection technique (accomplished without Nessus) that only inspects the TCP handshake and is not impacted by the presence of a personal firewall. [5]

[edit] Microsoft Windows Scripting

The Clean Access Agent makes extensive use of the Windows Script Engine, version 5.6. It was demonstrated that removal or disabling of the scripting engine in MS Windows will bypass and break posture interrogation by the Clean Access Agent, which will "fail open" and allow devices to connect to a network upon proper authentication.[6]

[edit] MAC Spoofing Prevention

[edit] Device Segregation

While MAC address spoofing may be accomplished in a wireless environment by means of using a sniffer to detect and clone the MAC address of a client who has already been authorized or placed in a "clean" user role, it is not easy to do so in a wired environment, unless the Clean Access Server has been misconfigured. In a correct architecture and configuration, the Clean Access Server would hand out IP subnets and addresses via DHCP on its untrusted interface using a 30 bit network address and 2 bits for hosts, therefore only one host could be placed in each DHCP scope/subnet at any given time. This segregates unauthorized users from each other and from the rest of the network, and makes wired-sniffing irrelevant and spoofing or cloning of authorized MAC addresses nearly impossible. Proper and similar implementation in a wireless environment would in fact contribute to a more secure instance of Clean Access.

[edit] Certified-Device Timers

In addition, mac-spoofing could further be combated with the use of timers for certified devices. Timers allow administrators to clear the list of certified MAC addresses on a regular basis and force a re-authorization of devices and users to the Clean Access Server. Timers allow an administrator to clear certified devices based on user roles, time and date, and age of certification; a staggered method is also available that allows one to avoid clearing all devices at once.

[edit] References

  1. ^ Blackhat 2007, NAC@ACK by Michael Thumann & Dror-John Roecher https://www.blackhat.com/presentations/bh-usa-07/Roecher_and_Thumann/Presentation/bh-usa-07-roecher_and_thumann.pdf
  2. ^ Cisco Security Response: NACATTACK Presentation http://www.cisco.com/en/US/products/products_security_response09186a00808110da.html
  3. ^ Cisco Security Response: NACATTACK Presentation http://www.cisco.com/en/US/products/products_security_response09186a00808110da.html
  4. ^ Index of /
  5. ^ Release Notes for Cisco Clean Access (NAC Appliance) Version 3.6(4) http://www.cisco.com/univercd/cc/td/doc/product/vpn/ciscosec/cca/cca36/36rn.htm
  6. ^ Release Notes for Cisco NAC Appliance (Cisco Clean Access), Version 4.1(2) http://www.cisco.com/en/US/products/ps6128/prod_release_note09186a008085b16f.html

[edit] External links