Juniper JN0-230 JNCIA Security Associate – SRX Series Devices

1. Introduction to SRX Series Devices

Hello and welcome. Let’s begin our discussion on Juniper security with a brief introduction to the SRX series devices. The SRX series devices are high-performance devices with security, routing, and networking capabilities. In fact, it might be interesting for you to know that SRX stands for security, routing, and switching. The SRX abbreviation stands for switching. So the SRX series devices provide security, routing, and switching capabilities.

In this course, we are going to primarily focus on the security capabilities of the SRX device, which include things like the next-generation firewall, application visibility, user authentication, intrusion prevention, and unified threat management. Almost all the firewalls that are produced today are next-generation firewalls. Unlike traditional firewalls that used to regulate traffic using traditional information like source and destination, IP addresses, source and destination, port numbers, and protocol, next-generation firewalls are able to perform deep packet inspection. They are able to identify what type of traffic is contained within a packet. For example, today we are able to use instant messaging within HTTP or play games over an HTTP connection in a browser window.

So next-generation firewalls have a capability called application visibility that allows them to perform deep packet inspection, look at the payload, and identify what application or type of traffic is being requested. User authentication allows you to monitor regular traffic not only using device IP addresses but also based on who is logged into the device. So within an organization, if you move devices or switch from one device to another, Juniper still knows that it’s the same user and is able to regulate traffic based on the user information. Intrusion prevention allows you to identify and block network-level attacks. Unified threat management includes features like antivirus, anti-spam, web filtering, and content filtering. Now let’s look at the classification of SRS devices. Based on the size of these devices or the processing power of these devices, They can be classified into three types. The first are devices for small enterprises and branch offices. This includes devices like the SRX 300, SRX 302, 34345, 380, and 550 services gateways. These devices are known to consolidate security, routing,  switching, and connectivity into a small device. These devices are ideal for small offices, like branch offices. Then you have devices for midsize enterprises and data centers. And this includes models like the SRX 1500, SRX 4100 or 4200, and the SRX 4600. These are high-performance devices that are highly available and designed to protect small and medium-sized businesses. Next, you have devices for large data centres and service providers.

And this includes models like the 5405, 600, and 5800. These devices are ideal for service providers and large enterprises. Apart from these three types of devices, we also have another category of devices called the vSRX and the CSRX. The vSRX is just like your physical SRX device, but in a virtualized form factor. It stands for “Virtual SRX.” While the CSRX is a container firewall that provides visibility and security for containerized applications and microservices, I’m here at Juniper’s website, www.juniper.net. More information on the SRX series devices can also be found on the website. Once you’re on the website, head over to Products and Solutions and then click on Security. Here we can see the different types of firewalls that we spoke about. You have the SRX series firewalls and the CSRX container firewall. Click on SRX series firewalls, and you have all the classifications that we spoke about: small enterprise, midsize enterprise, and large data center. Click on any SRX device type for more information about it. Here you have all the information about that device, like its capabilities and what features it supports, and you also have the option to download the device’s data sheet.

2. Traffic flow of an SRX device

Welcome back. Let’s now talk about a very fundamental and very important topic known as the traffic flow on a Juno’s device. This topic is very critical, and a good understanding of it will help you easily understand the remaining topics in this course. Before we talk about the traffic flow, let’s understand the different types of traffic on a Juno’s device and what traffic is influenced by the traffic flow. So on a Juno’s device, traffic can be largely classified into two types: transit traffic and exception traffic. We’ll talk about the first one, transit traffic. This is traffic that enters an Egressinterface and exits an Egress interface. An example of this is someone trying to access the Internet. So here we have an SRX device, we have a host on the left side, and we have a server on the right side. Maybe it’s a server on the Internet. When the host on the left tries to access the server, that traffic goes through the firewall. So it enters an egress interface and exits an egress interface. This is an example of transit traffic. The other type of traffic is exception traffic. This is traffic that terminates on the SRX device, or, in other words, the destination of this traffic is the SRX device itself.

