Juniper JN0-230 JNCIA Security Associate – SRX Series Devices Part 2

6. Interface Address Configuration

Let’s now talk about interface address configuration. We’ll understand how to configure IP addresses on an interface. Let’s get to Juno’s terminal and see this live in action. All right, I’m here at Juno’s terminal, and as you can see, I’ve already logged in. I’ll use the CLI command to navigate to operational mode. We’ll begin with the command “show interfaces.” This is the command that can be used to view summarized information about all the interfaces on the SRX device. The show interface is terse. The actual command is “show interfaces.” And if we put a question mark here, we can choose different levels of information to be shown. We can, for example, specify that we want brief information, detailed information, extensive information, or a terse output, which is a summarized output. So we’ll show interfaces, then hit enter.

And here we can see all the interfaces on this device, their administrative status, link status, and any IP addresses that are configured on that interface control C. To exit out, I’ll use the editor configure command to enter configuration mode. And I’ll first enter the physical interface configuration mode. So edit interfaces, and then give the interface name GE zero. To configure an IP address, we need to be in the logical interface mode. So we’ll use the edit command with the unit keyword, “edit unit,” and the unit number, which is zero. And now we can configure the IP address by setting the protocol family. So put a question mark in the family.

And here we have the different families that we can configure. We’ll set up INET or IPV4. Set a question mark in the family inet space. And now we have the option to configure an address. In the address, type family, followed by a question mark. And now we can provide the IP address. I’m going to provide the IP address 10 dot 1 and the subnet mask, which is slash 24. The command to view the configuration is show. So here we can see the configuration that we’ve provided. Assume there is a change in requirement. We need to change that IP address to ten one one two. Let’s give it a try. As a result, make the family Internet address 10 1 2; slash 24. If I do a show here, what do you think will be the output?

Let’s give it a try. Isn’t that interesting? The old IP address has not been replaced. Instead, we now have two IP addresses on the same interface. This is an interesting feature of Juno’s. Juno’s interfaces can have multiple IP addresses configured on them. You can designate these addresses as primary or preferred. But the important thing to keep in mind is that a Juno’s interface can have multiple addresses. So if that’s the case, how do we replace the IP address? Let’s say we wanted to replace this address with this address. How do we do that? Well, there are a couple of ways in which you can do that. The first method is to delete the address. We can delete the family IP addresses, followed by the address 1001 224. And if we do a show now, we only have one address. If we wanted to replace this address with another address, we could delete this and set a new IP address. The second way to do this is to use the rename command. So let’s start with a question mark. And here we can see that we have the rename option. Let’s give that a try. Rename it and include your family. We want to rename an address. So the current address is 101. 24. Let’s do a question mark. The keyword is “ask,” and the next keyword is “address.” And then we need to provide the new address. Let’s do a show over here. And now we can see that we’ve changed that address to a new address. So this is very important to keep in mind as you get started with Juno’s interface: Juno’s interface can have multiple IP addresses. In fact, a Juno’s interface can also have multiple protocol families configured on it. As you can see here, right now we only have the IPV4 protocol family. But we could also do this and bring the family in at six. And if I do a show, you will see that we have two protocol families configured on the same interface: IPV 4 and IPV 6. However, there’s one important thing to keep in mind about the protocol family called Ethernet switching. This one, called Ethernet switching, cannot be combined with any other protocol family. Let’s give that a try. Configure family ethernet switching. Press enter.

You would configure this protocol family when you want the interface to behave like a switch interface. We talked about this in an earlier lecture, saying that SRX devices have consolidated capabilities. They perform security routing and switching. So we can configure an interface to behave like a switch interface by setting the family as Ethernet switching. If I do a show now, you will notice we get a warning message about the family Ethernet switching, and the rest of the families are mutually exclusive. which means if you configure the family as Ethernet switching, you cannot have any other families configured on that interface. If you do not have Ethernet switching configured, you can have multiple protocol families operating on the same interface. So that’s how we configure an IP address on an SRX device. Now it’s time for you to try the configuration. Try to configure IP addresses on multiple logical interfaces, meaning one IP address on unit zero and another IP address on unit one. Additionally, try configuring IP addresses from different protocol families on the same interface unit zero. See if you can assign an IPV-4 address and an IPV-6 address at the same time.

