Configuring Firewall Filters

To configure firewall filters, include the following statements:

 [edit] firewall {   policer  policer-name  {     if-exceeding {       bandwidth-limit  rate;  burst-size-limit  bytes;  }     then {  policer-action  ;     }   }   filter  filter-name  {     accounting-profile  name;  interface-specific;     policer  policer-name  {       if-exceeding {         bandwidth-limit  rate;  burst-size-limit  bytes;  }       then {  policer-action  ;       }     }     term  term-name  {       from {  match-conditions  ;       }       then {  actions  ;  action-modifiers  ;       }     }   } } interfaces {  interface-name  {     unit  logical-unit-number  {       family inet {         filter {           input  filter-name  ;           output  filter-name  ;         }       }     }   } } 

Policing does not use the filter match conditions. Instead, it uses the if-exceeding statement. For more information, see the JUNOS technical documentation: Routing Policy.

Firewall filter terms are evaluated in the order in which you specify them in the configuration. To reorder terms, use the configuration mode insert command. For example, the command insert term up before term start places the term up before the term start .

In the then statement of a firewall filter term, you specify the action to take if the packet matches the conditions in the from statement (see Table 8.16 and Table 8.17).

Table 8.16. Firewall Filter Actions

Action	Description
accept	Accept a packet. This is the default.
discard	Discard a packet silently, without sending an ICMP message. Discarded packets are not available for logging or sampling.
reject <message-type>	Discard a packet, sending an ICMP destination unreachable message. Rejected packets can be logged or sampled if you configure either of those action modifiers. You can specify one of the following message codes: administratively- prohibited (default), bad-host-tos , bad-network-tos , host-prohibited , host-unknown , host-unreachable , network-prohibited , network-unknown , network-unreachable , port-unreachable , precedence-cutoff , precedence-violation , protocol-unreachable , source-host-isolated , source-route-failed , or tcp-reset . If you specify tcp-reset , a TCP reset is returned if the packet is a TCP packet. Otherwise, nothing is returned.
routing-instance routing-instance	Specify a routing table to which packets are forwarded.

Table 8.17. Firewall Filter Action Modifiers

Action Modifier	Description
count counter-name	Increment a counter for this filter. The name can contain letters , numbers , and hyphens (-), and can be up to 24 characters long. A counter name is specific to the filter that uses it, so all interfaces that use the same filter count into the same counter.
forwarding-class class-name	Specify a particular forwarding class.
ipsec-sa sa-name	Specify an IPSec security association for the packet. Used with the source-address and destination-address match conditions.
log	Log the packet's header information in the Routing Engine. You can access this information from the CLI, but it is not available from network management.
loss-priority priority	Set the packet loss priority (PLP) to any , low , or high .
policer policer-name	Apply rate limits to the traffic using the named policer.
sample	Sample the traffic on the interface. Use this modifier only when traffic sampling is enabled.
syslog	Log an alert for this packet. The log can be sent to a server for storage and analysis.

When a firewall filter consists of a single term, the filter is evaluated as follows :

• If the packet matches all the conditions, the action in the then statement is taken.

• If the packet does not match all the conditions, it is discarded.

When a firewall filter consists of more than one term, the filter is evaluated sequentially:

• The packet is evaluated against the conditions in the from statement in the first term.

• If the packet matches, the action in the then statement is taken and the evaluation ends. Subsequent terms in the firewall filter are not evaluated.

• If the packet does not match, it is evaluated against the conditions in the from statement in the second term.

  This process continues until either the packet matches the from conditions in one of the subsequent terms or there are no more terms.

• If a packet passes through all the terms in the filter without matching any of them, it is discarded.

If a term does not contain a from statement, the packet is considered to match and the action in the term's then statement is taken. If a term does not contain a then statement or if you do not configure an action in the then statement, and if the packet matches the conditions in the term's from statement, the packet is accepted.

Each firewall filter has an implicit discard action at the end of the filter, which is equivalent to the following explicit filter term. Therefore, if a packet matches none of the terms in the filter, it is discarded.

 term implicit-rule {   then discard; } 

