Juniper JN0-230 JNCIA Security Associate – Security Policies

1. Security Policies

Welcome back. It’s now time to shift our attention to another topic known as security policies. So, in this section, we’ll look at what security policies are. How can security policies be used to control traffic passing through the network? How to configure and monitor security policies; things to keep in mind while designing security policies; objects that can be referenced within security policies And then we’ll also talk about global policies, how to activate security policies during specific time periods, how to configure intrusion detection and prevention, and how to use user information as match criteria while designing security policies. Let’s get started. We’ll start by talking about security policies. Security policies are used to enforce rules on transit traffic. The key word here is transit traffic. The SRX device can process two types of traffic: host-inbound traffic and transit traffic. Host inbound traffic is traffic that terminates on the SRX device. For example, when you ping the SRX device or log into the SRX device using SSH or telnet, the destination of that traffic is the device itself. Host inbound traffic is not controlled using security policies.

Transit traffic is any traffic that passes through the SRX device, like a user sitting in the trust zone trying to access the internet or a user sitting on the internet trying to access a server sitting in the DMZ zone. Those are examples of transit traffic. So security policies are used to enforce rules on transit traffic, meaning they can be used to decide what traffic can pass through and what actions need to take place as the traffic passes through the device. The SRX device is a zone-based firewall, so traffic always enters one security zone and exits another security zone. And that’s how we’ll configure security policies as well. We’ll set up security policies to affect traffic coming from one zone and leaving another. The combination of a firm zone and two zones is called the context. And on the SRX device, you may have multiple contexts. For example, two zones are untrusted from zone trust, and two zones are in the DMZ from zone trust. Every context will have an ordered list of policies, and policy evaluation is always performed from top to bottom.

So here’s an example: Here we have a context change from zone trust to zone untrust. And in this context, we have two policies, policy one and policy two. When traffic comes in and matches this context, meaning trust to untrust, the first policy that will be looked at for a match will be policy 1. If that doesn’t match, the next policy to be matched will be policy two, and so on. Similarly, we could have a different set of policies for a different context, like, for example, trust versus the DMZ. In this context, we have three policies. Now, let’s talk about traffic flow. Where in the traffic flow is security policy evaluated? So here’s the ingress packet. The first thing that will be checked is to see if the packet belongs to an existing session. Let’s say this packet does not belong to an existing session. So in that case, it will take this path, where the first thing to be evaluated is screens. Then we have static and destination net evaluations. Then we have route and zone lookups, and then a policy lookup happens. So as you can see, the policy lookup is pretty late in the traffic flow, and there’s a reason behind this.

Policies control traffic between a set of zones: a source zone and a destination zone. The zone can be identified by looking at the interface on which the traffic arrived. But what about the two zones? The two zones can be influenced by two configurations: static NAT and destination NET. We haven’t spoken about Nat yet, but NetOR network address translation is a mechanism that allows you to translate static Nat and destination nat can translate, or in other words, can change the destination of a packet. So imagine this: if the destination of the package has changed, the outgoing route will change. Since the outgoing route has changed, the egress interface will change. And since the Egress interface has changed, the outgoing zone will also change. That means the two zones of the packet have been updated, which is why the policy lookup occurs pretty late in the traffic flow. The SRX device does not know what the outgoing zone of the packet is until this point, which is why the policy lookup is near the end of the traffic flow. So I hope you have an understanding of why the policy lookup is delayed. Two inputs from zone and two zones are required for the policy lookup. The zone is immediately available by looking at the interface on which the packet arrived. But the two zones can be influenced by static and destination networks. So if that’s configured, the route changes, the zone changes, and that’s why the Policy Lookup has to wait until we know the zone through which the packet is exiting.