7. Initial Configuration

The keyword we are looking for is login, so set system login question Mark and the next keyword is user question Mark and here we can provide the username. The username is a fictitious question. Mark, and now we need to provide information like class and authentication. A login class is a set of permissions that can be applied to a user by default. Juno’s has four predefined login classes. You can see them and the permissions associated with them here. And you also have the option to define a custom login class. Right now, we’ll keep things simple and assign the login class as “super user,” which provides all permissions. We also need to define an authentication method for this user. So let’s do “set system login user username: question Mark” and we’ll use the authentication keyword. And we’ll use the option “plaintext password” and provide the password a couple of times. Press enter, and that’s completed. Let’s do a system login, and here we can see the user that we configured. Notice that here you also have the option to provide a user identifier for the user you configured. You can configure that manually or leave that to Junos. When you commit your configuration, Juno will automatically generate a user ID for the user. and we can see that over here. Next we’ll understand how to configure login message and a login announcement. The command is “Set system login question mark.” We have an option here called Message and Announcement. The message string is shown before the user logs into the device, and the announcement string is shown after the user logs into the device. Let’s configure both and see the differences. Set the system login message question to “Mark,” and now we need to type in the string. Remember, this is shown before the user logs into the device.

So you could add something like a disclaimer. Let’s say all logins are monitored. Close the quotes and press Enter. And let’s also configure the login announcement. Set the system login announcement, which is shown after the user logs in, before tapping in the string. I’m going to add a slash (/) a couple of times. That will add a new line, and I will say, for support, please contact the Network Operations Center. In the end, I’ll provide a couple of new lines, close the quotes, and press Enter. Let’s commit the changes, log out of the device, and log back in to see if we can see those messages. So I’m locked out; I’ll clear my screen, and I’ll use the SSH command to log in. And here we can see the login message. All logins are monitored. Now let’s log in. And now we can see the login announcement. The white space that you see before and after the message is because of the slash (/) that we added. Let’s use the CLI command and go to operational mode. And while we’re in operational mode, let’s understand how to configure the date on the device. The date configuration is performed in operational mode.

The command is “set date.” Let’s put a question mark here, and we have a couple of options. We can manually configure the date and time or grab the date and time from an NTP server. When you use the NTP option from the operational mode, you are not creating an NTP association; that is done from the configuration mode, but here you are grabbing the time for once from an NTP server. We’ll look at both options. Let’s start with “Set Date” and provide the time manually. So we’ll provide the year, the month, the date, the hour, and the minute and press Enter. Okay, so we’ve configured the date manually. Let’s take a look at the device clock. And to do that, the command is “Show system uptime.” And here we can see the current time on the device. The time source is the local clock. This displays when the device was booted, when it was last configured, which was probably a few minutes ago, how many users are logged into the device, and the device’s uptime. Let’s also use the other option, setting the date to NTP. And now we can provide the IP address of an NTP server. I’m going to provide a domain name pool for NTP.org. If you’re going to provide a domain name, make sure you have a name server configured on the device. Otherwise, the SRX will not be able to resolve that to an IP address. I’ll press Enter, and we can see that we have grabbed the time from an NTP server. Now let’s get back to configuration mode and understand how to configure an NTP server so the device can maintain an NTP association.

