Security

I'm testing the Endpoint conflict capabilities and having zero success on the wire. 

CPPM 6.8.3, Aruba-S 16.08

I have a rule in my enforcement policy that is supposed to drop conflicted devices in a separate role on the switch.

 

I connect a device and it gets profiled and that works well. I manually change the category to something way off from the device (Windows device vs Video Device). I reconnect the the laptop, and it gets on without issue. There is no conflict detected. I do see that in the endpoint repository that the IP, hostname, and the "Last Profile At" time changes. However, no conflict is detected.

 

I also tried spoofing the MAC from a different device and that device is also profiled, updated (all but the needed properties), and allowed on the network.

 

Suggestions?

I've replicated this in versions 6.7.10 and 6.8.3.

Hi Zemerick,

 

Hi did a lot of profilings with conflict detection a time ago.The issue i was strungling with was that after a second authentication dhcp fingerprinting was not take place and dont update the endpoint respository.

 

What i did:

1. Put an HP printer in my network, dhcp fingerprint, profiled and came online correctly.

2. i spoof the mac-adres of the printer to my laptop

3. put out the printer interface and put my laptop in, 1 minute after the first connection (step 1).

4. because the interval between the printer and the laptop was to short, fingerprinting dont happen, and conflict detection dont take place.

 

What i figure-out was that ClearPass DHCP fingerprinting  was hold off for a couple of minutes to prevent to much CPU resource from receiving DHCP probe requests.

 

Iam not sure if this is still happen in 6.8.x, because there are some profiling updates in de 6.8 release i didnt test.

 

Thank you. However I'm seeing this hours after the initial profile. In the endpoints database I see that the endpoint is updated. This is reflected by the "Last profile time". Also, the host name and IP are updated on the endpoint.

I've since tried to reduce the cache timer for the authorization source without luck. Clearing the cache for the authorization source has the same effect.

I've tried this with the MAC AUTH and MAC AUTH ALL auth sources.

Zemerick did you get any further with this?

 

i have been working on this years ago and got it semi stable within some limits. due to that fact we never rolled it out in production.

 

recently i got the question again and done some research, it feels not much has changed. one issue is that the conflict state comes after the "spoofed" authentication has passed, so you will only see this on the authentication after that.

I have not. I have discovered another short-coming of the conflict feature since then. 

 

For some reason CPPM is re-identifying devices as the exact same Category and family and triggering a device conflict. For instance, an SmartDevice, Apple iPhone. Will trigger an alert. When you examine the device in the endpoint repository, it will show that the new fingerprint is also a SmartDevice, Apple iPhone. 

 

To my understanding, the only way CPPM triggers a conflict is if the device category is changed. So, I'm not sure what the issue is. As you can imagine this is a very big issue. I instructed the customer to engage TAC to dive in further, and keep me posted.

I have been testing the profiling conflict function on 6.8.4 and have had some issues very similar to the one you have described.

I had a TAC ticket and we came to the solution to change the Endpoint Repository cache from 300 seconds to 0 seconds.

 

After this change the profiling conflict is detected in the second authentication following the CoA after the profiling event.

 

Due to the Covid-19 situation, I have not been able to deep dive in the behavior if the device with spoofed MAC address is connected within 5 minutes from the initial profiling of the correct device with the same MAC address.

 

could that be related to this Jonas?

 

https://community.arubanetworks.com/t5/AAA-NAC-Guest-Access-BYOD/What-is-the-limitation-in-ClearPass-for-DHCP-based-profiling/ta-p/216413

Yes, that's one factor. But the cache timeout is an issue if the original device was profiled long time ago and you connect a device with a spoofed MAC address.

In that case the Endpoint Repository cache cause the detection of the conflict to not be detected. Actually it's detected as a conflict but the Conflict flag is not set to True in the Enforcement evaluation.

 

By setting the cache timeout to 0 seconds, it works as intended.