In the from statement in the firewall filter term, specify conditions that the packet must match for the action in the then statement to be taken. All conditions in the from statement must match for the action to be taken. The order in which you specify match conditions is not important, because a packet must match all conditions in a term.

If you specify no match conditions in a term, that term matches all packets.

An individual condition in a from statement can contain a list of values. For example, you can specify numeric ranges or multiple source or destination addresses. When a condition defines a list of values, a match occurs if one of the values in the list matches the packet.

Individual conditions in a from statement can be negated. When you negate a condition, you are defining an explicit mismatch. If a packet matches a negated condition, it is immediately considered not to match the from statement, and the next term in the filter is evaluated, if there is one; if there are no more terms, the packet is discarded.

Match conditions are grouped into the following categories depending on how you specify the condition:

• Numeric range

• Address filter

• Multiple match conditions

• Bit-field filter

Numeric range filter conditions match packet fields that can be identified by a numeric value, such as port and protocol numbers. For numeric range filter match conditions, you specify a keyword that identifies the condition and a single value or a range of values that a field in a packet must match. Table 8.18 describes the numeric range filter match conditions. You can specify the numeric range value in one of the following ways:

• Single number (for example, source-port 25 )

• Range of numbers (for example, source-port 1024-65535)

• Text synonym for a single number (for example, source-port smtp)

Table 8.18. Numeric Range Firewall Filter Match Conditions

Match Condition	Description
keyword - except	Negate a match. For example, destination-port-except number .
destination-port number	TCP or UDP destination port field. You cannot specify both the port and destination-port match conditions in the same term. Normally, you specify this match in conjunction with the protocol match statement to determine which protocol is being used on the port. In place of the numeric value, you can specify one of the following text synonyms (the port numbers are also listed): afs (1483), bgp (179), biff (512), bootpc (68), bootps (67), cmd (514), cvspserver (2401), dhcp (67), domain (53), eklogin (2105), ekshell (2106), exec (512), finger (79), ftp (21), ftp-data (20), http (80), https (443), ident (113), imap (143), kerberos-sec (88), klogin (543), kpasswd (761), krb-prop (754), krbupdate (760), kshell (544), ldap (389), login (513), mobileip-agent (434), mobilip-mn (435), msdp (639), netbios-dgm (138), netbios-ns (137), netbios-ssn (139), nfsd (2049), nntp (119), ntalk (518), ntp (123), pop3 (110), pptp (1723), printer (515), radacct (1813), radius (1812), rip (520), rkinit (2108), smtp (25), snmp (161), snmptrap (162), snpp (444), socks (1080), ssh (22), sunrpc (111), syslog (514), tacacs-ds (65), talk (517), telnet (23), tftp (69), timed (525), who (513), xdmcp (177), zephyr-clt (2103), or zephyr-hm (2104).
dscp number	Differentiated Services code point (DSCP). The Diffserv protocol uses the ToS byte in the IP header. The most significant six bits of this byte form the DSCP. For more information, see Chapter 6, "Interfaces and Class of Service," on page 185. In place of the numeric value, you can specify one of the following text synonyms (the field values are also listed): The Expedited Forwarding RFC defines one code point: ef (46). The Assured Forwarding RFC defines four classes, with three drop precedences in each class, for a total of 12 code points: af11 (10), af12 (12), af13 (14); af21 (18), af22 (20), af23 (22); af31 (26), af32 (28), af33 (30); af41 (34), af42 (36), af43 (38).
fragment-offset number	Fragment offset field.
icmp-code number	ICMP code field. This value or keyword provides more specific information than the icmp-type . Because the value's meaning depends on the associated icmp-type , you must specify the icmp-type along with the icmp-code . In place of the numeric value, you can specify one of the following text synonyms (the field values are also listed). The keywords are grouped by the ICMP type with which they are associated: parameter-problem: ip-header-bad (0), required-option-missing (1); redirect: redirect-for-host (1), redirect-for-network (0), redirect-for-tos-and-host (3), redirect-for-tos-and-net (2); time-exceeded: ttl-eq-zero-during-reassembly (1), ttl-eq-zero-during-transit (0); unreachable: communication-prohibited-by-filtering (13), destination-host-prohibited (10), destination-host-unknown (7), destination-network-prohibited (9), destination-network-unknown (6), fragmentation-needed (4), host-precedence-violation (14), host-unreachable (1), host-unreachable-for-TOS (12), network-unreachable (0), network-unreachable-for-TOS (11), port-unreachable (3), precedence-cutoff-in-effect (15), protocol-unreachable (2), source-host-isolated (8), source-route-failed (5).
icmp-type number	ICMP packet type field. Normally, you specify this match in conjunction with the protocol match statement to determine which protocol is being used on the port. In place of the numeric value, you can specify one of the following text synonyms (the field values are also listed): echo-reply (0), echo-request (8), info -reply (16), info-request (15), mask-request (17), mask-reply (18), parameter-problem (12), redirect (5), router-advertisement (9), router-solicit (10), source-quench (4), time-exceeded (11), timestamp (13), timestamp-reply (14), or unreachable (3).
interface- group group-number	Interface group on which the packet was received. An interface group is a set of one or more logical interfaces. For information, see "Applying Firewall Filters to Interfaces," on page 361.
packet-length bytes	Length of the received packet, in bytes. The length refers only to the IP packet, including the packet header, and does not include any Layer 2 encapsulation overhead.
port number	TCP or UDP source or destination port field. You cannot specify both the port match and either the destination-port or source-port match conditions in the same term. Normally, you specify this match in conjunction with the protocol match statement to determine which protocol is being used on the port. In place of the numeric value, you can specify one of the text synonyms listed under destination-port .
precedence ip-precedence-field	IP precedence field. In place of the numeric field value, you can specify one of the following text synonyms (the field values are also listed): critical-ecp (0xa0), flash (0x60), flash-override (0x80), immediate (0x40), internet-control (0xc0), net-control (0xe0), priority (0x20), or routine (0x00).
protocol number	IP protocol field. In place of the numeric value, you can specify one of the following text synonyms (the field values are also listed): egp (8), esp (50), gre (47), icmp (1), igmp (2), ipip (4), ipv6 (41), ospf (89), pim (103), rsvp (46), tcp (6), or udp (17).
source-port number	TCP or UDP source port field. You cannot specify the port and source-port match conditions in the same term. Normally, you specify this match in conjunction with the protocol match statement to determine which protocol is being used on the port. In place of the numeric field, you can specify one of the text synonyms listed under destination-port .