Another thing that we need to know is: how does the SRX device determine which policy to apply to a specific packet? What are the match conditions used to look up a policy? So keep in mind we are talking about a packet that is taking the first packet path, meaning the packet is not part of an existing session. If the packet is not part of an existing session, what criteria are used to identify a matching policy? That’s what we’re going to talk about in the initial policy lookup. So to look up a policy, the SRX device uses the source zone information. This is based on the interface on which the traffic arrived, or the ingress interface destination zone. This is based on route lookup source address, destination IP address and thesis after static and destination net translation. And that’s because static and destination Nat can translator change the destination IP address of a packet. If it does not make sense to you right now, don’t worry, we have a complete section where we’re going to talk about static destination and source net translation. Other criteria that are used for initial policy lookup are source port and destination port, and this is after destination net translation because destination NAT can also be used to translate the destination port. Logical System:

A logical system is a mechanism that allows you to partition an SRX device into multiple SRX devices. Imagine you are a service provider and you have three customers for whom you need to manage network traffic, and you need to use SRX devices for that. If you have three customers, you would normally need three SRX devices. But by using a configuration called Logical System, you can break up an SRX device into multiple virtual SRX devices. So a logical system is basically a configuration that allows you to partition an SRX device into multiple virtual SRX devices. Different logical systems will have different sets of policies to manage traffic. So while performing the initial policy lookup, logical system is also a criteria that is used to identify the correct policy. The next criteria is user identity, and the last criteria is the protocol or application that is being accessed. So all this information is used to identify what policy needs to be applied to an incoming packet. So, going back to the traffic flow diagram, we’ve spoken about the criteria used to match a policy for a packet that does not belong to an existing session. But what about packets that belong to an existing session? How does the SREX know that the packet belongs to an existing session? Well, for that, the SRX performs something called a “Session Lookup,” and it uses five pieces of information. The first is the source IP address, followed by the destination IP address, the source port, the destination port, and the protocol. These five pieces of information, commonly known as the “five tuples,” are used to determine if the packet belongs to an existing session. There’s one last thing that we need to talk about, and that is the stateful nature of security policies. Security policies are state-directed in nature. Let me explain that with an example. So here we have an SRX device, a workstation connected to the trust zone of the SRX device, and a server connected to the DMZ zone. Let’s say the host in the trust zone tries to access the server in the DMZ zone.

And there is a security policy that allows this traffic to pass through when the server responds back to the host. The return traffic is not subject to any security policy evaluation. Since the return traffic is part of an existing session, that traffic will be allowed without any further evaluation. And that’s because of the stately nature of security policies. So when we configure security policies, we’ll only allow traffic in one direction, and the response traffic will be automatically allowed. So those are some of the concepts of security policies. The key takeaway here is that security policies are used to control transit traffic. Security policies are also defined within a context, which means they have a firm zone and a two zone definition. Every context will have its own list of policies, and policies are always evaluated in a top-down fashion. And the other thing to bear in mindis that security policies are stateful in nature.

2. Configuring Security Policies

Welcome back. Let’s now look at some configuration examples for security policies. But before we do that, let’s talk about the actions that can be configured in a security policy. The first action is permit; when this action is configured on a security policy based on the initial policy, lookup, the packet is permitted. The reject action comes next. The behavior of the reject action will depend on the type of traffic that is received. For example, in TCP traffic, the reject action will cause a TCP reset packet to be sent. But for all other traffic types, meaning ICMP, UDP, or any other IP protocol except TCP, the reject action will cause an ICMP reset message to be sent. Third, we have the “deny” action. When this is configured, the packet is silently dropped. As a best practice, the reject action is used for internal assets or trusted assets within an organization. This allows applications to receive a reject message instead of waiting for a timeout to occur. The reject action is not configured for untrusted assets, such as those on the Internet, because the response sent by the reject action could be used for data collection. So for Internet-facing assets, the deny action is commonly used. There are a couple more actions that can be configured. The first is to count. This counts the bytes or kilobytes of all traffic. The policy allows traffic to pass through the device in both directions, both initial traffic and response traffic. The other action that can be configured is logging.

