{"stig":{"title":"Juniper Router RTR Security Technical Implementation Guide","version":"3","release":"2"},"checks":[{"vulnId":"V-217011","ruleId":"SV-217011r604135_rule","severity":"medium","ruleTitle":"The Juniper router must be configured to enforce approved authorizations for controlling the flow of information within the network based on organization-defined information flow control policies.","description":"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. Information flow control policies and enforcement mechanisms are commonly employed by organizations to control the flow of information between designated sources and destinations (e.g., networks, individuals, and devices) within information systems.\n\nEnforcement occurs, for example, in boundary protection devices (e.g., gateways, routers, guards, encrypted tunnels, and firewalls) that employ rule sets or establish configuration settings that restrict information system services, provide a packet filtering capability based on header information, or provide a message filtering capability based on message content (e.g., implementing key word searches or using document characteristics).","checkContent":"This requirement is not applicable for the DoDIN Backbone.\n\nReview the router configuration to verify that firewall filters are configured to allow or deny traffic for specific source and destination addresses as well as ports and protocols. For example, the configuration below will allow only printer traffic into subnet 11.1.23.0/24 and SQL traffic into subnet 11.1.24.0/24. ICMP is allowed for troubleshooting and OSPF is the routing protocol used within the network.\n\ninterfaces {\n ge-0/0/0 {\n unit 0 {\n family inet {\n filter {\n input FILTER_SERVER_TRAFFIC;\n }\n address 11.1.12.2/24;\n }\n }\n }\n…\n…\n…\nfirewall {\n family inet {\n filter FILTER_SERVER_TRAFFIC {\n term PRINT_FILTER {\n from {\n destination-address {\n 11.1.23.0/24;\n }\n protocol tcp;\n destination-port [ 515 631 9100 ];\n }\n then accept;\n }\n term SQL_FILTER {\n from {\n destination-address {\n 11.1.24.0/24;\n }\n protocol tcp;\n destination-port [ 1433 1434 4022 ];\n }\n then accept;\n }\n term ALLOW_OSPF {\n from {\n protocol ospf;\n }\n then accept;\n }\n term ALLOW_ICMP {\n from {\n protocol icmp;\n }\n then accept;\n }\n term DENY_ALL_OTHER {\n then {\n log;\n syslog;\n reject;\n }\n }\n }\n\n\n\nIf the router is not configured to enforce approved authorizations for controlling the flow of information within the network based on organization-defined information flow control policies, this is a finding.","fixText":"This requirement is not applicable for the DoDIN Backbone.\n\nConfigure firewall filters to allow or deny traffic for specific source and destination addresses as well as ports and protocols between various subnets as required. The commands used below were used to create the configuration as shown in the check content.\n\n[edit firewall family inet]\nset filter FILTER_SERVER_TRAFFIC term PRINT_FILTER from destination-address 11.1.23.0/24\nset filter FILTER_SERVER_TRAFFIC term PRINT_FILTER from protocol tcp destination-port [515 631 9100] \nset filter FILTER_SERVER_TRAFFIC term PRINT_FILTER then accept\nset filter FILTER_SERVER_TRAFFIC term SQL_FILTER from destination-address 11.1.24.0/24\nset filter FILTER_SERVER_TRAFFIC term SQL_FILTER from protocol tcp destination-port [1433 1434 4022]\nset filter FILTER_SERVER_TRAFFIC term SQL_FILTER then accept\nset filter FILTER_SERVER_TRAFFIC term ALLOW_OSPF from protocol ospf\nset filter FILTER_SERVER_TRAFFIC term ALLOW_OSPF then accept\nset filter FILTER_SERVER_TRAFFIC term ALLOW_ICMP from protocol icmp\nset filter FILTER_SERVER_TRAFFIC term ALLOW_ICMP then accept\nset filter FILTER_SERVER_TRAFFIC term DENY_ALL_OTHER then log reject\n\n[edit interfaces ge-0/0/0 unit 0 family inet]\nset filter input FILTER_SERVER_TRAFFIC","ccis":["CCI-001368"]},{"vulnId":"V-217012","ruleId":"SV-217012r945861_rule","severity":"medium","ruleTitle":"The Juniper router must be configured to implement message authentication for all control plane protocols.","description":"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 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.\n\nThis 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.","checkContent":"Review the router configuration. Verify that neighbor router authentication is enabled for all routing protocols as shown in the example configuration below.\n\nprotocols {\n bgp {\n group AS_5 {\n type external;\n peer-as 5;\n neighbor x.x.x.x {\n authentication-key \"$8$tBga0ORx7VsYoIEgJ\"; ## SECRET-DATA\n }\n }\n }\n ospf {\n area 0.0.0.0 {\n interface ge-0/0/0.0 {\n authentication {\n simple-password \"$8$NHVb2mPQ3nCYg/t\"; ## SECRET-DATA\n }\n }\n interface ge-0/1/0.0 {\n authentication {\n simple-password \"$8$Lgb7NbHkPTQnVwF/\"; ## SECRET-DATA\n }\n }\n interface lo0.0;\n interface ge-0/2/0.0 {\n authentication {\n simple-password \"$8$7DdVY.mTF39s26A\"; ## SECRET-DATA\n }\n }\n }\n }\n isis {\n level 1 {\n authentication-key \"$8$n2OT9CuvMXN-wp0VY\"; ## SECRET-DATA\n authentication-type md5;\n }\n level 2 {\n authentication-key \"$8$8G9x7ViHm5T3dbz6\"; ## SECRET-DATA\n authentication-type md5;\n }\n interface ge-0/0/0.0;\n interface ge-0/0/1.0;\n }\n ldp {\n interface ge-0/0/0.0;\n interface ge-0/0/1.0;\n session 10.3.3.3 {\n authentication-key \"$8$3hus/u1ylMNVYX7qf\"; ## SECRET-DATA\n }\n session 10.1.2.2 {\n authentication-key \"$8$Qq0I3nCrlMLX-9A7V\"; ## SECRET-DATA\n }\n }\n rip {\n authentication-type md5;\n authentication-key \"$8$34fM/u1ylMNVYX7qf\"; ## SECRET-DATA\n group RIP_GROUP {\n neighbor ge-1/0/1.0;\n }\n }\n}\n\nIf authentication is not enabled for all control plane protocols, this is a finding.","fixText":"Configure authentication to be enabled for all control plane protocols as shown in the example below.\n\n[edit protocols ospf area 0.0.0.0]\nset interface ge-0/0/0 authentication simple-password xxxxxxxxxxxx\nset interface ge-0/1/0 authentication simple-password xxxxxxxxxxxx\nset interface ge-0/2/0 authentication simple-password xxxxxxxxxxxx\n\n[edit protocols isis]\nset level 1 authentication-type md5\nset level 1 authentication-key xxxxxxxx\nset level 2 authentication-type md5\nset level 2 authentication-key xxxxxxxx\n\n[edit protocols rip]\nset authentication-type md5\nset authentication-key xxxxxxxx\n\n[edit protocols bgp group AS_2 neighbor x.x.x.x]\nset authentication-key xxxxxxxxxxxxxxx\n\n[edit protocols ldp]\nset session 10.1.2.2 authentication-key xxxxxxxxxx","ccis":["CCI-002205","CCI-000366"]},{"vulnId":"V-217013","ruleId":"SV-217013r945863_rule","severity":"medium","ruleTitle":"The Juniper router must be configured to use keys with a duration not exceeding 180 days for authenticating routing protocol messages.","description":"If the keys used for routing protocol authentication are guessed, the malicious user could create havoc within the network by advertising incorrect routes and redirecting traffic. Some routing protocols allow the use of key chains for authentication. A key chain is a set of keys that is used in succession, with each having a lifetime of no more than 180 days. Changing the keys frequently reduces the risk of them eventually being guessed.\n\nKeys cannot be used during time periods for which they are not activated. If a time period occurs during which no key is activated, neighbor authentication cannot occur, and therefore routing updates will fail. Therefore, ensure that for a given key chain, key activation times overlap to avoid any period of time during which no key is activated.","checkContent":"This requirement is not applicable for the DoDIN Backbone.\n\nReview the start times for each key within the configured key chains used for routing protocol authentication as shown in the examples below.\n\nsecurity {\n …\n …\n …\n authentication-key-chains {\n key-chain BGP_KEY {\n key 1 {\n secret \"$8$PTQnhclvMX3687\"; ## SECRET-DATA\n start-time \"2018-5-1.12:00:00 +0000\";\n }\n key 2 {\n secret \"$8$iq.5OBESyKfTlM\"; ## SECRET-DATA\n start-time \"2018-9-1.12:00:00 +0000\";\n }\n key 3 {\n secret \"$8$ZADjqAtOIRSk.hr\"; ## SECRET-DATA\n start-time \"2019-1-1.12:00:00 +0000\";\n }\n }\n }\n}\n\nospf {\n area 0.0.0.0 {\n interface ge-0/0/0.0 {\n authentication {\n md5 1 key \"$8$P5T36/t0ORDi.5F3tp\" start-time \"2018-1-1.01:01:00 +0000\"; ## SECRET-DATA\n md5 2 key \"$8$S.oevLbwg4aUvWxn\" start-time \"2018-4-1.01:01:00 +0000\"; ## SECRET-DATA\n md5 3 key \"$8$SInrWxbO1hcYg4ajH\" start-time \"2018-8-1.01:01:00 +0000\"; ## SECRET-DATA\n }\n }\n }\n}\n\nIf each key used for routing protocol authentication does not have a lifetime of no more than 180 days, this is a finding.","fixText":"This requirement is not applicable for the DoDIN Backbone.\n\nConfigure each key used for routing protocol authentication to have a lifetime of no more than 180 days as shown in the example below.\n\n[edit security authentication-key-chains]\nset key-chain BGP_KEY key 1 start-time 2018-05-01.12:00 secret xxxxxxxxxxxxx\nset key-chain BGP_KEY key 2 start-time 2018-09-01.12:00 secret xxxxxxxxxxxxx\nset key-chain BGP_KEY key 3 start-time 2019-01-01.12:00 secret xxxxxxxxxxxxx\n }\n\n[edit protocols ospf area 0.0.0.0 interface ge-0/0/0.0]\nset authentication md5 1 key xxxxxxxx start-time 2018-01-01.01:01\nset authentication md5 2 key xxxxxxxx start-time 2018-04-01.01:01 \nset authentication md5 3 key xxxxxxxx start-time 2018-08-01.01:01\n\nNote: Currently Junos does not support key chains for RIP.","ccis":["CCI-000366","CCI-002205"]},{"vulnId":"V-217014","ruleId":"SV-217014r604135_rule","severity":"medium","ruleTitle":"The Juniper router must be configured to use encryption for routing protocol authentication.","description":"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 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.\n\nThis 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.","checkContent":"Review the router configuration. For every routing protocol that affects the routing or forwarding tables, verify that neighbor router authentication is encrypting the authentication key as shown in the examples below.\n\nOSPF Example:\n\nprotocols {\n …\n …\n …\n ospf {\n area 0.0.0.0 {\n interface ge-0/0/0 {\n authentication {\n md5 1 key \"$8$NHVb2mPQ3nCYg/t\"; ## SECRET-DATA\n }\n }\n interface ge-0/1/0 {\n authentication {\n md5 1 key \"$8$Lgb7NbHkPTQnVwF/\"; ## SECRET-DATA\n }\n }\n interface lo0.0;\n interface ge-0/2/0 {\n authentication {\n md5 1 key \"$8$7DdVY.mTF39s26A\"; ## SECRET-DATA\n }\n }\n }\n }\n}\n\nIS-IS Example:\n\nsecurity {\n …\n …\n …\n }\n authentication-key-chains {\n key-chain ISIS_KEY {\n key 1 {\n secret \"$8$W8oXxdji.f5F-VQn\"; ## SECRET-DATA\n start-time \"2018-5-1.12:00:00 +0000\";\n algorithm hmac-sha-1;\n options isis-enhanced;\n }\n key 2 {\n secret \"$8$Q4953nCrlMLX-9A7V\"; ## SECRET-DATA\n start-time \"2018-9-1.12:00:00 +0000\";\n algorithm hmac-sha-1;\n options isis-enhanced;\n }\n key 3 {\n secret \"$8$UeiHmpu1Ehr.PSe\"; ## SECRET-DATA\n start-time \"2019-1-1.12:00:00 +0000\";\n algorithm hmac-sha-1;\n options isis-enhanced;\n }\n }\n }\n}\n\nprotocols {\n …\n …\n …\n isis {\n level 1 authentication-key-chain ISIS_KEY;\n level 2 authentication-key-chain ISIS_KEY;\n interface ge-0/0/0 {\n level 1 hello-authentication-key-chain ISIS_KEY;\n level 2 hello-authentication-key-chain ISIS_KEY;\n }\n interface lo0.0;\n }\n\nBGP Example:\n\nsecurity {\n …\n …\n …\n }\n authentication-key-chains {\n key-chain BGP_KEY {\n key 1 {\n secret \"$8$PTQnhclvMX3687\"; ## SECRET-DATA\n start-time \"2018-5-1.12:00:00 +0000\";\n }\n key 2 {\n secret \"$8$iq.5OBESyKfTlM\"; ## SECRET-DATA\n start-time \"2018-9-1.12:00:00 +0000\";\n }\n key 3 {\n secret \"$8$ZADjqAtOIRSk.hr\"; ## SECRET-DATA\n start-time \"2019-1-1.12:00:00 +0000\";\n }\n }\n\nprotocols {\n bgp {\n group AS_2 {\n type external;\n peer-as 2;\n neighbor 11.1.25.2 {\n authentication-algorithm md5;\n authentication-key-chain BGP_KEY;\n }\n neighbor 11.1.1.1 {\n authentication-algorithm hmac-sha-1-96;\n authentication-key-chain BGP_KEY;\n }\n }\n }\n \nIf the routing protocol is not encrypting the authentication key, this is a finding.","fixText":"Configure all routing protocol authentications to encrypt the authentication key.\n\nOSPF Example:\n\n[edit protocols ospf area 0.0.0.0]\nset interface ge-0/0/0 authentication md5 1 key xxxxxxxxxxxx\nset interface ge-0/1/0 authentication md5 1 key xxxxxxxxxxxx\nset interface ge-0/2/0 authentication md5 1 key xxxxxxxxxxxx\n\nIS-IS Example:\n\n[edit security authentication-key-chains]\nset key-chain ISIS_KEY key 1 options isis-enhanced\nset key-chain ISIS_KEY key 2 options isis-enhanced\nset key-chain ISIS_KEY key 3 options isis-enhanced\nset key-chain ISIS_KEY key 1 start-time 2018-05-01.12:00 algorithm hmac-sha-1 secret xxxxxxxxxxxxx\nset key-chain ISIS_KEY key 2 start-time 2018-09-01.12:00 algorithm hmac-sha-1 secret xxxxxxxxxxxxx\nset key-chain ISIS_KEY key 3 start-time 2019-01-01.12:00 algorithm hmac-sha-1 secret xxxxxxxxxxxxx\n\n[edit protocols]\nset isis level 1 authentication-key-chain ISIS_KEY\nset isis interface ge-0/0/0 level 1 hello-authentication-key-chain ISIS_KEY\nset isis interface ge-0/0/0 level 2 hello-authentication-key-chain ISIS_KEY\n\nBGP Example:\n\n[edit security authentication-key-chains]\nset key-chain BGP_KEY key 1 start-time 2018-05-01.12:00 secret xxxxxxxxxxxxx\nset key-chain BGP_KEY key 2 start-time 2018-09-01.12:00 secret xxxxxxxxxxxxx\nset key-chain BGP_KEY key 3 start-time 2019-01-01.12:00 secret xxxxxxxxxxxxx\n\n[edit protocols bgp group AS_5]\nset neighbor 11.1.25.5 authentication-algorithm hmac-sha-1-96\nset neighbor 11.1.25.5 authentication-key-chain BGP_KEY\nset neighbor 11.1.1.1 authentication-algorithm hmac-sha-1-96\nset neighbor 11.1.1.1 authentication-key-chain BGP_KEY","ccis":["CCI-000803"]},{"vulnId":"V-217015","ruleId":"SV-217015r604135_rule","severity":"medium","ruleTitle":"The Juniper router must be configured to authenticate all routing protocol messages using NIST-validated FIPS 140-2 message authentication code algorithm.","description":"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 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.\n\nSince MD5 is vulnerable to \"birthday\" attacks and may be compromised, routing protocol authentication must use FIPS 140-2 validated algorithms and modules to encrypt the authentication key. 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.","checkContent":"Review the router configuration to verify it is using a NIST-validated FIPS 140-2 message authentication code algorithm to authenticate routing protocol messages.\n\nIS-IS Example:\n\nsecurity {\n …\n …\n …\n }\n authentication-key-chains {\n key-chain ISIS_KEY {\n key 1 {\n secret \"$8$W8oXxdji.f5F-VQn\"; ## SECRET-DATA\n start-time \"2018-5-1.12:00:00 +0000\";\n algorithm hmac-sha-1;\n options isis-enhanced;\n }\n key 2 {\n secret \"$8$Q4953nCrlMLX-9A7V\"; ## SECRET-DATA\n start-time \"2018-9-1.12:00:00 +0000\";\n algorithm hmac-sha-1;\n options isis-enhanced;\n }\n key 3 {\n secret \"$8$UeiHmpu1Ehr.PSe\"; ## SECRET-DATA\n start-time \"2019-1-1.12:00:00 +0000\";\n algorithm hmac-sha-1;\n options isis-enhanced;\n }\n }\n }\n}\n\nprotocols {\n …\n …\n …\n isis {\n level 1 authentication-key-chain ISIS_KEY;\n level 2 authentication-key-chain ISIS_KEY;\n interface ge-0/0/0 {\n level 1 hello-authentication-key-chain ISIS_KEY;\n level 2 hello-authentication-key-chain ISIS_KEY;\n }\n interface lo0.0;\n }\n\nBGP Example:\n\n}\nsecurity {\n …\n …\n …\n }\n authentication-key-chains {\n key-chain BGP_KEY {\n key 1 {\n secret \"$8$PTQnhclvMX3687\"; ## SECRET-DATA\n start-time \"2018-5-1.12:00:00 +0000\";\n }\n key 2 {\n secret \"$8$iq.5OBESyKfTlM\"; ## SECRET-DATA\n start-time \"2018-9-1.12:00:00 +0000\";\n }\n key 3 {\n secret \"$8$ZADjqAtOIRSk.hr\"; ## SECRET-DATA\n start-time \"2019-1-1.12:00:00 +0000\";\n }\n }\n\nprotocols {\n bgp {\n group AS_2 {\n type external;\n peer-as 2;\n neighbor 11.1.25.2 {\n authentication-algorithm hmac-sha-1-96;\n authentication-key-chain BGP_KEY;\n }\n neighbor 11.1.1.1 {\n authentication-algorithm hmac-sha-1-96;\n authentication-key-chain BGP_KEY;\n }\n }\n }\n\nOSPF Example:\n\nIPsec authentication must be used to authenticate OSPF messages with a FIPS 140-2 message authentication code algorithm. \n\nStep 1: Verify the authentication algorithm in the IPsec security association as shown in the example below.\n\nsecurity {\n …\n …\n …\n ipsec {\n security-association IPSEC-SA1 {\n mode transport;\n manual {\n direction bidirectional {\n protocol ah;\n spi 256;\n authentication {\n algorithm hmac-sha1-96;\n key ascii-text \"$8$u6M6OEcrevL7-YaZUjHmF39B1hP5CuBRle\"; ## SECRET-DATA\n }\n }\n }\n }\n }\n\nStep 2: Verify that an IPsec security association has been configured on the interfaces as shown in the following example:\n\nprotocols {\n …\n …\n …\n ospf {\n area 0.0.0.0 {\n interface ge-0/0/0 {\n ipsec-sa IPSEC-SA1;\n }\n interface ge-0/1/0 {\n ipsec-sa IPSEC-SA1;\n }\n interface lo0.0;\n interface ge-0/2/0 {\n ipsec-sa IPSEC-SA1;\n }\n }\n }\n ospf3 {\n area 0.0.0.0 {\n interface ge-1/2/0 {\n ipsec-sa IPSEC-SA1;\n }\n }\n }\n}\n\nIf a NIST-validated FIPS 140-2 message authentication code algorithm is not being used to authenticate routing protocol messages, this is a finding.\n\nNote: Juniper does not support FIPS 140-2 message authentication code algorithm for RIP.","fixText":"Configure routing protocol authentication to use a NIST-validated FIPS 140-2 message authentication code algorithm.\n\nIS-IS Example:\n\n[edit security authentication-key-chains]\nset key-chain ISIS_KEY key 1 options isis-enhanced\nset key-chain ISIS_KEY key 2 options isis-enhanced\nset key-chain ISIS_KEY key 3 options isis-enhanced\nset key-chain ISIS_KEY key 1 start-time 2018-05-01.12:00 algorithm hmac-sha-1 secret xxxxxxxxxxxxx\nset key-chain ISIS_KEY key 2 start-time 2018-09-01.12:00 algorithm hmac-sha-1 secret xxxxxxxxxxxxx\nset key-chain ISIS_KEY key 3 start-time 2019-01-01.12:00 algorithm hmac-sha-1 secret xxxxxxxxxxxxx\n\n[edit protocols]\nset isis level 1 authentication-key-chain ISIS_KEY\nset isis interface ge-0/0/0 level 1 hello-authentication-key-chain ISIS_KEY\nset isis interface ge-0/0/0 level 2 hello-authentication-key-chain ISIS_KEY\n\nBGP Example:\n\n[edit security authentication-key-chains]\nset key-chain BGP_KEY key 1 start-time 2018-05-01.12:00 secret xxxxxxxxxxxxx\nset key-chain BGP_KEY key 2 start-time 2018-09-01.12:00 secret xxxxxxxxxxxxx\nset key-chain BGP_KEY key 3 start-time 2019-01-01.12:00 secret xxxxxxxxxxxxx\n\n[edit protocols bgp group AS_5]\nset neighbor 11.1.25.5 authentication-algorithm hmac-sha-1-96\nset neighbor 11.1.25.5 authentication-key-chain BGP_KEY\nset neighbor 11.1.1.1 authentication-algorithm hmac-sha-1-96\nset neighbor 11.1.1.1 authentication-key-chain BGP_KEY\n\nOSPF Example:\n\nConfigure IPsec Security Association\n[edit security ipsec]\nset security-association IPSEC-SA1\nset security-association IPSEC-SA1 mode transport\nset security-association IPSEC-SA1 manual direction bidirectional\nset security-association IPSEC-SA1 manual direction bidirectional protocol ah\nset security-association IPSEC-SA1 manual direction bidirectional spi 256 \nset security-association IPSEC-SA1 manual direction bidirectional authentication algorithm hmac-sha1-96 key ascii-text 1234567890abcdefghij \n\n[edit protocols ospf area 0.0.0.0]\nset interface ge-0/0/0 ipsec-sa IPSEC-SA1\nset interface ge-0/1/0 ipsec-sa IPSEC-SA1\nset interface ge-0/2/0 ipsec-sa IPSEC-SA1\n\n[edit protocols ospf area 0.0.0.0]\nset interface ge-1/2/0 ipsec-sa IPSEC-SA1","ccis":["CCI-000803"]},{"vulnId":"V-217016","ruleId":"SV-217016r604135_rule","severity":"low","ruleTitle":"The Juniper router must be configured to have all inactive interfaces disabled.","description":"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.\n\nIf an interface is no longer used, the configuration must be deleted and the interface disabled. For sub-interfaces, delete sub-interfaces that are on inactive interfaces and delete sub-interfaces that are themselves inactive. If the sub-interface is no longer necessary for authorized communications, it must be deleted.","checkContent":"Review the router configuration and verify that inactive interfaces have been disabled as shown below.\n\ninterfaces {\n ge-1/1/0 {\n disable;\n unit 0 {\n }\n }\n\nIf an interface is not being used but is configured or enabled, this is a finding.","fixText":"Disable all inactive interfaces as shown below.\n\n[edit interfaces]\nset ge-1/1/0 disable","ccis":["CCI-001414"]},{"vulnId":"V-217017","ruleId":"SV-217017r604135_rule","severity":"low","ruleTitle":"The Juniper router must be configured to have all non-essential capabilities disabled.","description":"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.","checkContent":"Review the router configuration to determine if services not required for operation are enabled. Services such as finger, ftp, telnet must never be enabled; hence, they should not be shown under the system services hierarchy.\n\nIf J-web is not used for administrative access, the web-management services must not be configured as shown below.\n\nIf DHCP server is not being deployed on the router, the command dhcp-local-server must not be configured as shown below.\n\nsystem {\n …\n …\n …\n services {\n web-management {\n https {\n interface ge-0/0/0.0;\n }\n }\n finger;\n ftp;\n ssh {\n protocol-version v2;\n macs [ hmac-sha1-96 hmac-sha2-256 hmac-sha2-512 ];\n }\n telnet;\n netconf {\n ssh;\n }\n dhcp-local-server {\n group DHCP_GROUP {\n interface ge-0/1/0.0;\n }\n }\n }\n\nIf unnecessary services and functions are enabled on the router, this is a finding.","fixText":"Remove unneeded services and functions from the router as shown below.\n\n[edit system services]\ndelete telnet\n[edit system services]\ndelete finger\n[edit system services]\ndelete ftp","ccis":["CCI-000381"]},{"vulnId":"V-217018","ruleId":"SV-217018r991997_rule","severity":"medium","ruleTitle":"The Juniper router must be configured to protect against or limit the effects of denial-of-service (DoS) attacks by employing control plane protection.","description":"The Routing Engine (RE) is critical to all network operations because it is the component used to build all forwarding paths for the data plane via control plane processes. It is also instrumental with ongoing network management functions that keep the routers and links available for providing network services. Any disruption to the RP or the control and management planes can result in mission-critical network outages.\n\nA DoS attack targeting the RE can result in excessive CPU and memory utilization. To maintain network stability and RP security, the router must be able to handle specific control plane and management plane traffic that is destined to the RE. In the past, one method of filtering was to use ingress filters on forwarding interfaces to filter both forwarding path and receiving path traffic. However, this method does not scale well as the number of interfaces grows and the size of the ingress filters grows. Control plane policing increases the security of routers and multilayer switches by protecting the RE from unnecessary or malicious traffic. Filtering and rate limiting the traffic flow of control plane packets can be implemented to protect routers against reconnaissance and DoS attacks, allowing the control plane to maintain packet forwarding and protocol states despite an attack or heavy load on the router or multilayer switch.","checkContent":"Determine whether control plane protection has been implemented on the router.\n\nVerify that a CoPP policy has been configured that classifies traffic types into levels of importance.\n\nfirewall {\n family inet {\n…\n…\n…\n }\n filter CoPP_Policy {\n term CRITICAL {\n from {\n protocol [ ospf pim tcp ];\n source-port bgp;\n destination-port bgp;\n }\n then policer CRITICAL_POLICER;\n }\n term IMPORTANT {\n from {\n protocol [ tcp udp ];\n destination-port [ ssh tacacs snmp ntp ];\n }\n then {\n policer IMPORTANT_POLICER; \n }\n }\n term NORMAL {\n from {\n protocol icmp;\n icmp-type [ echo-reply echo-request ];\n icmp-code [ port-unreachable ttl-eq-zero-during-transit ];\n }\n then policer NORMAL_POLICER;\n }\n term UNDESIRABLE {\n from {\n protocol udp;\n }\n then policer UNDESIRABLE_POLICER;\n }\n term ALL-OTHER {\n from {\n address {\n 0.0.0.0/0;\n }\n }\n then policer ALL-OTHER_POLICER;\n }\n }\n}\n\nVerify that policers have been configured to rate limit traffic types.\n\nfirewall {\n family inet {\n…\n…\n…\n }\n policer CRITICAL_POLICER {\n filter-specific;\n if-exceeding {\n bandwidth-limit 3m;\n burst-size-limit 4k;\n }\n then discard;\n }\n policer IMPORTANT_POLICER {\n filter-specific;\n if-exceeding {\n bandwidth-limit 400k;\n burst-size-limit 1500;\n }\n then discard;\n }\n policer NORMAL_POLICER {\n filter-specific;\n if-exceeding {\n bandwidth-limit 55k;\n burst-size-limit 1500;\n }\n then discard;\n }\n policer UNDESIRABLE_POLICER {\n filter-specific;\n if-exceeding {\n bandwidth-limit 32k;\n burst-size-limit 1500;\n }\n then discard;\n }\n policer ALL-OTHER_POLICER {\n filter-specific;\n if-exceeding {\n bandwidth-limit 40k;\n burst-size-limit 1500;\n }\n then discard;\n }\n\nVerify that the CoPP policy has been applied to the loopback interface as shown in the example below.\n\ninterfaces {\n…\n…\n…\n lo0 {\n unit 0 {\n family inet {\n filter {\n input CoPP_Policy;\n }\n address 2.2.2.2/32;\n }\n }\n }\n}\n\nNote: Several Juniper router platforms provide a Distributed DoS (DDoS) protection feature that is configured at the system hierarchy via set ddos-protection commands.\n\nIf the router does not have control plane protection implemented, this is a finding.","fixText":"Implement control plane protection by classifying traffic types based on importance and rate limit the traffic accordingly as shown in the example below.\n\nCreate filters for critical, important, normal, and undesirable traffic.\n\nset firewall filter CoPP_Policy term CRITICAL from protocol ospf\nset firewall filter CoPP_Policy term CRITICAL from protocol pim\nset firewall filter CoPP_Policy term CRITICAL from protocol tcp destination-port bgp\nset firewall filter CoPP_Policy term CRITICAL from protocol tcp source-port bgp\nset firewall filter CoPP_Policy term CRITICAL then policer CRITICAL_POLICER\n\nset firewall filter CoPP_Policy term IMPORTANT from protocol tcp destination-port ssh\nset firewall filter CoPP_Policy term IMPORTANT from protocol tcp destination-port tacacs\nset firewall filter CoPP_Policy term IMPORTANT from protocol tcp destination-port snmp\nset firewall filter CoPP_Policy term IMPORTANT from protocol tcp destination-port ntp\nset firewall filter CoPP_Policy term IMPORTANT then policer IMPORTANT_POLICER\n\nset firewall filter CoPP_Policy term NORMAL from protocol icmp icmp-code ttl-eq-zero-during-transit\nset firewall filter CoPP_Policy term NORMAL from protocol icmp icmp-code port-unreachable\nset firewall filter CoPP_Policy term NORMAL from protocol icmp icmp-type echo-reply\nset firewall filter CoPP_Policy term NORMAL from protocol icmp icmp-type echo-request\nset firewall filter CoPP_Policy term NORMAL then policer NORMAL_POLICER\n\nset firewall filter CoPP_Policy term UNDESIRABLE from protocol udp \nset firewall filter CoPP_Policy term UNDESIRABLE then policer UNDESIRABLE_POLICER\n\nset firewall filter CoPP_Policy term ALL-OTHER from address 0.0.0.0/0\nset firewall filter CoPP_Policy term ALL-OTHER then policer ALL-OTHER_POLICER\n\nCreate policers for each traffic type to limit bandwidth.\n\nset firewall policer CRITICAL_POLICER filter-specific\nset firewall policer CRITICAL_POLICER if-exceeding bandwidth-limit 3000000 burst-size-limit 4000\nset firewall policer CRITICAL_POLICER then discard\n\nset firewall policer IMPORTANT_POLICER filter-specific\nset firewall policer IMPORTANT_POLICER if-exceeding bandwidth-limit 400000 burst-size-limit 1500\nset firewall policer IMPORTANT_POLICER then discard\n\nset firewall policer NORMAL_POLICER filter-specific\nset firewall policer NORMAL_POLICER if-exceeding bandwidth-limit 55000 burst-size-limit 150000\nset firewall policer NORMAL_POLICER then discard\n\nset firewall policer UNDESIRABLE_POLICER filter-specific\nset firewall policer UNDESIRABLE_POLICER if-exceeding bandwidth-limit 32000 burst-size-limit 1500\nset firewall policer UNDESIRABLE_POLICER then discard\n\nset firewall policer ALL-OTHER_POLICER filter-specific\nset firewall policer ALL-OTHER_POLICER if-exceeding bandwidth-limit 40000 burst-size-limit 1500\nset firewall policer ALL-OTHER_POLICER then discard\n\nApply the CoPP policy to the loopback interface.\n\nset interface lo0 unit 0 family inet filter input CoPP_Policy\n\nNote: Several Juniper router platforms provide a DDoS Protection feature that is configured at the system hierarchy via set ddos-protection commands.","ccis":["CCI-002385","CCI-004866"]},{"vulnId":"V-217019","ruleId":"SV-217019r604135_rule","severity":"high","ruleTitle":"The Juniper router must be configured to restrict traffic destined to itself.","description":"The Routing Engine handles traffic destined to the router—the key component used to build forwarding paths and is instrumental with all network management functions. Hence, any disruption or DoS attack to the Routing Engine can result in mission critical network outages.","checkContent":"Review the filter for the router’s receive path and verify that it will only allow specific management plane traffic from specific sources.\n\nVerify filter has been configured as shown in the example below.\n\nfirewall {\n family inet {\n …\n …\n …\n }\n filter DESTINED_TO_RE {\n term ALLOW_OSPF {\n from {\n protocol ospf;\n }\n then accept;\n }\n term ALLOW_BGP {\n from {\n source-address {\n 11.1.12.1/32;\n 11.1.23.3/32;\n 11.1.25.5/32;\n }\n protocol tcp;\n port bgp;\n }\n }\n term FILTER_TCP {\n from {\n destination-address {\n 11.1.12.0/24;\n }\n protocol tcp;\n destination-port [ ssh tacacs telnet ];\n }\n then accept;\n }\n term FILTER_UDP {\n from {\n destination-address {\n 11.1.12.0/24;\n }\n protocol udp;\n destination-port [ntp snmp ];\n }\n then accept;\n }\n term ICMP_ANY {\n from {\n protocol icmp;\n }\n then accept;\n }\n term DENY_BY_DEFAULT {\n then {\n log;\n discard;\n }\n }\n }\n }\n\nVerify that the input filter has been applied to loopback interface as shown in the example below.\n \ninterfaces {\n…\n…\n…\n lo0 {\n unit 0 {\n family inet {\n filter {\n input-list [ DESTINED_TO_RE CoPP_Policy ];\n }\n address 2.2.2.2/32;\n }\n }\n }\n}\n\nIf the router is not configured with a receive-path filter to restrict traffic destined to itself, this is a finding","fixText":"Configure the router’s receive path filters to restrict traffic destined to the router.\n\nConfigure a filter to define what traffic should be received by the Routing Engine.\n\n[edit firewall family inet]\nset filter DESTINED_TO_RP term FILTER_TCP from destination-address 11.1.12.0/24 \nset filter DESTINED_TO_RP term FILTER_TCP from protocol tcp destination-port ssh\nset filter DESTINED_TO_RP term FILTER_TCP from protocol tcp destination-port tacacs\nset filter DESTINED_TO_RP term FILTER_TCP then accept\nset filter DESTINED_TO_RP term FILTER_UDP from destination-address 11.1.12.0/24 \nset filter DESTINED_TO_RP term FILTER_UDP from protocol udp destination-port ntp\nset filter DESTINED_TO_RP term FILTER_UDP from protocol udp destination-port snmp\nset filter DESTINED_TO_RP term FILTER_UDP then accept\nset filter DESTINED_TO_RP term ICMP_ANY from protocol icmp \nset filter DESTINED_TO_RP term ICMP_ANY from protocol icmp then accept\nset filter DESTINED_TO_RP term DENY_BY_DEFAULT then log discard\n\nApply the filter to the loopback interface.\n\n[edit interfaces lo0 unit 0 family inet] \nset filter input-list DESTINED_TO_RP.","ccis":["CCI-001097"]},{"vulnId":"V-217020","ruleId":"SV-217020r604135_rule","severity":"medium","ruleTitle":"The Juniper router must be configured to drop all fragmented Internet Control Message Protocol (ICMP) packets destined to itself.","description":"Fragmented ICMP packets can be generated by hackers for DoS attacks such as Ping O' Death and Teardrop. It is imperative that all fragmented ICMP packets are dropped.","checkContent":"Review the filter that is applied inbound to the loopback interface and verify that it discards fragmented ICMP packets as shown in the example below.\n\nfirewall {\n family inet {\n …\n …\n …\n }\n filter DESTINED_TO_RE {\n …\n …\n …\n }\n term BLOCK_ICMP_FRAG {\n from {\n is-fragment;\n protocol icmp;\n }\n then {\n discard;\n }\n }\n term ICMP_ANY {\n from {\n protocol icmp;\n }\n then accept;\n }\n term DENY_BY_DEFAULT {\n then {\n log;\n discard;\n }\n }\n }\n }\n\nIf the router is not configured to filter to drop all fragmented ICMP packets destined to itself, this is a finding.","fixText":"Configure the filter that is applied inbound to the loopback interface to drop all fragmented ICMP packets as shown in the example below.\n\n[edit firewall family inet filter DESTINED_TO_RP]\nset term BLOCK_ICMP_FRAG from protocol icmp is-fragment\nset term BLOCK_ICMP_FRAG then discard\ninsert term BLOCK_ICMP_FRAG before term DENY_BY_DEFAULT","ccis":["CCI-001097"]},{"vulnId":"V-217021","ruleId":"SV-217021r855889_rule","severity":"medium","ruleTitle":"The Juniper router must be configured to have Gratuitous ARP disabled on all external interfaces.","description":"A gratuitous ARP is an ARP broadcast in which the source and destination MAC addresses are the same. It is used to inform the network about a host IP address. A spoofed gratuitous ARP message can cause network mapping information to be stored incorrectly, causing network malfunction.","checkContent":"Review the configuration to determine if gratuitous ARP is disabled on all external interfaces. The following command should not be set to any interface: gratuitous-arp-reply\n\nIf gratuitous ARP is enabled on any external interface, this is a finding.","fixText":"Disable gratuitous ARP on all external interfaces using the following command.\n\n[edit interfaces ge-1/1/0 ]\ndelete gratuitous-arp-reply","ccis":["CCI-002385"]},{"vulnId":"V-217022","ruleId":"SV-217022r855890_rule","severity":"medium","ruleTitle":"The Juniper router must be configured to have Internet Control Message Protocol (ICMP) unreachable messages disabled on all external interfaces.","description":"The ICMP supports IP traffic by relaying information about paths, routes, and network conditions. Routers automatically send ICMP messages under a wide variety of conditions. Host unreachable ICMP messages are commonly used by attackers for network mapping and diagnosis.","checkContent":"Review the firewall hierarchy configuration to verify that all packets that are not permitted are silently dropped using the discard parameter as shown in the configuration example below.\n\nfirewall {\n family inet {\n …\n …\n …\n }\n filter FILTER_INBOUND {\n term ALLOW_XYZ {\n from {\n protocol xyz;\n }\n then accept;\n }\n …\n …\n …\n }\n term DENY_BY_DEFAULT {\n then {\n log;\n discard;\n }\n }\n }\n }\n\nIf ICMP unreachable notifications are sent for packets that are dropped, this is a finding.","fixText":"[edit firewall family inet]\nset filter FILTER_INBOUND term DENY_BY_DEFAULT then log discard","ccis":["CCI-002385"]},{"vulnId":"V-217023","ruleId":"SV-217023r855891_rule","severity":"medium","ruleTitle":"The Juniper router must be configured to have Internet Control Message Protocol (ICMP) mask reply messages disabled on all external interfaces.","description":"The ICMP supports IP traffic by relaying information about paths, routes, and network conditions. Routers automatically send ICMP messages under a wide variety of conditions. Mask Reply ICMP messages are commonly used by attackers for network mapping and diagnosis.","checkContent":"JUNOS has no interface command to not reply to an ICMP Mask Request message destined to the router. Consequently, to ensure that the router does not send any ICMP Mask Reply message in response to an ICMP Mask Request, include a term statement in the routing engine filter to silently drop any ICMP Masks Requests sent to it as shown in the example below.\n\nfirewall {\n family inet {\n …\n …\n …\n }\n filter DESTINED_TO_RE {\n term ALLOW_XYZ {\n from {\n protocol xyz;\n }\n then accept;\n }\n …\n …\n …\n }\n term DENY_MASK_REQUEST {\n from {\n protocol icmp;\n icmp-type mask-request;\n }\n then {\n discard;\n }\n }\n term ICMP_ANY {\n from {\n protocol icmp;\n }\n then accept;\n }\n term DENY_BY_DEFAULT {\n then {\n log;\n discard;\n }\n }\n }\n }\n\nIf the router is not configured to silently drop all ICMP Mask Reply messages destined to the router, this is a finding.","fixText":"Configure the filter protecting the routing engine to silently drop all ICMP Mask Request messages destined to the router.\n\n[edit firewall family inet filter DESTINED_TO_RP]\nset term DENY_MASK_REQUEST from protocol icmp icmp-type mask-request\ninsert term DENY_MASK_REQUEST before term ALLOW_ICMP","ccis":["CCI-002385"]},{"vulnId":"V-217024","ruleId":"SV-217024r855892_rule","severity":"medium","ruleTitle":"The Juniper router must be configured to have Internet Control Message Protocol (ICMP) redirect messages disabled on all external interfaces.","description":"The ICMP supports IP traffic by relaying information about paths, routes, and network conditions. Routers automatically send ICMP messages under a wide variety of conditions. Redirect ICMP messages are commonly used by attackers for network mapping and diagnosis.","checkContent":"Review the device configuration to determine if it has been configured to ensure the router does not send ICMP Redirect messages out to any external interface.\n\ninterfaces {\n ge-1/0/0 {\n unit 0 {\n family inet {\n no-redirects;\n address 11.1.12.2/24;\n }\n }\n }\n ge-1/1/0 {\n unit 0 {\n family inet {\n no-redirects;\n address 11.1.23.2/24;\n }\n }\n }\n\nIf ICMP Redirect messages are enabled on any external interfaces, this is a finding.","fixText":"Disable ICMP redirects on all external interfaces as shown in the example below.\n\n[edit interfaces]\nset ge-1/0/0 unit 0 family inet no-redirects\nset ge-1/1/0 unit 0 family inet no-redirects","ccis":["CCI-002385"]},{"vulnId":"V-217025","ruleId":"SV-217025r604135_rule","severity":"low","ruleTitle":"The Juniper router must be configured to log all packets that have been dropped.","description":"Auditing and logging are key components of any security architecture. It is essential for security personnel to know what is being done or attempted to be done, and by whom, to compile an accurate risk assessment. Auditing the actions on network devices provides a means to recreate an attack or identify a configuration mistake on the device.","checkContent":"Review all filters to verify that packets that are discarded or rejected are logged as shown in the configuration below.\n\nfirewall {\n family inet {\n filter XYZ\n …\n …\n …\n }\n term DENY_BY_DEFAULT {\n then {\n syslog;\n discard;\n }\n }\n }\n }\n\nVerify that logging is enabled to capture packets that are dropped as shown in the configuration below.\n\nsystem {\n host-name XYZ;\n …\n …\n …\n }\n syslog {\n file LOG_FILE {\n firewall any;\n }\n }\n}\n\nNote: The “any” parameter can be configured in lieu of the “firewall” parameter.\n\nIf packets being dropped are not logged, this is a finding.","fixText":"Configure the firewall terms that discards or rejects packets to log the action as shown in the example below.\n\n[edit firewall family inet]\nset filter FILTER_INBOUND term DENY_BY_DEFAULT then syslog discard\n\nConfigure logging to record packets being dropped by firewall filters as shown in the example below.\n\n[edit system syslog]\nset file LOG_FILE firewall any\n\nNote: The “any” parameter can be configured in lieu of the “firewall” parameter.","ccis":["CCI-000134"]},{"vulnId":"V-217026","ruleId":"SV-217026r604135_rule","severity":"medium","ruleTitle":"The Juniper router must be configured to produce audit records containing information to establish where the events occurred.","description":"Without establishing where events occurred, it is impossible to establish, correlate, and investigate the events leading up to an outage or attack.\n\nIn order to compile an accurate risk assessment and provide forensic analysis, it is essential for security personnel to know where events occurred, such as router components, modules, device identifiers, node names, and functionality.\n\nAssociating information about where the event occurred within the network provides a means of investigating an attack, recognizing resource utilization or capacity thresholds, or identifying an improperly configured router.","checkContent":"Review the router configuration to verify that events are logged containing information to establish where the events occurred as shown in the example below.\n\nsystem {\n host-name XYZ;\n …\n …\n …\n }\n syslog {\n file LOG_FILE {\n any any;\n }\n }\n}\n\nIf the router is not configured to produce audit records containing information to establish to establish where the events occurred, this is a finding.","fixText":"Configure the router to log events containing information to establish where the events occurred as shown in the example below.\n \n[edit system syslog]\nset file LOG_FILE any any","ccis":["CCI-000132"]},{"vulnId":"V-217027","ruleId":"SV-217027r604135_rule","severity":"medium","ruleTitle":"The Juniper router must be configured to produce audit records containing information to establish the source of the events.","description":"Without establishing the source of the event, it is impossible to establish, correlate, and investigate the events leading up to an outage or attack.\n\nIn order to compile an accurate risk assessment and provide forensic analysis, security personnel need to know the source of the event.\n\nIn addition to logging where events occur within the network, the audit records must also identify sources of events such as IP addresses, processes, and node or device names.","checkContent":"Review the router configuration to verify that events are logged containing information to establish where the events occurred as shown in the example below.\n\nsystem {\n host-name XYZ;\n …\n …\n …\n }\n syslog {\n file LOG_FILE {\n any any;\n }\n }\n}\n\nIf the router is not configured to produce audit records containing information to establish the source of the events, this is a finding.","fixText":"Configure the router to log events containing information to establish where the events occurred as shown in the example below.\n \n[edit system syslog]\nset file LOG_FILE any any","ccis":["CCI-000133"]},{"vulnId":"V-217028","ruleId":"SV-217028r604135_rule","severity":"low","ruleTitle":"The Juniper router must be configured to disable the auxiliary port unless it is connected to a secured modem providing encryption and authentication.","description":"The use of POTS lines to modems connecting to network devices provides clear text of authentication traffic over commercial circuits that could be captured and used to compromise the network. Additional war dial attacks on the device could degrade the device and the production network.\n\nSecured modem devices must be able to authenticate users and must negotiate a key exchange before full encryption takes place. The modem will provide full encryption capability (Triple DES) or stronger. The technician who manages these devices will be authenticated using a key fob and granted access to the appropriate maintenance port; thus, the technician will gain access to the managed device (router, switch, etc.). The token provides a method of strong (two-factor) user authentication. The token works in conjunction with a server to generate one-time user passwords that will change values at second intervals. The user must know a personal identification number (PIN) and possess the token to be allowed access to the device.","checkContent":"Review the configuration and verify that the auxiliary port is disabled unless a secured modem providing encryption and authentication is connected to it.\n\nIf the auxiliary port has never been configured or has been removed from the configuration this is Not Applicable.\n\nsystem {\n host-name XYZ;\n …\n …\n …\n ports {\n auxiliary {\n disable;\n type xterm;\n }\n }\n\nIf the auxiliary port is not disabled or is not connected to a secured modem when it is enabled, this is a finding.","fixText":"Disable the auxiliary port.\n\n[edit system ports]\nset auxiliary disable\n\nNote: If used for out-of-band administrative access, the port must be connected to a secured modem providing encryption and authentication.","ccis":["CCI-001414"]},{"vulnId":"V-217029","ruleId":"SV-217029r604135_rule","severity":"high","ruleTitle":"The Juniper perimeter router must be configured to deny network traffic by default and allow network traffic by exception.","description":"A deny-all, permit-by-exception network communications traffic policy ensures that only connections that are essential and approved are allowed.\n\nThis requirement applies to both inbound and outbound network communications traffic. All inbound and outbound traffic must be denied by default. Firewalls and perimeter routers should only allow traffic through that is explicitly permitted. The initial defense for the internal network is to block any traffic at the perimeter that is attempting to make a connection to a host residing on the internal network. In addition, allowing unknown or undesirable outbound traffic by the firewall or router will establish a state that will permit the return of this undesirable traffic inbound.","checkContent":"This requirement is not applicable for the DoDIN Backbone.\n\nReview the router configuration to verify that the inbound filter applied to all external interfaces is configured to allow specific ports and protocols and deny all other traffic.\n\nVerify that an inbound filter is applied to all external interfaces as shown in the example below.\n\ninterfaces {\n ge-0/0/0 {\n unit 0 {\n family inet {\n filter {\n input FILTER_INBOUND_TRAFFIC;\n }\n address 11.1.12.2/24;\n }\n }\n }\n\nReview inbound filters to verify that the ending term is configured to deny all other traffic that is not explicitly allowed.\n\nfirewall {\n family inet {\n filter FILTER_INBOUND_TRAFFIC {\n term ALLOW_BGP {\n from {\n destination-address {\n 11.1.24.0/24;\n }\n protocol tcp;\n destination-port bgp;\n }\n then accept;\n }\n …\n …\n …\n term ALLOW_XYZ {\n from {\n protocol xyz;\n }\n then accept;\n }\n term DENY_ALL_OTHER {\n then {\n syslog;\n discard;\n }\n }\n }\n\nIf the filter is not configured to allow specific ports and protocols and deny all other traffic, this is a finding.\n\nIf the filter is not configured inbound on all external interfaces, this is a finding.","fixText":"This requirement is not applicable for the DoDIN Backbone.\n\nConfigure a term at the end of the inbound filter to deny all other traffic by default as shown in the example below.\n\n[edit firewall family inet]\nset filter FILTER_INBOUND_TRAFFIC term DENY_ALL_OTHER then syslog discard","ccis":["CCI-001109"]},{"vulnId":"V-217030","ruleId":"SV-217030r604135_rule","severity":"medium","ruleTitle":"The Juniper perimeter router must be configured to enforce approved authorizations for controlling the flow of information between interconnected networks in accordance with applicable policy.","description":"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.","checkContent":"This requirement is not applicable for the DODIN Backbone.\n\nReview the router configuration to verify that filters are configured to allow or deny traffic for specific source and destination addresses as well as ports and protocols. In the example below, the router is peering BGP with DISN. ICMP echo and echo-reply packets are allowed for troubleshooting connectivity. WWW traffic is permitted inbound to the NIPRnet host-facing web server (x.12.1.22).\n\nStep 1: Verify that external interface has an inbound filter configured as shown in the example below:\n\ninterfaces {\n ge-0/0/0 {\n unit 0 {\n family inet {\n filter {\n input FILTER_INBOUND_TRAFFIC;\n }\n address x.1.12.2/30;\n }\n }\n }\n\n\nStep 2: Verify that the inbound filter allows only traffic that is to be permitted into the network as shown in the example below:\n\nfirewall {\n family inet {\n filter FILTER_INBOUND_TRAFFIC {\n term TCP_ESTABLISHED {\n from {\n tcp-established;\n }\n then accept;\n }\n term ALLOW_BGP {\n from {\n source-address {\n x.1.12.1/32;\n }\n protocol tcp;\n destination-port bgp;\n }\n then accept;\n }\n term ALLOW_PING {\n from {\n protocol icmp;\n icmp-type [ echo-reply echo-request ];\n }\n then accept;\n }\n term ALLOW_WWW {\n from {\n destination-address {\n x.12.1.22/32;\n }\n protocol tcp;\n destination-port http;\n }\n then accept;\n }\n term DENY_ALL_OTHER {\n then {\n syslog;\n reject;\n }\n }\n }\n }\n}\n\nIf the router is not configured to enforce approved authorizations for controlling the flow of information within the network based on organization-defined information flow control policies, this is a finding.","fixText":"This requirement is not applicable for the DODIN Backbone.\n\n[edit firewall family inet]\nset filter FILTER_INBOUND_TRAFFIC term TCP_ESTABLISHED from tcp-established\nset filter FILTER_INBOUND_TRAFFIC term TCP_ESTABLISHED then accept\nset filter FILTER_INBOUND_TRAFFIC term ALLOW_BGP from source-address x.1.12.1/32\nset filter FILTER_INBOUND_TRAFFIC term ALLOW_BGP from protocol tcp\nset filter FILTER_INBOUND_TRAFFIC term ALLOW_BGP from destination-port bgp\nset filter FILTER_INBOUND_TRAFFIC term ALLOW_BGP then accept\nset filter FILTER_INBOUND_TRAFFIC term ALLOW_PING from protocol icmp\nset filter FILTER_INBOUND_TRAFFIC term ALLOW_PING from icmp-type echo-reply\nset filter FILTER_INBOUND_TRAFFIC term ALLOW_PING from icmp-type echo-request\nset filter FILTER_INBOUND_TRAFFIC term ALLOW_PING then accept\nset filter FILTER_INBOUND_TRAFFIC term ALLOW_WWW from destination-address x.12.1.22/32\nset filter FILTER_INBOUND_TRAFFIC term ALLOW_WWW from protocol tcp\nset filter FILTER_INBOUND_TRAFFIC term ALLOW_WWW from destination-port http\nset filter FILTER_INBOUND_TRAFFIC term ALLOW_WWW then accept\nset filter FILTER_INBOUND_TRAFFIC term DENY_ALL_OTHER then syslog\nset filter FILTER_INBOUND_TRAFFIC term DENY_ALL_OTHER then reject\n\nStep 2: Apply the filter inbound on all applicable interfaces.\n\n[edit interfaces ge-0/0/0 unit 0 family inet]\nset filter input FILTER_INBOUND_TRAFFIC","ccis":["CCI-001414"]},{"vulnId":"V-217031","ruleId":"SV-217031r855893_rule","severity":"medium","ruleTitle":"The Juniper perimeter router must be configured to only allow incoming communications from authorized sources to be routed to authorized destinations.","description":"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.\n\nTraffic can be restricted directly by an access control list (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.\n\nThis requirement is intended to allow network administrators the flexibility to use whatever technique is most effective.","checkContent":"This requirement is not applicable for the DoDIN Backbone.\n\nReview the router configuration to determine if the router allows only incoming communications from authorized sources to be routed to authorized destinations. The hypothetical example below allows inbound NTP from host x.3.12.33 only to host x.1.22.4.\n\nfilter INBOUND_FILTER {\n term ALLOW_NTP {\n from {\n source-address {\n x.3.12.33/32;\n }\n destination-address {\n x.1.22.4/32; <<< change to global address\n }\n protocol udp;\n destination-port ntp;\n }\n }\n}\n\nIf the router does not restrict incoming communications to allow only authorized sources and destinations, this is a finding.","fixText":"This requirement is not applicable for the DoDIN Backbone.\n\nConfigure the router to allow only incoming communications from authorized sources to be routed to authorized destinations.","ccis":["CCI-002403"]},{"vulnId":"V-217032","ruleId":"SV-217032r855894_rule","severity":"medium","ruleTitle":"The Juniper perimeter router must be configured to block inbound packets with source Bogon IP address prefixes.","description":"Packets with Bogon IP source addresses should never be allowed to traverse the IP core. Bogon IP networks are RFC1918 addresses or address blocks that have never been assigned by the IANA or have been reserved.","checkContent":"This requirement is not applicable for the DoDIN Backbone.\n\nReview the router configuration to verify that an ingress filter applied to all external interfaces is blocking packets with Bogon source addresses.\n\nVerify a prefix list has been configured containing the current Bogon prefixes as shown in the example below.\n\npolicy-options {\n prefix-list BOGON_PREFIXES {\n 0.0.0.0/8;\n 10.0.0.0/8;\n 100.64.0.0/10;\n 127.0.0.0/8;\n 169.254.0.0/16;\n 172.16.0.0/12;\n 192.0.0.0/24;\n 192.0.2.0/24;\n 192.168.0.0/16;\n 198.18.0.0/15;\n 198.51.100.0/24;\n 203.0.113.0/24;\n 224.0.0.0/4;\n 240.0.0.0/4;\n }\n}\n\nVerify that the inbound filter applied to all external interfaces will block all traffic from Bogon source addresses.\n\ninterfaces {\n ge-0/0/0 {\n unit 0 {\n family inet {\n filter {\n input INBOUND_FILTER;\n }\n address 11.1.12.2/24;\n }\n }\n }\n…\n…\n…\nfirewall {\n family inet {\n filter INBOUND_FILTER {\n term BLOCK_BOGONS {\n from {\n source-prefix-list {\n BOGON_PREFIXES;\n }\n }\n then {\n syslog;\n discard;\n }\n }\n term ALLOW_BGP {\n from {\n protocol tcp;\n destination-port bgp;\n }\n then accept;\n }\n term ALLOW_XYZ {\n from {\n protocol xyz;\n }\n then accept;\n }\n term DENY_ALL_OTHER {\n then {\n syslog;\n reject;\n }\n }\n }\n}\n\nExternal Interfaces connected to the NIPRNet or SIPRNet\n\nReview the inbound ACLs on external facing interfaces attached to the NIPRnet or SIPRnet to validate access control lists are configured to block inbound packets with IP sources addresses as documented in RFC5735 and RFC6598. \n\n\nExternal Interfaces connected to a commercial ISP or other non-DoD network\nReview the inbound ACLs on external facing interfaces validate access control lists are configured to block inbound packets with IP sources addresses as documented in RFC5735 and RFC6598, as well as address space that has been allocated to the RIRs but not assigned by the RIR to an ISP or other enterprise network. The full list of bogons can be found at the following link: https://www.team-cymru.org/Services/Bogons/fullbogons-ipv4.txt\n\nIf the router is not configured to block inbound packets with source Bogon IP address prefixes, this is a finding.","fixText":"This requirement is not applicable for the DoDIN Backbone.\n\nConfigure the perimeter to block inbound packets with Bogon source addresses.\n\nConfigure a prefix list containing the current Bogon prefixes as shown below.\n\n[edit policy-options]\nset prefix-list BOGON_PREFIXES 0.0.0.0/8\nset prefix-list BOGON_PREFIXES 10.0.0.0/8\nset prefix-list BOGON_PREFIXES 100.64.0.0/10\nset prefix-list BOGON_PREFIXES 127.0.0.0/8\nset prefix-list BOGON_PREFIXES 169.254.0.0/16\nset prefix-list BOGON_PREFIXES 172.16.0.0/12\nset prefix-list BOGON_PREFIXES 192.0.0.0/24\nset prefix-list BOGON_PREFIXES 192.0.2.0/24\nset prefix-list BOGON_PREFIXES 192.168.0.0/16\nset prefix-list BOGON_PREFIXES 198.18.0.0/15\nset prefix-list BOGON_PREFIXES 198.51.100.0/24\nset prefix-list BOGON_PREFIXES 203.0.113.0/24\nset prefix-list BOGON_PREFIXES 224.0.0.0/4\nset prefix-list BOGON_PREFIXES 240.0.0.0/4\n\nAdd a term to the inbound filter to block the Bogon prefixes.\n\n[edit firewall family inet filter INBOUND_FILTER]\nset term BLOCK_BOGONS from source-prefix-list BOGON_PREFIXES\nset term BLOCK_BOGONS then syslog discard\ninsert term BLOCK_BOGONS before term ALLOW_BGP","ccis":["CCI-002403"]},{"vulnId":"V-217033","ruleId":"SV-217033r1050846_rule","severity":"high","ruleTitle":"The Juniper perimeter router must be configured to protect an enclave connected to an approved gateway by using an inbound filter that only permits packets with destination addresses within the site's address space.","description":"Enclaves with approved 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 denial-of-service (DoS) attack and provide a back door 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.","checkContent":"This requirement is not applicable for the DODIN backbone.\n\nVerify the interface connecting to the ISP has an inbound filter as shown in the example below.\n\ninterfaces {\n ge-0/0/0 {\n description \"Verizon ISP link\";\n unit 0 {\n family inet {\n filter {\n input ISP_FILTER;\n }\n address 11.1.12.2/24;\n }\n }\n }\n\nVerify that the filter only allows traffic to specific destination addresses (i.e., enclave’s NIPRNet address space) as shown in the example below.\n\nfirewall {\n family inet {\n filter ISP_FILTER {\n term RESTRICT_DESTINATION {\n from {\n destination-address {\n 0.0.0.0/0;\n 11.1.0.0/16 except;\n }\n }\n then {\n syslog;\n discard;\n }\n }\n term ALLOW_XYZ {\n from {\n protocol xyz;\n }\n then accept;\n }\n …\n …\n …\n term DENY_ALL_OTHER {\n then {\n syslog;\n reject;\n }\n }\n }\n\nIf the ingress filter bound to the interface connecting to an approved gateway 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 approved gateway network service provider, this is a finding.","fixText":"This requirement is not applicable for the DODIN backbone.\n\nConfigure the ingress filter of the perimeter router connected to an approved 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 approved gateway network service provider as shown in the example below.\n\n[edit firewall family inet filter ISP_FILTER]\nset term RESTRICT_DESTINATION from destination-address 0.0.0.0/0\nset term RESTRICT_DESTINATION from destination-address 11.1.0.0/16 except\nset term RESTRICT_DESTINATION then syslog discard\ninsert term RESTRICT_DESTINATION before term ALLOW_XYZ","ccis":["CCI-001414"]},{"vulnId":"V-217034","ruleId":"SV-217034r1050849_rule","severity":"high","ruleTitle":"The Juniper perimeter router must be configured to not be a Border Gateway Protocol (BGP) peer to an approved gateway service provider.","description":"Internet service providers (ISPs) use BGP to share route information with other autonomous systems (i.e., other ISPs and corporate networks). If the perimeter router was configured to BGP peer with an ISP, NIPRNet routes could be advertised to the ISP, thereby creating a backdoor connection from the internet to the NIPRNet.","checkContent":"This requirement is not applicable for the DODIN backbone.\n\nReview the protocols hierarchy in the router configuration (see example below) and verify no BGP neighbors are configured to a peer AS that belongs to the approved gateway service provider.\n\nprotocols {\n bgp {\n group AS_2 {\n type external;\n peer-as 2;\n neighbor x.x.x.x {\n authentication-algorithm hmac-sha-1-96;\n authentication-key-chain BGP_KEY;\n }\n neighbor x.x.x.x {\n authentication-algorithm hmac-sha-1-96;\n authentication-key-chain BGP_KEY;\n }\n }\n }\n\nIf BGP neighbors are connecting to a peer AS of the approved gateway service provider, this is a finding.","fixText":"This requirement is not applicable for the DODIN backbone.\n\nConfigure a static route on the perimeter router to reach the AS of a router connecting to an approved gateway as shown in the example below.\n\n[edit routing-options]\nset static route 0.0.0.0/0 next-hop x.x.x.x","ccis":["CCI-001414"]},{"vulnId":"V-217035","ruleId":"SV-217035r604135_rule","severity":"low","ruleTitle":"The Juniper perimeter router must be configured to not redistribute static routes to an alternate gateway service provider into BGP or an IGP peering with the NIPRNet or to other autonomous systems.","description":"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.","checkContent":"This requirement is not applicable for the DoDIN Backbone.\n\nReview the configurations under the protocols hierarchy. If the export statement is configured as shown in the example below proceed to step 2.\n\n}\nprotocols {\n bgp {\n group AS_5 {\n type external;\n export REDISTRIBUTE;\n peer-as 5;\n …\n …\n …\n }\n }\n }\n ospf {\n export REDISTRIBUTE;\n area 0.0.0.0 {\n interface ge-0/0/0 {\n …\n …\n …\n }\n }\n }\n}\n\nReview the export policy referenced above to determine if static routes are being exported as shown in the example below.\n\npolicy-options {\n …\n …\n …\n }\n policy-statement REDISTRIBUTE {\n term EXPORT_STATIC {\n from protocol static;\n then accept;\n }\n }\n}\n\nReview the static routes that have been configured to determine if there routes with the next hop address that of the alternate gateway.\n\nrouting-options {\n static {\n route 10.1.16.0/24 next-hop 10.1.12.1;\n route 0.0.0.0/0 next-hop 144.22.1.3;\n }\n\nIf the static routes to the alternate gateway are being redistributed into BGP or any IGP peering to a NIPRNet gateway or any other autonomous system, this is a finding.","fixText":"This requirement is not applicable for the DoDIN Backbone.\n\nConfigure the router so that static routes are not redistributed to an alternate gateway into either a BGP or any IGP peering with the NIPRNet or to any other autonomous systems. This can be done by excluding that route in the export policy as shown in the example below.\n\n[edit policy-options policy-statement REDISTRIBUTE]\nset term NOT_ISP_DEFAULT from protocol static route-filter 0.0.0.0/0 exact\nset term NOT_ISP_DEFAULT then reject\ninsert term set term NOT_ISP_DEFAULT before term EXPORT_STATIC","ccis":["CCI-001414"]},{"vulnId":"V-217036","ruleId":"SV-217036r945858_rule","severity":"high","ruleTitle":"The Juniper perimeter router must be configured to restrict it from accepting outbound IP packets that contain an illegitimate address in the source address field via egress filter or by enabling Unicast Reverse Path Forwarding (uRPF).","description":"A compromised host in an enclave can be used by a malicious platform to launch cyberattacks on third parties. This is a common practice in \"botnets\", which are a collection of compromised computers using malware to attack other computers or networks. DDoS attacks frequently leverage IP source address spoofing to send packets to multiple hosts that in turn will then send return traffic to the hosts with the IP addresses that were forged. This can generate significant amounts of traffic. Therefore, protection measures to counteract IP source address spoofing must be taken. 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; thereby mitigating IP source address spoofing.","checkContent":"This requirement is not applicable for the DoDIN Backbone.\n\nReview the router configuration to verify uRPF or an egress filter has been configured on all internal interfaces to restrict the router from accepting outbound IP packets that contain an illegitimate address in the source address field.\n\ninterfaces {\n ge-0/1/0 {\n description \"LAN link\";\n unit 0 {\n family inet {\n rpf-check;\n\nIf 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.","fixText":"This requirement is not applicable for the DoDIN Backbone.\n\nConfigure the router to ensure that an egress filter or uRPF is configured on internal interfaces to restrict the router from accepting any outbound IP packet that contains an illegitimate address in the source field. The example below enables uRPF.\n\n[edit interfaces ge-0/1/0 unit 0 family inet]\nset rpf-check","ccis":["CCI-001094"]},{"vulnId":"V-217037","ruleId":"SV-217037r604135_rule","severity":"medium","ruleTitle":"The Juniper perimeter router must be configured to filter traffic destined to the enclave in accordance with the guidelines contained in DoD Instruction 8551.1.","description":"Vulnerability assessments must be reviewed by the System Administrator, and protocols must be approved by the Information Assurance (IA) staff before entering the enclave.\n\nAccess control lists (ACLs) are the first line of defense in a layered security approach. They permit authorized packets and deny unauthorized packets based on port or service type. They enhance the posture of the network by not allowing packets to reach a potential target within the security domain. The lists provided are highly susceptible ports and services that should be blocked or limited as much as possible without adversely affecting customer requirements. Auditing packets attempting to penetrate the network but that are stopped by an ACL will allow network administrators to broaden their protective ring and more tightly define the scope of operation.\n\nIf the perimeter is in a Deny-by-Default posture and what is allowed through the filter is in accordance with DoD Instruction 8551.1, and if the permit rule is explicitly defined with explicit ports and protocols allowed, then all requirements related to PPS being blocked would be satisfied.","checkContent":"This requirement is not applicable for the DoDIN Backbone.\n\nReview the router configuration to verify that the ingress filter is in accordance with DoD 8551.\n\nVerify that an inbound filter is configured on all external interfaces.\n\ninterfaces {\n ge-0/0/0 {\n unit 0 {\n family inet {\n filter {\n input INBOUND_FILTER;\n }\n address 11.1.12.2/24;\n }\n }\n }\n\nReview the inbound filter to verify that it is filtering traffic in accordance with DoD 8551.\n\nfirewall {\n family inet {\n filter INBOUND_FILTER {\n term ALLOW_ABC {\n from {\n protocol tcp;\n destination-port abc;\n }\n then accept;\n }\n term ALLOW_XYZ {\n from {\n protocol xyz;\n }\n then accept;\n }\n term DENY_ALL_OTHER {\n then {\n syslog;\n reject;\n }\n }\n }\n}\n\nIf the router does not filter traffic in accordance with the guidelines contained in DoD 8551, this is a finding.","fixText":"This requirement is not applicable for the DoDIN Backbone.\n\nConfigure the router to use an inbound filter on all external interfaces as shown in the example below to restrict traffic in accordance with the guidelines contained in DOD Instruction 8551.1.\n\nset filter INBOUND_FILTER term ALLOW_ABC from protocol tcp destination-port abc\nset filter INBOUND_FILTER term ALLOW_ABC then accept\nset filter INBOUND_FILTER term ALLOW_XYZ from protocol tcp destination-port xyz\nset filter INBOUND_FILTER term ALLOW_XYZ then accept\nset filter INBOUND_FILTER term DENY_ALL_OTHER then syslog reject\n\n[edit interfaces ge-0/0/0 unit 0 family inet]\nset filter input INBOUND_FILTER","ccis":["CCI-001097"]},{"vulnId":"V-217038","ruleId":"SV-217038r604135_rule","severity":"medium","ruleTitle":"The Juniper perimeter router must be configured to filter ingress traffic at the external interface on an inbound direction.","description":"Access lists are used to separate data traffic into that which it will route (permitted packets) and that which it will not route (denied packets). Secure configuration of routers makes use of access lists for restricting access to services on the router itself as well as for filtering traffic passing through the router. \n\nInbound versus Outbound: It should be noted that some operating systems default access lists are applied to the outbound queue. The more secure solution is to apply the access list to the inbound queue for three reasons:\n\n- The router can protect itself before damage is inflicted.\n- The input port is still known and can be filtered upon.\n- It is more efficient to filter packets before routing them.","checkContent":"This requirement is not applicable for the DoDIN Backbone.\n\nReview the router configuration to verify that an inbound filter is configured on all external interfaces as shown in the example below.\n\ninterfaces {\n description \"NIPRNet\";\n ge-0/0/0 {\n unit 0 {\n family inet {\n filter {\n input INBOUND_FILTER;\n }\n address x.x.x.x/24;\n }\n }\n }\n\nIf the router is not configured to filter traffic entering the network at all external interfaces in an inbound direction, this is a finding.","fixText":"This requirement is not applicable for the DoDIN Backbone.\n\nConfigure the router to use an inbound filter on all external interfaces as shown in the example below.\n\n[edit interfaces ge-0/0/0 unit 0 family inet]\nset filter input INBOUND_FILTER","ccis":["CCI-001097"]},{"vulnId":"V-217039","ruleId":"SV-217039r604135_rule","severity":"medium","ruleTitle":"The Juniper perimeter router must be configured to filter egress traffic at the internal interface on an inbound direction.","description":"Access lists are used to separate data traffic into that which it will route (permitted packets) and that which it will not route (denied packets). Secure configuration of routers makes use of access lists for restricting access to services on the router itself as well as for filtering traffic passing through the router. \n\nInbound versus Outbound: It should be noted that some operating systems default access lists are applied to the outbound queue. The more secure solution is to apply the access list to the inbound queue for three reasons:\n\n- The router can protect itself before damage is inflicted.\n- The input port is still known and can be filtered upon.\n- It is more efficient to filter packets before routing them.","checkContent":"This requirement is not applicable for the DoDIN Backbone.\n\nReview the router configuration to verify that the egress ACL is bound to the internal interface in an inbound direction.\n\ninterfaces {\n ge-0/1/0 {\n description \"LAN link\";\n unit 0 {\n family inet {\n filter {\n input OUTBOUND_FILTER;\n }\n address x.x.x.x/24;\n }\n }\n }\n\nIf the router is not configured to filter traffic leaving the network at the internal interface in an inbound direction, this is a finding.","fixText":"This requirement is not applicable for the DoDIN Backbone.\n\nConfigure the router to use an inbound filter on all internal interfaces as shown in the example below.\n\n[edit interfaces ge-0/1/0 unit 0 family inet]\nset filter input OUTBOUND_FILTER","ccis":["CCI-001097"]},{"vulnId":"V-217040","ruleId":"SV-217040r945859_rule","severity":"medium","ruleTitle":"The Juniper perimeter router must be configured to block all packets with any IP options.","description":"Packets with IP options are not fast switched and henceforth must be punted to the router processor. Hackers who initiate denial-of-service (DoS) attacks on routers commonly send large streams of packets with IP options. Dropping the packets with IP options reduces the load of IP options packets on the router. The end result is a reduction in the effects of the DoS attack on the router and on downstream routers.","checkContent":"This requirement is not applicable for the DoDIN Backbone.\n\nReview the router configuration to determine if it will block all packets with IP options.\n\nfirewall {\n family inet {\n filter INBOUND_FILTER {\n term DROP_IPOPTIONS {\n from {\n ip-options any;\n }\n then {\n syslog;\n discard;\n }\n }\n term BLOCK_BOGONS {\n from {\n source-prefix-list {\n BOGON_PREFIXES;\n }\n }\n then {\n syslog;\n discard;\n }\n }\n term ALLOW_ABC {\n …\n …\n …\n term DENY_ALL_OTHER {\n then {\n log;\n syslog;\n reject;\n }\n }\n }\n\nIf the router is not configured to drop all packets with IP options, this is a finding.","fixText":"This requirement is not applicable for the DoDIN Backbone.\n\nConfigure the router to drop all packets with IP options.\n\n[edit firewall family inet filter INBOUND_FILTER]\nset term DROP_IPOPTIONS from ip-options any\nset term DROP_IPOPTIONS then discard\ninsert term DROP_IPOPTIONS before term BLOCK_BOGONS","ccis":["CCI-002403"]},{"vulnId":"V-217041","ruleId":"SV-217041r855896_rule","severity":"low","ruleTitle":"The Juniper perimeter router must be configured to have Link Layer Discovery Protocol (LLDP) disabled on all external interfaces.","description":"LLDPs are primarily used to obtain protocol addresses of neighboring devices and discover platform capabilities of those devices. Use of SNMP with the LLDP Management Information Base (MIB) allows network management applications to learn the device type and the SNMP agent address of neighboring devices, thereby enabling the application to send SNMP queries to those devices. LLDPs are also media- and protocol-independent as they run over the data link layer; therefore, two systems that support different network-layer protocols can still learn about each other. Allowing LLDP messages to reach external network nodes is dangerous as it provides an attacker a method to obtain information of the network infrastructure that can be useful to plan an attack.","checkContent":"This requirement is not applicable for the DoDIN Backbone.\n\nReview all router configurations to ensure LLDP is not enabled external interface. \n\nprotocols {\n …\n …\n …\n lldp {\n advertisement-interval 30;\n interface all;\n }\n}\n\nIf LLDP is configured globally or on any external interface, this is a finding.","fixText":"This requirement is not applicable for the DoDIN Backbone.\n\nDisable LLDP on all external interfaces. If necessary, remove the interface all parameter and define all internal interfaces as shown in the example below.\n\n[edit protocols lldp]\ndelete interface all\nset interface ge-0/1/0\nset interface ge-0/1/1","ccis":["CCI-002403"]},{"vulnId":"V-217042","ruleId":"SV-217042r855897_rule","severity":"medium","ruleTitle":"The Juniper perimeter router must be configured to have Proxy ARP disabled on all external interfaces.","description":"When Proxy ARP is enabled on a router, it allows that router to extend the network (at Layer 2) across multiple interfaces (LAN segments). Because proxy ARP allows hosts from different LAN segments to look like they are on the same segment, proxy ARP is only safe when used between trusted LAN segments. Attackers can leverage the trusting nature of proxy ARP by spoofing a trusted host and then intercepting packets. Proxy ARP should always be disabled on router interfaces that do not require it, unless the router is being used as a LAN bridge.","checkContent":"Review the router configuration to determine if IP Proxy ARP is disabled on all external interfaces.\n\ninterfaces {\n description \"NIPRNet\";\n ge-0/0/0 {\n unit 0 {\n proxy-arp restricted;\n family inet {\n\nIf IP Proxy ARP is enabled on any external interface, this is a finding.","fixText":"This requirement is not applicable for the DoDIN Backbone.\n\nDisable Proxy ARP on all external interfaces as shown in the example below.\n\n[edit interfaces em0 unit 0]\ndelete proxy-arp restricted","ccis":["CCI-002403"]},{"vulnId":"V-217043","ruleId":"SV-217043r1050852_rule","severity":"medium","ruleTitle":"The Juniper perimeter router must be configured to block all outbound management traffic.","description":"For in-band management, the management network must have its own subnet to enforce control and access boundaries provided by Layer 3 network nodes, such as routers and firewalls. Management traffic between the managed network elements and the management network is routed via the same links and nodes as that used for production or operational traffic. Safeguards must be implemented to ensure that the management traffic does not leak past the perimeter of the managed network.","checkContent":"This requirement is not applicable for the DODIN backbone.\n\nThe perimeter router of the managed network must be configured with an outbound filter on the egress interface to block all management traffic as shown in the example below.\n\nVerify that the router has been configured with an outbound filter as shown in the example below.\n\ninterfaces {\n description \"NIPRNet\";\n ge-0/0/0 {\n unit 0 {\n family inet {\n no-redirects;\n filter {\n output OUTBOUND_FILTER;\n }\n address 10.1.12.2/24;\n }\n }\n }\n\nVerify that the outbound filter discards or rejects management traffic as shown in the example below.\n\nfirewall {\n family inet {\n …\n …\n …\n }\n filter OUTBOUND_FILTER {\n term BLOCK_TACACS {\n from {\n protocol tcp;\n port tacacs;\n }\n then {\n syslog;\n discard;\n }\n }\n term BLOCK_SNMP {\n from {\n protocol udp;\n port [ snmp snmptrap ];\n }\n then {\n syslog;\n discard;\n }\n }\n term BLOCK_NETFLOW {\n from {\n protocol udp;\n port [ 2055 9995 9996 ];\n }\n then {\n syslog;\n discard;\n } \n }\n term ALLOW_OTHER {\n then accept;\n }\n }\n }\n\nIf management traffic is not blocked at the perimeter, this is a finding.","fixText":"This requirement is not applicable for the DODIN backbone.\n\nConfigure the perimeter router of the managed network with an outbound filter on the egress interface to block all management traffic.\n\nConfigure a filter to block egress management traffic.\n\n[edit firewall family inet]\nSet filter OUTBOUND_FILTER term BLOCK_TACACS from protocol tcp port tacacs\nSet filter OUTBOUND_FILTER term BLOCK_TACACS then syslog discard\nSet filter OUTBOUND_FILTER term BLOCK_SNMP from protocol udp port [snmp snmptrap]\nSet filter OUTBOUND_FILTER term BLOCK_SNMP then syslog discard\nset filter OUTBOUND_FILTER term BLOCK_NETFLOW from protocol udp port [2055 9995 9996]\nset filter OUTBOUND_FILTER term BLOCK_NETFLOW then syslog discard \n\nConfigure the external interfaces with the outbound filter.\n\n[edit interfaces ge-0/0/0 unit 0 family inet]\nset filter output OUTBOUND_FILTER","ccis":["CCI-001097"]},{"vulnId":"V-217044","ruleId":"SV-217044r1050855_rule","severity":"medium","ruleTitle":"The Juniper out-of-band management (OOBM) gateway router must be configured to transport management traffic to the Network Operations Center (NOC) via dedicated circuit, MPLS/VPN service, or IPsec tunnel.","description":"Using dedicated paths, the OOBM backbone connects the OOBM gateway routers located at the edge of the managed network and at the NOC. Dedicated links can be deployed using provisioned circuits or MPLS Layer 2 and Layer 3 VPN services or implementing a secured path with gateway-to-gateway IPsec tunnels. The tunnel mode ensures that the management traffic will be logically separated from any other traffic traversing the same path.","checkContent":"This requirement is not applicable for the DODIN backbone.\n\nReview the network topology diagram to determine connectivity between the managed network and the NOC. Review the OOBM gateway router configuration to validate the path and interface that the management traffic traverses. If an IPsec tunnel is used to transport the management traffic between the NOC and the managed network, review the configuration following the steps below.\n\nReview the security association within the IPsec configuration to be used for encapsulating the management traffic and verify that it is in tunnel mode. Also note the security association to be used.\n\nsecurity {\n ipsec {\n proposal IPSEC_PHASE2_PROPOSAL {\n protocol esp;\n authentication-algorithm hmac-sha1-96;\n encryption-algorithm aes-128-cbc;\n }\n policy IPSEC_POLICY {\n perfect-forward-secrecy {\n keys group14;\n }\n proposals IPSEC_PHASE2_PROPOSAL;\n }\n security-association IPSEC-SA_XYZ {\n description \"For XYZ\";\n mode transport;\n manual {\n direction bidirectional {\n protocol ah;\n spi 256;\n authentication {\n algorithm hmac-sha1-96;\n key ascii-text \"$8$oPJjH.P5F69mSHqPQn6u0RhSreW-dsZGi8XYoZDmP\"; ## SECRET-DATA\n }\n }\n }\n }\n security-association IPSEC_SA_MGMT {\n description \"IPsec Tunnel for Mgmt Traffic\";\n mode tunnel;\n dynamic {\n ipsec-policy IPSEC_POLICY;\n }\n }\n }\n ike {\n proposal IKE_PHASE1_PROPOSAL {\n authentication-method pre-shared-keys;\n dh-group group14;\n authentication-algorithm sha-256;\n encryption-algorithm aes-256-cbc;\n }\n policy 10.1.25.2 {\n mode main;\n proposals IKE_PHASE1_PROPOSAL;\n pre-shared-key ascii-text \"$8$J4UDkCA01IcHqEy\"; ## SECRET-DATA\n }\n }\n\nVerify there is a filter to direct the management traffic to the IPsec tunnel by verifying the name of the IPsec SA referenced in the then statement as shown in the example below.\n\nfirewall {\n family inet {\n …\n …\n …\n filter MGMT_TRAFFIC {\n term ALLOW_SNMP {\n from {\n protocol udp;\n port [ snmp snmptrap ];\n }\n then ipsec-sa IPSEC_SA_MGMT;\n }\n term ALLOW_TACACS {\n from {\n protocol tcp;\n port tacacs;\n }\n then ipsec-sa IPSEC_SA_MGMT;\n }\n term ALLOW_NETFLOW {\n from {\n protocol udp;\n port [ 2055 9995 9996 ];\n }\n then ipsec-sa IPSEC_SA_MGMT;\n }\n term OTHER {\n then accept;\n }\n }\n }\n\nIf management traffic is not transported between the managed network and the NOC via dedicated circuit, MPLS/VPN service, or IPsec tunnel, this is a finding.","fixText":"This requirement is not applicable for the DODIN backbone.\n\nEnsure that a dedicated circuit, MPLS/VPN service, or IPsec tunnel is deployed to transport management traffic between the managed network and the NOC. If an IPsec tunnel is to be used, the steps below can be used as a guideline.\n\nConfigure an IPsec tunnel using commands similar to the example below.\n\n[edit security]\nset ike proposal IKE_PHASE1_PROPOSAL authentication-method pre-shared-keys\nset ike proposal IKE_PHASE1_PROPOSAL authentication-algorithm sha-256\nset ike proposal IKE_PHASE1_PROPOSAL dh-group group14\nset ike proposal IKE_PHASE1_PROPOSAL encryption-algorithm aes-256-cbc\nset ike policy 10.1.25.2 proposals IKE_PHASE1_PROPOSAL\nset ike policy 10.1.25.2 mode main\nset ike policy 10.1.25.2 pre-shared-key ascii-text xxxxxxxxx\nset ipsec proposal IPSEC_PHASE2_PROPOSAL protocol esp\nset ipsec proposal IPSEC_PHASE2_PROPOSAL authentication-algorithm hmac-sha1-96\nset ipsec proposal IPSEC_PHASE2_PROPOSAL encryption-algorithm aes-256-cbc\nset ipsec security-association IPSEC_SA_MGMT mode tunnel\nset ipsec security-association IPSEC_SA_MGMT dynamic ipsec-policy IPSEC_POLICY\n\nConfigure a filter to define the management traffic to be forwarded into the IPsec tunnel.\n\n[edit firewall family inet]\nset filter MGMT_TRAFFIC term ALLOW_SNMP from protocol udp port [snmp snmptrap]\nset filter MGMT_TRAFFIC term ALLOW_SNMP then ipsec-sa IPSEC_SA_MGMT\nset filter MGMT_TRAFFIC term ALLOW_TACACS from protocol tcp port tacacs\nset filter MGMT_TRAFFIC term ALLOW_TACACS then ipsec-sa IPSEC_SA_MGMT\nset filter MGMT_TRAFFIC term ALLOW_NETFLOW from protocol udp port [2055 9995 9996]\nset filter MGMT_TRAFFIC term ALLOW_NETFLOW then ipsec-sa IPSEC_SA_MGMT\nset filter MGMT_TRAFFIC term OTHER then accept","ccis":["CCI-001097","CCI-004891"]},{"vulnId":"V-217045","ruleId":"SV-217045r604135_rule","severity":"medium","ruleTitle":"The Juniper out-of-band management (OOBM) gateway router must be configured to forward only authorized management traffic to the Network Operations Center (NOC).","description":"The OOBM network is an IP network used exclusively for the transport of OAM&P data from the network being managed to the OSS components located at the NOC. Its design provides connectivity to each managed network device, enabling network management traffic to flow between the managed network elements and the NOC. This allows the use of paths separate from those used by the managed network.","checkContent":"This requirement is not applicable for the DoDIN Backbone.\n\nReview the network topology diagram to determine connectivity between the managed network and the NOC. Review the OOBM gateway router configuration to validate the path that the management traffic traverses. Verify that only management traffic is forwarded through the OOBM interface or IPsec tunnel.\n\nIf an OOBM link is used, verify that the only authorized management traffic is transported to the NOC by reviewing the outbound filter applied to the OOBM interface as shown in the example below.\n\ninterfaces {\n description \"OOBM Net\";\n ge-1/1/0 {\n unit 0 {\n family inet {\n filter {\n output MGMT_TRAFFIC;\n }\n address 10.2.22.2/24;\n }\n }\n }\n…\n…\n…\nfirewall {\n family inet {\n …\n …\n …\n filter MGMT_TRAFFIC {\n term ALLOW_SNMP {\n from {\n protocol udp;\n port [ snmp snmptrap ];\n }\n then accept;\n }\n term ALLOW_TACACS {\n from {\n protocol tcp;\n port tacacs;\n }\n then accept;\n }\n term ALLOW_NETFLOW {\n from {\n protocol udp;\n port [ 2055 9995 9996 ];\n }\n then accept;\n }\n term DENY_OTHER {\n then {\n syslog;\n discard;\n }\n }\n }\n }\n\nIf an IPsec tunnel is used, verify that the only authorized management traffic is transported to the NOC by reviewing the filter referencing the applicable security association as shown int example below.\n\nfirewall {\n family inet {\n …\n …\n …\n filter MGMT_TRAFFIC {\n term ALLOW_SNMP {\n from {\n protocol udp;\n port [ snmp snmptrap ];\n }\n then ipsec-sa IPSEC_SA_MGMT;\n }\n term ALLOW_TACACS {\n from {\n protocol tcp;\n port tacacs;\n }\n then ipsec-sa IPSEC_SA_MGMT;\n }\n term ALLOW_NETFLOW {\n from {\n protocol udp;\n port [ 2055 9995 9996 ];\n }\n then ipsec-sa IPSEC_SA_MGMT;\n }\n term OTHER {\n then accept;\n }\n }\n }\n\nIf traffic other than authorized management traffic is permitted through the OOBM interface or IPsec tunnel, this is a finding.","fixText":"This requirement is not applicable for the DoDIN Backbone.\n\nConfigure filters to permit only authorized management traffic into IPsec tunnels or the OOBM interface used for forwarding management data as shown in the examples below.\n\nOOBM Link\n[edit firewall family inet]\nset filter MGMT_TRAFFIC term ALLOW_SNMP from protocol udp port [snmp snmptrap]\nset filter MGMT_TRAFFIC term ALLOW_SNMP then accept\nset filter MGMT_TRAFFIC term ALLOW_TACACS from protocol tcp port tacacs\nset filter MGMT_TRAFFIC term ALLOW_TACACS then accept\nset filter MGMT_TRAFFIC term ALLOW_NETFLOW from protocol udp port [2055 9995 9996]\nset filter MGMT_TRAFFIC term ALLOW_NETFLOW then accept\nset filter MGMT_TRAFFIC term DENY_OTHER then syslog discard\n\n[edit interfaces ge-1/1/0 unit 0 family inet]\nset filter output MGMT_TRAFFIC\n\nIPsec Tunnel\n[edit firewall family inet]\nset filter MGMT_TRAFFIC term ALLOW_SNMP from protocol udp port [snmp snmptrap]\nset filter MGMT_TRAFFIC term ALLOW_SNMP then ipsec-sa IPSEC_SA_MGMT\nset filter MGMT_TRAFFIC term ALLOW_TACACS from protocol tcp port tacacs\nset filter MGMT_TRAFFIC term ALLOW_TACACS then ipsec-sa IPSEC_SA_MGMT\nset filter MGMT_TRAFFIC term ALLOW_NETFLOW from protocol udp port [2055 9995 9996]\nset filter MGMT_TRAFFIC term ALLOW_NETFLOW then ipsec-sa IPSEC_SA_MGMT\nset filter MGMT_TRAFFIC term OTHER then accept","ccis":["CCI-001097"]},{"vulnId":"V-217046","ruleId":"SV-217046r604135_rule","severity":"medium","ruleTitle":"The Juniper out-of-band management (OOBM) gateway router must be configured to have separate IGP instances for the managed network and management network.","description":"If the gateway router is not a dedicated device for the OOBM 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.","checkContent":"This requirement is not applicable for the DoDIN Backbone.\n\nVerify that the OOBM interface is an adjacency in the IGP domain for the management network via separate VRF as shown in the example below.\n\n}\nprotocols {\n ospf {\n area 0.0.0.0 {\n interface ge-2/0/0;\n interface ge-2/1/0;\n }\n }\n}\nrouting-instances {\n VRF_MGMT {\n instance-type vrf;\n interface ge-1/0/0;\n interface ge-1/1/0;\n route-distinguisher 10.1.12.0:12;\n vrf-target {\n import target:1234:4567;\n export target:1234:4567;\n }\n routing-options {\n router-id 11.11.11.11;\n }\n protocols {\n ospf {\n area 0.0.0.0 {\n interface ge-1/0/0;\n interface ge-1/1/0;\n }\n }\n }\n }\n}\n\nIf the router is not configured to have separate IGP instances for the managed network and management network, this is a finding.","fixText":"This requirement is not applicable for the DoDIN Backbone.\n\nConfigure the router to have a separate IGP instance for the management network as shown in the example below.\n\n[edit routing-instances]\nset VRF_MGMT instance-type vrf\nset VRF_MGMT route-distinguisher 10.1.12.0:12\nset VRF_MGMT vrf-target import target:1234:4567\nset VRF_MGMT vrf-target export target:1234:4567\nset VRF_MGMT interface ge-1/0/0\nset VRF_MGMT interface ge-1/1/0\nset VRF_MGMT protocols ospf area 0.0.0.0 interface ge-1/0/0\nset VRF_MGMT protocols ospf area 0.0.0.0 interface ge-1/1/0\nset VRF_MGMT routing-options router-id 11.11.11.11","ccis":["CCI-001414"]},{"vulnId":"V-217047","ruleId":"SV-217047r604135_rule","severity":"medium","ruleTitle":"The Juniper out-of-band management (OOBM) gateway router must be configured to not redistribute routes between the management network routing domain and the managed network routing domain.","description":"If the gateway router is not a dedicated device for the OOBM 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.\n\nSince 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 OOBM network. In addition, the routes from the two domains must not be redistributed to each other.","checkContent":"This requirement is not applicable for the DoDIN Backbone.\n\nVerify the Interior Gateway Protocol (IGP) instance used for the managed network does not redistribute routes into the IGP instance used for the management network, and vice versa. The example below imports routes from the global route table (inet.0) in the route table for the management VRF.\n\n}\nrouting-options {\n interface-routes {\n rib-group inet INET0_GROUP;\n }\n rib-groups {\n INET0_GROUP {\n import-rib [ VRF_MGMT.inet.0 inet.0 ];\n }\n }\n}\n\nIf the IGP instance used for the managed network redistributes routes into the IGP instance used for the management network, or vice versa, this is a finding.","fixText":"This requirement is not applicable for the DoDIN Backbone.\n\nRemove the configuration that imports routes from the management network into the managed network or vice versa as shown in the example below.\n\n[edit routing-options]\ndelete rib-groups INET0_GROUP\ndelete interface-routes rib-group inet INET0_GROUP","ccis":["CCI-001414"]},{"vulnId":"V-217048","ruleId":"SV-217048r604135_rule","severity":"medium","ruleTitle":"The Juniper out-of-band management (OOBM) gateway router must be configured to block any traffic destined to itself that is not sourced from the OOBM network or the NOC.","description":"If the gateway router is not a dedicated device for the OOBM network, several safeguards must be implemented for containment of management and production traffic boundaries. It is imperative that hosts from the managed network are not able to access the OOBM gateway router.","checkContent":"This requirement is not applicable for the DoDIN Backbone.\n\nReview the firewall filter applied to the routers loopback interface to verify that only traffic sourced from the OOBM network or the NOC is allowed to access the router as shown in the example below.\n\ninterfaces {\n…\n…\n…\n lo0 {\n unit 0 {\n family inet {\n filter {\n input PROTECT_RE;\n }\n address 1.1.1.1/32;\n }\n }\n }\n}\n…\n…\n…\nfirewall {\n family inet {\n filter PROTECT_RE {\n term RESTRICT_ADDRESS {\n from {\n source-address {\n 0.0.0.0/0;\n 10.2.14.0/24 except;\n }\n }\n then {\n syslog;\n discard;\n }\n }\n term ALLOW_OTHER {\n then accept;\n }\n }\n }\n}\n\nIf the router does not block any traffic destined to itself that is not sourced from the OOBM network or the NOC, this is a finding.","fixText":"This requirement is not applicable for the DoDIN Backbone.\n\nConfigure the router to only allow traffic to the Routing Engine from the OOBM network.\n\n[edit firewall family inet]\nset filter PROTECT_RP term RESTRICT_ADDRESS from source-address 0.0.0.0/0\nset filter PROTECT_RP term RESTRICT_ADDRESS from source-address 10.2.14.0/24 except\nset filter PROTECT_RP term RESTRICT_ADDRESS then syslog discard \nset filter PROTECT_RP term ALLOW_OTHER then accept \n\n[edit interfaces lo0 unit 0 family inet]\nset filter input PROTECT_RP","ccis":["CCI-001097"]},{"vulnId":"V-217049","ruleId":"SV-217049r604135_rule","severity":"medium","ruleTitle":"The Juniper router must be configured to only permit management traffic that ingresses and egresses the OOBM interface.","description":"The OOBM access switch will connect to the management interface of the managed network elements. The management interface can be a true OOBM interface or a standard interface functioning as the management interface. In either case, the management interface of the managed network element will be directly connected to the OOBM network.\n\nAn OOBM 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 OOBM port, the interface functioning as the management interface must be configured so that management traffic does not leak into the managed network and that production traffic does not leak into the management network.","checkContent":"Verify that the managed interface has an inbound and outbound filter configured. \n\ninterfaces {\n …\n …\n …\n ge-0/0/0 {\n description \"OOBM Network\";\n unit 0 {\n family inet {\n filter {\n input OOBM_INBOUND;\n output OOBM_OUTBOUND;\n }\n address 10.2.14.1/24;\n }\n }\n }\n\nVerify that the ingress filter only allows management and ICMP traffic. \n\nfirewall {\n family inet {\n …\n …\n …\n filter OOBM_INBOUND {\n term ALLOW_SNMP {\n from {\n protocol udp;\n port snmp;\n }\n then accept;\n }\n term ALLOW_TACACS {\n from {\n protocol tcp;\n port tacacs;\n }\n then accept;\n }\n term ALLOW_ICMP {\n from {\n protocol icmp;\n }\n then accept;\n }\n term ALLOW_SSH {\n from {\n protocol tcp;\n port ssh;\n }\n then accept;\n }\n term ALLOW_NTP {\n from {\n protocol tcp;\n port ntp;\n }\n then accept;\n }\n term DENY_OTHER {\n then {\n syslog;\n discard;\n }\n }\n }\n }\n}\n\nVerify that the ingress filter only allows management and ICMP traffic. \n\nfirewall {\n family inet {\n …\n …\n …\n filter OOBM_OUTBOUND {\n term ALLOW_SNMP {\n from {\n protocol udp;\n port [ snmp snmptrap ];\n }\n then accept;\n }\n term ALLOW_TACACS {\n from {\n protocol tcp;\n port tacacs;\n }\n then accept;\n }\n term ALLOW_SSH {\n from {\n protocol tcp;\n port ssh;\n }\n then accept;\n }\n term ALLOW_NTP {\n from {\n protocol udp;\n port ntp;\n }\n then accept;\n }\n term ALLOW_SYSLOG {\n from {\n protocol udp;\n port syslog;\n }\n then accept;\n }\n term ALLOW_NETFLOW {\n from {\n protocol udp;\n port [ 2055 9995 9996 ];\n }\n then accept;\n }\n term DENY_OTHER {\n then {\n syslog;\n discard;\n }\n }\n }\n }\n}\n\nCaveat: If the management interface is a true OOBM interface, this requirement is not applicable.\n\nIf the router does not restrict traffic that ingresses and egresses the management interface, this is a finding.","fixText":"If the management interface is not a dedicated OOBM interface, it must be configured with both an ingress and egress filter.\n\nConfigure an inbound filter a shown in the example below.\n\n[edit firewall family inet]\nset filter OOBM_INBOUND term ALLOW_SNMP from protocol udp port snmp\nset filter OOBM_INBOUND term ALLOW_SNMP then accept\nset filter OOBM_INBOUND term ALLOW_TACACS from protocol tcp port tacacs\nset filter OOBM_INBOUND term ALLOW_TACACS then accept\nset filter OOBM_INBOUND term ALLOW_SSH from protocol tcp port ssh\nset filter OOBM_INBOUND term ALLOW_SSH then accept\nset filter OOBM_INBOUND term ALLOW_NTP from protocol udp port ntp\nset filter OOBM_INBOUND term ALLOW_NTP then accept\nset filter OOBM_INBOUND term ALLOW_ICMP from protocol icmp\nset filter OOBM_INBOUND term ALLOW_ICMP then accept\nset filter OOBM_INBOUND term DENY_OTHER then syslog discard\n\nConfigure an outbound filter a shown in the example below.\n\nset filter OOBM_OUTBOUND term ALLOW_SNMP from protocol udp port [snmp snmptrap]\nset filter OOBM_OUTBOUND term ALLOW_SNMP then accept\nset filter OOBM_OUTBOUND term ALLOW_TACACS from protocol tcp port tacacs\nset filter OOBM_OUTBOUND term ALLOW_TACACS then accept\nset filter OOBM_OUTBOUND term ALLOW_SSH from protocol tcp port ssh\nset filter OOBM_OUTBOUND term ALLOW_SSH then accept\nset filter OOBM_OUTBOUND term ALLOW_NTP from protocol udp port ntp\nset filter OOBM_OUTBOUND term ALLOW_NTP then accept\nset filter OOBM_OUTBOUND term ALLOW_SYSLOG from protocol udp port \nset filter OOBM_OUTBOUND term ALLOW_SYSLOG then accept\nset filter OOBM_OUTBOUND term ALLOW_NETFLOW from protocol udp port [2055 9995 9996]\nset filter OOBM_OUTBOUND term ALLOW_NETFLOW then accept\nset filter OOBM_OUTBOUND term DENY_OTHER then syslog discard\n\nApply the filters to the OOBM interfaces.\n\n[edit interfaces ge-0/0/0 unit 0 family inet]\nset filter input OOBM_INBOUND\nset filter output OOBM_OUTBOUND","ccis":["CCI-001097"]},{"vulnId":"V-217050","ruleId":"SV-217050r604135_rule","severity":"medium","ruleTitle":"The Juniper router providing connectivity to the NOC must be configured to forward all in-band management traffic via an IPsec tunnel.","description":"When the production network is managed in-band, the management network could be housed at a NOC that is located remotely at single or multiple interconnected sites. NOC interconnectivity, as well as connectivity between the NOC and the managed network, must be enabled using IPsec tunnels to provide the separation and integrity of the managed traffic.","checkContent":"This requirement is not applicable for the DoDIN Backbone.\n\nVerify that all traffic from the managed network to the management network and vice-versa is secured via IPsec tunnel.\n\nReview the security association within the IPsec configuration to be used for encapsulating the management traffic and verify that it is in tunnel mode. Also note the security association to be used.\n\nsecurity {\n ipsec {\n proposal IPSEC_PHASE2_PROPOSAL {\n protocol esp;\n authentication-algorithm hmac-sha1-96;\n encryption-algorithm aes-128-cbc;\n }\n policy IPSEC_POLICY {\n perfect-forward-secrecy {\n keys group14;\n }\n proposals IPSEC_PHASE2_PROPOSAL;\n }\n security-association IPSEC-SA_XYZ {\n description \"For XYZ\";\n mode transport;\n manual {\n direction bidirectional {\n protocol ah;\n spi 256;\n authentication {\n algorithm hmac-sha1-96;\n key ascii-text \"$8$oPJjH.P5F69mSHqPQn6u0RhSreW-dsZGi8XYoZDmP\"; ## SECRET-DATA\n }\n }\n }\n }\n security-association IPSEC_SA_MGMT {\n description \"IPsec Tunnel for Mgmt Traffic\";\n mode tunnel;\n dynamic {\n ipsec-policy IPSEC_POLICY;\n }\n }\n }\n ike {\n proposal IKE_PHASE1_PROPOSAL {\n authentication-method pre-shared-keys;\n dh-group group14;\n authentication-algorithm sha-256;\n encryption-algorithm aes-128-cbc;\n }\n policy 10.1.25.2 {\n mode main;\n proposals IKE_PHASE1_PROPOSAL;\n pre-shared-key ascii-text \"$8$J4UDkCA01IcHqEy\"; ## SECRET-DATA\n }\n }\n\nVerify there is a filter to direct the management traffic to the IPsec tunnel by verifying the name of the IPsec SA referenced in the then statement as shown in the example below.\n\nfirewall {\n family inet {\n …\n …\n …\n filter MGMT_TRAFFIC {\n term ALLOW_SNMP {\n from {\n protocol udp;\n port [ snmp snmptrap ];\n }\n then ipsec-sa IPSEC_SA_MGMT;\n }\n term ALLOW_TACACS {\n from {\n protocol tcp;\n port tacacs;\n }\n then ipsec-sa IPSEC_SA_MGMT;\n }\n term ALLOW_NETFLOW {\n from {\n protocol udp;\n port [ 2055 9995 9996 ];\n }\n then ipsec-sa IPSEC_SA_MGMT;\n }\n term OTHER {\n then accept;\n }\n }\n }\n\nIf the management traffic is not secured via IPsec tunnel, this is a finding.","fixText":"This requirement is not applicable for the DoDIN Backbone.\n\nEnsure that all traffic from the managed network to the management network is secured via IPsec tunnel as shown in the configuration examples below.\n\nConfigure an IPsec tunnel to be used to transport the management traffic.\n\n[edit security]\nset ike proposal IKE_PHASE1_PROPOSAL authentication-method pre-shared-keys\nset ike proposal IKE_PHASE1_PROPOSAL authentication-algorithm sha-256\nset ike proposal IKE_PHASE1_PROPOSAL dh-group group14\nset ike proposal IKE_PHASE1_PROPOSAL encryption-algorithm aes-128-cbc\nset ike policy 10.1.25.2 proposals IKE_PHASE1_PROPOSAL\nset ike policy 10.1.25.2 mode main\nset ike policy 10.1.25.2 pre-shared-key ascii-text xxxxxxxxx\nset ipsec proposal IPSEC_PHASE2_PROPOSAL protocol esp\nset ipsec proposal IPSEC_PHASE2_PROPOSAL authentication-algorithm hmac-sha1-96\nset ipsec proposal IPSEC_PHASE2_PROPOSAL encryption-algorithm aes-128-cbc\nset policy IPSEC_POLICY perfect-forward-secrecy keys group14\nset policy IPSEC_POLICY proposals xxxxx\nset ipsec security-association IPSEC_SA_MGMT mode tunnel\nset ipsec security-association IPSEC_SA_MGMT dynamic ipsec-policy IPSEC_POLICY\n\nConfigure a filter that will select which traffic to be forwarded via the IPsec tunnel by specifying the security association bound to the tunnel.\n\n[edit firewall family inet]\nset filter MGMT_TRAFFIC term ALLOW_SNMP from protocol udp port [snmp snmptrap]\nset filter MGMT_TRAFFIC term ALLOW_SNMP then ipsec-sa IPSEC_SA_MGMT\nset filter MGMT_TRAFFIC term ALLOW_TACACS from protocol tcp port tacacs\nset filter MGMT_TRAFFIC term ALLOW_TACACS then ipsec-sa IPSEC_SA_MGMT\nset filter MGMT_TRAFFIC term ALLOW_NETFLOW from protocol udp port [2055 9995 9996]\nset filter MGMT_TRAFFIC term ALLOW_NETFLOW then ipsec-sa IPSEC_SA_MGMT\nset filter MGMT_TRAFFIC term OTHER then accept","ccis":["CCI-001097"]},{"vulnId":"V-217051","ruleId":"SV-217051r855898_rule","severity":"low","ruleTitle":"The Juniper BGP router must be configured to enable the Generalized TTL Security Mechanism (GTSM).","description":"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. \n\nGTSM 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.","checkContent":"Verify that a filter has been configured to only allow BGP packets with a TTL of 255 as shown in the example below.\n\nfirewall {\n …\n …\n …\n filter GTSM_FILTER {\n term TTL_SECURITY {\n from {\n protocol tcp;\n ttl-except 255;\n port bgp;\n }\n then {\n syslog;\n discard;\n }\n }\n term ELSE_ACCEPT {\n then accept;\n }\n }\n}\n\nVerify that the filter is applied to all interfaces connecting to eBGP peers.\n\ninterfaces {\n…\n…\n…\n ge-0/0/0 {\n unit 0 {\n family inet {\n filter {\n input-list [INBOUND_FILTER GTSM_FILTER];\n }\n address x.x.x.x/30;\n }\n }\n }\n}\n\nConfigure the router to send all BGP packets with a TTL of 255 as shown in the example below.\n\nIf the router is not configured to use GTSM for all Exterior Border Gateway Protocol peering sessions, this is a finding.","fixText":"Configure a filter to only accept bgp packets with a TTL of 255 as shown in the example below.\n\n[edit firewall]\nset filter GTSM_FILTER term TTL_SECURITY from protocol tcp port bgp ttl-except 255\nset filter GTSM_FILTER term TTL_SECURITY then syslog discard\nset filter GTSM_FILTER term ELSE_ACCEPT then accept\n\nApply the firewall filter to the inbound interface for all eBGP single-hop peer as shown in the example below.\n\n[edit interfaces ge-0/0/0 unit 0 family inet] \nset filter input-list INBOUND_FILTER\nset filter input-list GTSM_FILTER","ccis":["CCI-002385"]},{"vulnId":"V-217052","ruleId":"SV-217052r945862_rule","severity":"medium","ruleTitle":"The Juniper BGP router must be configured to use a unique key for each autonomous system (AS) that it peers with.","description":"If the same keys are used between eBGP neighbors, the chance of a hacker compromising any of the BGP sessions increases. It is possible that a malicious user exists in one autonomous system who would know the key used for the eBGP session. This user would then be able to hijack BGP sessions with other trusted neighbors.","checkContent":"Review the BGP configuration to determine if it is peering with multiple autonomous systems.\n\nInterview the ISSM and router administrator to determine if unique keys are being used. \n\nprotocols {\n bgp {\n group AS44 {\n type external;\n peer-as 44;\n neighbor x.x.x.x {\n authentication-key \"$8$tBga0ORx7VsYoIEgJ\"; ## SECRET-DATA\n }\n }\n group AS66 {\n type external;\n peer-as 66;\n neighbor x.x.x.x {\n authentication-key \"$8$Q4953nCrlMLX-9A7V\"; ## SECRET-DATA\n }\n }\n }\n\nIf unique keys are not being used, this is a finding.","fixText":"Configure the router to use unique keys for each AS that it peers with as shown in the example below.\n\n[edit protocols bgp]\nset group GROUP_AS66 authentication-key abc123\nset group GROUP_AS44 authentication-key xyz123","ccis":["CCI-000366","CCI-002205"]},{"vulnId":"V-217053","ruleId":"SV-217053r604135_rule","severity":"medium","ruleTitle":"The Juniper BGP router must be configured to reject inbound route advertisements for any Bogon prefixes.","description":"Accepting route advertisements for Bogon prefixes can result in the local autonomous system (AS) becoming a transit for malicious traffic as it will in turn advertise these prefixes to neighbor autonomous systems.","checkContent":"Review the router configuration to verify that it will reject BGP routes for any Bogon prefixes.\n\nVerify a prefix list has been configured containing the current Bogon prefixes as shown in the example below.\n\npolicy-options {\n prefix-list BOGON_PREFIXES {\n 0.0.0.0/8;\n 10.0.0.0/8;\n 100.64.0.0/10;\n 127.0.0.0/8;\n 169.254.0.0/16;\n 172.16.0.0/12;\n 192.0.0.0/24;\n 192.0.2.0/24;\n 192.168.0.0/16;\n 198.18.0.0/15;\n 198.51.100.0/24;\n 203.0.113.0/24;\n 224.0.0.0/4;\n 240.0.0.0/4;\n }\n}\n\nVerify that a policy has been configured to reject the Bogon prefixes.\n\npolicy-options {\n …\n …\n …\n policy-statement FILTER_ROUTES {\n term REJECT_BOGONS {\n from {\n prefix-list BOGON_PREFIXES;\n }\n then reject;\n }\n term ACCEPT_OTHERS {\n then accept;\n }\n }\n}\n\nVerify that the configured policy to filter Bogons has been applied to external BGP peers as shown in the example below.\n\nprotocols {\n bgp {\n group GROUP_AS4 {\n type external;\n import FILTER_ROUTES;\n peer-as 4;\n neighbor x.x.x.x;\n }\n }\n\nIf the router is not configured to reject inbound route advertisements for any Bogon prefixes, this is a finding.","fixText":"Configure the router to reject inbound route advertisements for any Bogon prefixes.\n\nConfigure a prefix list containing the current Bogon prefixes as shown below.\n\n[edit policy-options]\nset prefix-list BOGON_PREFIXES 0.0.0.0/8\nset prefix-list BOGON_PREFIXES 10.0.0.0/8\nset prefix-list BOGON_PREFIXES 100.64.0.0/10\nset prefix-list BOGON_PREFIXES 127.0.0.0/8\nset prefix-list BOGON_PREFIXES 169.254.0.0/16\nset prefix-list BOGON_PREFIXES 172.16.0.0/12\nset prefix-list BOGON_PREFIXES 192.0.0.0/24\nset prefix-list BOGON_PREFIXES 192.0.2.0/24\nset prefix-list BOGON_PREFIXES 192.168.0.0/16\nset prefix-list BOGON_PREFIXES 198.18.0.0/15\nset prefix-list BOGON_PREFIXES 198.51.100.0/24\nset prefix-list BOGON_PREFIXES 203.0.113.0/24\nset prefix-list BOGON_PREFIXES 224.0.0.0/4\nset prefix-list BOGON_PREFIXES 240.0.0.0/4\n\nConfigure a policy-statement to reject Bogon prefixes.\n\nset policy-statement FILTER_ROUTES term REJECT_BOGONS from prefix-list BOGON_PREFIXES\nset policy-statement FILTER_ROUTES term REJECT_BOGONS then reject\nset policy-statement FILTER_ROUTES term ACCEPT_OTHER then accept\n\nConfigure an import statement referencing the policy to reject Bogons on all external BGP peers.\n\n[edit protocols bgp group GROUP_AS4]\nset import FILTER_ROUTES","ccis":["CCI-001368"]},{"vulnId":"V-217054","ruleId":"SV-217054r604135_rule","severity":"medium","ruleTitle":"The Juniper BGP router must be configured to reject inbound route advertisements for any prefixes belonging to the local autonomous system (AS).","description":"Accepting route advertisements belonging to the local AS can result in traffic looping or being black holed, or at a minimum using a non-optimized path.","checkContent":"Review the router configuration to verify that it will reject routes belonging to the local AS.\n\nVerify a prefix list has been configured containing prefixes belonging to the local autonomous system as shown in the example below.\n\npolicy-options {\n …\n …\n …\n prefix-list OUR_PREFIXES {\n x.x.x.x/16;\n }\n\nVerify that a policy has been configured to reject the local prefixes.\n\npolicy-options {\n …\n …\n …\n policy-statement FILTER_ROUTES {\n term REJECT_BOGONS {\n from {\n prefix-list BOGON_PREFIXES;\n }\n then reject;\n }\n term REJECT_OUR_PREFIXES {\n from {\n prefix-list OUR_PREFIXES;\n }\n then reject;\n }\n term ACCEPT_OTHER {\n then accept;\n }\n }\n}\n\nVerify that the configured policy to filter local prefixes has been applied to external BGP peers as shown in the example below.\n\nprotocols {\n bgp {\n group GROUP_AS4 {\n type external;\n import FILTER_ROUTES;\n peer-as 4;\n neighbor x.x.x.x;\n }\n }\n\nIf the router is not configured to reject inbound route advertisements belonging to the local AS, this is a finding.","fixText":"Configure the router to reject inbound route advertisements for any prefixes belonging to the local AS.\n\nConfigure a prefix list containing prefixes belonging to the local autonomous system.\n\n[edit policy-options]\nset prefix-list OUR_PREFIXES x.x.x.x/16\n\nConfigure a policy-statement to reject prefixes belonging to the local autonomous system. This can be done by adding a term to the existing policy to filter Bogons as shown in the example below.\n\n[edit policy-options policy-statement FILTER_ROUTES]\nset term REJECT_OUR_PREFIXES from prefix-list OUR_PREFIXES\nset term REJECT_OUR_PREFIXES then reject\ninsert term REJECT_OUR_PREFIXES before term ACCEPT_OTHER\n\nNote: There is no need change the BGP configuration assuming the import statement is already configured for all external neighbors.","ccis":["CCI-001368"]},{"vulnId":"V-217055","ruleId":"SV-217055r604135_rule","severity":"medium","ruleTitle":"The Juniper BGP router must be configured to reject inbound route advertisements from a customer edge (CE) Juniper router for prefixes that are not allocated to that customer.","description":"As a best practice, a service provider should only accept customer prefixes that have been assigned to that customer and any peering autonomous systems. A multi-homed customer with BGP speaking routers connected to the Internet or other external networks could be breached and used to launch a prefix de-aggregation attack. Without ingress route filtering of customers, the effectiveness of such an attack could impact the entire IP core and its customers.","checkContent":"Review the router configuration to verify that there are filters defined to only accept routes for prefixes that belong to specific customers. \n\nVerify prefix list has been configured containing prefixes belonging to each customer as shown in the example below.\n\npolicy-options {\n …\n …\n …\n prefix-list CUST1_PREFIXES {\n x.x.x.x/24;\n x.x.x.x/24;\n }\n prefix-list CUST2_PREFIXES {\n x.x.x.x/24;\n }\n\nVerify that a policy has been configured to only accept routes belonging to the customer.\n\npolicy-options {\n …\n …\n …\n policy-statement FILTER_CUST1_ROUTES {\n term ACCEPT-ROUTES {\n from {\n prefix-list CUST1_PREFIXES;\n }\n then accept;\n }\n term REJECT_OTHER {\n then reject;\n }\n }\n policy-statement FILTER_CUST2_ROUTES {\n term ACCEPT_ROUTES {\n from {\n prefix-list CUST2_PREFIXES;\n }\n then accept;\n }\n term REJECT_OTHER {\n then reject;\n }\n }\n}\n\nVerify that the configured policy to filter customer prefixes has been applied to customer BGP peers as shown in the example below.\n\nprotocols {\n bgp {\n …\n …\n …\n }\n group CUST1 {\n type external;\n import FILTER_CUST1_ROUTES;\n peer-as 55;\n neighbor x.x.x.x;\n neighbor x.x.x.x;\n }\n group CUST2 {\n type external;\n import FILTER_CUST2_ROUTES;\n peer-as 44;\n neighbor x.x.x.x;\n neighbor x.x.x.x;\n }\n }\n …\n …\n …\n}\n\nNote: Routes to PE-CE links within a VPN are needed for troubleshooting end-to-end connectivity across the MPLS/IP backbone. Hence, these prefixes are an exception to this requirement.\n\nIf the router is not configured to reject inbound route advertisements from each CE router for prefixes that are not allocated to that customer, this is a finding.","fixText":"Configure the router to reject inbound route advertisements from a CE router for prefixes that are not allocated to that customer.\n\nConfigure a prefix list containing prefixes belonging to the customers.\n\n[edit policy-options]\nset prefix-list CUST1_PREFIXES x.x.x.x/24\nset prefix-list CUST1_PREFIXES x.x.x.x/24\nset prefix-list CUST2_PREFIXES x.x.x.x/24\nset prefix-list CUST2_PREFIXES x.x.x.x/24\n\nConfigure a policy-statement to filter customer routes.\n\nset policy-statement FILTER_CUST1_ROUTES term ACCEPT_ROUTES from prefix-list CUST1_PREFIXES\nset policy-statement FILTER_CUST1_ROUTES term then accept\nset policy-statement FILTER_CUST1_ROUTES term REJECT_OTHER then reject\nset policy-statement FILTER_CUST2_ROUTES term ACCEPT_ROUTES from prefix-list CUST2_PREFIXES\nset policy-statement FILTER_CUST2_ROUTES term then accept\nset policy-statement FILTER_CUST2_ROUTES term REJECT_OTHER then reject\n\nApply the import policy to filter received routes for each customer group.\n\n[edit protocols bgp group CUST1]\nset import FILTER_CUST1_ROUTES \n[edit protocols bgp group CUST2]\nset import FILTER_CUST2_ROUTES","ccis":["CCI-001368"]},{"vulnId":"V-217056","ruleId":"SV-217056r604135_rule","severity":"medium","ruleTitle":"The Juniper BGP router must be configured to reject outbound route advertisements for any prefixes that do not belong to any customers or the local autonomous system (AS).","description":"Advertisement of routes by an autonomous system for networks that do not belong to any of its customers pulls traffic away from the authorized network. This causes a denial of service (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 GIG IP core could redistribute IGP routes into BGP, thereby leaking internal routes.","checkContent":"This requirement is not applicable for the DODIN Backbone.” \n\nReview the router configuration to verify that there is a filter defined to only advertise routes for prefixes that belong to any customers or the local AS. \n\nVerify that a policy has been configured to filter prefixes for BGP advertisement as shown in the example below.\n\n}\npolicy-options {\n …\n …\n …\n policy-statement BGP_ADVERTISE_POLICY {\n term INCLUDE_LOCAL {\n from {\n prefix-list OUR_PREFIXES;\n }\n then accept;\n }\n term INCLUDE_CUST1 {\n from {\n prefix-list CUST1_PREFIXES;\n }\n then accept;\n }\n term INCLUDE_CUST2 {\n from {\n prefix-list CUST2_PREFIXES;\n }\n then accept;\n }\n term REJECT_OTHER {\n then reject;\n }\n }\n\nVerify that the export statement as shown below references the advertise policy. \n\nprotocols {\n bgp {\n group AS4 {\n type external;\n import FILTER_ROUTES;\n export BGP_ADVERTISE_POLICY;\n peer-as 4;\n neighbor x.x.x.x;\n }\n group CUST1 {\n type external;\n import FILTER_CUST1_ROUTES;\n export BGP_ADVERTISE_POLICY;\n peer-as 55;\n neighbor x.x.x.x;\n neighbor x.x.x.x;\n }\n group CUST2 {\n type external;\n import FILTER_CUST2_ROUTES;\n export BGP_ADVERTISE_POLICY;\n peer-as 44;\n neighbor x.x.x.x;\n neighbor x.x.x.x;\n }\n }\n …\n …\n …\n}\n\nNote: The prefix lists should have already been configured per the previous requirements.\n\nIf the router is not configured to reject outbound route advertisements that do not belong to any customers or the local AS, this is a finding.","fixText":"Configure the router to filter outbound route advertisements for prefixes that are not allocated to or belong to any customer or the local autonomous system.\n\nConfigure a policy-statement to filter BGP route advertisements that will only include the local and customer prefixes.\n\n[edit policy-options]\nset policy-statement BGP_ADVERTISE_POLICY term INCLUDE_LOCAL from prefix-list OUR_PREFIXES\nset policy-statement BGP_ADVERTISE_POLICY term INCLUDE_LOCAL then accept\nset policy-statement BGP_ADVERTISE_POLICY term INCLUDE_CUST1 from prefix-list CUST1_PREFIXES\nset policy-statement BGP_ADVERTISE_POLICY term INCLUDE_CUST1 then accept \nset policy-statement BGP_ADVERTISE_POLICY term INCLUDE_CUST2 from prefix-list CUST2_PREFIXES\nset policy-statement BGP_ADVERTISE_POLICY term INCLUDE_CUST2 then accept \nset policy-statement BGP_ADVERTISE_POLICY term REJECT_OTHER then reject\n\nNote: The prefix lists should have already been configured per the previous requirements.\n\nConfigure an export statement referencing the advertise policy on all external BGP peer groups as shown in the example below.\n\n[edit protocols bgp group GROUP_AS4]\nset export BGP_ADVERTISE_POLICY \n[edit protocols bgp group CUST1]\nset export BGP_ADVERTISE_POLICY \n[edit protocols bgp group CUST2]\nset export BGP_ADVERTISE_POLICY","ccis":["CCI-001368"]},{"vulnId":"V-217057","ruleId":"SV-217057r604135_rule","severity":"medium","ruleTitle":"The Juniper BGP router must be configured to reject outbound route advertisements for any prefixes belonging to the IP core.","description":"Outbound route advertisements belonging to the core can result in traffic either looping or being black holed, or at a minimum, using a non-optimized path.","checkContent":"Review the router configuration to verify that there is a filter defined to block route advertisements for prefixes that belong to the IP core. \n\nVerify a prefix list has been configured containing prefixes belonging to the local autonomous system as shown in the example below.\n\npolicy-options {\n …\n …\n …\n prefix-list CORE_PREFIX {\n x.x.x.x/16;\n }\n\nVerify that a policy has been configured to not advertise prefixes belong to the core as shown in the example below.\n\npolicy-options {\n …\n …\n …\n policy-statement BGP_ADVERTISE_POLICY {\n term EXCLUDE_CORE {\n from {\n prefix-list CORE_PREFIX;\n }\n then reject;\n }\n term INCLUDE_OTHER {\n then accept;\n }\n }\n\nVerify that the export statement as shown below references the advertise policy. \n\nprotocols {\n bgp {\n group AS4 {\n type external;\n export BGP_ADVERTISE_POLICY;\n peer-as 4;\n neighbor x.x.x.x;\n }\n\nIf the router is not configured to reject outbound route advertisements that belong to the IP core, this is a finding.","fixText":"Configure the router to filter outbound route advertisements belonging to the IP core.\n\nConfigure a prefix list containing prefixes belonging to the IP core.\n\n[edit policy-options]\nset prefix-list CORE_PREFIX x.x.x.x/16\n\nConfigure a policy-statement to filter BGP route advertisements that will exclude core prefixes.\n\n[edit policy-options]\nset policy-statement BGP_ADVERTISE_POLICY term EXCLUDE_CORE from prefix-list CORE_PREFIX\nset policy-statement BGP_ADVERTISE_POLICY term EXCLUDE_CORE then reject\nset policy-statement BGP_ADVERTISE_POLICY term INCLUDE_OTHER then accept\n\nConfigure an export statement referencing the advertise policy on all external BGP peer groups as shown in the example below.\n\n[edit protocols bgp group GROUP_AS4]\nset export BGP_ADVERTISE_POLICY","ccis":["CCI-001097"]},{"vulnId":"V-217058","ruleId":"SV-217058r945854_rule","severity":"low","ruleTitle":"The Juniper BGP router must be configured to reject route advertisements from BGP peers that do not list their autonomous system (AS) number as the first AS in the AS_PATH attribute.","description":"Verifying the path a route has traversed will ensure the IP core is not used as a transit network for unauthorized or possibly even Internet traffic. All autonomous system boundary routers (ASBRs) must ensure updates received from eBGP peers list their AS number as the first AS in the AS_PATH attribute.","checkContent":"Review the router configuration to verify the router is configured to deny updates received from eBGP peers that do not list their AS number as the first AS in the AS_PATH attribute. Verify that the enforce-first-as command has been configured at the BGP or group hierarchy as shown in the example below:\n\nprotocols {\n…\n…\n…\n bgp {\n enforce-first-as;\n\nIf the router is not configured to reject updates from peers that do not list their AS number as the first AS in the AS_PATH attribute, this is a finding.","fixText":"Configure the router to deny updates received from eBGP peers that do not list their AS number as the first AS in the AS_PATH attribute using the enforce-first-as command as shown in the example below:\n\n[edit protocols bgp group]\nset enforce-first-as","ccis":["CCI-000032"]},{"vulnId":"V-217059","ruleId":"SV-217059r945855_rule","severity":"low","ruleTitle":"The Juniper BGP router must be configured to reject route advertisements from CE routers with an originating AS in the AS_PATH attribute that does not belong to that customer.","description":"Verifying the path a route has traversed will ensure that the local AS is not used as a transit network for unauthorized traffic. To ensure that the local AS does not carry any prefixes that do not belong to any customers, all PE routers must be configured to reject routes with an originating AS other than that belonging to the customer.","checkContent":"This requirement is not applicable for the DODIN Backbone.” \n\nReview the router configuration to verify the router is configured to deny updates received from CE routers with an originating AS in the AS_PATH attribute that does not belong to that customer.\n\nStep 1: Verify a policy has been configured to filter AS_PATH attribute for received BGP advertisements as shown in the example below:\n\npolicy-options {\n …\n …\n …\n policy-statement FILTER_ASx {\n term ALLOW_ASx {\n from as-path PEER_ASx;\n then accept;\n }\n term ELSE_REJECT {\n then reject;\n }\n }\n …\n …\n …\n as-path PEER_ASx \"^x$\";\n}\n\nNote: the characters “^” and “$” representing the beginning and the end of the expression respectively are optional and are implicitly defined if omitted.\nStep 2: Verify that the import policy has been applied to all external BGP peers as shown in the example below:\n\nprotocols {\n bgp {\n group GROUP_ASx {\n type external;\n import [ FILTER_ASx FILTER_ROUTES ];\n peer-as x;\n neighbor x.x.x.x;\n }\n \nIf the router is not configured to reject updates from CE routers with an originating AS in the AS_PATH attribute that does not belong to that customer, this is a finding.","fixText":"Step 1: Configure a policy to filter the AS_PATH as shown in the example below: \n\n[edit policy-options] \nset as-path PEER_ASx \"^x$\" \nset policy-statement FILTER_ASx term ALLOW_ASx from as-path PEER_ASx \nset policy-statement FILTER_ASx term ALLOW_ASx then accept \nset policy-statement FILTER_ASx term ELSE_REJECT then reject \n\nStep 2: Apply the import policy as shown in the example below: \n\n[edit protocols bgp group GROUP_ASx] \nset import [FILTER_AS4 FILTER_ROUTES]","ccis":["CCI-000032"]},{"vulnId":"V-217060","ruleId":"SV-217060r855900_rule","severity":"medium","ruleTitle":"The Juniper BGP router must be configured to use the maximum prefixes feature to protect against route table flooding and prefix de-aggregation attacks.","description":"The effects of prefix de-aggregation can degrade router performance due to the size of routing tables and also result in black-holing legitimate traffic. Initiated by an attacker or a misconfigured router, prefix de-aggregation occurs when the announcement of a large prefix is fragmented into a collection of smaller prefix announcements.\n\nIn 1997, misconfigured routers in the Florida Internet Exchange network (AS7007) de-aggregated every prefix in their routing table and started advertising the first /24 block of each of these prefixes as their own. Faced with this additional burden, the internal routers became overloaded and crashed repeatedly. This caused prefixes advertised by these routers to disappear from routing tables and reappear when the routers came back online. As the routers came back after crashing, they were flooded with the routing table information by their neighbors. The flood of information would again overwhelm the routers and cause them to crash. This process of route flapping served to destabilize not only the surrounding network but also the entire Internet. Routers trying to reach those addresses would choose the smaller, more specific /24 blocks first. This caused backbone networks throughout North America and Europe to crash.\n\nMaximum prefix limits on peer connections combined with aggressive prefix-size filtering of customers' reachability advertisements will effectively mitigate the de-aggregation risk. BGP maximum prefix must be used on all eBGP routers to limit the number of prefixes that it should receive from a particular neighbor, whether customer or peering AS. Consider each neighbor and how many routes they should be advertising and set a threshold slightly higher than the number expected.","checkContent":"Review the router configuration to verify that the number of received prefixes from each eBGP neighbor is controlled.\n\nprotocols {\n bgp {\n group GROUP_AS4 {\n type external;\n family inet {\n unicast {\n prefix-limit {\n maximum 10;\n teardown;\n }\n }\n } peer-as 4;\n neighbor x.x.x.x;\n }\n\nIf the router is not configured to control the number of prefixes received from each peer to protect against route table flooding and prefix de-aggregation attacks, this is a finding.","fixText":"Configure the router to use the maximum prefixes feature to protect against route table flooding and prefix de-aggregation attacks as shown in the example below.\n\n[edit protocols bgp group GROUP_AS4]\nset family inet unicast prefix-limit maximum nnnnn teardown","ccis":["CCI-002385"]},{"vulnId":"V-217061","ruleId":"SV-217061r855901_rule","severity":"low","ruleTitle":"The Juniper BGP router must be configured to limit the prefix size on any inbound route advertisement to /24 or the least significant prefixes issued to the customer.","description":"The effects of prefix de-aggregation can degrade router performance due to the size of routing tables and also result in black-holing legitimate traffic. Initiated by an attacker or a misconfigured router, prefix de-aggregation occurs when the announcement of a large prefix is fragmented into a collection of smaller prefix announcements.","checkContent":"This requirement is not applicable for the DODIN Backbone. \n\nReview the router configuration to determine if it is compliant with this requirement.\n\nVerify that a policy statement has been configured to reject prefixes longer than /24 or the least significant prefixes issued to the customers as shown in the example below.\n\npolicy-options {\n …\n …\n …\n }\n policy-statement NO_LONG_PREFIXES {\n from {\n route-filter 0.0.0.0/0 prefix-length-range /25-/32 reject;\n }\n }\n\nNote: It may be necessary to configure separate policy statements depending on the address space issued to each customer.\n\nVerify that there is an import statement referencing the policy statement to filter prefix length.\n\nprotocols {\n bgp {\n …\n …\n …\n }\n group CUST1 {\n type external;\n import [ FILTER_CUST1_ROUTES NO_LONG_PREFIXES ];\n peer-as 55;\n neighbor x.x.x.x;\n neighbor x.x.x.x;\n }\n group CUST2 {\n type external;\n import [ FILTER_CUST1_ROUTES NO_LONG_PREFIXES ];\n peer-as 44;\n neighbor x.x.x.x;\n neighbor x.x.x.x;\n }\n\nIf the router is not configured to limit the prefix size on any inbound route advertisement to /24 or the least significant prefixes issued to the customer, this is a finding.","fixText":"Configure the router to limit the prefix size on any route advertisement to /24 or the least significant prefixes issued to the customer.\n\nConfigure a route filter to reject any prefix that is longer than /24.\n\n[edit policy-options]\nset policy-statement NO_LONG_PREFIXES from route-filter 0.0.0.0/0 prefix-length-range /25-/32 reject\n\nApply the policy statement to the BGP customer groups.\n\n[edit protocols bgp group CUST1]\nset import NO_LONG_PREFIXES\n[edit protocols bgp group CUST2]\nset import NO_LONG_PREFIXES","ccis":["CCI-002385"]},{"vulnId":"V-217062","ruleId":"SV-217062r992001_rule","severity":"low","ruleTitle":"The Juniper BGP router must be configured to use its loopback address as the source address for iBGP peering sessions.","description":"Using a loopback address as the source address offers a multitude of uses for security, access, management, and scalability of the BGP routers. It is easier to construct appropriate ingress filters for router management plane traffic destined to the network management subnet since the source addresses will be from the range used for loopback interfaces instead of a larger range of addresses used for physical interfaces. Log information recorded by authentication and syslog servers will record the router’s loopback address instead of the numerous physical interface addresses.\n\nWhen the loopback address is used as the source for eBGP peering, the BGP session will be harder to hijack since the source address to be used is not known globally—making it more difficult for a hacker to spoof an eBGP neighbor. By using traceroute, a hacker can easily determine the addresses for an eBGP speaker when the IP address of an external interface is used as the source address. The routers within the iBGP domain should also use loopback addresses as the source address when establishing BGP sessions.","checkContent":"Review the router configuration to verify that a loopback address has been configured.\n\ninterfaces {\n …\n …\n …\n }\n lo0 {\n unit 0 {\n family inet {\n address 2.2.2.2/32;\n }\n }\n }\n}\n\nVerify that the loopback interface is used as the source address for all iBGP sessions.\n\nprotocols {\n bgp {\n …\n …\n …\n }\ngroup IBGP_PEERS {\n type internal;\n local-address 2.2.2.2;\n neighbor x.x.x.x;\n}\n\nIf the router does not use its loopback address as the source address for all iBGP sessions, this is a finding.","fixText":"Configure the router to use its loopback address as the source address for all iBGP peering.\n\n[edit protocols bgp group IBGP_PEERS]\nset local-address 2.2.2.2","ccis":["CCI-004931"]},{"vulnId":"V-217063","ruleId":"SV-217063r992002_rule","severity":"low","ruleTitle":"The Juniper MPLS router must be configured to use its loopback address as the source address for LDP peering sessions.","description":"Using a loopback address as the source address offers a multitude of uses for security, access, management, and scalability of backbone routers. It is easier to construct appropriate ingress filters for router management plane traffic destined to the network management subnet since the source addresses will be from the range used for loopback interfaces instead of from a larger range of addresses used for physical interfaces. Log information recorded by authentication and syslog servers will record the router's loopback address instead of the numerous physical interface addresses.","checkContent":"Review the router configuration to determine if it is compliant with this requirement.\n\nVerify that a loopback address has been configured as shown in the following example:\n\n}\ninterfaces {\n …\n …\n …\n }\n lo0 {\n unit 0 {\n family inet {\n address 2.2.2.2/32;\n }\n }\n }\n}\n\nBy default, routers will use its loopback address for LDP peering. If an address has not be configured on the loopback interface, it will use its physical interface connecting to the LDP peer. If the router-id command is specified that overrides this default behavior, verify that it is the IP address of the designated loopback interface as shown in the example below.\n\n}\nrouting-options {\n router-id 2.2.2.2;\n autonomous-system 5;\n}\n\nIf the router is not configured do use its loopback address for LDP peering, this is a finding.","fixText":"Configure the router to use their loopback address as the source address for LDP peering sessions. As noted in the check content, the default behavior is to use its loopback address. However, if a router ID is configured, ensure it matches the address of the loopback address as shown in the example below.\n\n[edit routing-options]\nset router-id 2.2.2.2","ccis":["CCI-004931"]},{"vulnId":"V-217064","ruleId":"SV-217064r604135_rule","severity":"low","ruleTitle":"The Juniper MPLS router must be configured to synchronize IGP and LDP to minimize packet loss when an IGP adjacency is established prior to LDP peers completing label exchange.","description":"Packet loss can occur when an IGP adjacency is established and the router begins forwarding packets using the new adjacency before the LDP label exchange completes between the peers on that link. Packet loss can also occur if an LDP session closes and the router continues to forward traffic using the link associated with the LDP peer rather than an alternate pathway with a fully synchronized LDP session. The MPLS LDP-IGP Synchronization feature provides a means to synchronize LDP with OSPF or IS-IS to minimize MPLS packet loss. When an IGP adjacency is established on a link but LDP-IGP synchronization is not yet achieved or is lost, the IGP will advertise the max-metric on that link.","checkContent":"Review the router OSPF or IS-IS configuration and verify that LDP will synchronize with the link-state routing protocol as shown in the example below.\n\nOSPF Example:\n\nprotocols {\n mpls {\n interface ge-0/0/0.0;\n }\n …\n …\n …\n ospf {\n export REDISTRIBUTE;\n area 0.0.0.0 {\n interface ge-0/0/0.0 {\n ldp-synchronization {\n hold-time 10;\n }\n …\n …\n …\n }\n }\n ldp {\n interface ge-0/0/0.0;\n }\n}\n\nIS-IS Example:\n\nprotocols {\n mpls {\n interface ge-0/0/0.0;\n }\n …\n …\n …\n isis {\n level 1 authentication-key-chain ISIS_KEY;\n level 2 authentication-key-chain ISIS_KEY;\n interface ge-0/0/0.0 {\n ldp-synchronization {\n hold-time 10;\n }\n …\n …\n …\n }\n }\n ldp {\n interface ge-0/0/0.0;\n }\n}\n\nIf the router is not configured to synchronize IGP and LDP, this is a finding.","fixText":"Configure the MPLS router to synchronize IGP and LDP, minimizing packet loss when an IGP adjacency is established prior to LDP peers completing label exchange.\n\n[edit protocols ospf area 0.0.0.0]\nset interface ge-0/0/0.0 ldp-synchronization hold-time 10\n\n[edit protocols isis]\nset interface ge-0/0/0.0 ldp-synchronization hold-time 10\n\nNote: The hold-time is the amount of time (in seconds) the routing device advertises the maximum cost metric for a link that is not fully operational. Default is infinity.","ccis":["CCI-000366"]},{"vulnId":"V-217065","ruleId":"SV-217065r604135_rule","severity":"low","ruleTitle":"The Juniper MPLS router with RSVP-TE enabled must be configured to enable refresh reduction features.","description":"RSVP-TE can be used to perform constraint-based routing when building LSP tunnels within the network core that will support QoS and traffic engineering requirements. RSVP-TE is also used to enable MPLS Fast Reroute, a network restoration mechanism that will reroute traffic onto a backup LSP in case of a node or link failure along the primary path. When there is a disruption in the MPLS core, such as a link flap or router reboot, the result is a significant amount of RSVP signaling, such as \"PathErr\" and \"ResvErr\" messages that need to be sent for every LSP using that link.\n\nWhen RSVP messages are sent out, they are sent either hop by hop or with the router alert bit set in the IP header. This means that every router along the path must examine the packet to determine if additional processing is required for these RSVP messages. If there is enough signaling traffic in the network, it is possible for an interface to receive more packets for its input queue than it can hold, resulting in dropped RSVP messages and hence slower RSVP convergence. Increasing the size of the interface input queue can help prevent dropping packets; however, there is still the risk of having a burst of signaling traffic that can fill the queue. Solutions to mitigate this risk are RSVP message pacing or refresh reduction to control the rate at which RSVP messages are sent. RSVP refresh reduction includes the following features: RSVP message bundling, RSVP Message ID to reduce message processing overhead, Reliable delivery of RSVP messages using Message ID, and summary refresh to reduce the amount of information transmitted every refresh interval.","checkContent":"Review the router configuration to determine if it is compliant with this requirement. The aggregate reliable commands in the example below will enable the following RSVP refresh reduction features: message bundling, Message ID, reliable message delivery, and summary refresh.\n\nprotocols {\n rsvp {\n interface ge-0/0/0.0 {\n aggregate;\n reliable;\n }\n }\n\nIf the router configured with RSVP-TE does not have refresh reduction features enabled, this is a finding.","fixText":"Configure the router to enable all refresh reduction features as shown in the example.\n\n[edit protocols rsvp]\nset interface ge-0/0/0.0 aggregate reliable\n\nNote: The aggregate reliable commands will enable the following RSVP refresh reduction features: message bundling, reliable message delivery, and summary refresh.","ccis":["CCI-001095"]},{"vulnId":"V-217066","ruleId":"SV-217066r604135_rule","severity":"medium","ruleTitle":"The Juniper MPLS router must be configured to have TTL Propagation disabled.","description":"The head end of the label-switched path (LSP), the label edge router (LER) will decrement the IP packet's time-to-live (TTL) value by one and then copy the value to the MPLS TTL field. At each label-switched router (LSR) hop, the MPLS TTL value is decremented by one. The MPLS router that pops the label (either the penultimate LSR or the egress LER) will copy the packet's MPLS TTL value to the IP TTL field and decrement it by one.\n\nThis TTL propagation is the default behavior. Because the MPLS TTL is propagated from the IP TTL, a traceroute will list every hop in the path, be it routed or label switched, thereby exposing core nodes. With TTL propagation disabled, LER decrements the IP packet's TTL value by one and then places a value of 255 in the packet's MPLS TTL field, which is then decremented by one as the packet passes through each LSR in the MPLS core. Because the MPLS TTL never drops to zero, none of the LSP hops triggers an ICMP TTL exceeded message and consequently, these hops are not recorded in a traceroute. Hence, nodes within the MPLS core cannot be discovered by an attacker.","checkContent":"Review the router configuration to verify that TTL propagation is disabled.\n\nprotocols {\n mpls {\n no-propagate-ttl;\n }\n\nIf the MPLS router is not configured to disable TTL propagation, this is a finding.","fixText":"Configure the MPLS router to disable TTL propagation.\n\n[edit protocols mpls]\nset no-propagate-ttl","ccis":["CCI-000366"]},{"vulnId":"V-217067","ruleId":"SV-217067r992003_rule","severity":"high","ruleTitle":"The Juniper PE router must be configured to have each Virtual Routing and Forwarding (VRF) instance bound to the appropriate physical or logical interfaces to maintain traffic separation between all MPLS L3VPNs.","description":"The primary security model for an MPLS L3VPN infrastructure is traffic separation. The service provider must guarantee the customer that traffic from one VPN does not leak into another VPN or into the core, and that core traffic must not leak into any VPN. Hence, it is imperative that each CE-facing interface can only be associated to one VRF—that alone is the fundamental framework for traffic separation.","checkContent":"Review the design plan for deploying L3VPN and VRF-lite. \n\nReview all CE-facing interfaces and verify that the proper VRF is defined. The example below depicts the CE-facing interface ge-0/1/0 bound to VRF titled L3VPN_CUST1. Notice that the PE router is peering OSPF with the CE router.\n\ninterfaces {\n …\n …\n …\n }\n ge-0/1/0 {\n description \"link to Customer 1\";\n unit 0 {\n family inet {\n address 101.3.44.6/30;\n }\n }\n }\n …\n …\n …\n}\n\nrouting-instances {\n L3VPN_CUST1 {\n description \"Between PE1 & PE2\";\n instance-type vrf;\n interface ge-0/1/0.0;\n route-distinguisher 33:33;\n vrf-target target:33:33;\n vrf-table-label;\n protocols {\n ospf {\n area 0.0.0.1 {\n interface ge-0/1/0.0;\n }\n }\n }\n }\n}\n\nIf any VRFs are not bound to the appropriate physical or logical interface, this is a finding.","fixText":"Configure the PE router to have each VRF bound to the appropriate physical or logical interfaces to maintain traffic separation between all MPLS L3VPNs as shown in the example below.\n\n[edit]\nset routing-instances L3VPN_CUST1 instance-type vrf\nset routing-instances L3VPN_CUST1 description \"Between PE1 & PE2\"\nset routing-instances L3VPN_CUST1 interface ge-0/1/0.0\nset routing-instances L3VPN_CUST1 protocols ospf interface area 1 ge-0/1/0.0\nset routing-instances L3VPN_CUST1 route-distinguisher 33:33\nset routing-instances L3VPN_CUST1 vrf-target target:33:33 \nset routing-instances L3VPN_CUST1 vrf-table-label","ccis":["CCI-004931"]},{"vulnId":"V-217068","ruleId":"SV-217068r992004_rule","severity":"high","ruleTitle":"The Juniper PE router must be configured to have each Virtual Routing and Forwarding (VRF) instance with the appropriate Route Target (RT).","description":"The primary security model for an MPLS L3VPN as well as a VRF-lite infrastructure is traffic separation. Each interface can only be associated to one VRF, which is the fundamental framework for traffic separation. Forwarding decisions are made based on the routing table belonging to the VRF. Control of what routes are imported into or exported from a VRF is based on the RT. It is critical that traffic does not leak from one COI tenant or L3VPN to another; hence, it is imperative that the correct RT is configured for each VRF.","checkContent":"Review the design plan for MPLS/L3VPN and VRF-lite to determine what RTs have been assigned for each VRF.\n\nReview the router configuration and verify that the correct RT is configured for each VRF. In the example below, route target 33:33 has been configured for customer 1.\n\nrouting-instances {\n L3VPN_CUST1 {\n description \"Between PE1 & PE2\";\n instance-type vrf;\n interface ge-0/1/0.0;\n route-distinguisher 33:33;\n vrf-target target:33:33;\n vrf-table-label;\n protocols {\n ospf {\n area 0.0.0.1 {\n interface ge-0/1/0.0;\n }\n }\n }\n }\n\nIf there are VRFs configured with the wrong RT, this is a finding.","fixText":"Configure the router to have each VRF instance defined with the correct RT.\n\n[edit]\nset routing-instances L3VPN_CUST1 vrf-target target:33:33","ccis":["CCI-004931"]},{"vulnId":"V-217069","ruleId":"SV-217069r992005_rule","severity":"medium","ruleTitle":"The Juniper PE router must be configured to have each VRF with the appropriate Route Distinguisher (RD).","description":"An RD provides uniqueness to the customer address spaces within the MPLS L3VPN infrastructure. The concept of the VPN-IPv4 and VPN-IPv6 address families consists of the RD prepended before the IP address. Hence, if the same IP prefix is used in several different L3VPNs, it is possible for BGP to carry several completely different routes for that prefix, one for each VPN.\n\nSince VPN-IPv4 addresses and IPv4 addresses are different address families, BGP never treats them as comparable addresses. The purpose of the RD is to create distinct routes for common IPv4 address prefixes. On any given PE router, a single RD can define a VRF in which the entire address space may be used independently, regardless of the makeup of other VPN address spaces. Hence, it is imperative that a unique RD is assigned to each L3VPN and that the proper RD is configured for each VRF.","checkContent":"Review the RDs that have been assigned for each VRF according to the plan provided by the ISSM. Review the router configuration and verify that the correct RD is configured for each VRF. In the example below, route distinguisher 33:33 has been configured for customer 1.\n\nrouting-instances {\n L3VPN_CUST1 {\n description \"Between PE1 & PE2\";\n instance-type vrf;\n interface ge-0/1/0.0;\n route-distinguisher 33:33;\n vrf-target target:33:33;\n vrf-table-label;\n protocols {\n ospf {\n area 0.0.0.1 {\n interface ge-0/1/0.0;\n }\n }\n }\n }\n\nIf the wrong RD has been configured for any VRF, this is a finding.","fixText":"Configure the correct RD for each VRF.\n\n[edit]\nset routing-instances L3VPN_CUST1 route-distinguisher 33:33","ccis":["CCI-004931"]},{"vulnId":"V-217070","ruleId":"SV-217070r878055_rule","severity":"medium","ruleTitle":"The Juniper PE router providing MPLS Layer 2 Virtual Private Network (L2VPN) services must be configured to authenticate targeted Label Distribution Protocol (LDP) sessions used to exchange virtual circuit (VC) information using a FIPS-approved message authentication code algorithm.","description":"LDP provides the signaling required for setting up and tearing down pseudowires (virtual circuits used to transport Layer 2 frames) across an MPLS IP core network. Using a targeted LDP session, each PE router advertises a virtual circuit label mapping that is used as part of the label stack imposed on the frames by the ingress PE router during packet forwarding. Authentication provides protection against spoofed TCP segments that can be introduced into the LDP sessions.","checkContent":"Review the router configuration to determine if LDP messages are being authenticated for the targeted LDP sessions. In the example below, the PE router is LDP peering with remote PE 8.8.8.8.\n\n ldp {\n interface ge-0/1/0.0;\n interface ge-0/1/1.0;\n session 8.8.8.8 {\n authentication-algorithm hmac-sha-1-96;\n authentication-key-chain LDP_KEY;\n }\n }\n\nIf authentication is not being used for the LDP targeted sessions using a FIPS-approved message authentication code algorithm, this is a finding.","fixText":"Implement authentication for all targeted LDP sessions using a FIPS-approved message authentication code algorithm.\n\n[edit security authentication-key-chains]\nset key-chain LDP_KEY key 1 start-time 2018-05-01.12:00 secret xxxxxxxxxxxxx\nset key-chain LDP_KEY key 2 start-time 2018-09-01.12:00 secret xxxxxxxxxxxxx\nset key-chain LDP_KEY key 3 start-time 2019-01-01.12:00 secret xxxxxxxxxxxxx\n\n[edit protocols ldp]\nset session 8.8.8.8 authentication-algorithm hmac-sha-1-96 authentication-key-chain LDP_KEY","ccis":["CCI-001958"]},{"vulnId":"V-217071","ruleId":"SV-217071r992006_rule","severity":"high","ruleTitle":"The Juniper PE router providing MPLS Virtual Private Wire Service (VPWS) must be configured to have the appropriate virtual circuit identification (VC ID) for each attachment circuit.","description":"VPWS is an L2VPN technology that provides a virtual circuit between two PE routers to forward Layer 2 frames between two customer-edge routers or switches through an MPLS-enabled IP core. The ingress PE router (virtual circuit head-end) encapsulates Ethernet frames inside MPLS packets using label stacking and forwards them across the MPLS network to the egress PE router (virtual circuit tail-end). During a virtual circuit setup, the J-PE routers exchange VC label bindings for the specified VC ID. The VC ID specifies a pseudowire associated with an ingress and egress PE router and the customer-facing attachment circuits. \n\nTo guarantee that all frames are forwarded onto the correct pseudowire and to the correct customer and attachment circuits, it is imperative that the correct VC ID is configured for each attachment circuit.","checkContent":"Review the ingress and egress PE router configuration for each virtual circuit that has been provisioned.\n\nVerify that the correct and unique VCID has been configured for the appropriate attachment circuit. In the example below ge-0/1/0 is the CE-facing interface that is configured for VPWS (aka pseudowire).\n\ninterfaces {\n ge-0/1/0.0 {\n encapsulation ethernet-ccc;\n unit 0 {\n }\n }\n…\n…\n…\nprotocols {\n …\n …\n …\n }\n l2circuit {\n neighbor 8.8.8.8 {\n interface ge-0/1/0.0{\n virtual-circuit-id 13;\n }\n }\n }\n\nIf the correct VC ID has not been configured on both routers, this is a finding.\n\nNote: Ethernet over MPLS in VLAN mode transports Ethernet traffic from a source 802.1Q VLAN to a destination 802.1Q VLAN over a core MPLS network. The VC ID must be unique and the same on each end as it is used to connect the endpoints of the VC.","fixText":"Assign globally unique VC IDs for each virtual circuit and configure the attachment circuits with the appropriate VC ID. Configure the same VC ID on both ends of the VC.\n\n[edit protocols l2circuit]\nset neighbor 8.8.8.8 interface em0 virtual-circuit-id 13","ccis":["CCI-004931"]},{"vulnId":"V-217072","ruleId":"SV-217072r992007_rule","severity":"high","ruleTitle":"The Juniper PE router providing Virtual Private LAN Services (VPLS) must be configured to have all attachment circuits defined to the routing instance with the globally unique VPLS ID assigned for each customer VLAN.","description":"VPLS defines an architecture that delivers Ethernet multipoint services over an MPLS network. Customer Layer 2 frames are forwarded across the MPLS core via pseudowires using IEEE 802.1q Ethernet bridging principles. A pseudowire is a virtual bidirectional connection between two attachment circuits (virtual connections between PE and CE routers). A pseudowire contains two unidirectional label-switched paths (LSP) between two PE routers. Each MAC virtual forwarding table instance is interconnected using pseudowires provisioned for the bridge domain, thereby maintaining privacy and logical separation between each VPLS bridge domain.\n\nThe forwarding table instance specifies the pseudowires associated with connecting PE routers and the customer-facing attachment circuits belonging to a given VLAN. Resembling a Layer 2 switch, the forwarding table instance is responsible for learning MAC addresses and providing loop-free forwarding of customer traffic to the appropriate end nodes. Each VPLS domain is identified by a globally unique VPN ID; hence, VFIs of the same VPLS domain must be configured with the same VPLS ID on all participating PE routers. To guarantee traffic separation for all customer VLANs and that all packets are forwarded to the correct destination, it is imperative that the correct attachment circuits are associated with the appropriate forwarding table instance and that each forwarding table instance is associated to the unique VPLS ID assigned to the customer VLAN.","checkContent":"Review the implementation plan and the VPLS IDs assigned to customer VLANs for the VPLS deployment.\n\nReview the PE router configuration to verify that customer attachment circuits are associated to the appropriate routing instance configured for the customers VPLS ID.\n\ninterfaces {\n ge-0/1/0.0 {\n encapsulation ethernet-vpls;\n unit 0 {\n }\n }\n…\n…\n…\nrouting-instances {\n VPLS_CUST2 {\n instance-type vpls;\n interface ge-0/1/0.0;\n route-distinguisher 22:22;\n vrf-target target:22:22;\n protocols {\n vpls {\n site-range 9;\n no-tunnel-services;\n site R8 {\n site-identifier 8;\n interface ge-0/1/0.0;\n }\n vpls-id 102;\n neighbor 8.8.8.8;\n }\n }\n }\n}\n\nIf the attachment circuits have not been bound to appropriate routing instance configured with the assigned VPLS ID for each customer VLAN, this is a finding.","fixText":"Assign globally unique VPLS ID to each VPLS routing instance as shown in the example.\n\n[edit routing-instances VPLS_CUST2 protocols vpls]\nset vpls-id 102 neighbor 8.8.8.8","ccis":["CCI-004931"]},{"vulnId":"V-217073","ruleId":"SV-217073r604135_rule","severity":"medium","ruleTitle":"The Juniper PE router providing Virtual Private LAN Services (VPLS) must be configured to have traffic storm control thresholds on CE-facing interfaces.","description":"A traffic storm occurs when packets flood a VPLS bridge, creating excessive traffic and degrading network performance. Traffic storm control prevents VPLS bridge disruption by suppressing traffic when the number of packets reaches configured threshold levels. Traffic storm control monitors incoming traffic levels on a port and drops traffic when the number of packets reaches the configured threshold level during any one-second interval.","checkContent":"Review the router configuration to verify that storm control is enabled on CE-facing interfaces deploying VPLS.\n\nVerify that a flood filter has been configured for each VPLS routing instances as shown in the example below.\n\nrouting-instances {\n VPLS_CUST2 {\n instance-type vpls;\n interface ge-0/1/0.0; \n route-distinguisher 22:22;\n vrf-target target:22:22;\n forwarding-options {\n family vpls {\n flood {\n input VPLS_FLOOD_FILTER;\n }\n }\n }\n protocols {\n vpls {\n site-range 9;\n no-tunnel-services;\n site R8 {\n site-identifier 8;\n interface ge-0/1/0.0;\n }\n vpls-id 102;\n neighbor 8.8.8.8;\n }\n }\n }\n}\n\nReview the filter configured for the VPLS routing instances to verify it defines traffic types associated with storm control (i.e. broadcast, multicast, and unknown unicast storms).\n\nfirewall {\n …\n …\n …\n family vpls {\n filter VPLS_FLOOD_FILTER {\n term BROADCAST_TRAFFIC {\n from {\n traffic-type broadcast;\n }\n then {\n policer STORM_POLICER;\n accept;\n }\n }\n term MULTICAST_TRAFFIC {\n from {\n traffic-type multicast;\n }\n then {\n policer STORM_POLICER;\n accept;\n }\n }\n term UNKNOWN_UNICAST_TRAFFIC {\n from {\n traffic-type unknown-unicast;\n }\n then {\n policer STORM_POLICER;\n accept;\n }\n }\n }\n }\n\nVerify that the policer rates limits storm traffic.\n\nfirewall {\n …\n …\n …\n policer STORM_POLICER {\n if-exceeding {\n bandwidth-limit 10m;\n burst-size-limit 5m;\n }\n then discard;\n }\n\nIf storm control is not enabled, this is a finding.","fixText":"Configure storm control for each VPLS bridge domain. Base the rate limiting on expected traffic rates plus some additional capacity. \n\nConfigure a policer to rate limit traffic to provide storm control for all VPLS implementations as shown in the example.\n\n[edit firewall]\nset policer STORM_POLICER if-exceeding bandwidth-limit 10m burst-size-limit 5m\nset policer STORM_POLICER then discard\n\nConfigure the filter to specify traffic types to rate limit broadcast, multicast, and unknown unicast storms as shown in the example.\n\n[edit firewall family vpls filter VPLS_FLOOD_FILTER]\nset term BROADCAST_TRAFFIC from traffic-type broadcast\nset term BROADCAST_TRAFFIC then policer STORM_POLICER accept\nset term MULTICAST_TRAFFIC from traffic-type multicast\nset term MULTICAST_TRAFFIC then policer STORM_POLICER accept\nset term UNKNOWN_UNICAST_TRAFFIC from traffic-type unknown-unicast \nset term UNKNOWN_UNICAST_TRAFFIC then policer STORM_POLICER accept \n\nApply the storm control filter to all VPLS routing instances as shown in the example.\n\n[edit routing-instances VPLS_CUST2]\nset forwarding-options family vpls flood input VPLS_FLOOD_FILTER","ccis":["CCI-001095"]},{"vulnId":"V-217074","ruleId":"SV-217074r855903_rule","severity":"low","ruleTitle":"The Juniper PE router must be configured to implement Protocol Independent Multicast (PIM) snooping for each Virtual Private LAN Services (VPLS) bridge domain.","description":"PIM snooping provides a way to constrain multicast traffic at Layer 2. By monitoring PIM join and prune packets on each interface, the PE router is able to determine interested multicast receivers and hence will populate the layer 2 multicast-forwarding table. This enables the PE router to deliver traffic only to ports with at least one interested member within the VPLS bridge, thereby significantly reducing the volume of multicast traffic that would otherwise flood an entire VPLS bridge domain. The PIM snooping operation applies to both access circuits and pseudowires within a VPLS bridge domain.","checkContent":"Review the router configuration to verify that PIM snooping has been configured under the routing instance protocols hierarchy for each VPLS bridge domain as shown in the example.\n\nrouting-instances {\n VPLS_CUST2 {\n instance-type vpls;\n interface ge-0/1/0.0; \n route-distinguisher 22:22;\n vrf-target target:22:22;\n }\n protocols {\n vpls {\n site-range 9;\n no-tunnel-services;\n site R8 {\n site-identifier 8;\n interface ge-0/1/0.0;\n }\n vpls-id 102;\n neighbor 8.8.8.8;\n }\n pim-snooping;\n }\n }\n }\n}\n\nIf the router is not configured to implement PIM snooping for each VPLS bridge domain, this is a finding.","fixText":"Configure PIM snooping for each VPLS bridge domain as shown in the example below.\n\n[edit routing-instances VPLS_CUST2]\nset routing-instances VPLS_CUST2 protocols pim-snooping","ccis":["CCI-002385"]},{"vulnId":"V-217075","ruleId":"SV-217075r604135_rule","severity":"medium","ruleTitle":"The Juniper PE router must be configured to limit the number of MAC addresses it can learn for each Virtual Private LAN Services (VPLS) bridge domain.","description":"VPLS defines an architecture that delivers Ethernet multipoint services over an MPLS network. Customer Layer 2 frames are forwarded across the MPLS core via pseudowires using IEEE 802.1q Ethernet bridging principles. A pseudowire is a virtual bidirectional connection between two attachment circuits (virtual connections between PE and CE routers). A pseudowire contains two unidirectional label-switched paths (LSP). Each MAC forwarding table instance is interconnected using domain-specific LSPs, thereby maintaining privacy and logical separation between each VPLS domain.\n\nWhen a frame arrives on a bridge port (pseudowire or attachment circuit) and the source MAC address is unknown to the receiving PE router, the source MAC address is associated with the pseudowire or attachment circuit and the forwarding table is updated accordingly. Frames are forwarded to the appropriate pseudowire or attachment circuit according to the forwarding table entry for the destination MAC address. Ethernet frames sent to broadcast and unknown destination addresses must be flooded out to all interfaces for the bridge domain; hence, a PE router must replicate packets across both attachment circuits and pseudowires.\n\nA malicious attacker residing in a customer network could launch a source MAC address spoofing attack by flooding packets to a valid unicast destination, each with a different MAC source address. The PE router receiving this traffic would try to learn every new MAC address and would quickly run out of space for the VFI forwarding table. Older, valid MAC addresses would be removed from the table, and traffic sent to them would have to be flooded until the storm threshold limit is reached. Hence, it is essential that a limit is established to control the number of MAC addresses that will be learned and recorded into the forwarding table for each bridge domain.","checkContent":"Review the PE router configuration to determine if a MAC address limit has been set for each VPLS bridge domain.\n\nrouting-instances {\n VPLS_CUST2 {\n instance-type vpls;\n interface ge-0/1/0.0; \n route-distinguisher 22:22;\n vrf-target target:22:22;\n protocols {\n vpls {\n site-range 9;\n mac-table-size {\n nnnn;\n }\n no-tunnel-services;\n site R8 {\n site-identifier 8;\n interface ge-0/1/0.0;\n }\n vpls-id 102;\n neighbor 8.8.8.8;\n }\n }\n }\n}\n\nIf a limit has not been configured, this is a finding.","fixText":"Configure a MAC address learning limit for each VPLS bridge domain.\n\n[edit routing-instances VPLS_CUST2 protocols vpls]\nset mac-table-size nnnn","ccis":["CCI-001094"]},{"vulnId":"V-217076","ruleId":"SV-217076r604135_rule","severity":"high","ruleTitle":"The Juniper PE router must be configured to block any traffic that is destined to IP core infrastructure.","description":"IP/MPLS networks providing VPN and transit services must provide, at the least, the same level of protection against denial-of-service (DoS) attacks and intrusions as Layer 2 networks. Although the IP core network elements are hidden, security should never rely entirely on obscurity.\n\nIP addresses can be guessed. Core network elements must not be accessible from any external host. Protecting the core from any attack is vital for the integrity and privacy of customer traffic as well as the availability of transit services. A compromise of the IP core can result in an outage or, at a minimum, non-optimized forwarding of customer traffic. Protecting the core from an outside attack also prevents attackers from using the core to attack any customer. Hence, it is imperative that all routers at the edge deny traffic destined to any address belonging to the IP core infrastructure.","checkContent":"Review the router configuration to verify that an ingress filter is applied to all CE-facing interfaces. \n\ninterfaces {\n ge-0/1/0 {\n description \"link to Customer 2\";\n unit 0 {\n family inet {\n filter {\n input INGRESS_FILTER;\n }\n address x.x.x.x/30;\n }\n }\n }\n\nVerify that the ingress filter discards and logs packets destined to the IP core address space. \n\nfirewall {\n family inet {\n filter INGRESS_FILTER {\n term BLOCK_TO_CORE {\n from {\n destination-address {\n x.x.x.x/8;\n }\n }\n then {\n log;\n discard;\n }\n }\n term ALLOW_TRANSIT_TRAFFIC {\n then accept;\n }\n }\n }\n\nIf the PE router is not configured to block any traffic with a destination address assigned to the IP core infrastructure, this is a finding.\n\nNote: Internet Control Message Protocol (ICMP) echo requests and traceroutes will be allowed to the edge from external adjacent neighbors.","fixText":"Configure protection for the IP core to be implemented at the edges by blocking any traffic with a destination address assigned to the IP core infrastructure.\n\nConfigure an ingress filter to discard and log packets destined to the IP core address space. \n\n[edit firewall family inet]\nset filter INGRESS_FILTER term BLOCK_TO_CORE from destination-address x.x.x.x/8\nset filter INGRESS_FILTER term BLOCK_TO_CORE then log discard\nset filter INGRESS_FILTER term ALLOW_TRANSIT_TRAFFIC then accept\n\nApply the filter inbound to all CE-facing interfaces.\n\n[edit interfaces ge-0/1/0 unit 0]\nset family inet filter input INGRESS_FILTER","ccis":["CCI-001097"]},{"vulnId":"V-217077","ruleId":"SV-217077r604135_rule","severity":"medium","ruleTitle":"The Juniper PE router must be configured with Unicast Reverse Path Forwarding (uRPF) loose mode enabled on all CE-facing interfaces.","description":"The uRPF feature is a defense against spoofing and denial-of-service (DoS) attacks by verifying if the source address of any ingress packet is reachable. To mitigate attacks that rely on forged source addresses, all provider edge routers must enable uRPF loose mode to guarantee that all packets received from a CE router contain source addresses that are in the route table.","checkContent":"Review the router configuration to determine if uRPF loose mode is enabled on all CE-facing interfaces.\n\ninterfaces {\n ge-0/1/0 {\n description \"link to Customer 2\";\n unit 0 {\n family inet {\n rpf-check {\n mode loose;\n }\n address x.x.x.x/30;\n }\n }\n }\n\nIf uRPF loose mode is not enabled on all CE-facing interfaces, this is a finding.","fixText":"Configure uRPF loose mode on all CE-facing interfaces as shown in the example.\n\n[edit interfaces ge-0/1/0 unit 0 family inet]\nset rpf-check mode loose","ccis":["CCI-001097"]},{"vulnId":"V-217078","ruleId":"SV-217078r945860_rule","severity":"medium","ruleTitle":"The Juniper PE router must be configured to ignore or block all packets with any IP options.","description":"Packets with IP options are not fast switched and therefore must be punted to the router processor. Hackers who initiate denial-of-service (DoS) attacks on routers commonly send large streams of packets with IP options. Dropping the packets with IP options reduces the load of IP options packets on the router. The end result is a reduction in the effects of the DoS attack on the router and on downstream routers.","checkContent":"Review the router configuration to determine if it will block all packets with IP options.\n\nfirewall {\n family inet {\n filter INGRESS_FILTER {\n term BLOCK_TO_CORE {\n from {\n destination-address {\n x.x.x.x/8;\n }\n }\n then {\n log;\n discard;\n }\n }\n term BLOCK_IP_OPTIONS {\n from {\n ip-options any;\n }\n then {\n discard;\n }\n }\n term ALLOW_TRANSIT_TRAFFIC {\n then accept;\n }\n }\n }\n\nIf the router is not configured to drop all packets with IP options, this is a finding.","fixText":"Configure the router to drop all packets with IP options.\n\n[edit firewall family inet filter INGRESS_FILTER]\nset term BLOCK_IP_OPTIONS from ip-options any\nset term BLOCK_IP_OPTIONS then discard\ninsert term BLOCK_IP_OPTIONS before term ALLOW_TRANSIT_TRAFFIC","ccis":["CCI-002403"]},{"vulnId":"V-217079","ruleId":"SV-217079r604135_rule","severity":"low","ruleTitle":"The Juniper PE router must be configured to enforce a Quality-of-Service (QoS) policy in accordance with the QoS GIG Technical Profile.","description":"Different applications have unique requirements and toleration levels for delay, jitter, bandwidth, packet loss, and availability. To manage the multitude of applications and services, a network requires a QoS framework to differentiate traffic and provide a method to manage network congestion. The Differentiated Services Model (DiffServ) is based on per-hop behavior by categorizing traffic into different classes and enabling each node to enforce a forwarding treatment to each packet as dictated by a policy.\n\nPacket markings such as IP Precedence and its successor, Differentiated Services Code Points (DSCP), were defined along with specific per-hop behaviors for key traffic types to enable a scalable QoS solution. DiffServ QoS categorizes network traffic, prioritizes it according to its relative importance, and provides priority treatment based on the classification. It is imperative that end-to-end QoS is implemented within the IP core network to provide preferred treatment for mission-critical applications.","checkContent":"Review the router configuration and verify that it has been configured to enforce a QoS policy in accordance with the QoS GIG Technical Profile (GTP-0009). The router must be configured to use either configured or default Behavior Aggregate (BA) classifier on all interfaces as shown in the example below:\n\nclass-of-service {\n …\n …\n …\n }\n interfaces {\n ge-0/0/1 {\n unit 0 {\n classifiers {\n dscp default;\n }\n }\n }\n ge-0/1/0 {\n unit 0 {\n classifiers {\n dscp default;\n }\n }\n }\n ge-1/0/1 {\n unit 0 {\n classifiers {\n dscp default;\n }\n }\n }\n ge-1/1/0 {\n unit 0 {\n classifiers {\n dscp default;\n }\n }\n }\n\nNote: The GTP QOS document (GTP-0009) can be downloaded via the following link:\nhttps://intellipedia.intelink.gov/wiki/Portal:GIG_Technical_Guidance/GTG_GTPs/GTP_Development_List\n\nIf the router is not configured to enforce a QoS policy in accordance with the QoS DODIN Technical Profile, this is a finding.","fixText":"Configure all interfaces to use a configured or the default BA classifier as shown in the example below:\n\n[edit class-of-service interfaces]\nset ge-0/0/1 unit 0 classifiers dscp default\nset ge-0/1/0 unit 0 classifiers dscp default \nset ge-1/0/1 unit 0 classifiers dscp default\nset ge-1/1/0 unit 0 classifiers dscp default\n\nNote: The GTP QOS document (GTP-0009) can be downloaded via the following link:\nhttps://intellipedia.intelink.gov/wiki/Portal:GIG_Technical_Guidance/GTG_GTPs/GTP_Development_List","ccis":["CCI-001095"]},{"vulnId":"V-217080","ruleId":"SV-217080r604135_rule","severity":"low","ruleTitle":"The Juniper P router must be configured to enforce a Quality-of-Service (QoS) policy in accordance with the QoS GIG Technical Profile.","description":"Different applications have unique requirements and toleration levels for delay, jitter, bandwidth, packet loss, and availability. To manage the multitude of applications and services, a network requires a QoS framework to differentiate traffic and provide a method to manage network congestion. The Differentiated Services Model (DiffServ) is based on per-hop behavior by categorizing traffic into different classes and enabling each node to enforce a forwarding treatment to each packet as dictated by a policy.\n\nPacket markings such as IP Precedence and its successor, Differentiated Services Code Points (DSCP), were defined along with specific per-hop behaviors for key traffic types to enable a scalable QoS solution. DiffServ QoS categorizes network traffic, prioritizes it according to its relative importance, and provides priority treatment based on the classification. It is imperative that end-to-end QoS is implemented within the IP core network to provide preferred treatment for mission-critical applications.","checkContent":"Review the router configuration and verify that it has been configured to enforce a QoS policy in accordance with the QoS GIG Technical Profile (GTP-0009). The router must be configured to use either configured or default Behavior Aggregate (BA) classifier on all interfaces as shown in the example below:\n\nclass-of-service {\n …\n …\n …\n }\n interfaces {\n ge-0/0/1 {\n unit 0 {\n classifiers {\n dscp default;\n }\n }\n }\n ge-0/1/0 {\n unit 0 {\n classifiers {\n dscp default;\n }\n }\n }\n ge-1/0/1 {\n unit 0 {\n classifiers {\n dscp default;\n }\n }\n }\n ge-1/1/0 {\n unit 0 {\n classifiers {\n dscp default;\n }\n }\n }\n\nNote: The GTP QOS document (GTP-0009) can be downloaded via the following link: \nhttps://intellipedia.intelink.gov/wiki/Portal:GIG_Technical_Guidance/GTG_GTPs/GTP_Development_List\n\nIf the router is not configured to enforce a QoS policy in accordance with the QoS GIG Technical Profile, this is a finding.","fixText":"Configure all P router interfaces and PE core-facing interfaces to use a configured or the default BA classifier as shown in the example below.\n\n[edit class-of-service interfaces]\nset ge-0/0/1 unit 0 classifiers dscp default\nset ge-0/1/0 unit 0 classifiers dscp default \nset ge-1/0/1 unit 0 classifiers dscp default\nset ge-1/1/0 unit 0 classifiers dscp default\n\nNote: The GTP QOS document (GTP-0009) can be downloaded via the following link: \nhttps://intellipedia.intelink.gov/wiki/Portal:GIG_Technical_Guidance/GTG_GTPs/GTP_Development_List","ccis":["CCI-001095"]},{"vulnId":"V-217081","ruleId":"SV-217081r604135_rule","severity":"medium","ruleTitle":"The Juniper PE router must be configured to enforce a Quality-of-Service (QoS) policy to limit the effects of packet flooding denial-of-service (DoS) attacks.","description":"DoS is a condition when a resource is not available for legitimate users. Packet flooding distributed denial-of-service (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 using readily available tools such as Low Orbit Ion Cannon or botnets. \n\nMeasures 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).","checkContent":"Verify that a forwarding class has been configured for the Scavenger class. CS1 has been adopted as the forwarding class; hence, the example below will define class CS1 to be used.\n\nclass-of-service {\n …\n …\n …\n }\n forwarding-classes {\n class CS1 queue-num 7 priority low;\n }\n\nThe Scavenger class is marked at the access layer with DSCP CS1. Hence, the router must maintain the marking and assign the packet to the configured forwarding class CS1.\n\nPE Router only - Verify that the Multifield (MF) classifier has provisioned for this class as shown in the example below.\n\nfirewall {\n family inet {\n filter CLASSIFY_TRAFFIC {\n …\n …\n …\n }\n term SCAVENGER {\n from {\n dscp cs1;\n }\n then {\n forwarding-class CS1;\n accept;\n }\n }\n term ACCEPT_OTHER {\n then {\n forwarding-class best-effort;\n accept;\n }\n }\n }\n }\n}\n\nPE and P router - Verify that a Behavior aggregate (BA) classifier has been configured to match the Scavenger class (CS1) as shown in the example below.\n\nclass-of-service {\n classifiers {\n dscp CLASSIFIER {\n import default;\n forwarding-class CS1 {\n loss-priority high code-points 001000;\n }\n }\n }\n\nNote: A proactive approach to mitigating DoS and worm flooding attacks within the base/camp/agency enclaves is to respond immediately to out-of-profile network behavior indicative of a DoS or worm attack via access-Layer policers. Such policers can meter traffic rates received from endpoint devices. When these traffic flows exceed specified rates, they no longer are considered normal flows and henceforth can be set to the Scavenger class marking (DSCP CS1).\n\nP router – Verify that the BA classifier has been applied to all interfaces as shown in the example below.\n\nclass-of-service {\n …\n …\n …\n }\n interfaces {\n ge-0/0/1 {\n unit 0 {\n classifiers {\n dscp CLASSIFIER;\n }\n }\n }\n ge-0/1/1 {\n unit 0 {\n classifiers {\n dscp CLASSIFIER;\n }\n }\n }\n }\n}\n\nRemaining steps only apply to the PE router.\n\nVerify that a scheduler has been configured for the Scavenger class as shown in the example below.\n\nclass-of-service {\n …\n …\n …\n }\n schedulers {\n …\n …\n …\n }\n SCAVENGER_SCHED {\n transmit-rate percent 5;\n buffer-size percent 5;\n priority low;\n }\n }\n}\n\nVerify that the scheduler has been added to the scheduler map.\n\nclass-of-service {\n …\n …\n …\n }\n scheduler-maps {\n QOS_SCHED_MAP {\n forwarding-class expedited-forwarding scheduler VOIP_SCHED;\n forwarding-class network-control scheduler CONTROL_PLANE_SCHED;\n forwarding-class assured-forwarding scheduler MGMT_SCHED;\n forwarding-class best-effort scheduler BEST_EFFORT_SCHED;\n forwarding-class CS1 scheduler SCAVENGER_SCHED;\n }\n }\n\nVerify that rewrite rules have been created to mark DSCP CS1 for those packets assigned to the Scavenger class with the appropriate code points.\n\nclass-of-service {\n …\n …\n …\n }\n rewrite-rules {\n dscp REWRITE_DSCP {\n import default;\n forwarding-class CS1 {\n loss-priority high code-point 001000;\n }\n }\n }\n\nVerify that the scheduler map, rewrite rules, and the BA classifier has been applied to all core-facing interfaces.\n\nclass-of-service {\n …\n …\n …\n }\n interfaces {\n ge-2/1/1 {\n scheduler-map QOS_SCHED_MAP;\n unit 0 {\n classifiers {\n dscp CLASSIFIER;\n }\n rewrite-rules {\n dscp REWRITE_DSCP;\n }\n }\n }\n ge-2/0/1 {\n scheduler-map QOS_SCHED_MAP;\n unit 0 {\n rewrite-rules {\n dscp REWRITE_DSCP;\n }\n }\n }\n }\n\nIf QoS policy to limit the effects of packet flooding denial-of-service (DoS) attacks has not been configured, this is a finding.","fixText":"Configure a forwarding class has been configured for the Scavenger class as shown in the example below.\n\n[edit class-of-service forwarding-classes]\nset class CS1 queue-num 7 priority low \n\nThe Scavenger class is marked at the access layer with DSCP CS1. Hence, the router must maintain the marking and assign the packet to the configured forwarding class CS1.\n\nPE Router only – Configure a Multifield (MF) classifier to provision for the Scavenger class as shown in the example below.\n\n[edit firewall family inet filter CLASSIFY_TRAFFIC]\nset term SCAVENGER from dscp cs1\nset term SCAVENGER then forwarding-class CS1 accept\ninsert term SCAVENGER before term ACCEPT_OTHER\n\nPE and P Router – Configure a Behavior aggregate (BA) classifier to match on the packets marked with DSCP CS1.\n\n[edit class-of-service classifiers] \nset dscp CLASSIFIER import default forwarding-class CS1 loss-priority high code-points 001000 \n\nP router only – Apply the BA classifier to all interfaces.\n\n[edit class-of-service interfaces]\nset ge-0/0/1 unit 0 classifiers dscp CLASSIFIER\nset ge-0/1/1 unit 0 classifiers dscp CLASSIFIER\n\nRemaining steps are only applicable to the PE router.\n\nConfigure a scheduler for the Scavenger class.\n\n[edit class-of-service schedulers]\nset SCAVENGER_SCHED transmit-rate percent 5\nset SCAVENGER_SCHED buffer-size percent 5\nset SCAVENGER_SCHED priority low\nset BEST_EFFORT_SCHED transmit-rate percent 55\n\nAdd the Scavenger scheduler to the scheduler map.\n\n[edit class-of-service scheduler-maps QOS_SCHED_MAP]\nset forwarding-class CS1 scheduler SCAVENGER_SCHED\n\nApply the scheduler map to all core-facing interfaces.\n\n[edit class-of-service interfaces]\nset ge-2/1/1 scheduler-map QOS_SCHED_MAP\nset ge-1/0/1 scheduler-map QOS_SCHED_MAP\n\nNote: The above step should already have been completed.\n\nConfigure rewrite rules to ensure egress Scavenger packets will continue to be marked with DSCP CS1.\n\n[edit class-of-service rewrite-rules]\nset dscp REWRITE_DSCP import default forwarding-class CS1 loss-priority high code-point 001000 \n\nApply the configured rewrite rules to all core-facing interfaces.\n\n[edit class-of-service interfaces]\nset ge-2/1/1 unit 0 rewrite-rules dscp REWRITE_DSCP\nset ge-1/0/1 unit 0 rewrite-rules dscp REWRITE_DSCP","ccis":["CCI-001095"]},{"vulnId":"V-217082","ruleId":"SV-217082r604135_rule","severity":"medium","ruleTitle":"The Juniper multicast router must be configured to disable Protocol Independent Multicast (PIM) on all interfaces that are not required to support multicast routing.","description":"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. \n\nA 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. \n\nAs 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 engineers have documented their multicast topology and thereby knows which interfaces are enabled for multicast. Once this is done, the zones can be scoped as required.","checkContent":"Review the network's multicast topology diagram.\n\nReview the router configuration to verify that only the PIM interfaces as shown in the multicast topology diagram are enabled for PIM.\n\nprotocols {\n …\n …\n …\n pim {\n interface ge-1/0/1.0 {\n mode sparse;\n }\n interface ge-1/1/1.0 {\n mode sparse;\n }\n interface ge-2/1/0.0 {\n mode sparse;\n }\n interface ge-2/1/1.0 {\n mode sparse;\n }\n }\n\nIf an interface is not required to support multicast routing and it is enabled, this is a finding.","fixText":"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.\n\n[edit protocols pim]\ndelete interface ge-2/1/1.0","ccis":["CCI-001414"]},{"vulnId":"V-217083","ruleId":"SV-217083r604135_rule","severity":"medium","ruleTitle":"The Juniper multicast router must be configured to bind a Protocol Independent Multicast (PIM) neighbor filter to interfaces that have PIM enabled.","description":"PIM is a routing protocol used to build multicast distribution trees for forwarding multicast traffic across the network infrastructure. PIM 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, 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.","checkContent":"This requirement is not applicable for the DoDIN Backbone.\n\nVerify all interfaces enabled for PIM have a neighbor filter bound to the interface as shown in the example below.\n\nprotocols {\n …\n …\n …\n pim {\n interface ge-1/0/1.0 {\n mode sparse;\n neighbor-policy PIM_NBR1_POLICY;\n }\n interface ge-1/1/1.0 {\n mode sparse;\n neighbor-policy PIM_NBR2_POLICY;\n }\n interface ge-2/1/0.0 {\n mode sparse;\n neighbor-policy PIM_NBR3_POLICY;\n }\n }\n\nReview the prefix list and policy statements configured for filtering PIM neighbors as shown in the example below.\n\npolicy-options {\n prefix-list PIM_NBR1 {\n x.x.x.x/32;\n }\n prefix-list PIM_NBR2 {\n x.x.x.x/32;\n }\n prefix-list PIM_NBR3 {\n x.x.x.x/32;\n }\n\n policy-statement PIM_NBR1_POLICY {\n from {\n prefix-list PIM_NBR1;\n }\n then accept;\n }\n policy-statement PIM_NBR2_POLICY {\n from {\n prefix-list PIM_NBR2;\n }\n then accept;\n }\n policy-statement PIM_NBR3_POLICY {\n from {\n prefix-list PIM_NBR3;\n }\n then accept;\n }\n\nIf PIM neighbor filters are not bound to all interfaces that have PIM enabled, this is a finding.","fixText":"This requirement is not applicable for the DoDIN Backbone.\n\nConfigure neighbor filters to only accept PIM control plane traffic from documented PIM neighbors. Bind neighbor filters to all PIM enabled interfaces.\n\nConfigure prefix list for each neighbor.\n\n[edit policy-options]\nset prefix-list PIM_NBR1 x.x.x.x/32\nset prefix-list PIM_NBR2 x.x.x.x/32\nset prefix-list PIM_NBR3 x.x.x.x/32\n\nConfigure policy statements for each PIM neighbor.\n\n[edit policy-options]\nset policy-statement PIM_NBR1_POLICY from prefix-list PIM_NBR1\nset policy-statement PIM_NBR1_POLICY then accept\nset policy-statement PIM_NBR2_POLICY from prefix-list PIM_NBR1\nset policy-statement PIM_NBR2_POLICY then accept\nset policy-statement PIM_NBR3_POLICY from prefix-list PIM_NBR1\nset policy-statement PIM_NBR3_POLICY then accept\n\nApply the neighbor policy to all interfaces enabled for PIM.\n\n[edit protocols pim]\nset interface ge-1/0/1.0 neighbor-policy PIM_NBR1_POLICY \nset interface ge-1/1/1.0 neighbor-policy PIM_NBR1_POLICY \nset interface ge-2/1/0.0 neighbor-policy PIM_NBR1_POLICY","ccis":["CCI-001414"]},{"vulnId":"V-217084","ruleId":"SV-217084r604135_rule","severity":"low","ruleTitle":"The Juniper multicast edge router must be configured to establish boundaries for administratively scoped multicast traffic.","description":"If multicast traffic is forwarded beyond the intended boundary, it is possible that it can be intercepted by unauthorized or unintended personnel.\n\nAdministrative 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.\n\nAdmin-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.","checkContent":"Review the router configuration to verify it is blocking admin-scope multicast traffic (239.0.0.0/8) at the multicast domain edge as shown in the example below:\n\nrouting-options {\n …\n …\n …\n multicast {\n scope ADMIN_SCOPE {\n prefix 239.0.0.0/8;\n interface [ ge-1/0/1.0 ge-1/1/1.0 ];\n }\n }\n}\n\nIf the router is not configured to block admin-scoped multicast traffic at the multicast domain edge, this is a finding.","fixText":"Configure the router to block admin-scoped multicast traffic at the multicast domain edge as shown in the example below:\n\n[edit routing-options]\nset multicast scope ADMINL_SCOPE interface ge-1/0/1.0 prefix 239.0.0.0/8\nset multicast scope ADMINL_SCOPE interface ge-1/1/1.0 prefix 239.0.0.0/8","ccis":["CCI-001414"]},{"vulnId":"V-217085","ruleId":"SV-217085r878057_rule","severity":"low","ruleTitle":"The Juniper multicast Rendezvous Point (RP) router must be configured to limit the multicast forwarding cache so that its resources are not saturated by managing an overwhelming number of Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP) source-active entries.","description":"MSDP peering between networks enables sharing of multicast source information. Enclaves with an existing multicast topology using PIM-SM can configure their RP routers to peer with MSDP routers. As a first step of defense against a denial-of-service (DoS) attack, all RP routers must limit the multicast forwarding cache to ensure that router resources are not saturated managing an overwhelming number of PIM and MSDP source-active entries.","checkContent":"Review the router configuration to determine if forwarding cache thresholds are defined as shown in the example below.\n\nrouting-options {\n multicast {\n …\n …\n …\n }\n forwarding-cache {\n threshold {\n suppress 5000;\n reuse 4000;\n }\n }\n }\n}\n\nIf the RP router is not configured to limit the multicast forwarding cache to ensure that its resources are not saturated, this is a finding.","fixText":"Configure the router to limit the multicast forwarding cache for source-active entries.\n\n[edit routing-options multicast]\nset forwarding-cache threshold suppress 5000 reuse 4000","ccis":["CCI-002385"]},{"vulnId":"V-217086","ruleId":"SV-217086r604135_rule","severity":"low","ruleTitle":"The Juniper multicast Rendezvous Point (RP) router must be configured to filter Protocol Independent Multicast (PIM) Register messages received from the Designated Router (DR) for any undesirable multicast groups and sources.","description":"Real-time multicast traffic can entail multiple large flows of data. An attacker can flood a network segment with multicast packets, over-using the available bandwidth and thereby creating a denial-of-service (DoS) condition. Hence, it is imperative that register messages are accepted only for authorized multicast groups and sources.","checkContent":"Verify that the RP router is configured to filter PIM register messages.\n\nVerify that the RP has a register policy enabled as shown in the example below.\n\nprotocols {\n …\n …\n …\n }\n pim {\n rp {\n rp-register-policy MULTICAST_REGISTER_POLICY;\n local {\n address 2.2.2.2;\n }\n }\n\nVerify that the register policy has defined both bad multicast groups and sources as shown in the example below.\n\npolicy-options {\n …\n …\n …\n }\n policy-statement MULTICAST_REGISTER_POLICY {\n term BAD_SOURCES {\n from {\n source-address-filter x.x.x.x/32 exact;\n source-address-filter x.x.x.x/24 orlonger;\n }\n then reject;\n }\n term BAD_GROUPS {\n from {\n route-filter 224.1.1.0/24 orlonger;\n route-filter 225.1.2.3/32 exact;\n route-filter 239.0.0.0/8 orlonger;\n …\n …\n …\n route-filter 232.0.0.0/8 orlonger;\n }\n then reject;\n }\n term ALLOW_OTHER {\n then accept;\n }\n }\n\nIf the RP router peering with PIM-SM routers is not configured with a policy to block registration messages for any undesirable multicast groups and sources, this is a finding.","fixText":"Configure the router to filter PIM register messages received from a multicast DR for any undesirable multicast groups and sources.\n\n[edit policy-options policy-statement MULTICAST_REGISTER_POLICY]\nset term BAD_SOURCES from source-address-filter x.x.x.x/32 exact\nset term BAD_SOURCES from source-address-filter x.x.x.x/24 orlonger\nset term BAD_GROUPS from route-filter 224.1.1.0/24 orlonger\nset term BAD_GROUPS from route-filter 225.1.2.3/32 exact\nset term BAD_GROUPS from route-filter 239.0.0.0/8 orlonger\nset term BAD_GROUPS then reject\nset term ALLOW_OTHER then accept\n\n[edit protocols pim rp]\nset rp-register-policy MULTICAST_REGISTER_POLICY","ccis":["CCI-001414"]},{"vulnId":"V-217087","ruleId":"SV-217087r604135_rule","severity":"low","ruleTitle":"The Juniper multicast Rendezvous Point (RP) router must be configured to filter Protocol Independent Multicast (PIM) Join messages received from the Designated Juniper router (DR) for any undesirable multicast groups.","description":"Real-time multicast traffic can entail multiple large flows of data. An attacker can flood a network segment with multicast packets, over-using the available bandwidth and thereby creating a denial-of-service (DoS) condition. Hence, it is imperative that join messages are only accepted for authorized multicast groups and sources.","checkContent":"Review the RP router configuration to determine if it filters PIM join messages for any reserved multicast groups.\n\nStep 1: Verify that a PIM import statement has been configured as shown in the example below:\n\nprotocols {\n …\n …\n …\n }\n pim {\n import MULTICAST_JOIN_POLICY;\n\nStep 2: Verify that the join policy has defined both bad multicast groups and sources as shown in the example below:\n\npolicy-options {\n …\n …\n …\n }\n policy-statement MULTICAST_JOIN_POLICY {\n term BAD_GROUPS {\n from {\n route-filter 224.1.1.0/24 orlonger;\n route-filter 225.1.2.3/32 exact;\n …\n …\n …\n route-filter 232.0.0.0/8 orlonger;\n }\n then reject;\n }\n term ALLOW_OTHER {\n then accept;\n }\n }\nIf the RP router peering with PIM-SM routers is not configured with a PIM import policy to block join messages for any undesirable multicast groups, this is a finding.","fixText":"RP routers that are peering with customer PIM-SM routers must implement a PIM import policy to block join messages for any undesirable multicast groups.\n\nStep 1: Configure a multicast join policy to filter bad groups and sources as shown in the example below:\n\n[edit policy-options policy-statement MULTICAST_JOIN_POLICY]\nset term BAD_GROUPS from route-filter 224.1.1.0/24 orlonger\nset term BAD_GROUPS from route-filter 225.1.2.3/32 exact\n…\n…\n…\nset term BAD_GROUPS then reject\nset term ALLOW_OTHER then accept\n\nStep 2: Configure PIM to enable the join policy as shown in the example below:\n\n[edit protocols pim]\nset import MULTICAST_JOIN_POLICY","ccis":["CCI-001414"]},{"vulnId":"V-217088","ruleId":"SV-217088r855906_rule","severity":"medium","ruleTitle":"The Juniper multicast Rendezvous Point (RP) must be configured to rate limit the number of Protocol Independent Multicast (PIM) Register messages.","description":"When a new source starts transmitting in a PIM Sparse Mode network, the DR will encapsulate the multicast packets into register messages and forward them to the RP using unicast. This process can be taxing on the CPU for both the DR and the RP if the source is running at a high data rate and there are many new sources starting at the same time. This scenario can potentially occur immediately after a network failover. The rate limit for the number of register messages should be set to a relatively low value based on the known number of multicast sources within the multicast domain.","checkContent":"Review the configuration of the RP to verify that it is rate limiting the number of multicast register messages.\n\nprotocols {\n …\n …\n …\n }\n pim {\n rp {\n register-limit maximum nnnnn;\n local {\n address 2.2.2.2;\n }\n }\n\nNote: Each any-source group (*,G) counts as one group toward the limit. Each source-specific group (S,G) counts as one group toward the limit.\n\nIf the RP is not limiting multicast register messages, this is a finding.","fixText":"Configure the RP to rate limit the number of multicast register messages it will allow for each (S, G) entry.\n\n[edit protocols pim rp]\nset register-limit maximum nnnnn","ccis":["CCI-002385"]},{"vulnId":"V-217089","ruleId":"SV-217089r878058_rule","severity":"low","ruleTitle":"The Juniper multicast Designated Router (DR) must be configured to filter the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Report messages to allow hosts to join only multicast groups that have been approved by the organization.","description":"Real-time multicast traffic can entail multiple large flows of data. Large unicast flows tend to be fairly isolated (i.e., someone doing a file download here or there), whereas multicast can have broader impact on bandwidth consumption, resulting in extreme network congestion. Hence, it is imperative that there is multicast admission control to restrict which multicast groups hosts are allowed to join via IGMP or MLD.","checkContent":"Review the configuration of the DR to verify that it is filtering IGMP or MLD report messages, allowing hosts to join only those groups that have been approved.\n\nVerify that a group policy has been configured to filter IGMP join requests as shown in the example below.\n\nprotocols {\n igmp {\n interface ge-1/0/1.0 {\n group-policy MULTICAST_JOIN_POLICY;\n }\n }\n\nVerify that the group policy only allows join requests for those groups that have been approved.\n\npolicy-options {\n …\n …\n …\n }\n policy-statement MULTICAST_JOIN_POLICY {\n …\n …\n …\n }\n term BAD_GROUPS {\n from {\n route-filter 224.1.1.0/24 orlonger;\n route-filter 225.1.2.3/32 exact;\n route-filter 239.0.0.0/8 orlonger;\n …\n …\n …\n route-filter 232.0.0.0/8 orlonger;\n }\n then reject;\n }\n term ALLOW_APPROVED {\n then accept;\n }\n }\n\nNote: This requirement is only applicable to Source Specific Multicast (SSM) implementation. This requirement is not applicable to Any Source Multicast (ASM) since the filtering is being performed by the Rendezvous Point router.\n\nIf the DR is not filtering IGMP or MLD report messages to only allow joins for approved groups, this is a finding.","fixText":"Configure the DR to filter the IGMP and MLD report messages to allow hosts to join only those multicast groups that have been approved.\n\nConfigure a multicast join policy to filter groups that have not been approved as shown in the example below.\n\n[edit policy-options policy-statement MULTICAST_JOIN_POLICY]\nset term BAD_GROUPS from route-filter 224.1.1.0/24 orlonger\nset term BAD_GROUPS from route-filter 225.1.2.3/32 exact\nset term BAD_GROUPS from route-filter 239.0.0.0/8 orlonger\nset term BAD_GROUPS then reject\nset term ALLOW_APPROVED then accept\n\nApply the policy to all interfaces enabled for IGMP.\n\n[edit protocols igmp]\nset interface ge-1/0/1.0 group-policy MULTICAST_JOIN_POLICY","ccis":["CCI-002403"]},{"vulnId":"V-217090","ruleId":"SV-217090r878059_rule","severity":"medium","ruleTitle":"The Juniper multicast Designated Router (DR) must be configured to filter the Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Report messages to allow hosts to join a multicast group only from sources that have been approved by the organization.","description":"Real-time multicast traffic can entail multiple large flows of data. Large unicast flows tend to be fairly isolated (i.e., someone doing a file download here or there), whereas multicast can have broader impact on bandwidth consumption, resulting in extreme network congestion. Hence, it is imperative that there is multicast admission control to restrict which multicast groups hosts are allowed to join via IGMP or MLD.","checkContent":"Review the configuration of the DR to verify that it is filtering IGMP or MLD report messages, allowing hosts to only join multicast groups from sources that have been approved.\n\nVerify that a group policy has been configured to filter IGMP join requests as shown in the example below.\n\nprotocols {\n igmp {\n interface ge-1/0/1.0 {\n group-policy MULTICAST_JOIN_POLICY;\n }\n }\n\nVerify that the policy only allows join requests for those sources that have been approved.\n\npolicy-options {\n …\n …\n …\n }\n policy-statement MULTICAST_JOIN_POLICY {\n term BAD_SOURCES {\n from {\n source-address-filter x.x.x.x/32 exact;\n source-address-filter x.x.x.x/24 orlonger;\n }\n then reject;\n }\n …\n …\n …\n }\n term ALLOW_APPROVED {\n then accept;\n }\n }\n\nNote: This requirement is only applicable to Source Specific Multicast (SSM) implementation.\n\nIf the DR is not filtering IGMP or MLD report messages to only allow joins for approved sources, this is a finding.","fixText":"Configure the DR to filter the IGMP and MLD report messages to allow hosts to join only those multicast groups from sources that have been approved.\n\nConfigure a multicast join policy to filter unauthorized multicast sources.\n\n[edit policy-options policy-statement MULTICAST_JOIN_POLICY]\nset term BAD_SOURCES from source-address-filter x.x.x.x/32 exact\nset term BAD_SOURCES from source-address-filter x.x.x.x/24 orlonger\nset term BAD_SOURCES then reject\nset term ALLOW_APPROVED then accept\n\n Apply the policy to all interfaces enabled for IGMP.\n\n[edit protocols igmp]\nset interface ge-1/0/1.0 group-policy MULTICAST_JOIN_POLICY","ccis":["CCI-002403"]},{"vulnId":"V-217091","ruleId":"SV-217091r855909_rule","severity":"medium","ruleTitle":"The Juniper multicast Designated Router (DR) must be configured to limit the number of mroute states resulting from Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Host Membership Reports.","description":"The current multicast paradigm can let any host join any multicast group at any time by sending an IGMP or MLD membership report to the DR. In a Protocol Independent Multicast (PIM) Sparse Mode network, the DR will send a PIM Join message for the group to the RP. Without any form of admission control, this can pose a security risk to the entire multicast domain - specifically the multicast routers along the shared tree from the DR to the RP that must maintain the mroute state information for each group join request. Hence, it is imperative that the DR is configured to limit the number of mroute state information that must be maintained to mitigate the risk of IGMP or MLD flooding.","checkContent":"Review the DR configuration to verify that it is limiting the number of mroute states via IGMP or MLD.\n\nprotocols {\n igmp {\n interface ge-1/0/1.0 {\n group-limit nnn;\n }\n }\n\nIf the DR is not limiting multicast join requests via IGMP or MLD, this is a finding.","fixText":"Configure the DR on a global or interface basis to limit the number of mroute states resulting from IGMP or MLD membership reports.\n\n[edit protocols igmp]\nset interface ge-1/0/1.0 group-limit nnn","ccis":["CCI-002385"]},{"vulnId":"V-217092","ruleId":"SV-217092r945856_rule","severity":"medium","ruleTitle":"The Juniper multicast Designated Router (DR) must be configured to set the shortest-path tree (SPT) threshold to infinity to minimalize source-group (S, G) state within the multicast topology where Any Source Multicast (ASM) is deployed.","description":"ASM can have many sources for the same groups (many-to-many). For many receivers, the path via the RP may not be ideal compared with the shortest path from the source to the receiver. By default, the last-hop router will initiate a switch from the shared tree to a source-specific SPT to obtain lower latencies. This is accomplished by the last-hop router sending an (S, G) Protocol Independent Multicast (PIM) Join toward S (the source).\n\nWhen the last-hop router begins to receive traffic for the group from the source via the SPT, it will send a PIM Prune message to the RP for the (S, G). The RP will then send a Prune message toward the source. The SPT switchover becomes a scaling issue for large multicast topologies that have many receivers and many sources for many groups because (S, G) entries require more memory than (*, G). Hence, it is imperative to minimize the amount of (S, G) state to be maintained by increasing the threshold that determines when the SPT switchover occurs.","checkContent":"Review the multicast last-hop router configuration to verify that the SPT switchover threshold is set to infinity for all or specific multicast groups and sources.\n\nVerify that an infinity policy has been enabled for PIM.\n\nprotocols {\n …\n …\n …\n }\n pim {\n spt-threshold {\n infinity SPT_INFINITY;\n }\n }\n}\n\nVerify that the infinity policy defines specific multicast groups and sources or all multicast groups and sources as shown in the example below.\n\npolicy-options {\n …\n …\n …\n }\n policy-statement SPT_INFINITY {\n term ALL_GROUPS {\n from {\n route-filter 234.0.0.0/8 orlonger;\n }\n then accept;\n }\n }\n}\n\nIf any multicast router is not configured to set the SPT threshold to infinity to minimalize (S, G) state, this is a finding.","fixText":"Configure the multicast router to increase the SPT threshold or set it to infinity to minimalize (S, G) state within the multicast topology where ASM is deployed.\n\nConfigure a policy statement to set SPT threshold to infinity for all multicast groups or only specific groups and sources.\n\n[edit policy-options]\nset policy-statement SPT_INFINITY term ALL_GROUPS from route-filter 234.0.0.0/8 orlonger\nset policy-statement SPT_INFINITY term ALL_GROUPS then accept\n\nApply the SPT infinity policy.\n\n[edit protocols pim]\nset spt-threshold infinity SPT_INFINITY","ccis":["CCI-002385"]},{"vulnId":"V-217093","ruleId":"SV-217093r855911_rule","severity":"medium","ruleTitle":"The Juniper Multicast Source Discovery Protocol (MSDP) router must be configured to only accept MSDP packets from known MSDP peers.","description":"MSDP peering with customer network routers presents additional risks to the DISN Core, whether from a rogue or misconfigured MSDP-enabled router. To guard against an attack from malicious MSDP traffic, the receive path or interface filter for all MSDP-enabled RP routers must be configured to only accept MSDP packets from known MSDP peers.","checkContent":"Review the router configuration to determine if there is a receive path or interface filter to only accept MSDP packets from known MSDP peers.\n\nVerify that the loopback has been configured to filter packets destined to the routing engine as shown in the example below.\n\ninterfaces {\n …\n …\n …\n }\n lo0 {\n unit 0 {\n family inet {\n filter {\n input PROTECT_RE;\n }\n address 2.2.2.2/32;\n }\n }\n }\n}\n\nVerify that the filter is configured to only accept MSDP packets from known MSDP peers as shown in the example below.\n\nfirewall {\n family inet {\n filter PROTECT_RE {\n term MSDP_PEERS {\n from {\n source-address {\n 0.0.0.0/0;\n 1.1.1.1/32 except;\n 5.5.5.5/32 except;\n }\n protocol tcp;\n port msdp;\n }\n then {\n discard;\n }\n }\n term ALLOW_OTHER {\n then accept;\n }\n }\n }\n}\n\nIf the router is not configured to only accept MSDP packets from known MSDP peers, this is a finding.","fixText":"Configure the receive path filter to only accept MSDP packets from known MSDP peers as shown in the following example:\n\n[edit firewall family inet filter PROTECT_RE]\nset term MSDP_PEERS from protocol tcp port msdp\nset term MSDP_PEERS from source-address 0.0.0.0/0\nset term MSDP_PEERS from source-address 1.1.1.1/32 except\nset term MSDP_PEERS from source-address 5.5.5.5/32 except\nset term MSDP_PEERS then discard\nset term ALLOW_OTHER then accept\n\nApply the filter to the loopback interface.\n\n[edit interfaces lo0 unit 0 family inet]\nset filter input PROTECT_RE","ccis":["CCI-002403"]},{"vulnId":"V-217094","ruleId":"SV-217094r855912_rule","severity":"medium","ruleTitle":"The Juniper Multicast Source Discovery Protocol (MSDP) router must be configured to authenticate all received MSDP packets.","description":"MSDP peering with customer network routers presents additional risks to the core, whether from a rogue or misconfigured MSDP-enabled router. MSDP password authentication is used to validate each segment sent on the TCP connection between MSDP peers, protecting the MSDP session against the threat of spoofed packets being injected into the TCP connection stream.","checkContent":"Review the router configuration to determine if received MSDP packets are authenticated.\n\nprotocols {\n msdp {\n group AS25 {\n peer 5.5.5.5 {\n authentication-key \"$8$KspW87GUH.mTxNfz\"; ## SECRET-DATA}\n }\n }\n\nIf the router does not require MSDP authentication, this is a finding.","fixText":"Configure the router to authenticate MSDP messages as shown in the following example:\n\n[edit protocols msdp group AS25 peer 5.5.5.5]\nset authentication-key xxxxxxxx","ccis":["CCI-001958"]},{"vulnId":"V-217095","ruleId":"SV-217095r835204_rule","severity":"low","ruleTitle":"The Juniper Multicast Source Discovery Protocol (MSDP) router must be configured to filter received source-active multicast advertisements for any undesirable multicast groups and sources.","description":"The interoperability of BGP extensions for interdomain multicast routing and MSDP enables seamless connectivity of multicast domains between autonomous systems. MP-BGP advertises the unicast prefixes of the multicast sources used by Protocol Independent Multicast (PIM) routers to perform RPF checks and build multicast distribution trees. MSDP is a mechanism used to connect multiple PIM sparse-mode domains, allowing RPs from different domains to share information about active sources. When RPs in peering multicast domains hear about active sources, they can pass on that information to their local receivers, thereby allowing multicast data to be forwarded between the domains. Configuring an import policy to block multicast advertisements for reserved, Martian, single-source multicast, and any other undesirable multicast groups, as well as any source-group (S, G) states with Bogon source addresses, would assist in avoiding unwanted multicast traffic from traversing the core.","checkContent":"Review the router configuration to determine if there is import policy to block source-active multicast advertisements for undesirable multicast groups and sources.\n\npolicy-options {\n …\n …\n …\n }\n policy-statement SA_IMPORT {\n term BAD_GROUPS {\n from {\n route-filter 224.0.1.2/32 exact;\n route-filter 224.77.0.0/16 orlonger;\n }\n then reject;\n }\n term BAD_SOURCES {\n from {\n source-address-filter x.x.x.x /8 orlonger;\n source-address-filter x.x.x.x /8 orlonger;\n }\n then reject;\n }\n term ACCEPT_OTHERS {\n then accept;\n }\n }\n\nVerify that an import source-active filter has been applied to MSDP.\n\nprotocols {\n …\n …\n …\n }\n msdp {\n import SA_IMPORT;\n\nIf the router is not configured with an import policy to block undesirable SA multicast advertisements, this is a finding.","fixText":"Configure the MSDP to implement an import policy to block multicast advertisements for undesirable multicast groups and sources.\n\nConfigure the source-active filter to reject undesirable multicast groups and sources as shown in the example below.\n\n[edit policy-options]\nset policy-statement SA_IMPORT term BAD_GROUPS from route-filter 224.0.1.2/32 exact\nset policy-statement SA_IMPORT term BAD_GROUPS from route-filter 224.77.0.0/16 orlonger\nset policy-statement SA_IMPORT term BAD_GROUPS then reject\nset policy-statement SA_IMPORT term BAD_SOURCES from source-address-filter x.x.x.x/8 orlonger\nset policy-statement SA_IMPORT term BAD_SOURCES from source-address-filter x.x.x.x/16 orlonger\nset policy-statement SA_IMPORT term BAD_SOURCES then reject\nset policy-statement SA_IMPORT term ACCEPT_OTHERS then accept\n\nConfigure the source-active filter to be an import filter.\n\n[edit protocols msdp]\nset import SA_IMPORT","ccis":["CCI-001368"]},{"vulnId":"V-217096","ruleId":"SV-217096r819169_rule","severity":"low","ruleTitle":"The Juniper Multicast Source Discovery Protocol (MSDP) router must be configured to filter source-active multicast advertisements to external MSDP peers to avoid global visibility of local-only multicast sources and groups.","description":"To avoid global visibility of local information, there are a number of source-group (S, G) states in a PIM-SM domain that must not be leaked to another domain, such as multicast sources with private address, administratively scoped multicast addresses, and the auto-RP groups (224.0.1.39 and 224.0.1.40).\n\nAllowing a multicast distribution tree, local to the core, to extend beyond its boundary could enable local multicast traffic to leak into other autonomous systems and customer networks.","checkContent":"Review the router configuration to determine if there is export policy to block local source-active multicast advertisements.\n\nVerify that the router is configured with an export policy to filter multicast source-active advertisements.\n\npolicy-options {\n …\n …\n …\n }\n policy-statement SA_EXPORT {\n term INTERNAL_GROUP {\n from {\n route-filter 239.0.0.0/8 orlonger;\n }\n then reject;\n }\n term INTERNAL_ADDR {\n from {\n source-address-filter 10.0.0.0/8 orlonger;\n }\n then reject;\n }\n term ACCEPT_OTHERS {\n then accept;\n }\n }\n\nVerify that an export source-active filter has been applied to MSDP.\n\nprotocols {\n …\n …\n …\n }\n msdp {\n export SA_EXPORT;\n\nIf the router is not configured with an export policy to block local source-active multicast advertisements, this is a finding.","fixText":"Configure the router with an export policy avoid global visibility of local multicast (S, G) states. The example below will avoid exporting multicast active sources belonging to the private network.\n\n[edit policy-options]\nset policy-statement SA_EXPORT term INTERNAL_GROUP from route-filter 239.0.0.0/8 orlonger\nset policy-statement SA_EXPORT term INTERNAL_GROUP then reject\nset policy-statement SA_EXPORT term INTERNAL_ADDR from source-address-filter 10.0.0.0/8 orlonger\nset policy-statement SA_EXPORT term INTERNAL_ADDR then reject\nset policy-statement SA_EXPORT term ACCEPT_OTHERS then accept\n\n[edit protocols msdp]\nset export SA_EXPORT","ccis":["CCI-001368"]},{"vulnId":"V-217097","ruleId":"SV-217097r604135_rule","severity":"low","ruleTitle":"The Juniper Multicast Source Discovery Protocol (MSDP) router must be configured to limit the amount of source-active messages it accepts on per-peer basis.","description":"To reduce any risk of a denial-of-service (DoS) attack from a rogue or misconfigured MSDP router, the router must be configured to limit the number of source-active messages it accepts from each peer.","checkContent":"Review the router configuration to determine if it is configured to limit the amount of source-active messages it accepts on a per-peer basis.\n\nprotocols {\n …\n …\n …\n }\n msdp {\n export SA_EXPORT;\n import SA_IMPORT;\n group AS25 {\n peer x.x.x.x {\n active-source-limit {\n maximum nnn;\n }\n\nIf the router is not configured to limit the source-active messages it accepts, this is a finding.","fixText":"Configure the router to limit the amount of source-active messages it accepts from each peer.\n\n[edit protocols msdp group AS25 peer x.x.x.x]\nset active-source-limit maximum nnn","ccis":["CCI-001368"]},{"vulnId":"V-217098","ruleId":"SV-217098r992008_rule","severity":"low","ruleTitle":"The Juniper Multicast Source Discovery Protocol (MSDP) router must be configured to use its loopback address as the source address when originating MSDP traffic.","description":"Using a loopback address as the source address offers a multitude of uses for security, access, management, and scalability of MSDP routers. It is easier to construct appropriate ingress filters for router management plane traffic destined to the network management subnet since the source addresses will be from the range used for loopback interfaces instead of a larger range of addresses used for physical interfaces. Log information recorded by authentication and syslog servers will record the router’s loopback address instead of the numerous physical interface addresses.","checkContent":"Review the router configuration to verify that a loopback address has been configured.\n\ninterfaces {\n …\n …\n …\n lo0 {\n unit 0 {\n family inet {\n address 2.2.2.2/32;\n }\n }\n }\n}\n\nVerify that the loopback interface is used as the source address for all MSDP packets generated by the router.\n\nprotocols {\n msdp {\n group AS25 {\n peer 5.5.5.5 {\n local-address 2.2.2.2;\n }\n }\n }\n\nIf the router does not use its loopback address as the source address when originating MSDP traffic, this is a finding.","fixText":"Configure the router to use its loopback address is used as the source address when sending MSDP packets.\n\n[edit protocols msdp]\nset group AS_5 peer 5.5.5.5 local-address 2.2.2.2","ccis":["CCI-004931"]},{"vulnId":"V-233292","ruleId":"SV-233292r604135_rule","severity":"medium","ruleTitle":"The Juniper perimeter router must be configured to suppress Router Advertisements on all external IPv6-enabled interfaces.","description":"Many of the known attacks in stateless autoconfiguration are defined in RFC 3756 were present in IPv4 ARP attacks. To mitigate these vulnerabilities, links that have no hosts connected such as the interface connecting to external gateways must be configured to suppress router advertisements.","checkContent":"This requirement is not applicable for the DODIN Backbone. \n\nReview the router configuration to verify that Router Advertisements are suppressed on all external IPv6-enabled interfaces as shown in the example below.\n\nBy default, router advertisements are disabled by Junos. Verify that there are no external-facing interfaces defined under the protocols router-advertisement hierarchy as shown in the example below.\n\nprotocols {\n router-advertisement {\n interface fe-0/1/0.0 {\n prefix 2001:1:123::/64;\n }\n }\n}\n\nIf the router is not configured to suppress Router Advertisements on all external IPv6-enabled interfaces, this is a finding.","fixText":"Remove any external IPv6-enabled interfaces from the protocols router-advertisement hierarchy.","ccis":["CCI-000366"]},{"vulnId":"V-233293","ruleId":"SV-233293r604135_rule","severity":"medium","ruleTitle":"The Juniper router must not be configured to use IPv6 Site Local Unicast addresses.","description":"As currently defined, site local addresses are ambiguous and can be present in multiple sites. The address itself does not contain any indication of the site to which it belongs. The use of site-local addresses has the potential to adversely affect network security through leaks, ambiguity, and potential misrouting as documented in section 2 of RFC3879. RFC3879 formally deprecates the IPv6 site-local unicast prefix FEC0::/10 as defined in RFC3513.","checkContent":"Review the router configuration to ensure FEC0::/10 IP addresses are not defined. \n\nIf FEC0::/10 IP addresses are defined, this is a finding.","fixText":"Configure the device using authorized IPv6 addresses.","ccis":["CCI-000366"]},{"vulnId":"V-233294","ruleId":"SV-233294r878056_rule","severity":"medium","ruleTitle":"The Juniper perimeter router must be configured drop IPv6 packets with a Routing Header type 0, 1, or 3255.","description":"The routing header can be used maliciously to send a packet through a path where less robust security is in place, rather than through the presumably preferred path of routing protocols. Use of the routing extension header has few legitimate uses other than as implemented by Mobile IPv6. \n\nThe Type 0 Routing Header (RFC 5095) is dangerous because it allows attackers to spoof source addresses and obtain traffic in response, rather than the real owner of the address. Secondly, a packet with an allowed destination address could be sent through a Firewall using the Routing Header functionality, only to bounce to a different node once inside. The Type 1 Routing Header is defined by a specification called \"Nimrod Routing\", a discontinued project funded by DARPA. Assuming that most implementations will not recognize the Type 1 Routing Header, it must be dropped. The Type 3–255 Routing Header values in the routing type field are currently undefined and should be dropped inbound and outbound.","checkContent":"This requirement is not applicable for the DODIN Backbone. \n\nReview the router configuration to determine if it is configured to drop IPv6 packets containing a Routing Header of type 0, 1, or 3-255.\n\nStep 1: Verify that all external IPv6-enabled interfaces have an IPv6 filter as shown in the example below.\n\ninterfaces {\n ge-0/0/0 {\n unit 0 {\n family inet6 {\n filter {\n input IPV6-INGRESS-FILTER;\n }\n address 2001:1:0:146::1/64;\n }\n }\n }\n}\n\nStep 2: Verify that the IPV6 filter blocks all packets with a routing header as shown in the example below.\n\nfirewall {\n family inet6 {\n filter IPV6-INGRESS-FILTER {\n term ROUTING_HEADER {\n from {\n next-header routing;\n }\n then {\n syslog;\n discard;\n }\n }\n term ALLOW_TCP_ESTABLISHED {\n from {\n next-header tcp;\n tcp-established;\n }\n then accept;\n }\n term DENY_BY_DEFAULT {\n then {\n syslog;\n discard;\n }\n }\n }\n }\n}\n\nNote: Currently JUNOS has no method to filter option type within a routing header. Hence, all packets with a routing header must be dropped. \n\n\nIf the router is not configured to drop IPv6 packets containing a Routing Header of type 0, 1, or 3-255, this is a finding.","fixText":"Step 1: Configure a filter to block packets with a routing header as shown in the example.\n\nuser@R1# edit firewall family inet6\nuser@R1# edit filter IPV6-INGRESS-FILTER\nuser@R1# set term ROUTING_HEADER from next-header routing\nuser@R1# set term ROUTING_HEADER then discard syslog\nuser@R1# top\n\nStep 2: Apply the filter inbound on all external IPv6-enabled interfaces.\n\nuser@R1# edit interfaces ge-0/0/0 unit 0 family inet6\nuser@R1# set filter input IPV6-INGRESS-FILTER\nuser@R1# commit","ccis":["CCI-002403"]},{"vulnId":"V-233295","ruleId":"SV-233295r855914_rule","severity":"medium","ruleTitle":"The Juniper perimeter router must be configured to drop IPv6 packets containing a Hop-by-Hop header with invalid option type values.","description":"These options are intended to be for the Destination Options header only. The optional and extensible natures of the IPv6 extension headers require higher scrutiny since many implementations do not always drop packets with headers that it cannot recognize and hence could cause a Denial-of-Service on the target device. In addition, the type, length, value (TLV) formatting provides the ability for headers to be very large.","checkContent":"This requirement is not applicable for the DODIN Backbone. \n\nReview the router configuration to determine if ACLs are bound to the applicable interfaces to drop IPv6 packets containing a Hop-by-Hop header with option type values of 0x04 (Tunnel Encapsulation Limit), 0xC9 (Home Address Destination), or 0xC3 (NSAP Address). \n\nStep 1: Verify that all external IPv6-enabled interfaces have an IPv6 filter as shown in the example below.\n\ninterfaces {\n ge-0/0/0 {\n unit 0 {\n family inet6 {\n filter {\n input IPV6-INGRESS-FILTER;\n }\n address 2001:1:0:146::1/64;\n }\n }\n }\n}\n\nStep 2: Verify that the IPV6 filter blocks all packets with a Hop-by-Hop header as shown in the example below.\n\nfirewall {\n family inet6 {\n filter IPV6-INGRESS-FILTER {\n term HOP_BY_HOP_HEADER {\n from {\n next-header hop-by-hop;\n }\n then {\n syslog;\n discard;\n }\n }\n term ALLOW_TCP_ESTABLISHED {\n from {\n next-header tcp;\n tcp-established;\n }\n then accept;\n }\n term DENY_BY_DEFAULT {\n then {\n syslog;\n discard;\n }\n }\n }\n }\n}\n\n\nNote: Currently JUNOS has no method to filter option type within Hop-by-Hop header. Hence, all packets with the Hop-by-Hop header must be dropped. \n\n\nIf the router is not configured to drop IPv6 packets containing a Hop-by-Hop header with invalid option type values, this is a finding.","fixText":"Configure the router to drop IPv6 packets containing a Hop-by-Hop header as shown in the example below.\nStep 1: Configure a filter to block packets with a Hop-by-Hop header as shown in the example.\n\nuser@R1# edit firewall family inet6\nuser@R1# edit filter IPV6-INGRESS-FILTER\nuser@R1# set term HOP_BY_HOP_HEADER from next-header hop-by-hop\nuser@R1# set term HOP_BY_HOP_HEADER then discard syslog\nuser@R1# top\n\nStep 2: Apply the filter inbound on all external IPv6-enabled interfaces.\n\nuser@R1# edit interfaces ge-0/0/0 unit 0 family inet6\nuser@R1# set filter input IPV6-INGRESS-FILTER\nuser@R1# commit","ccis":["CCI-002403"]},{"vulnId":"V-233296","ruleId":"SV-233296r855915_rule","severity":"medium","ruleTitle":"The Juniper perimeter router must be configured to drop IPv6 packets containing a Destination Option header with invalid option type values.","description":"These options are intended to be for the Hop-by-Hop header only. The optional and extensible natures of the IPv6 extension headers require higher scrutiny since many implementations do not always drop packets with headers that it cannot recognize. Hence, this could cause a Denial-of-Service on the target device. In addition, the type, length, value (TLV) formatting provides the ability for headers to be very large.","checkContent":"This requirement is not applicable for the DODIN Backbone. \n\nReview the router configuration and determine if filters are bound to the external interfaces to drop all IPv6 packets containing a Destination Option header with option type values of 0x05 (Router Alert) or 0xC2 (Jumbo Payload). \n\nThe following example will block any inbound IPv6 packet containing a Destination Option header with option type values of with option type values of 0x05 (Router Alert) or 0xC2 (Jumbo Payload): \nStep 1: Verify that all external IPv6-enabled interfaces have an IPv6 filter as shown in the example below.\n\ninterfaces {\n ge-0/0/0 {\n unit 0 {\n family inet6 {\n filter {\n input IPV6-INGRESS-FILTER;\n }\n address 2001:1:0:146::1/64;\n }\n }\n }\n}\n\nStep 2: Verify that the IPV6 filter blocks all packets with a Destination Option header as shown in the example below.\n\nfirewall {\n family inet6 {\n filter IPV6-INGRESS-FILTER {\n term DEST_ OPT_HEADER {\n from {\n next-header dstops;\n }\n then {\n syslog;\n discard;\n }\n }\n term ALLOW_TCP_ESTABLISHED {\n from {\n next-header tcp;\n tcp-established;\n }\n then accept;\n }\n term DENY_BY_DEFAULT {\n then {\n syslog;\n discard;\n }\n }\n }\n }\n}\n\n\nNote: Currently JUNOS has no method to filter option type within Destination Option header. Hence, all packets with the Destination Option header must be dropped.\n\nIf the router is not configured to drop IPv6 packets containing a Destination Option header with invalid option type values, this is a finding.","fixText":"Step 1: Configure a filter to block packets with a Destination Option header as shown in the example.\n\nuser@R1# edit firewall family inet6\nuser@R1# edit filter IPV6-INGRESS-FILTER\nuser@R1# set term DEST_ OPT_HEADER from next-header dstops\nuser@R1# set term DEST_ OPT_HEADER then discard syslog\nuser@R1# top\n\nStep 2: Apply the filter inbound on all external IPv6-enabled interfaces.\n\nuser@R1# edit interfaces ge-0/0/0 unit 0 family inet6\nuser@R1# set filter input IPV6-INGRESS-FILTER\nuser@R1# commit","ccis":["CCI-002403"]},{"vulnId":"V-233297","ruleId":"SV-233297r855916_rule","severity":"medium","ruleTitle":"The Juniper perimeter router must be configured to drop IPv6 packets containing an extension header with the Endpoint Identification option.","description":"The optional and extensible natures of the IPv6 extension headers require higher scrutiny since many implementations do not always drop packets with headers that it cannot recognize, and hence could cause a Denial-of-Service on the target device. In addition, the type, length, value (TLV) formatting provides the ability for headers to be very large. This option type is associated with the Nimrod Routing system and has no defining RFC document.","checkContent":"This requirement is not applicable for the DODIN Backbone. \n\nReview the router configuration and determine if filters are bound to the applicable interfaces to drop all inbound IPv6 packets containing an option type values of 0x8A (Endpoint Identification) regardless of whether it appears in a Hop-by-Hop or Destination Option header. \n\nThe following example will block IPv6 packet containing either a Hop-by-Hop or Destination Option header: \n\n family inet6 {\n filter IPV6-INGRESS-FILTER {\n term HOP_BY_HOP_HEADER {\n from {\n next-header hop-by-hop;\n }\n then {\n syslog;\n discard;\n }\n }\n term DEST_ OPT_HEADER {\n from {\n next-header dstops;\n }\n then {\n syslog;\n discard;\n }\n }\n term ALLOW_TCP_ESTABLISHED {\n from {\n next-header tcp;\n tcp-established;\n }\n then accept;\n }\n term DENY_BY_DEFAULT {\n then {\n syslog;\n discard;\n }\n }\n }\n }\n}\n\n\nNote: Currently JUNOS has no method to filter option type within either Hop-by-Hop or Destination Option header. Hence, all packets with a Hop-by-Hop or Destination Option headers must be dropped.\n\nIf the router is not configured to drop IPv6 packets containing an extension header with the Endpoint Identification option, this is a finding.","fixText":"Step 1: Configure a filter to block packets with either a Hop-by-Hop or Destination Option header as shown in the example.\n\nuser@R1# edit firewall family inet6\nuser@R1# edit filter IPV6-INGRESS-FILTER\nuser@R1# set term HOP_BY_HOP_HEADER from next-header hop-by-hop\nuser@R1# set term HOP_BY_HOP_HEADER then discard syslog\nuser@R1# set term DEST_ OPT_HEADER from next-header dstops\nuser@R1# set term DEST_ OPT_HEADER then discard syslog\nuser@R1# top\n\nStep 2: Apply the filter inbound on all external IPv6-enabled interfaces.\n\nuser@R1# edit interfaces ge-0/0/0 unit 0 family inet6\nuser@R1# set filter input IPV6-INGRESS-FILTER\nuser@R1# commit","ccis":["CCI-002403"]},{"vulnId":"V-233298","ruleId":"SV-233298r855917_rule","severity":"medium","ruleTitle":"The Juniper perimeter router must be configured to drop IPv6 packets containing the NSAP address option within Destination Option header.","description":"The optional and extensible natures of the IPv6 extension headers require higher scrutiny since many implementations do not always drop packets with headers that it cannot recognize, and hence could cause a Denial-of-Service on the target device. In addition, the type, length, value (TLV) formatting provides the ability for headers to be very large. This option type from RFC 1888 (OSI NSAPs and IPv6) has been deprecated by RFC 4048.","checkContent":"This requirement is not applicable for the DODIN Backbone. \n\nReview the router configuration and determine if filters are bound to the applicable interfaces to drop IPv6 packets containing a Destination Option header with option type value of 0xC3 (NSAP address). \n\nThe following example will block any inbound IPv6 packet containing a Destination Option header: \nStep 1: Verify that all external IPv6-enabled interfaces have an IPv6 filter as shown in the example below.\n\ninterfaces {\n ge-0/0/0 {\n unit 0 {\n family inet6 {\n filter {\n input IPV6-INGRESS-FILTER;\n }\n address 2001:1:0:146::1/64;\n }\n }\n }\n}\n\n\n\nStep 2: Verify that the IPV6 filter blocks all packets with a Destination Option header as shown in the example below.\n\nfirewall {\n family inet6 {\n filter IPV6-INGRESS-FILTER {\n term DEST_ OPT_HEADER {\n from {\n next-header dstops;\n }\n then {\n syslog;\n discard;\n }\n }\n term ALLOW_TCP_ESTABLISHED {\n from {\n next-header tcp;\n tcp-established;\n }\n then accept;\n }\n term DENY_BY_DEFAULT {\n then {\n syslog;\n discard;\n }\n }\n }\n }\n}\n\n\nNote: Currently JUNOS has no method to filter option type within Destination Option header. Hence, all packets with the Destination Option header must be dropped.\n\nIf the router is not configured to drop IPv6 packets containing the NSAP address option within Destination Option header, this is a finding.","fixText":"Step 1: Configure a filter to block packets with a Destination Option header as shown in the example.\n\nuser@R1# edit firewall family inet6\nuser@R1# edit filter IPV6-INGRESS-FILTER\nuser@R1# set term DEST_ OPT_HEADER from next-header dstops\nuser@R1# set term DEST_ OPT_HEADER then discard syslog\nuser@R1# top\n\nStep 2: Apply the filter inbound on all external IPv6-enabled interfaces.\n\nuser@R1# edit interfaces ge-0/0/0 unit 0 family inet6\nuser@R1# set filter input IPV6-INGRESS-FILTER\nuser@R1# commit","ccis":["CCI-002403"]},{"vulnId":"V-233299","ruleId":"SV-233299r855918_rule","severity":"medium","ruleTitle":"The Juniper perimeter router must be configured to drop IPv6 packets containing a Hop-by-Hop or Destination Option extension header with an undefined option type.","description":"The optional and extensible natures of the IPv6 extension headers require higher scrutiny since many implementations do not always drop packets with headers that it cannot recognize, and hence could cause a Denial-of-Service on the target device. In addition, the type, length, value (TLV) formatting provides the ability for headers to be very large.","checkContent":"This requirement is not applicable for the DODIN Backbone. \n\nReview the router configuration and determine if filters are bound to the applicable interfaces to drop all inbound IPv6 packets containing an undefined option type value regardless of whether they appear in a Hop-by-Hop or Destination Option header. Undefined values are 0x02, 0x03, 0x06, 0x9 – 0xE, 0x10 – 0x22, 0x24, 0x25, 0x27 – 0x2F, and 0x31 – 0xFF.\n\nThe following example will block any inbound IPv6 packet containing either a Hop-by-Hop or Destination Option header: \n\n family inet6 {\n filter IPV6-INGRESS-FILTER {\n term HOP_BY_HOP_HEADER {\n from {\n next-header hop-by-hop;\n }\n then {\n syslog;\n discard;\n }\n }\n term DEST_ OPT_HEADER {\n from {\n next-header dstops;\n }\n then {\n syslog;\n discard;\n }\n }\n term ALLOW_TCP_ESTABLISHED {\n from {\n next-header tcp;\n tcp-established;\n }\n then accept;\n }\n term DENY_BY_DEFAULT {\n then {\n syslog;\n discard;\n }\n }\n }\n }\n}\n\n\n\nNote: Currently JUNOS has no method to filter option type within either Hop-by-Hop or Destination Option header. Hence, all packets with a Hop-by-Hop or Destination Option headers must be dropped.\n\nIf the router is not configured to drop IPv6 packets containing a Hop-by-Hop or Destination Option extension header with an undefined option type, this is a finding.","fixText":"Step 1: Configure a filter to block packets with either a Hop-by-Hop or Destination Option header as shown in the example.\n\nuser@R1# edit firewall family inet6\nuser@R1# edit filter IPV6-INGRESS-FILTER\nuser@R1# set term HOP_BY_HOP_HEADER from next-header hop-by-hop\nuser@R1# set term HOP_BY_HOP_HEADER then discard syslog\nuser@R1# set term DEST_ OPT_HEADER from next-header dstops\nuser@R1# set term DEST_ OPT_HEADER then discard syslog\nuser@R1# top\n\nStep 2: Apply the filter inbound on all external IPv6-enabled interfaces.\n\nuser@R1# edit interfaces ge-0/0/0 unit 0 family inet6\nuser@R1# set filter input IPV6-INGRESS-FILTER\nuser@R1# commit","ccis":["CCI-002403"]}]}