Switch port-security max address 1 does not limit at all.

gert00002 · ‎12-20-2013

Hi,

I tested the port security on c3560-advipservicesk9-mz.122-46.SE.bin as shown below. Despite setting a limit of one mac address, a burst of faked arp replies from 200.0.0.87 on port 23 killed the ARP table in an instant. Only the switch's own entry 200.0.0.11 survived (duplicate address detected, haha if he only knew!). Unused addresses are ignored "ignored gratuitous arp" but used go straight through. Setting the port security violation to restrict or protect is even more useless, because the attack can be repeated at any time.

Is this as expected?

What am I doing wrong?

SW1#show port int fa0/23

Port Security : Enabled

Port Status : Secure-up

Violation Mode : Shutdown

Aging Time : 0 mins

Aging Type : Absolute

SecureStatic Address Aging : Disabled

Maximum MAC Addresses : 1

Total MAC Addresses : 1

Configured MAC Addresses : 0

Sticky MAC Addresses : 0

Last Source Address:Vlan : 00e0.4c53.4458:1

Security Violation Count : 0

SW1#show arp

Protocol Address Age (min) Hardware Addr Type Interface

Internet 200.0.0.87 0 00e0.4c53.4458 ARPA Vlan1

Internet 200.0.0.11 - 0014.a804.3240 ARPA Vlan1

Internet 200.0.0.12 3 0012.d911.5940 ARPA Vlan1

Internet 200.0.0.13 3 0008.e376.adc0 ARPA Vlan1

Internet 200.0.0.14 2 f029.29ed.c140 ARPA Vlan1

Internet 200.0.0.1 0 0011.2233.4455 ARPA Vlan1

Internet 200.0.0.2 3 0015.63bd.7700 ARPA Vlan1

Internet 200.0.0.3 3 0012.8017.9220 ARPA Vlan1

Internet 200.0.0.4 3 0017.9496.7444 ARPA Vlan1

Internet 200.0.0.5 3 081f.f36e.5632 ARPA Vlan1

Internet 200.0.0.6 3 001f.6cec.5d74 ARPA Vlan1

SW1#

01:46:34: IP ARP: rcvd rep src 200.0.0.1 0011.2233.4455, dst 200.0.0.30 Vlan1

01:46:34: IP ARP: rcvd rep src 200.0.0.2 0011.2233.4456, dst 200.0.0.31 Vlan1

01:46:34: IP ARP: rcvd rep src 200.0.0.3 0011.2233.4457, dst 200.0.0.32 Vlan1

01:46:34: IP ARP: rcvd rep src 200.0.0.4 0011.2233.4458, dst 200.0.0.33 Vlan1

01:46:34: IP ARP: rcvd rep src 200.0.0.5 0011.2233.4459, dst 200.0.0.34 Vlan1

01:46:34: IP ARP: rcvd rep src 200.0.0.6 0011.2233.445a, dst 200.0.0.35 Vlan1

01:46:34: IP ARP: rcvd rep src 200.0.0.7 0011.2233.445b, dst 200.0.0.36 Vlan1

01:46:34: IP ARP: ignored gratuitous arp src 200.0.0.7 0011.2233.445b, dst 200.0.0.36 0014.a804.3240, interface Vlan1

01:46:34: IP ARP: rcvd rep src 200.0.0.8 0011.2233.445c, dst 200.0.0.37 Vlan1

01:46:34: IP ARP: ignored gratuitous arp src 200.0.0.8 0011.2233.445c, dst 200.0.0.37 0014.a804.3240, interface Vlan1

01:46:34: IP ARP: rcvd rep src 200.0.0.9 0011.2233.445d, dst 200.0.0.38 Vlan1

01:46:34: IP ARP: ignored gratuitous arp src 200.0.0.9 0011.2233.445d, dst 200.0.0.38 0014.a804.3240, interface Vlan1

01:46:34: IP ARP: rcvd rep src 200.0.0.10 0011.2233.445e, dst 200.0.0.39 Vlan1

01:46:34: IP ARP: ignored gratuitous arp src 200.0.0.10 0011.2233.445e, dst 200.0.0.39 0014.a804.3240, interface Vlan1

01:46:34: IP ARP: rcvd rep src 200.0.0.11 0011.2233.445f, dst 200.0.0.40 Vlan1

Dec 20 15:45:20.424: %IP-4-DUPADDR: Duplicate address 200.0.0.11 on Vlan1, sourced by 0011.2233.445f

01:46:34: IP ARP: sent rep src 200.0.0.11 0014.a804.3240,

dst 200.0.0.11 0014.a804.3240 Vlan1

01:46:34: IP ARP: rcvd rep src 200.0.0.12 0011.2233.4460, dst 200.0.0.41 Vlan1

