Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Configuring System Logging for a Security Device

 

Understanding System Logging for Security Devices

Junos OS supports configuring and monitoring of system log messages (also called syslog messages). You can configure files to log system messages and also assign attributes, such as severity levels, to messages. Reboot requests are recorded to the system log files, which you can view with the show log command.

This section contains the following topics:

Control Plane and Data Plane Logs

Junos OS generates separate log messages to record events that occur on the system’s control and data planes.

  • The control plane logs, also called system logs, include events that occur on the routing platform. The system sends control plane events to the eventd process on the Routing Engine, which then handles the events by using Junos OS policies, by generating system log messages, or both. You can choose to send control plane logs to a file, user terminal, routing platform console, or remote machine. To generate control plane logs, use the syslog statement at the [system] hierarchy level.

  • The data plane logs, also called security logs, primarily include security events that are handled inside the data plane. Security logs can be in text or binary format, and they can be saved locally (event mode) or sent to an external server (stream mode). Binary format is required for stream mode and recommended to conserve log space in event mode.

    Note the following:

    • Security logs can be saved locally (on box) or externally (off box), but not both.

    • SRX1400, SRX1500, SRX3400, SRX3600, SRX4100, SRX4200, SRX4600, SRX5400, SRX5600, and SRX5800 devices default to stream mode. To specify binary format and an external server, see Configuring Off-Box Binary Security Log Files.

      Note

      Logs might be dropped if you configure event mode logging on these devices.

      Starting with Junos OS Release 15.1X49-D100, the default mode for SRX1500 device is stream mode. Prior to Junos OS Release 15.1X49-D100, the default mode for SRX1500 device was event mode.

    • Starting in Junos OS Release 19.3R1, SRX300, SRX320, SRX340, SRX345, SRX550, and SRX550M devices default to stream mode. Data plane events are written to system log files in a similar manner to control plane events. To specify binary format for the security logs, see Configuring Off-Box Binary Security Log Files.

    Starting in Junos OS Release 20.2R1, we support escape in stream log forwarding and on-box reporting to avoid parsing errors. Stream mode supports escape in sd-syslog and binary formats when logs are not sent to eventd process. For the logs send to eventd process, we recommend not to enable an escape option as the eventd process has enabled the escape for the structure log. Event mode supports escape only in binary format. By default the escape option is disabled. You must enable the escape option using the set security log escape command.

Redundant System Log Server

Security system logging traffic intended for remote servers is sent through the network interface ports, which support two simultaneous system log destinations. Each system logging destination must be configured separately. When two system log destination addresses are configured, identical logs are sent to both destinations. While two destinations can be configured on any device that supports the feature, adding a second destination is primarily useful as a redundant backup for standalone and active/backup configured chassis cluster deployments.

The following redundant server information is available:

  • Facility: cron

  • Description: cron scheduling process

  • Severity Level (from highest to lowest severity): debug

  • Description: Software debugging messages

Understanding Stream Logging for Security Devices

Junos OS supports forwarding logs using stream mode and event mode. All the categories can be configured for sending specific category logs to different log servers for stream mode log forwarding.

Stream mode log forwarding includes the following steps:

  • An RTLOG system log message is generated by the data plane and is sent out from the Packet Forwarding Engine.

  • An RTLOG system log message is generated by pfe process and is sent from Packet Forwarding Engine.

  • An RTLOG system log message is generated by the Routing Engine unified threat management (utmd) process and is sent by rtlogd process from the Routing Engine.

For stream mode log forwarding, the transport protocol used between Packet Forwarding Engine and the log server can be UDP, TCP, or TLS. These transport protocols UDP, TCP, and TLS are configurable. The transport protocol used between the Routing Engine and the log server can only be UDP. TLS is not supported on cSRX.

Starting in Junos OS Release 17.4R2 and later, on SRX300, SRX320, SRX340, SRX345 Series devices and vSRX instances, when the device is configured in stream mode, you can configure maximum of eight system log hosts.

In Junos OS Release 17.4R2 and earlier releases, you can configure only three system log hosts in the stream mode. If you configure more than three system log hosts, then the following error message is displayed error: configuration check-out failed.

Starting in Junos OS Release 20.2R1, we support escape in stream log forwarding to avoid parsing errors. Stream mode supports escape in sd-syslog and binary formats when logs are not sent to eventd process. For the logs send to eventd process, we recommend not to enable an escape option as the eventd process has enabled the escape for the structure log. By default the escape option is disabled. You must enable the escape option using the set security log escape command.

