Profile Transitions and the use of Exception Actions

[jitendrac]

How to avoid mac spoofing in MAB using Profiling Transitions and the use of Exception Actions 

We have ISE 3.3 Patch 3 deployed for one of our customer. For wired printer we are using MAB. For authentication and authorization, we are using the profiling service of PSN. Below is the policy set created

• Policy Set Name - IL-Wired-MAB
• Condition – Default Wired_MAB
• Authentication Policy - IL-MAB
• Condition – Default Wired_MAB
• if User Not Found – CONTINUE
• if Process Fail – DROP)Use Internal Endpoints
• (if Auth Fail – CONTINUE
• Authorization Policy - Printer MAB
• Condition – End Points Logical Profile EQUALS Printer
• Authorization Profiles – IL_Printer (Printer Vlan)

We can see ISE PSN has successfully profiled some printer with Canon Device (CF=10)  and some printer with Canon  Printer (CF=40)

However, when we connect the laptop to the printer port, with a MAC address spoof. Laptop gets successfully authenticated and authorised with Canon Device profile. (OUI Match)

When we looked at the Canon Devie profile, it just matching the OUI of the MAC Address.

PSN is has following probes enabled

• RADIUS
• DHCP
• HTTP
• DNS
• AD

We are not using device sensor as Cisco C1000 is not supporting Device Sensor Feature.

RADIUS is not of use as the Printer does not support 802.1x. DHCP is not of use as the printer has an IP address statically configured.

Is there any way I can stop MAC Address spoofing method to bypass ISE NAC solution.

I read about Profile Transitions and the use of Exception Actions to restrict

Where we can take action with new device profile learned on printer port.

 But I'm not sure how to configure it. Can anyone suggest to me how to restrict unauthorised access to wired printer using Profile Transition and Exception

[Arne Bier]

@MHM Cisco World you're barking up the wrong tree mate. I don't know what part of this you don't understand. MAC spoofing is the most basic thing in the world. Your last question about "why both endpoints have same OUI ?" - obviously they'd have the same OUI if the first three bytes of the MAC address is the same - that's what defines the OUI. And MAC address spoofing has nothing to do with device sensor. The switch is not aware that MAC spoofing is going. on. 

The original question from @jitendrac was about how to handle the detection of such events, and we answered that already - ISE Anomalous Detection. And this only works if DHCP is involved, since ISE has profiled the MAC address using DHCP as being a Windows PC, and then next time it sees the same MAC address it's a Linux OS. That triggers anomalous detection and a Global Exception in ISE can do stuff to that - watch the YouTube video for an example. I maintain, that this is still flawed, because you can't assume that DHCP is always involved. And Anomalous Detection (in my experience) has flaws (false positives) and the mechanisms used for detection and comparison are not well enough documented. Perhaps the solution lies elsewhere - e.g. using NetFlow record analysis to detect anomalous behaviours - send your client interface NetFlow records to a clever system that can detect the anomalies, and then have that system integrate with ISE pxGrid to quarantine the interface. That would be harder and more expensive, but most likely have better outcomes.   

[jitendrac]

We did some testing in the environment

Here is the result of testing

1. The printer is on the network
2. ISE learns the profile of the printer we get "canon-device" in Matched Policy and End Point Policy in Context Visibility.
3. We spoof the MAC address of the printer assigned to the laptop, remove the printer, and connect the computer to the printer switch port.
4. We get access to a network.

This is the problem we are discussing. 

However, I do not get access to the network if I delete the MAC address from context visibility when connecting the same laptop with a spoof MAC address. This time, Context Visibility shows Windows11-Workstation as Matched Policy and End Point Policy.

This indicates if the MAC address is already profiled and if a new device with the same MAC address comes with a different expected profile. ISE does not change the old profile OR override that old profile with a new one.

This looks like my Endpoint Profile Change feature is not working as expected. Maybe I am missing some configuration.

I want to understand following. Let me know if there are any documentation or Cisco Live Webinar that are covering this topic

1. When ISE populates the Context Visibility First Time - Does its populate As soon as Profile matched with CF Score OR will it wait for certain duration till it do not see other Profile coming on same port with same MAC but more CF score ?
2. What if 2 different profile with same CF matched ? Which one ISE will take as final to mentioned in Context Visibility ?
3. Where to define Exception Action ? Do we have to configure Exception Action in already learned Profile ?

[Aref Alsouqi]

---

@jitendrac wrote:

However, I do not get access to the network if I delete the MAC address from context visibility when connecting the same laptop with a spoof MAC address. This time, Context Visibility shows Windows11-Workstation as Matched Policy and End Point Policy.

Still with a static IP assigned to that spoofing laptop? if so, that shouldn't happen as the spoofed OUI belongs to Canon. However, if you open up the spoofing laptop page on ISE and you go to the attributes page it should show you all the attributes collected and from there you can see how and why the laptop was profiled as a Windows 11 workstation. If there are two profiles matching an endpoint, the one with the higher certainty will be applied, and if an endpoint was already profiled as something, ISE won't change its profile unless a higher certainty is hit from another profile.

Also, please take a look at this guide focused on ISE profiling:

ISE Profiling Design Guide - Cisco Community

[jitendrac]

No that time, the spoofing laptop did not have a static IP. Maybe due to DHCP and other probes it got profiled as Windows 11 workstation

I will test again by assigning a same IP address of printer and same MAC as of that printer. Lets see what ISE detect after deleting MAC from context visibility

[MHM Cisco World]

When we use dhcp we dont look for IP we look for 

Dhcp-class-identifier <<- this will make ISE can differentiate between laserPinter and workstation 

MHM

[Aref Alsouqi]

Then that explains why it was profiled as something else.

[MHM Cisco World]

the Printer use below attributes 
-OUI <<- since ISE use mac to get OUI and mac is same then this useless 
-DHCP Class Id <<- this sure you can use it via ip dhcp relay 
-SNMP DeviceDescr <<- you dont have sensor so you can use it

[jitendrac]

Thanks MHM ,

I will check if the customer can allow us to use NMAP scan and SNMP query on the endpoint

[MHM Cisco World]

what about DHCP relay ?

MHM

[jitendrac]

Hello Community,

I am reopening this discussion to gather further insights.

Based on most of your recommendations, we successfully convinced the customer to utilize DHCP for printer profiling. Additionally, we enabled NMAP, SNMP, and DHCP probes for endpoint discovery and classification.

Successful Printer Profiling

Using the aforementioned probes, we successfully profiled printers and retrieved the attributes, some of which are mentioned below:

• Endpoint MAC Address: F4-81-39-DE-F9-7A
• Endpoint Source: DHCP Probe
• Last NMAP Scan Time: 2025-Jan-27 13:04:57 IST
• MFCInfoEndpointType: Printer
• MFCInfoHardwareManufacturer: Canon Inc.
• MFCInfoHardwareModel: Canon-Printer
• MessageCode: 5200
• DHCP Attributes:
  • client-fqdn: BAG20NOT005812
  • dhcp-class-identifier: MSFT 5.0
  • dhcp-client-identifier: 01:F4:81:39:DE:F9:7A
  • dhcp-message-type: DHCPREQUEST
  • dhcp-parameter-request-list: 1, 3, 6, 15, 44, 47
  • dhcp-requested-address: 10.183.11.11
  • host-name: Canondef97a
• SNMP Attributes:
  • hrDeviceDescr: Canon iR1435
  • hrDeviceStatus: 2
  • Operating System : Canon i-SENSYS MF5490dn (Accuracy: 96%)
  • Operating-system-result Canon i-SENSYS MF5490dn printer (accuracy 96%)
  • sysDescr: Canon iR1435 /P
  • sysName: imageRUNNER1435
  • sysObjectID: 1.3.6.1.4.1.1602.4.7

Profiling Policy Configuration

A custom user-defined profiling policy rule was created utilizing the above attributes. The Minimum Certainty Factor (CF) was set to 80 to ensure accurate classification. Upon rebooting the printer, the endpoint matched the profiling rule successfully.

MAC Spoofing Bypass Issue

However, when we spoofed the MAC address of the printer and connected a laptop from a different branch, Cisco ISE did not flag this as anomalous behavior. Surprisingly, the spoofed MAC address was allowed access without any restrictions. This spoofed MAC endpoint also passed through same authorization policy which actual printer passed. 

Expected Behavior vs. Observed Behavior

• Expectation: Anomalous behavior detection should have triggered due to the mismatch in endpoint attributes (e.g., OS fingerprinting, device type, SNMP details).
• Observation: ISE permitted access to the spoofed MAC laptop endpoint

Seeking Community Input

1. Is there a way to enforce profiling-based validation beyond MAC address to mitigate spoofing risks?
2. Can Anomalous Behavior Detection (ABD) be fine-tuned to detect attribute mismatches (e.g., OS, SNMP, hostname inconsistencies)

Any guidance on remediating MAC spoofing risks within ISE profiling policies would be highly appreciated.
Shall we enable CoA as reauth OR make Anomalous Endpoint Detection Enforcement by creating rule as mentioned in link Configure Anomalous Endpoint Detection and Enforcement on ISE 2.2 - Cisco
But for Enforcement at least it should flag as Anomalous Endpoint which is not happening in my case. 

[jitendrac]

Expected Behavior vs. Observed Behavior

• Expectation: Anomalous behavior detection should have triggered due to the mismatch in endpoint attributes (e.g., OS fingerprinting, device type, SNMP details).
• Observation: ISE permitted access to the spoofed MAC laptop endpoint

Seeking Community Input

1. Is there a way to enforce profiling-based validation beyond MAC address to mitigate spoofing risks?
2. Can Anomalous Behavior Detection (ABD) be fine-tuned to detect attribute mismatches (e.g., OS, SNMP, hostname inconsistencies)

Any guidance on remediating MAC spoofing risks within ISE profiling policies would be highly appreciated.
Shall we enable CoA as reauth OR make Anomalous Endpoint Detection Enforcement by creating rule as mentioned in link Configure Anomalous Endpoint Detection and Enforcement on ISE 2.2 - Cisco
But for Enforcement at least it should flag as Anomalous Endpoint which is not happening in my case. 

[Aref Alsouqi]

Anything with MAB could be spoofed, the recommendation would be to move to dot1x using certificates if possible, otherwise using username and password. Both these dot1x options are way more secure than relying on MAB.

ISE  Anomalous Behavior Detection has its own limitations, the checks that ISE uses aren't that much, hence, I don't believe you can customize it using hostnames, OS, etc.

You need CoA to be enabled if you want to isolate the anomalous endpoint, because the CoA is the key feature here to apply the enforcement. If you don't turn it on there wouldn't be a way to isolate that endpoint.

[jitendrac]

I just need to understand when ISE collects device DHCP Attributes. Is it as soon as the endpoint is connected, or does it have to wait for some time?

[Arne Bier]

ISE processes any endpoint DHCP data that it receives either via “ip helper” statements, or via Catalyst Device Sensor feature (via RADIUS interim accounting updates ). Device Sensor can also supply HTTP, CDP and LLDP  snooped data. ISE gets this data very soon after authentication. You can see the Device Sensor data in tcpdump.