Juniper JNCIA JN0-103 – Routing Policy and Firewall Filters Part 6

12. Anti Spoofing

Welcome back. In this lecture we’ll talk about antispoofing. Let’s begin. Before we talk about antispoofing, let’s understand what do we mean by IP Spoofing? So, one method of attempting to gain access to a restricted area of the network is to insert a false source address in the packet header to make the packet appear to come from a trusted source.

This technique is called as IP spoofing. IP Spoofing is a very well known attack on networks where you actually spoof the source address. You forward a packet and change the source IP address of the packet to make it look like it is coming from a trusted network. This technique is called as IP spoofing. Unicast Reverse Path Forwarding, also known as Unicast RPF Check, is a tool used to reduce forwarding of IP packets that may be spoofing an address.

A Unicast RPF check performs a route table lookup on an IP packet’s source address and checks the incoming interface. If the packet is from a valid path, the router forwards the packet to the destination address. If it’s not from a valid path, the router discards the packet. Unicast RPF is supported for IPV Four and IPV Six protocol families, as well as for the Virtual Private Network or VPN address family. Let’s look at an example. On the right hand side, I have a little diagram.

There’s a router which has two interfaces fe One. There’s a network which is ten one 100:24 which is attached to the fee. The router receives an incoming packet on Fe One interface which has a source IP address of ten one one six. Just by looking at it, we can quickly figure out this is a spoofed IP address. Because ten dot one dot one dot zero slash 24 is attached on Fe zero. The source IP of ten one dot six should never be received on any interface other than Fe zero.

This is what we call as IP Spoofing. So if a packet with source IP address ten one six arrives at Fe One, but the Juno’s operating system has a route to ten one, fe zero, a check for IP Spoofing discovers that this address arrived at an Invalid interface as defined in the routing table. What this essentially tries to tell you is that when we look at the routing table of this router, we’ll have a direct route for ten one 100:24 connected via Fe Zero, but the packet arrived on an Invalid interface which is Fe one. A valid packet from ten one one six can only arrive via fe zero, not Fe One.

Therefore, the Juno’s operating system concludes that the packet has a spoofed source IP address and discards it. Let’s talk about strict versus loserpf. Both of these are modes of reverse path forwarding. When using Lose mode RPF, the Juno’s device only checks to see if a valid route to the source exists. In the routing table, we spoke about default route in one of the earlier lectures. I believe that was a lecture on routing tables. Most of the devices will have a default route called Zero Zero pointing to the next top IP address. When we configure the device to use Losemode RPF, it only checks to see if a valid route to the source exists in the routing table. Imagine this if we are using Lose Mode RPF, it only checks to see if a valid route exists or not. By default, the default route will cover every possible address. And obviously it is going to allow all the packets, right? So on devices that have a default route, a valid route to every IP address exists. Hence Lose mode RPF will allow all packets. When using Strict Mode RPF, the Juno’s device checks to see if a valid route to the source exists in the routing table and if the packet has arrived on the correct interface. So Strict Mode RPF looks not only for the presence of a route, but also checks to see if the packet arrived on the correct interface.

Now let’s talk about active versus feasible path. On the left hand side of the screen, I have PCA which is connected to router R One. R One is connected to two routers r Two and R Three and R Two and R Three are connected to another router called R Four, which then connects to the Internet. Imagine PCA wants to make a request to connect to the Internet. The request from PCA first reaches router One. Router one can forward the packet to R Two or R Three.

Let’s just assume for a minute r One forwards the packet to R Two. R Two forwards the packet to R Four and the packet reaches the Internet. When the response comes back, it first hits R Four. At this point, R four can forward the packet back to R two or R Three. If Router R Four forwards the packet to R Two, it goes to R One and it reaches PCA. It has taken the exact route back with which it reached the Internet. This path is known as the active path. But think about this r Four could also have forwarded the packet to R Three, and then to R One, and then to PCA. Even by doing this, the packet reaches the correct destination. However, the routes have changed. The original route was PCA to R. One to R, two to R four to Internet. The reverse is now Internet to R Four to R Three to R One to PCA. This path is known as the feasible path.

