Catalyst 3560: dot1x port secury - MAB places client MAC in data and voice VLAN

[rherud]

Dear community,

The Catalyst 3560 (12.2(55)SE5), the MAB places the client MAC in data AND voice VLAN simultanously and this is a security whole.

This model is out of support so I cannot open a TAC case.

('sh tech' is attached)

The facts:

As authentication server the Microsoft NPS (Windows Server 2008 R2) was used.

The MAB was logged as successful:

May 16 15:02:16: %SYS-5-CONFIG_I: Configured from console by thomas.doh on vty0 (10.146.117.37)
May 16 15:02:17: %LINK-5-CHANGED: Interface FastEthernet0/3, changed state to administratively down
May 16 15:02:18: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/3, changed state to down
May 16 15:02:40: %SYS-5-CONFIG_I: Configured from console by thomas.doh on vty0 (10.146.117.37)
May 16 15:02:42: %LINK-3-UPDOWN: Interface FastEthernet0/3, changed state to down
May 16 15:02:44: %AUTHMGR-5-START: Starting 'mab' for client (0090.f809.4d15) on Interface Fa0/3 AuditSessionID AC10FD1C000000810B816134
May 16 15:02:44: %MAB-5-SUCCESS: Authentication successful for client (0090.f809.4d15) on Interface Fa0/3 AuditSessionID AC10FD1C000000810B816134
May 16 15:02:44: %AUTHMGR-7-RESULT: Authentication result 'success' from 'mab' for client (0090.f809.4d15) on Interface Fa0/3 AuditSessionID AC10FD1C000000810B816134
May 16 15:02:44: %AUTHMGR-5-VLANASSIGN: VLAN 888 assigned to Interface Fa0/3 AuditSessionID AC10FD1C000000810B816134
May 16 15:02:45: %AUTHMGR-5-SUCCESS: Authorization succeeded for client (0090.f809.4d15) on Interface Fa0/3 AuditSessionID AC10FD1C000000810B816134
May 16 15:02:46: %LINK-3-UPDOWN: Interface FastEthernet0/3, changed state to up
May 16 15:02:47: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/3, changed state to up

But it places the client MAC to data and voice VLAN!:

uksanbehmhtac028#sh mac address-table int fa0/3
          Mac Address Table
-------------------------------------------

Vlan    Mac Address       Type        Ports
----    -----------       --------    -----
  74    0090.f809.4d15    STATIC      Fa0/3
888    0090.f809.4d15    STATIC      Fa0/3
Total Mac Addresses for this criterion: 2

uksanbehmhtac028# sh authentication int fa0/3

Client list:
Interface  MAC Address     Method   Domain   Status         Session ID
  Fa0/3      0090.f809.4d15  mab      VOICE    Authz Success  AC10FD1C000000810B816134

Available methods list:
  Handle  Priority  Name
    3        0      dot1x
    2        1      mab
Runnable methods list:
  Handle  Priority  Name
    2        0      mab
    3        1      dot1x

uksanbehmhtac028#sh dot1x int fa0/3
Dot1x Info for FastEthernet0/3
-----------------------------------
PAE                       = AUTHENTICATOR
PortControl               = AUTO
ControlDirection          = Both
HostMode                  = MULTI_DOMAIN
QuietPeriod               = 5
ServerTimeout             = 30
SuppTimeout               = 30
ReAuthMax                 = 1
MaxReq                    = 2
TxPeriod                  = 1
 

The relevant configuration:

...

aaa new-model
!
!
aaa authentication login default group tacacs+ local
aaa authentication enable default group tacacs+ enable
aaa authentication dot1x default group radius
aaa authorization config-commands
aaa authorization exec default group tacacs+ local if-authenticated
aaa authorization commands 15 default group tacacs+ if-authenticated
aaa authorization network default group radius
aaa accounting dot1x default start-stop group radius
aaa accounting exec default start-stop group tacacs+
aaa accounting commands 1 default start-stop group tacacs+
aaa accounting commands 15 default start-stop group tacacs+
aaa accounting network default start-stop group radius
aaa accounting system default start-stop group tacacs+
!
aaa session-id common

...

!
interface FastEthernet0/3
 description *** Std NAC port ***
 switchport access vlan 74
 switchport mode access
 switchport voice vlan 888
 srr-queue bandwidth share 1 30 35 5
 srr-queue bandwidth shape 10 0 0 0
 priority-queue out
 authentication event fail action authorize vlan 174
 authentication event server dead action authorize vlan 174
 authentication event server dead action authorize voice
 authentication event no-response action authorize vlan 174
 authentication host-mode multi-domain
 authentication order mab dot1x
 authentication priority mab dot1x
 authentication port-control auto
 mab
 mls qos vlan-based
 dot1x pae authenticator
 dot1x timeout quiet-period 5
 dot1x timeout server-timeout 30
 dot1x timeout tx-period 1
 dot1x max-reauth-req 1
 spanning-tree portfast
!

...

A HP switch does not have the issue when using the same authentication server.

I have searched on CCO and the WWW but did not find a hint to that issue.

Do you see any mistake or suspect in the configuration or is there a known bug?

If you need any further information please let me know.

Every hint is welcome!

Thanks a lot!

Bye
Rene

[Tushar Gaba]

Rene , Though it doesn't look to be a config issue .it would be better if you keep a very basic configuration removing and timeouts and qos and then share the same results . Going by the looks of it , appears to be a phone connecting because i see access vlan there and phone vlan getting assigned which means device class attribute being pushed from server . The vlan assignments for 888 looks ok but why switch is not removing the vlan entry which was the access vlan thats where the issue is .. How about trying with single host mode .. Did you check if cdp is enabled on port .. ? Also debug epm and authentication feature vlan-assign would be handy to have ..

[Poonam Garg]

Also enable ip device tracking under your f0/3 interface.

#ip device tracking

Then shut and no shut the port to start authentication process again.

[DOUG HAYES]

I have this same issue. on a 2960S, using Cisco ACS4.3.

I think it is by design. But it is a huge security hole as mentioned, but I've seen no posted method of closing it.

http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/identity-based-networking-services/config_guide_c17-605524.html#wp9000480

1. After link up, the IP phone sends untagged traffic (assuming that the Voice VLAN has not been statically configured on the phone). All this traffic is initially dropped because the switch port is unauthorized.

2. Asynchronously from the sending of untagged traffic discussed above, the process of authentication is started and the switch sends a RADIUS-Access-Request to the AAA server.

3. Once the connecting IP phone is successfully authenticated via IEEE 802.1X or MAB, the AAA server responds with a RADIUS-Access-Accept with the device-traffic-class=voice VSA and the switch port will be authorized in the Voice domain.

4. Port forwarding is still authorized on both the Voice and Data VLANs at this point. While the switch generally limits authenticated phones to the voice VLAN, MDA makes a temporary exception to accommodate third-party phones that do not learn the voice VLAN via CDP or LLDP. Immediately after authentication, phones are allowed to send untagged traffic in the data VLAN. This allows a third party phone to learn the voice VLAN (typically via DHCP or TFTP) on the data VLAN.

5. After learning the VVID, the IP phone starts tagging traffic. The switch immediately removes the temporary access to the data VLAN and the phone is strictly limited to the voice VLAN. Access to the Data VLAN is now prohibited for the IP phone.

If a hacker is spoofing the mac address of the phone, and you issue show mac address command, you see the two VLANs associated with the MAC address. The hacker can get a DHCP address from the network DHCP server for the data vlan, and hack away, happy as a clam.  This is because he never tags the traffic, and therefore the port is never restricted.

How do we mitigate this attack ?