Arista MLS DCS-7000 Series RTR Security Technical Implementation Guide

V1R2 2016-03-29       U_Arista_MLS_DCS-7000_Series_RTR_STIG_V1R2_Manual-xccdf.xml
V1R1 2015-07-06       U_Arista_MLS_DCS-7000_Series_RTR_STIG_V1R1_Manual-xccdf.xml
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 e-mail to the following address: [email protected]
Comparison
All 23
No Change 20
Updated 2
Added 0
Removed 1
V-60817 No Change
Findings ID: AMLS-L3-000100 Rule ID: SV-75273r1_rule Severity: medium CCI: CCI-001414

Discussion

Information flow control regulates authorized information to travel within a network and between interconnected networks. Controlling the flow of network traffic is critical so it does not introduce any unacceptable risk to the network infrastructure or data. An example of a flow control restriction is blocking outside traffic claiming to be from within the organization. For most routers, internal information flow control is a product of system design.

Checks

Verify each router enforces approved authorizations for controlling the flow of information between interconnected networks in accordance with applicable policy.

This requirement may be met through the use of IP access control lists. To verify IP access lists are configured, execute the "show ip access-lists summary" command, and check that the list is configured and is active on applicable interfaces. To verify the lists control the flow of information in accordance with organizational policy, enter the "show ip access-list [name]" command, and review the associated permit and deny statements.

If the router does not enforce approved authorizations for controlling the flow of information between interconnected networks in accordance with applicable policy, this is a finding.

Fix

Configure the router to enforce approved authorizations for controlling the flow of information between interconnected networks in accordance with applicable policy.

To use an IP access list to fulfill this function, enter the following commands, substituting organizational values for the bracketed variables.

ip access-list [name]
[permit/deny] [protocol] [source address] [source port] [destination address] [destination port]
exit

interface [type] [number]
ip access-group [name] [direction]
V-60889 No Change
Findings ID: AMLS-L3-000110 Rule ID: SV-75347r1_rule Severity: medium CCI: CCI-001414

Discussion

If multicast traffic is forwarded beyond the intended boundary, it is possible that it can be intercepted by unauthorized or unintended personnel. Limiting where, within the network, a given multicast group's data is permitted to flow is an important first step in improving multicast security.

A scope zone is an instance of a connected region of a given scope. Zones of the same scope cannot overlap, while zones of a smaller scope will fit completely within a zone of a larger scope. For example, Admin-local scope is smaller than Site-local scope, so the administratively configured boundary fits within the bounds of a site. According to RFC 4007 IPv6 Scoped Address Architecture (section 5), scope zones are also required to be "convex from a routing perspective"; that is, packets routed within a zone must not pass through any links that are outside of the zone. This requirement forces each zone to be one contiguous island rather than a series of separate islands.

As stated in the DoD IPv6 IA Guidance for MO3, "One should be able to identify all interfaces of a zone by drawing a closed loop on their network diagram, engulfing some routers and passing through some routers to include only some of their interfaces." Therefore, it is imperative that the network has documented their multicast topology and thereby knows which interfaces are enabled for multicast. Once this is done, the zones can be scoped as required.

Checks

If IPv4 or IPv6 multicast routing is enabled, verify all interfaces enabled for PIM are documented in the network's multicast topology diagram. Review the router configuration via the "show running-config" command to determine if multicast routing is enabled and which interfaces are enabled for PIM, identified via the "ip pim sparse-mode" statement in the interface configuration. Alternatively, from the interface configuration mode, enter "show active all" and verify that the statement "no ip pim sparse-mode" is present, if PIM is not required for the active interface.

If an interface is not required to support multicast routing and it is enabled, this is a finding.

Fix

Document all enabled interfaces for PIM in the network's multicast topology diagram. Disable support for PIM on interfaces that are not required to support it.

Interfaces have PIM disabled by default. To disable PIM from an interface active in a multi-cast network, enter "no pim sparse-mode" in the interface configuration mode.
V-60891 No Change
Findings ID: AMLS-L3-000120 Rule ID: SV-75349r1_rule Severity: medium CCI: CCI-001414

Discussion

Protocol Independent Multicast (PIM) is a routing protocol used to build multicast distribution trees for forwarding multicast traffic across the network infrastructure. Protocol Independent Multicast traffic must be limited to only known PIM neighbors by configuring and binding a PIM neighbor filter to those interfaces that have PIM enabled. If a PIM neighbor filter is not applied to those interfaces that have PIM enabled, unauthorized routers can join the PIM domain and discover and use the rendezvous points and also advertise their rendezvous points into the domain. This can result in a denial of service by traffic flooding or result in the unauthorized transfer of data.

Checks

Review the multicast topology diagram and determine if router interfaces are enabled for IPv4 or IPv6 multicast routing.