See also

Understanding Binary Format for Security Logs

The Junos OS generates separate log messages to record events that occur on the system’s control plane and data plane. The control plane monitors events that occur on the routing platform. Such events are recorded in system log messages. To generate system log messages, use the syslog statement at the [system] hierarchy level.

Data plane log messages, referred to as security log messages, record security events that the system handles directly inside the data plane. To generate security log messages, use the log statement at the [security] hierarchy level.

System log messages are maintained in log files in text-based formats, such as BSD Syslog, Structured Syslog, and WebTrends Enhanced Log Format (WELF).

Security log messages can also be maintained in text-based formats. Because security logging can produce large amounts of data, however, text-based log files can quickly consume storage and CPU resources. Depending on your implementation of security logging, a log file in a binary-based format can provide more efficient use of on-box or off-box storage and improved CPU utilization. Binary format for security log messages is available on all SRX Series devices.

When configured in event mode, security log messages generated in the data plane are directed to the control plane and stored locally on the device. Security log messages stored in binary format are maintained in a log file separate from that used to maintain system log messages. Events stored in a binary log file are not accessible with advanced log-scripting commands intended for text-based log files. A separate CLI operational command supports decoding, converting, and viewing binary log files that are stored locally on the device.

When configured in stream mode, security log messages generated in the data plane are streamed to a remote device. When these messages are stored in binary format, they are streamed directly to an external log collection server in a Juniper-specific binary format. Externally-stored binary log files can only be read using Juniper Secure Analytics (JSA) or Security Threat Response Manager (STRM).

Starting in Junos OS Release 17.4R2 and later, on SRX300, SRX320, SRX340, SRX345 Series devices and vSRX instances, when the device is configured in stream mode, you can configure maximum of eight system log hosts.

In Junos OS Release 17.4R2 and earlier releases, you can configure only three system log hosts in the stream mode. If you configure more than three system log hosts, then the following error message is displayed error: configuration check-out failed.

For information about configuring on-box (event-mode) binary security logs, please see Configuring On-Box Binary Security Log Files. For information about configuring off-box (stream-mode) binary security logs, please see Configuring Off-Box Binary Security Log Files.

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.

Overview

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:

  • syslog

  • sd-syslog

  • welf

  • binary

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.

Note

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).

Note

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:

Note

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

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.

    In Junos OS Release 19.4R1, we've upgraded the on-box logging database to improve query performance.

  • 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

      Devices

      Session

      Screen

      IDP

      UTM

      IPsec-VPN

      SKY

      SRX300, SRX320, SRX340, SRX345, and SRX550M

      1.8G

      0.18G

      0.18G

      0.18G

      0.06G

      0.18G

      SRX1500

      12G

      2.25G

      2.25G

      2.25G

      0.75G

      2.25G

      SRX4100 and SRX4200

      15G

      2.25G

      2.25G

      2.25G

      0.75G

      2.25G

      SRX4600

      22.5G

      6G

      6G

      6G

      0.75G

      2.25G

      vSRX

      1.8G

      0.18G

      0.18G

      0.18G

      0.06G

      0.18G

  • 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.

Table Selection

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.

Table Lifetime

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.

Table Dense Mode

In Junos OS Release 19.4R1, we've upgraded the default storage and search mechanism in the on-box logging database to manage logs. You can now customize log storage and search mechanism results. For example, if you expect fewer traffic logs, you can use the default configuration with a start time and a stop time.

However, if you expect a large number of traffic logs and greater time intervals for which the logs will be generated, then enable dense mode. To enable dense mode, use the set security log report table-mode dense configuration command.

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.

See also

Monitoring Reports

On-box reporting offers a comprehensive reporting facility where your security management team can spot a security event when it occurs, immediately access and review pertinent details about the event, and quickly decide appropriate remedial action. The J-Web reporting feature provides one- or two-page reports that are equivalent to a compilation of numerous log entries.

This section contains the following topics:

Threats Monitoring Report

Purpose

Use the Threats Report to monitor general statistics and activity reports of current threats to the network. You can analyze logging data for threat type, source and destination details, and threat frequency information. The report calculates, displays, and refreshes the statistics, providing graphic presentations of the current state of the network.

Action

