Detections
Analytics

2.2 Ensure 'Protect RE' Firewall Filter includes explicit terms for all Management Services

Information

The Firewall Filter used to protect the Junos Device should include explicit terms for all Management, Automation and Monitoring Services used

Rationale:

Junos supports a wide range of Management, Monitoring and Automation Services, making it an extremely flexible and adaptable platform. However, as with any computer system, the more services that are offered and the more hosts to which they are available, the wider attack surface is offered to a potential attacker.

Because Management Services provide users the ability to remotely configure, monitor or otherwise control the Junos Device, it is important to restrict access to just trusted hosts for each individual service.

Examples of Junos Management Services include (but are not limited to):

Telnet (which should not be used, as described elsewhere)

SSH (a secure alternative to Telnet)

JWeb GUI (a web based interface over HTTP or HTTPS)

SNMP (Simple Network Management Protocol, typically used for monitoring)

NETCONF (an XML-RPC based automation standard)

gRPC (a Remote Procedure Call based automation interface)

REST API (an HTTP/S based automation interface)

DMI (Device Management Interface - used by Network Management Systems, including Junos Space)

Unused services should ideally not be running at all - for example, if you do not use the JWeb GUI to manage your device, the service should be disabled under the [edit system services] configuration hierarchy as described elsewhere in this Benchmark.

Service's which are in use to manage your network should be appropriately secured using recommendations elsewhere in this Benchmark and have access restricted to trusted hosts for that service, using explicit terms in the 'Protect RE' Firewall Filter discussed in Recommendation 2.1 Ensure 'Protect RE' Firewall Filter is set for inbound traffic to the Routing Engine.

A full discussion of Firewall Filter design and evaluation is beyond the scope of this Benchmark, but is covered in more detail in Chapter 4 of the Juniper DayOne book Hardening Junos Devices 2nd Edition, available for free from the Juniper DayOne Tech Libary.

Impact:

Firewall Filters should be carefully tested before implementation on production systems as incorrect configuration may prevent normal services functioning.

It is strongly recommended that changes to Firewall Filters are applied using commit confirmed so that changes will be automatically rolled back should they prevent the administrator from connecting to the Junos Device.

NOTE: Nessus has provided the target output to assist in reviewing the benchmark to ensure target compliance.

Solution

A full discussion of Firewall Filters is beyond the scope of this Benchmark.
It is important to ensure that Firewall Filters include terms to match and accept all of your required Routing Protocols, Management Services and any other services used on your Junos Device. As noted elsewhere, it is strongly recommended that changes to Firewall Filters applied to the Loopback interface always be applied using commit confirmed so that the change will be automatically rolled back should the administrator lose connection after committing the change.
To create a IPv4 firewall filter enter the following command from the [edit firewall] hierarchy.

[edit firewall]
user@host#edit family inet
[edit firewall family inet]
user@host#edit filter <filter name>
[edit firewall family inet filter <filter name>]
user@host#edit term <term name>
[edit firewall family inet filter <filter name> term <term name>]
user@host#set from <match conditions>
user@host#set then <action>

An IPv6 firewall filter, if required, can be configured under the family inet6 from the same hierarchy.
Once a suitable filter has been configured, it must be applied to the Loopback interface, using the following command from the [edit] hierarchy:

[edit]
user@host#set interface lo0 unit 0 family inet filter input <filter name>

If additional Loopback Interface Units are configured (in other Routing Instances), the filter should also be applied to these.
If IPv6 filters are also required, the same command is used but applying to family inet6.
To configure the CIS-Example-IPv4 shown previously in the Audit Procedure, we opted to first configure a prefix-list each for our management-hosts and snmp-servers using the following commands from the [edit policy-options] heirachy:

[edit policy-options]
mwhite@SRX1# set prefix-list management-hosts 172.16.10.0/24
mwhite@SRX1# set prefix-list management-hosts 192.168.17.0/24
mwhite@SRX1# set prefix-list snmp-servers apply-path 'snmp community <*> clients <*>'

