Basic Mac Spoofing using Whitelist Endpoint Group + Endpoint Device Profile

[tertang@cisco.com]

We're trying to implement a basic MAC Spoofing detection by using a combination of  a Endpoint whitelist group based on MAC addresses and a Authorized Device Profile tied together in a policy. ie Whitelisted Printer MAC address + Printer logical profile condition.

However the behaviour that we're seeing is that there is no profile change or update in the endpoint device type when it is being spoofed

We do see additional endpoint attributes added to the endpoint but the device profile does not get updated.

This allows the spoofed device then to get the authorizations meant for the printer.

This is the intended behaviour?

[vrostowsky]

Chin-

Do you have plus licensing?  What version of ISE are you running?  If you have a static mac condition, then make sure you have that rule above any other that it may be matching under MAB.  You will also want to turn on IP Device tracking and check the attributes to see what is available to match in your conditions.  I am not sure if you are profiling the device types, but if you are using a static mac condition, you can still match and change the profile based on other attributes.  Ensure your devices are COA enabled then watch the RADIUS logs as you test your policy

HTH-

Vince

[Jason Kunst · Accepted solution]

Would recommend you upgrade to a release that supports anomalous behavior detection. Recommendation would be for version 2.2 with the latest patch

https://www.cisco.com/c/en/us/support/docs/security/identity-services-engine-22/200973-configure-anomalous-endpoint-detection-a.html

Should also be considering plus licensing otherwise you’re going to be doing a hack work around it’s not recommended

[tertang@cisco.com]

Already on version 2.2 with the latest patch. Also had anomalous detection and enforcement enabled but it doesn't work in the environment.

trying to figure out why the endpoint profile doesn't get updated when spoofed by another device.

ISE profiler shows merged endpoint attributes of the spoofed printer; i.e. OUI = RICOH and attributes of the spoofing workstation. i.e. dhcp class identifier = MSFT 5.0

the customer environment only supports endpoint profile change as the anomalous detection triggering condition.

[paul]

The real solution here is to not try to stop someone that is spoofing a MAC or spoofing your profiling conditions.  That is a known and accepted risk when using ISE.  The way you counter is it by properly locking down your MAB results with DACLs.  If they spoof a printer MAC, you say "Congratulations you have gained access to the network, but you can only do printer functions."

The DACL lockdown phase (or TrustSec) is an important, but often neglected part of an ISE implementation.

[tertang@cisco.com]

i agree. but unfortunately its a specific POV clause that we need to fulfill and there's no 2 ways about it.

[paul]

Are you using the built in RICOH-Device rule or did you build a custom printer profile?

Even with the built-in rules your specific test may not work. The default RICHO-Device rule has a minimum certainty factor of 10. The default Microsoft-Workstation rule even though it is a 2nd level rule has a minimum certainty factor of 10. In my experience it is a crap shoot what profile will get picked when there is a tie on minimum certainty factor. And it probably isn’t going to move off of a profile when there is a tie. The 2nd level Microsoft-Workstation should really be a 20 in my opinion. The first level workstation rule is a minimum certainty factor of 10 as well. So it may not even move to that rule which means it won’t move to Microsoft-Workstation.

[Craig Hyps]

For specific use cases, you can achieve reclassification and optional quarantine using Exception Actions.

[jpoh]

Hi Team,

I have another ISE customer that is also Cisco voice customer. they have 12K phone in the network and currently going to enable dot1x on their infra. They plan to use MAB for all phone and thus will whitelist phone MAC in ISE. But they worry about MAC spoofing. Can our anomalous endpoint detection help in below case? They will enable device sensor on switches.

(1) user look at phone MAC and spoof into his laptop

(2) plug out IP phone and connect his laptop into the cable

Will anomalous endpoint detection help in above case?

Regards &

Have a nice day

[paul]

Anomalous detection may help but I would focus on DACL control which can be tough with voice, but possible.

For the person you are really worried about that is smart enough to realize the customer is running a NAC solution and grab a phone and spoof its MAC, they probably are smart enough to not expose profiling data to ISE that would allow anomalous detection to kick in. Like I said previously MAC spoofing and profile data spoofing is a risk you accept and limit the exposure of the risk with DACLs/TrustSec.

Paul Haferman

Office- 920.996.3011

Cell- 920.284.9250

[vrostowsky]

I agree with Paul. as i have my phones doing MAB, based on profile but have a DACL that limits the phones to the Call Manager servers and voice gateways.  since the phones are on a separate VLAN, it is a very clean way of limiting what devices on that subnet can do.

HTH

Vince

[paul]

The only issue with the phone DACL is softphones on PCs. You can’t just limit to voice subnets/voice servers/voice gateways. You would need to open up voice ports (there are many) to the data subnets as well if you are using softphones.

Paul Haferman

Office- 920.996.3011

Cell- 920.284.9250

[Scott Sams]

we have an objective to get 802.1x working with our phones but while we fight that nightmare, we chose to put VACLs to lock down the voice side.  we use voice vlans which to my understanding uses CDP/LLDP for the COA or vlan jump.  since a spoofed device does not respond to CDP/LLDP it ends up on the data vlan making our efforts pointless on VACLs.  any ideas there?

[Craig Hyps]

Phones have very specific DHCP Class ID values.  With Anomaly Behavior Detection, the DHCP Class ID will change if connect Windows PC with phone MAC.  Mac OS and Linux may not populate this attribute so will likely require Exception Actions today to detect the device change.