As an example, when you ping the SRX device or try to log into the SRX device using SSH or telnet, in this case, the destination of that traffic is the SRX device itself. So we have a host on the left. When the host tries to ping the SRX device, that traffic is destined for the SRX device, and a response comes back from the SRX device itself. That is an example of exception traffic. The traffic flow that we’re going to talk about only affects transit traffic. And here’s what it looks like. This is the traffic flow diagram. Let’s understand this step by step. So here we have the ingress packet, or a packet that arrives at the interface of the SRX device. The first thing that the SRX will check is if the packet belongs to an existing session. The answer to that question will determine the path that the packet will take. If the packet belongs to an existing session, it takes the fast path, and as you can see here, it has fewer processes compared to this path over here. If the answer to that question is no, meaning the packet does not belong to an existing session, it takes what we call the “first packet path.” Regardless of the path You will notice the first step in both paths is a screen check.

Screens are a configuration on the Sorx device that can be used to check for malformed packets. andanomalies As a result, screens can be used to protect your network and devices from common network-level attacks such as TCP Syn flood or ICMP flood. We’ll talk more about screens in an upcoming lecture. So that’s the first check that’s applied, a screen check. The configuration that controls the flow of traffic on the SRX device is a security policy. It is the security policy that determines if the traffic is allowed to pass through the device or not. You might have a question. If it’s the security policy that controls the flow of traffic, shouldn’t policies be evaluated right at the beginning? Well, the answer is yes, but the information required to look up a security policy is not available until a zone lookup is completed. So security policies control traffic between zones. Zones are representations of your network segments. So on your SRX device, you will have zones like trust zone, DMZ zone, untrust zone, VPN zone, etc. A policy controls traffic between a pair of zones; it may control traffic from the trust zone to the untrust zone or from the trust zone to the DMZ zone.

So a policy controls traffic between two zones, a source zone and a destination zone, which is why the policy lookup happens after the zone lookup. We need to know the zones involved in the flow of traffic before we can understand what policy to apply. Now, zone lookup depends on interface lookup because zones have interfaces. So we need to know the egress interface of the packet. and that information is available from a route lookup. The route defines the path that the packet will take, or it defines the outgoing interface of the packet. There are two configurations that can change the outgoing interface of a packet: static NAT and destination NAT. Nat stands for Network Address Translation. And largely, there are three types of net sources: static and destination. Out of these three, two types of net (static and destination) can change the destination interface or the outgoing interface of a packet. So if a static NAT or destination net has been configured on the SRX device, it could change the destination IP address of the packet. If the destination IP address changes, the outgoing route will change. If the route changes, the interface required to reach that route will change. So if the interface changes, the zone changes.

Because interfaces are tied to zones, if the zone changes, we may have to lookup a different policy, which is why policies are evaluated late in the traffic flow. We have a detailed discussion on security policies, but right now I’m going to show you at a high level what a policy looks like. So I’m under “edit security policies,” and here’s the command that I’ve used: show from zone trust to zone untrust. We have a policy called “Allow Web.” As you can see, policies are defined within a context with a from and to zone definition. So, before we can look up a policy, we need to know which zone the traffic is entering and leaving. Now let’s understand how a static net or destination net can influence the outgoing zone of a packet. So here we have a host on the left side of the SRX device and the Internet on the right side. Let’s say the host is trying to send a packet to the internet, and that packet arrives on the GE interface. As we’ll understand in an upcoming lecture, interfaces are tied to zones. So looking at the incoming interface, the SRX knows that the packet has arrived in the trust zone.

