topic Re: ISE - how-to prevent mac spoofing in Network Access Control

ISE - how-to prevent mac spoofing

c.andrew — Mon, 11 Mar 2019 03:22:03 GMT

I've built an ISE lab (1.1.3.124) and have an authorization policy which permits access to profiled Cisco-Access-Points. For the purpose of the lab, these devices have full access.

Profiling is working correctly. I have a 1231 AP which is correctly profiled and placed in an endpoint group, Cisco-Access-Point.

From a Linux laptop, using macchanger, I can successfully spoof the mac of the AP and gain full access - for some reason ISE isn't profile checking the laptop and I'm not sure why. The laptop obtains an IP using DHCP. I have the following profile checks enabled: NetFlow, DHCP, RADIUS, DNS, SNMP.

When I check Live Authentications, apart from the session IDs, there is no difference when comparing the authz between the AP and the spoofed laptop.

I was hoping that ISE would recognise the spoofed attempt and let it fall through to the deny policy.

I'm happy to attach any screenshots if required.

Thanks.

Re: ISE - how-to prevent mac spoofing

George Stefanick — Sat, 27 Apr 2013 15:23:38 GMT

Try deleting the MAC address in ISE and then try your spoof again ..

Sent from Cisco Technical Support iPad App

Re: ISE - how-to prevent mac spoofing

George Stefanick — Sat, 27 Apr 2013 15:26:00 GMT

Read the coa section

http://www.cisco.com/en/US/docs/security/ise/1.0/user_guide/ise10_prof_pol.html

Sent from Cisco Technical Support iPad App

ISE - how-to prevent mac spoofing

c.andrew — Sat, 27 Apr 2013 15:29:30 GMT

Thanks - I will check the link.

I have already tried deleting the MAC address from ISE. When I attach the Linux laptop with the spoofed address, it correctly sits at a lower CWA policy and is profiled as Linux Workstation.

The profiling part is working beautifully, but I can't figure out why ISE is allowing the spoof to take place.

Re: ISE - how-to prevent mac spoofing

George Stefanick — Sat, 27 Apr 2013 15:40:32 GMT

It sounds like to me coa isn't working. Check that link out and tell ,e what you think based on your config ..

Sent from Cisco Technical Support iPad App

ISE - how-to prevent mac spoofing

c.andrew — Sat, 27 Apr 2013 16:15:47 GMT

Thanks for your help on this.

Have checked the config guide. My profiler configuration, CoA type was already set to port bounce. I've also tried reauth - same result.

If I delete the device (listed as Cisco-Access-Point) from ISE, while the spoofed Linux device is attached, a CoA is issued, a port-bounce (or reauth) occurs, then the device is profiled as Linux-Workstation and sits at a lower policy for CWA - all OK there.

The way I'm testing this is to have the AP profiled and authorized. Disconnect the cable from the AP and plug this into my spoofed MAC interface on a Linux laptop. ISE doesn't recognise it's a different device and returns the authz profile for Cisco-Access-Point identity group.

Re: ISE - how-to prevent mac spoofing

George Stefanick — Sat, 27 Apr 2013 16:27:49 GMT

Sounds like ise is not validating the probes after a device has been profiled ..

I would open a ticket on this one .. Or perhaps Monday when other folks hit the forums they might have some additional ideas ..

Sent from Cisco Technical Support iPhone App

ISE - how-to prevent mac spoofing

c.andrew — Sat, 27 Apr 2013 17:00:45 GMT

Well I've just observed a very odd result which is repeatable!!

If I remove the MAC from ISE. Then attach the Linux device, with it's spoofed address, it is correctly profiled and sits at a CWA policy. I then attach the cable to the Cisco AP, after a shortwhile, a CoA goes out and it is re-profied as a Cisco-Access-Point.

This is the behaviour I want to see, but in reverse.

Re: ISE - how-to prevent mac spoofing

mlezerkiewicz — Wed, 08 May 2013 18:00:39 GMT

Is Cisco working on this?

Sent from Cisco Technical Support iPad App

Re: ISE - how-to prevent mac spoofing

msonnie — Wed, 08 May 2013 21:26:32 GMT

May I know if you are using Certificates for profiling purposes ?

As I believe that certificates are not being used.

If you use the certificates for Profiling purposes, then the MAC address of a device would be bind with the certificate and could only be spoofed, if a duplicate certificate could be made.

HTH.

Message was edited by: Mohit Sonnie

Re: ISE - how-to prevent mac spoofing

c.andrew — Thu, 09 May 2013 08:38:09 GMT

