Arista MLS EOS 4.2x L2S Security Technical Implementation Guide

  • Version/Release: V2R1
  • Published: 2024-06-04
  • Released: 2024-07-24
  • Expand All:
  • Severity:
  • Sort:
Compare

Select any two versions of this STIG to compare the individual requirements

View

Select any old version/release of this STIG to view the previous requirements

This Security Technical Implementation Guide is published as a tool to improve the security of Department of Defense (DOD) information systems. The requirements are derived from the National Institute of Standards and Technology (NIST) 800-53 and related documents. Comments or proposed revisions to this document should be sent via email to the following address: disa.stig_spt@mail.mil.
c
The Arista MLS layer 2 switch must uniquely identify all network-connected endpoint devices before establishing any connection.
IA-3 - High - CCI-000778 - V-255968 - SV-255968r882246_rule
RMF Control
IA-3
Severity
High
CCI
CCI-000778
Version
ARST-L2-000020
Vuln IDs
  • V-255968
Rule IDs
  • SV-255968r882246_rule
Controlling LAN access via 802.1x authentication can assist in preventing a malicious user from connecting an unauthorized PC to a switch port to inject or receive data from the network without detection. Satisfies: SRG-NET-000148-L2S-000015, SRG-NET-000343-L2S-000016
Checks: C-59644r882244_chk

Verify the Arista MLS switch configuration has 802.1x authentication implemented for all access switch ports connecting to LAN outlets (i.e., RJ-45 wall plates) or devices not located in the telecom room, wiring closets, or equipment rooms. MAC Authentication Bypass (MAB) must be configured on switch ports connected to devices that do not provide an 802.1x supplicant. Verify the Arista MLS switch configuration for 802.1x is configured globally and, on the required host-based access ports or MAB, is configured on ports that require RADIUS and MAC-based supplicants. switch# show run | section dot1x logging level DOT1X informational  aaa authentication dot1x default group radius  dot1x system-auth-control ! interface Ethernet6 description 802.1X Access Network switchport access vlan 100 dot1x pae authenticator dot1x reauthentication dot1x port-control auto dot1x host-mode single-host dot1x timeout quiet-period 10 ! interface Ethernet7 description STIG MAC-Based Authentication speed 100full dot1x pae authenticator dot1x port-control auto dot1x mac based authentication ! If 802.1x authentication or MAB is not configured on all access switch ports connecting to LAN outlets or devices not located in the telecom room, wiring closets, or equipment rooms, this is a finding.

Fix: F-59587r882245_fix

Configure Arista MLS switch for 802.1X globally with the following mandatory parameters, and then configure non-data center access ports and all applicable interfaces. Step 1: Configure the Arista MLS switch for 802.1X globally using the following commands: ! logging level DOT1X informational  aaa authentication dot1x default group radius  dot1x system-auth-control ! Step 2: Configure the Arista switch for all non-data center access ports with 802.1X VLAN to an access/trunk port and set the 802.1X port access entity (PAE) to authenticator with the following commands: interface Ethernet4 description 802.1X Host-Mode Access Port switchport access vlan 100 dot1x pae authenticator dot1x reauthentication dot1x port-control auto dot1x host-mode single-host dot1x timeout quiet-period 10 ! Step 3: The Arista switch can be also configured for MAC-based authentication. Configuring MAB requires that every supplicant trying to gain access to the switch authenticator port is individually authenticated by MAC address as opposed to authenticating just one supplicant on a given VLAN or port with 802.1X, and then using the MAC address of these devices as username and password in the RADIUS request packets. ! interface Ethernet7 description MAC-Based Authentication speed 100full dot1x pae authenticator dot1x port-control auto dot1x mac based authentication !

b
The Arista MLS layer 2 switch must be configured for Storm Control to limit the effects of packet flooding types of denial-of-service (DoS) attacks.
SC-5 - Medium - CCI-001095 - V-255969 - SV-255969r991773_rule
RMF Control
SC-5
Severity
Medium
CCI
CCI-001095
Version
ARST-L2-000030
Vuln IDs
  • V-255969
Rule IDs
  • SV-255969r991773_rule
Denial of service is a condition when a resource is not available for legitimate users. Packet flooding distributed DoS (DDoS) attacks are referred to as volumetric attacks and have the objective of overloading a network or circuit to deny or seriously degrade performance, which denies access to the services that normally traverse the network or circuit. Volumetric attacks have become relatively easy to launch by using readily available tools such as Low Orbit Ion Cannon or by using botnets. Measures to mitigate the effects of a successful volumetric attack must be taken to ensure that sufficient capacity is available for mission-critical traffic. Managing capacity may include, for example, establishing selected network usage priorities or quotas and enforcing them using rate limiting, Quality of Service (QoS), or other resource reservation control methods. These measures may also mitigate the effects of sudden decreases in network capacity that are the result of accidental or intentional physical damage to telecommunications facilities (such as cable cuts or weather-related outages). Satisfies: SRG-NET-000193-L2S-000020, SRG-NET-000362-L2S-000024, SRG-NET-000512-L2S-000001
Checks: C-59645r882247_chk