By default, when a Juno’s device performs its RPF check, it considers only the active routes to a given destination. In networks where multiple routes exist, for example, different forward and reverse path, the default behavior of considering only active routes can cause legitimate traffic to be dropped. To address this, the Juno’s device can be configured to consider all feasible paths to a destination when it performs RPF. In this mode, the system considers all routes it receives to a given destination, even if they are not the active route to the destination. In networks where the possibility of asymmetric routing exists, you should activate this option, and I’m going to show this to you how to activate it. Some important information about reverse path forwarding.

You do not need to implement RPF checking on all devices within your network. Typically, we configure only the edge device to perform RPF checking because all inbound and outbound spoofing passes through that device. Unicast RPF configuration options vary between Juno’s devices. The higher end devices usually have a lot more checks than we can configure.

Let’s now talk about fail filters. When a device running the Juno’s operating system decides that a packet has failed the RPF check, it discards the packet by default. However, if you specify an optional fail filter, the device processes packets that fail the RPF check through that filter prior to discarding them, which means the packets that are being discarded by RPF check, if we want to have some kind of processing on them, some additional processing performed on them, we can use fail filters.

In the fail filter, you can perform all the actions and action modifiers you could in any other firewall filter, including accepting the traffic despite the packet failing the RPF check. So there are certain types of traffic which do not actually pass RPF checks, but they are very critical to network operations. For that reason, we may want to configure fail filters. I’ll show you some examples on most Juno’s devices, packets from DHCP and boot P protocol fail RPF checks. The reason is these packets have a source IP address of zero zero and a destination address of two 5525-525-5255, which is the broadcast address. For this reason, these packets fail the RPF checks. These packets can be allowed with the concept of fail filters. How do we configure a fail filter? Well, you start configuring a fail filter by configuring a firewall term. By now, we know how to configure firewall terms.

So what you do is you start by giving a name to that term. You can give it whatever name you like. For example, on the screen right now, I have a term called DHCP hyphen boot P. In the from portion, I try to match the source address of zero 00:32 or the destination address of 2552 552-552-5532. If that is the case, the action is to accept the traffic. It is exactly a firewall filter, which can then be used as a fail filter. Let me show you how.

All right, I’m at the device. Let’s first enter configuration mode. First up, let me show you how to enable RPF check. All right, so what I’ve done is set interfaces female. Let’s do a question mark first. All right, so you can see that over here we have the option called RPF check. I’m going to do a question mark, and we can actually hit enter over here. That’s how you enable RPF check on an interface. We have some additional options as well. You notice that we can provide a fail filter over here, so I can do fail filter question mark.

And we can call the name of the firewall filter over here. We can also set lose mode RPF from here. Just going to erase that RPF check. We can do mode space question mark, and we can change the mode to lose mode RPF check, right? So that’s how we enable RPF check. That’s how we can change the mode of RPF, and that’s how we can use fail filters. How do we enable feasible paths? Well, that’s a different option. Let me erase this first. All right, so I’m going to start with set routing options. Set routing options. Question mark. And we’re looking for this option over here called Forwarding table.

Forwarding table question, Mark. The option that we are looking for is this one over here, unicast Reverse Path. And let’s do a question mark. Now we can see that we can specify considering only active paths or if we want to consider feasible paths as well, right? So the option is under. Routing Options forwarding table unicast reverse Path okay, everybody, so that’s it for this lecture. And that’s it for this section as well. In the next lecture, we’re going to summarize all the interesting things that we learned in section seven. I’d like to thank you for watching, and I’ll catch you in the next lecture. Thank you.

13. Summary of Section 7

Welcome back. In this lecture, we’ll summarize what we learned in section seven. Let’s begin. We started off section seven by talking about routing protocols and routing policies. Routing policies allow you to control the flow of routing information to and from the routing table. We can apply routing policies as information. Information enters the routing table and as information leaves the routing table. Policies that control how the software imports routes into the routing table are named as import policies, while policies that control how the software sends routes from the routing table are named as export policies. We then discussed about default routing policies.

Default routing policies are applied on incoming or outgoing routes or packets if there is no explicitly configured policy related to the route or to the interface upon which the packet arrives. Which means if we have not configured any explicit routing policies, default routing policies are applied on packets or routes that enter or leave the device. We also understood the default behaviors of the different routing protocols. For example, the default import policy for BGP is to accept all IP version four routes from configured neighbors, and the default export policy is to re advertise all active BGP routes. The default import policy for OSPF applies only to external routes, not internal routes, and it accepts all the routes. The default export policy is to reject everything.

