Juniper JN0-230 JNCIA Security Associate – Security Policies Part 2

4. Policy Precedence

Welcome back. Let’s now talk about policy proceedings. If we have multiple security policies that have similar match criteria, which policy will be applied first? That question is answered by policy proceedings. Policy proceedings act as a tiebreaker when we have multiple policies with similar criteria. Let me show you with an example. Here we have a security policy that matches traffic from the trust zone to the untrust zone. It’s called “allow telnet.” It matches any source address and any destination address, and the application is telnet. The action is set to permit Similarly, we have another policy, but this time it’s a global policy. We haven’t spoken about global policies yet, but in simple words, global policies allow you to define security policies without defining zones. As you can see, there are no zones and only two zones defined.

We are directly matching the source address, which is any destination address for any application that uses telnet. However, the action is set to deny this time. So we have similar match criteria for both policies but conflicting actions. In this case, which policy will be applied to incoming traffic? The answer to this question is in policy proceedings.

So the first policy type to match is an intrazone policy. The second policy to match is the interzone policy. Third, we have global policies, and if none of these match, the default action is taken. So this is how it works. When the SRX device receives traffic, it first tries to identify what is the source zone for that traffic and what is the destination zone. Once it has this information, it knows which context should be used. Let’s say the incoming traffic is from the source zone “trusted” and the destination zone for that traffic is “untrusted.”

In this case, the context is trust or untrust. So now the historian knows that this traffic cannot be evaluated against intra-zone policies. So it will start evaluating interzone policies to find a match. If it can’t find a match with interzone policies, it will then move on to global policies. Let’s talk about these different policy types. Starting with intra-zone policy, this is always the first context to be matched. For an intra-zone policy, the ingress and egress interfaces must be in the same zone. For example, from zone trust to zone trust The second context is for interzone policies. This context is tried if the incoming packet does not match any intrazone context.

Two zones, for example, are untrustworthy in terms of zone trust. If this context matches, indicating that the SRX is aware that the from zone and the two zones are distinct, it will initiate the evaluation of interzone policies, as well as all policies in that context. Next, we have global policies, and this context is tried if the incoming packet does not match any intrazone or interzone context. If this context matches, all policies in the context are evaluated from top to bottom for a match. If none of the above match, the default action is taken, so this is applied if there is no matching intra-zone, inter-zone, or global policy, and the command to set the default action is “set security policies,” “default policy,” and then you can specify the default policy. So when you’re designing policies on an SRX device, it’s very important to keep policy precedents in mind. For example, if you’re trying to confirm a global policy and you want that policy to match each and every time, you’ll need to ensure that there is no similar interzone policy because if there is, the interzone policy will always match because it has more proceedings than the global policy.

5. Using Address Objects

Welcome back. In this lecture, we’ll understand how to use address objects within a security policy. In one of the earlier lectures, we learned what address objects are, what the different types of address objects are, and how they can be configured. Now we’ll understand how to use them within a security policy. Let’s get straight to the terminal and take a look at this. All right, I’m here at the SRX device. Let’s first enter configuration mode and navigate to editing security policies. We’ll use the show command to take a look at the policies. So here are a couple of policies. Allow Web, which allows any source and destination address to be used on Juno’s, http, and https. And we have a catch-all policy called DenyAll that blocks any traffic that is not explicitly permitted by any of the above policies. Now let’s enter the configuration of a specific policy. So we’ll change the policy and Policy Name from zone Trust to zone Untrust. And let’s try setting, matching, source, address, and question mark. And let’s take a look at the options available here. So we have the options that we spoke about earlier, like “any,” “any IPV 4,” or “any IPV 6,” but now we also have a couple more address objects available for selection. Let’s talk about these addresses. I’ll erase the command, go to the top of the configuration mode, and let’s do Show Security Address Book and press Enter.

