Juniper Router RTR Security Technical Implementation Guide
Pick two releases to diff their requirements.
Open a previous version of this STIG.
- RMF Control
- AC-4
- Severity
- M
- CCI
- CCI-001368
- Version
- JUNI-RT-000010
- Vuln IDs
-
- JUNI-RT-000010
- Rule IDs
-
- JUNI-RT-000010_rule
Checks: C-JUNI-RT-000010_chk
This requirement is not applicable for the DoDIN Backbone. Review 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. interfaces { ge-0/0/0 { unit 0 { family inet { filter { input FILTER_SERVER_TRAFFIC; } address 11.1.12.2/24; } } } … … … firewall { family inet { filter FILTER_SERVER_TRAFFIC { term PRINT_FILTER { from { destination-address { 11.1.23.0/24; } protocol tcp; destination-port [ 515 631 9100 ]; } then accept; } term SQL_FILTER { from { destination-address { 11.1.24.0/24; } protocol tcp; destination-port [ 1433 1434 4022 ]; } then accept; } term ALLOW_BGP { from { protocol tcp; destination-port bgp; } then accept; } term ALLOW_OSPF { from { protocol ospf; } then accept; } term ALLOW_ICMP { from { protocol icmp; } then accept; } term DENY_ALL_OTHER { then { log; syslog; reject; } } } If 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.
Fix: F-JUNI-RT-000010_fix
This requirement is not applicable for the DoDIN Backbone. Configure 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. [edit firewall family inet] set filter FILTER_SERVER_TRAFFIC term PRINT_FILTER from destination-address 11.1.23.0/24 set filter FILTER_SERVER_TRAFFIC term PRINT_FILTER from protocol tcp destination-port [515 631 9100] set filter FILTER_SERVER_TRAFFIC term PRINT_FILTER then accept set filter FILTER_SERVER_TRAFFIC term SQL_FILTER from destination-address 11.1.24.0/24 set filter FILTER_SERVER_TRAFFIC term SQL_FILTER from protocol tcp destination-port [1433 1434 4022] set filter FILTER_SERVER_TRAFFIC term SQL_FILTER then accept set filter FILTER_SERVER_TRAFFIC term ALLOW_OSPF from protocol ospf set filter FILTER_SERVER_TRAFFIC term ALLOW_OSPF then accept set filter FILTER_SERVER_TRAFFIC term ALLOW_ICMP from protocol icmp set filter FILTER_SERVER_TRAFFIC term ALLOW_ICMP then accept set filter FILTER_SERVER_TRAFFIC term DENY_ALL_OTHER then log reject [edit interfaces ge-0/0/0 unit 0 family inet] set filter input FILTER_SERVER_TRAFFIC
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- JUNI-RT-000020
- Vuln IDs
-
- JUNI-RT-000020
- Rule IDs
-
- JUNI-RT-000020_rule
Checks: C-JUNI-RT-000020_chk
Review the router configuration. Verify that neighbor router authentication is enabled for all routing protocols. The configuration examples below depicts OSPF and BGP authentication. protocols { bgp { group AS_5 { type external; peer-as 5; neighbor x.x.x.x { authentication-key "$9$tBga0ORx7VsYoIEgJ"; ## SECRET-DATA } } } ospf { area 0.0.0.0 { interface ge-0/0/0 { authentication { simple-password "$9$NHVb2mPQ3nCYg/t"; ## SECRET-DATA } } interface ge-0/1/0 { authentication { simple-password "$9$Lgb7NbHkPTQnVwF/"; ## SECRET-DATA } } interface lo0.0; interface ge-0/2/0 { authentication { simple-password "$9$7DdVY.mTF39s26A"; ## SECRET-DATA } } } } } If authentication is not enabled, this is a finding.
Fix: F-JUNI-RT-000020_fix
Configure authentication to be enabled for every protocol that affects the routing or forwarding tables. The example configuration commands below enables OSPF and BGP authentication. [edit protocols ospf area 0.0.0.0] set interface ge-0/0/0 authentication simple-password xxxxxxxxxxxx set interface ge-0/1/0 authentication simple-password xxxxxxxxxxxx set interface ge-0/2/0 authentication simple-password xxxxxxxxxxxx [edit protocols bgp group AS_2 neighbor x.x.x.x] set authentication-key xxxxxxxxxxxxxxx
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- JUNI-RT-000030
- Vuln IDs
-
- JUNI-RT-000030
- Rule IDs
-
- JUNI-RT-000030_rule
Checks: C-JUNI-RT-000030_chk
This requirement is not applicable for the DoDIN Backbone. Review the start times for each key within the configured key chains used for routing protocol authentication as shown in the example below. security { … … … authentication-key-chains { key-chain BGP_KEY { key 1 { secret "$9$PTQnhclvMX3687"; ## SECRET-DATA start-time "2018-5-1.12:00:00 +0000"; } key 2 { secret "$9$iq.5OBESyKfTlM"; ## SECRET-DATA start-time "2018-9-1.12:00:00 +0000"; } key 3 { secret "$9$ZADjqAtOIRSk.hr"; ## SECRET-DATA start-time "2019-1-1.12:00:00 +0000"; } } } } Note: Currently Junos does not support key chains for OSPF and RIP If any key has a lifetime of more than 180 days, this is a finding.
Fix: F-JUNI-RT-000030_fix
This requirement is not applicable for the DoDIN Backbone. Configure each key used for routing protocol authentication to have a lifetime of no more than 180 days as shown in the example below. [edit security authentication-key-chains] set key-chain BGP_KEY key 1 start-time 2018-05-01.12:00 secret xxxxxxxxxxxxx set key-chain BGP_KEY key 2 start-time 2018-09-01.12:00 secret xxxxxxxxxxxxx set key-chain BGP_KEY key 3 start-time 2019-01-01.12:00 secret xxxxxxxxxxxxx
- RMF Control
- IA-7
- Severity
- M
- CCI
- CCI-000803
- Version
- JUNI-RT-000040
- Vuln IDs
-
- JUNI-RT-000040
- Rule IDs
-
- JUNI-RT-000040_rule
Checks: C-JUNI-RT-000040_chk
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. OSPF Example: protocols { … … … ospf { area 0.0.0.0 { interface ge-0/0/0 { authentication { md5 1 key "$9$NHVb2mPQ3nCYg/t"; ## SECRET-DATA } } interface ge-0/1/0 { authentication { md5 1 key "$9$Lgb7NbHkPTQnVwF/"; ## SECRET-DATA } } interface lo0.0; interface ge-0/2/0 { authentication { md5 1 key "$9$7DdVY.mTF39s26A"; ## SECRET-DATA } } } } } IS-IS Example: security { … … … } authentication-key-chains { key-chain ISIS_KEY { key 1 { secret "$9$W8oXxdji.f5F-VQn"; ## SECRET-DATA start-time "2018-5-1.12:00:00 +0000"; algorithm hmac-sha-1; options isis-enhanced; } key 2 { secret "$9$Q4953nCrlMLX-9A7V"; ## SECRET-DATA start-time "2018-9-1.12:00:00 +0000"; algorithm hmac-sha-1; options isis-enhanced; } key 3 { secret "$9$UeiHmpu1Ehr.PSe"; ## SECRET-DATA start-time "2019-1-1.12:00:00 +0000"; algorithm hmac-sha-1; options isis-enhanced; } } } } protocols { … … … isis { level 1 authentication-key-chain ISIS_KEY; level 2 authentication-key-chain ISIS_KEY; interface ge-0/0/0 { level 1 hello-authentication-key-chain ISIS_KEY; level 2 hello-authentication-key-chain ISIS_KEY; } interface lo0.0; } BGP Example: security { … … … } authentication-key-chains { key-chain BGP_KEY { key 1 { secret "$9$PTQnhclvMX3687"; ## SECRET-DATA start-time "2018-5-1.12:00:00 +0000"; } key 2 { secret "$9$iq.5OBESyKfTlM"; ## SECRET-DATA start-time "2018-9-1.12:00:00 +0000"; } key 3 { secret "$9$ZADjqAtOIRSk.hr"; ## SECRET-DATA start-time "2019-1-1.12:00:00 +0000"; } } protocols { bgp { group AS_2 { type external; peer-as 2; neighbor 11.1.25.2 { authentication-algorithm md5; authentication-key-chain BGP_KEY; } neighbor 11.1.1.1 { authentication-algorithm hmac-sha-1-96; authentication-key-chain BGP_KEY; } } } If the routing protocol is not encrypting the authentication key, this is a finding.
Fix: F-JUNI-RT-000040_fix
Configure all routing protocol authentications to encrypt the authentication key. OSPF Example: [edit protocols ospf area 0.0.0.0] set interface ge-0/0/0 authentication md5 1 key xxxxxxxxxxxx set interface ge-0/1/0 authentication md5 1 key xxxxxxxxxxxx set interface ge-0/2/0 authentication md5 1 key xxxxxxxxxxxx IS-IS Example: [edit security authentication-key-chains] set key-chain ISIS_KEY key 1 options isis-enhanced set key-chain ISIS_KEY key 2 options isis-enhanced set key-chain ISIS_KEY key 3 options isis-enhanced set key-chain ISIS_KEY key 1 start-time 2018-05-01.12:00 algorithm hmac-sha-1 secret xxxxxxxxxxxxx set key-chain ISIS_KEY key 2 start-time 2018-09-01.12:00 algorithm hmac-sha-1 secret xxxxxxxxxxxxx set key-chain ISIS_KEY key 3 start-time 2019-01-01.12:00 algorithm hmac-sha-1 secret xxxxxxxxxxxxx [edit protocols] set isis level 1 authentication-key-chain ISIS_KEY set isis interface ge-0/0/0 level 1 hello-authentication-key-chain ISIS_KEY set isis interface ge-0/0/0 level 2 hello-authentication-key-chain ISIS_KEY BGP Example: [edit security authentication-key-chains] set key-chain BGP_KEY key 1 start-time 2018-05-01.12:00 secret xxxxxxxxxxxxx set key-chain BGP_KEY key 2 start-time 2018-09-01.12:00 secret xxxxxxxxxxxxx set key-chain BGP_KEY key 3 start-time 2019-01-01.12:00 secret xxxxxxxxxxxxx [edit protocols bgp group AS_5] set neighbor 11.1.25.5 authentication-algorithm hmac-sha-1-96 set neighbor 11.1.25.5 authentication-key-chain BGP_KEY set neighbor 11.1.1.1 authentication-algorithm hmac-sha-1-96 set neighbor 11.1.1.1 authentication-key-chain BGP_KEY
- RMF Control
- IA-7
- Severity
- M
- CCI
- CCI-000803
- Version
- JUNI-RT-000050
- Vuln IDs
-
- JUNI-RT-000050
- Rule IDs
-
- JUNI-RT-000050_rule
Checks: C-JUNI-RT-000050_chk
Review the router configuration to verify it is using a NIST-validated FIPS 140-2 message authentication code algorithm to authenticate routing protocol messages. IS-IS Example: security { … … … } authentication-key-chains { key-chain ISIS_KEY { key 1 { secret "$9$W8oXxdji.f5F-VQn"; ## SECRET-DATA start-time "2018-5-1.12:00:00 +0000"; algorithm hmac-sha-1; options isis-enhanced; } key 2 { secret "$9$Q4953nCrlMLX-9A7V"; ## SECRET-DATA start-time "2018-9-1.12:00:00 +0000"; algorithm hmac-sha-1; options isis-enhanced; } key 3 { secret "$9$UeiHmpu1Ehr.PSe"; ## SECRET-DATA start-time "2019-1-1.12:00:00 +0000"; algorithm hmac-sha-1; options isis-enhanced; } } } } protocols { … … … isis { level 1 authentication-key-chain ISIS_KEY; level 2 authentication-key-chain ISIS_KEY; interface ge-0/0/0 { level 1 hello-authentication-key-chain ISIS_KEY; level 2 hello-authentication-key-chain ISIS_KEY; } interface lo0.0; } BGP Example: } security { … … … } authentication-key-chains { key-chain BGP_KEY { key 1 { secret "$9$PTQnhclvMX3687"; ## SECRET-DATA start-time "2018-5-1.12:00:00 +0000"; } key 2 { secret "$9$iq.5OBESyKfTlM"; ## SECRET-DATA start-time "2018-9-1.12:00:00 +0000"; } key 3 { secret "$9$ZADjqAtOIRSk.hr"; ## SECRET-DATA start-time "2019-1-1.12:00:00 +0000"; } } protocols { bgp { group AS_2 { type external; peer-as 2; neighbor 11.1.25.2 { authentication-algorithm md5; authentication-key-chain BGP_KEY; } neighbor 11.1.1.1 { authentication-algorithm hmac-sha-1-96; authentication-key-chain BGP_KEY; } } } OSPF Example: IPsec authentication must be used to authenticate OSPF messages with a FIPS 140-2 message authentication code algorithm. Verify that an IPsec security association has been configured on the interfaces as shown in the following example: protocols { … … … ospf { area 0.0.0.0 { interface ge-0/0/0 { ipsec-sa IPSEC-SA1; } interface ge-0/1/0 { ipsec-sa IPSEC-SA1; } interface lo0.0; interface ge-0/2/0 { ipsec-sa IPSEC-SA1; } } } } Verify the authentication algorithm in the IPsec security association as shown in the example below. security { … … … ipsec { security-association IPSEC-SA1 { mode transport; manual { direction bidirectional { protocol ah; spi 256; authentication { algorithm hmac-sha1-96; key ascii-text "$9$u6M6OEcrevL7-YaZUjHmF39B1hP5CuBRle"; ## SECRET-DATA } } } } } If a NIST-validated FIPS 140-2 message authentication code algorithm is not being used to authenticate routing protocol messages, this is a finding. Note: Juniper does not support FIPS 140-2 message authentication code algorithm for OSPFv2 and RIP.
Fix: F-JUNI-RT-000050_fix
Configure routing protocol authentication to use a NIST-validated FIPS 140-2 message authentication code algorithm. IS-IS Example: [edit security authentication-key-chains] set key-chain ISIS_KEY key 1 options isis-enhanced set key-chain ISIS_KEY key 2 options isis-enhanced set key-chain ISIS_KEY key 3 options isis-enhanced set key-chain ISIS_KEY key 1 start-time 2018-05-01.12:00 algorithm hmac-sha-1 secret xxxxxxxxxxxxx set key-chain ISIS_KEY key 2 start-time 2018-09-01.12:00 algorithm hmac-sha-1 secret xxxxxxxxxxxxx set key-chain ISIS_KEY key 3 start-time 2019-01-01.12:00 algorithm hmac-sha-1 secret xxxxxxxxxxxxx [edit protocols] set isis level 1 authentication-key-chain ISIS_KEY set isis interface ge-0/0/0 level 1 hello-authentication-key-chain ISIS_KEY set isis interface ge-0/0/0 level 2 hello-authentication-key-chain ISIS_KEY BGP Example: [edit security authentication-key-chains] set key-chain BGP_KEY key 1 start-time 2018-05-01.12:00 secret xxxxxxxxxxxxx set key-chain BGP_KEY key 2 start-time 2018-09-01.12:00 secret xxxxxxxxxxxxx set key-chain BGP_KEY key 3 start-time 2019-01-01.12:00 secret xxxxxxxxxxxxx [edit protocols bgp group AS_5] set neighbor 11.1.25.5 authentication-algorithm hmac-sha-1-96 set neighbor 11.1.25.5 authentication-key-chain BGP_KEY set neighbor 11.1.1.1 authentication-algorithm hmac-sha-1-96 set neighbor 11.1.1.1 authentication-key-chain BGP_KEY OSPF Example: Configure IPsec Security Association [edit security ipsec] set security-association IPSEC-SA1 set security-association IPSEC-SA1 mode transport set security-association IPSEC-SA1 manual direction bidirectional set security-association IPSEC-SA1 manual direction bidirectional protocol ah set security-association IPSEC-SA1 manual direction bidirectional spi 256 set security-association IPSEC-SA1 manual direction bidirectional authentication algorithm hmac-sha1-96 key ascii-text 1234567890abcdefghij [edit protocols ospf area 0.0.0.0] set interface ge-0/0/0 ipsec-sa IPSEC-SA1 set interface ge-0/1/0 ipsec-sa IPSEC-SA1 set interface ge-0/2/0 0 ipsec-sa IPSEC-SA1
- RMF Control
- AC-4
- Severity
- L
- CCI
- CCI-001414
- Version
- JUNI-RT-000060
- Vuln IDs
-
- JUNI-RT-000060
- Rule IDs
-
- JUNI-RT-000060_rule
Checks: C-JUNI-RT-000060_chk
Review the router configuration and verify that inactive interfaces have been disabled as shown below. interfaces { ge-1/1/0 { disable; unit 0 { } } If an interface is not being used but is configured or enabled, this is a finding.
Fix: F-JUNI-RT-000060_fix
Disable all inactive interfaces as shown below. [edit interfaces] set ge-1/1/0 disable
- RMF Control
- CM-7
- Severity
- L
- CCI
- CCI-000381
- Version
- JUNI-RT-000070
- Vuln IDs
-
- JUNI-RT-000070
- Rule IDs
-
- JUNI-RT-000070_rule
Checks: C-JUNI-RT-000070_chk
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. If J-web is not used for administrative access, the web-management services must not be configured as shown below. If DHCP server is not being deployed on the router, the command dhcp-local-server must not be configured as shown below. system { … … … services { web-management { https { interface ge-0/0/0.0; } } finger; ftp; ssh { protocol-version v2; macs [ hmac-sha1-96 hmac-sha2-256 hmac-sha2-512 ]; } telnet; netconf { ssh; } dhcp-local-server { group DHCP_GROUP { interface ge-0/1/0.0; } } } If unnecessary services and functions are enabled on the router, this is a finding.
Fix: F-JUNI-RT-000070_fix
Remove unneeded services and functions from the router as shown below. [edit system services] delete telnet [edit system services] delete finger [edit system services] delete ftp
- RMF Control
- SC-5
- Severity
- M
- CCI
- CCI-002385
- Version
- JUNI-RT-000120
- Vuln IDs
-
- JUNI-RT-000120
- Rule IDs
-
- JUNI-RT-000120_rule
Checks: C-JUNI-RT-000120_chk
Determine whether control plane protection has been implemented on the router. Verify that a CoPP policy has been configured that classifies traffic types into levels of importance. firewall { family inet { … … … } filter CoPP_Policy { term CRITICAL { from { protocol [ ospf pim tcp ]; source-port bgp; destination-port bgp; } then policer CRITICAL_POLICER; } term IMPORTANT { from { protocol [ tcp udp ]; destination-port [ ssh tacacs snmp ntp ]; } then { policer IMPORTANT_POLICER; } } term NORMAL { from { protocol icmp; icmp-type [ echo-reply echo-request ]; icmp-code [ port-unreachable ttl-eq-zero-during-transit ]; } then policer NORMAL_POLICER; } term UNDESIRABLE { from { protocol udp; } then policer UNDESIRABLE_POLICER; } term ALL-OTHER { from { address { 0.0.0.0/0; } } then policer ALL-OTHER_POLICER; } } } Verify that policers have been configured to rate limit traffic types. firewall { family inet { … … … } policer CRITICAL_POLICER { filter-specific; if-exceeding { bandwidth-limit 3m; burst-size-limit 4k; } then discard; } policer IMPORTANT_POLICER { filter-specific; if-exceeding { bandwidth-limit 400k; burst-size-limit 1500; } then discard; } policer NORMAL_POLICER { filter-specific; if-exceeding { bandwidth-limit 55k; burst-size-limit 1500; } then discard; } policer UNDESIRABLE_POLICER { filter-specific; if-exceeding { bandwidth-limit 32k; burst-size-limit 1500; } then discard; } policer ALL-OTHER_POLICER { filter-specific; if-exceeding { bandwidth-limit 40k; burst-size-limit 1500; } then discard; } Verify that the CoPP policy has been applied to the loopback interface as shown in the example below interfaces { … … … lo0 { unit 0 { family inet { filter { input CoPP_Policy; } address 2.2.2.2/32; } } } } If the router does not have control plane protection implemented, this is a finding.
Fix: F-JUNI-RT-000120_fix
Implement control plane protection by classifying traffic types based on importance and rate limit the traffic accordingly as shown in the example below. Create filters for critical, important, normal, and undesirable traffic set firewall filter CoPP_Policy term CRITICAL from protocol ospf set firewall filter CoPP_Policy term CRITICAL from protocol pim set firewall filter CoPP_Policy term CRITICAL from protocol tcp destination-port bgp set firewall filter CoPP_Policy term CRITICAL from protocol tcp source-port bgp set firewall filter CoPP_Policy term CRITICAL then policer CRITICAL_POLICER set firewall filter CoPP_Policy term IMPORTANT from protocol tcp destination-port ssh set firewall filter CoPP_Policy term IMPORTANT from protocol tcp destination-port tacacs set firewall filter CoPP_Policy term IMPORTANT from protocol tcp destination-port snmp set firewall filter CoPP_Policy term IMPORTANT from protocol tcp destination-port ntp set firewall filter CoPP_Policy term IMPORTANT then policer IMPORTANT_POLICER set firewall filter CoPP_Policy term NORMAL from protocol icmp icmp-code ttl-eq-zero-during-transit set firewall filter CoPP_Policy term NORMAL from protocol icmp icmp-code port-unreachable set firewall filter CoPP_Policy term NORMAL from protocol icmp icmp-type echo-reply set firewall filter CoPP_Policy term NORMAL from protocol icmp icmp-type echo-request set firewall filter CoPP_Policy term NORMAL then policer NORMAL_POLICER set firewall filter CoPP_Policy term UNDESIRABLE from protocol udp set firewall filter CoPP_Policy term UNDESIRABLE then policer UNDESIRABLE_POLICER set firewall filter CoPP_Policy term ALL-OTHER from address 0.0.0.0/0 set firewall filter CoPP_Policy term ALL-OTHER then policer ALL-OTHER_POLICER Create policers for each traffic type to limit bandwidth set firewall policer CRITICAL_POLICER filter-specific set firewall policer CRITICAL_POLICER if-exceeding bandwidth-limit 3000000 burst-size-limit 4000 set firewall policer CRITICAL_POLICER then discard set firewall policer IMPORTANT_POLICER filter-specific set firewall policer IMPORTANT_POLICER if-exceeding bandwidth-limit 400000 burst-size-limit 1500 set firewall policer IMPORTANT_POLICER then discard set firewall policer NORMAL_POLICER filter-specific set firewall policer NORMAL_POLICER if-exceeding bandwidth-limit 55000 burst-size-limit 150000 set firewall policer NORMAL_POLICER then discard set firewall policer UNDESIRABLE_POLICER filter-specific set firewall policer UNDESIRABLE_POLICER if-exceeding bandwidth-limit 32000 burst-size-limit 1500 set firewall policer UNDESIRABLE_POLICER then discard set firewall policer ALL-OTHER_POLICER filter-specific set firewall policer ALL-OTHER_POLICER if-exceeding bandwidth-limit 40000 burst-size-limit 1500 set firewall policer ALL-OTHER_POLICER then discard Apply the CoPP policy to the loopback interface set interface lo0 unit 0 family inet filter input CoPP_Policy
- RMF Control
- SC-7
- Severity
- H
- CCI
- CCI-001097
- Version
- JUNI-RT-000130
- Vuln IDs
-
- JUNI-RT-000130
- Rule IDs
-
- JUNI-RT-000130_rule
Checks: C-JUNI-RT-000130_chk
Review the filter for the router’s receive path and verify that it will only allow specific management plane traffic from specific sources. Verify filter has been configured as shown in the example below firewall { family inet { … … … } filter DESTINED_TO_RP { term ALLOW_OSPF { from { protocol ospf; } then accept; } term ALLOW_BGP { from { source-address { 11.1.12.1/32; 11.1.23.3/32; 11.1.25.5/32; } protocol tcp; port bgp; } } term FILTER_TCP { from { destination-address { 11.1.12.0/24; } protocol tcp; destination-port [ ssh tacacs telnet snmp ]; } then accept; } term FILTER_UDP { from { destination-address { 11.1.12.0/24; } protocol udp; destination-port ntp; } then accept; } term ICMP_ANY { from { protocol icmp; } then accept; } term DENY_BY_DEFAULT { then { log; discard; } } } } Verify input filter has been applied to loopback interface as shown in the example below interfaces { … … … lo0 { unit 0 { family inet { filter { input-list [ DESTINED_TO_RP CoPP_Policy ]; } address 2.2.2.2/32; } } } } If the router is not configured with a receive-path filter to restrict traffic destined to itself, this is a finding.
Fix: F-JUNI-RT-000130_fix
Configure the router’s receive path filters to restrict traffic destined to the router. Configure a filter to define what traffic should be received by the route processor. [edit firewall family inet] set filter DESTINED_TO_RP term FILTER_TCP from destination-address 11.1.12.0/24 set filter DESTINED_TO_RP term FILTER_TCP from protocol tcp destination-port ssh set filter DESTINED_TO_RP term FILTER_TCP from protocol tcp destination-port tacacs set filter DESTINED_TO_RP term FILTER_TCP from protocol tcp destination-port snmp set filter DESTINED_TO_RP term FILTER_TCP then accept set filter DESTINED_TO_RP term FILTER_UDP from destination-address 11.1.12.0/24 set filter DESTINED_TO_RP term FILTER_UDP from protocol udp destination-port ntp set filter DESTINED_TO_RP term FILTER_UDP then accept set filter DESTINED_TO_RP term ICMP_ANY from protocol icmp set filter DESTINED_TO_RP term ICMP_ANY from protocol icmp then accept set filter DESTINED_TO_RP term DENY_BY_DEFAULT then log discard Apply the filter to the loopback interface. [edit interfaces lo0 unit 0 family inet] set filter input-list DESTINED_TO_RP
- RMF Control
- SC-7
- Severity
- M
- CCI
- CCI-001097
- Version
- JUNI-RT-000140
- Vuln IDs
-
- JUNI-RT-000140
- Rule IDs
-
- JUNI-RT-000140_rule
Checks: C-JUNI-RT-000140_chk
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. firewall { family inet { … … … } filter DESTINED_TO_RP { … … … } term BLOCK_ICMP_FRAG { from { is-fragment; protocol icmp; } then { discard; } } term ICMP_ANY { from { protocol icmp; } then accept; } term DENY_BY_DEFAULT { then { log; discard; } } } } If the router is not configured to filter to drop all fragmented ICMP packets destined to itself, this is a finding.
Fix: F-JUNI-RT-000140_fix
Configure the filter that is applied inbound to the loopback interface to drop all fragmented ICMP packets as shown in the example below. [edit firewall family inet filter DESTINED_TO_RP] set term BLOCK_ICMP_FRAG from protocol icmp is-fragment set term BLOCK_ICMP_FRAG then discard insert term BLOCK_ICMP_FRAG before term DENY_BY_DEFAULT
- RMF Control
- SC-5
- Severity
- M
- CCI
- CCI-002385
- Version
- JUNI-RT-000150
- Vuln IDs
-
- JUNI-RT-000150
- Rule IDs
-
- JUNI-RT-000150_rule
Checks: C-JUNI-RT-000150_chk
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 If gratuitous ARP is enabled on any external interface, this is a finding.
Fix: F-JUNI-RT-000150_fix
Disable gratuitous ARP on all external interfaces using the following command [edit interfaces ge-1/1/0 ] delete gratuitous-arp-reply
- RMF Control
- SC-5
- Severity
- M
- CCI
- CCI-002385
- Version
- JUNI-RT-000170
- Vuln IDs
-
- JUNI-RT-000170
- Rule IDs
-
- JUNI-RT-000170_rule
Checks: C-JUNI-RT-000170_chk
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. firewall { family inet { … … … } filter FILTER_INBOUND { term ALLOW_XYZ { from { protocol xyz; } then accept; } … … … } term DENY_BY_DEFAULT { then { log; discard; } } } } If ICMP unreachable notifications are sent for packets that are dropped, this is a finding.
Fix: F-JUNI-RT-000170_fix
[edit firewall family inet] set filter FILTER_INBOUND term DENY_BY_DEFAULT then log discard
- RMF Control
- SC-5
- Severity
- M
- CCI
- CCI-002385
- Version
- JUNI-RT-000180
- Vuln IDs
-
- JUNI-RT-000180
- Rule IDs
-
- JUNI-RT-000180_rule
Checks: C-JUNI-RT-000180_chk
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. firewall { family inet { … … … } filter DESTINED_TO_RP { term ALLOW_XYZ { from { protocol xyz; } then accept; } … … … } term DENY_MASK_REQUEST { from { protocol icmp; icmp-type mask-request; } then { discard; } } term ICMP_ANY { from { protocol icmp; } then accept; } term DENY_BY_DEFAULT { then { log; discard; } } } } If the router is not configured to silently drop all ICMP Mask Reply messages destined to the router, this is a finding.
Fix: F-JUNI-RT-000180_fix
Configure the filter protecting the routing engine to silently drop all ICMP Mask Request messages destined to the router. [edit firewall family inet filter DESTINED_TO_RP] set term DENY_MASK_REQUEST from protocol icmp icmp-type mask-request insert term DENY_MASK_REQUEST before term ALLOW_ICMP
- RMF Control
- SC-5
- Severity
- M
- CCI
- CCI-002385
- Version
- JUNI-RT-000190
- Vuln IDs
-
- JUNI-RT-000190
- Rule IDs
-
- JUNI-RT-000190_rule
Checks: C-JUNI-RT-000190_chk
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. interfaces { ge-1/0/0 { unit 0 { family inet { no-redirects; address 11.1.12.2/24; } } } ge-1/1/0 { unit 0 { family inet { no-redirects; address 11.1.23.2/24; } } } If ICMP Redirect messages are enabled on any external interfaces, this is a finding.
Fix: F-JUNI-RT-000190_fix
Disable ICMP redirects on all external interfaces as shown in the example below. [edit interfaces] set ge-1/0/0 unit 0 family inet no-redirects set ge-1/1/0 unit 0 family inet no-redirects
- RMF Control
- AU-3
- Severity
- L
- CCI
- CCI-000134
- Version
- JUNI-RT-000200
- Vuln IDs
-
- JUNI-RT-000200
- Rule IDs
-
- JUNI-RT-000200_rule
Checks: C-JUNI-RT-000200_chk
Review all filters to verify that packets that are discarded or rejected are logged as shown in the configuration below. firewall { family inet { filter XYZ … … … } term DENY_BY_DEFAULT { then { syslog; discard; } } } } Verify that logging is enabled to capture packets that are dropped as shown in the configuration below. system { host-name XYZ; … … … } syslog { file LOG_FILE { firewall any; } } } Note: The “any” parameter can be configured in lieu of the “firewall” parameter. If packets being dropped are not logged, this is a finding.
Fix: F-JUNI-RT-000200_fix
Configure the firewall terms that discards or rejects packets to log the action as shown in the example below. [edit firewall family inet] set filter FILTER_INBOUND term DENY_BY_DEFAULT then syslog discard Configure logging to record packets being dropped by firewall filters as shown in the example below. [edit system syslog] set file LOG_FILE firewall any Note: The “any” parameter can be configured in lieu of the “firewall” parameter.
- RMF Control
- AU-3
- Severity
- M
- CCI
- CCI-000132
- Version
- JUNI-RT-000210
- Vuln IDs
-
- JUNI-RT-000210
- Rule IDs
-
- JUNI-RT-000210_rule
Checks: C-JUNI-RT-000210_chk
Review the router configuration to verify that events are logged containing information to establish where the events occurred as shown in the example below. system { host-name XYZ; … … … } syslog { file LOG_FILE { any any; } } } If the router is not configured to produce audit records containing information to establish to establish where the events occurred, this is a finding.
Fix: F-JUNI-RT-000210_fix
Configure the router to log events containing information to establish where the events occurred as shown in the example below. [edit system syslog] set file LOG_FILE any any
- RMF Control
- AU-3
- Severity
- M
- CCI
- CCI-000133
- Version
- JUNI-RT-000220
- Vuln IDs
-
- JUNI-RT-000220
- Rule IDs
-
- JUNI-RT-000220_rule
Checks: C-JUNI-RT-000220_chk
Review the router configuration to verify that events are logged containing information to establish where the events occurred as shown in the example below. system { host-name XYZ; … … … } syslog { file LOG_FILE { any any; } } } If the router is not configured to produce audit records containing information to establish the source of the events, this is a finding.
Fix: F-JUNI-RT-000220_fix
Configure the router to log events containing information to establish where the events occurred as shown in the example below. [edit system syslog] set file LOG_FILE any any
- RMF Control
- AC-4
- Severity
- L
- CCI
- CCI-001414
- Version
- JUNI-RT-000230
- Vuln IDs
-
- JUNI-RT-000230
- Rule IDs
-
- JUNI-RT-000230_rule
Checks: C-JUNI-RT-000230_chk
Review the configuration and verify that the auxiliary port is disabled unless a secured modem providing encryption and authentication is connected to it. system { host-name XYZ; … … … ports { auxiliary { disable; type xterm; } } Note: If the auxiliary port has never been configured or has been removed from the configuration, it will not be shown in the configuration. If the auxiliary port is not disabled or is not connected to a secured modem when it is enabled, this is a finding.
Fix: F-JUNI-RT-000230_fix
Disable the auxiliary port. [edit system ports] set auxiliary disable Note: If used for out-of-band administrative access, the port must be connected to a secured modem providing encryption and authentication.
- RMF Control
- SC-7
- Severity
- H
- CCI
- CCI-001109
- Version
- JUNI-RT-000240
- Vuln IDs
-
- JUNI-RT-000240
- Rule IDs
-
- JUNI-RT-000240_rule
Checks: C-JUNI-RT-000240_chk
This requirement is not applicable for the DoDIN Backbone. Review 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. Verify that an inbound filter is applied to all external interfaces as shown in the example below. interfaces { ge-0/0/0 { unit 0 { family inet { filter { input FILTER_INBOUND_TRAFFIC; } address 11.1.12.2/24; } } } Review inbound filters to verify that the ending term is configured to deny all other traffic that is not explicitly allowed. firewall { family inet { filter FILTER_INBOUND_TRAFFIC { term ALLOW_BGP { from { destination-address { 11.1.24.0/24; } protocol tcp; destination-port bgp; } then accept; } … … … term ALLOW_XYZ { from { protocol xyz; } then accept; } term DENY_ALL_OTHER { then { syslog; discard; } } } If the filter is not configured to allow specific ports and protocols and deny all other traffic, this is a finding. If the filter is not configured inbound on all external interfaces, this is a finding.
Fix: F-JUNI-RT-000240_fix
This requirement is not applicable for the DoDIN Backbone. Configure a term at the end of the inbound filter to deny all other traffic by default as shown in the example below. [edit firewall family inet] set filter FILTER_INBOUND_TRAFFIC term DENY_ALL_OTHER then syslog discard
- RMF Control
- AC-4
- Severity
- M
- CCI
- CCI-001414
- Version
- JUNI-RT-000250
- Vuln IDs
-
- JUNI-RT-000250
- Rule IDs
-
- JUNI-RT-000250_rule
Checks: C-JUNI-RT-000250_chk
Review 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. interfaces { ge-0/0/0 { unit 0 { family inet { filter { input FILTER_SERVER_TRAFFIC; } address 11.1.12.2/24; } } } … … … firewall { family inet { filter FILTER_SERVER_TRAFFIC { term PRINT_FILTER { from { destination-address { 11.1.23.0/24; } protocol tcp; destination-port [ 515 631 9100 ]; } then accept; } term SQL_FILTER { from { destination-address { 11.1.24.0/24; } protocol tcp; destination-port [ 1433 1434 4022 ]; } then accept; } term ALLOW_BGP { from { protocol tcp; destination-port bgp; } then accept; } term ALLOW_OSPF { from { protocol ospf; } then accept; } term ALLOW_ICMP { from { protocol icmp; } then accept; } term DENY_ALL_OTHER { then { syslog; reject; } } } If 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.
Fix: F-JUNI-RT-000250_fix
This requirement is not applicable for the DoDIN Backbone. Configure 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. [edit firewall family inet] set filter FILTER_SERVER_TRAFFIC term PRINT_FILTER from destination-address 11.1.23.0/24 set filter FILTER_SERVER_TRAFFIC term PRINT_FILTER from protocol tcp destination-port [515 631 9100] set filter FILTER_SERVER_TRAFFIC term PRINT_FILTER then accept set filter FILTER_SERVER_TRAFFIC term SQL_FILTER from destination-address 11.1.24.0/24 set filter FILTER_SERVER_TRAFFIC term SQL_FILTER from protocol tcp destination-port [1433 1434 4022] set filter FILTER_SERVER_TRAFFIC term SQL_FILTER then accept set filter FILTER_SERVER_TRAFFIC term ALLOW_OSPF from protocol ospf set filter FILTER_SERVER_TRAFFIC term ALLOW_OSPF then accept set filter FILTER_SERVER_TRAFFIC term ALLOW_ICMP from protocol icmp set filter FILTER_SERVER_TRAFFIC term ALLOW_ICMP then accept set filter FILTER_SERVER_TRAFFIC term DENY_ALL_OTHER then syslog reject Apply the filter inbound on all applicable interfaces. [edit interfaces ge-0/0/0 unit 0 family inet] set filter input FILTER_SERVER_TRAFFIC
- RMF Control
- SC-7
- Severity
- M
- CCI
- CCI-002403
- Version
- JUNI-RT-000260
- Vuln IDs
-
- JUNI-RT-000260
- Rule IDs
-
- JUNI-RT-000260_rule
Checks: C-JUNI-RT-000260_chk
This requirement is not applicable for the DoDIN Backbone. Review 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 server 11.1.12.1 only to host 3.3.3.3 and denies all other NTP traffic. } filter INBOUND_FILTER { term ALLOW_NTP { from { source-address { 11.1.12.1/32; } destination-address { 3.3.3.3/32; } protocol udp; destination-port ntp; } } term DENY_NTP { from { protocol tcp; destination-port ntp; } } } If the router does not restrict incoming communications to allow only authorized sources and destinations, this is a finding.
Fix: F-JUNI-RT-000260_fix
This requirement is not applicable for the DoDIN Backbone. Configure the router to allow only incoming communications from authorized sources to be routed to authorized destinations.
- RMF Control
- SC-7
- Severity
- M
- CCI
- CCI-002403
- Version
- JUNI-RT-000270
- Vuln IDs
-
- JUNI-RT-000270
- Rule IDs
-
- JUNI-RT-000270_rule
Checks: C-JUNI-RT-000270_chk
This requirement is not applicable for the DoDIN Backbone. Review the router configuration to verify that an ingress filter applied to all external interfaces is blocking packets with Bogon source addresses. Verify a prefix list has been configured containing the current Bogon prefixes as shown in the example below. policy-options { prefix-list BOGON_PREFIXES { 0.0.0.0/8; 10.0.0.0/8; 100.64.0.0/10; 127.0.0.0/8; 169.254.0.0/16; 172.16.0.0/12; 192.0.0.0/24; 192.0.2.0/24; 192.168.0.0/16; 198.18.0.0/15; 198.51.100.0/24; 203.0.113.0/24; 224.0.0.0/4; 240.0.0.0/4; } } Verify that the inbound filter applied to all external interfaces will block all traffic from Bogon source addresses. interfaces { ge-0/0/0 { unit 0 { family inet { filter { input INBOUND_FILTER; } address 11.1.12.2/24; } } } … … … firewall { family inet { filter INBOUND_FILTER { term BLOCK_BOGONS { from { source-prefix-list { BOGON_PREFIXES; } } then { syslog; discard; } } term ALLOW_BGP { from { protocol tcp; destination-port bgp; } then accept; } term ALLOW_XYZ { from { protocol xyz; } then accept; } term DENY_ALL_OTHER { then { syslog; reject; } } } } If the router is not configured to block inbound packets with source Bogon IP address prefixes, this is a finding.
Fix: F-JUNI-RT-000270_fix
This requirement is not applicable for the DoDIN Backbone. Configure the perimeter to block inbound packets with Bogon source addresses. Configure a prefix list containing the current Bogon prefixes as shown below. [edit policy-options] set prefix-list BOGON_PREFIXES 0.0.0.0/8 set prefix-list BOGON_PREFIXES 10.0.0.0/8 set prefix-list BOGON_PREFIXES 100.64.0.0/10 set prefix-list BOGON_PREFIXES 127.0.0.0/8 set prefix-list BOGON_PREFIXES 169.254.0.0/16 set prefix-list BOGON_PREFIXES 172.16.0.0/12 set prefix-list BOGON_PREFIXES 192.0.0.0/24 set prefix-list BOGON_PREFIXES 192.0.2.0/24 set prefix-list BOGON_PREFIXES 192.168.0.0/16 set prefix-list BOGON_PREFIXES 198.18.0.0/15 set prefix-list BOGON_PREFIXES 198.51.100.0/24 set prefix-list BOGON_PREFIXES 203.0.113.0/24 set prefix-list BOGON_PREFIXES 224.0.0.0/4 set prefix-list BOGON_PREFIXES 240.0.0.0/4 Add a term to the inbound filter to block the Bogon prefixes [edit firewall family inet filter INBOUND_FILTER] set term BLOCK_BOGONS from source-prefix-list BOGON_PREFIXES set term BLOCK_BOGONS then syslog discard insert term BLOCK_BOGONS before term ALLOW_BGP
- RMF Control
- AC-4
- Severity
- H
- CCI
- CCI-001414
- Version
- JUNI-RT-000280
- Vuln IDs
-
- JUNI-RT-000280
- Rule IDs
-
- JUNI-RT-000280_rule
Checks: C-JUNI-RT-000280_chk
This requirement is not applicable for the DoDIN Backbone. Verify the interface connecting to ISP has an inbound filter as shown in the example below. interfaces { ge-0/0/0 { description "Verizon ISP link"; unit 0 { family inet { filter { input ISP_FILTER; } address 11.1.12.2/24; } } } Verify that the filter only allows traffic to specific destination addresses (i.e. enclave’s NIPRNet address space) as shown in the example below. firewall { family inet { filter ISP_FILTER { term RESTRICT_DESTINATION { from { destination-address { 0.0.0.0/0; 11.1.0.0/16 except; } } then { syslog; discard; } } term ALLOW_XYZ { from { protocol xyz; } then accept; } … … … term DENY_ALL_OTHER { then { syslog; reject; } } } If the ingress filter bound to the interface connecting to an alternate 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 alternate gateway network service provider, this is a finding.
Fix: F-JUNI-RT-000280_fix
This requirement is not applicable for the DoDIN Backbone. Configure the ingress filter of the perimeter router connected to an alternate gateway to only permit packets with destination addresses of the site's NIPRNet address space or a destination address belonging to the address block assigned by the alternate gateway network service provider as shown in the example below. [edit firewall family inet filter ISP_FILTER] set term RESTRICT_DESTINATION from destination-address 0.0.0.0/0 set term RESTRICT_DESTINATION from destination-address 11.1.0.0/16 except set term RESTRICT_DESTINATION then syslog discard insert term RESTRICT_DESTINATION before term ALLOW_XYZ
- RMF Control
- AC-4
- Severity
- H
- CCI
- CCI-001414
- Version
- JUNI-RT-000290
- Vuln IDs
-
- JUNI-RT-000290
- Rule IDs
-
- JUNI-RT-000290_rule
Checks: C-JUNI-RT-000290_chk
This requirement is not applicable for the DoDIN Backbone. Review the protocols hierarchy in the router configuration (see example below) and verify there are no BGP neighbors configured to a peer AS that belongs to the alternate gateway service provider. protocols { bgp { group AS_2 { type external; peer-as 2; neighbor x.x.x.x { authentication-algorithm hmac-sha-1-96; authentication-key-chain BGP_KEY; } neighbor x.x.x.x { authentication-algorithm hmac-sha-1-96; authentication-key-chain BGP_KEY; } } } If there are BGP neighbors connecting to a peer AS of the alternate gateway service provider, this is a finding.
Fix: F-JUNI-RT-000290_fix
This requirement is not applicable for the DoDIN Backbone. Configure a static route on the perimeter router to reach the AS of a router connecting to an alternate gateway as shown in the example below. [edit routing-options] set static route 0.0.0.0/0 next-hop x.x.x.x
- RMF Control
- AC-4
- Severity
- L
- CCI
- CCI-001414
- Version
- JUNI-RT-000300
- Vuln IDs
-
- JUNI-RT-000300
- Rule IDs
-
- JUNI-RT-000300_rule
Checks: C-JUNI-RT-000300_chk
This requirement is not applicable for the DoDIN Backbone. Review the configurations under the protocols hierarchy. If the export statement is configured as shown in the example below proceed to step 2. } protocols { bgp { group AS_5 { type external; export REDISTRIBUTE; peer-as 5; … … … } } } ospf { export REDISTRIBUTE; area 0.0.0.0 { interface ge-0/0/0 { … … … } } } } Review the export policy referenced above to determine if static routes are being exported as shown in the example below. policy-options { … … … } policy-statement REDISTRIBUTE { term EXPORT_STATIC { from protocol static; then accept; } } } Review the static routes that have been configured to determine if there routes with the next hop address that of the alternate gateway. routing-options { static { route 10.1.16.0/24 next-hop 10.1.12.1; route 0.0.0.0/0 next-hop 144.22.1.3; } If 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.
Fix: F-JUNI-RT-000300_fix
This requirement is not applicable for the DoDIN Backbone. Configure 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. [edit policy-options policy-statement REDISTRIBUTE] set term NOT_ISP_DEFAULT from protocol static route-filter 0.0.0.0/0 exact set term NOT_ISP_DEFAULT then reject insert term set term NOT_ISP_DEFAULT before term EXPORT_STATIC
- RMF Control
- SC-5
- Severity
- H
- CCI
- CCI-001094
- Version
- JUNI-RT-000310
- Vuln IDs
-
- JUNI-RT-000310
- Rule IDs
-
- JUNI-RT-000310_rule
Checks: C-JUNI-RT-000310_chk
This requirement is not applicable for the DoDIN Backbone. Review 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. interfaces { ge-0/1/0 { description "LAN link"; unit 0 { family inet { rpf-check; If uRPF or an egress filter to restrict the router from accepting outbound IP packets that contain an illegitimate address in the source address field has not been configured on all internal interfaces in an enclave, this is a finding.
Fix: F-JUNI-RT-000310_fix
This requirement is not applicable for the DoDIN Backbone. Configure 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. [edit interfaces ge-0/1/0 unit 0 family inet] set rpf-check
- RMF Control
- SC-7
- Severity
- M
- CCI
- CCI-001097
- Version
- JUNI-RT-000320
- Vuln IDs
-
- JUNI-RT-000320
- Rule IDs
-
- JUNI-RT-000320_rule
Checks: C-JUNI-RT-000320_chk
This requirement is not applicable for the DoDIN Backbone. Review the router configuration to verify that the ingress filter is in accordance with DoD 8551. Verify that an inbound filter is configured on all external interfaces. interfaces { ge-0/0/0 { unit 0 { family inet { filter { input INBOUND_FILTER; } address 11.1.12.2/24; } } } Review the inbound filter to verify that it is filtering traffic in accordance with DoD 8551. firewall { family inet { filter INBOUND_FILTER { term ALLOW_ABC { from { protocol tcp; destination-port abc; } then accept; } term ALLOW_XYZ { from { protocol xyz; } then accept; } term DENY_ALL_OTHER { then { syslog; reject; } } } } If the router does not filter traffic in accordance with the guidelines contained in DoD 8551, this is a finding.
Fix: F-JUNI-RT-000320_fix
This requirement is not applicable for the DoDIN Backbone. Configure 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. set filter INBOUND_FILTER term ALLOW_ABC from protocol tcp destination-port abc set filter INBOUND_FILTER term ALLOW_ABC then accept set filter INBOUND_FILTER term ALLOW_XYZ from protocol tcp destination-port xyz set filter INBOUND_FILTER term ALLOW_XYZ then accept set filter INBOUND_FILTER term DENY_ALL_OTHER then syslog reject [edit interfaces ge-0/0/0 unit 0 family inet] set filter input INBOUND_FILTER
- RMF Control
- SC-7
- Severity
- M
- CCI
- CCI-001097
- Version
- JUNI-RT-000330
- Vuln IDs
-
- JUNI-RT-000330
- Rule IDs
-
- JUNI-RT-000330_rule
Checks: C-JUNI-RT-000330_chk
This requirement is not applicable for the DoDIN Backbone. Review the router configuration to verify that an inbound filter is configured on all external interfaces as shown in the example below. interfaces { description "NIPRnet"; ge-0/0/0 { unit 0 { family inet { filter { input INBOUND_FILTER; } address x.x.x.x/24; } } } If the router is not configured to filter traffic entering the network at all external interfaces in an inbound direction, this is a finding.
Fix: F-JUNI-RT-000330_fix
This requirement is not applicable for the DoDIN Backbone. Configure the router to use an inbound filter on all external interfaces as shown in the example below. [edit interfaces ge-0/0/0 unit 0 family inet] set filter input INBOUND_FILTER
- RMF Control
- SC-7
- Severity
- M
- CCI
- CCI-001097
- Version
- JUNI-RT-000340
- Vuln IDs
-
- JUNI-RT-000340
- Rule IDs
-
- JUNI-RT-000340_rule
Checks: C-JUNI-RT-000340_chk
This requirement is not applicable for the DoDIN Backbone. Review the router configuration to verify that the egress ACL is bound to the internal interface in an inbound direction. interfaces { ge-0/1/0 { description "LAN link"; unit 0 { family inet { filter { input OUTBOUND_FILTER; } address x.x.x.x/24; } } } If the router is not configured to filter traffic leaving the network at the internal interface in an inbound direction, this is a finding.
Fix: F-JUNI-RT-000340_fix
This requirement is not applicable for the DoDIN Backbone. Configure the router to use an inbound filter on all internal interfaces as shown in the example below. [edit interfaces ge-0/1/0 unit 0 family inet] set filter input OUTBOUND_FILTER
- RMF Control
- SC-7
- Severity
- M
- CCI
- CCI-002403
- Version
- JUNI-RT-000350
- Vuln IDs
-
- JUNI-RT-000350
- Rule IDs
-
- JUNI-RT-000350_rule
Checks: C-JUNI-RT-000350_chk
This requirement is not applicable for the DoDIN Backbone. Review the router configuration to determine if it will block all packets with IP options. firewall { family inet { filter INBOUND_FILTER { term DROP_IPOPTIONS { from { ip-options any; } then { syslog; discard; } } term BLOCK_BOGONS { from { source-prefix-list { BOGON_PREFIXES; } } then { syslog; discard; } } term ALLOW_ABC { … … … term DENY_ALL_OTHER { then { log; syslog; reject; } } } If the router is not configured to drop all packets with IP options, this is a finding.
Fix: F-JUNI-RT-000350_fix
This requirement is not applicable for the DoDIN Backbone. Configure the router to drop all packets with IP options. [edit firewall family inet filter INBOUND_FILTER] set term DROP_IPOPTIONS from ip-options any set term DROP_IPOPTIONS then discard insert term DROP_IPOPTIONS before term BLOCK_BOGONS
- RMF Control
- SC-7
- Severity
- L
- CCI
- CCI-002403
- Version
- JUNI-RT-000360
- Vuln IDs
-
- JUNI-RT-000360
- Rule IDs
-
- JUNI-RT-000360_rule
Checks: C-JUNI-RT-000360_chk
This requirement is not applicable for the DoDIN Backbone. Review all router configurations to ensure LLDP is not enabled external interface. protocols { … … … lldp { advertisement-interval 30; interface all; } } If LLDP is configured globally or on any external interface, this is a finding.
Fix: F-JUNI-RT-000360_fix
This requirement is not applicable for the DoDIN Backbone. Disable LLDP on all external interfaces. If necessary, remove the interface all parameter and define all internal interfaces as shown in the example below. [edit protocols lldp] delete interface all set interface ge-0/1/0 set interface ge-0/1/1
- RMF Control
- SC-7
- Severity
- M
- CCI
- CCI-002403
- Version
- JUNI-RT-000370
- Vuln IDs
-
- JUNI-RT-000370
- Rule IDs
-
- JUNI-RT-000370_rule
Checks: C-JUNI-RT-000370_chk
Review the router configuration to determine if IP Proxy ARP is disabled on all external interfaces. interfaces { description "NIPRnet"; ge-0/0/0 { unit 0 { proxy-arp restricted; family inet { If IP Proxy ARP is enabled on any external interface, this is a finding.
Fix: F-JUNI-RT-000370_fix
This requirement is not applicable for the DoDIN Backbone. Disable Proxy ARP on all external interfaces as shown in the example below. [edit interfaces em0 unit 0] delete proxy-arp restricted
- RMF Control
- SC-7
- Severity
- M
- CCI
- CCI-001097
- Version
- JUNI-RT-000380
- Vuln IDs
-
- JUNI-RT-000380
- Rule IDs
-
- JUNI-RT-000380_rule
Checks: C-JUNI-RT-000380_chk
This requirement is not applicable for the DoDIN Backbone. The 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. Verify that the router has been configured with an outbound filter as shown in the example below. interfaces { description "NIPRnet"; ge-0/0/0 { unit 0 { family inet { no-redirects; filter { output OUTBOUND_FILTER; } address 10.1.12.2/24; } } } Verify that the outbound filter discard or rejects management traffic as shown in the example below. firewall { family inet { … … … } filter OUTBOUND_FILTER { term BLOCK_TACACS { from { protocol tcp; port tacacs; } then { syslog; discard; } } term BLOCK_SNMP { from { protocol udp; port [ snmp snmptrap ]; } then { syslog; discard; } } term BLOCK_NETFLOW { from { protocol udp; port [ 2055 9995 9996 ]; } } term ALLOW_OTHER { then accept; } } } If management traffic is not blocked at the perimeter, this is a finding.
Fix: F-JUNI-RT-000380_fix
This requirement is not applicable for the DoDIN Backbone. Configure the perimeter router of the managed network with an outbound filter on the egress interface to block all management traffic. Configure a filter to block egress management traffic. [edit firewall family inet] Set filter OUTBOUND_FILTER term BLOCK_TACACS from protocol tcp port tacacs Set filter OUTBOUND_FILTER term BLOCK_TACACS then syslog discard Set filter OUTBOUND_FILTER term BLOCK_SNMP from protocol udp port [snmp snmptrap] Set filter OUTBOUND_FILTER term BLOCK_SNMP then syslog discard set filter OUTBOUND_FILTER term BLOCK_NETFLOW from protocol udp port [2055 9995 9996] set filter OUTBOUND_FILTER term BLOCK_NETFLOW then syslog discard Configure the external interfaces with the outbound filter. [edit interfaces ge-0/0/0 unit 0 family inet] set filter output OUTBOUND_FILTER
- RMF Control
- SC-7
- Severity
- M
- CCI
- CCI-001097
- Version
- JUNI-RT-000390
- Vuln IDs
-
- JUNI-RT-000390
- Rule IDs
-
- JUNI-RT-000390_rule
Checks: C-JUNI-RT-000390_chk
This requirement is not applicable for the DoDIN Backbone. Review 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. Review 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. security { ipsec { proposal IPSEC_PHASE2_PROPOSAL { protocol esp; authentication-algorithm hmac-sha1-96; encryption-algorithm aes-128-cbc; } policy IPSEC_POLICY { perfect-forward-secrecy { keys group5; } proposals IPSEC_PHASE2_PROPOSAL; } security-association IPSEC-SA_XYZ { description "For XYZ"; mode transport; manual { direction bidirectional { protocol ah; spi 256; authentication { algorithm hmac-sha1-96; key ascii-text "$9$oPJjH.P5F69mSHqPQn6u0RhSreW-dsZGi8XYoZDmP"; ## SECRET-DATA } } } } security-association IPSEC_SA_MGMT { description "IPsec Tunnel for Mgmt Traffic"; mode tunnel; dynamic { ipsec-policy IPSEC_POLICY; } } } ike { proposal IKE_PHASE1_PROPOSAL { authentication-method pre-shared-keys; dh-group group5; authentication-algorithm sha-256; encryption-algorithm aes-128-cbc; } policy 10.1.25.2 { proposals IKE_PHASE1_PROPOSAL; pre-shared-key ascii-text "$9$J4UDkCA01IcHqEy"; ## SECRET-DATA } } Verify 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. firewall { family inet { … … … filter MGMT_TRAFFIC { term ALLOW_SNMP { from { protocol udp; port [ snmp snmptrap ]; } then ipsec-sa IPSEC_SA_MGMT; } term ALLOW_TACACS { from { protocol tcp; port tacacs; } then ipsec-sa IPSEC_SA_MGMT; } term ALLOW_NETFLOW { from { protocol udp; port [ 2055 9995 9996 ]; } then ipsec-sa IPSEC_SA_MGMT; } term OTHER { then accept; } } } If 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.
Fix: F-JUNI-RT-000390_fix
This requirement is not applicable for the DoDIN Backbone. Ensure 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. Configure an IPsec tunnel using commands similar to the example below. [edit security] set ike proposal IKE_PHASE1_PROPOSAL authentication-method pre-shared-keys set ike proposal IKE_PHASE1_PROPOSAL authentication-algorithm sha-256 set ike proposal IKE_PHASE1_PROPOSAL dh-group group5 set ike proposal IKE_PHASE1_PROPOSAL encryption-algorithm aes-128-cbc set ike policy 10.1.25.2 proposals IKE_PHASE1_PROPOSAL set ike policy IKE_10.1.25.2 mode main set ike policy 10.1.25.2 pre-shared-key ascii-text xxxxxxxxx set ipsec proposal IPSEC_PHASE2_PROPOSAL protocol esp set ipsec proposal IPSEC_PHASE2_PROPOSAL authentication-algorithm hmac-sha1-96 set ipsec proposal IPSEC_PHASE2_PROPOSAL encryption-algorithm aes-128-cbc set ipsec security-association IPSEC_SA_MGMT mode tunnel set ipsec security-association IPSEC_SA_MGMT dynamic ipsec-policy IPSEC_POLICY Configure a filter to define the management traffic to be forwarded into the IPsec tunnel. [edit firewall family inet] set filter MGMT_TRAFFIC term ALLOW_SNMP from protocol udp port [snmp snmptrap] set filter MGMT_TRAFFIC term ALLOW_SNMP then ipsec-sa IPSEC_SA_MGMT set filter MGMT_TRAFFIC term ALLOW_TACACS from protocol tcp port tacacs set filter MGMT_TRAFFIC term ALLOW_TACACS then ipsec-sa IPSEC_SA_MGMT set filter MGMT_TRAFFIC term ALLOW_NETFLOW from protocol udp port [2055 9995 9996] set filter MGMT_TRAFFIC term ALLOW_NETFLOW then ipsec-sa IPSEC_SA_MGMT set filter MGMT_TRAFFIC term OTHER then accept
- RMF Control
- SC-7
- Severity
- M
- CCI
- CCI-001097
- Version
- JUNI-RT-000400
- Vuln IDs
-
- JUNI-RT-000400
- Rule IDs
-
- JUNI-RT-000400_rule
Checks: C-JUNI-RT-000400_chk
This requirement is not applicable for the DoDIN Backbone. Review 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. If 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. interfaces { description "OOBM Net"; ge-1/1/0 { unit 0 { family inet { filter { output MGMT_TRAFFIC; } address 10.2.22.2/24; } } } … … … firewall { family inet { … … … filter MGMT_TRAFFIC { term ALLOW_SNMP { from { protocol udp; port [ snmp snmptrap ]; } then accept; } term ALLOW_TACACS { from { protocol tcp; port tacacs; } then accept; } term ALLOW_NETFLOW { from { protocol udp; port [ 2055 9995 9996 ]; } then accept; } term DENY_OTHER { then { syslog; discard; } } } } If 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. firewall { family inet { … … … filter MGMT_TRAFFIC { term ALLOW_SNMP { from { protocol udp; port [ snmp snmptrap ]; } then ipsec-sa IPSEC_SA_MGMT; } term ALLOW_TACACS { from { protocol tcp; port tacacs; } then ipsec-sa IPSEC_SA_MGMT; } term ALLOW_NETFLOW { from { protocol udp; port [ 2055 9995 9996 ]; } then ipsec-sa IPSEC_SA_MGMT; } term OTHER { then accept; } } } If traffic other than authorized management traffic is permitted through the OOBM interface or IPsec tunnel, this is a finding.
Fix: F-JUNI-RT-000400_fix
This requirement is not applicable for the DoDIN Backbone. Configure 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. OOBM Link [edit firewall family inet] set filter MGMT_TRAFFIC term ALLOW_SNMP from protocol udp port [snmp snmptrap] set filter MGMT_TRAFFIC term ALLOW_SNMP then accept set filter MGMT_TRAFFIC term ALLOW_TACACS from protocol tcp port tacacs set filter MGMT_TRAFFIC term ALLOW_TACACS then accept set filter MGMT_TRAFFIC term ALLOW_NETFLOW from protocol udp port [2055 9995 9996] set filter MGMT_TRAFFIC term ALLOW_NETFLOW then accept set filter MGMT_TRAFFIC term DENY_OTHER then syslog discard [edit interfaces ge-1/1/0 unit 0 family inet] set filter output MGMT_TRAFFIC IPsec Tunnel [edit firewall family inet] set filter MGMT_TRAFFIC term ALLOW_SNMP from protocol udp port [snmp snmptrap] set filter MGMT_TRAFFIC term ALLOW_SNMP then ipsec-sa IPSEC_SA_MGMT set filter MGMT_TRAFFIC term ALLOW_TACACS from protocol tcp port tacacs set filter MGMT_TRAFFIC term ALLOW_TACACS then ipsec-sa IPSEC_SA_MGMT set filter MGMT_TRAFFIC term ALLOW_NETFLOW from protocol udp port [2055 9995 9996] set filter MGMT_TRAFFIC term ALLOW_NETFLOW then ipsec-sa IPSEC_SA_MGMT set filter MGMT_TRAFFIC term OTHER then accept
- RMF Control
- AC-4
- Severity
- M
- CCI
- CCI-001414
- Version
- JUNI-RT-000410
- Vuln IDs
-
- JUNI-RT-000410
- Rule IDs
-
- JUNI-RT-000410_rule
Checks: C-JUNI-RT-000410_chk
This requirement is not applicable for the DoDIN Backbone. Verify that the OOBM interface is an adjacency in the IGP domain for the management network via separate VRF as shown in the example below. } protocols { ospf { area 0.0.0.0 { interface ge-2/0/0; interface ge-2/1/0; } } } routing-instances { VRF_MGMT { instance-type vrf; interface ge-1/0/0; interface ge-1/1/0; route-distinguisher 10.1.12.0:12; vrf-target { import target:1234:4567; export target:1234:4567; } routing-options { router-id 11.11.11.11; } protocols { ospf { area 0.0.0.0 { interface ge-1/0/0; interface ge-1/1/0; } } } } } If the router is not configured to have separate IGP instances for the managed network and management network, this is a finding.
Fix: F-JUNI-RT-000410_fix
This requirement is not applicable for the DoDIN Backbone. Configure the router to have a separate IGP instance for the management network as shown in the example below. [edit routing-instances] set VRF_MGMT instance-type vrf set VRF_MGMT route-distinguisher 10.1.12.0:12 set VRF_MGMT vrf-target import target:1234:4567 set VRF_MGMT vrf-target export target:1234:4567 set VRF_MGMT interface ge-1/0/0 set VRF_MGMT interface ge-1/1/0 set VRF_MGMT protocols ospf area 0.0.0.0 interface ge-1/0/0 set VRF_MGMT protocols ospf area 0.0.0.0 interface ge-1/1/0 set VRF_MGMT routing-options router-id 11.11.11.11
- RMF Control
- AC-4
- Severity
- M
- CCI
- CCI-001414
- Version
- JUNI-RT-000420
- Vuln IDs
-
- JUNI-RT-000420
- Rule IDs
-
- JUNI-RT-000420_rule
Checks: C-JUNI-RT-000420_chk
This requirement is not applicable for the DoDIN Backbone. Verify 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. } routing-options { interface-routes { rib-group inet INET0_GROUP; } rib-groups { INET0_GROUP { import-rib [ VRF_MGMT.inet.0 inet.0 ]; } } } If 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.
Fix: F-JUNI-RT-000420_fix
This requirement is not applicable for the DoDIN Backbone. Remove the configuration that imports routes from the management network into the managed network or vice versa as shown in the example below. [edit routing-options] delete rib-groups INET0_GROUP delete interface-routes rib-group inet INET0_GROUP
- RMF Control
- SC-7
- Severity
- M
- CCI
- CCI-001097
- Version
- JUNI-RT-000430
- Vuln IDs
-
- JUNI-RT-000430
- Rule IDs
-
- JUNI-RT-000430_rule
Checks: C-JUNI-RT-000430_chk
This requirement is not applicable for the DoDIN Backbone. Review 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. interfaces { … … … lo0 { unit 0 { family inet { filter { input PROTECT_RP; } address 1.1.1.1/32; } } } } … … … firewall { family inet { filter PROTECT_RP { term RESTRICT_ADDRESS { from { source-address { 0.0.0.0/0; 10.2.14.0/24 except; } } then { syslog; discard; } } term ALLOW_OTHER { then accept; } } } } If 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.
Fix: F-JUNI-RT-000430_fix
This requirement is not applicable for the DoDIN Backbone. Configure the router to only allow traffic to the route processor from the OOBM network. [edit firewall family inet] set filter PROTECT_RP term RESTRICT_ADDRESS from source-address 0.0.0.0/0 set filter PROTECT_RP term RESTRICT_ADDRESS from source-address 10.2.14.0/24 except set filter PROTECT_RP term RESTRICT_ADDRESS then syslog discard set filter PROTECT_RP term ALLOW_OTHER then accept [edit interfaces lo0 unit 0 family inet] set filter input PROTECT_RP
- RMF Control
- SC-7
- Severity
- M
- CCI
- CCI-001097
- Version
- JUNI-RT-000440
- Vuln IDs
-
- JUNI-RT-000440
- Rule IDs
-
- JUNI-RT-000440_rule
Checks: C-JUNI-RT-000440_chk
Verify that the managed interface has an inbound and outbound filter configured. interfaces { … … … ge-0/0/0 { description "OOBM Network"; unit 0 { family inet { filter { input OOBM_INBOUND; output OOBM_OUTBOUND; } address 10.2.14.1/24; } } } Verify that the ingress filter only allows management, IGP, and ICMP traffic. firewall { family inet { … … … filter OOBM_INBOUND { term ALLOW_OSPF { from { protocol ospf; } then accept; } term ALLOW_SNMP { from { protocol udp; port snmp; } then accept; } term ALLOW_TACACS { from { protocol tcp; port tacacs; } then accept; } term ALLOW_ICMP { from { protocol icmp; } then accept; } term ALLOW_SSH { from { protocol tcp; port ssh; } then accept; } term ALLOW_NTP { from { protocol tcp; port ntp; } then accept; } term DENY_OTHER { then { syslog; discard; } } } } } Verify that the ingress filter only allows management, IGP, and ICMP traffic. firewall { family inet { … … … filter OOBM_OUTBOUND { term ALLOW_OSPF { from { protocol ospf; } then accept; } term ALLOW_SNMP { from { protocol udp; port [ snmp snmptrap ]; } then accept; } term ALLOW_TACACS { from { protocol tcp; port tacacs; } then accept; } term ALLOW_SSH { from { protocol tcp; port ssh; } then accept; } term ALLOW_NTP { from { protocol udp; port ntp; } then accept; } term ALLOW_SYSLOG { from { protocol udp; port syslog; } then accept; } term ALLOW_NETFLOW { from { protocol udp; port [ 2055 9995 9996 ]; } then accept; } term DENY_OTHER { then { syslog; discard; } } } } } Caveat: If the management interface is a true OOBM interface, this requirement is not applicable. If the router does not restrict traffic that ingresses and egresses the management interface, this is a finding.
Fix: F-JUNI-RT-000440_fix
If the management interface is not a dedicated OOBM interface, it must be configured with both an ingress and egress filter. Configure an inbound filter a shown in the example below. [edit firewall family inet] set filter OOBM_INBOUND term ALLOW_OSPF from protocol ospf set filter OOBM_INBOUND term ALLOW_OSPF then accept set filter OOBM_INBOUND term ALLOW_SNMP from protocol udp port snmp set filter OOBM_INBOUND term ALLOW_SNMP then accept set filter OOBM_INBOUND term ALLOW_TACACS from protocol tcp port tacacs set filter OOBM_INBOUND term ALLOW_TACACS then accept set filter OOBM_INBOUND term ALLOW_SSH from protocol tcp port ssh set filter OOBM_INBOUND term ALLOW_SSH then accept set filter OOBM_INBOUND term ALLOW_NTP from protocol udp port ntp set filter OOBM_INBOUND term ALLOW_NTP then accept set filter OOBM_INBOUND term ALLOW_ICMP from protocol icmp set filter OOBM_INBOUND term ALLOW_ICMP then accept set filter OOBM_INBOUND term DENY_OTHER then syslog discard Configure an outbound filter a shown in the example below. set filter OOBM_OUTBOUND term ALLOW_OSPF from protocol ospf set filter OOBM_OUTBOUND term ALLOW_OSPF then accept set filter OOBM_OUTBOUND term ALLOW_SNMP from protocol udp port [snmp snmptrap] set filter OOBM_OUTBOUND term ALLOW_SNMP then accept set filter OOBM_OUTBOUND term ALLOW_TACACS from protocol tcp port tacacs set filter OOBM_OUTBOUND term ALLOW_TACACS then accept set filter OOBM_OUTBOUND term ALLOW_SSH from protocol tcp port ssh set filter OOBM_OUTBOUND term ALLOW_SSH then accept set filter OOBM_OUTBOUND term ALLOW_NTP from protocol udp port ntp set filter OOBM_OUTBOUND term ALLOW_NTP then accept set filter OOBM_OUTBOUND term ALLOW_SYSLOG from protocol udp port set filter OOBM_OUTBOUND term ALLOW_SYSLOG then accept set filter OOBM_OUTBOUND term ALLOW_NETFLOW from protocol udp port [2055 9995 9996] set filter OOBM_OUTBOUND term ALLOW_NETFLOW then accept set filter OOBM_OUTBOUND term DENY_OTHER then syslog discard Apply the filters to the OOBM interfaces [edit interfaces ge-0/0/0 unit 0 family inet] set filter input OOBM_INBOUND set filter output OOBM_OUTBOUND
- RMF Control
- SC-7
- Severity
- M
- CCI
- CCI-001097
- Version
- JUNI-RT-000450
- Vuln IDs
-
- JUNI-RT-000450
- Rule IDs
-
- JUNI-RT-000450_rule
Checks: C-JUNI-RT-000450_chk
This requirement is not applicable for the DoDIN Backbone. Verify that all traffic from the managed network to the management network and vice-versa is secured via IPsec tunnel. Review 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. security { ipsec { proposal IPSEC_PHASE2_PROPOSAL { protocol esp; authentication-algorithm hmac-sha1-96; encryption-algorithm aes-128-cbc; } policy IPSEC_POLICY { perfect-forward-secrecy { keys group5; } proposals IPSEC_PHASE2_PROPOSAL; } security-association IPSEC-SA_XYZ { description "For XYZ"; mode transport; manual { direction bidirectional { protocol ah; spi 256; authentication { algorithm hmac-sha1-96; key ascii-text "$9$oPJjH.P5F69mSHqPQn6u0RhSreW-dsZGi8XYoZDmP"; ## SECRET-DATA } } } } security-association IPSEC_SA_MGMT { description "IPsec Tunnel for Mgmt Traffic"; mode tunnel; dynamic { ipsec-policy IPSEC_POLICY; } } } ike { proposal IKE_PHASE1_PROPOSAL { authentication-method pre-shared-keys; dh-group group5; authentication-algorithm sha-256; encryption-algorithm aes-128-cbc; } policy 10.1.25.2 { proposals IKE_PHASE1_PROPOSAL; pre-shared-key ascii-text "$9$J4UDkCA01IcHqEy"; ## SECRET-DATA } } Verify 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. firewall { family inet { … … … filter MGMT_TRAFFIC { term ALLOW_SNMP { from { protocol udp; port [ snmp snmptrap ]; } then ipsec-sa IPSEC_SA_MGMT; } term ALLOW_TACACS { from { protocol tcp; port tacacs; } then ipsec-sa IPSEC_SA_MGMT; } term ALLOW_NETFLOW { from { protocol udp; port [ 2055 9995 9996 ]; } then ipsec-sa IPSEC_SA_MGMT; } term OTHER { then accept; } } } If the management traffic is not secured via IPsec tunnel, this is a finding.
Fix: F-JUNI-RT-000450_fix
This requirement is not applicable for the DoDIN Backbone. Ensure that all traffic from the managed network to the management network is secured via IPsec tunnel as shown in the configuration examples below. Configure an IPsec tunnel to be used to transport the management traffic. [edit security] set ike proposal IKE_PHASE1_PROPOSAL authentication-method pre-shared-keys set ike proposal IKE_PHASE1_PROPOSAL authentication-algorithm sha-256 set ike proposal IKE_PHASE1_PROPOSAL dh-group group5 set ike proposal IKE_PHASE1_PROPOSAL encryption-algorithm aes-128-cbc set ike policy 10.1.25.2 proposals IKE_PHASE1_PROPOSAL set ike policy IKE_10.1.25.2 mode main set ike policy 10.1.25.2 pre-shared-key ascii-text xxxxxxxxx set ipsec proposal IPSEC_PHASE2_PROPOSAL protocol esp set ipsec proposal IPSEC_PHASE2_PROPOSAL authentication-algorithm hmac-sha1-96 set ipsec proposal IPSEC_PHASE2_PROPOSAL encryption-algorithm aes-128-cbc set ipsec security-association IPSEC_SA_MGMT mode tunnel set ipsec security-association IPSEC_SA_MGMT dynamic ipsec-policy IPSEC_POLICY Configure a filter that will select which traffic to be forwarded via the IPsec tunnel by specifying the security association bound to the tunnel. [edit firewall family inet] set filter MGMT_TRAFFIC term ALLOW_SNMP from protocol udp port [snmp snmptrap] set filter MGMT_TRAFFIC term ALLOW_SNMP then ipsec-sa IPSEC_SA_MGMT set filter MGMT_TRAFFIC term ALLOW_TACACS from protocol tcp port tacacs set filter MGMT_TRAFFIC term ALLOW_TACACS then ipsec-sa IPSEC_SA_MGMT set filter MGMT_TRAFFIC term ALLOW_NETFLOW from protocol udp port [2055 9995 9996] set filter MGMT_TRAFFIC term ALLOW_NETFLOW then ipsec-sa IPSEC_SA_MGMT set filter MGMT_TRAFFIC term OTHER then accept
- RMF Control
- SC-5
- Severity
- L
- CCI
- CCI-002385
- Version
- JUNI-RT-000460
- Vuln IDs
-
- JUNI-RT-000460
- Rule IDs
-
- JUNI-RT-000460_rule
Checks: C-JUNI-RT-000460_chk
Verify that a filter has been configured to only allow BGP packets with a TTL of 255 as shown in the example below. firewall { … … … filter GTSM_FILTER { term TTL_SECURITY { from { protocol tcp; ttl-except 255; port bgp; } then { syslog; discard; } } term ELSE_ACCEPT { then accept; } } } Verify that the filter is applied to all interfaces connecting to eBGP peers. interfaces { … … … ge-0/0/0 { unit 0 { family inet { filter { input-list [INBOUND_FILTER GTSM_FILTER]; } address x.x.x.x/30; } } } } Configure the router to send all BGP packets with a TTL of 255 as shown in the example below. If the router is not configured to use GTSM for all Exterior Border Gateway Protocol peering sessions, this is a finding.
Fix: F-JUNI-RT-000460_fix
Configure a filter to only accept bgp packets with a TTL of 255 as shown in the example below. [edit firewall] set filter GTSM_FILTER term TTL_SECURITY from protocol tcp port bgp ttl-except 255 set filter GTSM_FILTER term TTL_SECURITY then syslog discard set filter GTSM_FILTER term ELSE_ACCEPT then accept Apply the firewall filter to the inbound interface for all eBGP single-hop peer as shown in the example below. [edit interfaces ge-0/0/0 unit 0 family inet] set filter input-list INBOUND_FILTER set filter input-list GTSM_FILTER
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- JUNI-RT-000470
- Vuln IDs
-
- JUNI-RT-000470
- Rule IDs
-
- JUNI-RT-000470_rule
Checks: C-JUNI-RT-000470_chk
Review the BGP configuration to determine if it is peering with multiple autonomous systems. Interview the ISSM and router administrator to determine if unique keys are being used. protocols { bgp { group AS44 { type external; peer-as 44; neighbor x.x.x.x { authentication-key "$9$tBga0ORx7VsYoIEgJ"; ## SECRET-DATA } } group AS66 { type external; peer-as 66; neighbor x.x.x.x { authentication-key "$9$Q4953nCrlMLX-9A7V"; ## SECRET-DATA } } } If unique keys are not being used, this is a finding.
Fix: F-JUNI-RT-000470_fix
Configure the router to use unique keys for each AS that it peers with as shown in the example below. [edit protocols bgp] set group GROUP_AS66 authentication-key abc123 set group GROUP_AS44 authentication-key xyz123
- RMF Control
- AC-4
- Severity
- M
- CCI
- CCI-001368
- Version
- JUNI-RT-000480
- Vuln IDs
-
- JUNI-RT-000480
- Rule IDs
-
- JUNI-RT-000480_rule
Checks: C-JUNI-RT-000480_chk
Review the router configuration to verify that it will reject BGP routes for any Bogon prefixes. Verify a prefix list has been configured containing the current Bogon prefixes as shown in the example below. policy-options { prefix-list BOGON_PREFIXES { 0.0.0.0/8; 10.0.0.0/8; 100.64.0.0/10; 127.0.0.0/8; 169.254.0.0/16; 172.16.0.0/12; 192.0.0.0/24; 192.0.2.0/24; 192.168.0.0/16; 198.18.0.0/15; 198.51.100.0/24; 203.0.113.0/24; 224.0.0.0/4; 240.0.0.0/4; } } Verify that a policy has been configured to reject the Bogon prefixes. policy-options { … … … policy-statement FILTER_ROUTES { term REJECT_BOGONS { from { prefix-list BOGON_PREFIXES; } then reject; } term ACCEPT_OTHERS { then accept; } } } Verify that the configured policy to filter Bogons has been applied to external BGP peers as shown in the example below. protocols { bgp { group GROUP_AS4 { type external; import FILTER_ROUTES; peer-as 4; neighbor x.x.x.x; } } If the router is not configured to reject inbound route advertisements for any Bogon prefixes, this is a finding.
Fix: F-JUNI-RT-000480_fix
Configure the router to reject inbound route advertisements for any Bogon prefixes. Configure a prefix list containing the current Bogon prefixes as shown below. [edit policy-options] set prefix-list BOGON_PREFIXES 0.0.0.0/8 set prefix-list BOGON_PREFIXES 10.0.0.0/8 set prefix-list BOGON_PREFIXES 100.64.0.0/10 set prefix-list BOGON_PREFIXES 127.0.0.0/8 set prefix-list BOGON_PREFIXES 169.254.0.0/16 set prefix-list BOGON_PREFIXES 172.16.0.0/12 set prefix-list BOGON_PREFIXES 192.0.0.0/24 set prefix-list BOGON_PREFIXES 192.0.2.0/24 set prefix-list BOGON_PREFIXES 192.168.0.0/16 set prefix-list BOGON_PREFIXES 198.18.0.0/15 set prefix-list BOGON_PREFIXES 198.51.100.0/24 set prefix-list BOGON_PREFIXES 203.0.113.0/24 set prefix-list BOGON_PREFIXES 224.0.0.0/4 set prefix-list BOGON_PREFIXES 240.0.0.0/4 Configure a policy-statement to reject Bogon prefixes. set policy-statement FILTER_ROUTES term REJECT_BOGONS from prefix-list BOGON_PREFIXES set policy-statement FILTER_ROUTES term REJECT_BOGONS then reject set policy-statement FILTER_ROUTES term ACCEPT_OTHER then accept Configure an import statement referencing the policy to reject Bogons on all external BGP peers. [edit protocols bgp group GROUP_AS4] set import FILTER_ROUTES
- RMF Control
- AC-4
- Severity
- M
- CCI
- CCI-001368
- Version
- JUNI-RT-000490
- Vuln IDs
-
- JUNI-RT-000490
- Rule IDs
-
- JUNI-RT-000490_rule
Checks: C-JUNI-RT-000490_chk
Review the router configuration to verify that it will reject routes belonging to the local AS. Verify a prefix list has been configured containing prefixes belonging to the local autonomous system as shown in the example below. policy-options { … … … prefix-list OUR_PREFIXES { x.x.x.x/16; } Verify that a policy has been configured to reject the local prefixes. policy-options { … … … policy-statement FILTER_ROUTES { term REJECT_BOGONS { from { prefix-list BOGON_PREFIXES; } then reject; } term REJECT_OUR_PREFIXES { from { prefix-list OUR_PREFIXES; } then reject; } term ACCEPT_OTHER { then accept; } } } Verify that the configured policy to filter local prefixes has been applied to external BGP peers as shown in the example below. protocols { bgp { group GROUP_AS4 { type external; import FILTER_ROUTES; peer-as 4; neighbor x.x.x.x; } } If the router is not configured to reject inbound route advertisements belonging to the local AS, this is a finding.
Fix: F-JUNI-RT-000490_fix
Configure the router to reject inbound route advertisements for any prefixes belonging to the local AS. Configure a prefix list containing prefixes belonging to the local autonomous system. [edit policy-options] set prefix-list OUR_PREFIXES x.x.x.x/16 Configure 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. [edit policy-options policy-statement FILTER_ROUTES] set term REJECT_OUR_PREFIXES from prefix-list OUR_PREFIXES set term REJECT_OUR_PREFIXES then reject insert term REJECT_OUR_PREFIXES before term ACCEPT_OTHER Note: There is no need change the BGP configuration assuming the import statement is already configured for all external neighbors.
- RMF Control
- AC-4
- Severity
- M
- CCI
- CCI-001368
- Version
- JUNI-RT-000500
- Vuln IDs
-
- JUNI-RT-000500
- Rule IDs
-
- JUNI-RT-000500_rule
Checks: C-JUNI-RT-000500_chk
Review the router configuration to verify that there are filters defined to only accept routes for prefixes that belong to specific customers. Verify prefix list has been configured containing prefixes belonging to each customer as shown in the example below. policy-options { … … … prefix-list CUST1_PREFIXES { x.x.x.x/24; x.x.x.x/24; } prefix-list CUST2_PREFIXES { x.x.x.x/24; } Verify that a policy has been configured to only accept routes belonging to the customer. policy-options { … … … policy-statement FILTER_CUST1_ROUTES { term ACCEPT-ROUTES { from { prefix-list CUST1_PREFIXES; } then accept; } term REJECT_OTHER { then reject; } } policy-statement FILTER_CUST2_ROUTES { term ACCEPT_ROUTES { from { prefix-list CUST2_PREFIXES; } then accept; } term REJECT_OTHER { then reject; } } } Verify that the configured policy to filter customer prefixes has been applied to customer BGP peers as shown in the example below. protocols { bgp { … … … } group CUST1 { type external; import FILTER_CUST1_ROUTES; peer-as 55; neighbor x.x.x.x; neighbor x.x.x.x; } group CUST2 { type external; import FILTER_CUST2_ROUTES; peer-as 44; neighbor x.x.x.x; neighbor x.x.x.x; } } … … … } Note: 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. If 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.
Fix: F-JUNI-RT-000500_fix
Configure the router to reject inbound route advertisements from a CE router for prefixes that are not allocated to that customer. Configure a prefix list containing prefixes belonging to the customers. [edit policy-options] set prefix-list CUST1_PREFIXES x.x.x.x/24 set prefix-list CUST1_PREFIXES x.x.x.x/24 set prefix-list CUST2_PREFIXES x.x.x.x/24 set prefix-list CUST2_PREFIXES x.x.x.x/24 Configure a policy-statement to filter customer routes. set policy-statement FILTER_CUST1_ROUTES term ACCEPT_ROUTES from prefix-list CUST1_PREFIXES set policy-statement FILTER_CUST1_ROUTES term then accept set policy-statement FILTER_CUST1_ROUTES term REJECT_OTHER then reject set policy-statement FILTER_CUST2_ROUTES term ACCEPT_ROUTES from prefix-list CUST2_PREFIXES set policy-statement FILTER_CUST2_ROUTES term then accept set policy-statement FILTER_CUST2_ROUTES term REJECT_OTHER then reject Apply the import policy to filter received routes for each customer group. [edit protocols bgp group CUST1] set import FILTER_CUST1_ROUTES [edit protocols bgp group CUST2] set import FILTER_CUST2_ROUTES
- RMF Control
- AC-4
- Severity
- M
- CCI
- CCI-001368
- Version
- JUNI-RT-000510
- Vuln IDs
-
- JUNI-RT-000510
- Rule IDs
-
- JUNI-RT-000510_rule
Checks: C-JUNI-RT-000510_chk
Review 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. Verify that a policy has been configured to filter prefixes for BGP advertisement as shown in the example below. } policy-options { … … … policy-statement BGP_ADVERTISE_POLICY { term INCLUDE_LOCAL { from { prefix-list OUR_PREFIXES; } then accept; } term INCLUDE_CUST1 { from { prefix-list CUST1_PREFIXES; } then accept; } term INCLUDE_CUST2 { from { prefix-list CUST2_PREFIXES; } then accept; } term REJECT_OTHER { then reject; } } Verify that the export statement as shown below references the advertise policy. protocols { bgp { group AS4 { type external; import FILTER_ROUTES; export BGP_ADVERTISE_POLICY; peer-as 4; neighbor x.x.x.x; } group CUST1 { type external; import FILTER_CUST1_ROUTES; export BGP_ADVERTISE_POLICY; peer-as 55; neighbor x.x.x.x; neighbor x.x.x.x; } group CUST2 { type external; import FILTER_CUST2_ROUTES; export BGP_ADVERTISE_POLICY; peer-as 44; neighbor x.x.x.x; neighbor x.x.x.x; } } … … … } Note: The prefix lists should have already been configured per the previous requirements. If the router is not configured to reject outbound route advertisements that belong to any customers or the local AS, this is a finding.
Fix: F-JUNI-RT-000510_fix
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. Configure a policy-statement to filter BGP route advertisements that will only include the local and customer prefixes. [edit policy-options] set policy-statement BGP_ADVERTISE_POLICY term INCLUDE_LOCAL from prefix-list OUR_PREFIXES set policy-statement BGP_ADVERTISE_POLICY term INCLUDE_LOCAL then accept set policy-statement BGP_ADVERTISE_POLICY term INCLUDE_CUST1 from prefix-list CUST1_PREFIXES set policy-statement BGP_ADVERTISE_POLICY term INCLUDE_CUST1 then accept set policy-statement BGP_ADVERTISE_POLICY term INCLUDE_CUST2 from prefix-list CUST2_PREFIXES set policy-statement BGP_ADVERTISE_POLICY term INCLUDE_CUST2 then accept set policy-statement BGP_ADVERTISE_POLICY term REJECT_OTHER then reject Note: The prefix lists should have already been configured per the previous requirements. Configure an export statement referencing the advertise policy on all external BGP peer groups as shown in the example below. [edit protocols bgp group GROUP_AS4] set export BGP_ADVERTISE_POLICY [edit protocols bgp group CUST1] set export BGP_ADVERTISE_POLICY [edit protocols bgp group CUST2] set export BGP_ADVERTISE_POLICY
- RMF Control
- SC-7
- Severity
- M
- CCI
- CCI-001097
- Version
- JUNI-RT-000520
- Vuln IDs
-
- JUNI-RT-000520
- Rule IDs
-
- JUNI-RT-000520_rule
Checks: C-JUNI-RT-000520_chk
Review the router configuration to verify that there is a filter defined to block route advertisements for prefixes that belong to the IP core. Verify a prefix list has been configured containing prefixes belonging to the local autonomous system as shown in the example below. policy-options { … … … prefix-list CORE_PREFIX { x.x.x.x/16; } Verify that a policy has been configured to not advertise prefixes belong to the core as shown in the example below. policy-options { … … … policy-statement BGP_ADVERTISE_POLICY { term EXCLUDE_CORE { from { prefix-list CORE_PREFIX; } then reject; } term INCLUDE_OTHER { then accept; } } Verify that the export statement as shown below references the advertise policy. protocols { bgp { group AS4 { type external; export BGP_ADVERTISE_POLICY; peer-as 4; neighbor x.x.x.x; } If the router is not configured to reject outbound route advertisements that belong to the IP core, this is a finding.
Fix: F-JUNI-RT-000520_fix
Configure the router to filter outbound route advertisements belonging to the IP core. Configure a prefix list containing prefixes belonging to the IP core. [edit policy-options] set prefix-list CORE_PREFIX x.x.x.x/16 Configure a policy-statement to filter BGP route advertisements that will exclude core prefixes. [edit policy-options] set policy-statement BGP_ADVERTISE_POLICY term EXCLUDE_CORE from prefix-list CORE_PREFIX set policy-statement BGP_ADVERTISE_POLICY term EXCLUDE_CORE then reject set policy-statement BGP_ADVERTISE_POLICY term INCLUDE_OTHER then accept Configure an export statement referencing the advertise policy on all external BGP peer groups as shown in the example below. [edit protocols bgp group GROUP_AS4] set export BGP_ADVERTISE_POLICY
- RMF Control
- AC-4
- Severity
- L
- CCI
- CCI-000032
- Version
- JUNI-RT-000530
- Vuln IDs
-
- JUNI-RT-000530
- Rule IDs
-
- JUNI-RT-000530_rule
Checks: C-JUNI-RT-000530_chk
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 a policy has been configured to filter AS_PATH attribute for received BGP advertisements as shown in the example below. policy-options { … … … policy-statement FILTER_AS4 { term ALLOW_AS4 { from as-path PEER_AS4; then accept; } term ELSE_REJECT { then reject; } } … … … as-path PEER_AS4 "^6$"; } Note: the characters “^” and “$” representing the beginning and the end of the expression respectively are optional and are implicitly defined if omitted. Verify that the import policy has been applied to all external BGP peers as shown in the example below. protocols { bgp { group GROUP_AS4 { type external; import [FILTER_AS4 FILTER_ROUTES]; peer-as 4; neighbor x.x.x.x; } If 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.
Fix: F-JUNI-RT-000530_fix
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. Configure a policy to filter the AS_PATH as shown in the example below. [edit policy-options] set as-path PEER_AS4 "^4$" set policy-statement FILTER_AS4 term ALLOW_AS4 from as-path PEER_AS4 set policy-statement FILTER_AS4 term ALLOW_AS4 then accept set policy-statement FILTER_AS4 term ELSE_REJECT then reject Apply the import policy as shown in the example below. [edit protocols bgp group GROUP_AS4] set import [FILTER_AS4 FILTER_ROUTES]
- RMF Control
- SC-5
- Severity
- M
- CCI
- CCI-002385
- Version
- JUNI-RT-000540
- Vuln IDs
-
- JUNI-RT-000540
- Rule IDs
-
- JUNI-RT-000540_rule
Checks: C-JUNI-RT-000540_chk
Review the router configuration to verify that the number of received prefixes from each eBGP neighbor is controlled. protocols { bgp { group GROUP_AS4 { type external; family inet { unicast { prefix-limit { maximum 10; teardown; } } } peer-as 4; neighbor x.x.x.x; } If 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.
Fix: F-JUNI-RT-000540_fix
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. [edit protocols bgp group GROUP_AS4] set family inet unicast prefix-limit maximum nnnnn teardown
- RMF Control
- SC-5
- Severity
- L
- CCI
- CCI-002385
- Version
- JUNI-RT-000550
- Vuln IDs
-
- JUNI-RT-000550
- Rule IDs
-
- JUNI-RT-000550_rule
Checks: C-JUNI-RT-000550_chk
Review the router configuration to determine if it is compliant with this requirement. Verify 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. policy-options { … … … } policy-statement NO_LONG_PREFIXES { from { route-filter 0.0.0.0/0 prefix-length-range /25-/32 reject; } } Note: It may be necessary to configure separate policy statements depending on the address space issued to each customer. Verify that there is an import statement referencing the policy statement to filter prefix length. protocols { bgp { … … … } group CUST1 { type external; import [ FILTER_CUST1_ROUTES NO_LONG_PREFIXES ]; peer-as 55; neighbor x.x.x.x; neighbor x.x.x.x; } group CUST2 { type external; import [ FILTER_CUST1_ROUTES NO_LONG_PREFIXES ]; peer-as 44; neighbor x.x.x.x; neighbor x.x.x.x; } If 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.
Fix: F-JUNI-RT-000550_fix
Configure the router to limit the prefix size on any route advertisement to /24 or the least significant prefixes issued to the customer. Configure a route filter to reject any prefix that is longer than /24. [edit policy-options] set policy-statement NO_LONG_PREFIXES from route-filter 0.0.0.0/0 prefix-length-range /25-/32 reject Apply the policy statement to the BGP customer groups. [edit protocols bgp group CUST1] set import NO_LONG_PREFIXES [edit protocols bgp group CUST2] set import NO_LONG_PREFIXES
- RMF Control
- CM-6
- Severity
- L
- CCI
- CCI-000366
- Version
- JUNI-RT-000560
- Vuln IDs
-
- JUNI-RT-000560
- Rule IDs
-
- JUNI-RT-000560_rule
Checks: C-JUNI-RT-000560_chk
Review the router configuration to verify that a loopback address has been configured. interfaces { … … … } lo0 { unit 0 { family inet { address 2.2.2.2/32; } } } } Verify that the loopback interface is used as the source address for all iBGP sessions. protocols { bgp { … … … } group IBGP_PEERS { type internal; local-address 2.2.2.2; neighbor x.x.x.x; } If the router does not use its loopback address as the source address for all iBGP sessions, this is a finding.
Fix: F-JUNI-RT-000560_fix
Configure the router to use its loopback address as the source address for all iBGP peering. [edit protocols bgp group IBGP_PEERS] set local-address 2.2.2.2
- RMF Control
- CM-6
- Severity
- L
- CCI
- CCI-000366
- Version
- JUNI-RT-000570
- Vuln IDs
-
- JUNI-RT-000570
- Rule IDs
-
- JUNI-RT-000570_rule
Checks: C-JUNI-RT-000570_chk
Review the router configuration to determine if it is compliant with this requirement. Verify that a loopback address has been configured as shown in the following example: } interfaces { … … … } lo0 { unit 0 { family inet { address 2.2.2.2/32; } } } } By 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. } routing-options { router-id 2.2.2.2; autonomous-system 5; } If the router is not configured do use its loopback address for LDP peering, this is a finding.
Fix: F-JUNI-RT-000570_fix
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. [edit routing-options] set router-id 2.2.2.2
- RMF Control
- CM-6
- Severity
- L
- CCI
- CCI-000366
- Version
- JUNI-RT-000580
- Vuln IDs
-
- JUNI-RT-000580
- Rule IDs
-
- JUNI-RT-000580_rule
Checks: C-JUNI-RT-000580_chk
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. OSPF Example: protocols { mpls { interface ge-0/0/0.0; } … … … ospf { export REDISTRIBUTE; area 0.0.0.0 { interface ge-0/0/0.0 { ldp-synchronization { hold-time 10; } … … … } } ldp { interface ge-0/0/0.0; } } IS-IS Example: protocols { mpls { interface ge-0/0/0.0; } … … … isis { level 1 authentication-key-chain ISIS_KEY; level 2 authentication-key-chain ISIS_KEY; interface ge-0/0/0.0 { ldp-synchronization { hold-time 10; } … … … } } ldp { interface ge-0/0/0.0; } } If the router is not configured to synchronize IGP and LDP, this is a finding.
Fix: F-JUNI-RT-000580_fix
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. [edit protocols ospf area 0.0.0.0] set interface ge-0/0/0.0 ldp-synchronization hold-time 10 [edit protocols isis] set interface ge-0/0/0.0 ldp-synchronization hold-time 10 Note: 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.
- RMF Control
- SC-5
- Severity
- L
- CCI
- CCI-001095
- Version
- JUNI-RT-000590
- Vuln IDs
-
- JUNI-RT-000590
- Rule IDs
-
- JUNI-RT-000590_rule
Checks: C-JUNI-RT-000590_chk
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. protocols { rsvp { interface ge-0/0/0.0 { aggregate; reliable; } } If the router configured with RSVP-TE does not have refresh reduction features enabled, this is a finding.
Fix: F-JUNI-RT-000590_fix
Configure the router to enable all refresh reduction features as shown in the example. [edit protocols rsvp] set interface ge-0/0/0.0 aggregate reliable Note: the aggregate reliable commands will enable the following RSVP refresh reduction features: message bundling, reliable message delivery, and summary refresh.
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- JUNI-RT-000600
- Vuln IDs
-
- JUNI-RT-000600
- Rule IDs
-
- JUNI-RT-000600_rule
Checks: C-JUNI-RT-000600_chk
Review the router configuration to verify that TTL propagation is disabled. protocols { mpls { no-propagate-ttl; } If the MPLS router is not configured to disable TTL propagation, this is a finding.
Fix: F-JUNI-RT-000600_fix
Configure the MPLS router to disable TTL propagation. [edit protocols mpls] set no-propagate-ttl
- RMF Control
- CM-6
- Severity
- H
- CCI
- CCI-000366
- Version
- JUNI-RT-000610
- Vuln IDs
-
- JUNI-RT-000610
- Rule IDs
-
- JUNI-RT-000610_rule
Checks: C-JUNI-RT-000610_chk
Review the design plan for deploying L3VPN and VRF-lite. Review 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. interfaces { … … … } ge-0/1/0 { description "link to Customer 1"; unit 0 { family inet { address 101.3.44.6/30; } } } … … … } routing-instances { L3VPN_CUST1 { description "Between PE1 & PE2"; instance-type vrf; interface ge-0/1/0.0; route-distinguisher 33:33; vrf-target target:33:33; vrf-table-label; protocols { ospf { area 0.0.0.1 { interface ge-0/1/0.0; } } } } } If any VRFs are not bound to the appropriate physical or logical interface, this is a finding.
Fix: F-JUNI-RT-000610_fix
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. [edit] set routing-instances L3VPN_CUST1 instance-type vrf set routing-instances L3VPN_CUST1 description "Between PE1 & PE2" set routing-instances L3VPN_CUST1 interface ge-0/1/0.0 set routing-instances L3VPN_CUST1 protocols ospf interface area 1 ge-0/1/0.0 set routing-instances L3VPN_CUST1 route-distinguisher 33:33 set routing-instances L3VPN_CUST1 vrf-target target:33:33 set routing-instances L3VPN_CUST1 vrf-table-label
- RMF Control
- CM-6
- Severity
- H
- CCI
- CCI-000366
- Version
- JUNI-RT-000620
- Vuln IDs
-
- JUNI-RT-000620
- Rule IDs
-
- JUNI-RT-000620_rule
Checks: C-JUNI-RT-000620_chk
Review the design plan for MPLS/L3VPN and VRF-lite to determine what RTs have been assigned for each VRF. Review 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. routing-instances { L3VPN_CUST1 { description "Between PE1 & PE2"; instance-type vrf; interface ge-0/1/0.0; route-distinguisher 33:33; vrf-target target:33:33; vrf-table-label; protocols { ospf { area 0.0.0.1 { interface ge-0/1/0.0; } } } } If there are VRFs configured with the wrong RT, this is a finding.
Fix: F-JUNI-RT-000620_fix
Configure the router to have each VRF instance defined with the correct RT. [edit] set routing-instances L3VPN_CUST1 vrf-target target:33:33
- RMF Control
- CM-6
- Severity
- M
- CCI
- CCI-000366
- Version
- JUNI-RT-000630
- Vuln IDs
-
- JUNI-RT-000630
- Rule IDs
-
- JUNI-RT-000630_rule
Checks: C-JUNI-RT-000630_chk
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. routing-instances { L3VPN_CUST1 { description "Between PE1 & PE2"; instance-type vrf; interface ge-0/1/0.0; route-distinguisher 33:33; vrf-target target:33:33; vrf-table-label; protocols { ospf { area 0.0.0.1 { interface ge-0/1/0.0; } } } } If the wrong RD has been configured for any VRF, this is a finding.
Fix: F-JUNI-RT-000630_fix
Configure the correct RD for each VRF. [edit] set routing-instances L3VPN_CUST1 route-distinguisher 33:33
- RMF Control
- IA-3
- Severity
- M
- CCI
- CCI-001958
- Version
- JUNI-RT-000640
- Vuln IDs
-
- JUNI-RT-000640
- Rule IDs
-
- JUNI-RT-000640_rule
Checks: C-JUNI-RT-000640_chk
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. ldp { interface ge-0/1/0.0; interface ge-0/1/1.0; session 8.8.8.8 { authentication-algorithm hmac-sha-1-96; authentication-key-chain LDP_KEY; } } If authentication is not being used for the LDP targeted sessions using a FIPS-approved message authentication code algorithm, this is a finding.
Fix: F-JUNI-RT-000640_fix
Implement authentication for all targeted LDP sessions using a FIPS-approved message authentication code algorithm. [edit security authentication-key-chains] set key-chain LDP_KEY key 1 start-time 2018-05-01.12:00 secret xxxxxxxxxxxxx set key-chain LDP_KEY key 2 start-time 2018-09-01.12:00 secret xxxxxxxxxxxxx set key-chain LDP_KEY key 3 start-time 2019-01-01.12:00 secret xxxxxxxxxxxxx [edit protocols ldp] set session 8.8.8.8 authentication-algorithm hmac-sha-1-96 authentication-key-chain LDP_KEY
- RMF Control
- CM-6
- Severity
- H
- CCI
- CCI-000366
- Version
- JUNI-RT-000650
- Vuln IDs
-
- JUNI-RT-000650
- Rule IDs
-
- JUNI-RT-000650_rule
Checks: C-JUNI-RT-000650_chk
Review the ingress and egress PE router configuration for each virtual circuit that has been provisioned. Verify 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). interfaces { ge-0/1/0.0 { encapsulation ethernet-ccc; unit 0 { } } … … … protocols { … … … } l2circuit { neighbor 8.8.8.8 { interface ge-0/1/0.0{ virtual-circuit-id 13; } } } If the correct VC ID has not been configured on both routers, this is a finding. Note: 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.
Fix: F-JUNI-RT-000650_fix
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. [edit protocols l2circuit] set neighbor 8.8.8.8 interface em0 virtual-circuit-id 13
- RMF Control
- CM-6
- Severity
- H
- CCI
- CCI-000366
- Version
- JUNI-RT-000660
- Vuln IDs
-
- JUNI-RT-000660
- Rule IDs
-
- JUNI-RT-000660_rule
Checks: C-JUNI-RT-000660_chk
Review the implementation plan and the VPLS IDs assigned to customer VLANs for the VPLS deployment. Review the PE router configuration to verify that customer attachment circuits are associated to the appropriate routing instance configured for the customers VPLS ID. interfaces { ge-0/1/0.0 { encapsulation ethernet-vpls; unit 0 { } } … … … routing-instances { VPLS_CUST2 { instance-type vpls; interface ge-0/1/0.0; route-distinguisher 22:22; vrf-target target:22:22; protocols { vpls { site-range 9; no-tunnel-services; site R8 { site-identifier 8; interface ge-0/1/0.0; } vpls-id 102; neighbor 8.8.8.8; } } } } If 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.
Fix: F-JUNI-RT-000660_fix
Assign globally unique VPLS ID to each VPLS routing instance as shown in the example [edit routing-instances VPLS_CUST2 protocols vpls] set vpls-id 102 neighbor 8.8.8.8
- RMF Control
- SC-5
- Severity
- M
- CCI
- CCI-001095
- Version
- JUNI-RT-000680
- Vuln IDs
-
- JUNI-RT-000680
- Rule IDs
-
- JUNI-RT-000680_rule
Checks: C-JUNI-RT-000680_chk
Review the router configuration to verify that storm control is enabled on CE-facing interfaces deploying VPLS. Verify that a flood filter has been configured for each VPLS routing instances as shown in the example below. routing-instances { VPLS_CUST2 { instance-type vpls; interface ge-0/1/0.0; route-distinguisher 22:22; vrf-target target:22:22; forwarding-options { family vpls { flood { input VPLS_FLOOD_FILTER; } } } protocols { vpls { site-range 9; no-tunnel-services; site R8 { site-identifier 8; interface ge-0/1/0.0; } vpls-id 102; neighbor 8.8.8.8; } } } } Review 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). firewall { … … … family vpls { filter VPLS_FLOOD_FILTER { term BROADCAST_TRAFFIC { from { traffic-type broadcast; } then { policer STORM_POLICER; accept; } } term MULTICAST_TRAFFIC { from { traffic-type multicast; } then { policer STORM_POLICER; accept; } } term UNKNOWN_UNICAST_TRAFFIC { from { traffic-type unknown-unicast; } then { policer STORM_POLICER; accept; } } } } Verify that the policer rates limits storm traffic. firewall { … … … policer STORM_POLICER { if-exceeding { bandwidth-limit 10m; burst-size-limit 5m; } then discard; } If storm control is not enabled, this is a finding.
Fix: F-JUNI-RT-000680_fix
Configure storm control for each VPLS bridge domain. Base the rate limiting on expected traffic rates plus some additional capacity. Configure a policer to rate limit traffic to provide storm control for all VPLS implementations as shown in the example. [edit firewall] set policer STORM_POLICER if-exceeding bandwidth-limit 10m burst-size-limit 5m set policer STORM_POLICER then discard Configure the filter to specify traffic types to rate limit broadcast, multicast, and unknown unicast storms as shown in the example. [edit firewall family vpls filter VPLS_FLOOD_FILTER] set term BROADCAST_TRAFFIC from traffic-type broadcast set term BROADCAST_TRAFFIC then policer STORM_POLICER accept set term MULTICAST_TRAFFIC from traffic-type multicast set term MULTICAST_TRAFFIC then policer STORM_POLICER accept set term UNKNOWN_UNICAST_TRAFFIC from traffic-type unknown-unicast set term UNKNOWN_UNICAST_TRAFFIC then policer STORM_POLICER accept Apply the storm control filter to all VPLS routing instances as shown in the example. [edit routing-instances VPLS_CUST2] set forwarding-options family vpls flood input VPLS_FLOOD_FILTER
- RMF Control
- SC-5
- Severity
- L
- CCI
- CCI-002385
- Version
- JUNI-RT-000690
- Vuln IDs
-
- JUNI-RT-000690
- Rule IDs
-
- JUNI-RT-000690_rule
Checks: C-JUNI-RT-000690_chk
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. routing-instances { VPLS_CUST2 { instance-type vpls; interface ge-0/1/0.0; route-distinguisher 22:22; vrf-target target:22:22; } protocols { vpls { site-range 9; no-tunnel-services; site R8 { site-identifier 8; interface ge-0/1/0.0; } vpls-id 102; neighbor 8.8.8.8; } pim-snooping; } } } } If the router is not configured to implement PIM snooping for each VPLS bridge domain, this is a finding.
Fix: F-JUNI-RT-000690_fix
Configure PIM snooping for each VPLS bridge domain as shown in the example below. [edit routing-instances VPLS_CUST2] set routing-instances VPLS_CUST2 protocols pim-snooping
- RMF Control
- SC-5
- Severity
- M
- CCI
- CCI-001094
- Version
- JUNI-RT-000700
- Vuln IDs
-
- JUNI-RT-000700
- Rule IDs
-
- JUNI-RT-000700_rule
Checks: C-JUNI-RT-000700_chk
Review the PE router configuration to determine if a MAC address limit has been set for each VPLS bridge domain. routing-instances { VPLS_CUST2 { instance-type vpls; interface ge-0/1/0.0; route-distinguisher 22:22; vrf-target target:22:22; protocols { vpls { site-range 9; mac-table-size { nnnn; } no-tunnel-services; site R8 { site-identifier 8; interface ge-0/1/0.0; } vpls-id 102; neighbor 8.8.8.8; } } } } If a limit has not been configured, this is a finding.
Fix: F-JUNI-RT-000700_fix
Configure a MAC address learning limit for each VPLS bridge domain. [edit routing-instances VPLS_CUST2 protocols vpls] set mac-table-size nnnn
- RMF Control
- SC-7
- Severity
- H
- CCI
- CCI-001097
- Version
- JUNI-RT-000710
- Vuln IDs
-
- JUNI-RT-000710
- Rule IDs
-
- JUNI-RT-000710_rule
Checks: C-JUNI-RT-000710_chk
Review the router configuration to verify that an ingress filter is applied to all CE-facing interfaces. interfaces { ge-0/1/0 { description "link to Customer 2"; unit 0 { family inet { filter { input INGRESS_FILTER; } address x.x.x.x/30; } } } Verify that the ingress filter discards and logs packets destined to the IP core address space. firewall { family inet { filter INGRESS_FILTER { term BLOCK_TO_CORE { from { destination-address { x.x.x.x/8; } } then { log; discard; } } term ALLOW_TRANSIT_TRAFFIC { then accept; } } } If the PE router is not configured to block any traffic with a destination address assigned to the IP core infrastructure, this is a finding. Note: Internet Control Message Protocol (ICMP) echo requests and traceroutes will be allowed to the edge from external adjacent neighbors.
Fix: F-JUNI-RT-000710_fix
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. Configure an ingress filter to discard and log packets destined to the IP core address space. [edit firewall family inet] set filter INGRESS_FILTER term BLOCK_TO_CORE from destination-address x.x.x.x/8 set filter INGRESS_FILTER term BLOCK_TO_CORE then log discard set filter INGRESS_FILTER term ALLOW_TRANSIT_TRAFFIC then accept Apply the filter to all CE-facing interfaces. [edit interfaces ge-0/1/0 unit 0] set family inet filter input INGRESS_FILTER
- RMF Control
- SC-7
- Severity
- M
- CCI
- CCI-001097
- Version
- JUNI-RT-000720
- Vuln IDs
-
- JUNI-RT-000720
- Rule IDs
-
- JUNI-RT-000720_rule
Checks: C-JUNI-RT-000720_chk
Review the router configuration to determine if uRPF loose mode is enabled on all CE-facing interfaces. interfaces { ge-0/1/0 { description "link to Customer 2"; unit 0 { family inet { rpf-check { mode loose; } address x.x.x.x/30; } } } If uRPF loose mode is not enabled on all CE-facing interfaces, this is a finding.
Fix: F-JUNI-RT-000720_fix
Configure uRPF loose mode on all CE-facing interfaces as shown in the example [edit interfaces ge-0/1/0 unit 0 family inet] set rpf-check mode loose
- RMF Control
- SC-7
- Severity
- M
- CCI
- CCI-002403
- Version
- JUNI-RT-000730
- Vuln IDs
-
- JUNI-RT-000730
- Rule IDs
-
- JUNI-RT-000730_rule
Checks: C-JUNI-RT-000730_chk
Review the router configuration to determine if it will block all packets with IP options. firewall { family inet { filter INGRESS_FILTER { term BLOCK_TO_CORE { from { destination-address { x.x.x.x/8; } } then { log; discard; } } term BLOCK_IP_OPTIONS { from { ip-options any; } then { discard; } } term ALLOW_TRANSIT_TRAFFIC { then accept; } } } If the router is not configured to drop all packets with IP options, this is a finding.
Fix: F-JUNI-RT-000730_fix
Configure the router to drop all packets with IP options. [edit firewall family inet filter INGRESS_FILTER] set term BLOCK_IP_OPTIONS from ip-options any set term BLOCK_IP_OPTIONS then discard insert term BLOCK_IP_OPTIONS before term ALLOW_TRANSIT_TRAFFIC
- RMF Control
- SC-5
- Severity
- L
- CCI
- CCI-001095
- Version
- JUNI-RT-000740
- Vuln IDs
-
- JUNI-RT-000740
- Rule IDs
-
- JUNI-RT-000740_rule
Checks: C-JUNI-RT-000740_chk
Review the router configuration and verify that a QoS policy has been configured to provide preferred treatment for mission-critical applications in accordance with the QoS DoDIN Technical Profile. PE routers are responsible for classifying customer traffic and setting the forwarding class. Verify that a Multifield (MF) classifier has been configured to classify traffic based on protocol and ports as shown in the example below. firewall { family inet { … … … } filter CLASSIFY_TRAFFIC { term SIP { from { protocol tcp; port 5060; } then { forwarding-class expedited-forwarding; accept; } } term RTP { from { protocol udp; port 16384-32767; } then { forwarding-class expedited-forwarding; accept; } } term H.323 { from { protocol tcp; port 1720; } then { loss-priority high; forwarding-class assured-forwarding; accept; } } term VIDEO_GK { from { protocol udp; port 1718-1719; } then { loss-priority high; forwarding-class assured-forwarding; accept; } } term VIDEO_BEARER { from { protocol udp; port 3230-3235; } then { loss-priority low; forwarding-class assured-forwarding; accept; } } term SSH { from { protocol tcp; port ssh; } then { loss-priority high; forwarding-class assured-forwarding; accept; } } term TACACS { from { protocol tcp; port tacacs; } then { loss-priority high; forwarding-class assured-forwarding; accept; } } term SNMP { from { protocol tcp; port snmp; } then { loss-priority high; forwarding-class assured-forwarding; accept; } } term ICMP { from { protocol icmp; } then { loss-priority high; forwarding-class assured-forwarding; accept; } } term OSPF { from { protocol ospf; } then { forwarding-class network-control; accept; } } term PIM { from { protocol pim; } then { forwarding-class network-control; accept; } } term ACCEPT_OTHER { then { forwarding-class best-effort; accept; } } } } Verify that the classifier filter is bound to all CE-facing interfaces as shown in the example below. interfaces { ge-0/0/0 { description "Customer 1"; unit 0 { family inet { filter { CLASSIFY_TRAFFIC } address x.x.x.x/30; } } } Verify that drop profiles and schedulers have been configured that define how queued egress packets are prioritized. class-of-service { drop-profiles { LOW_DROP { fill-level 95 drop-probability 0; fill-level 100 drop-probability 100; } HIGH_DROP { fill-level 50 drop-probability 10; fill-level 95 drop-probability 100; } } schedulers { VOIP_SCHED { transmit-rate percent 10; buffer-size percent 10; priority high; } CONTROL_PLANE_SCHED { transmit-rate percent 10; buffer-size percent 10; priority medium-high; } VIDEO_SCHED { transmit-rate percent 20; buffer-size percent 20; priority medium-high; drop-profile-map loss-priority low protocol any drop-profile LOW_DROP; } MGMT_SCHED { transmit-rate percent 10; buffer-size percent 10; priority medium-low; drop-profile-map loss-priority high protocol any drop-profile HIGH_DROP; } BEST_EFFORT_SCHED { transmit-rate percent 50; buffer-size percent 50; priority low; } } } Verify that scheduler maps have been configured to link the forwarding classes to schedulers as shown in the example below. class-of-service { … … … } scheduler-maps { QOS_SCHED_MAP { forwarding-class expedited-forwarding scheduler VOIP_SCHED; forwarding-class network-control scheduler CONTROL_PLANE_SCHED; forwarding-class assured-forwarding scheduler MGMT_SCHED; forwarding-class best-effort scheduler BEST_EFFORT_SCHED; } } Verify that the configured QoS scheduler map has been applied to all interfaces and that the rewrite rules have been applied to all core-facing interfaces as shown in the example below. class-of-service { … … … } interfaces { ge-0/0/1 { scheduler-map QOS_SCHED_MAP; unit 0 { rewrite-rules { dscp default; } } } ge-0/1/1 { scheduler-map QOS_SCHED_MAP; unit 0 { rewrite-rules { dscp default; } } } ge-1/0/0 { scheduler-map QOS_SCHED_MAP; } ge-1/0/1 { scheduler-map QOS_SCHED_MAP; } } If the router is not configured to enforce a QoS policy in accordance with the QoS DoDIN Technical Profile, this is a finding.
Fix: F-JUNI-RT-000740_fix
Configure a QoS policy on each router in accordance with the QoS DoDIN Technical Profile. The PE router must classify ingress traffic entering the backbone. Configure a Multifield (MF) classifier to classify traffic based on protocol and ports as shown in the example below. [edit firewall family inet filter CLASSIFY_TRAFFIC] set term SIP from protocol tcp set term SIP from port 5060 set term SIP then forwarding-class expedited-forwarding set term SIP then accept set term RTP from protocol tcp set term RTP from port 16384-32767 set term RTP then forwarding-class expedited-forwarding set term RTP then accept set term H.323 from protocol tcp set term H.323 from port 1720 set term H.323 then forwarding-class assured-forwarding loss-priority low set term H.323 then accept set term VIDEO_GK from protocol udp set term VIDEO_GK from port 1718-1719 set term VIDEO_GK then forwarding-class assured-forwarding loss-priority low set term VIDEO_GK then accept set term VIDEO_BEARER from protocol udp set term VIDEO_BEARER from port 3230-3235 set term VIDEO_BEARER then forwarding-class assured-forwarding loss-priority low set term VIDEO_BEARER then accept set term SSH from protocol tcp set term SSH from port ssh set term SSH then forwarding-class assured-forwarding loss-priority high set term SSH then accept set term TACACS from protocol tcp set term TACACS from port tacacs set term TACACS then forwarding-class assured-forwarding loss-priority high set term TACACS then accept set term SNMP from protocol tcp set term SNMP from port snmp set term SNMP then forwarding-class assured-forwarding loss-priority high set term SNMP then accept set term ICMP from protocol icmp set term ICMP then forwarding-class assured-forwarding loss-priority high set term ICMP then accept set term OSPF from protocol ospf set term OSPF then forwarding-class network-control set term OSPF then accept set term PIM from protocol pim set term PIM then forwarding-class network-control set term PIM then accept set term ACCEPT_OTHER then forwarding-class best-effort set term ACCEPT_OTHER then accept Configure drop profiles. [edit class-of-service] set drop-profiles LOW_DROP fill-level 95 drop-probability 0 set drop-profiles LOW_DROP fill-level 100 drop-probability 100 set drop-profiles HIGH_DROP fill-level 50 drop-probability 10 set drop-profiles HIGH_DROP fill-level 95 drop-probability 100 Configure QoS schedulers to define how queued egress packets are prioritized. [edit class-of-service schedulers] set VOIP_SCHED transmit-rate percent 10 set VOIP_SCHED buffer-size percent 10 set VOIP_SCHED priority high set VIDEO_SCHED transmit-rate percent 20 set VIDEO_SCHED buffer-size percent 20 set VIDEO_SCHED priority medium-high set VIDEO_SCHED drop-profile-map protocol any loss-priority low drop-profile LOW_DROP set MGMT_SCHED transmit-rate percent 10 set MGMT_SCHED buffer-size percent 10 set MGMT_SCHED priority medium-low set MGMT_SCHED drop-profile-map protocol any loss-priority high drop-profile HIGH_DROP set CONTROL_PLANE_SCHED transmit-rate percent 10 set CONTROL_PLANE_SCHED buffer-size percent 10 set CONTROL_PLANE_SCHED priority medium-high set BEST_EFFORT_SCHED transmit-rate percent 50 set BEST_EFFORT_SCHED buffer-size percent 50 set BEST_EFFORT_SCHED priority low Configure scheduler maps to link the forwarding classes to schedulers. [edit class-of-service scheduler-maps QOS_SCHED_MAP] set forwarding-class expedited-forwarding scheduler VOIP_SCHED set forwarding-class network-control scheduler CONTROL_PLANE_SCHED set forwarding-class assured-forwarding scheduler VIDEO_SCHED set forwarding-class assured-forwarding scheduler MGMT_SCHED set forwarding-class best-effort scheduler BEST_EFFORT_SCHED Apply the filter that classifies traffic inbound on all CE-facing interfaces [edit interfaces ge-0/1/0 unit 0] set family inet filter input CLASSIFY_TRAFFIC Apply the scheduler map to all interfaces as shown in the example. [edit class-of-service interfaces] set ge-0/0/1 scheduler-map QOS_SCHED_MAP set ge-0/1/1 scheduler-map QOS_SCHED_MAP set ge-1/0/0 scheduler-map QOS_SCHED_MAP set ge-1/0/1 scheduler-map QOS_SCHED_MAP Apply the rewrite rules to mark egress packets on all core-facing interfaces as shown in the example. [edit class-of-service interfaces] set ge-0/0/1 unit 0 rewrite-rules dscp default set ge-0/1/1 unit 0 rewrite-rules dscp default
- RMF Control
- SC-5
- Severity
- L
- CCI
- CCI-001095
- Version
- JUNI-RT-000750
- Vuln IDs
-
- JUNI-RT-000750
- Rule IDs
-
- JUNI-RT-000750_rule
Checks: C-JUNI-RT-000750_chk
Since PE routers have classified traffic types and set DSCP values for packets received from CE routers, all P routers must be configured to use the configured or default Behavior Aggregate (BA) classifier on all interfaces as shown in the example below. PE routers must be configured to use the same BA classifier on all core-facing interfaces. class-of-service { … … … } interfaces { ge-0/0/1 { unit 0 { classifiers { dscp default; } } } ge-0/1/0 { unit 0 { classifiers { dscp default; } } } ge-1/0/1 { unit 0 { classifiers { dscp default; } } } ge-1/1/0 { unit 0 { classifiers { dscp default; } } } If the router is not configured to implement a QoS policy in accordance with the QoS DoDIN Technical Profile, this is a finding.
Fix: F-JUNI-RT-000750_fix
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. [edit class-of-service interfaces] set ge-0/0/1 unit 0 classifiers dscp default set ge-0/1/0 unit 0 classifiers dscp default set ge-1/0/1 unit 0 classifiers dscp default set ge-1/1/0 unit 0 classifiers dscp default
- RMF Control
- SC-5
- Severity
- M
- CCI
- CCI-001095
- Version
- JUNI-RT-000760
- Vuln IDs
-
- JUNI-RT-000760
- Rule IDs
-
- JUNI-RT-000760_rule
Checks: C-JUNI-RT-000760_chk
Verify that a filter has been configured to classify customer's traffic based on protocol and ports as shown in the example below. firewall { family inet { … … … } filter CLASSIFY_CUST1_TRAFFIC { term SIP { from { protocol tcp; port 5060; } then { forwarding-class expedited-forwarding; accept; } } term RTP { from { protocol udp; port 16384-32767; } then { forwarding-class expedited-forwarding; accept; } } term APP1 { from { protocol tcp; port nnnn; } then { loss-priority low; forwarding-class assured-forwarding; accept; } } term APP2 { from { protocol tcp; port nnnn; } then { loss-priority high; forwarding-class assured-forwarding; accept; } } term ACCEPT_OTHER { then { forwarding-class best-effort; accept; } } } } Verify that the classifier filter is bound to all CE-facing interfaces as shown in the example below. interfaces { ge-0/0/0 { description "Customer 1"; unit 0 { family inet { filter { CLASSIFY_CUST1_TRAFFIC } address x.x.x.x/30; } } } Verify that drop profiles and schedulers have been configured that define how queued egress packets are prioritized. class-of-service { drop-profiles { LOW_DROP { fill-level 95 drop-probability 0; fill-level 100 drop-probability 100; } HIGH_DROP { fill-level 50 drop-probability 10; fill-level 95 drop-probability 100; } } schedulers { VOIP_SCHED { transmit-rate percent 10; buffer-size percent 10; priority high; } APP1_SCHED { transmit-rate percent 20; buffer-size percent 20; priority medium-high; drop-profile-map loss-priority low protocol any drop-profile LOW_DROP; } APP2_SCHED { transmit-rate percent 10; buffer-size percent 10; priority medium-low; drop-profile-map loss-priority high protocol any drop-profile HIGH_DROP; } BEST_EFFORT_SCHED { transmit-rate percent 60; buffer-size percent 60; priority low; } } } Verify that scheduler maps have been configured to link the forwarding classes to schedulers as shown in the example below. class-of-service { … … … } scheduler-maps { QOS_SCHED_MAP { forwarding-class expedited-forwarding scheduler VOIP_SCHED; forwarding-class network-control scheduler APP1_SCHED; forwarding-class assured-forwarding scheduler APP2_SCHED; forwarding-class best-effort scheduler BEST_EFFORT_SCHED; } } Verify that the configured QoS scheduler map and the rewrite rules have been applied to all core-facing interfaces as shown in the example below. class-of-service { … … … } interfaces { ge-0/0/1 { scheduler-map QOS_SCHED_MAP; unit 0 { rewrite-rules { dscp default; } } } ge-0/1/1 { scheduler-map QOS_SCHED_MAP; unit 0 { rewrite-rules { dscp default; } } } If the PE router does not enforce a QoS policy to ensure that all customer traffic receives forwarding treatment as specified in the SLA, this is a finding.
Fix: F-JUNI-RT-000760_fix
Configure a QoS policy to provide traffic forwarding treatment as specified in the SLA. The PE router must classify ingress traffic entering the backbone. Configure a filter to classify traffic based on protocol and ports as shown in the example below. [edit firewall family inet filter CLASSIFY_CUST1_TRAFFIC] set term SIP from protocol tcp set term SIP from port 5060 set term SIP then forwarding-class expedited-forwarding set term SIP then accept set term RTP from protocol udp set term RTP from port 16384-32767 set term RTP then forwarding-class expedited-forwarding set term RTP then accept set term APP1 from protocol tcp set term APP1 from port nnnn set term APP1then forwarding-class assured-forwarding loss-priority low set term APP1 then accept set term APP2 from protocol tcp set term APP2 from port nnnn set term APP2 then forwarding-class assured-forwarding loss-priority high set term APP2 then accept set term ACCEPT_OTHER then forwarding-class best-effort set term ACCEPT_OTHER then accept Configure drop profiles. [edit class-of-service] set drop-profiles LOW_DROP fill-level 95 drop-probability 0 set drop-profiles LOW_DROP fill-level 100 drop-probability 100 set drop-profiles HIGH_DROP fill-level 50 drop-probability 10 set drop-profiles HIGH_DROP fill-level 95 drop-probability 100 Configure QoS schedulers to define how queued egress packets are prioritized. [edit class-of-service schedulers] set VOIP_SCHED transmit-rate percent 10 set VOIP_SCHED buffer-size percent 10 set VOIP_SCHED priority high set APP1_SCHED transmit-rate percent 20 set APP1_SCHED buffer-size percent 20 set APP1_SCHED priority medium-low set APP1_SCHED drop-profile-map protocol any loss-priority low drop-profile LOW_DROP set APP2_SCHED transmit-rate percent 10 set APP2_SCHED buffer-size percent 10 set APP2_SCHED priority medium-low set APP2_SCHED drop-profile-map protocol any loss-priority high drop-profile HIGH_DROP set BEST_EFFORT_SCHED transmit-rate percent 60 set BEST_EFFORT_SCHED buffer-size percent 60 set BEST_EFFORT_SCHED priority low Configure scheduler maps to link the forwarding classes to schedulers. [edit class-of-service scheduler-maps QOS_SCHED_MAP] set forwarding-class expedited-forwarding scheduler VOIP_SCHED set forwarding-class assured-forwarding scheduler APP1_SCHED set forwarding-class assured-forwarding scheduler APP2_SCHED set forwarding-class best-effort scheduler BEST_EFFORT_SCHED Apply the filter that classifies traffic inbound on all CE-facing interfaces [edit interfaces ge-0/1/0 unit 0] set family inet filter input CLASSIFY_CUST1_TRAFFIC Apply the scheduler map to all core-facing interfaces as shown in the example. [edit class-of-service interfaces] set ge-0/0/1 scheduler-map QOS_SCHED_MAP set ge-0/1/1 scheduler-map QOS_SCHED_MAP Apply the rewrite rules to mark egress packets on all core-facing interfaces as shown in the example. [edit class-of-service interfaces] set ge-0/0/1 unit 0 rewrite-rules dscp default set ge-0/1/1 unit 0 rewrite-rules dscp default
- RMF Control
- SC-5
- Severity
- M
- CCI
- CCI-001095
- Version
- JUNI-RT-000770
- Vuln IDs
-
- JUNI-RT-000770
- Rule IDs
-
- JUNI-RT-000770_rule
Checks: C-JUNI-RT-000770_chk
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. class-of-service { … … … } forwarding-classes { class CS1 queue-num 7 priority low; } The 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. PE Router only - Verify that the Multifield (MF) classifier has provisioned for this class as shown in the example below. firewall { family inet { filter CLASSIFY_TRAFFIC { … … … } term SCAVENGER { from { dscp cs1; } then { forwarding-class CS1; accept; } } term ACCEPT_OTHER { then { forwarding-class best-effort; accept; } } } } } PE 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. class-of-service { classifiers { dscp CLASSIFIER { import default; forwarding-class CS1 { loss-priority high code-points 001000; } } } Note: 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). P router – Verify that the BA classifier has been applied to all interfaces as shown in the example below. class-of-service { … … … } interfaces { ge-0/0/1 { unit 0 { classifiers { dscp CLASSIFIER; } } } ge-0/1/1 { unit 0 { classifiers { dscp CLASSIFIER; } } } } } Remaining steps only apply to the PE router. Verify that a scheduler has been configured for the Scavenger class as shown in the example below. class-of-service { … … … } schedulers { … … … } SCAVENGER_SCHED { transmit-rate percent 5; buffer-size percent 5; priority low; } } } Verify that the scheduler has been added to the scheduler map. class-of-service { … … … } scheduler-maps { QOS_SCHED_MAP { forwarding-class expedited-forwarding scheduler VOIP_SCHED; forwarding-class network-control scheduler CONTROL_PLANE_SCHED; forwarding-class assured-forwarding scheduler MGMT_SCHED; forwarding-class best-effort scheduler BEST_EFFORT_SCHED; forwarding-class CS1 scheduler SCAVENGER_SCHED; } } Verify that rewrite rules have been created to mark DSCP CS1 for those packets assigned to the Scavenger class with the appropriate code points. class-of-service { … … … } rewrite-rules { dscp REWRITE_DSCP { import default; forwarding-class CS1 { loss-priority high code-point 001000; } } } Verify that the scheduler map, rewrite rules, and the BA classifier has been applied to all core-facing interfaces. class-of-service { … … … } interfaces { ge-2/1/1 { scheduler-map QOS_SCHED_MAP; unit 0 { classifiers { dscp CLASSIFIER; } rewrite-rules { dscp REWRITE_DSCP; } } } ge-2/0/1 { scheduler-map QOS_SCHED_MAP; unit 0 { rewrite-rules { dscp REWRITE_DSCP; } } } } If QoS policy to limit the effects of packet flooding denial-of-service (DoS) attacks has not been configured, this is a finding.
Fix: F-JUNI-RT-000770_fix
Configure a forwarding class has been configured for the Scavenger class as shown in the example below. [edit class-of-service forwarding-classes] set class CS1 queue-num 7 priority low The 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. PE Router only – Configure a Multifield (MF) classifier to provision for the Scavenger class as shown in the example below. [edit firewall family inet filter CLASSIFY_TRAFFIC] set term SCAVENGER from dscp cs1 set term SCAVENGER then forwarding-class CS1 accept insert term SCAVENGER before term ACCEPT_OTHER PE and P Router – Configure a Behavior aggregate (BA) classifier to match on the packets marked with DSCP CS1. [edit class-of-service classifiers] set dscp CLASSIFIER import default forwarding-class CS1 loss-priority high code-points 001000 P router only – Apply the BA classifier to all interfaces [edit class-of-service interfaces] set ge-0/0/1 unit 0 classifiers dscp CLASSIFIER set ge-0/1/1 unit 0 classifiers dscp CLASSIFIER Remaining steps are only applicable to the PE router. Configure a scheduler for the Scavenger class. [edit class-of-service schedulers] set SCAVENGER_SCHED transmit-rate percent 5 set SCAVENGER_SCHED buffer-size percent 5 set SCAVENGER_SCHED priority low set BEST_EFFORT_SCHED transmit-rate percent 55 Add the Scavenger scheduler to the scheduler map. [edit class-of-service scheduler-maps QOS_SCHED_MAP] set forwarding-class CS1 scheduler SCAVENGER_SCHED Apply the scheduler map to all core-facing interfaces. [edit class-of-service interfaces] set ge-2/1/1 scheduler-map QOS_SCHED_MAP set ge-1/0/1 scheduler-map QOS_SCHED_MAP Note: The above step should already have been completed. Configure rewrite rules to ensure egress Scavenger packets will continue to be marked with DSCP CS1. [edit class-of-service rewrite-rules] set dscp REWRITE_DSCP import default forwarding-class CS1 loss-priority high code-point 001000 Apply the configured rewrite rules to all core-facing interfaces. [edit class-of-service interfaces] set ge-2/1/1 unit 0 rewrite-rules dscp REWRITE_DSCP set ge-1/0/1 unit 0 rewrite-rules dscp REWRITE_DSCP
- RMF Control
- AC-4
- Severity
- M
- CCI
- CCI-001414
- Version
- JUNI-RT-000780
- Vuln IDs
-
- JUNI-RT-000780
- Rule IDs
-
- JUNI-RT-000780_rule
Checks: C-JUNI-RT-000780_chk
Review the network's multicast topology diagram. Review the router configuration to verify that only the PIM interfaces as shown in the multicast topology diagram are enabled for PIM. protocols { … … … pim { interface ge-1/0/1.0 { mode sparse; } interface ge-1/1/1.0 { mode sparse; } interface ge-2/1/0.0 { mode sparse; } interface ge-2/1/1.0 { mode sparse; } } If an interface is not required to support multicast routing and it is enabled, this is a finding.
Fix: F-JUNI-RT-000780_fix
Document all enabled interfaces for PIM in the network's multicast topology diagram. Disable support for PIM on interfaces that are not required to support it. [edit protocols pim] delete interface ge-2/1/1.0
- RMF Control
- AC-4
- Severity
- M
- CCI
- CCI-001414
- Version
- JUNI-RT-000790
- Vuln IDs
-
- JUNI-RT-000790
- Rule IDs
-
- JUNI-RT-000790_rule
Checks: C-JUNI-RT-000790_chk
This requirement is not applicable for the DoDIN Backbone. Verify all interfaces enabled for PIM have a neighbor filter bound to the interface as shown in the example below. protocols { … … … pim { interface ge-1/0/1.0 { mode sparse; neighbor-policy PIM_NBR1_POLICY; } interface ge-1/1/1.0 { mode sparse; neighbor-policy PIM_NBR2_POLICY; } interface ge-2/1/0.0 { mode sparse; neighbor-policy PIM_NBR3_POLICY; } } Review the prefix list and policy statements configured for filtering PIM neighbors as shown in the example below. policy-options { prefix-list PIM_NBR1 { x.x.x.x/32; } prefix-list PIM_NBR2 { x.x.x.x/32; } prefix-list PIM_NBR3 { x.x.x.x/32; } policy-statement PIM_NBR1_POLICY { from { prefix-list PIM_NBR1; } then accept; } policy-statement PIM_NBR2_POLICY { from { prefix-list PIM_NBR2; } then accept; } policy-statement PIM_NBR3_POLICY { from { prefix-list PIM_NBR3; } then accept; } If PIM neighbor filters are not bound to all interfaces that have PIM enabled, this is a finding.
Fix: F-JUNI-RT-000790_fix
This requirement is not applicable for the DoDIN Backbone. Configure neighbor filters to only accept PIM control plane traffic from documented PIM neighbors. Bind neighbor filters to all PIM enabled interfaces. Configure prefix list for each neighbor [edit policy-options] set prefix-list PIM_NBR1 x.x.x.x/32 set prefix-list PIM_NBR2 x.x.x.x/32 set prefix-list PIM_NBR3 x.x.x.x/32 Configure policy statements for each PIM neighbor [edit policy-options] set policy-statement PIM_NBR1_POLICY from prefix-list PIM_NBR1 set policy-statement PIM_NBR1_POLICY then accept set policy-statement PIM_NBR2_POLICY from prefix-list PIM_NBR1 set policy-statement PIM_NBR2_POLICY then accept set policy-statement PIM_NBR3_POLICY from prefix-list PIM_NBR1 set policy-statement PIM_NBR3_POLICY then accept Apply the neighbor policy to all interfaces enabled for PIM [edit protocols pim] set interface ge-1/0/1.0 neighbor-policy PIM_NBR1_POLICY set interface ge-1/1/1.0 neighbor-policy PIM_NBR1_POLICY set interface ge-2/1/0.0 neighbor-policy PIM_NBR1_POLICY
- RMF Control
- AC-4
- Severity
- L
- CCI
- CCI-001414
- Version
- JUNI-RT-000800
- Vuln IDs
-
- JUNI-RT-000800
- Rule IDs
-
- JUNI-RT-000800_rule
Checks: C-JUNI-RT-000800_chk
Review the multicast topology diagram to determine if there are any documented Local -Scope (239.255.0.0/16) or Organization-Scope (239.192.0.0/14) boundaries. Verify the boundaries have been enforced as shown in the configuration example below. routing-options { … … … multicast { scope LOCAL_SCOPE { prefix 239.255.0.0/16; interface [ge-1/0/1.0 ge-1/1/1.0]; } scope ORGANIZATION_SCOPE { prefix 239.192.0.0/14; interface ge-2/0/1.0; } } } If the appropriate boundaries are not configured on applicable multicast-enabled interfaces, this is a finding.
Fix: F-JUNI-RT-000800_fix
Configure the appropriate boundaries to contain packets addressed within the administratively scoped zone as shown in the example below. [edit routing-options] set multicast scope LOCAL_SCOPE interface ge-1/0/1.0 prefix 239.255.0.0/16 set multicast scope LOCAL_SCOPE interface ge-1/0/1.0 prefix 239.255.0.0/16 set multicast scope ORGANIZATION_SCOPE interface ge-2/0/1.0 prefix 239.192.0.0/14
- RMF Control
- SC-5
- Severity
- L
- CCI
- CCI-002385
- Version
- JUNI-RT-000810
- Vuln IDs
-
- JUNI-RT-000810
- Rule IDs
-
- JUNI-RT-000810_rule
Checks: C-JUNI-RT-000810_chk
Review the router configuration to determine if forwarding cache thresholds are defined as shown in the example below. routing-options { multicast { … … … } forwarding-cache { threshold { suppress 5000; reuse 4000; } } } } If the RP router is not configured to limit the multicast forwarding cache to ensure that its resources are not saturated, this is a finding.
Fix: F-JUNI-RT-000810_fix
Configure the router to limit the multicast forwarding cache for source-active entries. [edit routing-options multicast] set forwarding-cache threshold suppress 5000 reuse 4000
- RMF Control
- AC-4
- Severity
- L
- CCI
- CCI-001414
- Version
- JUNI-RT-000820
- Vuln IDs
-
- JUNI-RT-000820
- Rule IDs
-
- JUNI-RT-000820_rule
Checks: C-JUNI-RT-000820_chk
Verify that the RP router is configured to filter PIM register messages. Verify that the RP has a register policy enabled as shown in the example below. protocols { … … … } pim { rp { rp-register-policy MULTICAST_REGISTER_POLICY; local { address 2.2.2.2; } } Verify that the register policy has defined both bad multicast groups and sources as shown in the example below. policy-options { … … … } policy-statement MULTICAST_REGISTER_POLICY { term BAD_SOURCES { from { source-address-filter x.x.x.x/32 exact; source-address-filter x.x.x.x/24 orlonger; } then reject; } term BAD_GROUPS { from { route-filter 224.1.1.0/24 orlonger; route-filter 225.1.2.3/32 exact; route-filter 239.0.0.0/8 orlonger; … … … route-filter 232.0.0.0/8 orlonger; } then reject; } term ALLOW_OTHER { then accept; } } If 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.
Fix: F-JUNI-RT-000820_fix
Configure the router to filter PIM register messages received from a multicast DR for any undesirable multicast groups or BOGON sources. [edit policy-options policy-statement MULTICAST_REGISTER_POLICY] set term BAD_SOURCES from source-address-filter x.x.x.x/32 exact set term BAD_SOURCES from source-address-filter x.x.x.x/24 orlonger set term BAD_GROUPS from route-filter 224.1.1.0/24 orlonger set term BAD_GROUPS from route-filter 225.1.2.3/32 exact set term BAD_GROUPS from route-filter 239.0.0.0/8 orlonger set term BAD_GROUPS then reject set term ALLOW_OTHER then accept [edit protocols pim rp] set rp-register-policy MULTICAST_REGISTER_POLICY
- RMF Control
- AC-4
- Severity
- L
- CCI
- CCI-001414
- Version
- JUNI-RT-000830
- Vuln IDs
-
- JUNI-RT-000830
- Rule IDs
-
- JUNI-RT-000830_rule
Checks: C-JUNI-RT-000830_chk
Review the RP router configuration to determine if it filters PIM join messages for any reserved multicast groups. Verify that a PIM import statement has been configured as shown in the example below. protocols { … … … } pim { import MULTICAST_JOIN_POLICY; Verify that the join policy has defined both bad multicast groups and sources as shown in the example below. policy-options { … … … } policy-statement MULTICAST_JOIN_POLICY { term BAD_SOURCES { from { source-address-filter x.x.x.x/32 exact; source-address-filter x.x.x.x/24 orlonger; } then reject; } term BAD_GROUPS { from { route-filter 224.1.1.0/24 orlonger; route-filter 225.1.2.3/32 exact; route-filter 239.0.0.0/8 orlonger; … … … route-filter 232.0.0.0/8 orlonger; } then reject; } term ALLOW_OTHER { then accept; } } If 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 and sources, this is a finding.
Fix: F-JUNI-RT-000830_fix
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 and sources. Configure a multicast join policy to filter bad groups and sources as shown in the example below. [edit policy-options policy-statement MULTICAST_JOIN_POLICY] set term BAD_SOURCES from source-address-filter x.x.x.x/32 exact set term BAD_SOURCES from source-address-filter x.x.x.x/24 orlonger set term BAD_GROUPS from route-filter 224.1.1.0/24 orlonger set term BAD_GROUPS from route-filter 225.1.2.3/32 exact set term BAD_GROUPS from route-filter 239.0.0.0/8 orlonger set term BAD_GROUPS then reject set term ALLOW_OTHER then accept Configure PIM to enable the join policy as shown in the example below. [edit protocols pim] set import MULTICAST_JOIN_POLICY
- RMF Control
- SC-5
- Severity
- M
- CCI
- CCI-002385
- Version
- JUNI-RT-000840
- Vuln IDs
-
- JUNI-RT-000840
- Rule IDs
-
- JUNI-RT-000840_rule
Checks: C-JUNI-RT-000840_chk
Review the configuration of the RP to verify that it is rate limiting the number of multicast register messages. protocols { … … … } pim { rp { register-limit maximum nnnnn; local { address 2.2.2.2; } } Note: 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. If the RP is not limiting multicast register messages, this is a finding.
Fix: F-JUNI-RT-000840_fix
Configure the RP to rate limit the number of multicast register messages it will allow for each (S, G) entry. [edit protocols pim rp] set register-limit maximum nnnnn
- RMF Control
- SC-7
- Severity
- L
- CCI
- CCI-002403
- Version
- JUNI-RT-000850
- Vuln IDs
-
- JUNI-RT-000850
- Rule IDs
-
- JUNI-RT-000850_rule
Checks: C-JUNI-RT-000850_chk
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. Verify that a group policy has been configured to filter IGMP join requests as shown in the example below. protocols { igmp { interface ge-1/0/1.0 { group-policy MULTICAST_JOIN_POLICY; } } Verify that the group policy only allows join requests for those groups that have been approved. policy-options { … … … } policy-statement MULTICAST_JOIN_POLICY { … … … } term BAD_GROUPS { from { route-filter 224.1.1.0/24 orlonger; route-filter 225.1.2.3/32 exact; route-filter 239.0.0.0/8 orlonger; … … … route-filter 232.0.0.0/8 orlonger; } then reject; } term ALLOW_APPROVED { then accept; } } If the DR is not filtering IGMP or MLD report messages to only allow joins for approved groups, this is a finding.
Fix: F-JUNI-RT-000850_fix
Configure the DR to filter the IGMP and MLD report messages to allow hosts to join only those multicast groups that have been approved. Configure a multicast join policy to filter groups that have not been approved as shown in the example below. [edit policy-options policy-statement MULTICAST_JOIN_POLICY] set term BAD_GROUPS from route-filter 224.1.1.0/24 orlonger set term BAD_GROUPS from route-filter 225.1.2.3/32 exact set term BAD_GROUPS from route-filter 239.0.0.0/8 orlonger set term BAD_GROUPS then reject set term ALLOW_APPROVED then accept Apply the policy to all interfaces enabled for IGMP. [edit protocols igmp] set interface ge-1/0/1.0 group-policy MULTICAST_JOIN_POLICY
- RMF Control
- SC-7
- Severity
- M
- CCI
- CCI-002403
- Version
- JUNI-RT-000860
- Vuln IDs
-
- JUNI-RT-000860
- Rule IDs
-
- JUNI-RT-000860_rule
Checks: C-JUNI-RT-000860_chk
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. Verify that a group policy has been configured to filter IGMP join requests as shown in the example below. protocols { igmp { interface ge-1/0/1.0 { group-policy MULTICAST_JOIN_POLICY; } } Verify that the policy only allows join requests for those sources that have been approved. policy-options { … … … } policy-statement MULTICAST_JOIN_POLICY { term BAD_SOURCES { from { source-address-filter x.x.x.x/32 exact; source-address-filter x.x.x.x/24 orlonger; } then reject; } … … … } term ALLOW_APPROVED { then accept; } } If the DR is not filtering IGMP or MLD report messages to only allow joins for approved sources, this is a finding.
Fix: F-JUNI-RT-000860_fix
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. Configure a multicast join policy to filter unauthorized multicast sources. [edit policy-options policy-statement MULTICAST_JOIN_POLICY] set term BAD_SOURCES from source-address-filter x.x.x.x/32 exact set term BAD_SOURCES from source-address-filter x.x.x.x/24 orlonger set term BAD_SOURCES then reject set term ALLOW_APPROVED then accept Apply the policy to all interfaces enabled for IGMP. [edit protocols igmp] set interface ge-1/0/1.0 group-policy MULTICAST_JOIN_POLICY
- RMF Control
- SC-5
- Severity
- M
- CCI
- CCI-002385
- Version
- JUNI-RT-000870
- Vuln IDs
-
- JUNI-RT-000870
- Rule IDs
-
- JUNI-RT-000870_rule
Checks: C-JUNI-RT-000870_chk
Review the DR configuration to verify that it is limiting the number of mroute states via IGMP or MLD. protocols { igmp { interface ge-1/0/1.0 { group-limit nnn; } } If the DR is not limiting multicast join requests via IGMP or MLD, this is a finding.
Fix: F-JUNI-RT-000870_fix
Configure the DR on a global or interface basis to limit the number of mroute states resulting from IGMP or MLD membership reports. [edit protocols igmp] set interface ge-1/0/1.0 group-limit nnn
- RMF Control
- SC-5
- Severity
- M
- CCI
- CCI-002385
- Version
- JUNI-RT-000880
- Vuln IDs
-
- JUNI-RT-000880
- Rule IDs
-
- JUNI-RT-000880_rule
Checks: C-JUNI-RT-000880_chk
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. Verify that an infinity policy has been enabled for PIM. protocols { … … … } pim { spt-threshold { infinity SPT_INFINITY; } } } Verify that the infinity policy defines specific multicast groups and sources or all multicast groups and sources as shown in the example below. policy-options { … … … } policy-statement SPT_INFINITY { term ALL_GROUPS { from { route-filter 234.0.0.0/8 orlonger; } then accept; } } } If any multicast router is not configured to set the SPT threshold to infinity to minimalize (S, G) state, this is a finding.
Fix: F-JUNI-RT-000880_fix
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. Configure a policy statement to set SPT threshold to infinity for all multicast groups or only specific groups and sources. [edit policy-options] set policy-statement SPT_INFINITY term ALL_GROUPS from route-filter 234.0.0.0/8 orlonger set policy-statement SPT_INFINITY term ALL_GROUPS then accept Apply the SPT infinity policy [edit protocols pim] set spt-threshold infinity SPT_INFINITY
- RMF Control
- SC-7
- Severity
- M
- CCI
- CCI-002403
- Version
- JUNI-RT-000890
- Vuln IDs
-
- JUNI-RT-000890
- Rule IDs
-
- JUNI-RT-000890_rule
Checks: C-JUNI-RT-000890_chk
Review the router configuration to determine if there is a receive path or interface filter to only accept MSDP packets from known MSDP peers. Verify that the loopback has been configured to filter packets destined to the routing engine as shown in the example below. interfaces { … … … } lo0 { unit 0 { family inet { filter { input PROTECT_RE; } address 2.2.2.2/32; } } } } Verify that the filter is configured to only accept MSDP packets from known MSDP peers as shown in the example below. firewall { family inet { filter PROTECT_RE { term MSDP_PEERS { from { source-address { 0.0.0.0/0; 1.1.1.1/32 except; 5.5.5.5/32 except; } protocol tcp; port msdp; } then { discard; } } term ALLOW_OTHER { then accept; } } } } If the router is not configured to only accept MSDP packets from known MSDP peers, this is a finding.
Fix: F-JUNI-RT-000890_fix
Configure the receive path filter to only accept MSDP packets from known MSDP peers as shown in the following example: [edit firewall family inet filter PROTECT_RE] set term MSDP_PEERS from protocol tcp port msdp set term MSDP_PEERS from source-address 0.0.0.0/0 set term MSDP_PEERS from source-address 1.1.1.1/32 except set term MSDP_PEERS from source-address 5.5.5.5/32 except set term MSDP_PEERS then discard set term ALLOW_OTHER then accept Apply the filter to the loopback interface. [edit interfaces lo0 unit 0 family inet] set filter input PROTECT_RE
- RMF Control
- IA-3
- Severity
- M
- CCI
- CCI-001958
- Version
- JUNI-RT-000900
- Vuln IDs
-
- JUNI-RT-000900
- Rule IDs
-
- JUNI-RT-000900_rule
Checks: C-JUNI-RT-000900_chk
Review the router configuration to determine if received MSDP packets are authenticated. protocols { msdp { group AS25 { peer 5.5.5.5 { authentication-key "$9$KspW87GUH.mTxNfz"; ## SECRET-DATA} } } If the router does not require MSDP authentication, this is a finding.
Fix: F-JUNI-RT-000900_fix
Configure the router to authenticate MSDP messages as shown in the following example: [edit protocols msdp group AS25 peer 5.5.5.5] set authentication-key xxxxxxxx
- RMF Control
- AC-4
- Severity
- L
- CCI
- CCI-001368
- Version
- JUNI-RT-000910
- Vuln IDs
-
- JUNI-RT-000910
- Rule IDs
-
- JUNI-RT-000910_rule
Checks: C-JUNI-RT-000910_chk
Review the router configuration to determine if there is import policy to block source-active multicast advertisements for undesirable multicast groups and sources. policy-options { … … … } policy-statement SA_IMPORT { term BAD_GROUPS { from { route-filter 224.0.1.2/32 exact; route-filter 224.77.0.0/16 orlonger; } then reject; } term BAD_SOURCES { from { source-address-filter x.x.x.x /8 orlonger; source-address-filter x.x.x.x /8 orlonger; then accept; } } Verify that an import source-active filter has been applied to MSDP. protocols { … … … } msdp { import SA_IMPORT; If the router is not configured with an import policy to block undesirable SA multicast advertisements, this is a finding.
Fix: F-JUNI-RT-000910_fix
Configure the MSDP to implement an import policy to block multicast advertisements for undesirable multicast groups and sources. Configure the source-active filter to reject undesirable multicast groups and sources as shown in the example below. [edit policy-options] set policy-statement SA_IMPORT term BAD_GROUPS from route-filter 224.0.1.2/32 exact set policy-statement SA_IMPORT term BAD_GROUPS from route-filter 224.77.0.0/16 orlonger set policy-statement SA_IMPORT term BAD_GROUPS then reject set policy-statement SA_IMPORT term BAD_SOURCES from source-address-filter x.x.x.x/8 orlonger set policy-statement SA_IMPORT term BAD_SOURCES from source-address-filter x.x.x.x/16 orlonger set policy-statement SA_IMPORT term BAD_SOURCES then reject set policy-statement SA_IMPORT term ACCEPT_OTHERS then accept Configure the source-active filter to be an import filter. [edit protocols msdp] set import SA_IMPORT
- RMF Control
- AC-4
- Severity
- L
- CCI
- CCI-001368
- Version
- JUNI-RT-000920
- Vuln IDs
-
- JUNI-RT-000920
- Rule IDs
-
- JUNI-RT-000920_rule
Checks: C-JUNI-RT-000920_chk
Review the router configuration to determine if there is export policy to block local source-active multicast advertisements. Verify that the router is configured with an export policy to filter multicast source-active advertisements. policy-options { … … … } policy-statement SA_EXPORT { term INTERNAL_GROUP { from { route-filter 239.0.0.0/8 orlonger; } then reject; } term INTERNAL_ADDR { from { source-address-filter 10.0.0.0/8 orlonger; } then reject; } term ACCEPT_OTHERS { then accept; } } Verify that an export source-active filter has been applied to MSDP. protocols { … … … } msdp { export SA_IMPORT; If the router is not configured with an export policy to block local source-active multicast advertisements, this is a finding.
Fix: F-JUNI-RT-000920_fix
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. [edit policy-options] set policy-statement SA_EXPORT term INTERNAL_GROUP from route-filter 239.0.0.0/8 orlonger set policy-statement SA_EXPORT term INTERNAL_GROUP then reject set policy-statement SA_EXPORT term INTERNAL_ADDR from source-address-filter 10.0.0.0/8 orlonger set policy-statement SA_EXPORT term INTERNAL_ADDR then reject set policy-statement SA_EXPORT term ACCEPT_OTHERS then accept [edit protocols msdp] set export SA_EXPORT
- RMF Control
- AC-4
- Severity
- L
- CCI
- CCI-001368
- Version
- JUNI-RT-000930
- Vuln IDs
-
- JUNI-RT-000930
- Rule IDs
-
- JUNI-RT-000930_rule
Checks: C-JUNI-RT-000930_chk
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. protocols { … … … } msdp { export SA_EXPORT; import SA_IMPORT; group AS25 { peer x.x.x.x { active-source-limit { maximum nnn; } If the router is not configured to limit the source-active messages it accepts, this is a finding.
Fix: F-JUNI-RT-000930_fix
Configure the router to limit the amount of source-active messages it accepts from each peer. [edit protocols msdp group AS25 peer x.x.x.x] set active-source-limit maximum nnn
- RMF Control
- CM-6
- Severity
- L
- CCI
- CCI-000366
- Version
- JUNI-RT-000940
- Vuln IDs
-
- JUNI-RT-000940
- Rule IDs
-
- JUNI-RT-000940_rule
Checks: C-JUNI-RT-000940_chk
Review the router configuration to verify that a loopback address has been configured. interfaces { … … … lo0 { unit 0 { family inet { address 2.2.2.2/32; } } } } Verify that the loopback interface is used as the source address for all MSDP packets generated by the router. protocols { msdp { group AS25 { peer 5.5.5.5 { local-address 2.2.2.2; } } } If the router does not use its loopback address as the source address when originating MSDP traffic, this is a finding.
Fix: F-JUNI-RT-000940_fix
Configure the router to use its loopback address is used as the source address when sending MSDP packets. [edit protocols msdp] set group AS_5 peer 5.5.5.5 local-address 2.2.2.2