Detections
Analytics

2.4 Ensure 'Protect RE' Firewall Filter includes explicit terms for all Protocols

Information

Routing and Switching Protocol traffic should be filtered

Rationale:

Junos devices support a vast range of Routing Protocols to enable flexible services to be deployed. 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.

In addition, an attacker may seek to connect to Routing Protocols in an attempt to gain knowledge of the network, re-route traffic to perform Man in the Middle (MITM) attacks or disrupt the network to perform a Denial of Service (DoS) attack.

Limiting the devices able to connect to these sensitive protocols, on a per protocol basis, greatly enhances the security of the device. These protocols might include (but are not limited to):

OSPF

IS-IS

BGP

RIP

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.
In the example below, we add a new term AcceptBGP to the CIS-Example-IPv4 shown previously in the Audit Procedure. We opted to first configure a prefix-list each for our bgp-neighbors using the following command from the [edit policy-options] hierarchy:

[edit policy-options]
mwhite@SRX1# set prefix-list bgp-neighbors apply-path 'protocols bgp group <*> neighbor <*>'

The bgp-neighbors prefix-list used an apply-path to return all configured BGP Neighbors configured for any group under the [edit protocols bgp] configuration. The same technique can be used to create a list of all configured NTP Servers, SNMP Servers and so on. Lists created using an apply-path will automatically update when the source configuration does, so if we add a new BGP Neighbor, the prefix-list is updated automatically.
NOTE - If you are running protocols in multiple Routing Instances, Logical Systems or similar features, you may need to adjust your prefix-list and apply-path to reflect these additional locations.
We can then add a new term to the existing CIS-Example-IPv4 firewall filter with the following commands from the [edit firewall] hierarchy:

[edit firewall]
mwhite@SRX1# set family inet filter CIS-Example-IPv4 term AccpetBGPfrom source-prefix-list bgp-neighbors
mwhite@SRX1# set family inet filter CIS-Example-IPv4 term AccpetBGP from protocol tcp
mwhite@SRX1# set family inet filter CIS-Example-IPv4 term AccpetBGP from destination-port bgp
mwhite@SRX1# set family inet filter CIS-Example-IPv4 term AccpetBGP then count BGP-Allowed
mwhite@SRX1# set family inet filter CIS-Example-IPv4 term AcceptBGP then accept

This filter matches traffic coming from any configured BGP Neighbor to TCP Port 179 and accepts it, incrementing a named counter BGP-Allowed, which helps us with troubleshooting and monitoring.
If it is not already, 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: 5fa28acc890e0b150853aa5ebd42aa30b35372ec0f2a47141529c61984fa102e