Junos Firewall Filters | Introduction to Juniper and JNCIA Part 14

firewall filters are like acls they're used to match traffic and perform an 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 acl4 comparison in case you're more familiar with those firewall filters are constructed with their own policy language this part really does feel like programming with something like if then and else statements the first component of a filter is called a term every policy contains one or more terms the terms are 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 the source and destination ip addresses the source and destination ports protocol and packet header fields like quas 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 on to the next term interestingly from statements are optional if there's 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 except is obvious but there's a subtle difference between reject and discard reject will drop the packet and it will send back an icmp unreachable message discard will silently drop the packet these three actions are called terminating 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 acls 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 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 count 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 route 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 ingress direction and in an egress 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 this a try we're going to configure a firewall filter to restrict ssh access to the switch and completely block telnet only the 192 168 211 address we'll have ssh access so to do this we'll create three terms the first term allows ssh from 192 168 211 the second term will deny all ssh and telnet traffic don't forget the default term has an implicit deny so we need a third term to allow all other 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 notice that i explicitly use the inet family this can optionally be omitted if the family is not explicitly included the inet family is assumed if you want to create an ipv6 filter you would need to include family inet 6. 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 easier 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 192.168.211 address using a tcp protocol on the ssh 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 then statement in this case this is simply to accept this traffic in the second term we're denying all ssh 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 discard action will silently drop 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 commit 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 vlan 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 0. this by default comes configured with unit 0 and an ip address this represents the internal link to the routing engine so if we want to filter traffic to the re 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 srx firewall apparently some mx 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 terms 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 acls in ios if you're interested in taking the jncia exam you'll definitely need to understand firewall filters they're not just used 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 3 of the introduction to juniper series click the next video to begin part 4 which is all about routing

Channel: Network Direction

Views: 2,278

Rating: 5 out of 5

Keywords: Network direction, Juniper, Junos, JNCIA, JN0-103, Firewall filters, Acl, Packet filter, Qos, Term, Access control entry, Implicit deny, From, Then, Action, Accept, Reject, Discard, Syslog, Sample, Next-term, Input, Output, Nesting, Lists, Next-policy, Control plane protection

Id: 7LXFonmAKk0

Length: 11min 14sec (674 seconds)

Published: Tue Feb 09 2021