Chapter 3. SRX GUI Management
In the beginning, there was the command line. At the time, the small single line of text that was printed out on a Teletype was the greatest evolution in human–computer interaction. If you showed this to the average six-year-old, she might play with the paper and laugh. However, give that same child one of today’s smart phones and she will cruise the Internet on it as an expert. This small story tells us that the user interfaces for the world around us have changed dramatically over the last 50 years. Today, the focus on usability and the design of an interface is truly an art form. Unfortunately, the SRX does not have a user interface that is so easy a six-year-old can use it. It does, however, have a series of tools that do simplify many of the management tasks.
The SRX has several different GUI tools that administrators can use to maximize the effectiveness of their management. The SRX has an on-box web management console called J-Web. J-Web originated with the J-Series router back in late 2004. From there it has been molded and developed into the tool it is today. Because managing each device individually would be impossible, Juniper also offers several solutions to simplify the management of dozens of devices.
In this chapter, we review all of the available options for managing an SRX using a GUI. We take a look at the various management platforms and the best practices for using them. Because each platform has lots of depth to it, this chapter is meant as an overview to the various platforms and not a complete guide.
Finally, an important item to note about GUIs is that they are always evolving to meet the needs of the future. Because of this, screens that are shown in this chapter might be drastically different by the time you see this book.
J-Web: Your On-Box Assistant
For most of your Junos adventure, you will be working with or handling the results of the CLI. However, whereas the command line is a great tool to look at a device from the 10-foot view, often enough you need to see the bigger picture from a bit farther out. This is where our journey begins. J-Web is the on-device GUI management tool available on the SRX. Unlike the M/MX/T Series, which require a separate package and license, the SRX software installation includes the J-Web tool. By default, J-Web is enabled on most SRX devices. To learn how to enable the GUI tool on the SRX, please review Chapter 5.
The goal of J-Web is to reduce the administrator’s effort spent performing various tasks. That sounds like basic information, but it is important to keep this in mind when using J-Web. It is not meant to solve all of your potential management issues, but it is a tool in the fight toward a better configuration.
To get started with J-Web, you must log in. The best practice is to always use an HTTPS or SSL secured connection. This will protect your login credentials as well as any communication to the SRX. If attackers were able to gain access to your session, they could potentially make unauthorized changes to your device.
Logging in is straightforward, as you only need to input your username and password. Depending on the device, the login process can take up to a minute, so be patient as you are waiting for the J-Web application to load. For best performance, it is suggested you use a modern version of Google Chrome, Firefox, or Internet Explorer 10. Although J-Web does not officially support all of these versions, it should work well. Figure 3-1 is a screenshot of what you should see when connecting to J-Web.
Dashboard
After logging in to J-Web for the first time, you will be directed to the dashboard. This is a great tool to use to instantly see the state of the device. The last section you were at within J-Web is stored as a cookie within your browser. Because of this, subsequent logins might not take you directly back to the dashboard.
Getting started, let’s take a look at the initial dashboard in Figure 3-2. The initial dashboard offers some important information at a quick glace. It gives you basic inventory stats as well as a chassis view. All of the panels in the dashboard can be dragged and dropped around to customize the view to your liking.
Chassis view
The view of the chassis is much more than just a boring picture. It allows you to see the status lights on the chassis as well as the physical status of ports. Many of the elements can be hovered over, and it allows you to see more detail about each element’s status. In Figure 3-3, you can see an example of this as the mouse hovers over one of the Ethernet ports.
Because devices are more than just a front panel, there is the ability to right-click the chassis and access a shortcut menu. This menu allows you to flip the view to the back of the chassis as well as see additional details about the chassis by taking you to the monitoring page. In Figure 3-4, you can see an example of the shortcut menu.
Selecting the rear view will bring up the back of the chassis. Depending on your platform, there will be different amounts of available information. Here on our example device, an SRX100, we have very little information available to us. This feature provides the most value on the SRX3000 series, as they have rear-facing ports. Figure 3-5 shows the rear view of the SRX100.
Finally, you can select the Chassis Information view from the menu. This will take you to the detailed chassis information page in the monitoring section of the UI, depicted in Figure 3-6. This allows you to review all of the detailed information for the hardware components on the device. An administrator can cycle through the various tabs and combo boxes to select all the various components in the chassis.
Informational panels
There are other various informational panels available within the dashboard. The displayed data can be either informational or status oriented.
The first panel to discuss is the System Identification panel, depicted in Figure 3-7. This shows the device basics such as uptime, time, software version, and serial number.
The most popular and arguably the most valuable panel is the Resource Utilization panel, shown in Figure 3-8. This shows the memory, CPU for both the control and data plane, and available system storage. This will periodically update (once per two minutes by default, but this setting is customizable) with current information. It is important to note the CPU on the smaller devices might seem to always have high utilization on the control plane. Driving the various web UI tasks can be quite resource intensive. Because of this, the CPU utilization might seem high.
If there are any outstanding alarms on the device, the System Alarms panel, shown in Figure 3-9, displays them. This is helpful to show any hardware faults or other important alarms.
The second most useful panel is the Security Resources panel, depicted in Figure 3-10. This panel displays the percentage of resources that have been allocated. Because each platform can only have so many active sessions, this is a great tool to see how close your device is to session exhaustion.
One thing you never want to have happen is to fill up your firewall’s disk. This can cause the device to seize or lose logging data. The File Usage panel, shown in Figure 3-11, displays how much of the disk is being utilized. It also offers a quick link to solve the problem if the disk is full. Because the branch devices typically have anemic storage, this is an important thing to monitor.
It is important to make sure that unauthorized users are not accessing your firewall. The Login Sessions panel, displayed in Figure 3-12, displays any users logged into the device. It shows both CLI and web UI users.
Because the SRX has a great amount of security features packed into the device, it is important to monitor the efficacy of its policies. The Threats Activity panel, shown in Figure 3-13, shows the threats that have been detected across UTM and IPS. It also offers a quick link to the more detailed reporting.
The Chassis Status panel, shown in Figure 3-14, displays a quick view of hardware status. It is not really useful on the branch devices, because if any of these states were alarmed, then the device is most likely to go down. On the larger devices this can offer more value.
The last panel is the Storage Usage panel, pictured in Figure 3-15. It provides details around how much of the disk is utilized.
Customizing the dashboard allows you to select and remove panels that are not important to you. It is easy to do this by selecting the preferences dialog button in the upper-right corner of the dashboard (see arrow in Figure 3-16). From here, the various panels can be selected and the refresh time can be changed.
Device Configuration
The configuration options available within J-Web are extremely detailed. Often, web management tools are slimmed down and many configuration options are not made available. This is a double-edged sword when it comes to managing your device. The good news is that almost every possible option is available within J-Web. The downside is finding what you want to do can be daunting at times. Generally, J-Web follows the flow of the CLI. If you know the CLI, then J-Web will follow a logical flow. Alternatively, if you don’t know the CLI, J-Web will assist you in learning its structure.
This section does not go over every possible feature, nor does it go into any specific feature in detail. It focuses on how to navigate some of the more important and popular features of the configuration in J-Web. As already discussed, GUIs are constantly evolving, so it is quite possible that even between minor releases there will be major UI changes. To navigate to the configuration section of J-Web, select the Configure tab, highlighted in Figure 3-17.
Task wizards
When we look to solve a problem where we do not know an answer, we tend to look at product experts. When one isn’t available, you can always call on the J-Web wizards. Wizards receive mixed reviews, as they tend to oversimplify tasks and not give the user the results they would expect. This is not the case with J-Web, as the wizards are extremely useful to get you started.
The wizards can be found in the upper-left corner of the configuration screen, as shown in Figure 3-18. If you look for the word “Wizards” this might be a bit confusing, so it is helpful to point it out.
The most helpful wizard is the Setup wizard. It not only can perform an initial setup, but it also helps modify the device’s configuration. If you want to configure your SRX but you don’t know how to get started, best practice is to use this wizard. In Figure 3-19, it is easy to see how the wizard will take you down a path.
If you choose to create a new configuration through the wizard, you will have the option to select the default setup that will preconfigure many of the best practices for you (see Figure 3-20). Alternatively, you can walk through the guided setup that will take you through all of the same configuration steps. Taking the guided tour is suggested for all new users. This shows you the most common elements that need to be configured and what is important from an SRX configuration standpoint. This is an excellent primer for any new user.
If you select the guided setup, the wizard will ask you to select your level of expertise, as shown in Figure 3-21. Selecting the basic path will take you through only the required set of options. If you select expert, you will be taken through a more advanced set of options. You should stick to the basic path if this is your first adventure in the SRX. If you have an understanding of zones, policies, and system services, please veer onto the expert path, as it will open up some newer options for you.
The wizard contains more than 120 screens, so we won’t review all of them. However, the first step for device information is important to call out. On any new Junos device you are always required to set the root password on authentication. Second, you always want to define a hostname, as once you access the device it is easy to forget which device you are on. This first step of the wizard makes you set up both. The example in Figure 3-22 shows you that it will walk you through the same process that an experienced Junos expert would take setting up the device from the CLI. After running through the wizard, you will know just what steps you would want to take if you were to set the device up through the CLI manually.
Committing the configuration
Originally, J-Web required you to commit each and every change that was made in J-Web. This was a really slow process, and frankly it ruined the experience of a GUI. Juniper listened to customers and created the ability to batch commit the configuration. It is important to understand how this works so you ensure that you apply the configuration changes that you make. The first time you make a configuration change you will see the informational pop-up box shown in Figure 3-23. It will let you know that you need to commit the configuration.
After you select to commit the changes, the configuration is first verified. This is exactly how a commit works through the CLI. This makes sense, as underneath J-Web is effectively the CLI. If the validation fails, it will instruct you on what to go back and change. If the validation succeeds, as shown in Figure 3-24, the committing of the configuration begins.
The time it takes to deliver the configuration and apply it will depend on what platform you are using and how big the configuration is. J-Web will generally move more slowly to commit a configuration than if you were to do the same task from the CLI. Be patient, therefore, as you are committing the configuration. Let the configuration commit, as displayed in Figure 3-25, and do not attempt to reload the page or close any windows.
Interfaces
One of the two most common tasks performed through J-Web is interface management. Often, new subinterfaces will need to be created or IP addresses added. J-Web does an excellent job of dealing with interfaces and managing them. The interfaces selection is the first item under the Tasks menu among the selections found on the left side of the J-Web interface. Once selected, a list of interfaces will appear in a tree format in the main panel. There will be lots of strange interface names, such as lt-0/0/0. These are virtual interfaces that are used for various protocols and packet encapsulations. Most of the time, you will be dealing with Ethernet interfaces, so let’s take a look at one of those in Figure 3-26.
From this page, it is also possible to get more details on the units of interfaces that are configured. Within the tree of interfaces, you can click on the small plus sign to expand all the units under an interface (see Figure 3-27). This is helpful to show the IP addresses that are configured on an interface.
To edit an interface in detail, right-click the interface or select Edit from the upper-right corner. Once you open the interface, shown in Figure 3-28, the most common configuration options are available to you. The three most important elements for the interface are zone, IP, and VLAN ID, all of which can be created from within this screen. Both IPv4 and IPv6 addressing are supported. The configuration of the interface is different from the web UI compared to the CLI. In the CLI, the zone configuration would be in a completely different area of the configuration outside of the interface, thus showing the effectiveness of J-Web.
Firewall policies
The most common task of any firewall is to manage policies. For most firewalls, this is a daily task. Because of this, any firewall management tool needs to be extremely strong when it comes to this task. J-Web is such a tool, as its policy management capabilities are very strong. A point to note is that if you plan on managing hundreds or thousands of policies on a device, you will want to move to the Space platform, which is optimized for such tasks.
The SRX has many different types of firewall policies. These range from NAT and IPS to stateful firewall. The most commonly used type is the stateful firewall polices. Getting into the policies is a bit confusing in J-Web. To access the policies through the web UI, select Security → Policy → Apply Policy. This strange naming convention comes through a legacy configuration in J-Web. It is preserved to keep those who are familiar with J-Web in logical territory.
Figure 3-29 shows what a standard firewall policy looks like. It is a traditional tabular design containing one policy per row. Each column represents a different element of the policy. Because the SRX utilizes a zone-based design, it is possible to filter the displayed policies by zones in the menu bar above the policy table. Those of you with a NetScreen background might notice that the icons used in the policies are the same from ScreenOS.
If you right-click a policy or click Edit in the upper,right corner, the details window will open, allowing you to configure all of the elements of the firewall policy (see Figure 3-30).
Point and click CLI
When all else fails, you can bring back the original J-Web design from 2005 and utilize the point and click CLI, shown in Figure 3-31. This is a literal interpretation of the CLI represented as a GUI. It is nice to use, as you can better understand how the hierarchy of the command line works. Sometimes you might know how to configure an element of the configuration only from the CLI, but you are unable to find it in the GUI. This tool will help bridge the gap between the web UI and the CLI, unifying both interfaces into one.
Monitoring Your SRX
Once your SRX is configured and running, it is time to monitor your environment. The J-Web tool is the perfect tool for monitoring a single SRX. It gives you many of the stats that you need to know about. Because the SRX has so many features, the monitoring capabilities vary per platform and release. In this section, we review the most important elements to monitor from J-Web.
Interface monitoring
Following the progression of our configuration section, first we look at how to monitor interfaces. Start by selecting the Monitor tab at the top of the page and then Interfaces on the left. This opens a table for all of the interfaces. In Figure 3-32, we have selected an interface, which brings up two traffic graphs, one for the input stats and the other for the output stats. These stats will show you how much traffic is going through the interface.
More important, if you scroll down on the same page, you can review both the error and packet counters. If you notice a significant amount of errors, something could be wrong with the cable, interface, or the remote node. In Figure 3-33, you can see these charts.
Traffic reports
The interface stats are excellent, but those are only counters for packets. To drill down further into the protocol stack, you can access the traffic reports under the Reports → Traffic menu on the left side. In Figure 3-34, you can see the breakdown of the traffic data. The flows are broken up by L3/L4 protocols of TCP, UDP, and ICMP. Then on the right side you can see the recently closed traffic sessions. This shows how much traffic has passed through the various sessions. You can customize how often these stats are refreshed automatically through the Refresh Interval drop-down box.
Operational Tasks
To maintain your SRX and prevent service outages, you must periodically perform operational tasks. There are a few important tasks that we review here. The best practice is to review each of these important tasks, so when the time comes to perform them, you will be ready to do so.
Software management
The Junos OS is developed under rigorous standards. Fresh releases are often packed with new features and bug fixes. Because of this, updating your SRX might be required several times per year, so it is good to be familiar with the SRX upgrade process. Most users choose to do the upgrade process from the CLI, but that can be complex. J-Web offers some simple ways to manage the software lifetime of your device.
To update your software, you must first upload an image. This is done through the Software → Upload Package menu. Updating is easy to do. Simply choose the file you want to upload from your computer, then select a few options (see Figure 3-35). You will always have to reboot. If you are able to reboot at that time, select the Reboot If Required checkbox. The “Do not save backup” option prevents the upgrade device from saving a backup copy of the image. Select this on the smaller branch devices, as they do not have enough disk storage to hold image backups. Once you have selected the options, click Upload and Install Package. This might take a while to complete, so be patient. Once the image is uploaded, a message will notify you that the process is complete. Do not close your browser before that, as it will interrupt the process.
Instead of having to push a package to the SRX, you can alternatively pull the image. This is great if you have a central repository of software for your data center. The location is required to specify where to pull the image from. You can use FTP, TFTP, HTTP, and SCP. Optionally, you can input a username and password for the package retrieval. The other options are the same as we reviewed before (see Figure 3-36).
Junos always keeps the last version of installed software available on the device. In the event you are experiencing unexpected behavior and need to roll back to the last installed release, you can simply go to the downgrade page shown in Figure 3-37 and click the Downgrade button. This will roll back to the previously installed release, but it will take some time and require the device to reboot. Once this process is started, you cannot stop it, so please be cautious in beginning the downgrade process.
Configuration management
Each time a configuration change is made, J-Web takes a snapshot of the configuration. Each device stores from between 5 and 50 different versions of the configuration. On the Config Management → History page, displayed in Figure 3-38, you can download, compare, and optionally roll back to an older version of the configuration. You might want to roll back your configuration if a change that you made did not work out as intended. Also you can see which user made the configuration change to determine who made the bad change.
Rebooting
Whether after a software upgrade or doing operational tasks, you will need to reboot your SRX from time to time. The Reboot screen, shown in Figure 3-39, allows you to reboot or halt the device. Halting the device will stop the OS. It is best to do that if you have console access so you can complete the reboot. The other options are to reboot immediately, reboot in X minutes, or schedule the reboot for a specific time. Optionally, you can display and log a message about why the reboot was needed.
Disk management
Junos offers very verbose monitoring and has a large software image that gets installed. Because of this, the disk often gets cluttered with many files. Potentially, your device’s disk could get filled and cause it to lose data or, even worse, it could crash. Using the options on the Files menu, you can manually run a cleanup process to delete unneeded files (see Figure 3-40). Alternately, if you click any of the links, you can manually delete or download files. This is great for collecting any core dumps, logfiles, or software images on your device, and it is helpful for grabbing diagnostic information or just to simply view a logfile through the browser.
Troubleshooting from J-Web
Occasionally, things will go bad on your network. This is what makes being a network engineer so fun. Once things go wrong, though, it is time to right them. Several common tasks can be handled through J-Web. Ultimately, deep debugging will need to be done through the command line, but the two most common tasks are available through the web interface as well.
Packet capture
For many troubleshooting issues, you need to perform a packet capture on traffic (see Figure 3-41). This will allow you to analyze flows and see where traffic is potentially going wrong. Packet capture support will vary per release, platform, and potentially hardware card. Please check with the latest documentation to see if your platform is supported. It is simple to configure the options. You should select which interface you want to collect packets from.
To select the entire packet that is on the wire, you must enter 0 into the Packet Size field. You can also add various filters to specify the IP, protocol, and ports that the traffic will use.
Network connectivity
Mike Muus changed the world one fine day in 1983. He created a utility called ping, named after sonar pings. Today, this tool is used as a basic network connectivity tester and as a starting point for almost any network troubleshooting. You can harness this tool through J-Web. By selecting the Ping option, you can send ICMP packets to remote hosts. You simply need to enter the IP address or hostname to send the packet. There are several other options that can be selected when sending pings, as shown in Figure 3-42.
The most important thing to note is the routing instance. This will be needed to change from the default to the specific routing instance that you would like to use to generate the ping. Second, you might want to select which interface to source the packet from as well.
Centralized Management
There are times when you will have too many devices to effectively manage individually. When this event occurs is to the decision of an individual administrator. A centralized management tool can simplify the management of your infrastructure and provide you a single pane of glass through which see your infrastructure and report on its activity. These are the two most important tasks of centralized management. Juniper offers several different management solutions that can provide you with these functions. Currently, from a management perspective, Junos Space is the premier platform for managing not only SRXs, but also all Junos devices.
To complement Junos Space, Juniper Networks utilizes the Statistical Report Manager software (STRM). The STRM platform not only collects logs, but also provides detailed analytics for then. And because security is not only provided by firewalls in a network, the STRM platform can accept logs from almost any device. The goal of this book is to focus on the individual devices themselves and not on the entire Junos ecosphere. Because of this, the centralized management section is a review of what is available and is not meant to be an exhaustive resource for these platforms.
Finally, in this section, we provide a brief review of the legacy management platform NSM. NSM has been around for more than seven years, and although its design is starting to show its age, it still is a very popular management platform for both legacy and new products alike.
Space: The Final Frontier of Management
Junos Space is more than a management console; it is a platform on which management is run. Back in 2007, once NSM was remade to include Junos, revolutionary thinking was going on about how management needed to be performed. NSM was an amazing security management tool, but it was not as flexible is Juniper would have liked to add new services on. Because of this, Juniper knew it was time to start investing in a platform that was extensible to meet all of its management needs for the next 10 years. Based on this need, Junos Space was created.
As new products were created and as new needs were to arise, Junos Space needed to be designed to meet this challenge. In Figure 3-43, we take a look at the platform and the basics of its design.
The Space platform utilizes Device Management Interface (DMI) to communicate with Junos devices. This is also known as a superset of the NetConf protocol that was defined originally in RFC 4741 as an XML-RPC-like protocol to provide configuration management of devices. The platform uses various technologies such as templates, inventory management, and event aggregation to store and manage device configurations. All of these elements are accessible via a Representational State Transfer (REST) HTTP protocol. This API is available to all users of the Space platform as well as its applications. The power of Space truly is in its RESTful API architecture. All of the Junos Space applications utilize a central API that is available to all users of Space. This way the platform is designed to be the underpinnings of the applications and gives each application designer the freedom to focus on the apps and not worry about how to connect to the devices.
The Junos Space ecosphere
Applications are the heart of where users spend their time when floating through Junos Space. Each application (see Figure 3-44) provides the specific tools that are needed to solve a problem from within your network. Applications like Security Director are built to manage your security infrastructure, whereas Service Now provides automated troubleshooting and reporting of any open issues that might arise on your network. Service Now can also automatically publish your issues to Juniper’s customer support to ensure that an engineer will be working on your issue before you even notice a problem occurred.
Security Director
To manage your security needs, the Security Director application takes this type of management to new levels. It not only provides you with a GUI to manage policies, but it can assist in managing the complete ecosystem of your security needs. Each new release of Security Director offers newer features to simplify policy management and increase the overall security efficacy of your network. Due to the advanced development and rapid releases, it is difficult to cover this product within a book that contains static content on publication. It is suggested that you view the publically available documentation to see all of the current features of the Security Director application (see Figure 3-45).
Firewall policy management
The top task to use Security Director for is firewall policy management. Security Director brings in many tools that advanced administrators are looking for. It allows you to create multiple policy templates, which you can use to automatically merge them into a single policy that is pushed down to a device. This eases administration as opposed to having to create these complex policies by hand. The policy UI, shown in Figure 3-46, is also more fluid and advanced than what is available from the J-Web interface.
Defining individual policies is similar to how you would do it on J-Web. A policy creation dialog box opens and allows you to add the standard elements that you would expect to add into a policy. However, unlike J-Web, there are additional options that can be applied to a policy. Because Security Director is centrally managed, it allows you to apply the policy to a group of devices or to a single device. It also can apply precedence to a policy so when the various policies are compiled before they are pushed to an SRX, you are able to define which policy would take precedence in the event of a conflict. These central management options are depicted in Figure 3-47.
Log Management with STRM
Configuring policies is only one side of the equation of managing a security infrastructure. The other half is looking at the efficacy of these policies. This is best done using the STRM platform from Juniper Networks. Although the focus of this discussion is the SRX, it should not be overlooked that the STRM platform can take in logs from almost any device. This includes other Junos platforms but also things such as Microsoft Active Directory and even Cisco products. The goal of the platform is to not just collect logs, but to use data aggregation to take those logs and make them into valuable reports.
Reporting with STRM
The heart of STRM is its reporting infrastructure. There are many built-in reports for STRM, but an administrator can also create predefined reports. These reports can correlate logs from various sources into a dashboard that defines the exact activities of your network.
Reporting on what applications are being used within your network is a popular task for STRM. Figure 3-48 is a depiction of this report. It takes logs from the AppSecure or AppID that come from the SRX and provides reporting for it. It reports on the top applications as well as the top application source IP addresses.
IP addresses are typically sourced by geographic location. This is an interesting point to report on for many reasons. If you are hosting a website, you might want to see where your potential clients are coming from. In the case of security, you want to see where specific attacks are starting. Is China your biggest threat or is it Detroit, Michigan? STRM has built-in reporting to be able to correlate country data to the IP address (see Figure 3-49).
Reporting by IP addressing is great, but determining the actual user who is accessing data is even better. It is possible to tie STRM into your user authentication infrastructure (see Figure 3-50) to be able to correlate this information. Through this, you can see if Darren has been spending too much time on YouTube or if Charlie has had his productivity reduced by reading home improvement articles. This is a more human approach to seeing the activity on your network. It has been proven in the US courts that an IP address does not directly show what activities a user has performed. Because of this, being able to correlate the activities of users is invaluable to any enterprise.
Legacy Security Management
162_Ma Before the SRX, and before Juniper even acquired NetScreen, the world had NetScreen Security Manager. This platform was the successor to Global Pro to manage the ScreenOS platforms. For its time, the platform was a revolution in management for the security industry. However, over time, as Juniper was in need for managing Junos in the enterprise, it worked to move this product to support Junos. Network and Security Manager became the product’s name, retaining the NSM acronym.
As of this writing, the NSM platform has been put into maintenance mode. This means that no new features will be put into the platform but all subsequent releases will be to patch the existing platform. NSM is not suggested for new deployments unless ScreenOS or IDP standalone support is needed. Both of these legacy platforms are only supported through NSM, so if centralized management is required for them, NSM must be used. Because NSM is no longer being developed, it will not be able to support new features in future versions of Junos. It will be able to manage newer releases through schema updates, but if a new feature requires a custom screen to configure it, that will not be created.
Using NSM
The NSM management tool follows a bit more traditional paradigms of management than Junos Space. It offers a similar dashboard, shown in Figure 3-51, to select which tasks you want to undertake. Because NSM is focused on network and security management, its capabilities are a bit more limited than what is found within Junos Space.
Policy management is still the most common task that is handled within NSM. It offers the traditional style of policy management that we have seen throughout this chapter. It also has some of the same policy template features that we have seen in Security Director (see Figure 3-52). In fact many of the features that you find in Junos Space are present within NSM.
Summary
Managing the security posture of your network is a daunting task. Different organizations use different tools to help solve this problem. The most common way to handle this kind of management is through GUIs. These tools take the complex nature of policy management and simplify it to give administrators an enhanced vision over which policies are enabled on their network.
J-Web offers a robust toolset that is available on every SRX system and also most Junos systems right out of the box. It offers tools that are more limited than central management systems, but capable enough to provide simplified on-device management. J-Web is constantly evolving to meet the needs of today’s customers. Throughout this chapter we have looked at many features of J-Web. Due to the advanced methodology and rapid software release cycle of Junos, new features and enhancements are popping up all the time. For the latest capabilities and features of Junos, please refer to the documentation of the current release of Junos that your device is running.
Although Junos Space has only been out for a few years, it has made herculean progress in its capabilities. The future of the Space platform, as well as Security Design, is bright. There most certainly will be more amazing features coming right around the corner to increase the efficacy of your network security policies.
Study Questions
- Questions
What management platform supports the legacy ScreenOS and standalone IDP?
When did J-Web originate?
What is the defining component of Junos Space?
What is the most common task for GUI management of security devices?
What is the alternate name for wizards that is used in J-Web?
Is it possible to manage your device’s software image through J-Web?
What is the name of the legacy security management platform for the SRX?
What tool does Juniper make to handle log management?
- Answers
NSM is the only platform that supports the ScreenOS and standalone IDP. It also supports most Junos platforms, including the SRX.
J-Web was originally created in 2005 and has had significant development around its feature set since it was launched.
Junos Space is a platform and not just a management tool. It allows applications to use a common API to control and access information about the devices connected to it. Through this, new applications and services can be rapidly built on the solid Space platform.
Policy management is the most common task done for security devices through a GUI. Being able to see all of the policies and how they interact through a single window is critical for any security administrator.
J-Web also defines its wizards as tasks.
J-Web offers complete device management, including software installation and rollbacks.
NSM is the legacy management platform. All new installations should focus on utilizing Junos Space.
Statistical Reports Manager (STRM) is the ideal tool for log management and reporting. STRM is not limited to Junos devices only; it can accept logs from nearly any device.
Get Juniper SRX Series now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
