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

8. Policy Rematch

Let’s now talk about an interesting topic called policy rematch. Policy Rematch is a configuration on the SRX device that causes the revaluation of an active session when its associated security policy is modified. That means when the security policy associated with a session is modified, the session will remain open if it still matches the policy that allowed the session initially. But the session will close if the associated policy is renamed, deactivated, or deleted. In other words, if a policy initially allowed a session to be established and the policy is then modified, but the modified policy configuration no longer allows the session, the session will be dropped. The modified policy should still allow the session to remain open. This configuration is disabled by default. Now, this might sound a bit confusing, so let’s get to the terminal and take a look at a configuration example. All right, I’m here at the terminal of the SRX device, and as you can see, I’m in configuration mode, and I’m under Edit Security Policies, from Zone Trust to Zone on Trust. Let’s start with a show command over here. I have a policy called “allow SSH telnet.” It matches any source address, any destination address, and a couple of applications, Juniper’s Telnet and Juniper’s SSH.

The action is configured to permit, and we’re logging a session in it. This means this policy will allow an SSH session to go through. Now, let’s verify this. I’m going to navigate to another terminal, which is here, and this is the terminal of a trusted host, or, in other words, a host that is sitting in the trust zone. Let’s try to SSH into a server on the Internet. So I’ll use the command SSH and the username, and then the IP address; press Enter, and I’m prompted for the password. There’s the password, and I’m logged in. Now let’s go back to the SRX. Now, while we have the SSH session running, we’re going to make a change to this policy. We’re going to remove SSH from the list of applications. So we’ll use the edit command, “edit policy.” and the policy name. And I’ll use the delete command, “delete match application,” and the application name, “Juno’s SSH.” Let’s do a show. So we are no longer matching the SSH application. Let’s go ahead and commit the change and let’s see what happens to the existing session.Commit has been completed. Let’s go back to this terminal here, and we can see that the session has not been terminated. The policy no longer allows SSH. We’ve deleted the application from here, but the session is still allowed. And we can also confirm this with the command “show security flow session.” And we can see the SSH session over here. What do you think is the reason? When we talked about the packet flow on an SRX device, we understood that when a packet arrives at the SRX device, one of the first things that is checked is, “Does the packet belong to an existing session?” In this case, the answer is yes. The packet belongs to an existing session, so it takes the fast path so it does not have to go through another policy. lookup, but as an administrator, this may not have been your intention when you removed SSH from the policy. The intention was to not allow any more SSH sessions. So how do we fix this? Well, the Policy Rematch configuration can be applied to make sure every time a policy is modified it is reevaluated. The way to do that is to go up to the edit security policies arrow key, and from here we’ll configure Set Policy Rematch. So if we do a show here, we have the security policy and we have this configuration called Policy Rematch. Now to test this, let’s reset our policy to the way it was. So change the zone trust to zone untrust and the policy name, and I’ll reconfigure the application. Configure the match application. Juneau’s SSH. Let’s do a show. Okay, before we commit the change, we’re going to go back over here and exit out of the session. And if we come back over here, if we run the command “show security flow session,” we can see that the session has been cleared.

Now let’s commit the changes. So far, the commitment has been completed. Now the policy allows SSH. So let’s go back over here and reestablish the SSH session. Okay, I’m logged in, and let’s go back to the SRX device and try to remove that application again. Remove the Match Application Juno’s SSH: Before we commit the changes, let’s take a look at the existing session, which we can see over here by running show Security Flow session. And let’s also confirm that Policy Rematch has been applied. So if we do a show here, we can see the policy-rematch configuration. Now let’s do a commit, and then let’s go back to the host and see if we still have an active session. So when I pressed Enter, it worked a couple of times, but now I’m trying to press the Enter key and it doesn’t work. That means the session has been cleared. It did take about a second or two for the session to be cleared, but now the session is no longer in place. We can confirm this by going back over here, and we’ll try the command run show security flow session, and we do not have any existing sessions. So a policy rematch is an important configuration. It causes the policies to be reevaluated when any changes are made. The important thing to keep in mind is that this configuration is disabled by default on an SRX device.

9. Application Firewall

Let’s now talk about the application firewall. We’ll begin our discussion by talking about traditional security policies, the policies that we have been configuring in the past few lectures. So, traditional security policies permit or reject traffic based on layer three or layer four information. and we’ve seen this in the past few lectures. We use IP addresses and port numbers to make a decision on what traffic needs to be allowed or rejected.