To view the Threats Report:

  1. Click Threats Report in the bottom right of the Dashboard, or select Monitor>Reports>Threats in the J-Web user interface. The Threats Report appears.
  2. Select one of the following tabs:
    • Statistics tab. See Table 2 for a description of the page content.

    • Activities tab. See Table 3 for a description of the page content.

Table 2: Statistics Tab Output in the Threats Report

Field

Description

General Statistics Pane

Threat Category

One of the following categories of threats:

  • Traffic

  • IDP

  • Content Security

    • Antivirus

    • Antispam

    • Web Filter—Click the Web filter category to display counters for 39 subcategories.

    • Content Filter

  • Firewall Event

Severity

Severity level of the threat:

  • emerg

  • alert

  • crit

  • err

  • warning

  • notice

  • info

  • debug

Hits in past 24 hours

Number of threats encountered per category in the past 24 hours.

Hits in current hour

Number of threats encountered per category in the last hour.

Threat Counts in the Past 24 Hours

By Severity

Graph representing the number of threats received each hour for the past 24 hours sorted by severity level.

By Category

Graph representing the number of threats received each hour for the past 24 hours sorted by category.

X Axis

Twenty-four hour span with the current hour occupying the right-most column of the display. The graph shifts to the left every hour.

Y Axis

Number of threats encountered. The axis automatically scales based on the number of threats encountered.

Most Recent Threats

Threat Name

Names of the most recent threats. Depending on the threat category, you can click the threat name to go to a scan engine site for a threat description.

Category

Category of each threat:

  • Traffic

  • IDP

  • Content Security

    • Antivirus

    • Antispam

    • Web Filter

    • Content Filter

  • Firewall Event

Source IP/Port

Source IP address (and port number, if applicable) of the threat.

Destination IP/Port

Destination IP address (and port number, if applicable) of the threat.

Protocol

Protocol name of the threat.

Description

Threat identification based on the category type:

  • Antivirus—URL

  • Web filter—category

  • Content filter—reason

  • Antispam—sender e-mail

Action

Action taken in response to the threat.

Hit Time

Time the threat occurred.

Threat Trend in past 24 hours

Category

Pie chart graphic representing comparative threat counts by category:

  • Traffic

  • IDP

  • Content Security

    • Antivirus

    • Antispam

    • Web Filter

    • Content Filter

  • Firewall Event

Web Filter Counters Summary

Category

Web filter count broken down by up to 39 subcategories. Clicking on the Web filter listing in the General Statistics pane opens the Web Filter Counters Summary pane.

Hits in past 24 hours

Number of threats per subcategory in the last 24 hours.

Hits in current hour

Number of threats per subcategory in the last hour.

Table 3: Activities Tab Output in the Threats Report

Field

Function

Most Recent Virus Hits

Threat Name

Name of the virus threat. Viruses can be based on services, like Web, FTP, or e-mail, or based on severity level.

Severity

Severity level of each threat:

  • emerg

  • alert

  • crit

  • err

  • warning

  • notice

  • info

  • debug

Source IP/Port

IP address (and port number, if applicable) of the source of the threat.

Destination IP/Port

IP address (and port number, if applicable) of the destination of the threat.

Protocol

Protocol name of the threat.

Description

Threat identification based on the category type:

  • Antivirus—URL

  • Web filter—category

  • Content filter—reason

  • Antispam—sender e-mail

Action

Action taken in response to the threat.

Last Hit Time

Last time the threat occurred.

Most Recent Spam E-Mail Senders

From e-mail

E-mail address that was the source of the spam.

Severity

Severity level of the threat:

  • emerg

  • alert

  • crit

  • err

  • warning

  • notice

  • info

  • debug

Source IP

IP address of the source of the threat.

Action

Action taken in response to the threat.

Last Send Time

Last time that the spam e-mail was sent.

Recently Blocked URL Requests

URL

URL request that was blocked.

Source IP/Port

IP address (and port number, if applicable) of the source.

Destination IP/Port

IP address (and port number, if applicable) of the destination.

Hits in current hour

Number of threats encountered in the last hour.

Most Recent IDP Attacks

Attack

Severity

Severity of each threat:

  • emerg

  • alert

  • crit

  • err

  • warning

  • notice

  • info

  • debug

Source IP/Port

IP address (and port number, if applicable) of the source.

Destination IP/Port

IP address (and port number, if applicable) of the destination.

Protocol

Protocol name of the threat.

Action

Action taken in response to the threat.