I'm running the 90 day trial of ISE, so I don't believe I can raise a TAC case on this - unless someone can let me know another way to raise this with Cisco? Thanks.

Re: ISE - how-to prevent mac spoofing

c.andrew — Thu, 09 May 2013 08:44:13 GMT

I'm not using certificates in this case. Many network devices don't have the ability to auth with certificates, so I am testing this using MAB.

George Stefanick sums it up above, "ise is not validating the probes after a device has been profiled", which I agree with.

ISE - how-to prevent mac spoofing

c.andrew — Fri, 18 Oct 2013 22:16:41 GMT

Just to update this thread.

I have re-tested this with ISE 1.2 (patch 2), and it behaves the same as above!!

Profiled Cisco AP. Unplug the AP. Attach a laptop (Linux or Windows) with a spoofed MAC (same MAC as the Cisco AP), and ISE permits access with the same result profile as the AP.

Am I expecting too much from ISE here - I thought the "intelligent" profiling should combat this type of thing.

Re: ISE - how-to prevent mac spoofing

Sam Hertica — Sat, 19 Oct 2013 04:25:25 GMT

This may or may not be already known, so I'm going to describe how I would expect ISE to work.

Authentications based on profiling
- The first time a device comes through ISE, it could get the wrong result you would expect the device to get. This is due to the fact that ISE has a bit of a challenge - to identify and authorize new users to its system before the probes can learn anything about these endpoints.
  - For example, DHCP and HTTP are fairly useless until after the port becomes authorized since no client traffic can flow before an authentication occurs. ISE might apply the catch-all CWA result allowing it on the network, but then the DHCP class identifier could say 'Cisco AP'.
  - ISE knows that any new profiled information could result in a different AuthZ policy, so it issues a CoA to inform the NAD to re-authenticate that particular session.
  - The same authentication occurs now, but ISE now already knows the device appears to act like a Cisco AP and hands back the WAP result this time instead of CWA.
  - Any future authentications that occur for this Cisco AP, we pass back the Cisco AP result since we know he was previously an AP. Our probes would still learn as much as they can about the 'new' authentication, but no data would change from our end since the probes learn redundant information for this legit Cisco AP.

So, what you're describing is you're performing MAB and swapping out the profiled Cisco AP with another device that is spoofing the MAC address. MAB literally stands for 'MAC Address Bypass', so when ISE is presented with the MAC address it checks its internal host store and finds out he does in fact know 'AA-BB-CC-DD-EE-FF'. The spoofed device was previously known to be a Cisco AP, so ISE will hand out the Cisco AP result allowing it on the network infrastructure VLAN with a special DACL if you're getting fancy.

Your point here is that the spoofed PC is allowed on the network, when in fact it isn't a Cisco AP. What should happen at this point is the probes start doing their magic. The only way a device becomes a 'Cisco-Access-Point' is if the CDP entry in the switch contains 'AIR' or the dhcp-class-identifier includes 'Cisco AP'. So what I would expect happen is if you have SNMP Query/Trap probes setup and working, as soon as the linux laptop plugs in with the spoofed MAC the switch would inform ISE that a link came up/up. ISE sends back an SNMP Query asking for more information, which the switch then provides. ISE would then realize that there's no CDP information there (unless your linux test box is utilizing CDP, then this is a mute point anyways) and update the session endpoint in its internal hosts either during or before the actual authentication occurs. If it's during, ISE would trigger a CoA, which would cause the endpoint to reauthenticate then fall into (probably) the Cisco-Devices group based of the OUI of the MAC.

The other way to become a Cisco-Access-Point by default is through the dhcp class identifier. So lets say your linux box authenticates, ISE passes back the AP result, and you're allowed on the network. Once you issue a DHCP Discover from your box, ISE should recieve it and learn that the DHCP class identifier has changed from what it expected ('Cisco AP') to something different and issue a CoA. The linux box will reauthenticate, and get passed back the generic CWA profile.

Ultimately the entire job relies on either the DHCP probe, SNMP Trap/Query Probes, and CoA...unless you've modified the profiling settings from the default. Since you mentioned deleting the MAC address from the internal hosts section forces ISE to send back CWA, i'm thinking that your switch config might be missing the CoA portion.

1. What probes do you have enabled. This by default requires DHCP, DHCP Span, or SNMP Query/Trap.

2. Can you see the successful CoA from the switch?

3. If you wait ~5 minutes after the linux box with the spoofed address authenticates and check the internal host, what does ISE know about that device? If my CoA theory is right I would expect after even a couple minutes we would recognize that the device isn't a Cisco WAP.

