ISE profiling and MAC address spoofing mitigation

[wiong]

I am googling around trying to confirm on ISE profiling and mitigation against MAC address spoofing but I have not find a confirmed answer.

When a device connects, get profiled and identified what it is, the ISE screen will show up the endpoint information including what is this endpoint (Cisco IP phone, Ricoh printer, etc). Even if the device is subsequently disconnected, I can still see it on the ISE screen although it shows that it is disconnected. If I now plug a device into the network and spoofed that endpoint MAC address, will ISE re-profile again or just let the device in since it has been profiled previously and still in the ISE DB with the MAC address intact?

I read somewhere in ISE document that when a device has been profiled (which may takes several seconds initially), ISE will cache the information so that subsequently, when the endpoint reconnects again, the network connectivity establishment is faster since it does not need to re-profile again? If this is the case, anyone can easily get into the network by just spoofing the MAC address.

[Mohammed al Baqari]

Hi,

If the device parameters change and the new ones sent to ISE (for example
in radius message while the switch is configured for device sensor), ISE
will reprofile the endpoint. The profile isn't one time activity, it keeps
checking whenever the device sends radius attributes to the it and in case
of changes, new profile is assigned.

[wiong]

Hi Mohammed,
So if I configured the switch as a device sensor using RADIUS and let's say the ISE profiling identified the endpoint as a Cisco IP phone using the TLV parameters. Now a rouge device spoofed it's MAC address but does not advertise the TLV value connects to the switch, the switch will send a RADIUS request again to ISE, ISE will re-profile the endpoint, checked the TLV value is changed and block the switch port to this rouge endpoint?

[Mohammed al Baqari · Accepted solution]

Yes this is correct.

[AMoore1776]

So what command needs to be running on the switch interface?

[nayan29net]

@Mohammed al Baqari 

On our production network we have Anomalous Behavior Detection enabled, but Enforcement is disabled.

What would be the impact if I enable the Enforcement and Change CoA type to Re Auth instead of No CoA.

Also,

What is the best practice for profiling an endpoint?

We generally try to avoid just using OUI or MAC address alone?

Is it wise to use DHCP Parameter Request List or NMAP Port Scan Result?

Also why two printer with same OUI/Different Model Provide different attributes?

I have some ricoh printer which provide precise details like 

hrDeviceDescr

RICOH Aficio SP 4210N

sysDescr

RICOH Aficio SP 4210N 1.02 / RICOH Network Printer C model

Where some does not provide any concrete information

They provide dhcp-parameter-request-list which is not necessary indication if its printer devices

[BrianPersaud]

I had the same question.  I tested the scenario with a Cisco IP phone and a laptop.  After the IP phone was profiled, I disconnected it from the network and then set the mac address on the laptop to the same as the IP phone.  I was able to authenticate successfully using the laptop with the exact authorization profile as the ip phone.  It classified the laptop as an IP phone based on the information it had cached previously.  The laptop was assigned to the voice vlan and had all the permissions on the network.

[wiong]

Seems like ISE cannot re-profile it again when the MAC address has been stored in the MAB. This is a potential security vulnerability?!

[BrianPersaud]

I retested after enabling Enable Anomalous Behaviour Detection and Enable Anomalous Behaviour Enforcement along with the appropriate authorization policy.  I set the laptop to use the mac address as the IP phone.  It worked as expected to deny the laptop from accessing the network.

[wiong]

Hi Brian,

How did you got it to work? Did the spoofing device advertise a different TLV value or etc? I am testing it but ISE did not re-profile even when I enable anomalous detection and enforcement. I spoke to TAC, TAC says that because the spoofing device did not send TLV value, ISE did not trigger re-profiling.. To me, isn't that consider a change in the profile coz there is no TLV for the same device that was earlier profiled successfully using OUI + TLV? A simple notebook can easily spoof the MAC address without even installing any 3rd party tools. 

[BrianPersaud]

Hi Here are the configs I used on the switch for 802.1x.  It is possible that it is using device sensor for your question about TLV.  I tested on a 3650 and 3850 switches with  IOS 16.6.6 with ISE 2.4 Patch 9.  Note I am also doing SNMP probe, a local port ACL and CoA.

