[SRX] Traffic logging configuration for logical system using local file

Overview of Logical Systems

Logical systems include both master and user logical systems and their administrators. When the master administrator creates a user logical system, a user logical system administrator is assigned to manage it. User logical systems are self-contained, private contexts, separate both from one another and from the master logical system. A user logical system has its own security, networking, logical interfaces, routing configurations, and one or more user logical system administrators. The user logical systems will have a default routing table [inet.0] and/or routing instance

Notes:

You can configure ONLY "virtual router" routing instance type in a user logical system
Only the master administrator can configure logging at the [edit security log] hierarchy level. User logical system administrators cannot configure logging for their logical systems.

Overview of Security Profiles

Security profiles for logical systems allow you to allocate resources. Security profiles specifies the number of resources to allocate to a logical system to which the security profile is bound. All system resources are allocated to master logical system and the master administrator allocates them to user logical system using security profile. KB34626 - Limitation for syslog server configuration under stream mode shows the maximum number of streams that can be created for each SRX device.

Overview of Traffic Logs

Security logs (also known as traffic logs) can log traffic such as Session traffic (session-create, session-close, session-deny), UTM traffic (utm-content-filter, utm-webfilter-permitted, utm-webfilter-blocked, utm-anti-spam, utm-anti-virus), IDP logs, Screen logs and IPSEC-VPN logs. The traffic logs can be generated by two modes: Stream or Event. Event mode will send the logs to the RE for processing while Stream mode requires streams which will mention if the log will be saved in a file locally or sent to a remote server. When the logging mode is set to stream, security logs generated in the data plane are streamed out a revenue traffic port directly to a remote server or stored in a binary file, in any case, action is performed by PFE. The maximum number of streams [as configured in security logs] for a logical system is governed by resource "security-log-stream-number" in secusrity profile. There are two quotas in security profile for a resource, reserved and maximum. If security profile doesn't mention the "security-log-stream-number" in reserved quota, the default value is 0 which is global system quota for the resource.

Notes:

Traffic logs for logical systems using remote server was supported since 18.2R1 onwards. The command "set logical-system <LSYS-name> security log" was introduced in release RLI 36610. This RLI added support only for traffic logging using remote server and not for logging using local file. Source - Technical documentation on log (Logical Systems and Tenant Systems)
Traffic logging for logical system using local file was supported since 19.2R1 onwards. The command "set logical-system <LSYS-name> security log file" and "set logical-system <LSYS-name> security log stream <stream-name> file" was introduced in this release [RLI40291-1]. The log file can be created using both the modes, event as well stream mode, but only one mode can be used at a time for security log in logical system. Stream mode can create files in all available formats [sd-syslog, syslog and binary] and event mode can create file in binary format only. Source - Technical documentation on Logical Systems and Tenant Systems

Configuration for Traffic Logs for Local File

The configuration below uses stream mode to create a local file test1.bin. This file will store the traffic logs. The format used here is binary. Other formats such as syslog and sd-syslog can be used as well.

root@vSRX3:LSYS1> show configuration security log | display set 
set logical-systems LSYS1 security log mode stream
set logical-systems LSYS1 security log stream S6 format binary
set logical-systems LSYS1 security log stream S6 file name test1.bin

There are many methods to validate that file is created and actively able to store the logs. Below are some of the most common and known methods.

Method 1: Check the stream log file directly using CLI command

root@vSRX3:LSYS1> show security log stream file test1.bin 

<14>1 2020-09-06T23:08:05 vSRX3 RT_FLOW - RT_FLOW_SESSION_CREATE_LS [junos@2636.1.1.1.2.129 logical-system-name="LSYS1" source-address="6.6.6.8" source-port="2495" destination-address="192.168.3.1" destination-port="2810" connection-tag="0" service-name="icmp" nat-source-address="6.6.6.8" nat-source-port="2495" nat-destination-address="192.168.3.1" nat-destination-port="2810" nat-connection-tag="0" src-nat-rule-type="N/A" src-nat-rule-name="N/A" dst-nat-rule-type="N/A" dst-nat-rule-name="N/A" protocol-id="1" policy-name="allowAll" source-zone-name="trust" destination-zone-name="trust" session-id-32="1459925" username="N/A" roles="N/A" packet-incoming-interface="gr-0/0/0.0" application="UNKNOWN" nested-application="UNKNOWN" encrypted="UNKNOWN" application-category="N/A" application-sub-category="N/A" application-risk="-1" application-characteristics="N/A" src-vrf-grp="N/A" dst-vrf-grp="N/A"]
<14>1 2020-09-06T23:08:06 vSRX3 RT_FLOW - RT_FLOW_SESSION_CREATE_LS [junos@2636.1.1.1.2.129 logical-system-name="LSYS1" source-address="6.6.6.8" source-port="2495" destination-address="192.168.3.1" destination-port="2811" connection-tag="0" service-name="icmp" nat-source-address="6.6.6.8" nat-source-port="2495" nat-destination-address="192.168.3.1" nat-destination-port="2811" nat-connection-tag="0" src-nat-rule-type="N/A" src-nat-rule-name="N/A" dst-nat-rule-type="N/A" dst-nat-rule-name="N/A" protocol-id="1" policy-name="allowAll" source-zone-name="trust" destination-zone-name="trust" session-id-32="1459931" username="N/A" roles="N/A" packet-incoming-interface="gr-0/0/0.0" application="UNKNOWN" nested-application="UNKNOWN" encrypted="UNKNOWN" application-category="N/A" application-sub-category="N/A" application-risk="-1" application-characteristics="N/A" src-vrf-grp="N/A" dst-vrf-grp="N/A"]