If the router is enabled for multicast routing, verify all interfaces enabled for PIM have a neighbor filter bound to the interface. The neighbor filter must only accept PIM control plane traffic from the documented PIM neighbors. To verify a neighbor filter is active, execute the "show running-config" command and find the "ip pim neighbor-filter [name]" statement in the interface configuration mode.

If PIM neighbor filters are not bound to all interfaces that have PIM enabled, this is a finding.

Fix

Configure neighbor filters to only accept PIM control plane traffic from documented PIM neighbors. Bind neighbor filters to all PIM-enabled interfaces.

To create a new neighbor filter, create an access list by entering:

ip access-list [name]
[ip access list permit/deny statement]
exit

Then apply the neighbor filter based on the access list to the PIM-enabled interface:

int ethernet 1
ip pim neighbor-filter [name-of-ACL]
V-60893 No Change
Findings ID: AMLS-L3-000130 Rule ID: SV-75351r1_rule Severity: medium CCI: CCI-001414

Discussion

If multicast traffic is forwarded beyond the intended boundary, it is possible that it can be intercepted by unauthorized or unintended personnel.

Administrative scoped multicast addresses are locally assigned and are to be used exclusively by the enterprise network or enclave. Administrative scoped multicast traffic must not cross the enclave perimeter in either direction. Restricting multicast traffic makes it more difficult for a malicious user to access sensitive traffic.

Admin-Local scope is encouraged for any multicast traffic within a network intended for network management, as well as for control plane traffic that must reach beyond link-local destinations.

Checks

Review the multicast topology diagram to determine if there are any documented Admin-Local (FFx4::/16), Site-Local (FFx5::/16), or Organization-Local (FFx8::/16) multicast boundaries for IPv6 traffic or any Local-Scope (239.255.0.0/16) boundaries for IPv4 traffic.

Verify the appropriate boundaries are configured on the applicable multicast-enabled interfaces via an "ip multicast boundary" statement in the interface configuration.

If the appropriate boundaries are not configured on applicable multicast-enabled interfaces, this is a finding.

Fix

Configure the appropriate boundaries to contain packets addressed within the administratively scoped zone. Defined multicast addresses are FFx4::/16, FFx5::/16, FFx8::/16, and 239.255.0.0/16.

To create a PIM Boundary, create an access list by entering:

ip access-list [name]
[ip access list permit/deny statement]
exit

Then apply the boundary filter based on the access list to the PIM-enabled interface:

int ethernet [X]
ip multicast boundary [name-of-ACL]
V-60895 No Change
Findings ID: AMLS-L3-000140 Rule ID: SV-75353r1_rule Severity: medium CCI: CCI-001414

Discussion

An inactive interface is rarely monitored or controlled and may expose a network to an undetected attack on that interface. Unauthorized personnel with access to the communication facility could gain access to a router by connecting to a configured interface that is not in use.

Checks

Verify inactive interfaces on the router are disabled by executing a "show interface status" command and confirming the line "disabled" is present on any interface where the interface is inactive.

If there are any inactive interfaces enabled on the router, this is a finding.

Fix

Remove subinterfaces and disable any inactive ports on the router via the "shutdown" command on the interface configuration mode.
V-60897 No Change
Findings ID: AMLS-L3-000150 Rule ID: SV-75355r1_rule Severity: medium CCI: CCI-001414

Discussion

Enclaves with Alternate Gateway connections must take additional steps to ensure there is no compromise on the enclave network or NIPRNet. Without verifying the destination address of traffic coming from the site's Alternate Gateway, the perimeter router could be routing transit data from the Internet into the NIPRNet. This could also make the perimeter router vulnerable to a DoS attack as well as provide a backdoor into the NIPRNet. The DoD enclave must ensure the ingress filter applied to external interfaces on a perimeter router connecting to an Approved Gateway is secure through filters permitting packets with a destination address belonging to the DoD enclave's address block.

Checks

Review the configuration of each router interface connecting to an Alternate Gateway via the "show running-config" command.

Verify each permit statement of the ingress filter only permits packets with destination addresses of the site's NIPRNet address space or a destination address belonging to the address block assigned by the Alternate Gateway network service provider.

If the ingress filter permits packets with addresses other than those specified, such as destination addresses of the site's NIPRNet address space or a destination address belonging to the address block assigned by the Alternate Gateway network service provider, this is a finding.

Fix

Configure the ingress filter of the perimeter router connected to an Alternate Gateway to only permit packets with destination addresses of the site's NIPRNet address space or a destination address belonging to the address block assigned by the Alternate Gateway network service provider. To configure an example of such a statement, enter:

ip access-list [name]
permit ip [source] [destination]
exit
interface [router interface]
ip access-group [name] in
exit
V-60899 No Change
Findings ID: AMLS-L3-000160 Rule ID: SV-75357r1_rule Severity: medium CCI: CCI-001414

