Firewall filters are like ACLs.
They're used to match traffic and perform in action in the most obvious case.
This acts as a packet filter or stateless firewall, but they can be
used for other things too, like routing policies and quality of service.
This video gets us familiar with how firewall filters are built
The most obvious use of a firewall
filter is to permit or deny traffic.
This makes our router or switch act as a stateless firewall
On your screen, you can see an example of how a firewall filter is built.
I've included the corresponding Cisco ACL for comparison.
In case you're more familiar with those
firewall filters are constructed with their own policy language.
This part really does
feel like programing with something like if then an L statements
the first component of a filter is called a term.
Every policy contains one or more terms.
The terms of the rules, these are like an access control entry in an ACL.
These contain the matching conditions and the action
when there is more than one term.
They are evaluated from the top down in the order they are shown in the config.
There is an implicit deny at the end of the filter.
This is an invisible term that drops all traffic
that is used if no other term matches.
There are two parts to a term.
The first part is matching traffic conditions.
This is done using a from statement
using the from statement.
We can match criteria like these source and destination IP addresses, the source
and destination ports protocol and packet header fields like cross markings
multiple from
statements in a single term are also valid.
We would do this for example, if we wanted to match the source
IP and a particular destination port number.
If there are multiple from statements,
they must all match for the entire term to be considered a match.
If the term doesn't match, processing moves onto the next term.
Interestingly, from statements are optional, there is no from statement.
Then all traffic will match.
The second part to a term is applying an action with a then statement.
This only applies if the traffic has been matched with a from statement.
There are a ton of actions we can apply.
We can even apply more than one action.
In some cases
The simplest actions are accept, reject and discard.
Accept is obvious, but there's a subtle difference between reject and discard
reject will drop the packet and it will send back in ICMP unreachable message.
Discard will silently drop the packet.
These three actions are called Terminate ing actions
when a terminating action is applied.
Processing of the packet filter ends.
No further terms are evaluated.
That's not surprising, really.
That's how most firewalls and seals work.
There are additional actions which are non terminating.
An example of a non terminating action is syslog,
which logs information about the packet.
Another interesting example is the sample action.
This collects a few packets, perhaps one in every thousand,
which can be sent externally for monitoring.
Non terminating actions are not final.
Which is why we can apply more than one action in some cases
We can have several non terminating actions per term,
but only one terminating action
when we apply a non terminating action.
They technically come with an implicit allow action.
This is terminating
which would prevent any other terms from being evaluated.
To work around this, we can't apply the next term action.
This will result in all non terminating actions being applied
and the next term being evaluated in the associated lab.
We try out the account action along with next term.
Then statements are technically optional.
If we don't include a then statement, traffic is permitted
Firewall filters can be used for several purposes, not just packet filtering.
For example, policies and quality of service
What matters is how we use our firewall filters.
So how do we turn this into a packet filter?
We apply it to an interface.
Each interface can have filters applied
in an English direction and in an English direction.
In config we refer to this as input and output.
Of course, we can apply
one policy to several interfaces if we want to.
The interesting thing in the Junos world
is that we can have more than one policy applied to a single interface
You might, for example, have general policies that you apply
to all interfaces and then more specific policies that you apply to some of them.
This can be done in two ways
nesting and lists
in the nested approach.
We have a single firewall filter applied to the interface.
This filter contains its own terms, conditions and actions.
Some of these terms will refer to other firewall filters.
This is a hierarchical style approach
Alternatively, we can apply several policies
directly to the interface as a list using square brackets.
The filters are evaluated sequentially in the order that they appear in the list.
When you have a list of firewall filters,
you can start using the next policy action.
If this is applied, the rest of the current policy is skipped
and the next policy in the list is evaluated.
Let's give all is a try.
We are going to configure a firewall filter to restrict sage
access to the switch and completely block telnet
only the 192168 211 address.
We'll have stage access.
So to do this, we'll create three terms.
The first term allows SSA from 19 to 168 211
The second term will deny all SSA Internet traffic.
Don't forget the default term has an implicit deny.
So we need a third term to allow all of the traffic.
The first step is to define our filter.
I'm creating one named management.
I put this in all caps just to stand out.
This is not a requirement by any means, just something I do.
Sometimes
there is an I
explicitly use the iiNet family.
This can optionally be omitted
if the family is not explicitly included.
The iiNet family is assumed if you want to create an IPv6 filter,
you would need to include family on it. Six
Now for the first term,
all terms have names which we can decide on ourselves
Some people like to include a number in there
to make the order of evaluation easy to read.
I don't like that so much as we might change the order of our terms
at some point down the track.
I have set three from statements in this term
for traffic to match this term, it needs to be coming from the 192168
211 address using a TCP protocol on the SSA port.
Saying from destination port may sound a little confusing.
But just remember that from really means match
Now we want to set an action for this traffic.
We'll do this with the event statement.
In this case, this is simply to accept this traffic
in the second term.
We're denying all S-H and Telnet traffic
normally all from statements need to be satisfied for the traffic
to be considered a match.
Here I am changing this behavior a bit
by including two different ports in a list.
In this case, either of these can match
for the whole term to be considered a match.
The discard action will silently draw up
any traffic that matches this term.
And finally, the third term, which matches all other traffic and allows it
we're not completely finished yet,
but I'm going to give this a commute anyway.
Now we can apply this to an interface, but which one
This is to filter traffic sent to the switch.
Does this mean we need to apply this to every interface or perhaps to a villain?
Maybe the management interface
You might find the answer to be a bit surprising.
We apply this rule to the loopback interface in Junos.
We have one loopback interface loopback.
Zero.
This, by default, comes configured with Unit zero and an IP address.
This represents the internal link to the routing engine.
So if we want to filter traffic to the array,
we will apply a filter to the loopback interface.
The filter is applied under the family
Keep in mind that you need to use the same family as you did in the filter.
The direction is input.
As we're filtering traffic coming into the device
We have configured a basic form of control plane protection
to see where our filter is applied.
Run show interfaces Filters.
I'm filtering the output for interfaces with IPv4 addresses only.
There are two columns here, one for input and one for output.
We can see that our firewall filter is applied on the loopback
interface in the input direction.
If we added a log action to our firewall filter term
we could see additional information using the show firewall log command.
Perhaps you can try this out yourself.
I just want to reiterate that we've been looking at stateless
firewall filters here.
These don't track the state of the flow of traffic
like a real firewall would for stateful firewall filtering.
You would need an Citrix firewall Apparently some mixed series routers
also have this option.
Juniper's
firewall filters are quite different to what you're probably used to.
So let me give you a quick summary
Firewall filters are the same thing as ACLs, despite the name.
They're not just for allowing and denying traffic.
They're also used in various policies.
A firewall filter contains a number of rules called Termes.
Each term contains match conditions using the from keyword and actions
using the then keyword
for traffic filtering, one or more filters are applied
to interfaces in the input or output direction.
In my opinion, while firewall filters look harder at first,
they're actually better than icons in iOS.
If you're interested in taking the giant CEA exam,
you'll definitely need to understand firewall filters.
They're not just use for packet filtering.
They're also used for routing policies, which we'll see in a few videos time.
If you can, I recommend practicing this in the lab.
I've got a few lab challenges for you on the website.
If you're interested,
lock this in your brain
as we're going to see firewall filters again.
This is the end of part three of the Introduction to Juniper Series.
Click the next video to begin part four, which is all about routing.