Understanding Prefilter policy in FTD

hello welcome back to firepower threat defense training video series and nanda in this video I'm going to talk about pre-filter policy in fiber threat defense before we go further into the pre-filter policy I would like to highlight the difference between pre-filter policy and access control policy as the name suggests the pre-filter policy happens much before the access control policy the pre-filter policy has two different type of policy one as tunnel policy and another other one as a pre-filter with pre-filter policy you could create a rule with simple IP level and then TCP protocol or a port number and then with VLAN tagging and then have actions on the matching traffic apart from that you have a tunnel tunnel rule which where you can match certain encapsulation traffic such as GRE IP and IP or ipv6 in IP or trade oh these encapsulation packet if you see a traffic that matches any of this protocol what you want to do you want to simply drop the packet at the pre filter level or you want to allow them at the pre filter level or strip of the encapsulation packet and then sync the inert payload to access control policy for further inspection these two different policy can be done at pre filter policy they are primarily matching criteria are based on IP address and port whereas access control policy it is much beyond from l22 application level right you can create policy based on IP address geo locations our security security intelligence e based on repetition of one particular IP you could say whether to allow or not and further further you can create policy based on user you know based on the destination you are that user is accessing based on application so all sort of else'll on inspection can be configured on access control policy on the action in the brief filter policy you have three actions one is analyze second is block and then fast path so let me talk about the fast path if rule matches based on the particular source IP dismiss Apr protocol port number if a traffic matches then if you depth action is fast path that traffic is allowed to exit the egress interface without any further inspection this helps greatly reduces the latins latency on a particular connection say for example if you have a traffic traveling from a server network to a different server network or a server network to a backup server where you trust the traffic and trust the IP address and you don't want to do any advance inspection on those traffic you could very well use the pre-filter policy to create access control to create a rule that matches a district network and then port number with the action fast path on the other side if you know that particular two network does not need to talk to each other for example a charm network does not want to talk to an RMD or a server network you could create the rule with an IP address a charm network rule and the network and harden network and then have the action as block so what that mean is you don't need to raise the f.2d resources to do an inspection for up to block which you know that it's the traffic is not needed and then you can block it at tree filter policy on the analyzed typically can be used when you when you know that in your network you have you are seeing and traffic which is either GRE or IP IP encapsulation traffic and you could create a rule which matches the GRE peer address address and then it once it matches the pre-filter policy strips of those encapsulation header and then when the action is analyzed the packet will be sent to the access control policy for further inspection so in access code policy you can have rules to match or inspect the inner payload of the encapsulation packet so let's go to the FMC and then see how to configure the pre-filter policy and how to verify and what are the other troubleshooting things that you can do it with pre-filter policy so as you could see that access control policy that by default the pre-filter policy is pointing to a default pre-filter policy every access control policy will have one pre-filter policy by default it will be equally pointing towards default pre-filter policy and if you create a custom or new pre-filter policy that you can point to here so you can find the pre-filter policy under policy access control people to policy the default one which cannot be changed has a no rule and has a default action which says analyze all tunnel traffic which means that if it finds any of the encapsulation tunnel traffic which is GRE or IP an IP or trudeau it's going to sing those traffic's to access control policy for further inspection I'm going to create a new rule reading so as I said we have two pol two rules one is tunnel rule and the other one is pre-filter rule let's look at what is tunnel rule as I said during the initial slide the tunnel rule will do an inspection based on encapsulation protocols such as GRE IP IP ipv6 and Trudeau you can create create a rule to match any of these encapsulation protocol and then say what you want to do with it either you want to analyze which means that it could same the inner payload for for the inspection to the access using access control policy or if you action is block then HEPA traffic matches this particular rule if it drops a packet at a pre-filter level if you say Pass Fast Pass then that match to traffic would be allowed to go to the glass interface we thought any further inspection get access Kanto policy so let's create a simple GRE Jun and then I'm going to say that fast path and we have two option here - match tunnel only for source and then match tunnel for both source and destination what that mean is with this matching criteria it's going to create a rule and if you have talent matching only for source that is only one policy will be created on the device if you have a match done for both source and destination there'll be two policy one is on the Icarus interface one is on the reverse direction so let me have the source and destination and then we verify that on the device CLI so I'm going to say from outside as a source and then inside network and then tunnel endpoint that is let's say like if I'm going to use a GRE as a protocol then the tunnel endpoint IP address that I have to mention here say for example so 192 one state 10 dot LaVon will be the source GRE IP address and then which which which expects maggot match on the track traffic similar on the destination and then set up the encapsulation protocol GRE you click Add and there you go you have this policy let's save this and if you could see that default action which action is analyze all traffic we will also see what that mean is so now that we have created the access control OC now we have to associate this to an access control so I'm going to associate this to an access from AC - policy saying the default policy - to the people of policy that I've just created setting it to pre filter - demo save this configuration deploy to the device now the deployment is completed let's go to the device and verify the conjugation and access control list so here you can see the pre pre filter policy pre filter policy here the one GRE tunnel that get created with IP wanted to 160 10.11 you could see that there are two rules that have been created here with the action trust from outside to inside and as I said there are two rules it is because that we have used this match the tunnel for source and destination now if we had if we are huge that rule that only from so then you would have seen only the first rule which means that you need to create one more rule for the returned traffic since we use the action as fast path we have the action as trust if we would have used as analyzed then we can we would have seen that traffic has permit apart from that we have default action as analyze all tunnel traffic so that has translated into these default rules which says that any traffic from game from any interface and any IP address that matches a protocol for GRA of either GRE or IP in IP or ipv6 all the tunnel protocol will by default mark does permit and then will be sent to access control for access control policy for further inspection let's create a prequel to policy rule to see how it works I'm going to create a pre-filter policy to all over traffic from inside Negro to outside into out then I'm gonna mark the action as fast path said their interface into his own and I'm going to say instead of course to an outside host so if a traffic matches from from source 160 note that this host one outside host I want the action as fast path let's see how it works and at the same time if I have I'll create one more rule from open and mark that as an lies and that is traffic from outside to inside the same set of pair of interface but I'm gonna reverse the network if a traffic or jannat from one eye to one sixth eight 10.10 to one side route 16 dog came back in from inside to outside I want the action to be analyzed which means that the traffic will be sent to the access control policy and also the let's make sure their access control policy exists we don't have any access from the policy and then the action is block all traffic so we should see that traffic are coming from out to inch be blocked let me dip lower the policy now the deployments such a fool let's go to and verify the qualification on the scale like now you could see that pre-filter policy has been created here there are two prefilter policy one is from inside to outside and awareness from outside to inside from inside to outside resist rust rule and then from outside to inside since we said it's an analyze the action is permit so which means that the traffic would be subject to the I'm from with access from the policy so I have an inside busy I'm going to do a tenant FTP from inside to outside and as per our rule this should be allowed with the first part yes I'm able to login to outside let's verify the connection so I can see the traffic from inside one surface 16 10 to 10 to 1 outside with a flag if you find a flag yen in this which means that this traffic is subject to snot inspection since we don't have the N flag which we can understand that this connection is started flowing and started trusting based on pre filter rule now I'm going to create a traffic from outside to inside so I could see that the traffic is getting blocked now the traffic from outside to inside is blocked by the access control policy which is with a default rule which is block all the traffic I'm going to create a new rule to allow traffic from outside to inside inside I'm gonna just enable the IPS inspection here and then say allow if there is no malicious activity on this traffic let's deploy this and then see how it works deployment a successful it's it's it's in a traffic from outside to inside now the traffic is allowed from outset inside let's verify on the device so now we can see the traffic from outside to inside and on the flag you see that flat and it says that this traffic is sent to access kind of policy that is not engine for further inspection with this we have come to the end of this video I hope this video is to meet you please subscribe to this channel for for more videos see you soon bye bye

Channel: Securing Networks with Cisco Firepower Threat Defense

Views: 15,779

Keywords: Pre-filter, prefilter vs Access Control policy, understanding Prefilter policy

Id: a4ahGktYIv8

Length: 16min 34sec (994 seconds)

Published: Mon Sep 18 2017