Juniper JN0-230 JNCIA Security Associate – Monitoring/Reporting

1. J-Web

All right, welcome back. We’re now in the last section of the course, and in this section, we’re going to focus on three topics. The first one is JWeb, which we’re going to talk about in this video. We’ll then talk about two modes of logging: stream mode logging and event mode logging. And then finally, we’ll talk about Juno, the space security director. The exam blueprint also has one more topic in this section called SKY 80. But we’ve already spoken about that in an earlier section. So we’ll talk about three topics in this section, beginning with JWeb.

So Jweb is the graphical user interface of the SRX device, and it allows you to interact with the SRX device using a web browser using the HTTP or HTTPS protocol. So all along the course, we have been primarily configuring the SRX device using the command-line interface. Another way of configuring and managing the SRX device is by using the graphical user interface, also known as JWeb. So Jweb can be used for monitoring, configuring, troubleshooting, and maintaining the SRX device. And it can also be used to configure and monitor events. Before you can use JWeb, you first need to configure access for JWeb using the command line interface, meaning you first need to enable JWeb access before you can go ahead and start using it.

So first we’ll use the CLI to enable Jweb, and then we’ll log into Jweb. All right, I’m here at the terminal of the SRX device, and as you can see, I’m already locked into the configuration mode. I’m going to show you the configuration of Show System Services. So show system services, and the configuration that we are interested in is this one here called Web Management. In fact, let’s navigate to Edit System Services, and let’s do a show from here. So for web management, I’ve allowed the HTTPS protocol, but we also have the option to enable the HTTP protocol. To do that, we could use the command “Set Web Management.” Or let’s begin with the question mark “Setspace.” The keyword is web management. Configure the “web management” question mark.

And here we have the two protocols: HTTP or HTTPS. Make a note of the difference. Because HTTP is not encrypted, it should only be used on a trusted network. If possible, you should be using HTTPS, which is an encrypted connection. So if we wanted to use HTTP, we could say “Set Web Management HTTP” and have the option to execute the command. Or if you want to limit HTTP access to specific interfaces only, you could use the interface keyword and provide the interface name. By default, HTTP will use port 80, but if you want to use a different port number, you could do that with the port keyword here. Right now, we’ll set it to Set Web Management, HTTP, and we can do the same thing for HTTP. So set web management to https with a question mark. Here we have a few more options, and that’s because HTTPS supports the use of certificates.

So we see a few more options here. But we do have the option called “interface and port.” HTTPS is an encrypted connection, so it requires a certificate. We have different options here. We can use a system-generated certificate or we can import a certificate. The easiest option is to use a system-generated certificate. If I do a show here, we can see we’ve allowed HTTP and HTTPS. HTTP is going to use a system-generated certificate. What this means is that when you connect with your browser using the IP address of the SRX device, your browser will give you a warning message. And that’s because the certificate is either locally generated or a system-generated certificate. So from a configuration standpoint, to enable JWeb, that’s all you need to configure. You need to configure the protocol, and optionally, you could configure the interface and the port. Now let’s log into JWeb. All right, I’m here at the JWeb user interface. Make a note here. My browser says this connection is not secure, and that’s because the certificate is a system-generated certificate. If we click here, we can see that it’s a self-signed certificate. For now, this is okay. So we’ll say okay, and we’ll login with the username and password. All right, I’m logged in. It says I have a few pending changes from the previous commit. So we’ll close this message here. And on the left side, we have this ribbon here that has different options that you can use. So, for example, the first one is the dashboard. This provides you with a high-level overview of the SRX device. For example, here we can see the different interfaces. And here we have some widgets. So we have a widget for system identification and resource utilization. And we have some more widgets here, like login sessions, file usage, system alarms, et cetera. If you want to use these widgets, it’s really simple; you just need to drag and drop them over here, and they should automatically pop up. If you don’t need a widget anymore, simply click the cross symbol here, and that should go away. The other option available here is to monitor. This allows you to monitor the different utilisation levels of the SRX device. So, for example, here we have the option to monitor ports.