The management-hosts prefix-list is a manual list of IP subnets which can be used in multiple policies or terms. If we add or remote IPs on the list, it will cause all of the terms to be updated, rather than having to manually update our management hosts in multiple locations.
The snmp-servers prefix-list used an apply-path to return all configured SNMP Clients (the Network Management Servers (NMS) which will be permitted to poll this Junos Device using Simple Network Management Protocol) from elsewhere in the configuration. The same technique can be used to create a list of all configured NTP Servers, BGP Peers and so on. Lists created using an apply-path will automatically update when the source does, so if we add a new SNMP Client, the prefix-list updated automatically.
We then created an IPv4 firewall filter from the [edit firewall] hierarchy:

[edit firewall]
mwhite@SRX1# set family inet filter CIS-Example-IPv4 term AccpetSSH from source-prefix-list management-hosts
mwhite@SRX1# set family inet filter CIS-Example-IPv4 term AccpetSSH from destination-port ssh
mwhite@SRX1# set family inet filter CIS-Example-IPv4 term AccpetSSH then count SSH-Allowed
mwhite@SRX1# set family inet filter CIS-Example-IPv4 term AccpetSSH then log
mwhite@SRX1# set family inet filter CIS-Example-IPv4 term AccpetSSH then syslog
mwhite@SRX1# set family inet filter CIS-Example-IPv4 term AccpetSSH then accept
mwhite@SRX1# set family inet filter CIS-Example-IPv4 term AcceptHTTPS from source-prefix-list management-hosts
mwhite@SRX1# set family inet filter CIS-Example-IPv4 term AcceptHTTPS from destination-port https
mwhite@SRX1# set family inet filter CIS-Example-IPv4 term AcceptHTTPS then count HTTPS-Allowed
mwhite@SRX1# set family inet filter CIS-Example-IPv4 term AcceptHTTPS then log
mwhite@SRX1# set family inet filter CIS-Example-IPv4 term AcceptHTTPS then syslog
mwhite@SRX1# set family inet filter CIS-Example-IPv4 term AcceptHTTPS then accept
mwhite@SRX1# set family inet filter CIS-Example-IPv4 term AcceptSNMP from source-prefix-list snmp-servers
mwhite@SRX1# set family inet filter CIS-Example-IPv4 term AcceptSNMP from destination-port snmp
mwhite@SRX1# set family inet filter CIS-Example-IPv4 term AcceptSNMP then count SNMP-Poll-Allowed
mwhite@SRX1# set family inet filter CIS-Example-IPv4 term AcceptSNMP then accept

The first two terms AcceptSSH and AcceptHTTPS accept SSH and HTTPS traffic respectively from any host listed in the the management-hosts prefix-list. Traffic matching these terms is also logged and separate counters incremented each time the term is hit.
Term 3, AcceptSNMP accepts SNMP Polling from SNMP Clients (SNMP Servers) which were automatically added to the snmp-servers prefix-list. As polling could be frequent, no logging is used, but a counter is incremented.
The filter can now be applied to the Loopback interface, using the following command from the [edit interfaces] hierarchy:

[edit interfaces]
mwhite@SRX1# set unit 0 family inet filter input CIS-Example-IPv4

Note - The example filter above not complete and may not be suitable for all environments - all other traffic to the Junos Device will be discarded.
Your filters should include terms for all of the Management, Monitoring and Automation services, as well as any Routing Protocols or other services such as IPSEC or BFD in use in your network.

Default Value:

No firewall filters are configured by default.

See Also

https://workbench.cisecurity.org/files/3069

Item Details

Category: CONFIGURATION MANAGEMENT, SYSTEM AND COMMUNICATIONS PROTECTION

References: 800-53|CM-7b., 800-53|SC-7(12), CSCv7|9, CSCv7|9.4

Plugin: Juniper

Control ID: 7d2ff044d13d23573eb4914ec6b35db1b5a2055aa26d6f37374bd1c936c3ce9f