Capitulo 10 JNCIA

Firewall filters in a networking environment perform many functions,
including restricting access to specific network resources.
Additionally, filters are associated with protecting the network
against denial-of-service (DoS) attacks and preventing spoofing of legal IP addresses. The
JUNOS software also uses firewall filters to provide you with accounting information and to
enable features such as filter-based forwarding.
This wide range of topics is a lot to cover in a single chapter, so we focus on the basic construction
and application of a firewall filter on a Juniper Networks router. First, we examine
why firewall filters are needed and when it is appropriate to implement them. We then see how
to construct and apply a firewall filter, and discuss the differences between using a filter on user
transit traffic versus protecting the Routing Engine. Finally, we demonstrate some JUNOS software
CLI commands used to monitor and troubleshoot the firewall filter operation.
Firewall Filter Overview
Before we begin to examine the details of implementing and configuring a firewall filter in the
JUNOS software, we should first discuss the larger picture of network security. The concept
of network security means different things to different people. To some, guaranteeing that a
packet’s contents are secure and unreadable is security. This is the driving precept behind the
IP Security (IPSec) protocols developed by the Internet Engineering Task Force (IETF). Other
network administrators would like to ensure that only acceptable personnel access specific
services. Generally speaking, a stateful firewall controls this type of access, examining the
Layer 3 and Layer 4 headers as well as the packet’s data. The firewall normally has the ability
to check domain name service (DNS) queries, validate web browser requests, and monitor
that TCP sessions do not remain active longer than required by the applications. Neither
function is the focus of this chapter. Instead, we examine a final form of security—the packet
filter.
You may already be familiar with the role a packet filter plays in a network; other router vendors
often call this an
access list
. The JUNOS software uses the term
firewall filter
to describe
the function of examining only the Layer 3 and Layer 4 headers on a packet-by-packet basis.
The filter makes a decision, based on rules you configure, as to whether the packet should be
forwarded or dropped by the router. The important distinction between a firewall filter and a
stateful firewall is that the filter doesn’t examine the packet’s data nor does it monitor the activity
of the TCP sessions transiting the router. The filter simply makes the binary decision about
forwarding the packet, allowing you to control access to resources in your network.
Implementing a Firewall Filter
431
Implementing a Firewall Filter
Although we understand the general function of a packet filter in examining a packet’s headers,
it is important to comprehend how the filter is implemented on a Juniper Networks router. The
firewall filter utilizes the functionality of the custom-designed
Internet Processor ASIC
. Our discussion
of a packet’s flow through the Packet Forwarding Engine in Chapter 1, “The Components
of a Juniper Networks Router,” detailed that the Internet Processor ASIC receives only the
notification cell to perform its route lookup. This cell contains the Layer 3 and Layer 4 header
information required by the filter, but it does not hold any information about the packet’s data.
While this lack of data keeps the router from performing stateful firewall activities, realize that
stateful monitoring is not the role your router should perform in the network.
The Internet Processor ASIC provides industry-leading forwarding rates for transit user traffic
while simultaneously supporting complex filtering, packet sampling, and rate-limiting features.
The Internet Processor ASIC supports a wealth of Layer 3 and Layer 4 packet-matching
conditions, actions, and action modifiers using a JUNOS software syntax that is quite similar
to the syntax of the policy framework discussed in Chapter 4, “Routing Policy.”
Each Juniper Networks M-series and T-series router contains an Internet Processor ASIC.
You can verify its existence by using the
show chassis hardware
command:
user@Shiraz>
show chassis hardware
Hardware inventory:
Item Version Part number Serial number Description
Chassis 50375 M5
Midplane REV 03 710-002650 HF1437
Power Supply A Rev 04 740-002497 LK22981 AC
Display REV 04 710-001995 HF1278
Host 8a00000749a99a01 teknor
FEB REV 08 710-002503 AL0781 Internet Processor II
FPC 0
PIC 0 REV 04 750-002992 HC5418 4x F/E, 100 BASE-TX
PIC 1 REV 03 750-002971 HE5256 4x OC-3 SONET, MM
Implementing a firewall filter within the JUNOS software is a two-step process: You first
define the firewall filter and then apply it to an interface. The filter definition uses various match
conditions, including the incoming interface on the router, IP address fields, protocol types, port
numbers, and other header bit fields. As a packet matches the specified conditions, actions are
performed to accept, discard, log, count, or sample the packet.
Writing the Firewall Filter
Although there are two steps to implementing a firewall filter, we focus on writing the filter
in this section. Simply put, you may not apply a filter until it is built. We examine the various
components of a firewall filter at a high level and see how the router evaluates the filter. We
432
Chapter 10 
Firewall Filters
then explore the possible match conditions and the actions to be taken if there is a match
within the filter.
Processing Filters
Much like a routing policy, a firewall filter has a specific set of rules that govern its processing
within the JUNOS software. Unlike a policy, however, only a single firewall filter may be applied
to any interface. Consequently, there is no concept of a firewall filter chain. The router evaluates
all packets individually against the specific filter applied to each interface.
We use the generic term
interface
throughout this chapter to represent both the
physical and logical portions of an interface in the JUNOS software.
The JUNOS software provides a very systematic method for constructing a firewall filter.
This allows you the maximum scalability and flexibility in using the router’s capabilities. You
configure a filter for IPv4 packets within the
[edit firewall family inet]
configuration
hierarchy. The basic syntax of a firewall filter is:
firewall {
family inet {
filter
filter-name
{
term
term-name
{
from {
match-conditions
;
}
then {
actions
;
action-modifiers
;
}
}
}
}
}
The JUNOS software requires the use of terms in a firewall filter and each term may contain
both match criteria and actions. The router evaluates the configured match conditions to determine
whether an IP packet meets all of the criteria of the filter. If it does, the router performs
any defined actions for the filter. The specific match conditions and actions are discussed in the
“Match Conditions” and “Actions” sections, respectively, later in this chapter.
The JUNOS software allows you to customize the names of your firewall filters so you can
easily identify their purpose at a later time. For example, a filter designed to deny ICMP pings
from Customer A might be named
no-ping-customerA
.
Implementing a Firewall Filter
433
We recommend that you assign self-explanatory names to your filters so that
their purpose is evident at a glance. A defined naming structure can help you
accomplish this goal.
Segmenting Filters
The lack of a firewall filter chain within the JUNOS software means that you have to write complex
filters with multiple terms to accomplish your goals. The basic firewall filter syntax is simply
expanded with multiple terms:
firewall {
family inet {
filter
filter-name
{
term
term-name
{
from {
match-conditions
;
}
then {
actions
;
action-modifiers
;
}
}
term
term-name
{
from {
match-conditions
;
}
then {
actions
;
action-modifiers
;
}
}
}
}
}
The multiple terms are evaluated in the order they are configured. New terms are always
added to the end of the existing filter. If this is not their desired location, you move them within
the filter by using the
insert
command (discussed later in this chapter).
434
Chapter 10 
Firewall Filters
While the requirement of using terms may appear restrictive, realize that there is a side benefit
to their use. You’ll often find it difficult to write a firewall filter and have it perform flawlessly
on your first attempt. Invariably, some match criteria and/or actions are left out. Using terms
allows you to add new information and rearrange the terms of your existing filter.
The Default Action
Each firewall filter in the JUNOS software contains a hidden term that causes a single final
action for all filters. This final action is to discard all packets and can be interpreted as:
term
implicit-rule
{
then {
discard;
}
}
This term does not appear in your configuration, but is applied by the router on all filters.
The lack of any
from
match conditions results in all packets performing the defined action: the
silent discard of those packets.
Many users configure this term within their filter for readability and to remember
that its actions always take place.
Match Conditions
Before writing a meaningful firewall filter, you must understand what information an IP packet
contains. Additionally, the type of IP user traffic entering your router is also good information
to have at hand. These two data sets provide the basis for the JUNOS software match conditions
for firewall filters. You can identify these criteria by using the
from
syntax. Unlike with a routing
policy, there is no
to
keyword.
The various match conditions are broken down into three categories: numeric ranges, address
fields, and IP header bit fields. We examine all three next in some detail.
Numeric Range Match Conditions
One very common criteria used in a firewall filter is the protocol number and port number of the
IP packet. These values readily translate into specific applications and programs used in the Internet.
For example, you may want all web-based traffic to be accepted but all ICMP (ping) traffic
to be rejected. The values contained in the IP header are configured within the filter like this:
[edit firewall family inet]
user@Shiraz#
show
Implementing a Firewall Filter
435
filter port-number {
term deny-telnet {
from {
protocol 6;
port 23;
}
then {
reject;
}
}
}
The term
deny-telnet
specifies that all packets with a protocol number of 6 (TCP) and port
number of 23 (Telnet) should be rejected. The use of both the protocol and port number ensures
that the correct traffic is rejected. The router does not assume that specific applications are
either TCP or UDP based; you must configure that knowledge explicitly to ensure that your filter
does not accept or reject unwanted traffic.
The JUNOS software allows you to use syntax keywords instead of numerical values for
many well-known protocol and port numbers. Here we’ve reconfigured our
port-number
filter
using this system:
[edit firewall family inet]
user@Shiraz#
show
filter example-filter-1 {
term deny-telnet {
from {
protocol tcp;
port telnet;
}
then {
reject;
}
}
}
Both the
example-filter-1
and
port-number
filters perform the same function. You may
use either the numeric values or the keywords, or both, in a single firewall filter. Many users find
the keywords easier to interpret and troubleshoot, so we use that method throughout the remainder
of the chapter.
436
Chapter 10 
Firewall Filters
A single filter term may contain multiple port numbers, if desired. For example, suppose you
want both Telnet and SMTP traffic to be accepted. Using two terms for this filter works as
expected:
[edit firewall family inet]
user@Shiraz#
show
filter example-filter-2 {
term allow-telnet {
from {
protocol tcp;
port telnet;
}
then accept;
}
term allow-mail {
from {
protocol tcp;
port smtp;
}
then accept;
}
}
However, the JUNOS software allows you to combine multiple numeric values within a single
match criterion by using the bracket notation:
[edit firewall family inet]
user@Shiraz#
show
filter example-filter-2 {
term allow-telnet-and-mail {
from {
protocol tcp;
port [ telnet smtp ];
}
then accept;
}
}
The router evaluates the allow-telnet-and-mail term as meaning that all TCP traffic with
a port number of 23 or 25 (SMTP) is to be accepted. Table 10.1 details the possible numeric
range match conditions that you use in a firewall filter.
Implementing a Firewall Filter 437
TABLE 1 0 . 1 Numeric Range Match Conditions
Match Condition Description
keyword-except Negates a match—for example, destination-portexcept
number.
destination-port number The TCP or UDP destination port field. You cannot specify
both the port and destination-port match conditions
in the same term.
Normally, you use this condition in conjunction with the
protocol match statement to determine which protocol
is being used on the port.
Some common text synonyms and their port numbers are
listed here: bgp (179), bootpc (68), bootps (67), domain (53),
finger (79), ftp (21), ftp-data (20), http (80), https (443),
kerberos-sec (88), ldap (389), msdp (639), netbios-dgm
(138), netbios-ns (137), netbios-ssn (139), nntp (119), ntp
(123), pop3 (110), pptp (1723), radius (1812), rip (520), smtp
(25), snmp (161), snmptrap (162), socks (1080), ssh (22),
syslog (514), tacacs-ds (65), telnet (23), or tftp (69).
dscp number The Differentiated Services codepoint. The Diffserv protocol
uses the type of service (ToS) byte in the IP header.
The most significant six bits of this byte form the Diffserv
codepoint (DSCP).
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 codepoint:
ef (46).
The Assured Forwarding RFC defines 4 classes, with 3
drop precedences in each class, for a total of 12 codepoints:
af11 (10), af12 (12), af13 (14), af21 (18), af22 (20),
af23 (22), af31 (26), af32 (28), af33 (30), af41 (34), af42
(36), or af43 (38).
fragment-offset number The fragment offset field.
icmp-code number The ICMP code field. This value or keyword provides
more specific information than the icmp-type condition.
Because the value’s meaning depends on the
associated icmp-type, it must also be specified along
with the icmp-code.
438 Chapter 10  Firewall Filters
icmp-type number The ICMP packet type field. Normally, you specify this
match in conjunction with the protocol match condition
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), routeradvertisement
(9), router-solicit (10), source-quench
(4), time-exceeded (11), timestamp (13), timestamp-reply
(14), or unreachable (3).
interface-group group-number The interface group on which the packet was received. An
interface-group is a set of one or more logical interfaces.
packet-length bytes The 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 The 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 The IP precedence field. The precedence bits are the three
most significant bits in the type of service (ToS) byte in the
IP header.
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 The 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).
TABLE 1 0 . 1 Numeric Range Match Conditions (continued)
Match Condition Description
Implementing a Firewall Filter 439
The JUNOS software allows you to enter an inclusive range of values. The criterion
port 6-25 means all values between 6 and 25.
Some of the conditions in Table 10.1, such as port, icmp-code, and icmp-type,
state that they are normally used in conjunction with a protocol match. This is
an important recommendation and ensures the proper operation of your filter.
Address Match Conditions
No filtering system would be complete without the ability to watch for IP addresses, and the
JUNOS software is no exception to that rule. You can use both the source and destination IP
addresses of a packet as a match condition. Consider the following filter:
[edit firewall family inet]
user@Shiraz# show
filter example-filter-3 {
term deny-subnets {
from {
source-address {
10.1.1.0/24;
172.16.0.0/16;
}
destination-address {
192.168.1.0/24;
}
}
source-port number The 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.
TABLE 1 0 . 1 Numeric Range Match Conditions (continued)
Match Condition Description
440 Chapter 10  Firewall Filters
then {
reject;
}
}
}
The deny-subnets term rejects any packets that have a destination address in the 192.168.1.0 /
24 subnet where the source address is in either the 10.1.1.0 /24 or the 172.16.0.0 /16 subnet. The
router interprets an address condition as a complete set of subnet addresses; all possible addresses
in the subnet may match.
You may specify multiple address prefixes in a filter term. The router performs a longest match
lookup on the specified addresses, much like a routing table lookup. As such, only a single prefix
in a term produces a match.
Don’t let the from address syntax confuse you into thinking that the router is
interpreting the directionality of the packet. The syntax checks both the source
and destination address fields, as shown in example-filter-3. Think of the
from/then filter syntax as really meaning if/then.
Table 10.2 lists the available address match conditions in the JUNOS software.
TABLE 1 0 . 2 Address Match Conditions
Match Condition Description
address prefix The IP source or destination address field. You cannot
specify both the address and the destinationaddress
or source-address match conditions in the
same term.
destination-address prefix The IP destination address field. You cannot specify
the destination-address and address match conditions
in the same term.
destination-prefix-list prefix-list The IP destination prefix list field. You cannot specify
the destination-prefix-list and prefix-list
match conditions in the same term.
prefix-list prefix-list The IP source or destination prefix list field. You
cannot specify both the prefix-list and the
destination-prefix-list or source-prefix-list
match conditions in the same term.
Implementing a Firewall Filter 441
For information on h ow to configure a prefix list, refer to the JNCIS Study
Guide.
Bit Field Match Conditions
The JUNOS software uses bit field match conditions to determine whether particular bits in the
Layer 3 and Layer 4 headers are set. These header fields include the IP options, TCP flags, and
IP fragmentation fields. For bit field matches, you specify a syntax keyword representing the
field to check and then supply the bit value in hexadecimal notation. Optionally, you can use
a text synonym to represent the bit value being checked.
The three filters shown here accomplish the same task of allowing return TCP traffic back into
your network. The difference between them is in the syntax options used to accomplish the goal.
[edit firewall family inet]
user@Shiraz# show
filter example-filter-4 {
term allow-tcp-established-ack {
from {
protocol tcp;
tcp-flags 0x10;
}
then accept;
}
term allow-tcp-established-rst {
from {
protocol tcp;
source-address prefix The IP source address field. You cannot specify the
source-address and address match conditions in
the same rule.
source-prefix-list prefix-list The IP source prefix list field. You cannot specify the
source-prefix-list and prefix-list match conditions
in the same term.
TABLE 1 0 . 2 Address Match Conditions (continued)
Match Condition Description
442 Chapter 10  Firewall Filters
tcp-flags 0x04;
}
then accept;
}
}
filter example-filter-5 {
term allow-tcp-established {
from {
protocol tcp;
tcp-flags "(ack|rst)";
}
then accept;
}
}
filter example-filter-6 {
term allow-tcp-established {
from {
protocol tcp;
tcp-established;
}
then accept;
}
}
Table 10.3 details the JUNOS software bit field match conditions.
TABLE 1 0 . 3 Bit Field Match Conditions
Match Condition Description
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).
Implementing a Firewall Filter 443
In both Table 10.3 and example-filter-5 earlier, we used the concept of a logical operator.
These operators allow you to construct complex Boolean operations in a firewall filter. You
configure these operators using a double-quote notation:
[edit firewall family inet]
user@Shiraz# show
filter example-filter-7 {
term allow-tcp-initial {
from {
protocol tcp;
tcp-flags “syn & !ack”;
}
then accept;
}
}
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).
first-fragment The first fragment of a fragmented packet. This condition does
not match unfragmented packets.
is-fragment This condition matches if the packet is a trailing fragment; it
does not match the first fragment of a fragmented packet. To
match both first and trailing fragments, you can use two terms,
or fragment-range 0-8191.
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 1 0 . 3 Bit Field Match Conditions (continued)
Match Condition Description
444 Chapter 10  Firewall Filters
The list of logical operators is shown in Table 10.4.
TABLE 1 0 . 4 Bit Field Logical Operators
Logical Operator Description
(...) Grouping
! Negation
& or + Logical AND
| or , Logical OR
A Useful First Filter Term
One type of traffic is almost always accepted by an inbound firewall filter: the traffic that your
network originates. After all, if your users can’t access resources outside your network, they
lose the ability to browse the Internet or send e-mail. These two applications use TCP as their
underlying protocol, and this is our focus for interacting with a firewall filter.
Remember that the essence of a TCP connection is a three-way handshake between hosts. This
means that a user sends out a TCP packet with the SYN flag set indicating its desire to form a
connection. The receiving host responds to this request with its own TCP packet. This returning
data has both the SYN and ACK flags set indicating that the remote host is acknowledging the
initial transmission and would like to set up its own connection to the local host.
Should this return TCP packet not reach the local host, the connection is not established and the
application does not function. Allowing this return packet through your inbound firewall filter
is a must. You have multiple methods for solving this issue. You could build a term that accepts
the return packet by application. The problem with this solution is administration of the firewall.
Every time a new application is required, you have to modify your filter settings. Alternately,
you could accept the return packet by either the source or destination IP address. Again,
there is an administration headache with this solution. You also encounter a scalability issue in
that the number of potential hosts sending the return traffic is quite large.
Implementing a Firewall Filter 445
The Absence of Match Criteria
Up to this point, we talked about the different match criteria we can use in a firewall filter term.
All of these options are, however, completely optional in their usage. You can configure a filter
without a match condition:
[edit firewall family inet]
user@Shiraz# show
filter example-filter-8 {
term accept-all-packets {
then accept;
}
}
When no match criteria are used, all packets will match the filter term. In other words, the
absence of match criteria means that all packets match and the configured actions are implemented.
In the case of example-filter-8, all IP user data packets are forwarded.
Many networks solve this problem by assuming that all traffic originated by your local network
is safe. Of course, there are inherent risks with this assumption. Some of your users could be
hackers using your network as a home base. Other users might unknowingly download viruses
or other harmful applications. In general, though, this assumption of safe local traffic holds
true. In this case, the filter configuration is quite simple: You allow the first term in your filter
to accept the return TCP traffic. You can see an example of this in the example-filter-6 filter
earlier in this section. In that filter, the initial term watches for protocol tcp as well as tcpestablished.
The keyword tcp-established is a synonym for a TCP packet that has either the
ACK or the RST flag set. Both of these flags indicate a return TCP packet to a local host that originated
the session.
A Common Last Term
When constructing a firewall filter, you must take one of two philosophical approaches. One
option is to allow into your network only packets that you know are good and reject everything
else. The opposite approach is to reject known bad packets and to accept everything else. Both
of these options have advantages and disadvantages that we won’t get into here. We also will
not be taking sides in this war. Instead, we focus on a useful and common last filter term when
you want to explicitly deny known bad packets.
446 Chapter 10  Firewall Filters
Actions
Identifying packets using the JUNOS software match conditions is only the first step in building
a firewall filter. Once you’ve located the packets, you must then decide what to do with them.
This is the job of a filter action.
All filter actions are configured within the then portion of the filter term. The JUNOS software
has three main types of actions you can use: terminating, flow-control, and action modifiers.
We explore these possibilities in the following sections.
Terminating Actions
A terminating action halts all evaluation of a firewall filter for a particular IP packet. The router
performs the specified action and no further terms are examined. Three actions exist within this
category: accept, discard, and reject.
The router forwards IP packets through a filter when the accept action is used. The opposite
function, packet drop, is performed when either the discard or reject action is configured. The
difference between discard and reject is in the response of the router to the dropping of the
packet.
When a packet is dropped as a result of the discard action, the router accomplishes this task
silently. This is generally a good option when your filter is used to protect against potential intruders.
The reject action prompts the router to return an administratively-prohibited ICMP
error message back to the source address in the packet’s header. If your goal is to keep unauthorized
traffic out of your network, you might not want to inform a potential intruder that you use
firewall filters to block traffic.
To assist you, the JUNOS software provides the ability to return other ICMP error messages
back to the IP source when you use reject. These alternative messages may be useful if a suspected
hacker is monitoring ICMP return messages for helpful information. In many cases, the
default error message is a clear sign to a hacker that a firewall filter has been reached. Table 10.5
details the possible ICMP options configurable with the reject action.
In this situation, your filter contains multiple terms with varying match conditions. The actions
in those terms are either reject or discard, depending on your desires. The issue that arises
is the implicit final filter action of then discard. Unless you manually alter the evaluation, the
filter drops all packets that have not matched a configured term. Clearly, this is not what you
intended.
The easy solution to this dilemma is to add a term to the end of your filter with no match criteria
listed. This term should have the terminating action of then accept configured. Additionally,
it would be wise to add either the log or syslog action modifier to that final term. This logging
function proves useful when you realize that you have discovered a new set of bad packets that
you want your filter to drop. The log files contain all the information you need to build a new
filter term and configure the appropriate match criteria.
Implementing a Firewall Filter 447
Flow-Control Actions
You have the ability to alter the default filter evaluation process in the JUNOS software. The
flow-control action next term allows the router to perform some actions on the packet and
then evaluate the following term in the filter. The action was designed to circumvent an implicit
accept that was associated with the filter terms. When you omit the then statement or use an
action modifier (discussed in the next section) within a filter term, the router accepts all packets
that match the configured criteria.
TABLE 1 0 . 5 reject Message Options
ICMP Message Type Notes
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
tcp-reset If you specify tcp-reset, a Transmission Control Protocol
(TCP) reset is returned if the packet is a TCP packet. Otherwise,
nothing is returned.
448 Chapter 10  Firewall Filters
To illustrate the need for the flow-control action, let’s look at an example. Suppose that you
have an inbound filter configured on your router. You would like to log information about all
received traffic on that interface. The filter should then reject telnet traffic but accept all other
traffic. You might logically configure a filter that looks like this:
[edit firewall family inet]
user@Shiraz# show
filter example-filter-9{
term log-all-packets {
then log;
}
term deny-telnet {
from {
protocol tcp;
port telnet;
}
then {
reject;
}
term accept-everything-else {
then accept;
}
}
The only action configured in the log-all-packets term is log. When the router evaluates
that term, it adds the implicit accept action and all IP packets are forwarded through the filter.
Clearly, this is not what you wanted. One simple solution is to simply add the log action to the
other existing terms:
[edit firewall family inet]
user@Shiraz# show
filter example-filter-9{
term deny-telnet {
from {
protocol tcp;
port telnet;
}
then {
log;
reject;
}
Implementing a Firewall Filter 449
term accept-everything-else {
then {
log;
accept;
}
}
}
While you solved the immediate issue, this is not a scalable solution. Imagine if your filter grew
to 100 or even 1000 terms. Placing the log action in each term is no longer a simple fix. This situation
is a perfect use for the next term action. Within example-filter-9, you configure this
action in the log-all-packets term. The router now logs information on all packets and passes
them to the following terms for further evaluation. The deny-telnet term now rejects the telnet
traffic and all other traffic is forwarded by the accept-everything-else term:
[edit firewall family inet]
user@Shiraz# show
filter example-filter-9{
term log-all-packets {
then {
log;
next term;
}
term deny-telnet {
from {
protocol tcp;
port telnet;
}
then {
reject;
}
term accept-everything-else {
then accept;
}
}
Action Modifiers
The JUNOS software may perform other functions on an IP packet being evaluated by a firewall
filter. Some of these actions include incrementing a counter, logging information about the IP
header locally, sampling the packet data, or sending information to a remote host using the
Unix syslog functionality.
450 Chapter 10  Firewall Filters
You can include any combination of action modifiers in a single filter term. Each term carries
with it an implicit accept action if no other terminating or flow-control actions are configured.
Let’s take a look at the available action modifiers.
count
A numerical packet counter is configured within a filter to track particular traffic types. All
counters operate within the Internet Processor ASIC, so forwarding performance is not affected
by their usage. You configure the count action and supply the name of the counter to increment:
[edit firewall family inet]
user@Shiraz# show
filter inbound-from-peer {
term count-traffic {
from {
source-address {
10.0.0/24;
}
then {
count traffic-counter;
accept;
}
}
}
The inbound-from-peer filter counts all packets with a source address contained in the 10.0.0.0 /
24 subnet. The specific counter that should be incremented is named traffic-counter.
log
Logging packet data is useful when you’re monitoring ongoing network events in real time. The
router can collect data contained in the IP header by using the log action. The information is
stored in a memory-resident buffer that is 500 lines deep. The buffer works on a first-in, firstout
basis, so the oldest data is overwritten by the newest data:
[edit firewall family inet]
user@Shiraz# show
filter log-tcp-flow-start {
term count-syn {
from {
protocol tcp;
tcp-initial;
}
Implementing a Firewall Filter 451
then {
log;
accept;
}
}
}
The log-tcp-flow-start filter matches only on the first packet in a TCP connection. The
header information of these packets is written to the buffer log and the packet is forwarded. The
log buffer is not stored on the router’s hard disk and can be accessed only with the show firewall
log command. (We discuss this CLI command in the “JUNOS software Commands” section later
in this chapter.)
sample
Statistical sampling examines a user-specified percentage of the traffic traversing the router.
This data can assist you in planning for future capacity, evaluating your network design, and
deploying new physical circuits. Sampling theory states that statistical sampling is quite accurate
when you select the sampling parameters properly.
Within the JUNOS software, you configure a filter to sample incoming traffic on a transit
interface by using the sample command:
[edit firewall family inet]
user@Shiraz# show
filter sample-peer-traffic {
term peer-connections {
from {
source-address {
10.10.0.0/16;
172.30.45.0/24;
192.168.164.0/20;
}
}
then {
sample;
accept;
}
}
}
The sample-peer-traffic filter samples all IP packets originating from one of the configured
peer subnets. The router then forwards the IP packets through the filter.
452 Chapter 10  Firewall Filters
Packet data is written to a file based on the sampling setting specified under
[edit forwarding-options]. The file is sent to a remote host using cflowd version
5 or 8. For more information regarding cflowd and its use, go to www.caida
.org/tools.
syslog
To overcome the limitation of the memory buffer used with the log action, the JUNOS software
provides a similar ability with the syslog command. The IP header information is now sent to
the hard drive on the Routing Engine using the normal Unix syslog process:
[edit firewall family inet]
user@Shiraz# show
filter log-tcp-flow-start {
term count-syn {
from {
protocol tcp;
tcp-initial;
}
then {
syslog;
accept;
}
}
}
We modified the log-tcp-flow-start filter to store the header information of the packets
to the hard drive instead of the memory log buffer. The logged data is contained within
the messages file and provides us with the ability to maintain a historical record of the stored
packets.
Applying Firewall Filters
Thus far, we’ve talked about how to build your own firewall filters and terms as well as the
defaults for the JUNOS software. We also discussed how the router evaluates from the first term
to the last term in order until it finds a match. To make your filter useful, you must apply it to
an interface on the router.
Each logical unit on the router may contain a single input and a single output filter. There
is no requirement to build a separate filter for each application. In fact, you should configure
as many reusable filters as possible to ease administration and troubleshooting in your network.
Once you apply your filter, the Internet Processor ASIC examines every packet received or forwarded
on that interface against the match conditions of the filter terms. When the router finds
a match, it takes the appropriate actions.
Protecting the Routing Engine 453
You apply each filter within the [edit interfaces] directory appropriate to your situation.
The fe-0/0/0.0 interface here has both an input and an output filter configured:
[edit interfaces fe-0/0/0]
user@Shiraz# show
description "Connection to AS 65000";
unit 0 {
family inet {
filter {
input AS65000-inbound-filter;
output AS65000-outbound-filter;
}
address 10.10.10.1/24;
}
}
When you access the router remotely using an in-band interface (not fxp0.0)
and you are creating firewall filters, it might be a good idea to use the commit
confirmed 1 command when you have finished. Should your new filter sever
your in-band connection, the router performs a rollback for you one minute
later to allow you to regain access.
Protecting the Routing Engine
Firewall filters configured on a router’s transit interfaces only evaluate user packets that are
flowing directly from one interface to another. These types of filters protect the network as a
whole from unauthorized access and other threats. The core routers themselves, however, are
left somewhat unprotected from unauthorized management access and other harmful effects.
You can achieve this type of protection by applying a firewall filter to the lo0 interface, which
protects the Routing Engine itself.
The CPU on the router’s switching control board actually implements this filter.
Therefore, this single filter processes all packets received on any transit interface
before they are sent to the Routing Engine.
Traditionally, two types of tools are used in a layered fashion to protect core routers. The first
line of defense is the router’s remote access management policy, which is essentially a list of IP
addresses. Management access to the router, like Telnet or SSH, requires a source IP address on
the list of approved addresses. After the source IP address is verified, a second tool, such as remote
454 Chapter 10  Firewall Filters
authentication dial-in user service (RADIUS) provides a second layer of security. A firewall filter
protecting the Routing Engine is a powerful replacement for the list of approved addresses.
Figure 10.1 shows the difference between a filter applied to the loopback interface as opposed
to one configured on a transit interface. The application of the filter to an interface on a Physical
Interface Card (PIC) affects only transit user traffic. Configuring a filter for the lo0 interface
affects and protects the Routing Engine.
FIGURE 1 0 . 1 Transit versus Routing Engine filters
You configure a Routing Engine filter the same way you do all other filters:
[edit interfaces lo0]
user@Shiraz# show
unit 0 {
family inet {
filter {
input protect-routing-engine;
}
address 192.168.1.1/32;
}
}
Firewall filters applied to the lo0 interface to protect the Routing Engine must allow
routing protocol traffic to be forwarded through the filter. The implicit discard in
every filter can cause disastrous and unintentional effects in your network.
Input Output
Filters here protect
the Routing Engine
Filters here affect
transit user traffic
Filters here affect
transit user traffic
lo0
Packet
Forwarding Engine
Routing Engine
IP II
Rate Policing 455
Rate Policing
The JUNOS software uses firewalls filters not only to drop or accept data packets but also to ratelimit
those packets. Rate policing enables you to limit the amount of traffic that passes into or out
of a particular interface. You can use a policer to thwart denial-of-service (DoS) attacks or to
enforce a service contract with a customer.
A firewall filter using a policer still employs the normal match conditions of addresses, protocols,
ports, and so forth to determine which specific traffic on an interface should be subject to rate
limiting. To apply rate limiting for all packets on an interface, you either omit any from match criteria
in a firewall filter or apply the policer itself directly to the interface. Before we begin using
our policers, however, we must first understand the configuration steps in building one.
Rate Limits
Policing uses two different types of values to rate-limit user traffic. The first is the bandwidthlimit
value, which is the average number of bits per second permitted in the range of 32Kbps to
32Gbps. The second is burst-size-limit, which is the amount of data allowed to exceed the
given bandwidth constraints. This value is configured as the number of bytes allowed between
1500 and 100,000,000 (100MB).
Only the IP packet and the IP header are calculated by the bandwidth-limit and
burst-size-limit options.
The JUNOS software policing function employs a token-bucket algorithm, which enforces a
limit on the average usable bandwidth while allowing bursts of traffic up to a specified maximum
value. This type of system allows an interface a certain amount of bursty traffic before
packets are discarded by supplying token credits on a regular time sequence up to the maximum
defined by the burst-size-limit value. At a high level, the algorithm works as follows:
1. As the policer evaluates each data packet, the current bandwidth of the interface is checked
against the bandwidth-limit value.
2. If the traffic flow is above the limit, the size of the packet (in bytes) is compared against the
current credits in the token bucket.
3. Should the packet size be smaller than the current credit, the policer accepts the packet and
reduces the current credit by that packet’s size. Otherwise, the policer rejects the packet.
The router deals with traffic that doesn’t meet the constraints of a policer in two main ways.
The packet is either silently discarded or its internal JUNOS software control information is
altered. This internal information is either the Packet Loss Priority (PLP) bit or the forwarding
class of the packet. By altering these values, you affect the probability that the packet is dropped
by the outbound interface when it becomes congested.
456 Chapter 10  Firewall Filters
The use of the PLP bit and the forwarding class for affecting traffic flows is
beyond the scope of this book.
Filter Policers
By using a policer in conjunction with a firewall filter, you can rate-limit specific types of traffic
flowing across an interface. Should a packet not exceed the defined rate limit, the router processes
it through the remainder of the filter term. If the packet exceeds the policer limits, it is
either discarded or altered based on the current router configuration.
A simple firewall filter using a policer might look like this:
[edit firewall family inet]
user@Shiraz# show
filter limit-ftp {
policer policer-1 {
if-exceeding {
bandwidth-limit 400k;
burst-size-limit 100k;
}
then discard;
}
term ftp {
from {
source-address {
10.2.3/24;
}
Setting the burst-size-limit
The Juniper Networks Technical Assistance Center (JTAC) suggests setting the burst-sizelimit
equal to the amount of traffic forwarded by the interface in 5 milliseconds. Let’s look at
an example.
Suppose you have a Gigabit Ethernet interface in your router. The interface can receive 1000
megabits per second. The burst-size-limit is entered in bytes per second, so we translate
1000Mbps into 125MBps. That further translates into 125,000KBps and finally 125,000,000Bps.
In a single millisecond, the interface receives 125,000 bytes, so a total of 625,000 bytes are
received in 5 milliseconds. The policer statement becomes burst-size-limit 625000.
Rate Policing 457
protocol tcp;
destination-port [ftp ftp-data];
}
then {
policer policer-1;
accept;
}
}
term accept-all {
then accept;
}
}
The limit-ftp filter rate-limits FTP traffic from hosts on the 10.2.3.0 /24 subnet only. All
other user traffic is accepted by the accept-all term. The policer, named policer-1, is placed
at the beginning of the filter by the router. It contains the rate limit values of 400Kbps of bandwidth
and a burst size of 100KB. FTP traffic exceeding the policer parameters uses the configured
action of discard.
If you apply the limit-ftp filter to multiple inbound interfaces, the policer definition is
shared among those interfaces. This means that the aggregate of the interface bandwidths is
combined before the router checks the policer parameters. You can create a separate instance
of the policer for each separate interface by using the interface-specific command like this:
[edit firewall family inet]
user@Shiraz# show
filter limit-ftp {
interface-specific;
policer policer-1 {
if-exceeding {
bandwidth-limit 400k;
burst-size-limit 100k;
}
then discard;
}
term ftp {
from {
source-address {
10.2.3/24;
}
protocol tcp;
458 Chapter 10  Firewall Filters
destination-port [ftp ftp-data];
}
then {
policer policer-1;
accept;
}
}
term accept-all {
then accept;
}
}
Interface Policers
A policer may also be configured directly on an interface to rate-limit all traffic flows. This
allows you the flexibility of a single configured policer applied to multiple interfaces, each with
its own instance of the policer. You configure this policer directly within the [edit firewall]
configuration hierarchy:
[edit firewall]
user@Shiraz# show
policer police-all-traffic {
if-exceeding {
bandwidth-limit 10m;
burst-size-limit 100k;
}
then {
discard;
}
}
The police-all-traffic policer discards all traffic above the limits of 10Mbps of bandwidth
and 100KB of burst capacity. You can then apply the policer to a transit interface, such
as fe-0/0/0.0:
[edit interfaces fe-0/0/0]
user@Shiraz# show
description "Connection to Customer-A";
unit 0 {
JUNOS software Commands 459
family inet {
policer {
input police-all-traffic;
output police-all-traffic;
}
address 10.100.1.1/24;
}
}
The same policer is applied in both the inbound and outbound directions. Additionally, you
can mix the interface policers and firewall filters together on a single interface. This allows you to
police all traffic flows while still securing your network with a filter:
[edit interfaces fe-0/0/0]
user@Shiraz# show
description "Connection to Customer-A";
unit 0 {
family inet {
filter {
input filter-customer-A;
}
policer {
input police-all-traffic;
output police-all-traffic;
}
address 10.100.1.1/24;
}
}
JUNOS software Commands
Now that you have a handle on creating and applying your firewall filters, let’s examine some
useful JUNOS software commands. These commands allow you to monitor your filter operation
as well as troubleshoot issues in your network. We first look at show and clear commands
specific to firewall filters and then revisit the insert and rename commands to modify your
configuration.
460 Chapter 10  Firewall Filters
show firewall
The show firewall command displays counter and policer statistics for all firewall filters. You
can include the name of a specific filter, as in show firewall filter filter-name, to view
just the statistics for that filter:
user@Shiraz> show firewall
Filter/Counter Packet count Byte count
protect-re
deny 46 2791
icmp 0 NA
Here, we’ve applied a filter named protect-re on the Shiraz router. This particular filter is utilizing
two different counters, deny and icmp, that supply byte and packet counts.
In examining the output more closely, you might notice that the icmp counter lists NA in the
Byte count column. In reality, the counter is not incrementing this field since it is a policer configured
within the firewall filter. By default, the Internet Processor ASIC automatically creates
a counter to record traffic in excess of a policer’s profile. The name of the policer is used in this
output as the name of the counter.
show firewall log
The show firewall log command displays entries in the memory-resident buffer or kernel
cache. The router stores information in this buffer when the log filter action is used. The cache
holds no more than 500 entries and wraps data when it is full. There is no CLI command to clear
the firewall log. Here is some sample output:
user@Shiraz> show firewall log
Time Filter A Interface Pro Source address Destination address
11:56:47 pfe A so-0/1/0.0 OSP 200.0.0.2 224.0.0.5
11:56:43 pfe A so-0/1/1.0 OSP 200.0.0.1 224.0.0.5
11:56:42 pfe A fe-0/0/1.0 TCP 10.0.8.2 10.0.8.1:179
The Filter column displays the name of the filter that logged the particular entry, if the filter
name is known. The Routing Engine is fully aware of filter names and enters data in this field for
traffic generated by it and logged by a transit filter. The Internet Processor ASIC on the Packet Forwarding
Engine is not aware of filter names and reports pfe as the filter name for all packets
logged by a filter action and sent to the memory buffer.
The column titled A between the Filter and Interface columns represents the action performed
by the filter for the particular packet. Possible entries in this column are A (accept),
R (reject), and D (discard).
JUNOS software Commands 461
The log buffer also displays information about the packet’s ingress interface, protocol, source
IP address, destination IP address, and port numbers.
The ingress interface displayed is not necessarily the interface to which the filter
has been applied. For example, the filter logging the data may be an egress
filter on the router.
You may also add the detail keyword to the show firewall log command to get more
information:
user@Shiraz> show firewall log detail
2001-09-03 11:57:42 UTC, Filter: pfe, Action: accept
Interface: so-0/1/1.0, Protocol: OSPF, Length: 64
Source: 200.0.0.1, Destination: 224.0.0.5
2001-09-03 11:57:42 UTC, Filter: pfe, Action: accept
Interface: fe-0/0/1.0, Protocol: TCP, Length: 52
Source: 10.0.8.2:1024, Destination: 10.0.8.1:179
show log messages
The show log messages command displays syslog entries in the file called messages. The
messages file is the default logging location for all router event information and can be quite
large. Firewall filter entries are sent using the syslog info level and have the code FW associated
with them, allowing you to more easily search for them. To see the firewall output only, pipe
the router output to match on the FW code:
user@Shiraz> show log messages | match FW
Sep 2 16:38:39 router scb FW: fe-0/0/2.0 A tcp 10.0.2.1 192.168.5.1 1026
23 (2 packets)
Sep 2 16:38:40 router scb FW: fe-0/0/2.0 A ospf 10.0.2.1 224.0.0.5 0
0 (1 packets)
Sep 2 16:38:40 router scb FW: fe-0/0/2.0 A tcp 10.0.2.1 192.168.5.1 1026
23 (2 packets)
The individual entries in the messages file are contained on a single line, allowing
the match pipe option to function. The particular output in the text was gathered
using a terminal width of 80 characters. Because each line is longer than
the terminal width, we see the apparent multiple-line entries.
462 Chapter 10  Firewall Filters
As with the show firewall log command, syslog entries indicate the ingress interface, protocol,
ports, and addresses for the stored packets.
clear firewall
You use the clear firewall counter-name command to reset the counters associated with
your firewall filters. You can clear an individual counter, an individual filter, or all filters on the
router. The appropriate command arguments control the specific action:
user@Shiraz> clear firewall ?
Possible completions:
all Clear all firewall counters
counter Counter name
filter Filter name
show interfaces filters
The show interfaces filters command displays all firewall filters configured on all interfaces
on the router. You can optionally specify a particular interface by adding the interface
name to the command, such as show interfaces filters interface-name:
user@Shiraz> show interfaces filters
Interface Admin Link Proto Input Filter Output Filter
fe-0/0/0 up up
fe-0/0/0.0 up up inet filter-1
filter-2
fe-0/0/1 up up
fe-0/0/1.0 up up inet filter-3
filter-4
fe-0/0/2 up down
fe-0/0/3 up down
show interfaces policers
The show interfaces policers command displays all policers applied on the router’s interfaces.
Again, a particular interface is viewed with the show interfaces policers interface-name:
user@Shiraz> show interfaces policers
Interface Admin Link Proto Input Policer Output Policer
fe-0/0/0 up up
fe-0/0/0.0 up up inet fe-0/0/0.0-in-policer
JUNOS software Commands 463
fe-0/0/0.0-out-policer
fe-0/0/1 up up
fe-0/0/1.0 up up inet fe-0/0/1.0-in-policer
fe-0/0/1.0-out-policer
fe-0/0/2 up down
fe-0/0/3 up down
show policer
The show policer command displays the names of all policers configured on the router. Additionally,
the router displays the interfaces where the policer is being used as well as the total
number of packets processed by the policer:
user@Shiraz> show policer
Policer: so-2/2/0.0-in-policer
so-2/2/0.0-in-policer
0 packets
Policer: so-2/2/0.0-out-policer
so-2/2/0.0-out-policer
238 packets
Both the show interfaces policers and the show policer commands display the
name of the policer in the format of interface.unit-in-policer or interface
.unit-out-policer. This naming syntax is used regardless of the policer name
configured within the [edit firewall] hierarchy.
insert
Assume you wrote a multiterm firewall filter called test-filter and applied it to an interface.
When you tested its operation, things just didn’t seem to work the way you thought they
would. After a closer examination of the configuration, you notice that term 1 should have
been term 2 and vice versa. One possible solution is to delete the entire firewall filter and
reenter it in the proper order. A better solution is to use the JUNOS software insert command
to easily reorder the terms.
The syntax of the insert command is:
[edit]
user@host# insert value-1 before|after value-2
464 Chapter 10  Firewall Filters
In the particular case of the test-filter firewall, either of the following commands solve
the problem:
[edit firewall family inet filter test-filter]
user@Shiraz# insert term 1 after term 2
or
[edit firewall family inet filter test-filter]
user@Shiraz# insert term 2 before term 1
rename
The JUNOS software rename command is just as handy as the insert command. Just like
renaming a routing policy name or an interface’s IP address, you can rename your firewall filters
and their terms. Using the rename command is very straightforward:
[edit firewall family inet]
user@Shiraz# rename filter filter-name1 to filter filter-name2
[edit firewall family inet filter filter-name]
user@Shiraz# rename term term-name1 to term term-name2
Summary
In this chapter, we saw how firewall filters allow you to filter packets based on their header
components and to perform specific actions on those packets. The Internet Processor ASIC provides
filtering capabilities on transit user traffic. Transit filters are useful for providing packet
filtering, thwarting denial-of-service (DoS) attacks, preventing address spoofing, and implementing
rate limiting. Filters may also be configured to protect the Routing Engine, its routing
protocols, and its services, such as Telnet and SSH.
Firewall filters consist of one or multiple terms, each containing a set of match conditions
using the from configuration syntax. After a packet matches the term’s criteria, you can perform
terminating actions, flow-control actions, or action modifiers.
After the filters are configured, they are then applied to the router’s logical interfaces. A single
interface unit may contain filters for inbound and outbound traffic.
The JUNOS software provides several useful show commands that allow you to check whether
your filters are working properly. Additionally, you can use the insert and rename commands
to alter your existing filter configurations.
Key Terms 465
Exam Essentials
Be able to describe firewall filter concepts. Firewall filters consist of match/action pairs that
allow you to target specific packets of interest and forward, reject, or silently discard them.
Understand that firewall filters allow control of traffic entering and leaving the router or Routing
Engine. Using both input and output filters controls how user transit traffic flows (or
doesn’t flow) through the router. A filter can also provide access control to the Routing Engine itself.
Know the various matching criteria available to identify specific packets. Various match criteria
are used to identify packets. Possible options include IP addresses, protocol and port numbers,
and other bit fields in the IP and TCP headers.
Be able to identify the possible actions taken when packets match a filter term. Actions can
allow the packet to be forwarded, rejected, or silently discarded via the accept, reject, and
discard actions. Additional actions include flow control through the next term action and
modifiers such as count, log, syslog, and sample.
Understand the use of action modifiers. You gather additional information about the contents
of a packet by using the action modifiers of count, log, and sample.
Identify JUNOS software commands that verify firewall filter operation. There are a number
of operational show commands that allow you to ensure the firewall filters are working
properly. Additionally, various configuration commands let you rename filters and reorder
terms as needed.
Key Terms
Before you take the exam, be certain you are familiar with the following terms:
accept logical operator
action numeric range match conditions
address match conditions Packet Loss Priority (PLP)
bit field match conditions rate policing
discard reject
firewall filter rename
flow-control action syslog
forwarding class terminating action
insert token-bucket algorithm
Internet Processor ASIC
466 Chapter 10  Firewall Filters
Review Questions
1. What are the components of a firewall filter? (Choose three.)
A. Match conditions
B. Actions
C. Action modifiers
D. Stateful monitoring
2. Which item is not a firewall filter action?
A. accept
B. discard
C. next filter
D. reject
3. Where would you apply a filter to protect the Routing Engine?
A. fxp0.0
B. fxp1
C. lo0
D. lo0.0
4. Which command might be best used when testing firewall filters through an in-band connection?
A. commit
B. commit and-quit
C. commit confirmed
D. commit confirmed 1
5. Firewall filters can be used to accept, discard, or reject packets based on _____. (Choose three.)
A. IP address
B. MAC address
C. Protocol type
D. Well-known port name
6. What is the rule regarding applying firewall filters on a single interface?
A. Multiple filters per logical unit in each direction (input and output)
B. One filter per logical unit in each direction (input and output)
C. One filter per physical interface
D. One filter per IP address, per logical interface in each direction (input and output)
Review Questions 467
7. Which action should be used to silently drop packets that match a term in a firewall filter?
A. accept
B. discard
C. dismiss
D. reject
8. A firewall filter is written and applied as an input filter on the lo0.0 interface. What types of
traffic will this action affect? (Choose two.)
A. Inbound packets destined for a remote network
B. Locally destined SSH sessions
C. RIP update packets
D. Transiting ICMP echo requests
9. When applying a firewall filter to the lo0.0 interface, you should be careful to do which of the
following?
A. Allow routing protocol traffic.
B. Allow transit traffic to enter on fxp0.0.
C. Allow transit traffic to exit on fxp0.0.
D. Restrict the number of telnet sessions to 5.
10. A firewall filter is applied as an input filter on a transit interface. Which types of traffic are
affected? (Choose three.)
A. Inbound traffic that is transiting the router
B. Outbound traffic that has transited the router
C. Traffic destined for the Routing Engine
D. Traffic destined for the interface address on which the filter is applied
11. Which command can be used to display information about packets that have been logged with
the log firewall filter action?
A. show firewall
B. show firewall log
C. show log
D. show log messages
12. Which command can be used to display information about packets that have been logged with
the syslog firewall filter action?
A. show firewall
B. show firewall log
C. show log
D. show log messages
468 Chapter 10  Firewall Filters
13. Which command clears all counters for the firewall filter named service-restriction only?
A. clear firewall
B. clear firewall service-restriction
C. clear firewall counter service-restriction
D. clear firewall filter service-restriction
14. What is the default action when using an action modifier?
A. accept
B. discard
C. reject
D. There is no default action.
15. If a packet does not match any terms in an applied firewall filter, the packet is ______.
A. Forwarded to the destination IP address
B. Silently discarded
C. Thrown away and an ICMP message sent to the source IP address
D. Sent to the Routing Engine for further processing
16. What items must be specified when configuring rate policing? (Choose two.)
A. bandwidth-limit
B. burst-size-limit
C. packet-size-limit
D. time-period
17. What is the default ICMP message sent to the IP source address of the packet when the action
is reject?
A. administratively-prohibited
B. host-prohibited
C. network-prohibited
D. port-prohibited
18. Which statement is true when using a match condition of port telnet?
A. It is not necessary to include protocol tcp as a match condition.
B. It is necessary to include protocol tcp as a match condition.
C. The router automatically checks for TCP as the protocol when port telnet is used as
a match condition.
D. The firewall stanza will not pass the commit checker.
Review Questions 469
19. Which action modifier logs packet matches to the hard drive on the Routing Engine?
A. count
B. log
C. syslog
D. next term
20. When using policers, which of the following is possible for packets exceeding the limits of the
policer? (Choose three.)
A. They are discarded.
B. They have their PLP bit set.
C. They have their forwarding class modified.
D. They are dropped from the network and an ICMP message is sent to the source address.
470 Chapter 10  Firewall Filters
Answers to Review Questions
1. A, B, C. Match conditions, actions, and action modifiers are all components of a firewall filter
in the JUNOS software.
2. C. The flow-control action available with a firewall filter is next term, not next filter.
Options A, B, and D are all terminating actions.
3. D. Although the loopback interface is the location where Routing Engine filters are used, the
actual application of the filter occurs on the logical unit portion, lo0.0.
4. D. The default timer for the commit confirmed command is 10 minutes. Using commit
confirmed 1 allows you quicker access to the router in case of a configuration error.
5. A, C, D. A firewall filter in the JUNOS software operates on the Internet Processor ASIC,
which evaluates only IP header information. Only options A, C, and D are contained in the IP
header. The Internet Processor ASIC never sees the MAC address of packets.
6. B. Each logical unit on the router may have a single input and a single output filter applied at
any one time.
7. B. Both discard and reject drop packets in a filter term, but only discard does so silently.
8. B, C. Firewall filters applied to the lo0.0 interface evaluate only packets destined for or
originating on the router itself. Only options B and C match this description.
9. A. All routing protocol traffic must be received by the Routing Engine to be effective. One common
error when configuring filters is not accepting the routing protocol traffic.
10. A, C, D. Input firewall filters applied to transit interfaces affect only traffic entering the router,
regardless of its destination.
11. B. The log filter action sends information to the memory buffer cache on the Routing Engine.
You can view the buffer’s contents with the show firewall log command.
12. D. The syslog filter action sends information to the hard drive storage file called messages.
You can view the file with the show log messages command.
13. D. Only the clear firewall filter service-restriction command will clear all
counters on the given firewall.
14. A. When using an action modifier in a filter term, the default terminating action is accept.
15. B. The implicit final term in a filter matches all packets with an action of discard. This action
silently discards packets from the network.
16. A, B. The two values configured in a policer are bandwidth-limit and burst-size-limit.
17. A. The reject filter action sends an ICMP message of administratively-prohibited back
to the source IP address of the packet.
Answers to Review Questions 471
18. B. The router does not automatically check for the type of protocol for a given packet. It is best
to include a protocol match condition, such as protocol tcp, to guarantee your filter is working
properly.
19. C. The syslog action modifier sends information to the hard drive storage on the Routing
Engine.
20. A, B, C. A policer action may discard packets, modify the PLP bit, or alter the forwarding class
information in a packet.