Detections
Analytics

2.5 Ensure firewall filters contain explicit deny and log term

Information

Flood Attack protection should be included in the 'Protect RE' Filter

Rationale:

As with any computer system connected to a network, an attacker may attempt to overwhelm the resources of a Junos device by flooding it with unwanted traffic, consuming resources and potentially resulting in a Denial of Service (or DoS) Attack.

Filtering traffic sources and the available services using a 'Protect RE' filter as discussed elsewhere in this section helps to limit the scope for an attack, but flood attacks using TCP SYN packets, ICMP or other protocols may still be possible.

To prevent this Rate-limiting can be applied to the Firewall Filter by configuring a policer to new terms matching the potential attack traffic.

A full discussion of how Rate-limiting is configured and implemented in Junos, and across different specific chipsets and platforms, is beyond the scope of this Benchmark. The Junos DayOne books Deploying Basic QoS and Hardening Junos Devices, 2nd Edition are available for Free from the Juniper website and provide excellent coverage of QoS/CoS techniques and the application of Rate-limiting to Firewall Filters respectively.

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.
In this example, we will add the new Flood Protection terms seen in the audit procedure to our existing Firewall Filter from Recommendation 2.3 Ensure 'Protect RE' Firewall filter includes Rate-Limiting for Management Services terms using the following commands from the [edit firewall] hierachy:
First we need to create an additional 'policer' definition, which can be re-used in multiple terms of filters.

[edit firewall]
mwhite@SRX1# set if-exceeding bandwidth-limit 100k
mwhite@SRX1# set if-exceeding burst-size-limit 15k
mwhite@SRX1# set then discard

This new policer enforces a bandwidth-limit of 100kb/s, with a burst-size proportional to the configured limit to allow bursts to briefly exceed the limit and smooth the impact of the policer on the service.
The new limit-100k policer is used in the new Limit-SYNFlood term, while the other new terms re-use the limit-1m and limit-10m configured previously. A policer applies separately for each term, so SSH, HTTPS and new terms re-using these policers can receive 10Mb/s of traffic each, not a combined 10Mb/s between them.

[edit firewall]
mwhite@SRX1# set term Limit-SYNFlood from source-prefix-list management-hosts
mwhite@SRX1# set term Limit-SYNFlood from protocol tcp
mwhite@SRX1# set term Limit-SYNFlood from tcp-flags '(syn & !ack) | fin | rst'
mwhite@SRX1# set term Limit-SYNFlood then policer limit-100k
mwhite@SRX1# set term AcceptICMP from icmp-type echo-request
mwhite@SRX1# set term AcceptICMP from icmp-type echo-reply
mwhite@SRX1# set term AcceptICMP from icmp-type unreachable
mwhite@SRX1# set term AcceptICMP from icmp-type time-exceeded
mwhite@SRX1# set term AcceptICMP then policer limit-1m
mwhite@SRX1# set term AcceptICMP then accept
mwhite@SRX1# set term AcceptTCP-Established from source-port ssh
mwhite@SRX1# set term AcceptTCP-Established from tcp-established
mwhite@SRX1# set term AcceptTCP-Established then policer limit-10m
mwhite@SRX1# set term AcceptTCP-Established then accept
mwhite@SRX1# set term AcceptTraceroute from protocol udp
mwhite@SRX1# set term AcceptTraceroute from destination-port 33434-33523
mwhite@SRX1# set term AcceptTraceroute then policer limit-1m
mwhite@SRX1# set term AcceptTraceroute then accept

Because the Limit-SYNFlood term needs to be executed before any TCP Services like SSH, HTTPS or BGP, we will move the term ahead of the AcceptSSH term configured previously:

[edit firewall]
mwhite@SRX1# insert family inet filter CIS-Example-IPv4 term Limit-SYNFlood before term AcceptSSH

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: SYSTEM AND COMMUNICATIONS PROTECTION

References: 800-53|SC-7(12), CSCv7|9.4

Plugin: Juniper

Control ID: c264ff7c9b4dd5c24347a1df4ae5d0b1993ad3db2ed09bcbbd70bde6c5f098f8