Verify the Arista MLS switch is configured for storm-control on applicable Ethernet interfaces. switch#show storm-control Port Type Level Rate(Mbps) Status Drops Reason Et10/2 all 75 7500 active 0 Et4 multicast 55 5500 active 0 Et4 broadcast 50 5000 active switch# If the Arista MLS switch is not configured to implement a storm-control policy, this is a finding.

Fix: F-59588r882248_fix

The Arista MLS switch must be configured to implement a storm-control policy for traffic prioritization and bandwidth reservation. Storm-control on switch Ethernet interfaces can be configured to limit the packets based on broadcast, multicast, and unknown-unicast traffic: switch#configure switch(config)#internet et[X] interface Ethernet[X]  switchport    storm-control broadcast level pps 5000    storm-control multicast level pps 5000    storm-control unknown-unicast level pps 5000

a
The Arista MLS switch must have Root Guard enabled on all switch ports connecting to access layer switches and hosts.
SC-5 - Low - CCI-002385 - V-255970 - SV-255970r882252_rule
RMF Control
SC-5
Severity
Low
CCI
CCI-002385
Version
ARST-L2-000050
Vuln IDs
  • V-255970
Rule IDs
  • SV-255970r882252_rule
Spanning Tree Protocol (STP) does not provide any means for the network administrator to securely enforce the topology of the switched network. Any switch can be the root bridge in a network. However, a more optimal forwarding topology places the root bridge at a specific predetermined location. With the standard STP, any bridge in the network with a lower bridge ID takes the role of the root bridge. The administrator cannot enforce the position of the root bridge but can set the root bridge priority to 0 in an effort to secure the root bridge position.
Checks: C-59646r882250_chk

Review the Arista MLS switch topology as well as the configuration to verify that root guard is enabled on switch ports facing switches that are downstream from the root bridge. Example: switch#sh run | sec guard root interface Ethernet37 spanning-tree guard root If the Arista MLS switch has not enabled guard root on all ports connecting to the access layer where the root bridge must not appear, this is a finding.

Fix: F-59589r882251_fix

The Arista MLS switch must be configured for spanning-tree guard root mode on all ports connecting to the access layer interface. Configure Arista MLS switch Ethernet interface with the following commands: switch#config  switch(config)interface Ethernet[X]  switch(config-if-Et[X])#spanning-tree guard root switch(config-if-Et[X])#exit !

b
The Arista MLS layer 2 switch must have BPDU Guard enabled on all switch ports connecting to access layer switches and hosts.
SC-5 - Medium - CCI-002385 - V-255971 - SV-255971r882255_rule
RMF Control
SC-5
Severity
Medium
CCI
CCI-002385
Version
ARST-L2-000060
Vuln IDs
  • V-255971
Rule IDs
  • SV-255971r882255_rule
If a rogue switch is introduced into the topology and transmits a Bridge Protocol Data Unit (BPDU) with a lower bridge priority than the existing root bridge, it will become the new root bridge and cause a topology change, rendering the network in a suboptimal state. The STP PortFast BPDU guard enhancement allows network designers to enforce the STP domain borders and keep the active topology predictable. The devices behind the ports that have STP PortFast enabled are not able to influence the STP topology. At the reception of BPDUs, the BPDU guard operation disables the port that has PortFast configured. The BPDU guard transitions the port into a disabled state and sends a log message.
Checks: C-59647r882253_chk

Review the Arista MLS to verify that BPDU Guard is enabled on all user-facing or untrusted access switch ports. switch#show run | section bpdu interface Ethernet37 spanning-tree bpduguard enable If the Arista MLS switch has not enabled BPDU Guard, this is a finding.

Fix: F-59590r882254_fix

The Arista MLS switch provides the capability to configure "spanning-tree bpduguard". Configure the Ethernet interface commands: config  interface Ethernet[X]  switch(config)#interface ethernet [X] switch(config-if-Et[X])#spanning-tree bpduguard enabled switch(config-if-Et[X])

b
The Arista MLS switch must have STP Loop Guard enabled on all nondesignated STP switch ports.
SC-5 - Medium - CCI-002385 - V-255972 - SV-255972r882258_rule
RMF Control
SC-5
Severity
Medium
CCI
CCI-002385
Version
ARST-L2-000070
Vuln IDs
  • V-255972
Rule IDs
  • SV-255972r882258_rule
The Spanning Tree Protocol (STP) loop guard feature provides additional protection against STP loops. An STP loop is created when an STP blocking port in a redundant topology erroneously transitions to the forwarding state. In its operation, STP relies on continuous reception and transmission of BPDUs based on the port role. The designated port transmits BPDUs, and the nondesignated port receives BPDUs. When one of the ports in a physically redundant topology no longer receives BPDUs, the STP conceives that the topology is loop free. Eventually, the blocking port from the alternate or backup port becomes a designated port and moves to a forwarding state. This situation creates a loop. The loop guard feature makes additional checks. If BPDUs are not received on a nondesignated port and loop guard is enabled, that port is moved into the STP loop-inconsistent blocking state.
Checks: C-59648r882256_chk

