Still Guarding the Edge with Junos

Again we come to the topic of guarding the edge. Another day, another battle. Last time it was Spanning-tree defence mechanisms, today it is mac address spoofing. Every device has a MAC address and is populated into a devices CAM table. The CAM table knows which interface the MAC address is associated to. CAM tables are a finite resource and can be overwhelmed. If someone wants to cause all traffic to be broadcast out of all switch ports all that needs to be done is the CAM table overloaded. This can generally be achieved with MAC spoofing and flooding.

srx110-left-high

This post will show how you can prevent this with a Juniper SRX. First of all let us look a the lab from last time.

Screen Shot 2013-02-03 at 6.20.44 PM

With this lab I have added five additional NICs to tc_001_Customer_A and tc_002_Customer_A to simulate extra hosts/MAC addresses. A flood can also be performed by many tools. This means when each device starts up there will be a huge number of MAC addresses communicating across vNIC0 and up to fe-0/0/1.0.

By default you can have as many MAC addresses on a port as you like. This can be fine in some environments but as you know, MAC flooding can occur and can prove fatal for a switch. I am going to show you how to limit and drop additional MAC addresses or shut the port down completely.

[email protected]> show ethernet-switching table    
Ethernet-switching table: 5 entries, 3 learned, 0 persistent entries
  VLAN              MAC address       Type         Age Interfaces
  vlan-trust        *                 Flood          - All-members
  vlan-trust        00:0c:29:64:81:38 Learn          0 fe-0/0/1.0
  vlan-trust        00:0c:29:64:81:6a Learn          0 fe-0/0/1.0
  vlan-trust        40:6c:8f:52:55:b5 Learn          0 fe-0/0/1.0
  vlan-trust        b0:a8:6e:66:e2:08 Static         - Router

Okay so as you can see quite a few machines on an access port. Well you wouldn’t want this in an end user access layer so you would employ MAC security. In my case I don’t expect more than 2 virtual guests on my ESXi host with 1 MAC address each. One for the NIC and that makes three. I plan to install a few more VMs later in the week so I will set the limit for 10.

[email protected]# set ethernet-switching-options secure-access-port interface fe-0/0/1.0 mac-limit 10 action drop   

[email protected]> show configuration ethernet-switching-options 
secure-access-port {
    interface fe-0/0/1.0 {
        mac-limit 10 action drop;
    }
}

Okay now I have set the SRX to drop any further connections after 10 dynamically learned mac addresses are counted on an interface. This process also logs when this occurs. Time to spin up the interfaces.

Screen Shot 2013-02-03 at 9.29.19 PM

As I add more NIC’s, more MAC addresses are learnt by the SRX. This leads to the CAM table learning more MAC addresses associated to the interface. Once we get to 10….

[email protected]> show interfaces fe-0/0/1.0 terse 
Interface               Admin Link Proto    Local                 Remote
fe-0/0/1.0              up    up   eth-switch

As we know the interface doesn’t drop so time to check the log.

[email protected]> show log messages | match ESWD_MAC | match 10:31
Feb  3 10:31:04  SRX110 eswd[1374]: ESWD_MAC_LIMIT_DROP: MAC limit (10) exceeded at fe-0/0/1.0: dropping the packet

Bingo! We can see that excess requests are being dropped and logged. Fantastic. On a server port this is what we want. We don’t want to lose communication to legitimate VM’s but we want to alert an administrator to investigate.

Now pretend we are on an end-user port. If this is the case then we don’t want to let them continue to do things as more than likely someone is trying to exploit a device. Lets change drop to shut down.

[email protected]# set ethernet-switching-options secure-access-port interface fe-0/0/1.0 mac-limit action shutdown

Not much different in command input but a lot different in action. Let us restart the VM’s and check. Remember our VM’s are pretending to send a MAC flood.

[email protected]> show interfaces fe-0/0/1.0 terse 
Interface               Admin Link Proto    Local                 Remote
fe-0/0/1.0              up    up   eth-switch

[email protected]> show interfaces fe-0/0/1.0 terse    
Interface               Admin Link Proto    Local                 Remote
fe-0/0/1.0              up    down eth-switch

There goes the neighbourhood. Now to check out the log!

[email protected]> show log messages | match ESWD_MAC | match 11:1   
Feb  3 11:10:45  SRX110 eswd[1374]: ESWD_MAC_LIMIT_BLOCK: MAC limit (10) exceeded at fe-0/0/1.0: shutting down the interface

There we are. A hit, a fine hit. This is rather a disruptive method but I believe imperative at the end-user level. Look at my connection to my ESXi host.

Screen Shot 2013-02-03 at 10.11.10 PM

Now it is important. Once the threat has been identified you want to enable the switchport again. This is done by the following command.

[email protected]> clear ethernet-switching port-error interface fe-0/0/1.0 

[email protected]> clear ethernet-switching port-error 

[email protected]> show interfaces fe-0/0/1.0 terse 
Interface Admin Link Proto Local Remote
fe-0/0/1.0 up up eth-switch

Either or works. Just remember the latter one is global.

This technology isn’t new and nor is it hard to configure. Once you have established what is expected network traffic in your environment, you should get around to configuring this. It makes life much easier knowing someone can’t flood your network and crash your access layer switches.

Leave a Reply

Your email address will not be published. Required fields are marked *

*