Discussion

The perimeter router will not use a routing protocol to advertise NIPRNet addresses to Alternate Gateways. Most ISPs use Border Gateway Protocol (BGP) to share route information with other autonomous systems, that is, any network under a different administrative control and policy than a local site. If BGP is configured on the perimeter router, no BGP neighbors will be defined to peer routers from an AS belonging to any Alternate Gateway. The only allowable method is a static route to reach the Alternate Gateway.

Checks

This requirement applies only to DoDIN enclaves. Review the configuration of the router connecting to the Alternate Gateway via the "show router bgp [processID]" command.

Verify there are no BGP neighbors configured to the remote AS that belongs to the Alternate Gateway service provider.

If there are BGP neighbors connecting the remote AS of the Alternate Gateway service provider, this is a finding.

Fix

Configure a static route on the perimeter router to reach the AS of a router connecting to an Alternate Gateway

Ip route [destination/mask] [forwarding interface]
V-60903 No Change
Findings ID: AMLS-L3-000170 Rule ID: SV-75361r1_rule Severity: medium CCI: CCI-001414

Discussion

If the static routes to the alternate gateway are being redistributed into an Exterior Gateway Protocol or Interior Gateway Protocol to a NIPRNet gateway, this could make traffic on NIPRNet flow to that particular router and not to the Internet Access Point routers. This could not only wreak havoc with traffic flows on NIPRNet, but it could overwhelm the connection from the router to the NIPRNet gateway(s) and also cause traffic destined for outside of NIPRNet to bypass the defenses of the Internet Access Points.

Checks

This requirement applies only to DoDIN enclaves. Review the configuration of the route connecting to the Alternate Gateway.

Verify redistribution of static routes to the Alternate Gateway is not occurring by reviewing the running configuration via the "show running-config" command. In the appropriate routing protocol configuration, there must not be a "redistribute static" statement. If there is a redistribute static statement, there must be an accompanying route map to prevent redistribution of routes to the alternate gateway.

If the static routes to the Alternate Gateway are being redistributed into an Exterior Gateway Protocol or Interior Gateway Protocol to a NIPRNet gateway, this is a finding.

Fix

Configure the router so that static routes are not redistributed to an Alternate Gateway into either an Exterior Gateway Protocol or Interior Gateway Protocol to the NIPRNet or to other Autonomous System. Enter "no redistribute static" into the routing process configuration to fulfill this requirement.

To configure a Route Map to allow for redistribution of some static routes, refer to Chapter 18.3 of the Arista Configuration Manual.
V-60905 No Change
Findings ID: AMLS-L3-000180 Rule ID: SV-75363r1_rule Severity: medium CCI: CCI-001414

Discussion

If the gateway router is not a dedicated device for the out-of-band management network, implementation of several safeguards for containment of management and production traffic boundaries must occur. Since the managed and management network are separate routing domains, configuration of separate Interior Gateway Protocol routing instances is critical on the router to segregate traffic from each network.

Checks

Verify that the out-of-band management interface is an adjacency in the Interior Gateway Protocol routing domain for the management network. This requirement does not apply to in-band management networks.

The out-of-band management interface will not form an adjacency with the IGP running on the switch. If the Arista MLS is acting as the gateway for the management network, and management traffic is ingressing the switch via in-band dataplane interfaces, these interfaces may be in a dedicated VRF for the management network. To verify this VRF, run a "show vrf" and confirm the interfaces handling management traffic are displayed in the resulting output. Alternatively, if VRFs are not used, the management network must use a separate routing domain that is not advertised or redistributed to the managed network. This can be verified by checking the relevant configuration statements for the routing protocol instances and ensuring no redistribute statement exists that will bridge the managed and management networks.

Using the "show ip route" command will also verify this requirement by displaying the routing tables. Stipulating the VRF via the "show ip route vrf [name]" will display a separate routing table for a configured VRF, distinct from the default routing table in the default VRF, provided by the "show ip route" command with an unspecified VRF.

If the router does not enforce that Interior Gateway Protocol instances configured on the out-of-band management gateway router only peer with their own routing domain, this is a finding.

Fix

Configure the router to enforce that Interior Gateway Protocol instances configured on the out-of-band management gateway router only peer with their own routing domain.