The SREX looks at the destination of the packet and forwards it out. GE interfaces are tied to zones, so looking at that interface, the SRX knows that this packet is destined for the untrust zone. So now the SRX knows the packet is coming from the trust zone and going to the untrust zone. It knows what policies to look up. But let’s say we have a destination named Natconfigured and the configuration looks like this: Again, we do not need to go into the details of NAT configuration; we have a dedicated section for that. But for the time being, we’ll only have a high-level understanding of it. So show the security net. This is the destination net configuration, and we are trying to match all traffic that is coming from the trust zone, destined anywhere. So all traffic entering the trust zone and going anywhere is because the destination address has been matched to zero slash zero. That means all traffic arriving at the trust zone will be matched, and after matching, we are applying the destination net, or in other words, we are changing the destination IP address of that packet. So now the packet that was destined for the internet via GE has had its destination IP address translated, and it will now go out via the STZ interface or secure tunnel interface. In other words, it will go over a VPN connection. This configuration is very common, especially for branch offices.

Branch offices commonly send their internet traffic to their corporate headquarters, and from there it’s taken to the internet. So, instead of going through GE, which was in the intra zone, all traffic now goes through TZ 0, which is in the VPN zone. As you can see, the incoming and outgoing zones have changed, and hence the policy lookup has to change. We must now consider policies with a strong zone of trust and two VPN zones. So hopefully it’s now clear why the policy lookup happens late in the traffic flow. After the policy lookup, we then apply sourcenet translation, meaning that if sourcenet is configured, we will translate the source IP address of the packet. Sourcenet does not influence how the policy is going to be evaluated because the packet has already arrived at the interface of the SRX device. Because the packet has already arrived, the SRX already knows what the origin zone is for that packet. Then we apply services like encryption or IDSPs. And then we create a session and allow that packet to go through. So this is the first packet path. If the ingress packet already belongs to an existing session, it takes the fast path. And as you can see, in the fast path, we apply screen configuration.

We then apply TCP checks, network addresses, translation, and any configured services, and the packet is sent out. But how does the SRX device know if the packet belongs to an existing session? That question is answered by looking at five pieces of information, commonly known as the “Tuple.Number one, we have the source IP address. The destination IP address is number two, the source port is number three, the destination port is number four, and the protocol is number five. These five pieces of information, or five tuples, are used to determine if the packet belongs to an existing session. The traffic flow that we understand now is dependent on whether the packet belongs to an existing session or not. So all these configurations depend on whether the packet belongs to an existing session or not. There are some configurations on the SRX device that do not depend on session information, and those are known as per-packet filters, policers, and shapers. These configurations will apply to every packet that enters the SRX device. As you can see, it is the first thing to be applied to every ingress packet. So regardless of whether the packet belongs to an existing session, every packet must go through filters, policers, and shapers, if configured. And also note that these configurations also apply to egress packets. So every incoming packet and every outgoing packet, regardless of whether they are part of a session or not, has to be applied with this configuration. Now, let’s talk about the two modes that the SRX device can be configured to operate in. We have the flow mode and the packet mode. Let’s begin by talking about the Flow mode. This is also called the session-based mode.

Packets are inspected for existing sessions in the flow mode. Like we saw in the traffic flow diagram, the SRX keeps track of session state using a state table. And this is the default mode for the SRX device. So the traffic flow looks like this: So when the host sends a packet, the SRX device will try to determine if it belongs to an existing session. Let’s say the answer to that question is no. In other words, this is the first packet of a session. The next thing the SRX will try to determine is, “Is this traffic permitted?” Is there a security policy in place that allows this traffic? Let’s say the answer to this question is yes. So the SRX device will create a session and allow the packet to pass through. When the server responds back, the SRX will ask the same question: Does the packet belong to an existing session? In this case, the answer is yes because the server is responding to a request made by the client. So the SRX device will allow the packet to go through. Now let’s talk about the packet mode. In this mode, traffic is processed like atraditional router on a per packet basis. So we don’t have the concept of sessions. When the device is operating in packet mode, each packet is individually inspected for a route lookup. The packet mode is required for services like MPLS forwarding. The important thing about packet mode is that it supports security features like IPsec network address translation, unified threat management, etc. do not work.