This causes traffic information to be logged. Now, there are a couple of different ways in which logging can be configured for a policy. You can configure logging at the session level in it, which means you want to log right at the beginning of a session. Or you can configure logging to occur when the session is closed, which means a log entry is generated when the session is closed or terminated. From a troubleshooting perspective, sessions in it are very useful because you will immediately see a log message when the session has been established. If you configure sessions to close, you’ll have to wait until the session is closed for a log message to be generated. Having understood this, let’s now get to the terminal and look at some configuration examples. All right, I’m here at Juno’s terminal. Let’s start with the security policies. Command. This command will show us any policies that have already been configured on the device. So far, no security policies have been configured. To configure a security policy, we can use this command, or we can use the edit command to navigate to a configuration hierarchy, and from there we can use the set command. So let’s do that. We’ll start with editing, and let’s do a question mark. “Security” is the keyword we’re looking for. The following keyword is “policies, edit security policies,” which is followed by a question mark. We need to specify a “from zone,” meaning the source zone of the traffic from that zone question mark.

I’m going to specify this as trust. The next keyword is “zone questionmark,” and my destination zone is untrustworthy. At this point, we can press Enter. Let’s do that. So now that we are in a specific configuration hierarchy, edit security policies from zone trust to zone untrust. Now we’ll use the set command. I’m going to clear my screen. Okay, let’s do a setspace question mark. The keyword is “policy question mark,” and we need to provide a policy name. I’m going to call this one “Allow web questionmark,” and we need to provide some match criteria. Let’s do that. Match the question mark. We’ll begin by matching the source address (question mark in the source address space). We can use any of these preconfigured addresses, any IPV 4 address, or any IPV 6 address. Or if we have an address configured in the address book, we can call that as well. Right now I do not have any configured addresses, so I’m just going to say any. Now we’ll set the destination address. Set Policy: policy name match, destination address, and any subsequent application matching policy name match, policy set Let’s do a question mark, and the keyword we’re looking for is “application question mark,” and here’s the list of applications that we can include.

We can include specific applications like any one of these, or we can say any, or if we want to provide multiple values at the same time, we can use the open square bracket. For this policy, I’m going to include Http and Https control C to exit Juno’s http, and I’m going to use the up arrow to repaint the command and change the application to Juno’s https. Let’s do a show. So we’ve matched the source address, destination address, and application, and it has a warning here that we’re missing the mandatory then statement. So let’s do that. Set policy, policy name, question mark, and this time we’ll use the then keyword, then question mark, and we have the options that we spoke about earlier. Permit, reject, deny, count, and log Let’s do a permit, and let’s also log this set policy, policy name, then log a question mark, and I’m going to log this session in it. Press Enter, and let’s do a show. The policy is looking good.

Now that we have matched the source address, destination address, and application, we can permit and log into a session in it. Let’s commit the changes and test our configuration. To test the configuration, I’m going to hop onto another device, which is over here. This device is sitting behind the firewall in the trust zone, so all traffic from this device has to pass through the firewall. This is a Linux machine, and to test the traffic, I’m going to use the telnet command, telnet, the hostname that we want to try, and the port number. So telnet hostname port 80, and we can see here that we get a message that we’re connected to the host name. That means the policy is working. Press CTRL-C to exit, and let’s go back to the SRX device. Let’s configure one more policy to drop all traffic that is not explicitly permitted by a security policy. By default, the SRX device will drop any traffic that is not explicitly permitted. But we can’t see that because it is an implicit denial. By adding a policy to drop the traffic, we are also able to log the traffic as well.