The reason you don’t see any information here is because this information requires the flash player to be enabled, which is not enabled on my local machine. Here we have the option to take a look at alarms. So any alarms found on the SRX device can be seen over here. We can also monitor events, but this requires that we set up logging on the SRX device, which is not enabled right now. Other items that we can monitor include users, device routing, class of service, and DHCP network authentication. We can also monitor VPN tunnels from here. So we can see the phase one and phase two tunnels over here. Flow Sessions will show you the sessions on the SRX device. Right now, there is no session on this SRX device. The device is not connected to any network. And we also have the option to view VLANs and a threat map. Other options are available. Device administration is available here. Over here, you can configure settings at the device level, like, for example, setting up the device, setting up user certificates, licenses, alarms, et cetera. The other option here is networking. Over here, we can configure things like ports, VLAN link aggregation, DHCP, firewall filters, net browsing, classes of service, and ETCA.

Let’s try to apply a configuration from JWeb and see what it looks like. Let’s configure a port. So I’m here in the ports configuration menu, and as you can see, I have two ports over here. Gee one. Let’s try to add a logical interface to GE. I’ll start by highlighting the port and giving you the option to edit the port. Or we have the option to add a logical interface. Let’s do that. So we’ll provide the unit number as zero. So this is going to be unit zero. We’ll add this to the untrust zone, and we’ll use this checkbox here to provide an IPV for address configuration. We could select to enable DHCP or we could provide an address configuration manually. So let’s do that. I’m going to give you the IP address 101. We have the option to change the subnet mask if we want to, but right now we’ll just leave it at the default and say okay. To commit the changes, we can use the option over here at the top. So this down arrow will be used to commit the changes.

We have choices such as committing, comparing, committing, confirming, discarding, and discarding our preferences. Right now we’ll just commit, and that’s going to push the changes to the SRX device. All right, so the commitment has been completed. Let’s look at the other options that are available. So on the left navigation menu, we’ll move on to security policies and objects. Over here, we can configure things like security policies, zones or screens, global addresses, services, dynamic applications, schedules, et cetera. The other option available here is security services. This allows you to configure things like UTM, IPS application layer gateways, SSL profiles, et cetera. And then we have a separate menu for VPN configuration. Here we can configure IPsec VPNs or manual key VPNs. And the last option available here is reporting. There are a lot of predefined reports that we can generate. For example, we have a threat assessment report, application usage, and user usage. We have excellent public speakers. This report looks very interesting. It shows you the top sources, or top source IPS by bandwidth, the top destination IPS by bandwidth, and the top source IPS by session, plus three more. You also have other reports, like the “Viruses blocked URL” report. This could be very useful to identify where your corporate users are spending more time. Other reports available include firewall events, IPSevents, top screen attackers, and top screen victims. That’s an interesting one. And then we have some more reports as well. So as you can see, everything that you can do from the command-line interface can be done from the JWeb interface. From the examination perspective, this topic is not very critical, but my recommendation is that you spend some time on the JWeb interface and get used to the layout of the different items over here.

2. Stream Mode vs Event Mode

Welcome back. Let’s now talk about stream-mode and event-mode logging. This is a very small topic, not a very important one, but you could expect about one question about this topic on the exam. So let’s talk about it. Let’s begin by talking about system logging. Juno supports the configuration and monitoring of system log messages, and we have seen a lot of this throughout the entire course. Separate log messages are generated to record events that occur on the control plane and the data plane. We haven’t spoken about the control plane and the data plane in this course on JNCIA security, and that’s on purpose because these topics are not included in the blueprint for this exam. In fact, Juniper expects you to know these topics as you start preparing for this exam. But to understand system logging, we need to talk a little bit about the control plane and the data plane. So let’s talk about it. A Juno’s device can be divided into two planes: the control plane and the forwarding plane, sometimes also known as the control plane and the data plane.

