Rate and give feedback:  Feedback Received. Thank You!

Rate and give feedback: 

X

This document helped resolve my issue

Yes No

Additional Comments

800 characters remaining

May we contact you if necessary?

Name:  

E-mail: 

Enter a valid Email ID

Need product assistance? Contact Juniper Support

Submit

This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply.

English  

English

Filter-Specific Counters and Policers

Filter-Specific Policer Overview

By default, a policer operates in term-specific mode so that, for a given firewall filter, the Junos OS creates a separate policer instance for every filter term that references the policer. As an option, you can configure a policer to operate in filter-specific mode so that a single policer instance is used by all terms (within the same firewall filter) that reference the policer.

For an IPv4 firewall filter with multiple terms that reference the same policer, configuring the policer to operate in filter-specific mode enables you to count and monitor the activity of the policer at the firewall filter level.

Note: Term-specific mode and filter-specific mode also apply to prefix-specific policer sets.

• [edit firewall policer policer-name]
• [edit logical-systems logical-system-name firewall policer policer-name]

You can reference filter-specific policers from IPv4 (family inet) firewall filters only.

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
• Overview
• Configuration
• Verification

Requirements

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

Overview

• tcp-connection-policer—Limits the traffic rate of the TCP packets to 500,000 bps and the burst size to 15,000 bytes. Packets that exceed the traffic rate are discarded.
• icmp-policer—Limits the traffic rate of the ICMP packets to 1,000,000 bps and the burst size to 15,000 bytes. Packets that exceed the traffic rate are 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).

• 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 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 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 Step-by-Step Procedure describes the steps on Device R2.

Configuration

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.

Step-by-Step Procedure

1. Configure the device interfaces.

   [edit interfaces fe-1/2/0 unit 0 family inet ]user@R2# set address 10.0.0.2/30
   [edit interfaces lo0 unit 0 family inet]user@R2# set address 192.168.0.2/32 primaryuser@R2# set address 172.16.0.2/32

2. Configure the BGP peering session.

   [edit protocols bgp group ext]user@R2# set type externaluser@R2# set export send-directuser@R2# set neighbor 10.0.0.1 peer-as 100
3. Configure the autonomous system (AS) number and router ID.
   [edit routing-options]user@R2# set autonomous-system 200user@R2# set router-id 192.168.0.2
4. Configure OSPF.
   [edit protocols ospf area 0.0.0.0]user@R2# set interface lo0.0 passiveuser@R2# set interface fe-1/2/0.0

5. Define the list of trusted addresses.

   [edit policy-options prefix-list trusted-addresses]user@R2# set 10.0.0.0/24user@R2# set 192.168.0.0/24

6. Configure a policy to advertise direct routes.

   [edit policy-options policy-statement send-direct term 1]user@R2# set from protocol directuser@R2# set then accept

7. Configure the TCP policer.

   [edit firewall policer tcp-connection-policer]user@R2# set filter-specificuser@R2# set if-exceeding bandwidth-limit 1muser@R2# set if-exceeding burst-size-limit 15kuser@R2# set then discard

8. Create the ICMP policer.

   [edit firewall policer icmp-policer]user@R2# set filter-specificuser@R2# set if-exceeding bandwidth-limit 1muser@R2# set if-exceeding burst-size-limit 15kuser@R2# set then discard

9. Configure the TCP filter rules.

   [edit firewall family inet filter protect-RE term tcp-connection-term]user@R2# set from source-prefix-list trusted-addressesuser@R2# set from protocol tcpuser@R2# set from tcp-establisheduser@R2# set then policer tcp-connection-policeruser@R2# set then accept

10. Configure the ICMP filter rules.

    [edit firewall family inet filter protect-RE term icmp-term]user@R2# set from source-prefix-list trusted-addressesuser@R2# set from protocol icmpuser@R2# set then policer icmp-policeruser@R2# set then count icmp-counteruser@R2# set then accept
11. Apply the filter to the loopback interface.
    [edit interfaces lo0 unit 0]user@R2# set family inet filter input protect-RE

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
• Using telnet to Verify the tcp-established Condition in the TCP Firewall Filter
• Using telnet to Verify the Trusted Prefixes Condition in the TCP Firewall Filter
• Using OSPF to Verify the TCP Firewall Filter
• Verifying the ICMP Firewall Filter

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.