So let’s create a new policy. We could use the Set command here, but let’s use the Edit command to edit Policy and Policy Name. I’m going to call this “Deny all,” and we can press Enter here. So now I’m under a specific policy configuration mode. Let’s use the set command, and we’ll say set, match, source, address, any set, match, destination, address, any set, match application, any. The reason we are configuring everything as “any” is because we want to catch any traffic that is not explicitly permitted by any of the above rules. And we’ll say “set,” then “reject,” “set,” then “log” at session. In it, I’ll go one level up and do a show. So we can now see both configured policies, “allow web” and “deny all.” Now I’m going to add one more policy, and I know that now you know how to configure a policy, but there is a reason behind it. Just stay with me here for a minute. The policy we are adding now will provide access to SSH traffic. So let’s configure that edit policy by name. Let’s do set, match source address, any set match destination address, and any set match application now that we’re in specific policy configuration mode. And this time we are going to use Juno’s SSH application, and we’ll say set, then permit, and we’ll say set, then log. at a session in it. I’ll complete my command session in it.

Let’s dress it up and put on a show. So now we can see three policies: allow Web, deny all, and allow SSH. While the policies have been correctly configured, there is a problem with our configuration. Take a moment, pause the video if required, and try to identify what the problem is with our configuration. Okay, now here’s the thing: We understood earlier that within a specific context—in this case, from zone trust to zone untrust—the policies are evaluated from top to bottom. That means when there is incoming traffic, it will try to match this policy first. If that doesn’t match, it will try the next policy, which is deny all, and if that doesn’t match, it will try to move on to the next policy. But in this case, this policy called “Deny All” is a catch-all policy. It’s matching any source address, any destination address, any application and rejecting the traffic.

That means all traffic will match this policy and will not move on to the next one. So this policy, which is “deny all,” is foreshadowing the next policy, “allow SSH.” So to configure this correctly, we need to move this policy above deny all. Let’s do that. To do this, we’ll use the insert command: insert question mark. The keyword is policy. And then we need to provide the policy name. As a result, we’re attempting to elevate Allows above deny all question marks. The keyword is before the question mark, and then the policy name is “deny all,” and we’ll press Enter. Let’s do a show now. And now it’s correctly configured. So we have the Allow Web policy, allows, and deny all; let’s do a commit. Commit completed. Now, there’s one last thing I want to show you. Here I’m going to exit to operational mode, and from here I’m going to use the command “show security policies.” As we expected, we can see all the policies over here: allow Web, allow SSH, and deny all. But here we can also see the default policy, which means if traffic does not match any of the configured policies, it will be dropped because that’s the default policy. Now, this is the recommended best practice. You want to make sure that anything that is not explicitly allowed is dropped. But there is a way to change this. It is not recommended for production environments, but it’s a good idea to know the command. So let’s go back to configuration mode. The command to change the default policy is Set Security Policies. If you do a question mark, the keyword “default policy” will appear. And we can change it here to allow everything. This means if traffic does not match any of the configured policies, it will be allowed to go through.

3. Monitoring Security Policies

Welcome back. Let’s now talk about monitoring security policies. So there are four commands that we’re going to look at: show security policies, show security flow sessions, show log, and show security match policies. Let’s get to the terminal and try these commands. All right, I’m here at the Juno terminal, and I’m in configuration mode. Let’s start by showing the security policies in the configuration mode. And this is going to show all the configured policies. So at this time, we have three policies configured. The first policy is called “Allow Web,” which permits HTTP and HTTPS traffic from any source to any destination. Next, we have “allow SSH,” which permits SSH traffic. And third is the “deny all” policy, which is like a “catch-all” policy. So any traffic that is not allowed by these two policies will be caught by “deny all,” and the traffic will be rejected and logged. While we have configured logging at the policy level, we haven’t specified a log file. So let’s do that. from the top of the configuration mode. I’m going to use the command-set system syslog question mark. And there are different destinations to which we can send our log files. But for now, I’m going to use this option here, which allows you to create a log file on the local device. Set the system syslog file, and provide a name for the file. Let’s call this one a traffic log. Then we need to provide the facility. A facility is a group of similar messages. For example, the security facility generates security-related messages.