The control plane is what you see above the dotted line, and it contains the routing engine, which is the brain of the device, while the forwarding plane, or data plane, is what you see below the dotted line, and it contains the packet forwarding engine, which is the muscle of the device. These two components are internally connected using an internal link. Let’s talk about the functions of the routing engine and the packet forwarding engine at a high level. We’ll begin with the routing engine. The routing engine is the brain of the device, and it is responsible for performing important functions like protocol updates and system management. So it is responsible for maintaining the routing tables, the bridging table, and the primary forwarding table. The routing engine is also responsible for controlling the interfaces, chassis components, system management, and access to the device. The command line interface and the JWeb are thus routing engine functions. Now let’s talk about the packet forwarding engine. The packet forwarding engine usually runs on separate hardware, and there is an important reason behind this. Let’s say there is a denial-of-service attack on the SRX device. The Dos attack can cause the control plane, or in other words, the routing engine, to become unstable and even malfunction. By keeping the packet forwarding engine on separate hardware, Juniper ensures that the packet forwarding engine can continue to function and operate even if the control plane becomes unstable.

That’s the reason the packet forwarding engine is hosted on separate hardware. The packet forwarding engine is responsible for forwarding transit traffic through the device. Transit traffic is any traffic that enters through one interface and exits through another interface. So it’s the packet forwarding engine, the muscle of the device, that’s responsible for forwarding transit traffic. The packet forwarding engine receives a copy of the forwarding table from the routing engine using an internal link, which is shown in the diagram. And this is the reason the packet-forwarding engine can continue to operate even if the routing engine goes down. Because it has its own copy of the forwarding table, it does not rely on the routing engine to determine where the packet needs to be forwarded. It has its own copy of the forwarding table. The packet forwarding engine is also responsible for implementing services such as rate limiting, stateless firewall filtering, and class of service. So we’ve understood the differences between the routing engine and the packet forwarding engine. Now let’s go back to the topic that we started with, logging. There are two types of logs on the SRX device: system logs and security logs. We’re going to start by talking about system logs. Logs generated by the control plane are known as system logs. Now we know what the control plane is. So any log messages generated by the control plane are what we call “system logs.” These include events that occur on the routing platform or the routing engine. The events that occur on the control plane are sent to a process called event D on the routing engine, which is responsible for generating the system logs. An example of a system log is when an administrator logs in and generates a log message or when a commit operation has been performed. System logs can be sent to a file. It can also be sent to an external terminal or a remote host.

And this is set up in the Edit system. Syslog We’ve seen this configuration a few times in this course. The second type of log is a security log. Logs generated by the data plane, or in other words, the forwarding plane, are called security logs. These are commonly known as “traffic logs,” because it is the data plane or the forwarding plane that is responsible for forwarding traffic. So we commonly call them traffic logs. These include security events handled within the data plane. An example of this is when traffic has been denied by a security policy. Security logs are available in two formats. You can choose a text format or a binary format. Using binary format ensures that log files are efficiently stored, which in turn improves the CPU’s performance. Now we’re going to talk about the differences between event mode and stream mode. Bear in mind that we are still talking about security logs. When configured in event mode, security logs can be saved locally on the control plane. When configured in stream mode, security logs can be sent to an external host. This difference between event mode and stream mode is very, very important from the examination perspective. Make a note or grab a screenshot.

Security logs are configured under “Edit security log.” By default, logs are stored in a file called “bin messages” under the VAR log directory. Now let’s look at a configuration example. So to configure security logs, you need to be under Edit Security. You will use the command set logmode, and then you’ll specify the mode. This can be an event or a stream. You have two formats: text and binary. To set the format, use the command Setlog format binary or Setlock format text. By default, the log file name is Bin Messages, but you can override that with the command Set log filename, and then you provide your log file name. By default, logs are stored in the directory VAR log. If you’d like to override that, use the command-set log file path and then provide the path where you want to store the log files. Remember that event mode logging is also known as “on-box” logging because the logs are kept locally on the control plane, whereas stream mode logging is known as “off-box” logging because the logs are kept on a remote server. So the key takeaway from this lecture is that there are two types of logs: system logs and security logs. System logs are generated by the control plane, while security logs are generated by the data plane. Security logs are also known as traffic logs. And there are two modes that you can configure: event mode for local logging and stream mode for external logging or remote logging. And there are two formats: text and binary.

