Juniper JN0-230 JNCIA Security Associate – Security Objects

1. Security Zones

Welcome back. Now we’re going to move into the second section of the Gncia security exam curriculum. In this section, we’ll focus on security zones, host inbound traffic, address objects, application objects, and screens. Let’s start with the first topic, security zones. So what is a security zone? Well, a security zone is a logical entity that you configure on your SRX device and that is used to designate segments of your network. Interfaces are then associated with security zones. This allows you to logically group interfaces with different security requirements.

So interfaces with identical security requirements can be grouped together into a single security zone at a minimum. To control traffic, you’ll need two security zones, basically to protect one segment of the network from the other. Let’s further understand security zones with a scenario. So let’s say we have an SRX device, and on this device we are going to configure three security zones: trust, DMZ, and untrust. The trust zone contains trusted devices, like workstations, that belong to your employees. The DMZ zone contains your servers, like your DNS server, your web server, and your mail server. And the untranslated zone represents the Internet. Think of this from a security perspective. Do all of these zones have the same security requirements? The answer is no. And that’s because these zones have different types of devices associated with them. Talking about the traffic flow, think about the trust zone.

The trust zone needs to have outbound access to the DMZ and to the untrust zone because users in the trust zone may need to access the server sitting in the DMZ zone, and they may also need to access the Internet. Now look at it from the DMZ zone’s perspective. The DMZ zone needs to allow inbound traffic from both the trust zone and the untrust zone because users on the Internet may also try to connect to the servers. So clearly, we can see that different segments of your network have different security requirements. And that’s why we configure zones. A zone is simply a representation of a segment of your network. When traffic passes from one security zone to another, it is subject to security policies. So, for example, we can configure security policies to regulate traffic from trust to DMZ, from trust to untrust, and from DMZ to untrust. Now let’s talk about the components of a security zone. A security zone contains security policies, which are rules that regulate traffic. A security zone can also contain screens. Screens are configurations used to block common network-level attacks. Next, we have address books. And just like the name suggests, an address book is a collection of addresses found within a zone. Then we have interfaces. An important thing to keep in mind is that an interface can only belong to one security zone, while a security zone can have many interfaces. TCP reset is the final component. Let’s talk about this.

So let’s say we have a host and the SRX firewall, and the host is trying to establish a connection to the firewall. This is a TCP connection. So we’ll have the TCP three-way handshake. The first packet will be sent by the host, and that is a sin packet. The SRX device will respond back with a synagogue, and the last packet will be sent by the host with the acknowledgement. When three packets are successfully exchanged, the devices are set to be in a TCP connection. But think about this for a minute. Let’s say the host, instead of sending a synpacket, sends a synac packet as the first packet. Clearly, this does not look correct. A legitimate connection will always start with a Sin packet, not a Synac packet. So when you have the TCP reset feature configured on the zone, the SRX device will drop any traffic that does not belong to an existing session, like this one here. This packet does not belong to an existing session, and it does not have the Sin flag set. So any traffic that does not belong to an existing session and does not have the Syn flag set will be dropped by the SRX. If you have the TCP reset feature configured from a security standpoint, this is an important feature to enable because all TCP connections should start with the Sin packet. The other type of zone that you can configure on an SRX device is known as a functional zone. This type of zone is used for special purposes, like hosting the management interface. Currently, the only supported functional zone type isthe management zone, also known as Mgt.

So what’s the purpose of using a functional zone? Well, when you add an interface to the management zone, which is the only supported functional zone at this time, it allows the interface to be used for out-of-band management purposes. Let me explain this to you with a picture. So here is a picture of a Juniper SRX 1500 firewall, and you can see that this firewall has a dedicated management port. This is used for out-of-band management of the device. But when we look at smaller devices like BranchA Syrix devices like this one here, this firewall does not have a dedicated management port. It has a console port. And all these ports over here are traffic ports or revenue ports. It does not have a dedicated management port. By adding a port to the functional zone or the management zone, we can designate that port for out-of-band management purposes. This is very important to keep in mind from the examination perspective. Now, let’s get to the Juno’s terminal and see how a zone is configured.