Review the Arista MLS switch configuration to verify that STP Loop Guard is enabled. It can be enabled globally or applied to an interface. switch# sh run | sec spanning-tree spanning-tree guard loop default Or, interface Ethernet6 spanning-tree guard loop If STP Loop Guard is not configured globally or on nondesignated STP ports, this is a finding.

Fix: F-59591r882257_fix

Configure the Arista MLS switch for STP Loop Guard globally with the following command: switch(config)#spanning-tree guard loop default switch(config)# Alternatively, configure Loop Guard on each interface: switch(config-if-Eth6)# spanning-tree guard loop

b
The Arista MLS layer 2 switch must have DHCP snooping for all user VLANs to validate DHCP messages from untrusted sources.
SC-5 - Medium - CCI-002385 - V-255973 - SV-255973r882261_rule
RMF Control
SC-5
Severity
Medium
CCI
CCI-002385
Version
ARST-L2-000090
Vuln IDs
  • V-255973
Rule IDs
  • SV-255973r882261_rule
In an enterprise network, devices under administrative control are trusted sources. These devices include the switches, routers, and servers in the network. Host ports and unknown DHCP servers are considered untrusted sources. An unknown DHCP server on the network on an untrusted port is called a spurious DHCP server, any device (PC, Wireless Access Point) that is loaded with DHCP server enabled. The DHCP snooping feature determines whether traffic sources are trusted or untrusted. The potential exists for a spurious DHCP server to respond to DHCPDISCOVER messages before the real server has time to respond. DHCP snooping allows switches on the network to trust the port a DHCP server is connected to and not trust the other ports. The DHCP snooping feature validates DHCP messages received from untrusted sources and filters out invalid messages as well as rate-limits DHCP traffic from trusted and untrusted sources. DHCP snooping feature builds and maintains a binding database, which contains information about untrusted hosts with leased IP addresses, and it utilizes the database to validate subsequent requests from untrusted hosts. Other security features, such as IP Source Guard and Dynamic Address Resolution Protocol (ARP) Inspection (DAI), also use information stored in the DHCP snooping binding database. Hence, it is imperative that the DHCP snooping feature is enabled on all user VLANs.
Checks: C-59649r882259_chk

Review the Arista MLS switch configuration and verify that DHCP snooping is enabled on all user VLANs. Verify the Arista MLS has the DHCP Snooping feature enabled globally by executing "show ip dhcp snooping". switch(config)# show ip dhcp snooping DHCP Snooping is enabled DHCP Snooping is operational DHCP Snooping is configured on following VLANs: 650 DHCP Snooping is operational on following VLANs: 650 If the Arista MLS switch does not have DHCP snooping enabled for all user VLANs to validate DHCP messages from untrusted sources, this is a finding.

Fix: F-59592r882260_fix

Configure the Arista MLS switch to have DHCP snooping enabled globally and for all user VLANs to validate DHCP messages from untrusted sources. Step 1: Configure DHCP Snooping globally by using the following command: switch(config)# ip dhcp snooping Step 2: Configure DHCP Snooping to enable the insertion of option-82 in DHCP request packets. By default, option-82 is not enabled and without this, DHCP Snooping is not operational. switch(config)#ip dhcp snooping information option Step 3: Configure the Arista MLS switch to enable IP DHCP Snooping on the corresponding VLANs. By default, DHCP Snooping will not be enabled on any VLAN. switch(config)#ip dhcp snooping vlan <vlan-id> Step 4: Configure the following command to set the circuit-id information that will be sent in option-82. By default, Interface name and VLAN ID are sent. Remote circuit-id will always be the MAC address of the relay agent. switch# ip dhcp snooping information option circuit-id type 2 format Hostname and interface name Interface name and VLAN ID

b
The Arista MLS layer 2 switch must have IP Source Guard enabled on all user-facing or untrusted access switch ports.
SC-5 - Medium - CCI-002385 - V-255974 - SV-255974r882264_rule
RMF Control
SC-5
Severity
Medium
CCI
CCI-002385
Version
ARST-L2-000100
Vuln IDs
  • V-255974
Rule IDs
  • SV-255974r882264_rule
IP Source Guard (IPSG) provides source IP address filtering on a layer 2 port to prevent a malicious host from impersonating a legitimate host by assuming the legitimate host's IP address. The feature uses dynamic DHCP snooping and static IP source binding to match IP addresses to hosts on untrusted Layer 2 access ports. Initially, all IP traffic on the protected port is blocked except for DHCP packets. After a client receives an IP address from the DHCP server, or after static IP source binding is configured by the administrator, all traffic with that IP source address is permitted from that client. Traffic from other hosts is denied. This filtering limits a host's ability to attack the network by claiming a neighbor host's IP address.
Checks: C-59650r882262_chk

Review the Arista MLS switch configuration to verify that IPSG is enabled on all user-facing or untrusted access switch ports. Step 1: The Arista MLS switch command verifies the IPSG configuration and operational states. switch(config)#show ip verify source Interface Operational State --------------- ------------------------ Ethernet1 IP source guard enabled Ethernet2 IP source guard disabled Step 2: The following command displays all VLANs configured in no IP verify source VLAN: switch(config)#show ip verify source vlan IPSG disabled on VLANS: 1-2 VLAN Operational State --------------- ------------------------ 1 IP source guard disabled 2 Error: vlan classification failed If the Arista MLS switch does not have IP Source Guard enabled on all untrusted access switch ports, this is a finding.