While this approach can be effective, it’s also limiting, especially when dealing with evasive applications. Let me give you an example. Let’s say we are required to allow HTTP traffic from the trust zone to the untrust zone. Now, I’m sure you’ve seen this today. More applications run within a web browser. You could be playing a game, using an instant messaging app, or managing an operating system or a virtual machine within a web browser. So many applications today run within a web browser, and they are all operating on HTTP. So, if we allow HTTP, we are allowing all this application traffic to pass through the firewall. So, traditional security policies do a good job of controlling traffic, but they are also limited in their ability to look within a packet and make a decision if that traffic should be allowed or not. And that’s why we have this concept called an application firewall. Application firewalls use application identification to determine whether traffic should be permitted. Traffic can be controlled based on application signatures. Now, this is very powerful. When application firewall is enabled, the SRX device can look within the packet, identify the application that is being used, and make a decision based on that.

Think about this. You are allowing all HTTP traffic, but the SREX device is able to look within a packet, identify that this signature matches social media traffic, and block it while all other HTTP traffic is passing through, social media traffic is not allowed. Now, let’s talk about the requirements. The first requirement is that an application identification licence must be installed on your SRX device and that the application signature package must be downloaded and installed. The application signature package contains the application signatures that the SRX device will need to make a decision. Now, talking about the application firewall, we need to talk about how this feature behaves on certain older versions of Juno compared to the latest versions. You would configure the traditional application firewall if you were using a device prior to Juniper OS 18.2. If you’re using an SRX device starting with Juniper OS 18.2, you would configure the application firewall as part of unified policies. We haven’t talked about unified policies yet, but in simple words, unified policies are security policies like what we’ve been configuring so far, but they allow you to match a dynamic application. So, unified policies are security policies with the capability to match a dynamic application.

So on Juno’s devices prior to OS 182, you would configure traditional application firewall policies. And starting with Juno’s OS 18.2, you would configure the application firewall as a part of your unified policy configuration. We’ll talk about unified policies in an upcoming lecture. But for the time being, keep in mind that unified policy is a security policy that allows the use of dynamic applications as match conditions. Now let me show you the difference between these two configuration styles with a configuration example. The configuration example you are seeing now is for an SRX device that’s running Juno OS prior to 18-2, R one. So we’re looking at the show security policies, starting with zone trust and progressing to zone untrust. The policy name is Allow Web. We’re matching any source address with any destination address, and the HTTPS application’s action is configured to permit. And then we are invoking the application services, we are invoking the application firewall functionality, and we have a rule set configured here called Block Facebook. Now let’s take a look at the definition of this rule set. This rule set is defined under “Show security application firewall.” The rule set name is Block Facebook, and we have a rule configured here that matches the dynamic application called Juno’s Facebook Access.

The action is set to deny, and the default rule is set to permit. So, as you can see, the application definition is part of a separate configuration under “Show Security Application Firewall.” Now let’s see how this is configured. Starting. R 1 for Juno OS 18.2. We are under the same IR key, showing security policies from Zone Trust to Zone Untrust. We have a different policy name this time. It’s called block Facebook. Allow rest. We have similar match conditions: any source address, any destination address. We are also specifying any application. But then we are also specifying the dynamic application called Juno’s Facebook Access. The interesting thing to note here is that this is part of your security policy configuration. There is no separate definition for this application. So we are configuring this within the security policy. The action is set to reject, and we have applied a profile called Blocked Apps. Now let’s see what this profile defines. So we are under “Show Security,” and here we have a configuration called “Dynamic Application,” which has the profile name “Blocked Apps.” Under this profile, we have a redirect message of type “custom text,” and here’s the custom text configuration. So the difference is that when you’re configuring a Juno device prior to version 18.2, the dynamic application configuration is a separate section versus starting Juno OS 18 two. The dynamic application configuration is part of your security policy configuration. Now, we’re not going to look at an application firewall configuration example because this functionality has been deprecated. The application firewall functionality is now part of unified policies. So we’ll look at a configuration example when we talk about unified policies. The old functionality prior to version 18 has been deprecated. So we don’t need to look at a configuration example for that. We’ll look at it when we talk about unified policies.

10. Unified Security Policies