Method 2: Check if the stream bytes are increasing for the mentioned stream name. Notice the name of stream [S6] and amount of txByte increased. The commands were executed immediately in below order.

root@vSRX3> request pfe execute target fwdd command "show usp rtlog streams LSYS1" | match "name|txByte"

0: name = S6, file_name = test1.bin, file_flag = 0x1, codec = 5, sev = 7
     tx = 3424, txByte = 9501600, txFail = 0, dropByte = 0, db_idx_DropCnt = 0

root@vSRX3> request pfe execute target fwdd command "show usp rtlog streams LSYS1" | match "name|txByte"    
0: name = S6, file_name = test1.bin, file_flag = 0x1, codec = 5, sev = 7
     tx = 3433, txByte = 9526575, txFail = 0, dropByte = 0, db_idx_DropCnt = 0

Method 3: The log file [test1.bin] is created under location /var/traffic-log/logical-systems/LSYS1/test1.bin. Check the status of last modified for the stream log file in shell.

The stream log file can be cleared as well. The command can be seen below:

root@vSRX3:LSYS1> clear security log stream file test1.bin    
Result: request to clear log stream file succeeds.

The configuration below uses event mode to create a local file test1.bin. This file will store the traffic logs in binary format.

root@vSRX3:LSYS1> show configuration security log | display set 
set logical-systems LSYS1 security log mode event
set logical-systems LSYS1 security log format binary
set logical-systems LSYS1 security log file name test4.bin

There are many methods to validate that file is created and actively able to store the logs. Below are some of the most common and known methods.

Method 1: Check the log file directly using CLI command

root@vSRX3:LSYS1> show security log file test4.bin 

<14>1 2020-09-07T00:22:43 vSRX3 RT_FLOW - RT_FLOW_SESSION_CREATE_LS [junos@2636.1.1.1.2.129 logical-system-name="LSYS1" source-address="6.6.6.8" source-port="2495" destination-address="192.168.3.1" destination-port="7277" connection-tag="0" service-name="icmp" nat-source-address="6.6.6.8" nat-source-port="2495" nat-destination-address="192.168.3.1" nat-destination-port="7277" nat-connection-tag="0" src-nat-rule-type="N/A" src-nat-rule-name="N/A" dst-nat-rule-type="N/A" dst-nat-rule-name="N/A" protocol-id="1" policy-name="allowAll" source-zone-name="trust" destination-zone-name="trust" session-id-32="1479733" username="N/A" roles="N/A" packet-incoming-interface="gr-0/0/0.0" application="UNKNOWN" nested-application="UNKNOWN" encrypted="UNKNOWN" application-category="N/A" application-sub-category="N/A" application-risk="-1" application-characteristics="N/A" src-vrf-grp="N/A" dst-vrf-grp="N/A"]
<14>1 2020-09-07T00:22:44 vSRX3 RT_FLOW - RT_FLOW_SESSION_CREATE_LS [junos@2636.1.1.1.2.129 logical-system-name="LSYS1" source-address="6.6.6.8" source-port="2495" destination-address="192.168.3.1" destination-port="7278" connection-tag="0" service-name="icmp" nat-source-address="6.6.6.8" nat-source-port="2495" nat-destination-address="192.168.3.1" nat-destination-port="7278" nat-connection-tag="0" src-nat-rule-type="N/A" src-nat-rule-name="N/A" dst-nat-rule-type="N/A" dst-nat-rule-name="N/A" protocol-id="1" policy-name="allowAll" source-zone-name="trust" destination-zone-name="trust" session-id-32="1479738" username="N/A" roles="N/A" packet-incoming-interface="gr-0/0/0.0" application="UNKNOWN" nested-application="UNKNOWN" encrypted="UNKNOWN" application-category="N/A" application-sub-category="N/A" application-risk="-1" application-characteristics="N/A" src-vrf-grp="N/A" dst-vrf-grp="N/A"]

Method 2: The log file [test4.bin] is created under location /var/logical-systems/LSYS1/log/test4.bin. Check the status of last modified for the log file in shell.

The log file created by EVENTD can be cleared as well. The command for the same can be seen below:

root@vSRX3:LSYS1> clear security log file test4.bin    
Result: request to clear log file succeeds.

Knowledge Base