Fix: F-59593r882263_fix

Configure the Arista MLS switch to have IPSG enabled on all user-facing or untrusted access switch ports. Step 1: The Arista MLS IPSG feature must be configured by applying filters to inbound IP packets based on their source MAC and IP addresses. The following example commands exclude VLAN IDs 1 through 3 from IPSG filtering. When enabled on a trunk port, IPSG filters the inbound IP packets on all allowed VLANs. IP packets received on VLANs 4 through 10 on Ethernet 36 will be filtered by IPSG, while those received on VLANs 1 through 3 are permitted. switch(config)#no ip verify source vlan 1-3 switch(config)#interface ethernet 36 switch(config-if-Et36)#switchport mode trunk switch(config-if-Et36)#switchport trunk allowed vlan 1-10 switch(config-if-Et36)#ip verify source switch(config-if-Et36)# Step 2: By using the Arista MLS switch command, the switch binds the source IP-MAC binding entries to IP address 10.1.1.1, MAC address 0000.aaaa.1111, VLAN ID 4094, and Ethernet interface 36. switch(config)#ip source binding 10.1.1.1 0000.aaaa.1111 vlan 4094 interface ethernet 36 switch(config)#

b
The Arista MLS layer 2 switch must have Dynamic Address Resolution Protocol (ARP) Inspection (DAI) enabled on all user VLANs.
SC-5 - Medium - CCI-002385 - V-255975 - SV-255975r882267_rule
RMF Control
SC-5
Severity
Medium
CCI
CCI-002385
Version
ARST-L2-000110
Vuln IDs
  • V-255975
Rule IDs
  • SV-255975r882267_rule
DAI intercepts Address Resolution Protocol (ARP) requests and verifies that each of these packets has a valid IP-to-MAC address binding before updating the local ARP cache and before forwarding the packet to the appropriate destination. Invalid ARP packets are dropped and logged. DAI determines the validity of an ARP packet based on valid IP-to-MAC address bindings stored in the DHCP snooping binding database. If the ARP packet is received on a trusted interface, the switch forwards the packet without any checks. On untrusted interfaces, the switch forwards the packet only if it is valid.
Checks: C-59651r882265_chk

Review the Arista MLS switch configuration to verify that Dynamic Address Resolution Protocol (ARP) Inspection (DAI) feature is enabled on all user VLANs. Verify ARP inspection for user VLANs by the following command: sh ip arp inspection vlan VLAN 2200 ------------ Configuration: Enabled Operation State: Active If static ARP inspection is not enabled on all user VLANs, this is a finding.

Fix: F-59594r882266_fix

Configure the Arista MLS switch to have static Address Resolution Protocol (ARP) Inspection to be enabled on all user VLANs. By default, Arista MLS switch static ARP Inspection is disabled on all VLANs. Static ARP inspection can be enabled on all specific user VLANs by using the following command: switch(config)#ip arp inspection vlan <vlan-list>

a
The Arista MLS layer 2 switch must have IGMP or MLD Snooping configured on all VLANs.
CM-6 - Low - CCI-000366 - V-255976 - SV-255976r882270_rule
RMF Control
CM-6
Severity
Low
CCI
CCI-000366
Version
ARST-L2-000130
Vuln IDs
  • V-255976
Rule IDs
  • SV-255976r882270_rule
IGMP and MLD snooping provides a way to constrain multicast traffic at Layer 2. By monitoring the IGMP or MLD membership reports sent by hosts within a VLAN, the snooping application can set up Layer 2 multicast forwarding tables to deliver specific multicast traffic only to interfaces connected to hosts interested in receiving the traffic, thereby significantly reducing the volume of multicast traffic that would otherwise flood the VLAN.
Checks: C-59652r882268_chk

Review the Arista MLS switch configuration to verify that IGMP or MLD snooping has been configured. Determine which snooping feature is used. For IGMP: Verify the PIM that also enables IGMP on an Arista MLS switch VLAN interface by using the "sh run interface vlan8" command: switch(config)#sh run int vlan8 interface VLAN8 ip igmp pim ipv4 sparse-mode switch(config)#exit For MLD: Verify the Arista MLS switch is configured for MLD snooping on an interface for version 1 and 2. Version 2 is the default MLD version. switch#sh run | section mld mld snooping vlan 200 If the Arista switch is not configured to implement IGMP or MLD snooping for each VLAN, this is a finding.

Fix: F-59595r882269_fix

Configure the Arista MLS switch for IGMP snooping for IPv4 and IPv6 multicast traffic for each VLAN. Configure the Arista MLS switch for IP PIM, which also enables IGMP on an Arista MLS switch VLAN or interface, by using the following command: switch(config)#int vlan8 ip igmp pim ipv4 sparse-mode pim ipv6 sparse-mode switch(config)#exit ! Arista MLS switch alternative configuration for MLD snooping on an interface for version 1 and 2. Version 2 is the default MLD version. switch(config)# mld snooping switch(config-mld-snooping)# vlan 200 !

