STIGQter STIGQter: STIG Summary: Infrastructure Router Security Technical Implementation Guide Juniper Version: 8 Release: 29 Benchmark Date: 25 Jan 2019: Traffic entering the tunnels is not restricted to only the authorized management packets based on destination address.

DISA Rule

SV-19311r1_rule

Vulnerability Number

V-17835

Group Title

IPSec traffic is not restricted

Rule Version

NET1006

Severity

CAT II

CCI(s)

Weight

10

Fix Recommendation

Where IPSec technology is deployed to connect the managed network to the NOC, it is imperative that the traffic entering the tunnels is restricted to only the authorized management packets based on destination address.

Check Contents

Verify that all traffic from the managed network to the management network and vice-versa is secured via IPSec encapsulation. In the configuration examples, 10.2.2.0/24 is the management network at the NOC and 192.168.1.0/24 is address space used at the network being managed (i.e., the enclave). Example from a show services command with Juniper M or T series router with Adaptive Services PIC using next-hop style is as follows:

service-set vpn-to-NOC {
next-hop-service {
inside-service-interface sp-0/0/0.1;
outside-service-interface sp-0/0/0.2;
}
ipsec-vpn-options {
local-gateway 19.16.1.1;
}
ipsec-vpn-rules site-to-NOC;
}
ipsec-vpn {
rule site-to-NOC {
term mgmt-traffic {
}
destination-address {
10.2.2.0/24;
}
}
then
remote-gateway 19.16.2.1;
dynamic {
ike-policy main_mode_ike_policy;
ipsec-policy dynamic_ipsec_policy;
}
}
}
match-direction input;
}
ipsec {
proposal esp_sha1_ipsec_prop {
protocol esp;
authentication-algorithm hmac-sha1-96;
encryption-algorithm 3des-cbc;
}
policy dynamic_ipsec_policy {
perfect-forward-secrecy {
keys group2;
}
proposals esp_sha1_ipsec_prop;
}
}
ike {
proposal psk_sha1_3des_ike_prop {
authentication-method pre-shared-keys;
authentication-algorithm sha1;
encryption-algorithm 3des-cbc;
}
policy main_mode_ike_policy {
mode main;
proposals psk_sha1_3des_ike_prop;
pre-shared-key ascii-text “$7#$AAtBRmNOjH”; ##SECRET-DATA
}
}
}

Note: Juniper recommends implementing all Layer 3 services with the next-hop-style service set as opposed to the interface-style. When you configure next-hop-style service sets, you associate them with specific inside and outside logical interfaces. These logical interfaces are units you configure on an AS PIC’s sp- interface as illustrated below:

interfaces {
sp-0/0/0 {
unit 0 {
family inet;
}
unit 1 {
description "IPSec Tunnel Inside Service Interface";
family inet;
service-domain inside;
}
unit 2 {
description "IPSec Tunnel Outside Service Interface";
family inet;
service-domain outside;
}
}


}

The router must be configured to match the traffic that is to be secured in the outbound direction. For next-hop service sets, this is the input direction as configured via match-direction input command as shown above under the services ipsec-vpn hierarchy. You configure the router to route traffic to the inside or outside interface as shown in the following example:

routing-options {
static {
route 10.2.2.0/24 next-hop sp-0/0/0.1;
}
}

Vulnerability Number

V-17835

Documentable

False

Rule Version

NET1006

Severity Override Guidance

Verify that all traffic from the managed network to the management network and vice-versa is secured via IPSec encapsulation. In the configuration examples, 10.2.2.0/24 is the management network at the NOC and 192.168.1.0/24 is address space used at the network being managed (i.e., the enclave). Example from a show services command with Juniper M or T series router with Adaptive Services PIC using next-hop style is as follows:

service-set vpn-to-NOC {
next-hop-service {
inside-service-interface sp-0/0/0.1;
outside-service-interface sp-0/0/0.2;
}
ipsec-vpn-options {
local-gateway 19.16.1.1;
}
ipsec-vpn-rules site-to-NOC;
}
ipsec-vpn {
rule site-to-NOC {
term mgmt-traffic {
}
destination-address {
10.2.2.0/24;
}
}
then
remote-gateway 19.16.2.1;
dynamic {
ike-policy main_mode_ike_policy;
ipsec-policy dynamic_ipsec_policy;
}
}
}
match-direction input;
}
ipsec {
proposal esp_sha1_ipsec_prop {
protocol esp;
authentication-algorithm hmac-sha1-96;
encryption-algorithm 3des-cbc;
}
policy dynamic_ipsec_policy {
perfect-forward-secrecy {
keys group2;
}
proposals esp_sha1_ipsec_prop;
}
}
ike {
proposal psk_sha1_3des_ike_prop {
authentication-method pre-shared-keys;
authentication-algorithm sha1;
encryption-algorithm 3des-cbc;
}
policy main_mode_ike_policy {
mode main;
proposals psk_sha1_3des_ike_prop;
pre-shared-key ascii-text “$7#$AAtBRmNOjH”; ##SECRET-DATA
}
}
}

Note: Juniper recommends implementing all Layer 3 services with the next-hop-style service set as opposed to the interface-style. When you configure next-hop-style service sets, you associate them with specific inside and outside logical interfaces. These logical interfaces are units you configure on an AS PIC’s sp- interface as illustrated below:

interfaces {
sp-0/0/0 {
unit 0 {
family inet;
}
unit 1 {
description "IPSec Tunnel Inside Service Interface";
family inet;
service-domain inside;
}
unit 2 {
description "IPSec Tunnel Outside Service Interface";
family inet;
service-domain outside;
}
}


}

The router must be configured to match the traffic that is to be secured in the outbound direction. For next-hop service sets, this is the input direction as configured via match-direction input command as shown above under the services ipsec-vpn hierarchy. You configure the router to route traffic to the inside or outside interface as shown in the following example:

routing-options {
static {
route 10.2.2.0/24 next-hop sp-0/0/0.1;
}
}

Check Content Reference

M

Responsibility

Information Assurance Officer

Target Key

510

Comments