10-18-2016 08:58 AM - edited 03-11-2019 12:09 AM
Hello
I was having a look at MAC spoofing with ISE 2.1.0.474
I am using RADIUS/SNMP trap and query and DHCP probes. A Cisco 7911 phone correctly gets profiled as "Cisco-IP-Phone-7911". The endpoint in ISE shows all the correct cdp/lldp/dhcp details
When I connect my windows laptop (spoofing the phones MAC), the laptop is authenticated as the phone. The endpoint is still profiled as "Cisco-IP-Phone-7911" - the endpoint shows the correct dhcp details for the laptop but retains the cdp/lldp details of the phone previously profiled. I checked the NAD and the device-sensor cache has no cdp/lldp details for the connected laptop and device-sensor accounting sends only the laptop dhcp tlv's to ISE.
If I delete the endpoint from ISE and connect my laptop (again spoofing the phones MAC), ISE correctly profiles the laptop as "Microsoft-Workstation"
When I disconnect the laptop and reconnect the phone, ISE re-profiles the endpoint as a "Cisco-IP-Phone-7911" based on the newly learnt cdp/lldp info.
ISE can learn new endpoint details through the probes and re-profile an endpoint as shown above. Am I right in saying that ISE won't re-profile an endpoint based on the fact that some attributes (e.g. cdp/lldp) have stopped appearing - only when new attributes are learnt?
Thanks
Andy
Solved! Go to Solution.
10-20-2016 07:09 PM
Hello Andy-
What you are experiencing is correct and expected behavior with the current mechanics of ISE. There is an enhancement request that was put in place a while back but it hasn't seen much traction:
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCur48184
The only time a device would move from one profile group to another is when a profiling rule with higher Certainty Factor is hit. For instance, if you create a custom rule with CF of 100 and if that rule is hit then a profiled device will never move to another rule that has CF that is <= to 100.
As you can tell, profiling is not bullet-proof. This is why it is best practice to limit the network access for profiled devices. For instance, IP Phones should only need access to the voice subnets and the PBX, Printers should only need access to print servers on specific ports, etc
I hope this helps!
Thank you for rating helpful posts!
10-20-2016 07:09 PM
Hello Andy-
What you are experiencing is correct and expected behavior with the current mechanics of ISE. There is an enhancement request that was put in place a while back but it hasn't seen much traction:
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCur48184
The only time a device would move from one profile group to another is when a profiling rule with higher Certainty Factor is hit. For instance, if you create a custom rule with CF of 100 and if that rule is hit then a profiled device will never move to another rule that has CF that is <= to 100.
As you can tell, profiling is not bullet-proof. This is why it is best practice to limit the network access for profiled devices. For instance, IP Phones should only need access to the voice subnets and the PBX, Printers should only need access to print servers on specific ports, etc
I hope this helps!
Thank you for rating helpful posts!
10-20-2016 11:12 PM
Thanks Neno - I'll contact TAC and add some weight to the enhancement request. Once we are out of Monitor mode the key thing will be strict authorization for ISE profiled devices.
Cheers
Andy
10-21-2016 11:01 AM
Great! Thanks Andy! Let us know what Cisco/TAC has to say about it :)
Neno
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide