Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Example: Configuring a Stateless Firewall Filter to Protect Against TCP and ICMP Floods

This example shows how to create a stateless firewall filter that protects against TCP and ICMP denial-of-service attacks.

Requirements

No special configuration beyond device initialization is required before configuring stateless firewall filters.

Overview

In this example we create a stateless firewall filter called protect-RE to police TCP and ICMP packets. It uses the policers described here:

  • tcp-connection-policer—This policer limits TCP traffic to 1,000,000 bits per second (bps) with a maximum burst size of 15,000 bytes. Traffic exceeding either limit is discarded.

  • icmp-policer—This policer limits ICMP traffic to 1,000,000 bps with a maximum burst size of 15,000 bytes. Traffic exceeding either limit is discarded.

When specifying limits, the bandwidth limit can be from 32,000 bps to 32,000,000,000 bps and the burst-size limit can be from 1,500 bytes through 100,000,000 bytes. Use the following abbreviations when specifying limits: k (1,000), m (1,000,000), and g (1,000,000,000).

Each policer is incorporated into the action of a filter term. This example includes the following terms:

  • tcp-connection-term—Polices certain TCP packets with a source address of 192.168.0.0/24 or 10.0.0.0/24. These addresses are defined in the trusted-addresses prefix list.

    Filtered packets include tcp-established packets The tcp-established match condition is an alias for the bit-field match condition tcp-flags “(ack | rst)”, which indicates an established TCP session, but not the first packet of a TCP connection.

  • icmp-term—Polices ICMP packets. All ICMP packets are counted in the icmp-counter counter.

Note:

You can move terms within the firewall filter by using the insert command. See insert in the Junos OS CLI User Guide.

You can apply a stateless firewall to the input or output sides, or both, of an interface. To filter packets transiting the device, apply the firewall filter to any non-Routing Engine interface. To filter packets originating from, or destined for, the Routing Engine, apply the firewall filter to the loopback (lo0) interface.

Figure 1 shows the sample network.

Figure 1: Firewall Filter to Protect Against TCP and ICMP FloodsFirewall Filter to Protect Against TCP and ICMP Floods

Because this firewall filter limits Routing Engine traffic to TCP packets, routing protocols that use other transport protocols for Layer 4 cannot successfully establish sessions when this filter is active. To demonstrate, this example sets up OSPF between Device R1 and Device R2.

CLI Quick Configuration shows the configuration for all of the devices in Figure 1.

The section #configuration1102__policy-firewall-tcp-icmp-st describes the steps on Device R2.

Configuration

Procedure

CLI Quick Configuration

To quickly configure the stateless firewall filter, copy the following commands to a text file, remove any line breaks, and then paste the commands into the CLI.

Device R1

Device R2

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Use the CLI Editor in Configuration Mode.

To configure stateless firewall filter to discard :

  1. Configure the device interfaces.

  2. Configure the BGP peering session.

  3. Configure the autonomous system (AS) number and router ID.

  4. Configure OSPF.

  5. Define the list of trusted addresses.

  6. Configure a policy to advertise direct routes.

  7. Configure the TCP policer.

  8. Create the ICMP policer.

  9. Configure the TCP filter rules.

  10. Configure the ICMP filter rules.

  11. Apply the filter to the loopback interface.

Results

Confirm your configuration by entering the show interfaces, show protocols, show policy-options, show routing-options, and show firewall commands from configuration mode. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

If you are done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Note:

To verify the TCP policer, you can use a packet generation tool. This task is not shown here.

Displaying Stateless Firewall Filter That Are in Effect

Purpose

Verify the configuration of the firewall filter.

Action

From operational mode, enter the show firewall command.

Meaning

The output shows the filter, the counter, and the policers that are in effect on Device R2.

Using telnet to Verify the tcp-established Condition in the TCP Firewall Filter

Purpose

Make sure that telnet traffic works as expected.

Action

Verify that the device can establish only TCP sessions with hosts that meet the from tcp-established condition.

  1. From Device R2, make sure that the BGP session with Device R1 is established.

  2. From Device R2, telnet to Device R1.

  3. From Device R1, telnet to Device R2.

  4. On Device R2, deactivate the from tcp-established match condition.

  5. From Device R1, try again to telnet to Device R2.

Meaning

Verify the following information:

  • As expected , the BGP session is established. The from tcp-established match condition is not expected to block BGP session establishment.

  • From Device R2, you can telnet to Device R1. Device R1 has no firewall filter configured, so this is the expected behavior.

  • From Device R1, you cannot telnet to Device R2. Telnet uses TCP as the transport protocol, so this result might be surprising. The cause for the lack of telnet connectivity is the from tcp-established match condition. This match condition limits the type of TCP traffic that is accepted of Device R2. After this match condition is deactivated, the telnet session is successful.

Using telnet to Verify the Trusted Prefixes Condition in the TCP Firewall Filter

Purpose

Make sure that telnet traffic works as expected.

Action

Verify that the device can establish only telnet sessions with a host at an IP address that matches one of the trusted source addresses. For example, log in to the device with the telnet command from another host with one of the trusted address prefixes. Also, verify that telnet sessions with untrusted source addresses are blocked.

  1. From Device R1, telnet to Device R2 from an untrusted source address.

  2. From Device R2, add 172.16/16 to the list of trusted prefixes.

  3. From Device R1, try again to telnet to Device R2.

Meaning

Verify the following information:

  • From Device R1, you cannot telnet to Device R2 with an unstrusted source address. After the 172.16/16 prefix is added to the list of trusted prefixes, the telnet request from source address 172.16.0.1 is accepted.

  • OSPF session establishment is blocked. OSPF does not use TCP as its transport protocol. After the from protocol tcp match condition is deactivated, OSPF session establishment is not blocked.

Using OSPF to Verify the TCP Firewall Filter

Purpose

Make sure that OSPF traffic works as expected.

Action

Verify that the device cannot establish OSPF connectivity.

  1. From Device R1, check the OSPF sessions.

  2. From Device R2, check the OSPF sessions.

  3. From Device R2, remove the from protocol tcp match condition.

  4. From Device R1, recheck the OSPF sessions.

  5. From Device R2, recheck the OSPF sessions.

Meaning

Verify the following information:

  • OSPF session establishment is blocked. OSPF does not use TCP as its transport protocol. After the from protocol tcp match condition is deactivated, OSPF session establishment is successful.

Verifying the ICMP Firewall Filter

Purpose

Verify that ICMP packets are being policed and counted. Also make sure that ping requests are discarded when the requests originate from an untrusted source address.

Action

  1. Undo the configuration changes made in previous verification steps.

    Reactivate the TCP firewall settings, and delete the 172.16/16 trusted source address.

  2. From Device R1, ping the loopback interface on Device R2.

  3. From Device R2, check the firewall statistics.

  4. From an untrusted source address on Device R1, send a ping request to Device R2’s loopback interface.

Meaning

Verify the following information:

  • The ping output shows that 10% packet loss is occurring.

  • The ICMP packet counter is incrementing, and the icmp-policer is incrementing.

  • Device R2 does not send ICMP responses to the ping 172.16.0.2 source 172.16.0.1 command.