So here we have a couple of address books. The first one is called trusted addresses. The address is called “Trusted Host One,” and that’s the associated IP address. It’s attached to the trust zone, which is why this address is available for selection because it belongs to the trust zone. And we are trying to match the source address, as you can see here, which is going to be from the trust zone. We are also able to see this address here, WS One or Web Server One, because that’s in the global address book, and we know that global addresses are available regardless of the zone. Now, take a note here. This address called WS One is not an IP prefix; it’s a DNS name. Now let’s reconfigure the policy to include these addresses. So, excuse me, Edit security policies from zone Trust to zone Untrust policy, and Policy name. And let’s do a quick show here. So we first need to delete this statement here. Let’s do it: remove any matches to the source address. And now we’ll use the source set match source address question mark to specify a specific address. And that will be set to one or trusted host one. We’ll also update the destination address. We’ll change it from “any” to “a specific web server only.” So, first, we’ll delete the existing configuration, then delete the match destination address and set it to set match destination address with a question mark. Now, notice here, we do not see the option called “One” because the destination address should be an object from the “Untrust” zone or from the “Global Address Book.” The Address Book is tied to an address book in the Trusted Zone, which is why we don’t see it as an option available over here. Let’s set it to WS 1. Let’s do a show. And now we are good to commit. All right, so that’s how we use an address object within IP policy. The key takeaway here is that the address object you are trying to configure should belong to the correct zone, the correct from zone, or the correct to zone. Or it can belong to the global address book.

6. Global Policies

Now we can-configure a new molar we one global policy or we can simply cumuli-zone policy. to a mow, ozone policy. Right now this policy winy zone traffic from anyone because have definition. d any zone definition. So let by providing the policy byprovidinginformation. urge zone information. Command, ” use the epiploic,” and edit global name, icy and the policy screen.  I’ll clear show. creen. Let’s do a scommand,lset space set commmark,setsplet’s station mark and let’ssmark,et match question Mark policies in doubt Mark, and the key word we’re looking for is “default policy set security.” Policy default policy dilemma Mark has the option to deny all or permit all, and we have the option to set it to deny all or permit all. By default, it is set to deny all, which is a recommended best practice. Any traffic that you want to allow through the SRX device should be allowed with an explicit policy configuration and not with the default action.

7. Schedulers

All right, now let’s talk about another interesting topic called schedulers. Imagine a situation where you need to allow or deny access only during specific times of the day or only during specific days of the week. As an example, you may only want to allow access to your contractors or your vendors on a specific day. Or, for example, you may want to block specific types of traffic during normal office hours. A configuration requirement like this can be achieved by using schedulers.

Let’s talk about it. So what is a scheduler? A scheduler is a configuration that allows a policy to be activated only during a specific time period. For example, you may only want to allow vendors access on Fridays. A configuration like this can be achieved by attaching a scheduler to a policy. The scheduler will ensure that the policy is only activated at a specific time. A scheduler can be associated with multiple policies. However, a policy can only be associated with a single scheduler. When a scheduler is inactive, the associated policy is unavailable for lookup. This is very important to keep in mind. The policy is only available for lookup when the scheduler is in an active state. Now let’s get to the terminal and see how we can configure this. All right, I’m here at Juno’s terminal. Let’s start by looking at the existing policy configuration. So we’ll navigate to Edit security policies and issue the Show command, and we can see that right now we have a policy called Allow Web, which is allowing any source address and any destination address on two applications, Http and Https, and the action is set to permit. Now let’s say we have a requirement to block Web traffic from Monday to Friday. Saturdays and Sundays are fine, but web traffic should be blocked all day from Monday to Friday.

This is a classic example of configuring a scheduler. So let’s go to the top of the configuration mode and configure a scheduler. We’ll start with the edit command. Edit the space and add a question mark. The configuration of schedulers is at the top of the configuration hierarchy. So we’ll say editors, schedulers, and question marks. The keyword is scheduler, with a question mark. And now we need to provide a name. Let’s call this Monday through Friday. Bear in mind that the scheduler only defines when the policy should be active by itself. The scheduler does not define whether to permit or reject traffic. So we are only providing a time definition within a scheduler. I’ll press Enter, and now we are in the specific scheduler configuration mode. I’ll clear my screen, and let’s start with the Set command: setspace Question Mark. Here we have the option to include specific days of the week. Or we can simply say every day. We could include individual days. Or we can simply say “daily” and exclude Saturday and Sunday, which seems like a more efficient way to configure it. So, for example, let’s do Set Daily Question Mark and say all day notice that you could provide a specific start time and you’ll also have the option to provide a stop time once you provide a start time. But for the time being, we’ll set it to all day, daily all day. And we want to exclude Saturdays and Sundays. So we’ll do setspace. Question mark. We’ll say Saturday, and then we’ll use the exclude keyword to set Saturday to exclude and Sunday to exclude, and let’s do a show. So the scheduler called “Monday to Friday all day” will apply daily between all times except Saturdays and Sundays. Now we need to configure a policy and attach the scheduler to the policy. So let’s go to the top of the configuration mode and navigate to editing security policies.