b
The Arista MLS layer 2 Arista MLS switch must implement Rapid STP where VLANs span multiple switches with redundant links.
CM-6 - Medium - CCI-000366 - V-255977 - SV-255977r882273_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
ARST-L2-000140
Vuln IDs
  • V-255977
Rule IDs
  • SV-255977r882273_rule
Spanning Tree Protocol (STP) is implemented on bridges and switches to prevent layer 2 loops when a broadcast domain spans multiple bridges and switches and when redundant links are provisioned to provide high availability in case of link failures. Convergence time can be significantly reduced using Multiple Spanning-Tree (802.1s) instead of Rapid STP (802.1w) instead of STP (802.1d), resulting in improved availability. Multiple Spanning-Tree Protocol (MSTP) should be deployed by implementing either Rapid Per-VLAN-Spanning-Tree (Rapid-PVST) or Multiple Spanning-Tree MST, the latter scales topologies much better when there are many VLANs.
Checks: C-59653r882271_chk

In cases where VLANs do not span multiple switches, it is a best practice to not implement STP. Avoiding the use of STP will provide the most deterministic and highly available network topology. If STP is required, review the Arista MLS switch configuration to verify that Rapid STP has been implemented. switch(config)#sh run | sec spanning-tree spanning-tree mode rstp ! Note: MSTP can be configured as an alternate mode. MSTP uses RSTP for rapid convergence and enables multiple VLANs to be grouped into and mapped to the same spanning-tree instance, thereby reducing the number of spanning-tree instances needed to support a large number of VLANs. If MSTP or Rapid STP has not been implemented where STP is required, this is a finding.

Fix: F-59596r882272_fix

Configure the Arista MLS switch for Multiple Spanning-tree (MST) or Rapid STP to be implemented at the access and distribution layers where VLANs span multiple switches. switch(config)#spanning-tree mode mstp The Arista MLS switch can alternatively be configured for spanning-tree mode RSTP to support a spanning-tree instance for each VLAN: switch(config)# spanning-tree mode rstp !

b
The Arista MLS layer 2 switch must enable Unidirectional Link Detection (UDLD) to protect against one-way connections.
CM-6 - Medium - CCI-000366 - V-255978 - SV-255978r882276_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
ARST-L2-000150
Vuln IDs
  • V-255978
Rule IDs
  • SV-255978r882276_rule
In topologies where fiber optic interconnections are used, physical misconnections can occur that allow a link to appear to be up when there is a mismatched set of transmit/receive pairs. When such a physical misconfiguration occurs, protocols such as STP can cause network instability. UDLD is a layer 2 protocol that can detect these physical misconfigurations by verifying that traffic is flowing bidirectionally between neighbors. Ports with UDLD enabled periodically transmit packets to neighbor devices. If the packets are not echoed back within a specific time frame, the link is flagged as unidirectional and the interface is shut down.
Checks: C-59654r882274_chk

If any of the switch ports have fiber optic interconnections with neighbors, review the Arista MLS switch configuration to verify that Loop Guard is enabled globally or on a per interface basis. switch# sh run | sec spanning-tree spanning-tree guard loop default Or, interface Ethernet6 spanning-tree guard loop If the switch has fiber optic interconnections with neighbors and Loop Guard is not enabled, this is a finding.

Fix: F-59597r882275_fix

Configure the Arista MLS switch to enable Loop Guard to prevent Unidirectional Link Detection (UDLD) and to protect against one-way connections. switch(config)#spanning-tree guard loop default switch(config)# Alternatively, configure Loop Guard on each interface: switch(config-if-Eth6)# spanning-tree guard loop Note: UDLD is a Cisco-proprietary protocol. However, other switch vendors, such as 3Com, Extreme, and D-Link, have similar functionality in their products, respectively: Device Link Detection Protocol (DLDP), Extreme Link Status Monitoring (ELSM), and D-Link Unidirectional Link Detection (DULD).

b
The Arista MLS layer 2 switch must have all trunk links enabled statically.
CM-6 - Medium - CCI-000366 - V-255979 - SV-255979r882279_rule
RMF Control
CM-6
Severity
Medium
CCI
CCI-000366
Version
ARST-L2-000160
Vuln IDs
  • V-255979
Rule IDs
  • SV-255979r882279_rule
When trunk negotiation is enabled via Dynamic Trunk Protocol (DTP), considerable time can be spent negotiating trunk settings (802.1q or ISL) when a node or interface is restored. While this negotiation is happening, traffic is dropped because the link is up from a layer 2 perspective. Packet loss can be eliminated by setting the interface statically to trunk mode, thereby avoiding dynamic trunk protocol negotiation and significantly reducing any outage when restoring a failed link or switch.
Checks: C-59655r882277_chk

Review the Arista MLS switch configuration to verify that all Ethernet interfaces designated as trunk links are statically configured to specify only member tagged VLAN traffic is allowed and all nonmember VLAN traffic will be dropped unless untagged traffic is associated with the interface's native VLAN. switch#show run | section trunk ! interface Ethernet6 description STIG Static Trunk speed forced 10000full switchport trunk native vlan 2102 switchport trunk allowed vlan 2100-2102 switchport mode trunk ! If trunk negotiation is enabled on any interface, this is a finding.