To specify multiple values in a single match condition, group the values within square brackets following the keyword (for example, source-port [smtp ftp-data 25 1024-65535]) .

To exclude a numeric value, append the string -except to the match keyword.

Address filter conditions match prefix values in a packet, such as IP source and destination prefixes. For address filter match conditions, you specify a keyword that identifies the field and one or more prefixes of that type that a packet must match. Table 8.19 describes the address filter match conditions. You can specify the address as a single prefix (a match occurs if the value of the field matches the prefix) or as multiple prefixes (a match occurs if any one of the prefixes in the list matches the packet). To specify the address prefix, use the notation prefix/prefix-length . To exclude a prefix, specify the string except after the prefix. Because the prefixes are order-independent and use longest-match rules, shorter prefixes subsume longer ones as long as they are the same type (whether you specify except or not). This is because anything that would match the longer prefix would also match the shorter one.

Table 8.19. Address Firewall Filter Match Conditions

Match Condition	Description
address prefix	IP source or destination address field
destination-address prefix	IP destination address field
destination-prefix-list prefix-list	IP destination prefix list field
prefix-list prefix-list	IP source or destination prefix list field
source-address prefix	IP source address field
source-prefix-list prefix-list	IP source prefix list field

Bit-field filter conditions match packet fields if particular bits in those fields are or are not set. You can match the IP options, TCP flags, and IP fragmentation fields. For bit-field filter match conditions, you specify a keyword that identifies the field and tests to determine that the option is present in the field. Table 8.20 describes the bit-field match conditions. To specify the bit-field value to match, enclose the value in quotation marks (double quotes). Generally, you specify the bits being tested using keywords. Bit-field match keywords always map to a single bit value. You also can specify bit fields as hexadecimal or decimal numbers. To negate a match, precede the value with an exclamation point. To match multiple bit-field values, use the logical operators list in Table 8.21. The operators are listed in order, from highest precedence to lowest precedence. Operations are left-associative.When you specify a numeric value that has more than one bit set, the value is treated as a logical AND of the set bits. You can use text synonyms to specify some common bit-field matches. You specify these matches as a single keyword.