Let’s configure a new policy. So edit Zone Trust to Zone Untrust, and we’ll provide a policy name. Let’s call this “block web.” Monday to Friday Okay. Block the web Monday to Friday. Press enter. And now we are in specific policy configuration mode. I’ll clear my screen again. So, set match, source address, any setmatch destination address, any setmatch application, Junio’s Http, hit the up arrow, and change that to Https. And this time we’re going to reject the traffic. So set, then reject, then log a session in it. Let’s do a show. The policy is configured. Now we need to attach a scheduler. So let’s do setspace. Question mark. And you’ll notice we have the option here to attach a scheduler. But before we do that, let’s verify the state of the scheduler. The state of the scheduler is verified from the operational mode, but it will run the same command from the configuration mode by prefixing it with the run keyword. So run Show, Scheduler, Question Mark, Scheduler Name, and we need to provide the name of the scheduler, but I realised that we haven’t committed the change, so let’s do that. I’ll start with the commit statement. Okay, and now we’ll verify the scheduler’s state. So we’ll run Show Schedulers and press Enter here to see that we have the scheduler called Monday to Friday running all day and the state is unused. Now let’s attach it to the policy. We are right now in the policy configuration mode, which we can see over here. I’ll clear my screen, and we’ll use the command set schedulername and the name of the scheduler, which is Monday through Friday, all day. Press Enter, and let’s do a show. Okay, so we’re matching any source address with any destination address across a couple of applications. We are rejecting the traffic, and the policy will only be active on these days. Let’s commit, okay? And let’s use the same command again to see the state of the scheduler. I’ll hit the apparel a few times.

There we have the command “show schedulers,” press Enter, and now we can see that the scheduler state has changed to “active.” Now let’s try to verify this with some traffic. There are a couple of ways we can do this. We can test from a live machine, or we can use the command show security match policies that we talked about in an earlier lecture. So we’ll go to operational mode, okay, and I’m going to clear my screen, and we’ll use the command show security match policies. This enables us to simulate and validate which policy will match the Security Match policies. Let us begin by passing zone information from zone Trust to zone Trust. Then we’ll provide the source IP. The source IP address is 10 121 2. This is a host that is sitting in the trust zone, and we’ll provide the source port. I’ll provide a random high port, we’ll provide the destination IP, and we’ll provide the destination port as well. Then we’ll provide the protocol information, which is TCP, and let’s do a question mark. So we are ready to execute the command. Let’s press enter. And notice here that the action type for this policy is “permit,” which means this traffic is right now going to be allowed. So even though the scheduler is active, it’s not actually working. And we can see here that matching is permitted on the Web. It should have matched the policy Block Web, which has the scheduler on it, but it’s matching the Allow Web policy, and it’s permitting the traffic. Can you think of a reason? Well, let’s go back to configuration mode and verify this. Let’s go edit some security policies and put on a show. And here we see the two policies. And do you see why the traffic is being allowed? The reason is that this policy matches all traffic. This policy is not getting matched because it needs to be above this policy. So any policy that you configure for blocking traffic should be placed at the top. So all we need to do now is reorder the policies using the insert command. So, insert “zone trust” into “zone untrust.” Monday through Friday, policy names block web before policy allows web. If we do a show now, we can see that this policy has now moved to the top, and let’s do a commit, go back to operational mode, and use the same command again. I’m going to hit the up arrow, and that’s the command: “Show security match policies from Zone Trust to Zone Untrust source.” IP source Port destination IPdestination Port and the protocol is TCP.Press Enter. And now we can see that it has matched the “Block Web Monday to Friday” policy. The action type is reject. Also down here in the policy information, we can see the name of the scheduler.