SetsystemQuestionMark is the command, and I’ll use the spacebar to execute it. The keyword we are looking for is this one NTP setsystem NTP question mark, and we’ll use the server keyword, “server question mark.” And we can provide the address of the server, which is pool.NTP.org. By configuring this in configuration mode, we are going to set up an NTP association with that server. That means the SRX device can periodically synchronise with the NTP server. It’s not a one-time activity. The device will periodically synchronise with the NTP server. Press Enter and let’s do a commit. Okay, let’s verify if the device has been able to establish an association. The command is in operational mode, but we can run it from configuration mode by prefixing it with run. So run. Show NTP associations. Press enter. And here we can see that we have an association with an NTP server. Now let’s set the time zone of the device. So the command is “set system question mark.” The keyword we are looking for is timezone. Question mark. And here you have all the time zones to select from. I’m going to type in my time zone manually. As a result, change the system time zone to Europe, London. Set the system time zone to Europe, London. press enter. So that’s completed. Now we’re going to understand how to set up system services. So we’ll use the command Set System Services Question Mark And here you can define the different methods that can be used to connect to the SRX device. As a best practice, you should only be using SSH. But notice that you also have the option to set up telnet. So let’s configure SSH and show system services.

And we can see that we have SSH configured over here. If you wanted to, you could configure Telnet as well for device access, but that is not a recommended practice. There is also a configuration called “Web Management” under “Show System Services” that allows you to define the protocols that can be used to manage the device from the browser (Http or Https). As a best practice, you should only be using HTTP. But let’s take a look at the command set “System Services Web Management Question Mark,” and we have the option to configure HTTP or HTTPS. The differences are highlighted here. Http is unencrypted, while Https is encrypted. So we’ll say https, and notice that this device is going to use a system-generated certificate for the HTTPS connection. What this means is when you try to connect with the device using a browser, your browser willgive you a warning that the device certificate cannot be verified and that’s because it’s a locally generatedor a system generated certificate. You’ll also notice an option called Interface. And this allows you to configure the interface through which you want to allow web management.

The last thing we’re going to talk about is how to configure Syslog, and the command for that is setsystem. Let’s do a question mark. The keyword we are looking for is “Syslog.” Syslog stands for “System Logging.” So a Syslog definition will tell the device where the logs need to be sent. So, question mark, setsystem syslog. We have different destinations that we can configure for logging. For example, we can log to a file or to a syslog server. Right now, we will configure logging on the local device. So we’ll use the command-set-system syslog file, question mark. We need to provide a file name. Let’s call this one a traffic log. We’re going to log all traffic on the SRX device into this file called traffic log, question mark. Now we need to provide the name of the facility. A facility is a group of similar messages. For example, the security facility will generate security-related messages. The user facility will generate user process-related messages. The firewall facility will generate firewall-filtering-related messages. Right now, we’ll keep it simple and configure that for any question mark. Now we need to provide the severity level of the messages we want to log.

There are different options available over here. We’ll keep things simple and adapt this to any situation. So we are saying, “Set system, syslogfile, file name, any facility, any severity, while this configuration will work.” But you will see a lot of messages in your syslog file because we are logging from any facility at any severity level. To make sure we only see traffic-related logs in the log file, we’re going to apply a filter. So set the system syslog file, filename, traffic log, and question mark. And this time we’re going to use the match keyword. Match the question mark. And now we’ll provide a regular expression every time Juno’s device generates a log entry for traffic. You will see the keyword “RT” underscore “flow” underscore “session.” Press enter. So now we are saying we want to log from any facility with any severity, but we only want to match messages that have this string in them. This will ensure that only traffic-related logs are sent to this file called “traffic log.” So, that’s all the commands we’re going to go over as part of the initial configuration. To save the changes, let’s issue the commit command.

8. Firewall Filters

TCP and UDP source port destination port I protocol field ICMP packet type IP options TCP marks both the incoming and outgoing interfaces. Now, let’s talk about the actions that we can configure. There are three types of actions. First, we have a terminating action. Then we have nonterminating action. And third, we have a flow control action. Let’s quickly talk about these. When a terminating action is configured, it stops the evaluation of a firewall filter for a specific packet. The specified action is performed, and no additional terms are examined. Examples of terminating actions include accepting, discarding, and rejecting. Let’s look at the differences.

The accept action will cause the packet to be accepted by the system. The discard action will cause the system to silently discard the packet without sending an ICMP message back to the source of the packet. The reject action will cause the system to discard the packet and send an ICMP message back to the source. So the common thing about the discard and reject actions is that they both cause the packet to be discarded. But the reject action will also send an ICMP message back to the source address. Now, let’s talk about non-training actions.

