ISE - how-to prevent mac spoofing

[c.andrew]

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.

[msonnie]

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

[c.andrew]

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.

[c.andrew]

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.

[Sam Hertica]

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.

[c.andrew]

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

[Sam Hertica]

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.

[c.andrew]

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.

[Sam Hertica]

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.

1. Switch doesn't send SNMP Trap to ISE after linkup for xp.
2. ISE doesn't recieve the SNMP Trap.
3. ISE doesn't process the SNMP Trap.
4. ISE doesn't trigger SNMP Query.
5. Switch doesn't recieve SNMP Query.
6. Switch doesn't process the SNMP Query.
7. Switch doesn't reply to the query.
8. ISE doesn't recieve the query.
9. 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.

[c.andrew]

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.

[c.andrew]

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

[Sam Hertica]

ISE :          192.168.99.11

Switch:          192.168.0.254

5de0 - client

Ok cool, thanks for the packet captures. I'm looking at just hte ISE perspective for the time being. The capture filter I used was

ip.addr == 192.168.0.254 && not udp.dstport == 20514

What's interesting is all our SNMP traffic is one way, and all are traps. The switch is sending the traps we would expect to ISE, but ISE is not querying our switch. If you look at the human readable output you took you will also find that ISE never sends any SNMP Querys, but recieves all our traps.

Raw packet data should open up in firefox. If it's giving you bogus data that's unfortunate...make sure you're running with a supported browser and if you do captures in the future dont bother with a capture filter and see if that helps.

Anyways, lets double check our ISE config. Open up our network devices and find the test switch we are using. Scroll through the SNMP settings and verify the community matches the switch, and that 'Link Trap Query' and 'MAC Trap Query' are both checked.

Other than that it should be functioning fine, but it's not. If both the query checkboxes were already selected, lets turn up some debugs and run through our test again. Head to

Administration -> System -> Logging -> Debug Log Collection -> [ise PSN]  and click edit

I want to turn up profiler to debug level.

For this test, I would like you to run the whole gambit from start to finish. Delete the entry in the internal hosts section, and create a span session from ISE (or try doing the TCPDump from the GUI again - it honestly shouldn't have any issues if you're using a supported browser). Plug in the Cisco AP and let it authenticate. Once you're happy and think the WAP is all set, you can disconnect it, and plug in your spoofed machine. Let that sit for at least two minutes, then stop the captures and download the profiler.log file from ISE (Operations -> Download Logs) and throw em up here.

Essentially I'm looking for ISE to issue an SNMP query that has the OIB 1.3.6.1.4.1.9.9.23.1.2.1.1.8, which is the CDP cache platform. The traps wouldn't have this info, but the Query should ask for it and the switch should respond. The packet captures you took earlier prove that the switch is sending traps appropriately, and ISE is recieving them. Now the profiler.log should help us determine if it's being processed correctly, and if a query is being sent out.

I have a feeling that the querys are working fine if ISE can profile the Cisco AP fine using CDP...so this is a wonderfully interesting test case you have set up.

[c.andrew]

Well I think this may be fixed, but apart from a reboot, I'm not sure what we've done.

I've attached SNMP-Configs to answer your SNMP questions.

After I deleted the endpoint MAC, ISE would not re-profile the AP correctly. From memory, tt was sat at cisco-device / unknown.

At this point I rebooted ISE, after which it was able to correctly profile the AP.

I caught the profiling in a packet capture, switched the cable to the spoofed XP host, and within a few seconds, ISE profiled the XP host to Microsoft-Workstation / Workstation.

Packet capture and endpoint details are attached.

I'm pleased it's working correctly, but I'm now unable to replicate the fault. :-)

Chris