Security

Hi all, i am testing with clearpass mac auth and the conflict rule.

 

So i dont get the confict working. What i want is that when a mac adress is spoofed on another device type, clearpass detects it and i can take action. I use clearpass 6.7.

 

Here is my situation:

I have a wired service with machauth

I have setup profiling in the service 

As authentication methods i have selected [MAC AUTH] This is because i only want known devices to pass authentication.

So the source is the endpoint repository

I have set the IP helper in my switch to do the DHCP profiling on all vlans.

 

I dont use roles.

 

So in the enforcement i have created the first conditions as a confilct:

(Authorization:[Endpoints Repository]:Conflict  EQUALS  true)

then [Deny Access Profile]

 

So what i did to test:

i connected a ap to my switch and it comes in the endpoint database

I set the device as KNOWN device so it can authenticate.

So far so good.

 

So next i spoofed the mac on my laptop and connected it. For some reason its get authenticated in the access tracker. So it does not have detected that its another device. 

 

Can someone point me in the good direction how to solve this? 

Did you follow the ClearPass Solution Guide for Wired Policy Enforcement?

Hi Tim,

 

I just did and also here i can see a simularenforcement rule.

 

It looks like the conflict is not triggered. 

Conflict is only triggered on a device category change.

Also, you should not deploy Aruba Switches + ClearPass without user roles.

I'm pleased to see that someone else is struggling with the same problem I seem to be having.  

My environment is Clearpass 6.7.  I am doing 'allow-all' MAC auth so I can allow everyone on to a Quarantine VLAN, then classify the IoT devices.  Users who end up in Quarantine can self-register on a portal.

 

When my IP camera comes onto the network, I see this in Endpoint Repository (click to enlarge):

 

Unclassified device (an IP camera) appears in endpoint repository

I can see that the device has been fingerprinted.  As you can see below, the fingerprint shows Option 60 as being 'udhcp'.

 

Fingerprint

 

 

So I go back to the first tab and classify the device.  I have previously created the Category, OS Family and Name - the values shown don't come in Clearpass by default.   As you can see, the IP address hasn't been picked up.  This is odd because the DHCP fingerprint was taken successfully, so not sure why this should be:

Classifying the device

 

In Access Tracker, I can see that the device is classified OK:

Access-tracker (Camera)

 

I then disconnect the IP camera, and use its MAC address on a Windows 7 PC.   The Windows 7 PC goes into the IOT VLAN, which is not what I wanted to happen - it should get Quarantined due to a profile conflict.  As you can see below, the category seems to have stayed the same, but the hostname of the PC has been picked up:

 

Endpoint - PC doing MAC spoofing

 

And in the fingerprint tab we can see that the DHCP client was a Microsoft one.  Still it shows as a Foscam camera:

 

Windows fingerprint

 

As you can see, in access-tracker it is showing that there has been no profile 'conflict'.  As I understand it a conflict occurs when a device changes OS or category between authentications.  This is probably due to the fact that the category did indeed not change - Clearpass still thinks this is a camera, despite the new DHCP fingerprint:  

 

No conflict reported

 

My enforcement policy looks like this.  I am hoping that a conflict happens when the PC is profiled and discovered to be different to the Camera it is trying to masquerade as.  But conflict always equals 'false' rule 4 below is not triggered.

 

Enforcement rules

 

It feels to me like fingerprinting is happening, but policy manager is not doing something right, so my policy is not working out the way I want.

 

Any suggestions would be most welcome!

 

Andrew

 

 

 

 

Yes, i understand. So also, when i test it with a role, i cant get the confict triggered. I will always get access to the network (VLAN4) when i unplug the ap, and plug in my laptop with spoofed mac adress.

 

My feeling is that the laptop is not profiled again and therefore the conflict attrubute will not trigger. so i tesed a few other enforcement rules as well.

 

I added some pictures of my config now.

 

So im wondering if someone has the conflict function working correctly, of is there a better way against spoofed mac addresses?

 

 

Looks similar to mine - except that I am not doing any role mapping.  I don't yet understand roles enough, so I was hoping for this test that I could get away with just an enforcement policy.

 

Tim Cappalli says here that the conflict should be generated if the same fingerprint is used.  That doesn't seem to be happening for us:

 

https://community.arubanetworks.com/t5/Higher-Education/ClearPass-Profile-Conflict/gpm-p/302762/highlight/true#M1865

 

Also Clearpass doesn't seem to get the device's IP address, but hopefully that is a side-issue.

I have checked the fingerprint of the access point and the spoofed windows 10 laptop and they look the same in the access tracker.  Im a little lost here.

Me too!   I wonder if there's a way to debug what is actually received by Clearpass just to make sure?   When I do my spoofing I remove the IP Camera from the network, so I am confident that only the PC has the MAC.  

 

Feels like Clearpass isn't updating itself properly, but I would just like to be sure about what it is receiving.

Can someone post a working config what we can test?

Thanks.

I had a session with tac about this issue. On the cli logs, they where able to see the conflict trigger.

But in the access tracker its not visable. So its not processed correctly. There is a bug id for this issue. This will be fixed in version 6.8.

What was the BUG ID associated with this? Anyone know?

---

@AirBubble wrote:
I had a session with tac about this issue. On the cli logs, they where able to see the conflict trigger.

But in the access tracker its not visable. So its not processed correctly. There is a bug id for this issue. This will be fixed in version 6.8.

---

 

I dont have a bug id but I send you the case number in personal message.