Fix: F-59598r882278_fix

Configure static Ethernet interfaces for switchport trunk mode. Ensure required VLAN member tagged traffic is allowed and all other VLAN traffic will be dropped unless an associated untagged native VLAN for the Ethernet interface is allowed. switch#configure switch(config)#interface Ethernet6 description STIG Static Trunk speed forced 10000full switchport trunk native vlan 2102 switchport trunk allowed vlan 2100-2102 switchport mode trunk ! switch(config)#interface Ethernet7 description STIG Static Trunk speed forced 10000full switchport trunk native vlan 3102 switchport trunk allowed vlan 3100-3102 switchport mode trunk !

b
The Arista MLS layer 2 switch must have all disabled switch ports assigned to an unused VLAN.
- Medium - CCI-004891 - V-255980 - SV-255980r991774_rule
RMF Control
Severity
Medium
CCI
CCI-004891
Version
ARST-L2-000170
Vuln IDs
  • V-255980
Rule IDs
  • SV-255980r991774_rule
It is possible that a disabled port that is assigned to a user or management VLAN becomes enabled by accident or by an attacker and as a result gains access to that VLAN as a member.
Checks: C-59656r882280_chk

Step 1: Review the switch configuration and examine all access switch ports. Verify the unused port is configured to be intentionally shut down and assigned to an inactive VLAN. switch(config)#sh run int eth8 interface Ethernet8 description PORT IS INTENTIONALLY SHUTDOWN switchport access vlan 999 shutdown switch(config)# Step 2: Verify traffic from the inactive VLAN is not allowed on any trunk links as shown in the example below: switch(config)#sh run int eth9 interface Ethernet9 switchport trunk native vlan 1000 switchport trunk allowed vlan 2-998, 1001-4094 switchport mode trunk switch(config)# If any access switch ports are not in use and not in an inactive shutdown, this is a finding. Note: Switch ports configured for 802.1x are exempt from this requirement.

Fix: F-59599r882281_fix

Configure all Arista MLS switch ports not in use to be shut down and assigned to an unused VLAN. Step 1: Configure all unused ports to be shut down and assigned to an unused VLAN. switch(config)#interface ethernet 9 switch(config-eth9)#shutdown switch(config-eth9)# description this port is intentionally shutdown switch(config-eth9)# switchport access vlan 999 Step 2: Configure any trunk links to exclude the unused VLAN. switch(config)# interface ethernet 10 switch(config-eth10)# switchport trunk native vlan 1000 switch(config-eth9)# switchport trunk allowed vlan 2-998, 1001-4094 switch(config-eth9)# switchport mode trunk

b
The Arista MLS layer 2 switch must not have the default VLAN assigned to any host-facing switch ports.
- Medium - CCI-004891 - V-255981 - SV-255981r991775_rule
RMF Control
Severity
Medium
CCI
CCI-004891
Version
ARST-L2-000180
Vuln IDs
  • V-255981
Rule IDs
  • SV-255981r991775_rule
In a VLAN-based network, switches use the default VLAN (i.e., VLAN 1) for in-band management and to communicate with other networking devices using Spanning-Tree Protocol (STP), Dynamic Trunking Protocol (DTP), VLAN Trunking Protocol (VTP), and Port Aggregation Protocol (PAgP)—all untagged traffic. As a consequence, the default VLAN may unwisely span the entire network if not appropriately pruned. If its scope is large enough, the risk of compromise can increase significantly.
Checks: C-59657r882283_chk

Review the Arista MLS switch configurations and verify no access switch ports have been assigned membership to the default VLAN (i.e., VLAN 1). switch(config)#sh vlan VLAN Name Status Ports ----- -------------------------------- --------- ------------------------------- 1 default 8 VLAN0008 active Cpu 25 VLAN0025 active Cpu 100 VLAN0100 active Cpu 1000 VLAN1000 active Eth1, Eth2 If access switch ports are assigned to the default VLAN, this is a finding.

Fix: F-59600r882284_fix