So many of the services that are available on the SRX device will not work. When it is configured to operate in packet mode, the traffic flow looks like this: when the host sends a packet, the SRX device will not check to see if it belongs to an existing session because it is operating in packet mode. And packet mode does not have the concept of sessions. So the only thing the SRX will check is to see if the traffic is permitted. If the answer is yes, the packet is allowed to go through. There is no session created. When the server responds back, the same check is applied. Is this traffic permitted? If the answer is yes, it is allowed to go through. As you can see, in packet mode, the SRX does not try to determine if the packet belongs to an existing session. So that’s about the traffic flow on a Juno’s device. The key takeaway here is that when you have an ingress packet on the SRX device, there are two paths that the packet can take, and that depends on whether the packet belongs to an existing session. If the answer is yes, it will take the fast path; otherwise, it will take the first path. We also understood why the policy lookup was performed late in the traffic flow. And the other key takeaway here is the two modes in which the SR SRX device can operate: flow mode and packet mode.

3. Introduction to Interfaces

Let’s now talk about the interfaces on an SRX device. Interfaces are primarily used to connect a device to a network. However, some interfaces are also used to provide a service or a specific function for the system. Interfaces can be physical or logical. A physical interface is something that we can touch, and a cable of some sort goes into it. A logical interface is an entity that has a protocol and a network address assigned to it. Interfaces can be of different types. The different types of interfaces include management interfaces, internal interfaces, network interfaces, service interfaces, and loopback interfaces. Let’s talk about each one of these, starting with the management interface, just like the name suggests. The management interface is a dedicated interface used to connect the Juno’s device to a management network. The management network is an out-of-band network, meaning production traffic does not pass through that network.

So the management interface is a dedicated interface that can be used to manage the device using an out-of-band connection. Common designations for this interface include FXB zero and Me zero. Here we have an SRX 1500 device, and as you can see, it has a dedicated management interface. These interfaces that you see here are traffic interfaces, also known as revenue interfaces. One thing to keep in mind is that not all SRX devices have dedicated management interfaces, especially the smaller devices. Like the branch SRX devices, they may not have a dedicated management interface. The next interface type is an internal interface. This is used to provide communication between the routing engine and the packet forwarding engine. A Juno’s device can be divided. into two layers. The first layer is the routing engine, and the second layer is the packet forwarding engine. Think of the routing engine as the brain of the device. It is responsible for making decisions like routing and forwarding. Decisions. While the packet forwarding engine is like the muscle of the device, it is responsible for forwarding the packets.

So these two layers, the routing engine and the packet forwarding engine, are internally connected through an internal interface. This interface is not user-configurable. In fact, it is automatically configured when the device boots up. Common designations include FXP-1 and em zero. The next interface type is the most common. It’s known as a network interface. And this is used to provide physical connections to other devices; there are different types of network interfaces. Ethernet serial asynchronous transfer mode, or ATM t1, and DS 3 are the most common. Here, I have an SRX 100 device. These interfaces that you see over here are traffic interfaces, and these are of type Ethernet. Next, we have service interfaces. These are used to provide one or more traffic manipulating services such as encapsulation, encryption, tunneling, and linking. Services. Service interfaces may be provided through a physical interface card, meaning a specific hardware unit, or a soft interface, meaning the service is provided through software. Service interfaces can be of different types, such as es, which is the encryption interface; gr, which is the generic routing encapsulation interface; and GRE IP, which is the IP over IP encapsulation interface. LSQ stands for link services queuing interface, ST stands for secure tunnel interface, and Tap stands for traffic monitoring and recording during passive monitoring.