ISE - how-to prevent mac spoofing

c.andrew — Sat, 19 Oct 2013 07:33:23 GMT

Thanks for the detailed reply.

I have the following probes enabled:

DHCP

DHCPSPAN

HTTP

RADIUS

DNS

SNMPQUERY

SNMPTRAP

This is the mab auth on the switch when the Windows XP laptop with spoofed address is attached:

%AUTHMGR-5-START: Starting 'mab' for client (001b.2abc.5de0) on Interface Fa0/2 AuditSessionID C0A863FE0000001923A54152

%MAB-5-SUCCESS: Authentication successful for client (001b.2abc.5de0) on Interface Fa0/2 AuditSessionID C0A863FE0000001923A54152

%AUTHMGR-5-SUCCESS: Authorization succeeded for client (001b.2abc.5de0) on Interface Fa0/2 AuditSessionID C0A863FE0000001923A54152

3560-1#sh authentication sessions interface fa0/2

Interface: FastEthernet0/2

MAC Address: 001b.2abc.5de0

IP Address: 192.168.99.50

User-Name: 00-1B-2A-BC-5D-E0

Status: Authz Success

Domain: DATA

Security Policy: Should Secure

Security Status: Unsecure

Oper host mode: multi-auth

Oper control dir: both

Authorized By: Authentication Server

Vlan Group: N/A

ACS ACL: xACSACLx-IP-L2-WLC-ONLY-5261a14b

Session timeout: N/A

Idle timeout: 20s (local), Remaining: 5s

Common Session ID: C0A863FE0000001923A54152

Acct Session ID: 0x000000AB

Handle: 0xB3000019

Runnable methods list:

Method State

dot1x Failed over

mab Authc Success

If I wait 10 minutes, ISE still has the laptop profiled as Cisco-AP-Aironet-1130.

Here's some relevant portions of my 3560 running c3560-ipservicesk9-mz.122-55.SE7.bin

snmp-server community ciscoro RO 10

snmp-server community ciscorw RW 10

snmp-server trap-source Vlan1

snmp-server source-interface informs Vlan1

snmp-server enable traps snmp authentication linkdown linkup coldstart warmstart

snmp-server enable traps mac-notification change move threshold

snmp-server host 192.168.99.11 ciscoro

interface FastEthernet0/2

switchport access vlan 99

switchport mode access

switchport block unicast

ip arp inspection limit rate 100

ip access-group ACL_DEFAULT in

authentication event fail action next-method

authentication host-mode multi-auth

authentication open

authentication order dot1x mab webauth

authentication priority dot1x mab webauth

authentication port-control auto

authentication timer inactivity 20

authentication violation restrict

mab

snmp trap mac-notification change added

snmp trap mac-notification change removed

dot1x pae authenticator

dot1x timeout tx-period 5

spanning-tree portfast

spanning-tree bpduguard enable

ip dhcp snooping limit rate 200

ISE - how-to prevent mac spoofing

Sam Hertica — Sat, 19 Oct 2013 13:48:09 GMT

c.andrew wrote:

Thanks for the detailed reply.

Not a problem, to be honest I would have replied sooner but it looks like whenever I looked through these forums I missed this post time and time again.

Your switchside SNMP config looks fine. Since you're using authentication open, DHCP is a useful probe (assuming it's unblocked in the ACL_DEFAULT)

The DHCP probes will only work if you have either a span session of that interface/vlan heading to ISE or if you setup an 'ip helper-address' for that vlan.

If ISE still believes after 10 minutes that it's still a Cisco AP, then it seems like either we're not getting the profiler information for the linux box, or we are getting it but we're ignoring it for some reason.

Could you take a screenshot of the spoofed linux endpoint in the Internal Hosts section of ISE? If you scroll through the list it should show you all the attributes ISE has learned about that particular endpoint, and i'm curious what's still tying it to be an AP.

Re: ISE - how-to prevent mac spoofing

c.andrew — Sat, 19 Oct 2013 17:15:04 GMT

Yes I've got ip helper on the relevant VLAN interface:

interface Vlan99

ip address 192.168.99.254 255.255.255.0

ip helper-address 192.168.99.11

I've put the output of the host in a PDF, attached.

The laptop was booted into it's Win XP partition, but it doesn't matter whether it's running XP or Centos.

Thanks Again.

Re: ISE - how-to prevent mac spoofing

Sam Hertica — Sat, 19 Oct 2013 18:09:51 GMT