Okay, I’m here at the SRX device. I’m going to enter configuration mode with the Edit command. And let’s start by looking at the zones already configured on this device, showing security zones. And here we can see that a couple of zones have been configured. This one is trust and this one is untrust, and we can see the components of the zone. TCP reset, for example, is configured on both of these zones. We have a screen configured in the untrusted zone, and this is to protect the device from attacks that originate from the Internet. Then you have interfaces, and we can see here that there’s one interface added to this zone, the trust zone, and one interface added to the untrust zone. The remaining two components, security policies and address books, can be seen by using the command “Show Security.” I’ll press enter. And here we can see that we have an address book called Trusted Addresses that is attached to the trust zone. We’ll talk more about configuring an address book in an upcoming lecture.

And if I scroll down here, we can also see the security policies. This policy here is configured from the trust zone to the untrust zone. Now let’s see how we can configure a new zone. The command is simply “set security.” And let’s start with a question mark. The keyword we are looking for is zones. Set security zones. Question mark. And here we can see the two types of zones: security zones and functional zones. Let’s configure a security zone. So set up security zones. Security Zone and then we need to provide the name of the zone. Let’s call this one the DMZ. And now I can press Enter. The zone has now been created, but a zone by itself is of no use unless we attach an interface to it. So let’s do that. Set security zones security zonename of the zone, which is DMZ, is the command. And then we’ll use the keyword “interfaces.” And from here, we can attach an interface to that zone. As an example, let’s attach FE 2. Let’s do a show.

Show Security Zones, and we can see the zone we created, security zone DMZ, which has only one interface configured. Now let’s see how to configure a functional zone. Set security zones with a question mark is the command. And the option we are looking for is this one. Question mark in the functional zone. And as we understand it, currently the only supported functional zone type is the management zone. Management question Mark, and we can associate an interface here with a question mark. And now we can associate an interface with the management zone. This will configure the interface to be used as an out-of-band management interface. For this configuration, I’m going to include Fe 7. Let us demonstrate security zones. Okay, so here we have the functional zone, and it has one interface, FE 70. When the changes are committed, this interface will be marked for out-of-band management purposes only.

2. Host Inbound Traffic

Let’s now talk about host-inbound traffic. We’ll understand what host inbound traffic is and how this can be used to control traffic that is arriving at the SRX device. So, what exactly is host inbound traffic? Well, it is traffic that is directed to the SRX device itself. It allows you to control the type of traffic that can reach the device from interfaces bound to that server own. So host inbound traffic is a mechanism by which you can control traffic that is destined for the SRX device itself, or, in other words, traffic that terminates on the device itself.

It’s important to keep in mind that host-inbound traffic is not used to control transit traffic, or traffic that enters from one interface and exits from another interface. That type of traffic is controlled using security policies. But hosting inbound traffic allows you to control what traffic is allowed to terminate on the device itself. An example is ping traffic when you try to ping the SRX device or SSH traffic when you try to log into the device using SSH. Now let’s get to the terminal and see how we can configure this. All right, I’m here at the terminal of the SRX device. I’m going to enter configuration mode, and let’s take a look at the trust zone configuration. Display security zones and trust in security zones. Host inbound traffic is configured under the zone. Show security zones, Trust security zone, and you can see we have a host inbound traffic configuration here. Now, there are two types of host-inbound traffic that we can configure.

The first one is system services, and the second one is protocols. Let’s take a look at the options available under these configurations. So let us establish security zones, security zones. Trust The keyword is host inbound traffic, and if we put a question mark here, we can see system services and protocols. Let’s start with system services. If we put a question mark here, we can see all the different types of system services that we can allow. So, for example, we have SSH, telnet, SNMP, HTTP/S, DNS, FTP ping, NTP, et cetera. Or we can also use the all keyword, like I’ve done here, to allow all traffic under that category. Similarly, let’s take a look at protocols. Set security zones, trust, host inbound traffic protocols, and a question mark. And here are the various protocols that can be allowed inbound on that zone. For example, we have BGP, IGMP, OSPF, Rip, etcetera here as well, and we have the option to include all of them. Now, I’m not going to configure this because I already have it configured. Let us demonstrate and trust in security zones. And as you can see here, we already have the configuration.