Last Send Time

Last time the IDP threat was sent.

Traffic Monitoring Report

Purpose

Monitor network traffic by reviewing reports of flow sessions over the past 24 hours. You can analyze logging data for connection statistics and session usage by a transport protocol.

Action

To view network traffic in the past 24 hours, select Monitor>Reports>Traffic in the J-Web user interface. See Table 4 for a description of the report.

Table 4: Traffic Report Output

Field

Description

Sessions in Past 24 Hours per Protocol

Protocol Name

Name of the protocol. To see hourly activity by protocol, click the protocol name and review the “Protocol activities chart” in the lower pane.

  • TCP

  • UDP

  • ICMP

Total Session

Total number of sessions for the protocol in the past 24 hours.

Bytes In (KB)

Total number of incoming bytes in KB.

Bytes Out (KB)

Total number of outgoing bytes in KB.

Packets In

Total number of incoming packets.

Packets Out

Total number of outgoing packets.

Most Recently Closed Sessions

Source IP/Port

Source IP address (and port number, if applicable) of the closed session.

Destination IP/Port

Destination IP address (and port number, if applicable) of the closed session.

Protocol

Protocol of the closed session.

  • TCP

  • UDP

  • ICMP

Bytes In (KB)

Total number of incoming bytes in KB.

Bytes Out (KB)

Total number of outgoing bytes in KB.

Packets In

Total number of incoming packets.

Packets Out

Total number of outgoing packets.

Timestamp

The time the session was closed.

Protocol Activities Chart

Bytes In/Out

Graphic representation of traffic as incoming and outgoing bytes per hour. The byte count is for the protocol selected in the Sessions in Past 24 Hours per Protocol pane. Changing the selection causes this chart to refresh immediately.

Packets In/Out

Graphic representation of traffic as incoming and outgoing packets per hour. The packet count is for the protocol selected in the Sessions in Past 24 Hours per Protocol pane. Changing the selection causes this chart to refresh immediately.

Sessions

Graphic representation of traffic as the number of sessions per hour. The session count is for the protocol selected in the Sessions in Past 24 Hours per Protocol pane. Changing the selection causes this chart to refresh immediately.

X Axis

One hour per column for 24 hours.

Y Axis

Byte, packet, or session count.

Protocol Session Chart

Sessions by Protocol

Graphic representation of the traffic as the current session count per protocol. The protocols displayed are TCP, UDP, and ICMP.

Configuring On-Box Binary Security Log Files

SRX Series devices use two types of logs—system logs and security logs—to record system events. System logs record control plane events—for example, when an admin user logs in. Security logs, also known as traffic logs, record data plane events regarding specific traffic handling. For example, Junos OS generates a security log if a security policy denies certain traffic because of a policy violation. For more about system logs, see Junos OS System Log Overview. For more information about security logs, see Understanding System Logging for Security Devices.

You can collect and save both system and security logs in binary format either on-box (that is, stored locally on the SRX Series device) or off-box (streamed to a remote device). Using binary format ensures that log files are efficiently stored, which in turn improves CPU utilization.

You can configure security files in binary format using the log statement at the [security] hierarchy level.

On-box logging is also known as event-mode logging. For stream-mode, off-box security logging, see Configuring Off-Box Binary Security Log Files. When you configure security logs in binary format for event-mode logging, you can optionally define the log filename, file path, and other characteristics, as detailed in the following procedure:

  1. Specify the logging mode and format for on-box logging::
    Note

    If you configure system logging to send system logs to an external destination (that is, off-box or stream-mode), security logs are also sent to that destination even if you are using event-mode security logging. For more information about sending system logs to an external destination, see Examples: Configuring System Logging.

    Note

    Off-box and on-box security logging modes cannot be enabled simultaneously.

  2. (Optional) Define a name and path for the log file. Note

    By default, the bin_messages file is created in the /var/log directory.

  3. (Optional) Change the maximum size of the log file and the maximum number of log files that can be archived. Note

    By default, the maximum size of the log file is 3 MB, and a total of three log files can be archived.

    In the following sample commands, you set a value of 5 MB and 5 archived files, respectively:

  4. (Optional) Configure the hpl flag to enable diagnostic traces for the binary security log files. The smf_hpl prefix identifies all binary logging traces.
  5. For the default-permit security policy, traffic logs for RT_FLOW are generated when a session ends.
  6. (Optional) Traffic logs for RT_FlOW are generated when a session starts.

