Juniper Routing Policy and Firewall Filters

This chapter is from the book

Juniper Networks Field Guide and Reference

Learn More Buy

This chapter is from the book

This chapter is from the book 

Juniper Networks Field Guide and Reference

Learn More Buy

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 ;
				}
			}
		}
	}
}

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

Table 8.17 Firewall Filter Action Modifiers

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

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

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.

Table 8.20 Bit-Field Firewall Filter Match Conditions

Table 8.21 Bit-Field Logical Operators

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.

• 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

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;

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.