If you specify a port match condition or a match of the ICMP type or TCP flags field, there is no implied protocol match. If you use one of the following match conditions in a term, you should explicitly specify the protocol in the same term:

• destination-port Specify the protocol tcp or protocol udp match condition in the same term.

• icmp-code Specify the protocol icmp match condition in the same term.

• icmp-type Specify the protocol icmp match condition in the same term.

• port Specify the protocol tcp or protocol udp match condition in the same term.

Table 8.20. Bit-Field Firewall Filter Match Conditions

Match Condition	Description
Conditions with Variables
fragment-flags number	IP fragmentation flags. In place of the numeric field value, you can specify one of the following keywords (the field values are also listed): dont-fragment (0x4000), more- fragments (0x2000), or reserved (0x8000).
ip-options number	IP options. In place of the numeric value, you can specify one of the following text synonyms (the field values are also listed): loose-source-route (131), record-route (7), router-alert (148), strict-source-route (137), or timestamp (68).
tcp-flags number	TCP flags. Normally, you specify this match in conjunction with the protocol match statement to determine which protocol is being used on the port. In place of the numeric value, you can specify one of the following text synonyms (the field values are also listed): ack (0x10), fin (0x01), push (0x08), rst (0x04), syn (0x02), or urgent (0x20).
Text Synonyms
first-fragment	First fragment of a fragmented packet. This condition does not match unfragmented packets.
is-fragment	Matches if the packet is a fragment.
tcp-established	TCP packets other than the first packet of a connection. This is a synonym for "(ack rst)" . This condition does not implicitly check that the protocol is TCP. To check this, specify the protocol tcp match condition.
tcp-initial	First TCP packet of a connection. This is a synonym for "(syn & !ack)" . This condition does not implicitly check that the protocol is TCP. To check this, specify the protocol tcp match condition.

Table 8.21. Bit-Field Logical Operators

Logical Operator	Description
(...)	Grouping
!	Negation
& or +	Logical AND
or ,	Logical OR

• source-port Specify the protocol tcp or protocol udp match condition in the same term.

• tcp-flags Specify the protocol tcp match condition in the same term.

When examining match conditions, the policy framework software tests only the specified field itself. It does not also test the IP header to determine that the packet is indeed an IP packet. If you do not explicitly specify the protocol when using the fields listed above, design your filters carefully to ensure that they are performing the expected matches.

Applying Firewall Filters to Interfaces

For a firewall filter to work, you must apply it to at least one interface:

 [edit interfaces] interfaces  interface-name  {   unit  logical-unit-number  {     family inet {       filter {         input  filter-name  ;         output  filter-name  ;       }     }   } } 

In the input statement, list the name of one firewall filter to be evaluated when packets are received on the interface. In the output statement, list the name of one firewall filter to be evaluated when packets are transmitted on the interface. You can apply only one input and one output firewall filter to each interface. You can use the same filter one or more times. Input or output filters applied to the loopback interface, lo0 , affect only input or outbound traffic sent from the Routing Engine, respectively.

When you apply a firewall filter to multiple interfaces, you can name individual counters specific to each interface. These counters enable you to easily maintain statistics on the traffic transiting the different interfaces. Configuration of interface-specific counters also creates separate instances of any policers you have configured for the same interface. To configure interface-specific counters, include the interface-specific statement:

 [edit firewall filter  filter-name  ] interface-specific; 

When applying a firewall filter, you can define an interface to be part of an interface group. Packets received on that interface are tagged as being part of the group. You then can match these packets using the interface-group match statement. To define the interface to be part of an interface group, include the group statement:

 [edit interfaces  interface-name  unit  logical-unit-number  family inet filter] group  group-number  ; 

Configuring Policing