View the content of the event-mode log file stored on the device using show security log file command and use clear security log file command to clear the content of the binary event-mode security log file.

Note

The show security log command displays event-mode security log messages if they are in a text-based format and the show security log file command displays event-mode security log messages if they are in binary format (on-box). Off-box binary logging is read by Juniper Secure Analytics (JSA).

Configuring Off-Box Binary Security Log Files

SRX Series devices have two types of log: system logs and security logs. System logs record control plane events, for example admin login to the device. For more about system logs, please see Junos OS System Log Overview. Security logs, also known as traffic logs, record data plane events regarding specific traffic handling, for example when a security policy denies certain traffic due to some violation of the policy. For more information about security logs, please see Understanding System Logging for Security Devices.

The two types of log can be collected and saved either on-box or off-box. The procedure below explains how to configure security logs in binary format for off-box (stream-mode) logging.

You can configure security files in binary format using the log statement at the [security] hierarchy level.

The following procedure specifies binary format for stream-mode security logging, and defines the log filename, path, and log file characteristics. For event-mode, on-box security logging, please see Configuring On-Box Binary Security Log Files.

  1. Specify the logging mode and the format for the log file. For off-box, stream-mode logging:
    Note

    Off-box and on-box security logging modes cannot be enabled simultaneously.

  2. For off-box security logging, specify the source address, which identifies the SRX Series device that generated the log messages. The source address is required.
  3. Optionally, define a log filename and a path. By default, the file bin_messages is created in the /var/log directory.
  4. Optionally, change the maximum size of the log file and the maximum number of log files that can be archived. By default the maximum size of the log file is 3 MB, and a total of three log files can be archived.
  5. Optionally, select the hpl flag to enable diagnostic traces for binary logging. The prefix smf_hpl identifies all binary logging traces.
  6. View the content of the event-mode log file stored on the device using either Juniper Secure Analytics (JSA) or Security Threat Response Manager (STRM).

Sending System Log Messages to a File

You can direct system log messages to a file on the CompactFlash (CF) card. The default directory for log files is /var/log. To specify a different directory on the CF card, include the complete pathname.

Create a file named security, and send log messages of the authorization class at the severity level info to the file.

To set the filename, the facility, and severity level:

Setting the System to Send All Log Messages Through eventd

The eventd process of logging configuration is most commonly used for Junos OS. In this configuration, control plane logs and data plane, or security, logs are forwarded from the data plane to the Routing Engine control plane rtlogd process. The rtlogd process then either forwards syslog or sd-syslog-formatted logs to the eventd process or the WELF-formatted logs to the external or remote WELF log collector.

To send all log messages through eventd:

  1. Set the eventd process to handle security logs and send them to a remote server.
  2. Configure the server that will receive the system log messages.

    where hostname is the fully qualified hostname or IP address of the server that will receive the logs.

Note

To send duplicate logs to a second remote server, repeat the command with a new fully qualified hostname or IP address of a second server.

If your deployment is an active/active chassis cluster, you can also configure security logging on the active node to be sent to separate remote servers to achieve logging redundancy.

To rename or redirect one of the logging configurations, you need to delete and recreate it. To delete a configuration:

Release History Table
Release
Description
Starting with Junos OS Release 15.1X49-D100, the default mode for SRX1500 device is stream mode. Prior to Junos OS Release 15.1X49-D100, the default mode for SRX1500 device was event mode.
Starting in Junos OS Release 17.4R2 and later, on SRX300, SRX320, SRX340, SRX345 Series devices and vSRX instances, when the device is configured in stream mode, you can configure maximum of eight system log hosts.

In Junos OS Release 17.4R2 and earlier releases, you can configure only three system log hosts in the stream mode. If you configure more than three system log hosts, then the following error message is displayed error: configuration check-out failed.
Starting in Junos OS Release 17.4R2 and later, on SRX300, SRX320, SRX340, SRX345 Series devices and vSRX instances, when the device is configured in stream mode, you can configure maximum of eight system log hosts.

In Junos OS Release 17.4R2 and earlier releases, you can configure only three system log hosts in the stream mode. If you configure more than three system log hosts, then the following error message is displayed error: configuration check-out failed.
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.
Starting in Junos OS Release 19.3R1, SRX300, SRX320, SRX340, SRX345, SRX550, and SRX550M devices default to stream mode.
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.