These are used to perform actions like incrementing a counter, logging information about the packet, sampling the data, or sending information to a remote host like a syslog server. Examples include count, log, policer, or syslog. The “count” action will cause the packets to be counted. The log action will log the packet header information, the police action can be used to rate limit traffic, and the syslog action can be used to log the packet to a system log file. An important thing to keep in mind is that if you use a nonterminating action such as count or log without an explicit terminating action, the resulting terminating action will be accepted. Assume we configure a Firewall filter term with the action set to count. In this case, it’s a non-terminating action. If we configure it this way, the packets will be counted and accepted. This is because we did not explicitly specify any terminating action, so it applies the default terminating action of accepting. If we do not want to terminate the Firewall Filter action, we can use the next-term action after the non-terminating action. This means that if the next-term action is configured, the Firewall filter evaluation will proceed to the next firewall filter term.

The last action type is a flow control action. This allows the device to perform the configured actions on the packet and then evaluate the next term of the filter rather than terminating the filter. The next term in the action vocabulary is flow control action. So that’s a lot of concepts in a single lecture. The key takeaways here are that a firewall filter is a configuration that can be used to control what traffic is allowed to enter or exit the device. Unlike security policies, firewall filters are stateless in nature. That means every packet will be subject to the firewall filter if it is configured. Firewall filters are configured using terms. Terms have matching conditions and actions. Match conditions are specified using the from statement. And we have three types of actions: terminating, nonterminating, and flow control actions. And one more important thing to keep in mind is that when evaluating firewall filters, the order of the terms is important. If you do not specify any match conditions, all traffic is considered to be a match, and any traffic that does not match the explicitly configured firewall filters will match the implicit term, which has an action of “discard.” In the next lecture, we’ll apply all of these concepts to configure firewall filters.

9. Configuring Firewall Filters

Now it’s time to take all the concepts that we learned about firewall filters and apply them to a configuration. But before we do that, there are a few things to keep in mind. Number one firewall filters can be applied to all interfaces to filter traffic that is entering or exiting the SRX device. This also applies to the loopback interface. This means we can also apply a firewall filter to the loopback interface or the lo zero interface to filter traffic that is destined for the SRX device itself or the routing engine of the SRX device. Also, an IPV-6 filter cannot be applied to an IPV-4 interface, because the protocol families of the firewall filter and the interface must match from a configuration standpoint. This is how it will look under the physical interface, under the logica interface, under the protocol family. We’ll use the filter keyword, then have a couple of keywords for input and output, and this allows us to apply the firewall filter in the direction that we want.

The keyword input can be used to filter inbound traffic or traffic entering the interface, while the keyword output can be used to filter outbound traffic or traffic that is exiting the interface. Let’s configure these two examples. First, we’ll configure a firewall filter to deny inbound ICMP traffic, and then we’ll configure a firewall filter to deny all inbound telnet traffic on the SRX device. Let’s get to the terminal and see how we can configure this. All right, I’m here at the terminal, and as you can see, I’ve already powered on my lab for this configuration. I’m using a different topology. So this is the SRX device, and it has a connected host called the trusted host. All traffic from the trusted host goes via the SRX device, which is connected on interface GE. The other host, called Bastion Host, is the management host, which is the host that allows us to connect to both devices. Back over here, I’ve already logged into both devices; let’s start the configuration. I’m already logged into the SRX device, and right now I’m in shell mode.

I’ll use the CLI command to navigate to the operational mode, and then use the configure command to navigate to the configuration mode. To configure a firewall filter, we’ll use the keyword “edit firewall,” and the option that we’re looking for is this one here called “filteredit firewall filter,” which will provide a filter name. Let’s call this one “block ICMP.” Earlier, we understood that firewall filters are made up of terms, so we needed to configure a term. Let’s start with the setspace question mark, and we need to use this keyword here called term, and we need to provide a term name. I’m going to refer to this one as an “R” question mark. We’ll then use the keyword to match the packet characteristics. And as you can see here, there are so many options that we can use to match incoming and outgoing packets. For example, we can match packets by source or destination address. We can match by destination address, destination port. We can match by forwarding class-specific ICMP codes. We can also match by interface packet length port, which includes both source and destination protocols, TCP flags, TTL information, etc. For this example, we are going to use the protocol keyword because we want to match inbound packets that have the ICMP protocol. So we’ll use the keyword ICMP and set term 1 from the protocol questionmark.