Policing, or rate limiting, enables you to limit the amount of traffic that passes into or out of an interface. It is an essential component of filters designed to thwart DoS attacks. Policing applies two types of rate limits on the traffic: bandwidth, which is the number of bits per second permitted, on average, and maximum burst size. Policing uses a token-bucket algorithm, which enforces a limit on average bandwidth while allowing bursts up to a specified maximum value. It offers more flexibility than a leaky bucket algorithm in allowing a certain amount of bursty traffic before it starts discarding packets.

You define specific classes of traffic on an interface, to which you can apply a set of rate limits. To do this, you define policers within a filter statement. For example, to limit all ftp traffic from a particular source to certain rate limits configure the following:

1. Include one or more policer statements in the filter configuration; they must precede the term definitions. To avoid the time-consuming process of configuring a policer within each filter, you can also define a policer outside the filter; the policer can then be used as a template.

2. Reference the policers in the then clause of a term.

3. Add actions, such as accept or discard, or other action modifiers, such as count or log.

4. Apply the policers to an interface for them to be activated. You apply policers the same way you apply firewall filters.

The policer is applied to the packet first, and if the packet exceeds the defined limits, the actions of the then clause of the policer are applied. If the result of the policing action was not a discard, the remaining components of the then clause of the term are applied.

To specify the rate-limiting part of a policer, include an if-exceeding statement, specifying the bandwidth limit in bits per second and the burst size limit in bytes:

 if-exceeding {   bandwidth-limit  rate;  burst-size-limit  bytes;  } 

There is no absolute minimum value for the bandwidth limit, and the maximum value is 4.29 Gbps. Any value below 61,040 bps results in a minimum effective rate of 30,520 bps. The maximum value for the burst size limit is 100 MB. The preferred method for setting this limit is to multiply the bandwidth of the interface on which you are applying the filter by the amount of time you allow a burst of traffic at that bandwidth to occur: for example, 5 milliseconds . If you do not know the interface bandwidth, you can multiply the MTU of the traffic on the interface by 10 to obtain a value. If a packet does not exceed its rate limits, it is processed further without being affected. If the packet exceeds its limits, it can be discarded or marked for subsequent processing as specified in the loss-priority and forwarding-class statements.

To configure a policer action, include the following statements:

 policer  policer-name  {   then {  policer-action;  } 

To simply discard a packet that exceeds the rate limits:

 then {    discard; } 

To set the loss priority equal to low:

 then {    loss-priority low; } 

To set the forwarding class:

 then {    forwarding-class  class-name;  } 

The possible values for loss-priority are any , low , and high , and class-name is any class name already configured for the forwarding class.

Configure Accounting

For more information, see the JUNOS Getting Started technical documentation.

Juniper Networks routers can collect various kinds of data about traffic passing through the router. You can set up one or more accounting profiles that specify some common characteristics of this data, including the fields used in the accounting records, the number of files that the router retains before discarding, the number of bytes per file, and the polling period that the system uses to record the data. You configure the profiles using statements at the [edit accounting-options] hierarchy level. You assign a unique accounting-profile name for each profile, and this name cross-references the information specified at the [edit accounting-options] hierarchy with interfaces or firewall configuration statements.

Configuring Filter-Based Forwarding

You can configure filters to classify packets based on source address and specify the forwarding path the packets take within the router. You can use this filter for applications to differentiate traffic from two clients that share a common access layer (for example, a Layer 2 switch) but are connected to different ISPs. When the filter is applied, the router can differentiate the two traffic streams and direct each to the appropriate network. Depending on the client's media type, the filter can use the source IP address to forward the traffic to the corresponding network through a tunnel. You can also configure filters to classify packets based on IP protocol type or IP precedence bits. You can forward packets based on input filters only; you cannot forward packets based on output filters. To direct traffic meeting defined match conditions to a specific routing table, include the routing-instance statement:

 [edit firewall filter  filter-name  term  term-name  then]  routing-instance  routing-instance;  

See Chapter 9, "Routing and Routing Protocols," on page 373.

To implement filter-based forwarding, you must create a routing table group that adds interface routes to the routing instance created to direct traffic that meets defined match conditions to a specific routing table and to the default routing table inet.0 . You create a routing table group to resolve the routes installed in the routing instance to directly connected next hops on that interface.