As you can see, every type of interface here provides a specific type of service. From an examination standpoint, we do not need to remember the names of the interfaces, but generally, it’s a good idea to know about these different interface types. Finally, we have the loopback interface. The loopback interface is the identity of the device. It is an interface that represents the device itself. So any traffic that is sent to the loopback interface is addressed to the same device. It uses a common designation across all platforms, which is Lo 0. It is used to identify the device itself, and it is the preferred method to identify if the device is online. And that’s because Lubeck’s interface identifies the device itself; it represents the device. So if the loopback interface is online, the device is online. When configuring firewall filters, loopacinterfaces are frequently used. A firewall filter is a mechanism by which we can control traffic that is originating from and destined for the device. By applying a firewall filter to the loopback interface, we can control what traffic is destined for the Juno’s device and what traffic is allowed to originate from the Juno’s device. So the key takeaway from this lecture is that we have five types of management interfaces: internal interface, network interface, service interface, and loopback interface.

4. Interface Naming Convention

Let’s now talk about the interface naming convention. We’ll understand the format used by Juno to name its interfaces. Juno uses a standard naming convention for its interfaces. The majority of interfaces are designated as type FPC, or forward slash pick. FPC stands for “flexible pick concentrator.” In other words, the line card slot number PI stands for physical interface card. In simple words, it is the interface card slot number, and then we have the port number. So for example, here’s an interface named “name hen one slash zero slash one.” In this case, GE represents the type of the interface which is gigabit ethernet. FPC is the number one, Pick is the number zero, and one is the number of the port. Let’s understand this with the help of a diagram. So let’s say this represents Juno’s device. On the Juno’s device, we’ll have line card slots. On this device, we have two line card slots. So the line card slot at the bottom is FPC zero, and the one above that is FPC one.

Now these line card slots will have interface card slots. So let’s say FPC zero has two interface card slots, and FPC one also has two interface card slots. So this one over here is pick zero, and this one here is pick one. Similarly, this one is pick zero and this one is pick one. These interface card slots will have ports to provide connections. So let’s say these are four port slots. So the ports are numbered starting at zero. So you have ports 0 through 3 available. And in a similar fashion, we have numbered the other port numbers. Now let’s look at an example. Let’s see if we can find the GE interface. Take a minute, pause the video if required and try to identify which interface is GE one. Okay, let’s do it together. So we are looking for FPC zero, pick zero, and port one. In this case, the FPC is at the bottom. The line card at the bottom is FPC 0. So we’re talking about this line card here. We are talking about picking zero. This is pick zero, and this is pick one. So we’re talking about this pick pig zero and port number one. This is the GE interface in this case. Let’s look at one more example. Let’s try to identify interface GE one, two, and one. Again, take a minute. If required, pause the video and try to identify this interface. Okay, let’s do it together. GE interface one, two, one. So we are talking about FPC 1, which is this line card over here.

We’re talking about picking two. So we have pick zero, and we have pick one. Where’s pick two? Well, that was a trick question. We do not have to pick two in this case. So for this Juno’s device over here, there is no interface called GE One Two One. Okay, let’s look at one last example. Let’s look for interfaces GE 1, 2, and 3. And I promise you that this one does exist on the device. Okay, let’s do it together. So we’re talking about FPC 1, or line card 1. So this is the one we are talking about. Then we have to pick one. So this was pick zero, this is pick one, and then we’re talking about port two. So that’s the port in question GE one one two. Here’s another diagram that represents an interface naming convention. This diagram represents a Juno’s MX 80 device. So this device has two line cards. This is the first line card, or FPC 0. And this is the second one, which is the FPC one. And here we have four picks: pick zero, pick one, pick two, and pick three. And here we can see that the interfaces are labelled from zero all the way up to eleven one line. The last thing to keep in mind is that not all interfaces follow the naming convention. For example, the Lubeck interface is always represented as lozero. Some other examples include the Ae interface, which is the aggregated Ethernet interface; oras, which is the aggregated Sonnet interface; and VLAN, which is the VLAN interface.

5. Interface Properties