Let’s now talk about another interesting topic called “unified security policies.” So what are “unified security policies”? Well, these are security policies that allow the use of dynamic applications as match conditions, along with layer three and layer four information. We’ve seen how to configure security policies in some of the earlier lectures, and we’ve seen that the match conditions that we apply to our source IP address, destination IP address, port numbers, and application Now, all of that is layer three and layer four information. With unified security policies, we can also use dynamic applications as match criteria. This allows you to classify traffic using layers four to seven of information. And these are the higher layers of the OSI model.

Policy actions are applied based on the identified application. Examples of dynamic applications include things like social media traffic, shopping traffic, Facebook access, YouTube access, etc. So, along with providing source and destination IP and port number information, we can use these dynamic applications as match criteria. Now, unified security policies have two major advantages. Number one, policy creation is easier and more granular. Juno’s has a large dictionary of predefined dynamic applications. So we do not have to spend time defining these applications on the SRX device. We simply have to use them in our security policies. This makes policy creation very easy. Also, we can be very granular or very specific in terms of what we want to allow and what we want to deny. As an administrator, it provides you with great control over traffic. Here’s an example of what a unified security policy looks like. It is almost the same security policy that we configured earlier. It has a name that varies from zone to zone a policy name. But here we are using the match criteria as a dynamic application. And here’s the application name. The best way to understand unified security policies is to configure one. So let’s get to the Juno’s terminal and see how we can configure this. All right, I’m here at the Juno terminal. Now, before we can configure a unified security policy, we first need to instal application identification.

And the reason for this is that unified security policies depend on application identification. So the first thing we’re going to do is verify if we have a licence for application identification. The command for that is Show System License. And this is a command in operational mode. So here we can see that I have a licence for application identification. Let’s go ahead and download the application signature packages. The command is “Request Services.” Let’s do a question mark. The command we are looking for is “application identification,” a question mark. And we’ll use the download keyword to check the status. We’ll append the command with the status keyword. The packages are being downloaded. Let’s try one more time. It’s been a few seconds now. I’m going to try again, and we can see that the application packages have been downloaded. The next step is to instal it. To check the status, I’ll go back to the apparel and remove the last two keywords, and the command is RequestServices Application Identification Install. We’ll append the status keyword. Let’s check the status again. All right, so the application package has been installed. Now we can configure the unified security policy. We’ll enter configuration mode with the edit command, and we’ll navigate to Edit security policies. I’ll clear my screen, and let’s begin with a show command. So, from the trust zone to the untrust zone, we can see that We have a policy called Allow Web, which matches any source address, any destination address, and HTTP and HTTPS traffic.

The action is set to permit, and we have logging configured for sessions in it. Now let’s configure a unified security policy that will block Facebook access. So let’s begin the configuration. We’ll start with the edit command, editing from Zone Trust to Zone Untrust. And we’ll give you a policy name. Let’s call this one “blocking Facebook.” We need to provide match conditions. So set the match source address. We’ll set this to any set-match destination address. Following that, we will match a dynamic application set match. And I’m going to use the question mark here. The keyword we are looking for is “dynamic application.” As a result, set match, dynamic application mark. And you’ll notice we have so many options here, so we can be really specific in terms of what we want to allow. I’m pressing my spacebar key here, and I notice there are so many application definitions. Like I said earlier, Juno has a really large dictionary of predefined applications. I’ll press CTRL C here and type in Juno’s Facebook address and press the question mark. And you’ll notice that just for Facebook, we have so many application signatures that we can allow or reject specific functionality within the Facebook application. Like, look at this one here: June’s Facebook chat. So we can use this application signature to allow or block the chat functionality within Facebook. But right now, we’re going to use this one here.

The first one was called Juno’s. Facebook access. This is a signature that is used to detect requests to Facebook.com, a social networking website Controlc.and I’ll complete the application name. Juno’s Facebook access Let’s do a show. Let’s complete the policy set then. And this time we’re going to reject the traffic. Also, let’s configure logging and then log at session. Let’s do a show. The policy configuration is looking good. Now, what if I wanted to get more information about this application called Juno’s Facebook Access? For this, we can use the operational mode command. That will be done from the configuration mode. So let’s start with Run. The command is “show services, applications, identification.” Let’s do a question mark. The keyword is “application,” and we’ll use the detailed keyword question mark. And then we need to provide the application name. So in this case, we are going to provide the application name as Facebook Access. Press Enter. And here we have all the information about that application signature, like the application ID and the group to which it belong to. In this case, social networking And some tags ask what the characteristics of the application are, what the risk category subcategory is, et cetera. And what are the ports and protocols used by the application? There’s one more command we’re going to talk about here. I’m still in policy configuration mode, which you can see here. We are configuring a specific policy. And if we did set the match-space question mark, note that along with the option to specify a dynamic application, we also have the option to specify a URL category. Let’s take a look at that. Set the URL category to match? Question mark. And now we have categories of applications. For example, we can use this to match websites or applications that belong to the compromised websites list, applications that belong to the education section, or applications that belong to the entertainment type.