The default import policy for Rip is to accept all routes from configured neighbors, and the default export policy is to reject everything. We then spoke about the building blocks of routing policies. Routing policies are composed of match conditions, actions, and terms. Match conditions are criteria against which a route is matched. Actions define what happens if all criteria match and terms are named. Structures in which match conditions and actions are defined. Match conditions can be written using firm statements and two statements from statements are used to match incoming routes, while two statements are used to match outgoing routes. Actions can be specified using then statements. Actions can be of three types flow control actions, actions that manipulate route characteristics, and trace actions. We then discussed about prefix lists.

A prefix list is a named list of IP addresses which is configured under the Edit policy options hierarchy. Prefix list can be referenced in multiple terms, in a single policy, or in different policies. We also understood that prefix list can be used with two commands prefix list and prefix list filter. With prefix list filter, we can specify a match type of exact longer or or longer on the listed prefixes. This action is executed immediately after the match occurs and the then statement is not evaluated. We then understood. Route filters.

Route filters are list of prefixes configured within a single routing policy or policy term. Unlike prefix lists, they are not reusable, but rather are specific to the policy or term in which they are configured. We then spoke about the route filter. Match Types we have exact longer or longer up to and then we have prefixed length range. We also looked at examples of each one of these. We then discussed about firewall filters. Firewall filters are used to control traffic passing through a Juno’s device. Firewall filters are stateless in nature, so each packet is examined individually.

Firewall filters can be used to do the following it can be used to restrict traffic that is designed for the routing engine based on source protocol and application. It can also be used to limit the traffic rate of packets designed for the routing engine. To protect against flooding or denial of service attacks. Firewall filters require at least one term. A term contains match conditions and actions. Firewall filters always include a default term that discards all packets that the configuration does not explicitly permit through the defined terms. With firewall filters, the order of terms is also important and can impact the results. We also understood this with an example.

We tried to create firewall filters that block talent traffic and ICMP traffic, and that’s where we understood the importance of correctly ordering the firewall terms. I hope you’ve not forgotten match conditions include the IP source address field, IP destination address field, TCP or UDP source portfolio, IP protocol field, ICMP packet type, IP options, TCP flags, incoming logical or physical interface, and outgoing logical or physical interface. So there’s a number of items against which we can match when we are defining firewall filters, firewall filter actions can fall in these categories. We have terminating actions flow control. Actions and action modifiers. Terminating actions include accept, discard, reject, flow, control. Action includes next term and action modifier includes actions like count, log, policer, syslog. Firewall filters can be applied on all interfaces, including the Lozero loopback interface. We then understood traffic policing. Traffic policing, also known as rate limiting, enables you to control the maximum rate of IP traffic sent or received on an interface. Policing employs the Token Bucket algorithm, which enforces a limit on the average bandwidth while allowing bursts up to a specified maximum value.

We understood that we can configure two rate limits for the traffic. Number one is bandwidth, which is the number of bits per second permitted on average, and number two is the maximum burst size, which defines the total number of bytes the system allows in bursts of data that exceed the given bandwidth limit. We also understood an example on how to compute this. Traffic police orders can be configured within firewall filters, or they can also be applied directly to the logical unit of a particular interface. Finally we talked about antispoofing unicast reverse path forwarding check or RPF.

Check is a tool to reduce forwarding of IP packets that may be spoofing an address. A unicast RPF check performs a route table lookup on an IP packet source address and checks the incoming interface. If the packet is from a valid path, the router forwards the packet to the destination address. However, if it’s not from a valid path, the router discards the packet. We understood that RPF can work in two modes lose mode and Strict mode. When using Lose mode RPF, the Juno’s device only checks to see if a valid route to the source exists in the routing table.

However, with Strict Mode RPF, the Juno’s device checks to see if a valid route to the source exists in the routing table and if the packet has arrived on the correct interface. Well, that’s all the topics that we discussed in Section. What next? Well, I’m coming up with a big thank you. I’m excited to see you in the next video, and I’d like to thank you for watching. Thank you.