Now notice here that I do not have ping configured in the trust zone. Now let’s try to ping the SRX device and see what happens. So on this window, I’m going to ping 109.216.1811, and that is the IP address of the interface that is attached to the trust zone. If I press Enter here, you’ll notice that I’m not able to ping the IP address, and that’s expected because ping is not allowed as a system service in the trust zone. Let’s go ahead and add that the command configures security zones, security zone trust, host inbound traffic, a question mark for system services, and ping. Let’s commit. Okay, commit is finished. Let’s now go to this tab over here and try to ping again. We can see that we are getting responses when we ping 192, 160 at the same time because we allowed ping as host inbound traffic on the trust zone. Now let’s go back over here and let me show you something interesting. Let’s do Set security zones securityZone Trust this time. and instead of configuring host inbound traffic, let’s go to the interface interfaces.

And the interface that’s already configured on the zone is this interface, and we can see that over here at fe zero, zero, one, dot zero. So let’s do that: fe zero, zero, one, dot zero, and if we do a question mark here, notice we can also configure host inbound traffic here. That is, host inbound traffic can be configured under the zone or the interface connected to that zone. Let’s try this host’s inbound traffic question mark. Let’s do System Services, question mark, and this time I am going to allow the SSH service. So if we do show security zones, security zone trust will notice that we have host inbound traffic configured directly under the zone, which allows SSH, HTTP, and ping. And we also have host inbound traffic configured under the interface that belongs to that zone. Furthermore, this host and boundtraffic configuration only supports SSH. Let’s make it official. And now let’s go back to this tab over here and try to ping the same IP address: 192.168.1.1, the IP address of the trust interface. If I press Enter here, you’ll notice I’m no longer getting any responses. What do you think happened over here? Let’s go back.

As can be seen, ping is already permitted as host inbound traffic on the trust zone. If that’s the case, why are we not able to ping the interface? Let’s talk about it. Host inbound traffic can be configured at the zone level, in which case it affects all interfaces in that zone. Or it can also be configured at the interface level, which is what we just did. When you configure host inbound traffic at the interface level, that will override the zone configuration, and that’s the reason ping stopped working. So back to the terminal over here. As long as we do not configure host inbound traffic on the interface, it will use the host inbound traffic configuration of the zone. As soon as you configure host inbound traffic on the interface, it will override the configuration in the zone. And clearly, we can see that the configuration under the interface does not allow ping. So with this type of configuration, it will only allow SSH on that interface but not allow HTTP or ping, which are configured under the zone. Now, let me ask you a question. Let’s say we configure it this way. set security zones trust interfaces for security zones, Fe 20 I’m going to hit the up arrow a couple of times to show security zones, security zones, and trust zones.

So now we have a couple of interfaces, FE 10 and FE 20. Can you identify what host inbound traffic will be allowed on this interface? Well, when you do not configure host inbound traffic at the interface, it will automatically pick up the configuration from here, which is under the zone. All right, I have a couple of exercises for you to try on your own. The first one in the trust zone should configure host-inbound traffic so that only one interface allows SSH and ICMP, while all other interfaces in the trust zone allow SSH, ICMP, HTTP, and HTTPS. So only one interface in the trust zone should allow SSH and ICMP, while all other interfaces should allow SSH, ICMP, HTTP, and HTTPS. So let’s say you have a zone configuration like this that has five interfaces in it. One way to accomplish this is to apply specific configurations to the remaining four interfaces and a separate configuration to the first interface. But that’s not the best way to do it. Ideally, we’d like to apply a single configuration to that single interface because it has a unique requirement, and then have all of the remaining interfaces grab the configuration from a central location. The second exercise is to configure host inbound traffic on the untrusted zone so that all interfaces allow inbound BGP traffic. So go ahead and power up your lap and try this configuration on your SRX device.

3. Address Objects

Welcome back. Let’s now talk about the different types of address objects that you can create on an SRX device. We’ll first start by talking about an address book. Think of an address book like a phone book. A phone book contains the contact information for people you know. Similarly, an address book is a collection of addresses and address sets that are reachable by the SRX device. So what are an address and an address set? Well, addresses are named objects that represent IPV-4 addresses, IPV-6 addresses, wildcard addresses, or DNS names. And an address set is a collection or group of addresses. So an address book is a container for addresses and address sets. By default, on an SRX device, you will have an address book called Global. You can create other address books on the SRX device and attach them to individual zones. The global address book is not attached to any security zone, but if you create any other address books, they must be attached to a security zone.

