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)
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
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 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
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
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
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
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!
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.
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.
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.
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 ?