aaa authentication login default group radius local
aaa authentication enable default enable group radius
aaa authentication dot1x default group radius
aaa authorization exec default local group radius
aaa authorization network default group radius
aaa authorization auth-proxy default group radius
aaa accounting auth-proxy default start-stop group radius
aaa accounting dot1x default start-stop group radius
aaa accounting system default start-stop group radius
aaa server radius dynamic-author
client 10.x.x.x server-key 7 xxxxxxxxxxxxxx
server-key 7 xxxxxxxxxxxxx
aaa session-id common
dot1x system-auth-control
dot1x critical eapol
radius-server attribute 6 on-for-login-auth
radius-server attribute 8 include-in-access-req
radius-server attribute 25 access-request include
radius server ISE01
address ipv4 10.x.x.x auth-port 1812 acct-port 1813
key 7 xxxxxxxxxxxxx

snmp-server group SNMP_GROUP v3 priv
snmp-server user SNMP_USER SNMP_GROUP v3 auth sha xxxxxxxxxx priv aes 256 xxxxxxxxxx
snmp-server host 10.x.x.x version 3 priv SNMP_USER
snmp-server enable traps snmp linkdown linkup
device-sensor accounting
device-sensor notify all-changes
authentication mac-move permit
access-session template monitor

ip access-list extended PORT-ACL-DEFAULT
permit udp any eq bootpc any eq bootps
permit udp any any eq domain
permit icmp any any
permit udp any any eq tftp
permit tcp any host 10.x.x.x eq 8443
deny ip any any

interface gi 1/0/1

description XXXXX
switchport access vlan XXXXX
switchport mode access
switchport voice vlan xx
ip access-group PORT-ACL-DEFAULT in
authentication event server dead action authorize
authentication event server alive action reinitialize
authentication host-mode multi-auth
authentication open
authentication order dot1x mab
authentication priority dot1x mab
authentication port-control auto
authentication periodic
authentication timer reauthenticate server
authentication violation restrict
mab
dot1x pae authenticator
dot1x timeout tx-period 10
spanning-tree portfast
spanning-tree bpduguard enable

[Colby LeMaire]

ISE will re-profile only if new parameters are received.  So if you spoof a MAC and you don't send anything else, ISE has no new information to re-profile with.  Absence of information is not enough to trigger ISE to profile it again.

Be careful with Anomalous Detection and Enforcement.  It has issues and there are some bugs filed on it.  For example, a Windows PC running Skype will send a DHCP message with a class identifier of the OS and will also send DHCP messages with a class identifier of MS-UC-Client.  Since the class identifier changes, ISE marks it as an anomalous endpoint.  One of my customers had every Windows client marked as anomalous.  With enforcement turned on, that would deny them all.

It is normal for a client to send multiple DHCP class identifiers.  That's how browsers do automatic proxy detection, software phones detect their SIP servers, etc.  ISE needs to account for that.  The DHCP RFC clearly explains the use of different application-specific class identifiers.

[BrianPersaud]

Thanks @Colby LeMaire  good to know about the issues with Anomalous Detection and Enforcement.  I did have the DHCP identifier issue on profiling Polycom phones.  The packet capture showed they were sending the Polycom identifier then the MS-UC-Client for skype for business.  Ended up doing a custom condition for this.  I will monitor the windows PC's to see if this issue occurs for skype for business client. 

[nayan29net]

On our production network we have Anomalous Behavior Detection enabled, but Enforcement is disabled.

What would be the impact if I enable the Enforcement as well and Change CoA type to Re Auth instead of No CoA.

Also,

What is the best practice for profiling an endpoint?

We generally try to avoid just using OUI or MAC address alone?

Is it wise to use DHCP Parameter Request List or NMAP Port Scan Result?

[MS-JK]

Having the same issues on dot1x workstations that have machine cert validation AND AD membership validation. I'm able to take MAC of a dot1x workstation previously validated and authenticate without CERT. The spoof machine even has different HOSTNAME. Yet I'm fully able to spoof get on the network. Bit scary. I'm on ISE 2.3p6 and anomaly detection is enabled. (not even seeing the spoofed machine/mac detected by the detection enabled.

Anyone found good documentation on this? Serious flaw within ISE unless there is something I'm not doing?

Thanks