The laptop was booted into it's Win XP partition, but it doesn't matter whether it's running XP or Centos.

Right. A MAC address is a MAC address . I skimmed your earlier response and assumed we kept running with linux, but as long as the MAC is the same it's no big deal.

I'll highlight what I think is interesting from that report

EndPointSource is DHCPSpan. This is the last probe ISE used to get information about this client
OUI is Cisco Systems. We expect this.
dhcp-class-identifier is MSFT 5.0. We expect this.
cdpCachePlatform is cisco AIR-AP. I would expect this to be blank...

Ok, so it seems like somethings iffy with our SNMP Query/Trap. I would have expected as soon as you plugged in the XP box, switch sends SNMP trap to ISE for linkup, ISE sends back SNMP query to read the device. SNMP Query/Traps are clearly working fine since you have CDP information, so something weird is happening here. There's a ton of things that could be wrong here, so we'll work through them one by one. We can start by taking a packet capture from ISE (Under operations -> diagnostic tools) to rule out where to look.

Switch doesn't send SNMP Trap to ISE after linkup for xp.
ISE doesn't recieve the SNMP Trap.
ISE doesn't process the SNMP Trap.
ISE doesn't trigger SNMP Query.
Switch doesn't recieve SNMP Query.
Switch doesn't process the SNMP Query.
Switch doesn't reply to the query.
ISE doesn't recieve the query.
ISE doesn't process the query.

It's unlikely that there's connectivity issues, but I hate ruling things out based on my assumptions...

Speaking of assumptions, I am also assuming that you are directly connecting the Cisco AP to the switch, and the XP box to the switch. This would mean that as soon as we disconnect the Cisco AP, the switch clears out the CDP information for that port. When the PC is plugged in, the CDP information stays empty. Please confirm you are directly connecting to the switch.

Anyways, what ISE is currently doing with the information it has is also expected. When ISE is attempting to profile the top-level for this device, we can tell that Cisco-Device gets +20 certainty factor from the OUI and the cdpDevicePlatform containing 'Cisco'. Workstation would get +20 for the MSFT dhcp class identifier. Cisco-Device has a minimum certainty factor of 10, while MSFT has 20. They are both considered, but ultimately Cisco-Device wins apparently. This i'm unclear about, whether Cisco-Device wins first because it's technically checked before Workstation, or if it's due to the fact MSFT is 20/20, and Cisco-Device is 20/10. Regardless, the problem here is the cdpCachePlatform isn't getting updated to being blank, which is why it's falling into Cisco-Device.

Now that it's inside Cisco-Device, we run through all the child policies for Cisco-Device. Because the cdpCachePlatform includes AIR we get dropped into teh Cisco-Access-Point. We scan through the child policies again, and the cdpCachePlatform gets us placed into the specific profiled group Cisco-Ap-Aironet-1130.

What SHOULD happen is ISE recieves updated information from the switch with regards to an empty CDP information. I would expect ISE to update the endpoint accordingly and issue a CoA. The profiler would look through all the parent policies, and match on Cisco-Device and Workstation. However, the only reason we believe it's a Cisco-Device is due to the OUI (which gives us +10 CF, and is what we expect). ISE would also think it's a Workstation because the DHCP class identifier contains MSFT, giving that policy +20 CF.

ISE will profile it as a Workstation, since it has a higher CF. Now ISE scans through the children of workstation, and will assign Windows-Workstation since the DHCP class identifier is MSFT.

Ultimately the problem is the lingering CDP information in the endpoint store. We need to figure out what is at device is at fault here before diving even deeper.

Re: ISE - how-to prevent mac spoofing

c.andrew — Sat, 19 Oct 2013 21:36:09 GMT

Yes the laptop / AP is plugged directly into Fa0/2 of my 3560.

Obtaining a packet capture has been challenging. No matter which host or browser I used, the pcap file was unreadable by Wireshark - regardless of whether I applied filters or not. The error reported is "The file... isn't a capture file in a format Wireshark understands". I'm running the latest version.

So I've configured two separate monitor sessions. One on the port connecting ISE - on this one, I filtered on ISE's MAC address since it is a VM.

The second monitor is on Fa0/2 (laptop).

Both captures record the laptop being plugged in and end with the successful mab authz.

Thanks again for your help on this.

Re: ISE - how-to prevent mac spoofing

c.andrew — Sat, 19 Oct 2013 21:48:15 GMT

Just noticed a "human readable" option on the packet capture. So I've obtained the attached from ISE.