Let’s talk about interface properties. We’ll understand the different properties that we can configure on a Juno’s interface. But before we talk about interface properties, we need to understand the different portions or parts of a Juno’s interface. A Juno’s interface can be divided into two portions. You have the physical portion, and you have the logical portion. Physical properties are configured at the physical interface level, while logical properties are configured at the logical interface level. If you’ve used equipment from other vendors in the past, this may sound different, but trust me, you’ll get used to it very soon. So it’s important to keep in mind that a Juno’s interface has two parts: a physical part and a logical part. Now let’s talk about the properties. Physical properties include things like mode, which means do you want the interface to operate in full-duplex or half-duplex mode? Then we can configure the speed. Do we want it to operate at 100 Mbps or 1 GBPS, and so on? Then we have MTU, which is the maximum transmission unit, and this value varies from two, five, six, or 9192 bytes. MTU is the largest packet size or frame size that can be sent over a network. Another physical property is encapsulation, which includes types like PPP, which is a point-to-point protocol; frame relay; PPP over Ethernet; et cetera. Talking about logical properties, we have the protocol family, which can be inet for IPV, four inet six for IPV, six ISO, MPLS, or Ethernet switching.

An interesting thing to note is that “Address” is a logical property. That means an IP address is configured on the logical portion of the interface, not the physical portion. We can also configure VLAN tagging as an alogical property, and we can also configure things like firewall filters or routing policies. Now let’s get to Juno’s terminal and take a look at this. All right, I’m here at a Juno terminal, and I’m going to be using an online lab. I’ve already started my lab, and here are my credentials, so I’m going to log into the lab. First, I’ll log into the terminal with the terminal username and password, and from there, I’ll connect to my SRX device. SSH username is the command. At IP address, press Enter and that’s the password and I’m logged in. When you log in as the root user on an SRX device, you are automatically taken into shell mode. From the shell mode, we can go to the operational mode using the CLI command, and from the operational mode, to go to the configuration mode, we can use the configure command or the edit command. So now we are on the configuration board. Let’s try to configure an interface. We can do it with the set command or with the edit command.

So let’s use the Edit command, and then let’s start with a question mark. We are trying to configure interfaces so that control C can exit out and edit interfaces, and then I’ll provide the interface name. In this case, the interface name is Gest Enter.

So I’ve entered this configuration mode of “edit interfaces.” Any configuration that we perform at this level is the physical interface configuration. The command to configure is “set space question mark.” And here we can see all the different properties that we can configure. For example, we can set a description for the interface, we can disable the interface, we can configure encapsulation, and we can configure the link mode, which is half or full duplex. We can configure a Mac address and provide an MTU value, which is the maximum transmission unit. We can configure the speed of the interface—I’m going to hit the space bar over here—and we can also configure VLAN tagging. One thing to keep in mind is that VLAN tagging at the physical interface level is just telling the SRX whether we want to enable VLAN tagging or not. The actual tags are configured at the logical interface level. So here we are just enabling support for VLAN tagging. Now let’s configure the logical interface. To do so, enter the logical interface using the edit command edit and; the keyword is unitso edit unit, followed by the unit number.

The first unit number starts with zero. So we’re now configuring interface GEzero, unit zero. We can see the properties that can be configured if we do a set space question mark over here. For example, we can configure the bandwidth, set a description, disable the interface, and set the protocol family. I’ll press the spacebar here. We can also set the VLAN ID and the VLAN tags. Now you might be wondering: where is the address configuration? Well, the address is configured after you set the protocol family. So for example, we can do “set family question mark,” and let’s say we want to configure IPV 4. The keyword would be inet set family inet question mark, and now we can provide the address on that interface. As a result, address is a logical property. We can configure a firewall filter, a traffic policer, and an RPF check, which is an anti-spoofing mechanism. Over here, we also have DHCP client configuration. So to summarize, the properties of a Juno’s interface can be configured at two levels. You have physical properties, and then you have logical properties, which are configured under the logical interface, which is identified with a unit number.