Configure the Arista MLS switch to remove the assignment of the default VLAN from all access switch ports. Step 1: Configure the Default VLAN 1 to shut down by using the following command: switch:(config#)interface vlan 1 switch(config-int-vlan1)#shutdown Step 2: Configure all access switch ports to be placed in a VLAN other than the default (1): switch(config)#interface ethernet 8 switch(config-eth8)#switchport access vlan 1000 switch(config-eth8)#exit

b
The Arista MLS layer 2 switch must have the default VLAN pruned from all trunk ports that do not require it.
- Medium - CCI-004891 - V-255982 - SV-255982r991776_rule
RMF Control
Severity
Medium
CCI
CCI-004891
Version
ARST-L2-000190
Vuln IDs
  • V-255982
Rule IDs
  • SV-255982r991776_rule
The default VLAN (i.e., VLAN 1) is a special VLAN used for control plane traffic such as Spanning-Tree Protocol (STP), Dynamic Trunking Protocol (DTP), VLAN Trunking Protocol (VTP), and Port Aggregation Protocol (PAgP). VLAN 1 is enabled on all trunks and ports by default. With larger campus networks, care needs to be taken about the diameter of the STP domain for the default VLAN. Instability in one part of the network could affect the default VLAN, thereby influencing control-plane stability and therefore STP stability for all other VLANs.
Checks: C-59658r882286_chk

Review the Arista MLS switch configuration and verify the default VLAN is pruned from trunk links that do not require it. Step 1: Review the Arista MLS switch configuration by using the following commands to ensure the default VLAN 1 state is suspended: switch(config)#vlan 1 switch(config-vlan-1)#sh act vlan !! STIG suspend vlan 1 #state suspend vlan 1 switch(config-vlan-1)#exit Step 2: Review the configuration to ensure default VLAN 1 is pruned from any trunk active links by using the command "show vlan brief": switch(config-vlan-4090)# switch(config-vlan-4090)#sh vlan brie VLAN Name Status Ports ----- -------------------------------- --------- ------------------------------- 1 default 8 VLAN0008 active Cpu 25 VLAN0025 active Cpu 100 VLAN0100 active Cpu 1000 VLAN1000 active 4090 VLAN4090 active If the default VLAN state is not suspended and pruned from trunk links that should not be transporting frames for the VLAN, this is a finding.

Fix: F-59601r882287_fix

Best practice for VLAN-based networks is to configure Arista MLS switch to prune unnecessary trunk links from gaining access to the default VLAN and ensure frames belonging to the default VLAN do not traverse trunks not requiring frames from the VLAN. Step 1: Configure the Arista MLS switch to ensure VLAN1 is pruned from all trunk and access ports that do not require it by using the following commands: switch(config)#vlan 1 switch(config-vlan-1)#show active switch(config-vlan-1)#sh act vlan !! STIG suspend vlan 1 #state suspend vlan 1 switch(config-vlan-1)#exit Step 2: Configure the Arista MLS switch to allow VLAN trunking except default VLAN 1 and configure Ethernet port 1 to change the native VLAN to 1000. switch(config)#interface e10 switch(config-eth1o)#switchport trunk native vlan 1000 switch(config-eth1)#switchport trunk allowed vlan except 1 Step 3: Alternatively, the Arista MLS switch can use trunk groups to determine which trunks service which VLANs: switch(config)#vlan 1 switch(config-vlan-1)#trunk group DO_NOT_USE switch(config-vlan-1)#sh act vlan !! STIG suspend vlan 1 #state suspend vlan 1 trunk group DO_NOT_USE hss474.10:51:12(config-vlan-1)# Step 4: On Arista MLS switch, ensure any unnecessary trunk links have not gained access to default VLAN 1; this can be verified with the command "show vlan brief": switch(config)#sh vlan brief VLAN Name Status Ports ----- -------------------------------- --------- ------------------------------- 1 default 8 VLAN0008 active Cpu 25 VLAN0025 active Cpu 100 VLAN0100 active Cpu 1000 VLAN1000 active Eth1, Eth15, Eth16, Eth17 4090 VLAN4090 active Eth2, Eth20, Eth32

b
The Arista MLS layer 2 switch must not use the default VLAN for management traffic.
- Medium - CCI-004931 - V-255983 - SV-255983r991777_rule
RMF Control
Severity
Medium
CCI
CCI-004931
Version
ARST-L2-000200
Vuln IDs
  • V-255983
Rule IDs
  • SV-255983r991777_rule
Switches use the default VLAN (i.e., VLAN 1) for in-band management and to communicate with directly connected switches using Spanning-Tree Protocol (STP), Dynamic Trunking Protocol (DTP), VLAN Trunking Protocol (VTP), and Port Aggregation Protocol (PAgP)—all untagged traffic. As a consequence, the default VLAN may unwisely span the entire network if not appropriately pruned. If its scope is large enough, the risk of compromise can increase significantly.
Checks: C-59659r882289_chk

Verify the Arista MLS configuration for a Management_Network VRF instance globally on the switch with the following example: switch(config)#sh run | sec vrf ip name-server vrf default 192.168.10.20 ! vrf instance Management_Network ! interface Ethernet12 description MANAGEMENT NETWORK PORT no switchport vrf Management_Network ip address 10.10.40.254/30 ! ip routing vrf Management_Network If the VRF is not configured to prevent the default VLAN from being used to access the switch, this is a finding.

Fix: F-59602r882290_fix

Step 1: Configure the Arista MLS switch for a VRF instance for Management Network access by using the following commands: switch(config)#vrf instance Management_Network switch(config-vrf-Management_Network)#exit Step 2: Configure the Ethernet port for VRF Management_Network and IP address for the management network traffic: switch(config-if-Et12)#vrf Management_Network switch(config-if-Et12)#ip address 10.10.40.254/30 switch(config-if-Et12)#exit

b
The Arista MLS layer 2 switch must have all user-facing or untrusted ports configured as access switch ports.
- Medium - CCI-004891 - V-255984 - SV-255984r991778_rule
RMF Control
Severity
Medium
CCI
CCI-004891
Version
ARST-L2-000210
Vuln IDs
  • V-255984
Rule IDs
  • SV-255984r991778_rule
Double encapsulation can be initiated by an attacker who has access to a switch port belonging to the native VLAN of the trunk port. Knowing the victim's MAC address and with the victim attached to a different switch belonging to the same trunk group, thereby requiring the trunk link and frame tagging, the malicious user can begin the attack by sending frames with two sets of tags. The outer tag that will have the attacker's VLAN ID (probably the well-known and omnipresent default VLAN) is stripped off by the switch, and the inner tag that will have the victim's VLAN ID is used by the switch as the next hop and sent out the trunk port.
Checks: C-59660r882292_chk

Review the Arista MLS switch configurations and examine all user-facing or untrusted switch ports configured as access switch ports. switch(config)# show run interface ethernet 13 - 15 interface Ethernet13 switchport access vlan 100 interface Ethernet14 switchport access vlan 100 interface Ethernet14 switchport access vlan 100 If any of the user-facing switch ports are configured as a trunk, this is a finding.

Fix: F-59603r882293_fix

Configure the Arista MLS switch to disable trunking on all user-facing or untrusted switch ports. switch{config)#interface ethernet 13 - 15 switch(config-if-Et13-15)#description disable trunking untrusted ports switch(config-if-Et13-15)#switchport mode access switch(config-if-Et13-15)#exit

b
The Arista MLS layer 2 switch must have the native VLAN assigned to an ID other than the default VLAN for all 802.1q trunk links.
- Medium - CCI-004891 - V-255985 - SV-255985r991779_rule
RMF Control
Severity
Medium
CCI
CCI-004891
Version
ARST-L2-000220
Vuln IDs
  • V-255985
Rule IDs
  • SV-255985r991779_rule
VLAN hopping can be initiated by an attacker who has access to a switch port belonging to the same VLAN as the native VLAN of the trunk link connecting to another switch that the victim is connected to. If the attacker knows the victim’s MAC address, it can forge a frame with two 802.1q tags and a layer 2 header with the destination address of the victim. Since the frame will ingress the switch from a port belonging to its native VLAN, the trunk port connecting to the victim’s switch will simply remove the outer tag because native VLAN traffic is to be untagged. The switch will forward the frame on to the trunk link unaware of the inner tag with a VLAN ID of which the victim’s switch port is a member.
Checks: C-59661r882295_chk

Review the Arista MLS switch configuration for all trunk ports to have a unique native VLAN ID that is not the default VLAN 1 by using the following example: switch(config)#sh run | sec native vlan interface Ethernet4 description STIG Disable_VLAN 1 and native vlan to 1000 switchport trunk native vlan 1000 switchport trunk allowed vlan 2-4094 If the native VLAN has the same VLAN ID as the default VLAN, this is a finding.

Fix: F-59604r882296_fix

Configure the interface trunk ports for the unique Native VLAN ID and configure the VLAN allowed by using the following commands: switch(config)#interface Ethernet10 switch(config-eth10)#description #STIG VLAN 1 Pruning switch(config-eth10)# switchport trunk native vlan 1000 switch(config-eth10)#switchport trunk allowed vlan 2-4094

a
The Arista MLS layer 2 switch must not have any switch ports assigned to the native VLAN.
- Low - CCI-004891 - V-255986 - SV-255986r991780_rule
RMF Control
Severity
Low
CCI
CCI-004891
Version
ARST-L2-000230
Vuln IDs
  • V-255986
Rule IDs
  • SV-255986r991780_rule
Double encapsulation can be initiated by an attacker who has access to a switch port belonging to the native VLAN of the trunk port. Knowing the victim’s MAC address and with the victim attached to a different switch belonging to the same trunk group, thereby requiring the trunk link and frame tagging, the malicious user can begin the attack by sending frames with two sets of tags. The outer tag that will have the attacker’s VLAN ID (probably the well-known and omnipresent default VLAN) is stripped off by the switch, and the inner tag that will have the victim’s VLAN ID is used by the switch as the next hop and sent out the trunk port.
Checks: C-59662r882298_chk

Review the configuration for all trunking ports to determine the native VLAN by using the following example (for vlan 1000): switch(config-if-Et4)#sh run int eth4 interface Ethernet4 description STIG Disable_VLAN 1 and native vlan to 1000 switchport trunk native vlan 1000 switchport trunk allowed vlan 2-999,1001-4094 switch(config-if-Et4)# Review the configuration to ensure no access switch ports are configured in the native VLAN by using the following example (for vlan 1000): swtich#sh vlan brief VLAN Name Status Ports ----- -------------------------------- --------- ------------------------------- 1 default 8 VLAN0008 active Cpu 25 VLAN0025 active Cpu 100 VLAN0100 active Cpu 1000 VLAN1000 active 4090 VLAN4090 active If any access switch ports have been assigned to the same VLAN ID as the native VLAN, this is a finding.

Fix: F-59605r882299_fix

Configure the Arista MLS switch to ensure all access switch ports use a VLAN other than the native VLAN. Configure all access switch ports to a VLAN other than the designated native VLAN by using the following example: switch(config)#interface Ethernet 21 switch(config-Eth21)# switchport access vlan xxxx