cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6710
Views
0
Helpful
14
Replies

Anomalous client detection behaviour

tertang@cisco.com
Cisco Employee
Cisco Employee

Based on the tech zone documentation

https://techzone.cisco.com/t5/Identity-Services-Engine-ISE/Configure-Anomalous-Endpoint-Detection-and-Enforcement-on-ISE…

it states that if one of the significant changes(NAS port type, DHCP Class ID, Endpoint Policy) is detected, it should trigger a CoA to happen.

Our testing use cases included

1. client on wireless MAB, Malicious user on wired MAB

2. client on wired MAB, Malicious user on wired MAB

Use case 1 works as intended, however use case 2 did not trigger the CoA action/ AnomalousBehaviour attribute is not added to the endpoint and not enabled.

The profiler logs shows that based on use case 1, 2 significant changes(NAS port type & Endpoint policy) were detected and triggered the CoA for reauth.

However in use case 2, only 1 significant change was detected (Endpoint Policy) and not Coa was'nt effected.

What is the correct behaviour that we should be expecting? is it 1 or 2 or more significant changes required to trigger the anomalous client detection ??

1 Accepted Solution

Accepted Solutions

minor correction...  if device profiled as printer or phone and then transitions to workstation -- as would be case where user attempts to gain access based on the policy associated with easily accessible MAB endpoint -- then trigger anomaly.  The definition of printer would be printer profile or one that switches from well-known print device like Xerox.

View solution in original post

14 Replies 14

ldanny
Cisco Employee
Cisco Employee

researching...

Danny

kthiruve
Cisco Employee
Cisco Employee

HI Chin,

Use case 1 is supported. In case of use case 2 if dhcp class Id changed and/or if  a device appears as workstation and later same device appears as Xerox machine it will be detected.

In use case 2, NAS port type remains the same in your case so unless the above applies it is working as per intended.

Thanks

Krishnan

minor correction...  if device profiled as printer or phone and then transitions to workstation -- as would be case where user attempts to gain access based on the policy associated with easily accessible MAB endpoint -- then trigger anomaly.  The definition of printer would be printer profile or one that switches from well-known print device like Xerox.

bad client.png

I just did a test in lab. As shown above, I connect a meraki AP to switch_A and got in via MAB. I connect my laptop to switch_B and got in via dot1x. So far so good.

I then change my laptop MAC to that of meraki AP and login via dot1x on switch_B again. As shown above, ISE did not flag laptop as bad client. It change my laptop profile to meraki profile and allow both my laptop and meraki to continue working on network.

Is this the correct behavior?

But if I use my iphone and connect via wireless dot1x, then change my laptop MAC to my iphone MAC and come in via wired MAB, ISE does flag my laptop as bad client and CoA my laptop.

So the conclusion seem to be that if both client of same MAC come in via different switch, ISE cannot detect it as bad client and still continue to allow them on the network. Worst, it change the profile of one of them.

Appreciate for your advise.

Regards &

Have a nice day

Hi, I have ISE 2.4 Patch 5,Wireless deployment only, ISE has categorize a endpoint that endpoint profiling from Microsoft-Workstation > Window 10-Workstation, but this is not consider massive behavioral change, look like just something else wrong 1.PNG

Hi Krishan,

Our testing shows that use case 2 doesn't trigger a CoA.

There was a endpoint profile change, ISE detected it and there was a corresponding MACSpoofing event in the profiling log

"2017-12-04 06:47:27,944 DEBUG  [MACSpoofingEventHandler-30-thread-1][] profiler.infrastructure.probemgr.event.MACSpoofingEventHandler -:ProfilerCollection:- Received AttrsModifiedEvent in MACSpoofingEventHandler MAC: 00:18:0A:F0:C5:30"

but that did not trigger a CoA to happen, which brings me back to my original question, do we need 1 or 2 changes to trigger a Coa for anomalous detection to happen??

tks

-Terence

