Detections
Analytics
2.1 Ensure 'Protect RE' Firewall Filter is set for inbound traffic to the Routing Engine
Information
Traffic to the Routing Engine should be filtered.Rationale:
JUNOS Devices can provide a wide range of services to the network and, 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.
To help protect the Junos Device from attack a Firewall Filter should be applied to all inbound traffic, restricting the services available and the hosts trusted to connect to them. Filtering traffic also removes potential resource usage, processing unwanted traffic or unused services.
On Junos, Transit Traffic (traffic passing through the Junos Device) is processed by the Data Plane (often referred to as the PFE). Traffic destined to the Junos Device itself, such as SSH sessions, SNMP Polling or Routing Protocol updates, is known as Exception Traffic.
Exception Traffic is passed to the Routing Engine, which is represented by the Loopback interface Lo0, for processing. By default traffic received on any interface to an address owned by the Junos Device will be passed to the RE and can connect to a service, such as SSH, if it is running.
By applying a Firewall Filter to inbound traffic on the Loopback interface, we can filter traffic to the RE arriving on any interface (whether a transit interface or a dedicated Out of Band Management Interface like fxp0). This Firewall Filter is commonly referred to as a 'Protect RE' filter and is often named as such, though does not have to be.
Filters should be applied for every address family configured on the Junos Device. For example, a Router configured with both IPv4 (family inet) and IPv6 (family inet6) addresses on any interfaces should have inbound Firewall Filters applied to the Loopback interface for both address families.
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.
At a minimum a Firewall Filter should be applied which restricts management services to trusted hosts, while accepting all other traffic so as not to interfere with normal function of protocol updates and services. This is not a suitable approach in high security environments, where a default discard/deny should be used along with other restrictions covered in separate Level 2 Recommendations in this section.
For devices with multiple Loopback Interface Units configured in different Routing Instances, Logical Systems or similar, Firewall Filters should be applied inbound for all configured Loopback units.
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.
The following example filter allows SSH from the 192.168.1.0/24 network and OSPF from 10.0.0.0/8, while (implicitly) discarding all other traffic (without logging):
firewall {
family inet {
filter ProtectRE {
term AllowOSPF {
from {
protocol ospf;
source-address 10.0.0.0/8;
}
then {
accept;
}
}
term AllowSSH {
from {
protocol tcp;
source-address 192.168.1.0/24;
destination-port ssh;
}
then {
accept;
log;
syslog;
}
}
}
}
}
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.
Default Value:
No firewall filters are configured by default.
See Also
Item Details
Audit Name: CIS Juniper OS Benchmark v2.1.0 L1
Category: SYSTEM AND COMMUNICATIONS PROTECTION
References: 800-53|SC-7, CSCv7|12.4
Plugin: Juniper
Control ID: 052a78a13c634ea5dd5e1bd7f86ea65421ed603a28a8132803aa618d39fb7c6e