01:46:34: IP ARP: rcvd rep src 200.0.0.13 0011.2233.4461, dst 200.0.0.42 Vlan1

01:46:34: IP ARP: rcvd rep src 200.0.0.14 0011.2233.4462, dst 200.0.0.43 Vlan1

01:46:34: IP ARP: rcvd rep src 200.0.0.15 0011.2233.4463, dst 200.0.0.44 Vlan1

01:46:34: IP ARP: ignored gratuitous arp src 200.0.0.15 0011.2233.4463, dst 200.0.0.44 0014.a804.3240, interface Vlan1

01:46:34: IP ARP: rcvd rep src 200.0.0.16 0011.2233.4464, dst 200.0.0.45 Vlan1

01:46:34: IP ARP: ignored gratuitous arp src 200.0.0.16 0011.2233.4464, dst 200.0.0.45 0014.a804.3240, interface Vlan1

01:46:34: IP ARP: rcvd rep src 200.0.0.1 0011.2233.4455, dst 200.0.0.30 Vlan1

01:46:34: IP ARP: rcvd rep src 200.0.0.2 0011.2233.4456, dst 200.0.0.31 Vlan1

01:46:34: IP ARP: rcvd rep src 200.0.0.3 0011.2233.4457, dst 200.0.0.32 Vlan1

01:46:34: IP ARP: rcvd rep src 200.0.0.4 0011.2233.4458, dst 200.0.0.33 Vlan1

Dec 20 15:45:20.449: %PM-4-ERR_DISABLE: psecure-violation error detected on Fa0/23, putting Fa0/23 in err-disable state

Dec 20 15:45:20.457: %PORT_SECURITY-2-PSECURE_VIOLATION: Security violation occurred, caused by MAC address 0014.1232.1231 on port FastEthernet0/23.

Dec 20 15:45:21.456: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/23, changed state to down

Dec 20 15:45:22.462: %LINK-3-UPDOWN: Interface FastEthernet0/23, changed state to down

SW1#show arp

Protocol Address Age (min) Hardware Addr Type Interface

Internet 200.0.0.87 0 00e0.4c53.4458 ARPA Vlan1

Internet 200.0.0.11 - 0014.a804.3240 ARPA Vlan1

Internet 200.0.0.12 0 0011.2233.4460 ARPA Vlan1

Internet 200.0.0.13 0 0011.2233.4461 ARPA Vlan1

Internet 200.0.0.14 0 0011.2233.4462 ARPA Vlan1

Internet 200.0.0.1 0 0011.2233.4455 ARPA Vlan1

Internet 200.0.0.2 0 0011.2233.4456 ARPA Vlan1

Internet 200.0.0.3 0 0011.2233.4457 ARPA Vlan1

Internet 200.0.0.4 0 0011.2233.4458 ARPA Vlan1

Internet 200.0.0.5 0 0011.2233.4459 ARPA Vlan1

Internet 200.0.0.6 0 0011.2233.445a ARPA Vlan1

SW1#

Rolf Fischer · ‎12-21-2013

Hi,

could you tell us how you tested the port-security feature?

Port-security can only indirectly prevent from ARP-attacks because it inspects the source MAC-addresses of the ethernet-frames, whereas the ARP-table is built from the payload of ARP-packets.

Normally, the sender MAC-address in an ARP reply and the source in the ethernet frame should be the same, but that's not mandatory.

Have a look at this ARP-reply from a Microsoft "NLB" in "Unicast Mode":

As you can see, the sender MAC in the ARP reply is different from the source (this is, by the way, how they achieve their "Load Balancing": Downgrade a switch to a hub), so from a port-security's persepective, everything's alright.

If you want to prevent from ARP attacks on Catalyst switches efficiently, Dynamic ARP Inspection (DAI) would be the recommended solution.

HTH

Rolf

gert00002 · ‎12-21-2013

Hi Rolf,

I used the software Ostinato to generate the faked request, as seen in the debug, using the switch mac as the target.

The source mac address was anything and counted up, so for the switch it must be considered different systems "out there" sending. Else the switch would not shut down the port.

I just expected the switch to shutdown the port immediately upon receiving any packet with a second mac address. If I send the packets one per second, then the switch shut down the port after the first packed. But the switch got 100 Mbit ports. However, the requirement is to block any attempts to destroy the ARP table. Problably the switch have different processes for filling the ARP table and detecting "more than one mac-address used" violations. So if the attacker is fast enough he is winning. We may consider connecting all workstations with 9.600 baud, that will fix the problem ;-)))))

Fixing the Problem with DAI was considered, but that is not flexible and I don't think it will fix the issue either.

Gert