So we’ve matched the protocol. Now we need to specify the action. So set term to one, and the keyword is then a question mark. And here we have different options that we can apply to the packet that has been matched. For example, we can accept the packet, increment a counter discard, apply a forwarding class, log the packet, and then move to the next firewall filter term, which we know is a flow control action. We can apply a policy, reject the packet, sample the packet, or use ETCA. Right, now we’ll configure this to discard the packet, press Enter, and let’s do a show. So we are matching the ICMP protocol, and the action is to discard the packet. The next step is to apply this to the interface. So we’ll go to the top of the configuration mode, and the interface on which we are going to apply is GE10 set interfaces (GE 10 family inet space, question mark), and the key word that we’re looking for is filter question mark, and we want to apply this to inbound packets. So the keyword is “input question mark,” and here we can see the filter name “block ICMP.”

Next, we need to commit the configuration, but before we do that, let’s try to ping the trusted host and see if we are allowed to ping or not. So I’m going to get the interface IP address first by using the command run show interfaces terse. Okay, and that’s the IP address that I’m going to ping from the trusted host. So I’m going to use this terminal here, which is for the trusted host, and from here I’m going to ping the IP address of the SRX interface, and we can see that the ping is successful. Now let’s go back to the SRX device control and exit, and let’s commit the configuration. Okay, now let’s go back to the trusted host and see if we can still ping. Hit the up arrow, and we can see that the packets are being blocked. So our firewall filter is working. Now let’s do something interesting here. Let’s go back over here and edit the firewall filter. So, change the firewall filter. The filter was called block ICMP. Let’s do a show. Now let’s change the action from discarding to rejecting. The discard action causes the packets to be silently discarded, which is what we saw here. We did not get any messages. We’ll change that to reject. So set the term to one, then reject. Let’s do a show. So that is no longer the case. Let’s commit, okay? And let’s go back over here and hit the apparel. And now we can see that we have a return message coming from the SDRX indicating that the packet is filtered. Now, one thing we should keep in mind here is that this firewall filter is very broadly defined. We are only matching packets with the protocol ICMP.

This means it will block any ICMP packets, not just those destined for the SRX device itself, but even ICMP packets destined for the Internet. So there are two ways we could have done this. We could have applied the filter to the loop back interface, which is lo 0, and that way it would only filter traffic destined for the SRX device. Or the other way to do that is to match packets that not only have the protocol of ICMP but also have the destination IP address of the SRX device. Ideally, we should apply it to the loopback interface. Talking about this firewall filter term again here, there’s one more thing that we need to configure. Remember, all firewall filters have an implicit deny at the bottom. That means any packet that does not match this term here will be automatically dropped, which means all legitimate traffic will also be dropped right now. So we’ll add one more firewall filter term to allow all other traffic. So let’s do “set term” and let’s call this “allow others.” And we’re not going to use the firm statement for this one because we want to match all packets, and we’ll set the action to then accept. Let’s do a show here and now. It looks good. So it blocks ICMP traffic but allows the rest of the traffic to go through. Let’s now configure the second firewall filter, which is to block telnet traffic.

So we’ll start with the set command, “Set term.” And this one will be known as R2 from the question mark. And this time we are going to use the destination port as a match criteria because telnet traffic is destined for port 23. So control C to exit out of the destination port. Let’s put a question mark here. We can provide the numeric value of the telnet port, or we can simply match the keyword telnet. Let’s do that. Let’s do a show here. So we are matching the destination port to telnet. This configuration is still not complete. We also need to specify the protocol we want to match. An important thing to keep in mind is that when you’re configuring firewall filters, you need to be as specific as possible. If we leave the configuration like this, it will match any IP protocol that has the destination port set to port 23. But we only want to match the TCP packet. As a result, we’ll say set term “two” from protocol. TCP show.