The kernel facility generates kernel-related messages. For now, I’m going to keep it very simple and use this file to log in from any facility. And then we need to provide the severity level. I’ll set this to any set system syslog file name, any facility, and any severity level. But this type of configuration will result in a lot of log messages. So we want to filter it down to specific messages only. And to do so, we’ll use the same command to change the file name of the system’s syslog file. But this time we’ll use the match keyword. This allows us to limit the log messages to only certain types. Match the question mark. And here we can provide a regular expression to match the log entries. I’m going to provide the regular expression as RT underscore flow underscore session because this is the log message that is generated when traffic flows through the device. So, change the name of the system syslog file to match the regular expression, which is RT underscore flow underscore session. Let’s g file name And let’s go back to the testing machine, which is over here. And let’s generate some traffic using the telnet hostname and port number, then press Enter. So this is now connected. Let’s go back over here to the SRX device, and I’ll go back to operational mode. And the first command that we’re going to use is show security flow session. This command will show you live traffic passing through the device. Show Security Flow Session, and we can see that the traffic complied with this policy. Allow Web is the policy’s name. This is the IP address of the machine. Ten 121, two, and that’s the IP address of the host, and that’s port 80 on Protocol TCP. So this shows us the live traffic. This command is very useful for troubleshooting purposes. It allows you to see live traffic passing through the device. Now, we also have logging configured on the device. So that means we should also see a log entry for this traffic. Let’s take a look at it. So the command is “show log,” with a question mark, and we need to specify the log file name, which is “traffic log.” And it should be right at the beginning because we used uppercase. There you go.

So show the log and the file name. And we can see that that traffic has been captured, and that’s because we used this keyword to match the traffic. So this is the source IP, destination IP, destination port protocol, which is Juno’s HTTP policy name allow web source zone, trust zone, and untrust zone. So those are two very useful commands: show security flow session and show log. The next command we’re going to look at is “Show security policies.” We’ve already seen this command earlier, but let’s take a look at it. show security policies, and this is going to show you all policies configured on the device. The last command we’re going to look at is “Show security match policies.” Here’s the keyword. And this command allows us to provide traffic information like source address, destination address, et cetera, and see which policy will match the traffic information we are providing. Let’s give it a try. Question about security match policies Mark and as you can see here, we can provide different types of information to see which policy will match that type of traffic. Let’s begin with the from zone. Make a note that this is an optional value, but we are going to provide it. So from zone trust to zone untrust, let’s do a question mark. Bear in mind that you cannot execute a command unless you see Enter as the first possible completion. So let’s provide the source IP, and I’m going to provide the IP of a host that is sitting in the trust zone. Let’s provide the source port information. I’m going to provide a random high-port number. Let’s provide a destination IP. I’m going to provide a host name. You could provide an IP as well.

Let’s provide a destination port. Let’s try port 80 (question mark). Note that we still do not have Enter as the first possible completion. That means we are still missing some information. Let’s provide the protocol information. Protocol TCP So, now that we’ve gone from zone trust to zone untrust source IP source port destination IP destination port protocol, let’s hit Enter. And here we can see that this policy matches the traffic information that we’ve provided. The policy type is allow web and the action type is permit. Here we have some more information about the policy, like the zone, the two zones, the source address, the destination address, and the application. In this case, the policy has two applications, http and https, and the associated port numbers and timeout values. Now let’s repeat that command for a different protocol. We’ll leave the source IP and destination IP unchanged. But let’s change the destination port to a highport value, and let’s change the protocol to ICMP. All right, so we’ve changed the destination port and the protocol. The protocol is now ICMP. Let’s press enter. And now we have a different result. This time, the matched policy is deny all, and the action is reject. So this is a very useful command, especially from a troubleshooting perspective, and especially if you do not have a live user to generate some live traffic so that you can match ads on the device. Using this command, we can provide a set of values to simulate and see which policy is going to match the traffic.