Understanding On-Box Logging and Reporting
This topic describes the on-box logging and reporting CLI functionality and the design aspects of on-box reporting for the SRX devices.
On-box traffic logging to solid-state drives (SSDs) supports eight external log servers or files.
An all-in-one XML file is added that contains all the traffic logs information. The XML file also generates all the logging header files and traffic log related documents.
A new process (daemon) called local log management daemon (llmd) is supported in Services Processing Cards 0 (SPCs0) to handle on-box traffic logging. Traffic produced by flowd in SPCs is listed in traffics logs. The llmd saves these logs to the local SSD. Traffic logs are saved in the following four different formats:
On-box reporting mechanism is an enhancement to the existing logging functionality. The existing logging functionality is modified to collect system traffic logs, analyzes the logs, and generate reports of these logs in the form of tables using the CLI. On-box reporting feature is intended to provide a simple and easy to use interface for viewing security logs. The on-box reports are easy to use J-Web pages of various security events in the form of tables and graphs. The reports allow the IT security management to identify security information at a glance, and quickly decide the actions to be taken.
The on-box reporting feature is enabled by default when you load the factory-default configurations on the SRX Series device with Junos OS Release 15.1X49-D100 or later.
If you are upgrading your SRX Series device from a Junos OS Release prior to Junos OS 15.1X49-D100, then the SRX device inherits the existing configuration and the on-box reporting feature is disabled by default. You need to configure the set security log report command and the set security log mode stream command to enable the on-box reporting feature on the device that are upgraded.
Starting in Junos OS Release 19.3R1 , the factory-default configuration does not include on-box reporting configuration to increase the solid-state drive (SSD) lifetime. You can enable the on-box reporting feature by configuring the set security log report CLI command at [edit security log] hierarchy.
You must configure security policy for the session using the set security policies from-zone zone-name to-zone zone-name policy policy-name then log session-close command to list all the applications and nested applications in Application Tracking on J-Web using the on-box reporting feature. See for more log (Security Policies) for details.
After the log message is recorded, the log is stored within a log file which is then stored in the database table of the RE for further analysis (on SRX300, SRX320, SRX340, SRX345, and SRX550M devices) or on the SSD card for further analysis (on SRX1500, SRX4100, and SRX4200 devices).
This feature supports receiving top most reports based on count or volume of the session or the type of log, captures events occurring in each second within a specified time range, captures log content for a specified CLI condition. Various CLI conditions like “summary”, top”, “in-detail”, and “in-interval” are used to generate reports. You can generate only one report at one time using the CLI. All the CLI conditions cannot be used at the same time. You can generate only one report at one time using the CLI.
The benefits of this feature are:
Reports are stored locally on the SRX Series device and there is no requirement for separate devices or tools for logs and reports storage.
The on-box reports are easy-to-use J-Web pages of various security events in the form of tables and graphs.
Provides a simple and easy-to-use interface for viewing security logs.
The reports generated enables the IT security management team to identify security information at a glance and quickly decide the actions to be taken.
The on-box reporting feature supports:
Generating reports based on the requirements. For example: count or volume of the session, types of logs for activities such as IDP, UTM, IPsec VPN.
Capturing real-time events within a specified time range.
Capturing all the network activities in a logical, organized, and easy-to-understand format based on various CLI specified conditions.
Understanding On-box logging and Reporting
In the on-box reporting mechanism, CLI is used to fetch the reporting data from the device. The SRX series device collects and saves all the required logs. These recorded logs are then used for further analysis to calculate and generate reports in the form of tables using the CLI. The data generated using CLI in the form of reports can be further retrieved in the form of tables and graphs in J-Web. The reports generated are easy-to-understand tables and graphs in J-Web. Thorough analysis of logs is performed (based on session types) for features such as screen, IDP, UTM and IPSec.
You can define filters for the log data that is reported on based on the following criteria:
The top, in-detail, and in-interval conditions cannot be used at the same time.
top <number>—This option allow you to generate reports for top security events as specified in the command. for example: top 5 IPS attacks or top 6 URLs detected through UTM.
in-detail <number>—This option allow you to generate detail log content.
in-interval <time-period>—This option allows you to generate the events logged between certain time intervals.
summary—This option allows you to generate the summary of the events. In this way, you can fine-tune the report to your needs, and displays only the data that you want to use.
The maximum in-interval number which shows the count in intervals is 30. If large duration is specified, then the counters are assembled to ensure the maximum in-interval is less than 30.
Both in-detail and summary have the “all” option, since different table have different attribute (like session table does not have the attribute “reason” but UTM has), the “all” option does not have any filter except start-time and stop-time. If there is any other filter other than start time and stop time then an error is displayed.
For example: root@kujang> show security log report in-detail all reason reason1
error: "query condition error"
The application firewall logs for application and user visibility will list applications and nested applications. When the logs of these features list nested applications then nested applications are listed in J-Web. When the logs list nested applications as not-applicable or unknown then only the applications are listed in J-Web.
Use the following CLI commands for application and user visibility for all the applications and nested applications listing:
For top nested-application by count—show security log report top session-close top-number <number> group-by application order-by count with user
For top nested-application by volume—show security log report top session-close top-number <number> group-by application order-by volume with user
For top user by count with nested application—show security log report top session-close top-number <number> group-by user order-by count with application
On-Box Reporting Features
The on-box reporting feature supports:
Sqlite3 support as a library—sqlite3 was not supported prior to Junos OS release 15.1X49-D100. Starting with Junos OS Release 15.1X49-D100, an SQL log database (SQLite Version 3) is used by the daemons running on the RE as well as other potential modules to store logs on SRX Series devices.
Running llmd in both Junos OS and Linux OS—The forwarding daemon (flowd) decodes database index from binary logs and sends both index and log to the local log management daemon (llmd).
On SRX300, SRX320, SRX340, SRX345, and SRX550M devices, llmd runs in Junos OS. On SRX1500, SRX4100, and SRX4200 devices, llmd runs in Linux. So, for supporting llmd to run in both Junos OS and Linux OS, the llmd code directory is moved from the Linux side to the Junos OS side.
Storing of logs into specified table of the sqlite3 database by llmd— A new syslog daemon is introduced to collect local logs on SRX Series devices and saving them into the database.
Starting in Junos OS Release 19.3R1, Junos OS stores logs in multiple tables instead of a single table in a database file. Each table contains the timestamp of the oldest and latest logs. When you initiate a query based on the start and end time, llmd finds latest table to generate reports.
For example, if there are 5 million logs in one table of a database file generated in the last 10 hours, and if you want to take a report, you should spend more than half an hour. From Junos OS Release 19.3R1, one table is separated into multiple tables, and each table has 0.5 million of logs. To generate the same report, one table information is sufficient.
We recommend you to query with a shorter time for better performance.
Database table definition—For session logs, the data types are source-address, destination-address, application, user, and so on. For logs related to security features, the data types are attack-name, URL, profile protocol, and so on. Therefore, different tables are designed to store different types of logs to help improve the performance and save disk space. SRX device creates a database table for each log type, when log data is recorded.
Each type of database table has its maximum record number that is device specific. When the table record number reaches the limitation, new logs replace the oldest logs. Junos OS stores log in an SRX Series device in which active traffic is passed.
Starting in Junos OS Release 19.3R1, you can create multiple tables in a database file to store logs. You can define the capacity to store logs in a table.
If the limit of log number exceeds the table capacity, Junos OS stores the logs in the second table. For example, if the limit of logs in table 1 exceeds the table capacity, Junos OS stores logs in table 2.
If the limit of the log number exceeds the last table of file 1, Junos OS stores the logs in table 1 of file 2. For example, table n is the last table of file 1. When the logs exceed the table capacity, Junos OS stores the logs in table 1 of file 2.
To make immediate effect after you change the table number, use clear security log report operational command.
Database table rotation—Each type of database table has its maximum record number that is device specific. When the table record number reaches the limitation, new logs replace the oldest logs.
Following Table 1 describes the database file size capacity:
Table 1: Database File Size Capacity
SRX300, SRX320, SRX340, SRX345, and SRX550M
SRX4100 and SRX4200
Calculating and displaying the reports that are triggered by CLI—The reports from the database are received from the CLI as the interface. Using the CLI, you can calculate and display the reporting details.
When you want to generate a report from multiple tables, llmd sorts tables based on timestamp and selects tables as per the requested start-time and stop-time.
For example, there are three tables that is table 1 (1 to 3), table 2 (3 to 5) and table 3 (6 to 8). 1 to 3, 3 to 6, and 6 to 8 denotes time stamp of latest and oldest logs. If you request a report from 4 to 6, Junos OS generates report from table 2 and table 3.
You can decide table lifetime by configuring set security log report table-lifetime command. Junos OS removes the table after the table identify time exceeds the table lifetime. For example, if you configure table lifetime as 2, and the current date is 26-July-2019, then it means on 24-July-2019 00:00:00 logs are removed.
If you change the date and time manually on a device, the table lifetime changes. For example, if a table identify time is 19-July-2019, and you configure table lifetime as 10, Junos OS should remove the table on 29-July-2019. If you change the device date as 18-July-2019, then the table real lifetime becomes 30-July-2019.
Chassis Cluster Scenario
For on-box reporting in a chassis cluster, the logs are stored in the local disk on which the device is processing active traffic. These logs are not synchronized to the chassis cluster peer.
Each node is responsible to store logs when each node is processing active traffic. In case of active/passive mode, only the active node processes the traffic and logs are also stored only in the active node. In case of failover, the new active node is processes the traffic and stores logs in its local disk. In case of active/active mode, each node processes its own traffic and logs are stored in the respective nodes.