To configure a management vrf, enter the following from the configuration mode:
vrf definition [name]
rd [AS#]:[local assignment]

Then, from the interface configuration mode, assign the interface to the VRF:
interface [type][number]
vrf forwarding [vrf name]

Then enable IP routing for the VRF:
ip routing vrf [name]

Then, from the IGP configuration mode interface, configure the routing protocols.
router [protocol] [processID]
vrf [name]
[configuration statement]

To remove offending redistribute statements, enter the command:
no redistribute [connected/ospf/bgp/etc]
V-60907 No Change
Findings ID: AMLS-L3-000190 Rule ID: SV-75365r1_rule Severity: medium CCI: CCI-001414

Discussion

If the gateway router is not a dedicated device for the out-of-band management network, several safeguards must be implemented for containment of management and production traffic boundaries; otherwise, it is possible that management traffic will not be separated from production traffic.

Since the managed network and the management network are separate routing domains, separate Interior Gateway Protocol routing instances must be configured on the router, one for the managed network and one for the out-of-band management network. In addition, the routes from the two domains must not be redistributed to each other.

Checks

Verify the Interior Gateway Protocol instance used for the managed network does not redistribute routes into the Interior Gateway Protocol instance used for the management network, and vice versa.

This can be verified via the "show run section [routing protocol]" command. The output of this command will display the active configuration for the routing protocol on the switch. Verify the routing protocol configuration does not contain a statement redistributing or advertising routes from the managed domain into the management domain, or vice versa.

Using the "show ip route" command will also verify this requirement by displaying the routing tables. Stipulating the VRF via the "show ip route vrf [name]" will display a separate routing table for a configured VRF, distinct from the default routing table in the default VRF, provided by the "show ip route" command with an unspecified VRF.

If the Interior Gateway Protocol instance used for the managed network redistributes routes into the Interior Gateway Protocol instance used for the management network, or vice versa, this is a finding.

Fix

Configure the Interior Gateway Protocol instance used for the managed network to prohibit redistribution of routes into the Interior Gateway Protocol instance used for the management network, and vice versa.

This can be configured via the VRF configuration provided in SRG-NET-000019-RTR-000012.
V-60909 No Change
Findings ID: AMLS-L3-000200 Rule ID: SV-75367r1_rule Severity: medium CCI: CCI-001414

Discussion

The out-of-band management access switch will connect to the management interface of the managed network elements. The management interface can be a true out-of-band management interface or a standard interface functioning as the management interface. In either case, the management interface of the managed network element will directly connect to the out-of-band management network.

An out-of-band management interface does not forward transit traffic, thereby providing complete separation of production and management traffic. Since all management traffic is immediately forwarded into the management network, it is not exposed to possible tampering. The separation also ensures that congestion or failures in the managed network do not affect the management of the device. If the device does not have an out-of-band management port, the interface functioning as the management interface must be configured so that management traffic, both data plane and control plane, does not leak into the managed network and that production traffic does not leak into the management network.

Checks

Review the configuration to verify the management interface is configured as passive for the Interior Gateway Protocol instance for the managed network.

The configuration of the routing protocol viewable via the "show running-config" command must include the following statement:

passive-interface [management] [#]

or

passive-interface [default]

Note that not all protocols support the concept of a passive interface, such as the use of BGP for an IGP. As the function of these protocols is different, if this statement is missing from a protocol that does not support this function, this is not a finding.

If the management interface is not configured as passive for the Interior Gateway Protocol instance for the managed network, this is a finding.

Fix

Configure the management interface as passive for the Interior Gateway Protocol instance configured for the managed network.

From the router configuration interface:

passive-interface management [#]
V-60911 No Change
Findings ID: AMLS-L3-000210 Rule ID: SV-75369r1_rule Severity: medium CCI: CCI-000366

Discussion

Information flow control regulates where information is allowed to travel within a network and between interconnected networks. The flow of all network traffic must be monitored and controlled so it does not introduce any unacceptable risk to the network infrastructure or data. Restrictions can be enforced based on source and destination IP addresses as well as the ports and services being requested. This requirement should enforce the deny-by-default policy whereby only the known and accepted traffic will be allowed outbound and inbound.

Checks

If explicit security attributes (for example, IP addresses, port numbers, protocol, Autonomous System, or interface) are not used to enforce information flow control, this is a finding.

Review the configuration of any access control list on the switch to determine if explicit attributes are being utilized. The ACL must include explicit attributes such as ip addresses, port numbers, protocols, etc.

Note that the Arista MLS includes a deny-by-default statement that is not displayed in the CLI. This statement exists at the end of every ACL.

Fix

Configure the router to enforce flow control using explicit security attributes (for example, IP addresses, port numbers, protocol, Autonomous System, or interface) on information, source, and destination objects as a basis for flow control decisions.

To enforce flow control using explicit security attributes, configure access control lists as per organization-defined requirements, to include statements such as:

ip access-list [Name}
deny [protocol] [source address] [source port] [destination address] [destination port] [dscp filter] [ttl filter]
V-60913 Updated
Findings ID: AMLS-L3-000220 Rule ID: SV-75371r12_rule Severity: medium CCI: CCI-000366

Discussion

A rogue router could send a fictitious routing update to convince a site's perimeter router to send traffic to an incorrect or even a rogue destination. This diverted traffic could be analyzed to learn confidential information about the site's network or merely used to disrupt the network's ability to communicate with other networks. This is known as a "traffic attraction attack" and is prevented by configuring neighbor router authentication for routing updates.

This requirement applies to all IPv4 and IPv6 protocols that are used to exchange routing or packet forwarding information; this includes all Interior Gateway Protocols (such as OSPF, EIGRP, and IS-IS) and Exterior Gateway Protocols (such as BGP), MPLS-related protocols (such as LDP), and Multicast-related protocols.

Checks

Review the router configuration; for every protocol that affects the routing or forwarding tables (where information is exchanged between neighbors), verify that neighbor router authentication is enabled.

For BGP, this can be verified via the "show running-config" command and validating that any configured neighbor has an associated password statement. For OSPF, under the interface configuration mode, verify the following statements are configured:

ip ospf authentication message-digest
ip ospf
authentication-key [type] [key]message-digest-key [number] md5 [type] [key]

For IS-IS, under the interface configuration mode, verify the following statements are configured:

isis authentication mode md5 [level-1|level-2]
isis authentication key [key-string] [level-1|level-2]

Alternatively, under “show isis interface” the authentication mode on the interface must show as being set to MD5.

Additionally, the global IS-IS router configuration must be set. From the output of “show isis summarye vyrify that the authentication mode for Level-1 and/or Level-2 as applicable, is set to


If authentication is not enable
dabled for BGP, OSPFd and I, this is a finding.

Fix

Configure authentication to be enabled for every protocol that affects the routing or forwarding tables.

To configure BGP authentication, in the BGP configuration mode interface, when adding neighbors, include the following statement:

neighbor [ip address] password [type] [password]

For OSPF, under the interface configuration mode, enter the following commands:

ip ospf authentication message-digest
ip ospf authentication-key [type] [key]


To Globally Configure IS-IS Authentication, use:
router isis [instance number] authentication mode md5 [level 1 | level 2] authentication key [0|7] [key string] [level 1 | level 2]

Where level 1 and level 2 variable specify the authentication to be used for each type or ISIS router, the ISIS instance number is the routing protocol instance, the variables 0 and 7 represent an encrypted or unencrypted key string, and the key string is the text for the encryption string. Global configuration authenticates ISIS LSPs, CSNPs and PSNPs.

Interface configuration authenticates ISIS Hello PDUs, and is configured as such:

interface [ethernet | port-channel | vlan] [X]
isis authentication mode md5
isis authentication key [0|7] [text]
V-60915 No Change
Findings ID: AMLS-L3-000230 Rule ID: SV-75373r1_rule Severity: medium CCI: CCI-001094

Discussion

A compromised host in an enclave can be used by a malicious actor as a platform to launch cyber attacks on third parties. This is a common practice in "botnets", which are collections of compromised computers using malware to attack (usually DDoS) other computers or networks. DDoS attacks frequently leverage IP source address spoofing, in which packets with false source IP addresses send traffic to multiple hosts, which then send return traffic to the hosts with the IP addresses that were forged. This can generate significant, even massive, amounts of traffic. Therefore, protection measures to counteract IP source address spoofing must be taken.

The router must not accept any outbound IP packets that contain an illegitimate address in the source address field by enabling Unicast Reverse Path Forwarding (uRPF) strict mode or by implementing an egress ACL. Unicast Reverse Path Forwarding (uRPF) provides an IP address spoof protection capability. When uRPF is enabled in strict mode, the packet must be received on the interface that the device would use to forward the return packet.

Checks

This check is only applicable to external-facing interfaces of a network edge router.

Review the router configuration to verify uRPF or an egress filter to restrict the router from accepting outbound IP packets that contain an illegitimate address in the source address field has been configured on all external interfaces. This is only applicable to perimeter routers.

If uRPF or an egress filter to restrict the router from accepting outbound IP packets that contain an illegitimate address in the source address field has not been configured on all internal interfaces in an enclave, this is a finding.

To verify that uRPF is configured, review the running-config for the interfaces required. The statement "ip-verify unicast source reachable" must be in the configuration. To verify use of an egress filter, verify an IP access list is configured that permits traffic sourced from within the organization address space and that the access list is applied to the egress interface.

Fix

This check is only applicable to external-facing interfaces of a network edge router.

Configure the router to ensure that an egress filter or uRPF is configured to restrict the router from accepting any outbound IP packet that contains an external IP address in the source field.

Configure uRPF via the "ip-verify unicast source reachable-via [any/strict]" statement from the interface configuration mode.

To apply an egress filter, configure an IP access List:
ip access-list [name]
[ip access list permit/deny statement]
exit

then apply the access list to the external facing interface:

int ethernet [X]
ip access-group [name-of-ACL] out
V-60917 No Change
Findings ID: AMLS-L3-000240 Rule ID: SV-75375r1_rule Severity: medium CCI: CCI-000381

Discussion

A compromised router introduces risk to the entire network infrastructure as well as data resources that are accessible via the network. The perimeter defense has no oversight or control of attacks by malicious users within the network. Preventing network breaches from within is dependent on implementing a comprehensive defense-in-depth strategy, including securing each device connected to the network. This is accomplished by following and implementing all security guidance applicable for each node type. A fundamental step in securing each router is to enable only the capabilities required for operation.

Checks

Review the router configuration to determine if services or functions not required for operation, or not related to router functionality (e.g., DNS, email client or server, FTP server, or web server) are enabled.

If unnecessary services and functions are enabled on the router, this is a finding.

Fix

Remove unneeded services and functions from the router. Removal is recommended since the service or function may be inadvertently enabled otherwise. However, if removal is not possible, disable the service or function.
V-60919 Updated
Findings ID: AMLS-L3-000250 Rule ID: SV-75377r12_rule Severity: medium CCI: CCI-000803

Discussion

A rogue router could send a fictitious routing update to convince a site's perimeter router to send traffic to an incorrect or even a rogue destination. This diverted traffic could be analyzed to learn confidential information about the site's network, or merely used to disrupt the network's ability to communicate with other networks. This is known as a "traffic attraction attack" and is prevented by configuring neighbor router authentication for routing updates. However, using clear-text authentication provides little benefit since an attacker can intercept traffic and view the authentication key. This would allow the attacker to use the authentication key in an attack.

This requirement applies to all IPv4 and IPv6 protocols that are used to exchange routing or packet forwarding information; this includes all Interior Gateway Protocols (such as OSPF, EIGRP, and IS-IS) and Exterior Gateway Protocols (such as BGP), MPLS-related protocols (such as LDP), and Multicast-related protocols.

Checks

Review the router configuration for the following configuration statement under the interface configuration for any interface participating in the OSPF topology:. SHA1 must be used instead of MD5 in all cases when that option is available.

ip ospf authentication message-digest
ip ospf message-digest-key [number] md5 [type] [key]

For IPv6 Authentication,
one of the following statements must be present under the ipv6 router ospfOSPF configuration statement, or on any interface running OSPFv3:
area [area number] authentication ipsec spi [spi number] [md5/sha1] [passphrase/key] [0/7] [passphrase/
, depending on the type of encryption established. There are two methods of authentication for OSPFv3 in this scenario; the first uses authentication header (AH), and the second uses Authentication Header with Encapsulating Security Payload. OSPFv3 authentication can be configured for an interface or an area, and interface configuration will override area configuration. Users may configure a key or a passphrase.

interface ethernet1
ipv6 ospf authentication ipsec spi [spi number] [md5/sha1] [passphrase/key] [0/7] [passphrase/key]

OR

interface ethernet1
ipv6 ospf encryption ipsec spi [spi number] esp null [md5/sha1] [passphrase/key] [0/7] [passphrase/key]

In an area configuration, the following text must be included under the "ipv6 router ospf [process ID]" configuration section.

ipv6 router ospf 200
area [area number] authentication ipsec spi [spi number] [md5/sha1] [passphrase/key] [0/7] [passphrase/key]

OR for ESP

ipv6 router ospf 200
area 0 encryption ipsec spi [spi] esp null [md5/sha1] [0/7] [key] |
passphrase [0/7] [
key]

If either of these statements
areis not present, OSPF is not using encryption for authentication, and this is a finding.

Fix

Configure routing protocol authentication to encrypt the authentication key via the following commands under the interface configuration mode:. SHA1 must be used instead of MD5 in all cases when that option is available.

ip ospf authentication message-digest
ip ospf message-digest-key [number] md5 [type] [key]

For IPv6 global configuration, enter:
ipv6 router ospf
{[process number}]
area [area number] authentication ipsec spi [spi number] [md5/sha1] [passphrase/key] [0/7] [passphrase/key]

Alternatively, under the interface configuration mode, enter:
ipv6 ospf a
rea [area number] authenticauthentication ipsec spi [spi number] [md5/sha1] [passphrase/key] [0/7] [passphrase/key]

To use ESP encryption on AH headers, instead enter:
ipv6 router ospf [process number]
area [area number] encryption ipsec spi [spi number] esp null [md5/sha1] [passphrase/key] [0/7] [passphrase/key]

or on an interface:
ipv6 ospf encryp
tion ipsec spi [spi number] esp null [md5/sha1] [passphrase/key] [0/7] [passphrase/key]
V-60921 No Change
Findings ID: AMLS-L3-000260 Rule ID: SV-75379r1_rule Severity: medium CCI: CCI-002385

Discussion

As described in RFC 3682, Generalized TTL Security Mechanism (GTSM) is designed to protect a router's IP-based control plane from DoS attacks. Many attacks focused on CPU load and line-card overload can be prevented by implementing GTSM on all Exterior Border Gateway Protocol-speaking routers. GTSM is based on the fact that the vast majority of control plane peering is established between adjacent routers; that is, the Exterior Border Gateway Protocol peers are either between connecting interfaces or between loopback interfaces. Since TTL spoofing is considered nearly impossible, a mechanism based on an expected TTL value provides a simple and reasonably robust defense from infrastructure attacks based on forged control plane traffic.

Checks

Review the router configuration.

If it is not configured to use Generalized TTL Security Mechanism (GTSM) or is not configured to provide equivalent functionality as per RFC3682 for all Exterior Border Gateway Protocol peering sessions, this is a finding.

The Arista MLS does not have a command to enable GTSM. Instead, any EBGP neighbor statement must include the "ebgp-multihop [hop]" configuration statement, viewable in the "router bgp [AS number]" section of the running config. For adjacent peers, this number must be 255.

Additionally, the control-plane ACL must have a statement that matches against the neighbor's correct TTL to allow inbound packets to the Switch. The neighbor TTL must be 255 for an adjacent peer or the result of 255-(number of hops) for a multihop peer.

Fix

Configure all Exterior Border Gateway Protocol peering sessions to use Generalized TTL Security Mechanism (GTSM) or an equivalent configuration as per RFC3682.

For adjacent EBGP neighbors, under the router configuration section, enter:

config
router bgp [AS number]
neighbor [address] ebgp-multihop 255
exit
ip access-list [name]
permit tcp [src address/mask] [dst address/mask] eq bgp ttl eq 255 log
exit
control-plane
ip access-group [name] [direction]
V-60923 No Change
Findings ID: AMLS-L3-000270 Rule ID: SV-75381r1_rule Severity: medium CCI: CCI-001095

Discussion

Denial of service is a condition when a resource is not available for legitimate users. Packet flooding 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).

Checks

Review the router configuration and interview the system administrator; verify that a mechanism for traffic prioritization and bandwidth reservation exists. This arrangement must ensure that sufficient capacity is available for mission-critical traffic and enforce the traffic priorities specified by the Combatant Commanders/Services/Agencies.

To review the configuration, execute a "show qos interfaces" command to see the qos configuration for all interfaces or "show qos interfaces [type] [number] to review the configuration for a specific interface.

QoS must be configured according to organizational policies.

If no such scheme exists or it is not configured, this is a finding.

Fix

Implement a mechanism for traffic prioritization and bandwidth reservation. This mechanism must enforce the traffic priorities specified by the Combatant Commanders/Services/Agencies.

Arista QoS implementations vary according to the underlying hardware platform. For a complete reference on how to configure QoS for the platform under evaluation, refer to the Arista configuration manual, Chapter 21.
V-60925 No Change
Findings ID: AMLS-L3-000280 Rule ID: SV-75383r1_rule Severity: medium CCI: CCI-002403

Discussion

Advertisement of routes by an Autonomous System for networks that do not belong to any of its trusted peers pulls traffic away from the authorized network. This causes a DoS on the network that allocated the block of addresses and may cause a DoS on the network that is inadvertently advertising it as the originator. It is also possible that a misconfigured or compromised router within the network could redistribute Interior Gateway Protocol routes into Border Gateway Protocol, thereby leaking internal routes.

Checks

Review the router configuration to verify that Border Gateway Protocol connections are only from known neighbors in a trusted AS. Check the BGP configuration statements viewable via the "show running-config" command to validate that no dynamic BGP listen ranges are configured for EBGP peerings to external networks. This requirement to eliminate dynamic listen ranges does not apply to internal networks.

If the router is configured with dynamic listen ranges for EBGP peers to external networks, this is a finding.

Fix

Remove any configuration statements for dynamic listen ranges to external EBGP peers. If connections must exist, use explicit neighbor statements for the peering router.
V-60927 No Change
Findings ID: AMLS-L3-000290 Rule ID: SV-75385r1_rule Severity: medium CCI: CCI-001097

Discussion

The Neighbor Discovery protocol allows a hop limit value to be advertised by routers in a Router Advertisement message to be used by hosts instead of the standardized default value. If a very small value was configured and advertised to hosts on the LAN segment, communications would fail due to the hop limit reaching zero before the packets sent by a host reached their destination.

Checks

Review the router configuration to determine if the maximum hop limit has been configured.

If it has been configured, then it must be set to at least 32.

If it has not been configured, the default value must be determined. The default value for the Arista MLS is 64.

Review the interface configuration via the "show running-config" command for the statement

ipv6 nd ra hop-limit 32

If the default value is below 32 and the maximum hop limit value has not been configured (set to at least 32), this is a finding.

In any case, maximum hop limit must be at least 32.

Fix

Configure the router maximum hop limit value to at least 32.

From the interface configuration mode, enter:

ipv6 nd ra hop-limit 32
V-60929 No Change
Findings ID: AMLS-L3-000300 Rule ID: SV-75387r1_rule Severity: medium CCI: CCI-002403

Discussion

Unrestricted traffic may contain malicious traffic that poses a threat to an enclave or to other connected networks. Additionally, unrestricted traffic may transit a network, which uses bandwidth and other resources.

Traffic can be restricted directly by an ACL (which is a firewall function) or by Policy Routing. Policy Routing is a technique used to make routing decisions based on a number of different criteria other than just the destination network, including source or destination network, source or destination address, source or destination port, protocol, packet size, and packet classification. This overrides the router's normal routing procedures used to control the specific paths of network traffic. It is normally used for traffic engineering but can also be used to meet security requirements; for example, traffic that is not allowed can be routed to the Null0 or discard interface. Policy Routing can also be used to control which prefixes appear in the routing table.

Traffic can be restricted directly by an ACL (which is a firewall function), or by Policy Routing. This requirement is intended to allow network administrators the flexibility to use whatever technique is most effective.

Checks

Review the router configuration to determine if the router only allows incoming communications from authorized sources to be routed to authorized destinations.

To verify an ACL is configured to allow only incoming communications from authorized sources, execute a "show ip access-list" command and verify the pertinent permit and deny statements are in place. Validate the access list is configured on the appropriate interface via the "show ip access-list summary" command or by reviewing the interface configuration viewable in the "show running-config" command.

If PBR is being used, verify the appropriate policy maps have been configured by reviewing the switch running-config via the "show running-config" command.

If the router does not restrict incoming communications to allow only authorized sources and destinations, this is a finding.

Fix

Configure the router to only allow incoming communications from authorized sources to be routed to authorized destinations.

Implement access control lists or policy-based routing as defined in the Arista Configuration Manual, chapters 18 and 22 respectively.
V-60933 No Change
Findings ID: AMLS-L3-000320 Rule ID: SV-75391r1_rule Severity: medium CCI: CCI-000803

Discussion

A rogue router could send a fictitious routing update to convince a site's perimeter router to send traffic to an incorrect or even a rogue destination. This diverted traffic could be analyzed to learn confidential information about the site's network or merely used to disrupt the network's ability to communicate with other networks. This is known as a "traffic attraction attack" and is prevented by configuring neighbor router authentication for routing updates. However, using clear-text authentication provides little benefit since an attacker can intercept traffic and view the authentication key. This would allow the attacker to use the authentication key in an attack.

This requirement applies to all IPv4 and IPv6 protocols that are used to exchange routing or packet forwarding information; this includes all Interior Gateway Protocols (such as OSPF, EIGRP, and IS-IS) and Exterior Gateway Protocols (such as BGP), MPLS-related protocols (such as LDP), and Multicast-related protocols.

Checks

Review the router configuration to determine if RIP is enabled via the "show running-config" command. RIP is disabled by default on an Arista switch and is only enabled when explicitly configured. If a configuration statement enabling RIP is in the Arista Multilayer Switch configuration, this is a finding.

Fix

Disable RIP via the "no router rip" command.
V-60931 Removed
Findings ID: AMLS-L3-000310 Rule ID: SV-75389r1_rule Severity: medium CCI: CCI-000803

Discussion

A rogue router could send a fictitious routing update to convince a site's perimeter router to send traffic to an incorrect or even a rogue destination. This diverted traffic could be analyzed to learn confidential information about the site's network or merely used to disrupt the network's ability to communicate with other networks. This is known as a "traffic attraction attack" and is prevented by configuring neighbor router authentication for routing updates. However, using clear-text authentication provides little benefit since an attacker can intercept traffic and view the authentication key. This would allow the attacker to use the authentication key in an attack. This requirement applies to all IPv4 and IPv6 protocols that are used to exchange routing or packet forwarding information; this includes all Interior Gateway Protocols (such as OSPF, EIGRP, and IS-IS) and Exterior Gateway Protocols (such as BGP), MPLS-related protocols (such as LDP), and Multicast-related protocols.

Checks

Review the router configuration to determine if IS-IS is enabled via the "show running-config" command. IS-IS is disabled by default on an Arista switch and is only enabled when explicitly configured. If a configuration statement enabling IS-IS is in the Arista Multilayer Switch configuration, this is a finding.

Fix

Disable IS-IS via the "no router isis [name]" command, substituting the IS-IS instance name for the bracketed variable.