ISE's Evil Default

-
Whilst working with Cisco ISE recently, I became aware of a setting within the product that could be a major ‘gotcha’ if you aren’t aware of it. We’ll take a very quick look at it in this article.
Background
Tucked away in the depths of the Cisco ISE menu structure is a rather innocent-looking configuration setting under the ‘Anomalous Client Detection’ section of the System Settings. The option I’m referring to can be found in the following location in ISE 1.2:
Administration > System> Settings > Protocols > RADIUS
The screenshot below shows the settings page I am discussing:



The settings on this page have been provided to protect ISE in the face of an onslaught of misbehaving or mis-configured clients that may flood it with authentication traffic (and hence RADIUS traffic). In larger environments, this could become an issue and affect ISE’s performance.
Suppress Anomalous Clients
The tick-box ‘Suppress Anomalous Clients’ provides a very useful function by quieting down the ‘noise’’ that you will start to see in the ISE logs once a reasonable number of clients are using the network. Instead of providing a line of information for each client transaction in the clients logs, only the most recent successful event is shown, providing a more manageable list of transactions to view. This effect is provided by the ‘Suppress Repeated Successful Authentications’ check-box, which is checked by default.
Reject Requests After Detection
One default side-effect of selecting the suppression of anomalous clients is that by default, the ‘Reject Requests After Detection’ check-box is also checked (highlighted in the graphic above). This is the ‘evil default’.
One might expect this option to simply provide another level of event suppression for misbehaving clients. Unfortunately, having this check-box enabled will actually add clients to an internal black-list of misbehaving clients for the period specified in the ‘Request Reject Interval’ - 60 minutes by default. Clients on this black-list will be ignored by ISE and effectively excluded.
Unfortunately, from the information I have been able to uncover so far, the internal black-list of excluded clients is not available to view, so there is no obvious way of knowing which clients have fallen foul of rejection (and hence exclusion) for being an ‘anomalous client’.
Exactly what qualifies a client as being anomalous isn’t too clear - the ‘Detection Interval’ and ‘Reporting Interval’ provide some clues, but they still don’t provide any clues about how many times a client has to be ‘anomalous’ to trip the rejection criteria.
Failure Scenario
Although the feature discussed above may not seem particularly worrisome, there are situations when it can kick-in and potentially take down your whole network for an hour (using the defaults).
If there is an extended period of time where clients are failing authentication, then if the anomalous client settings are enabled and left at default, all clients may become effectively excluded for an hour. A scenario such as the failure of an external authentication source (e.g. AD) or a policy configuration error could create such a situation. And, yes, I am speaking from experience of falling foul of such a scenario.
I’m not sure of Cisco’s official recommendation for this particular area of configuration, but I would think it is at least worth winding down the default ‘Request Rejection Interval’  to a lower value than 60 minutes - that’s a long time to lose your clients.
References

Cisco ISE 1.2 User Guide: http://www.cisco.com/c/en/us/td/docs/security/ise/1-2/user_guide/ise_user_guide/ise_ui_reference_administration.html#pgfId-1293445

Popular posts from this blog

The 5GHz “Problem” For Wi-Fi Networks: DFS

-
Image
Wi-Fi networking provides us with 2 bands for the operation of wireless LAN networks: the 2.4Ghz band and the 5GHz band. The 2.4GHz band has a reputation of being something of a “sewer” of a band, due to its limited number of usable channels, the number of Wi-Fi devices already using the band, and the high levels of non-Wi-Fi interference that it experiences. Many wireless LAN professionals will generally advise that you put your “important stuff” on the 5GHz band whenever possible. 5GHz has far more channels available, a corresponding lower number of devices per channel, and generally suffers much lower non-Wi-Fi interference. However, beneath the headline of “2.4Ghz = bad, 5Ghz = good”, there lurks a shadowy figure that can be troublesome if you’re not aware of its potential impact: DFS. Background Wi-Fi networks operate in areas of RF spectrum that require no licence to operate. This is in contrast to many other areas of the radio spectrum that generally require some form of (p
Read more

What Are Sticky Clients?

-
Image
One term you'll often hear banded about when talking with Wi-Fi professionals is "sticky clients". I thought it might be worth spending a few moments exploring what is meant by "sticky clients", why they are generally considered to be a bad thing in Wi-Fi networks and some approaches to mitigate them. Background Many folks dealing with Wi-Fi networks often talk about the "sticky" characteristics of wireless clients when discussing client roaming within a W-iFi network. In an ideal world, we'd like to have access points providing ubiquitous coverage across our desired area providing high-quality, consistent client coverage where-ever we go. In this wonderful land of rainbows and unicorns, our clients would gracefully roam from AP to AP, detecting and associating with their closest AP throughout the coverage area to ensure their best connection speed at all times. Unfortunately, the real world doesn’t quite reflect this roaming-client
Read more

Microsoft NPS as a RADIUS Server for WiFi Networks: SSID Filtering

-
Image
The Microsoft Network Policy Server (NPS) is often used as a  RADIUS server for WiFi networks. It can provide authentication and authorization services for devices and users on a wireless network in a Windows Active Directory environment. In this article we look at how we can use NPS to provide authentication for WiFi users across a number of SSIDs. We have previously discussed how to authenticate groups of users using the same SSID and then assign them to a VLAN that is appropriate to their security authorization. However, there may still be instances where two or more SSIDs are in-use on a wireless network and we would like to base policy decisions on the SSID that the authentication request is being generated from. As an example, if we consider a school, perhaps we would like students to only be able to authenticate if they connected to the SSID: "Student_Net". Similarly,  staff should only be able to connect using the SSID: "Staff_Net". This would
Read more