And now it appears that ProtocolTCP has a telnet destination port. Now we’ll take action. So set terms at two, then reject. Let’s do a show here. So this configuration is complete. However, there’s one problem. Earlier, we understood that firewall filters are evaluated in a top-down fashion. So let’s look at this. Let’s say we have an incoming telnet packet. It tries to match this filter here or this term here. It is not a match because it only matches the ICMP protocol. So it comes down to this one here and this one here matching all packets, and all packets get accepted. As a result, these terms will never match. So we need to move this term above this one. The way to do that is to use the insert keyword, “insert term.” The name of the term is R-2, and we want to move it before the term allows others. Let’s do a show. As a result, we now have Term R-1 for ICMP and Term R-2 for Telnet. Both are rejecting the traffic. And we have this term here, which accepts all other traffic. I’m also going to change the name of this firewall filter to correctly reflect what it is doing. So I’ll go up and I’ll use the rename keyword rename filter, block ICMP, to filter block ICMP telnet. Let’s do a show. This looks good. There’s only one change we need to make.

If we return to editing interfaces, the GE 10 family inet And if we do a show here, notice that it is referencing the old name and says that the firewall filter is no longer found. So let’s do filter input and provide the new name, which is block ICMP telnet. Let’s do the show. This is now looking good on interface G oneunit, with zero family in it to filter input and block ICMP telnet. The last thing to do is commit the changes. Okay, I hope you found that interesting. Here are a couple of exercises for you to try in your own lab environment. Number one, configure a firewall filter that logs and counts the number of inbound SSH packets. And number two: configure a firewall filter that only allows inbound ICMP packets from your trusted network. For example, if your trusted network is 192.168.0.1024, the SRX device should only allow ICMP packets from that network. If your trusted network is in a different IP address range, the SRX device should only allow inbound ICMP packets from that IP address range.

10. vSRX

Let’s now talk about vSRX, or virtual SRX. This is one of the topics that we need to be aware of from the JNCIA Security Examination perspective. We do not need to know the configuration of a vSRX firewall; we only need to focus on its features and capabilities. So let’s take a look at that. The vSRX Firewall is a virtual firewall that can be used in private, public, and hybrid cloud environments. It has the same features as the PhysicalSRX device, but in a virtualized form factor. Virtualization has been a trend in the industry for a few years now. Virtualized devices are being adopted by an increasing number of businesses. Vs RX fits into that.

One of the key advantages of using the vSRX is faster deployment time. We can fully configure a vSRX device from scratch within a short period of time. Let’s now talk about the vSRX features. It secures private and public cloud environments. It has the same security and networking capabilities as the Physical SRX. This includes IPsec, VPN, Net, UTMOR, unified threat management, IPS quality of service, and full routing capabilities. It also provides Rest APIs that allow you to integrate with third-party management tools. At the time of this recording, the Vsorx is available in public cloud environments like AWS, Azure, and GCP. It can also be installed on hypervisors like VMware and KVM. For the latest updates about the vSRX Firewall, I highly recommend that you check out Juniper’s website at www.juniper.net. Okay, I’m here at Juniper’s website to learn more about the vSRX Firewall. I’ll head over to Products and Solutions and then click Security.

Down here, the different firewalls are listed, and we can see the vSRX firewall. On this page, we have all the information about the vSRX virtual firewall. We can see the capabilities of the firewall. We have some documents here, such as technical documentation, product specifications, white papers, and the data sheet at the top. The data sheet contains a detailed product description and an outline of all the features supported by the vSRX Firewall. From the JNCIA Security Examination perspective, we do not need to get into the configuration of the vSRX Firewall, but it’s a good idea to know about the features and capabilities of this device. I highly recommend that you read about the features of the vSRX Firewall at least once.