So we can provide specific application names, or we can also provide category names. Control C to exit. I’m going to erase that command and go one level up and perform a show over here. So here we have the AllowWeb policy, which was configured earlier. And here we have the block Facebook policy. Looking at the configuration, I just realised that we have one more thing to configure. So I’m going to enterthe policy configuration mode again. Edit policy. Facebook now the one thing we are missing here is the set application keyword. Notice here that the Allow Web policy has set application configuration, but this policy only has dynamic application configuration. It does not have the application keyword configured. So let’s do that “set application” or “set match application,” and we’ll set this to Juno’s defaults.

The reason for doing this is that Juno’s defaults group has predefined values for common applications, like the default protocols and ports used by this application. For example, this application called Facebook Access needs access to HTTP. So all those definitions are found under this application called Juno’s defaults. Now, there’s one important thing to keep in mind. Beginning with Juno OS 19.1, R 1. This statement is no longer required; it is implicitly added. But if you’re configuring this on a device that’s running Junos OS prior to version 19.1, you will need to configure the statement explicitly. I’m using Junos 19 four.So I do not need to apply this statement. It is implicitly added. Even if I leave it that way, it’s not going to be a problem. So let’s just leave it that way. Let’s go up and perform a show. Before we can test this, the last thing we need to do is reorder the policies. We know that policies are evaluated from top to bottom. This policy is configured to match any source address and any destination address, and it will permit the traffic. This means that the BlockFacebook policy will never be matched. So we need to move it above the policy called Allow Web. As a result, we’ll use the insert keyword: type PolicyPolicy name before Policy Allow Web and press Enter. Let’s do a show. It’s looking good.

Now let’s commit. And when we try to commit, note that we are getting an error message. The error message says the policy called “Allow Web” does not contain any dynamic applications or URL categories but is placed below policies that use them. This is a well-known Juno’s behavior. Here we have two different types of policies. The first policy is a unified security policy because it uses the keyword dynamic application, while the second policy is a traditional policy or a legacy policy because it does not use the keyword dynamic application. When you have a combination like this, you will see this error message. And there are two ways to fix this. The first way to fix this is to move the policy called “Allow Web” above this one. But in our case, that’s not possible because if we move that policy above this one, it’s going to match all traffic and be permitted. The second way to fix this is to convert this policy, the legacy policy, into a unified security policy by including the dynamic application keyword. Let’s do that. So the command is “edit policy” and the policyname, and we’ll use the “set match dynamic application keyword” and set this to any. By doing this, this policy also becomes a unified security policy. Pressing Enter will go up one level, and we’ll do a show. So both policies now have the keyword “dynamic application.” Now let’s try the commit command. Commit completed. And now it’s time to put everything to the test. I’m going to hop over to another machine that’s sitting in the trust zone of the firewall. I have a browser open. Let’s first try to go to Juniper Net. All right, so that’s working fine. Let’s try to go to Facebook.com.

So that opens up a search engine with results. Let’s try to click from here, and straight away we can see a message that this traffic is not allowed. Now let’s go back to the SRX device and perform some verification. Let’s take a look at the log file. We can do this from the operational mode or from the configuration mode by prefixing the run command. The command is “runshow log,” and the logfile name that I’ve configured is “traffic log.” And let’s look at the last portion of the log. So type runshow log, log file name, pipe last, and hit Enter. And here we can see that we’ve matched the policy. That’s the policy name that we configured. And here we can see that the session has been denied. So as you can see, unified security policies provide us with an additional match condition, which is dynamic application. And they also simplify configuration so much. We have all these applications that are preconfigured and all these categories that are preconfigured, so we can use them as match conditions in our security policies, and that also allows us to be very granular in terms of what we want to allow or deny. Now, before I leave you, I’ve got a couple of examples for you to practice. Configuring unified security policies Number one, try to configure a unified security policy to block all websites in the shopping category. And number two: configure a unified security policy to block the chat feature on Facebook.