Filter: protect-RE                                        
Counters:
Name                                                Bytes              Packets
icmp-counter                                            0                    0
Policers:
Name                                                Bytes              Packets
icmp-policer                                                            0
tcp-connection-policer                                                  0

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.
   user@R2> show bgp summary | match down

   Groups: 1 Peers: 1 Down peers: 0
   

2. From Device R2, telnet to Device R1.
   user@R2> telnet 192.168.0.1

   Trying 192.168.0.1...
   Connected to R1.acme.net.
   Escape character is '^]'.
   
   R1 (ttyp4)
   
   login: 

3. From Device R1, telnet to Device R2.
   user@R1> telnet 192.168.0.2

   Trying 192.168.0.2...
   telnet: connect to address 192.168.0.2: Operation timed out
   telnet: Unable to connect to remote host

4. On Device R2, deactivate the from tcp-established match condition.
   [edit firewall family inet filter protect-RE term tcp-connection-term]user@R2# deactivate from tcp-established user@R2# commit
5. From Device R1, try again to telnet to Device R2.
   user@R1> telnet 192.168.0.1

   Trying 192.168.0.2...
   Connected to R2.acme.net.
   Escape character is '^]'.
   
   R2 (ttyp4)
   
   login: 

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.
   user@R1> telnet 172.16.0.2 source 172.16.0.1

   Trying 172.16.0.2...
   ^C

2. From Device R2, add 172.16/16 to the list of trusted prefixes.
   [edit policy-options prefix-list trusted-addresses]user@R2# set 172.16.0.0/16 user@R2# commit
3. From Device R1, try again to telnet to Device R2.
   user@R1> telnet 172.16.0.2 source 172.16.0.1

   Trying 172.16.0.2...
   Connected to R2.acme.net.
   Escape character is '^]'.
   
   R2 (ttyp4)
   
   login: 

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.
   user@R1> show ospf neighbor

   Address          Interface              State     ID               Pri  Dead
   10.0.0.2         fe-1/2/0.0             Init      192.168.0.2      128    34

2. From Device R2, check the OSPF sessions.
   user@R2> show ospf neighbor

3. From Device R2, remove the from protocol tcp match condition.
   [edit firewall family inet filter protect-RE term tcp-connection-term]user@R2# deactivate from protocoluser@R2# commit
4. From Device R1, recheck the OSPF sessions.
   user@R1> show ospf neighbor

   Address          Interface              State     ID               Pri  Dead
   10.0.0.2         fe-1/2/0.0             Full      192.168.0.2      128    36
   

5. From Device R2, recheck the OSPF sessions.
   user@R2> show ospf neighbor

   Address          Interface              State     ID               Pri  Dead
   10.0.0.1         fe-1/2/0.0             Full      192.168.0.1      128    39

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.

   [edit firewall family inet filter protect-RE term tcp-connection-term]user@R2# activate from protocol user@R2# activate from tcp-established
   [edit policy-options prefix-list trusted-addresses]user@R2# delete 172.16.0.0/16
   user@R2# commit
2. From Device R1, ping the loopback interface on Device R2.
   user@R1> ping 192.168.0.2 rapid count 600 size 2000

   PING 192.168.0.2 (192.168.0.2): 2000 data bytes
   !!!!!!!!.!!!!!!!!.!!!!!!!!!.!!!!!!!!.!!!!!!!!!.!!!!!!!!.!!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!!.!!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!!.!!!!!!!!.!!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!!.!!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!!.!!!!!!!!.!!!!!!!!.!!!!!!!!
   --- 192.168.0.2 ping statistics ---
   600 packets transmitted, 536 packets received, 10% packet loss
   pinground-trip min/avg/max/stddev = 2.976/3.405/42.380/2.293 ms
   

3. From Device R2, check the firewall statistics.
   user@R2> show firewall

   Filter: protect-RE                                        
   Counters:
   Name                                                Bytes              Packets
   icmp-counter                                      1180804                 1135
   Policers:
   Name                                                Bytes              Packets
   icmp-policer                                                           66
   tcp-connection-policer                                                  0
   

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

   PING 172.16.0.2 (172.16.0.2): 56 data bytes
   ^C
   --- 172.16.0.2 ping statistics ---
   14 packets transmitted, 0 packets received, 100% packet loss
   

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.