STIGViewer Support

The Juniper router must be configured to only permit management traffic that ingresses and egresses the OOBM interface.

Overview

Finding IDVersionRule IDIA ControlsSeverity
V-217049JUNI-RT-000440SV-217049r604135_ruleCCI-001097medium
Description
The OOBM access switch will connect to the management interface of the managed network elements. The management interface can be a true OOBM interface or a standard interface functioning as the management interface. In either case, the management interface of the managed network element will be directly connected to the OOBM network. An OOBM interface does not forward transit traffic, thereby providing complete separation of production and management traffic. Since all management traffic is immediately forwarded into the management network, it is not exposed to possible tampering. The separation also ensures that congestion or failures in the managed network do not affect the management of the device. If the device does not have an OOBM port, the interface functioning as the management interface must be configured so that management traffic does not leak into the managed network and that production traffic does not leak into the management network.
STIGDate
Juniper Router RTR Security Technical Implementation Guide2024-12-05

Related Frameworks

1 mapping across 5 frameworks
SCF0 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (18) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

CFG-02Secure Baseline Configurations
1.00
CRY-01Use of Cryptographic Controls
1.00
CRY-01.1Alternate Physical Protection
1.00
CRY-03Transmission Confidentiality
1.00
CRY-04Transmission Integrity
1.00
CRY-05Encrypting Data At Rest
1.00
DCH-01Data Protection
1.00
IAC-21Least Privilege
1.00
MON-01Continuous Monitoring
1.00
MON-01.1Intrusion Detection & Prevention Systems (IDS & IPS)
1.00

+8 more (top 10 by confidence shown)

NIST 800-530 mappings

No source states a mapping between these directly.

Also reachable in 2 hops (10) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

CM-6Configuration Settings
1.00
SC-24Fail in Known State
1.00
SC-47Alternate Communications Paths
1.00
SC-5Denial-of-service Protection
1.00
SC-7Boundary Protection
1.00
SC-7(11)Restrict Incoming Communications Traffic
1.00
SC-7(29)Separate Subnets to Isolate Functions
1.00
SC-7(5)Deny by Default — Allow by Exception
1.00
SI-4System Monitoring
1.00
SI-4(11)Analyze Communications Traffic Anomalies
1.00
NIST 800-1710 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (3) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

3.13.1
1.00
3.13.2
1.00
3.13.5
1.00
CCI1 mapping
NIST CSF 2.00 mappings

No source states a mapping between these directly.

Also reachable in 3 hops (5) derived by us, not asserted by any source

Each of these is a route we composed by chaining published mappings. No publisher states a relationship between the two endpoints.

Who does this work

15 NICE work roles and 9 EC-Council certifications.

This is an inference across published mappings, not a single claim by anyone. This check maps to a control, which maps to a Cybersecurity Framework outcome, which NIST assigns to the work roles below. EC-Council separately maps its certifications to those same roles.

A certification prepares someone for a role. It is not evidence that a holder is qualified, and neither NIST nor EC-Council has stated that any certification here addresses this check.

Work-role assignments published by NIST (NICE Framework Components 2.2.0 and the CSF 2.0 OLIR crosswalk). Certification mappings published by EC-Council.

Details

Check Text (C-217049r604135_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 and ICMP traffic. firewall { family inet { … … … filter OOBM_INBOUND { 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 and ICMP traffic. firewall { family inet { … … … filter OOBM_OUTBOUND { 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 Text (F-18276r297016_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_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_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