Address objects defined in one zone cannot be used in another. For example, if you define an address object in an address book that is attached to the trust zone, those addresses cannot be used in the untrust zone. And that’s because the address book in which the address is contained is tied to the trust zone. But that’s not the case with addresses defined in the global address book. When you define addresses in the global address book, they can be referenced across any of the zones on the SRX device. Let’s now talk about the different types of address objects that you can create.

The first is the IP prefix. Then we have an IP range, an aDNS address, and a wildcard address. Let’s look at examples of each of these, starting with the IP prefix. Here are some examples. Here we have an IP prefix object called Internal Land, and it references the address 10 00:16. We have another address object called Internal Land Two, which references 190 to 160 at ten 00:24. We can also use a 32-bit subnetmask to represent a specific host. For example, we have an IP prefix object called DHCPServer, and it references the address 101 100:32. In this case, we are referencing a specific host. An IP prefix object can also represent an IPV6 address. For example, here we have an IP prefix object called “Public DNS Server,” and it references an IPV6 address. The second type of address object is an IP range. For example, we have an address object called Internal Servers that has an IP range of 192–1681. Dot 10, 190, 168, and one dot 20. Here’s another example: an IP range object called Webservers that represents 201-1 to 201-10. Now let’s look at examples of DNS addresses. We have an address object called Update server that points to Update Microsoft.com.

Another DNS address object called NTPServer is present here, pointing to pool NTP.org. If you plan to use DNS address objects on your SRX device, make sure you have a name server configured. Otherwise, the SRX device will not be able to resolve these DNS addresses to IP addresses. Here’s another example of an address object called www dot Juniper.Net that points to www dot Juniper.Net. remember, the address object name is just a placeholder, so we can name it the way we like. For example, at www.dot-juniper.net, the next address object type is Wildcard Addresses.

These address objects are similar to IP prefixes in that they have an IP address and something that looks like a subnet mask. But there’s a small difference here. It denotes a wild card address. The Wildcard Mask, for example, is ten, and 5255-025-5255 is the Wildcard Mask, which tells the SRX device which parts of the IP address should be examined and which should be ignored. The portion that has the zero in the WildcardMask is the one that the SRX will ignore. So you could replace that with ten stars at 00:50. So this wildcard address would match any IP address in the format 10 x 00:50. The Wildcard Mask is used to instruct the SRX which bits of the IP address should be considered and which ones should be ignored. The second octave, which is zero, tells the SRX that the second octave of the IP address should be ignored. Here’s another example. 192, 106, 8010, 255, 255-0255 In this case, we are telling the SRX device to ignore the third octave of the IP address. So this matches any IP address of the format 190 to 168 x 10; two, five, five, and zero are not the only options that can be used with a Wild Card mask. In fact, we can use any power of two to denote what should be ignored. For example, here I have eight powers of two to denote one octet of the Wild Card Mask. So if we put one against each of these eight bits, we get two five five. And if we put a zero against each of these bits, we get a zero in the Wildcard Mask.

So zero means that the octave of the IP address should be completely ignored, while two five five means that the octet should be considered, which gives us an address like this: 190 to 168 x 10, but we could have only a few bits of the Wildcard Mask turned on. For example, if we only place a one against the first and second bits, we would get a WildCard Mask that looks like 255-255-3255 because we only placed a one against the last two bits. In that case, the corresponding octave of the IP address should ignore the first six bits because they are set to zero. Only the last two bits are set to one. So the purpose of a Wild Card Mask is to tell the SRX device which bits of an IP address should be considered and which ones should be ignored. The important thing to keep in mind is that 2, 5, and 0 are not the only options. With a Wildcard mask, we can turn on fewer bits, which means that all other bits of the wildcard mask are ignored. Now let’s talk about predefined addresses on an SRX device. There are three predefined addresses. The first is Any, and this will match any IP address, including IPV 4 and IPV 6. The second predefined address is any IPV 4. This will match any IPV4 address. The third is any IPV-6 address, and this corresponds to any IPV-6 address. So the key takeaway from this lecture is that an address book is a container for addresses and address sets. Addresses represent objects such as IP prefixes, IP ranges, DNS addresses, and wild card addresses. There’s a default address book called Global, which is not attached to any zone. But we can create additional address books, and they must be attached to a zone before they can be used.