3. Junos Space Security Directory

Welcome back. It’s now time for the next topic, which is the Juno Space Security Director. Before we talk about this, I’m going to begin with a story. About five to six years ago, I was working as a firewall engineer, and one of my responsibilities was to make configuration changes on firewalls. The customers were large, meaning they had offices in multiple locations around the world, and each location would be protected by a firewall, and all firewalls would have similar configurations. So every time I had to apply a configuration change, I would have to apply the same change to all the firewalls sitting in these different locations. To apply these changes, I had two choices. For some customers, I would log into every firewall sitting in every location and then apply the configuration change. However, some of my other customers had software that would allow me to make the change all at once. The software could be used to managemultiple firewalls from a central location. So all I would do is apply the configuration changes to the management software, and from there, push the same change to all the connected firewalls in one go. Juno Space Security Director is software that allows you to do this. It’s a tool that allows you to manage multiple devices from a central location.

So as an administrator, if you have to manage multiple firewalls, you have two choices: you can login to every firewall and apply the changes individually, or you can use a centralised management software where you apply the changes to the software and then push the changes from that software to all the connected devices. Let’s talk about this in detail. Security Director is a security management application designed to enable quick creation, maintenance, and deployment of security objects and policies. It provides a centralised management interface to manage stateful firewalling (UTM), IPS applications, firewall VPNs, and network address translation. It automates the deployment of the most recent policy updates using a feature known as Policy Enforcer. It also provides detailed data access and user activity reports. This is very important for any tool that provides centralised management capabilities because you will have multiple users who will be using the tool. It also provides threat management capabilities with the ability to detect, block, and remediate threats. It has an interesting feature in that it identifies unused firewall rules, resulting in the creation of effective firewall policies.

Moving on. It supports RBAC, also known as role-based access control, allowing you to configure different levels of access for users while limiting visibility into sensitive information. This is very important for any management software because you’ll have multiple users who will be accessing the software. And it’s especially important for organisations like service provider organisations because, as a service provider, you’ll be responsible for managing devices for multiple customers. Having RBAC, or role-based access control, will allow you to create different users with different levels of access. Security devices, users’ shared objects, and policies in one domain remain inaccessible to users who do not have access to that domain. So this allows you to separate information and objects in one domain from another. This provides for customer isolation, especially for service provider organizations. security director requires a separate license. I don’t have that license, but we’ll use the Donuts documentation to see what the interface looks like. All right, I’m here at the documentation for the Security Director. This is called the Security Director User Guide. And here’s a screenshot of what the user interface looks like. As you can see, the interface looks very similar to the JWeb interface. On the left are the different menu options. And here you have these different widgets that can be included in your dashboard. As we scroll down, we can see what the other pages look like.

For example, this is the monitor page. It looks very similar to JWeb. You can monitor different items over here, such as alert logs, applications, users, et cetera. Down here, the Devices tab allows you to configure the different devices. This is where you will add or remove devices for management purposes. You also have the configure option from where you can create shared objects like policies, Nat, etc.

And then you also have an option for reporting. This is again similar to JWeb. You have these predefined reports. You can simply select any report of your choice and click “Run Now.” And you also have another workspace called Administration that allows you to configure different objects like users, logging, etc. So, to summarize, Security Director is software that provides you with centralised management capabilities. If you’re an organisation that has many Juniper devices that need to be managed, it might be worth considering management software like Security Director because it’s time-consuming to apply changes to multiple devices and it can also lead to errors. Having a centralised software like Security Director will reduce the amount of time required to configure the devices and will also ensure that changes are free from errors.