I will again be clear as to what will and will not trigger anomalous behavior:

1) Change in media from WIred to Wireless (or vice-versa) as indicated by NAS-Port-Type

2) Change in DHCP-Class-Identifier from one value to and non-empty value

3) Change in endpoint profile from printer or IP phone to Workstation.

I asked the author of TZ article to update the document to be more clear.  He kindly added the notes about examples per #3 above, but there is still ambiguity regarding detection of general profile changes.

General profile changes were deliberately NOT part of ruleset as that would have generated thousands of false positives and potentially become a major self-inflicted DoS attack.  Just look at your profile change summary report and realize all of those would have been flagged anomalous and potentially locked it remediation with CoA enabled.

If you have enabled remediation option and are not seeing CoA for legitimate case per items noted above, then you will need to open TAC case to troubleshoot.

Regards,
Craig

Hi Craig and Team,

any advise for my test in lab? This can be easily reproduced. I am using IOS DHCP server on switch to issue DHCP IP address to client. My wireless AP is a flexconnect AP and wireless client will get IP address from switch IOS DHCP too.

I am in competition with two other vendor and they all can do it except ISE. The use case for this global banking customer is to make sure no one spoof the printer MAC or any other device that are using MAB, to gain access into network. I have tested this in their environment and it don't work, thus I re-create this in lab.

Is this normal behavior of ISE? Or it should work and I need to open a TAC case and troubleshoot?

Regards &

Have a nice day

What can be easily reproduced?

Anomaly Detection is currently based on the rules outlined above. If meeting the above criteria and detection not working, then may need to open case with TAC.  If ISE does not receive the relevant profile attributes, then no, ISE cannot detect anomaly.  Although not specifically called out, I suspect you are not getting DHCP data in ISE Profiler since you have enabled local DHCP server, in which case the SWITCH is unable to relay a copy of the packets.  This is not an ISE issue/limitation.  You could SPAN traffic, but more feasible and optimal solution is to enable the switch or wireless controller for Device Sensor.  This will send DHCP and much more via an efficient RADIUS packet.

Craig

Hi Craig,

I have open below case and re-produce the issue for TAC and TAC has capture the debug log. You can get all info in the case note, including the two switch config.

SR 683579173 :  ISE Anomalous client detection behaviour

I need to solve it and proof to customer that it does work by Dec 22. Else we will lost the regional ISE project to the other two competitor. Whatever help you or team can give me to solve this issue is much appreciated.

Regards &

Have a nice day

As I have tried to explain, what you are seeing is expected behavior if relying on IP Helper.  If the issue is that you are using Device Sensor AND DHCP does in fact show change in Class-Identifier value from one explicit (non-empty) value to another non-empty value, then this could be a known defect as another account reported similar issue in past couple months. 

If this is specifically an issue with anomaly detection with Device Sensor, have TAC engineer search for potential defect.  TAC engineer can also send me a note if looking for details of other case.

Craig

Thanks Craig,

I have put device sensor yesterday into my two switches and tested this morning. Yup, it works...:-)

But the next challenge I have is this customer has different brand of switches. They have Cisco switches, Avaya switches, HuaWei switches as well as Juniper switches. Those 3rd party switches might not have device sensor. Any suggestion to make anomalous client detection work across Cisco and 3rd party switches? SPAN the network?

Regards &

Have a nice day

Yes, there is a benefit over 3rd-party with Cisco switches!

SPAN is option, but not likely feasible to address this use case. Other options is to centralize DHCP.

If choose to provide local DHCP service with 3rd-party, then customer may not be able to detect anomalous behavior based on DHCP data.  Other mechanisms will continue to work such as change in media type for same MAC, or change in profile from phone/printer to workstation.

reynaldolopeza
Level 1
Level 1

I know this is an old post. But someone can confirm me if anomalous detection and enforcement are available with Base licenses? Or Plus licenses?

Kind regards,

Reynaldo