Log Event Extended Format (LEEF)

NXLog Enterprise Edition exclusive feature

The IBM Security QRadar LEEF format supports syslog as a transport. It describes an event using predefined attributes in the form of key-value pairs. Additional custom attributes can be used to include application-specific information.

NXLog Enterprise Edition can be configured to collect or forward logs in the LEEF format.

LEEF components

According to IBM QRadar: Log Event Extended Format (LEEF), Version 2, this proprietary format consists of the following components:

Syslog header: Contains the timestamp followed by the IPv4 address or hostname of the event source. An optional numeric priority tag containing no more than 3 digits enclosed in angle brackets (< >) can be specified as the first element. The header must conform to either RFC 3164 or RFC 5424.
LEEF header: A list typically comprised of five pipe-delimited values for LEEF version, vendor, source, product version, event ID, and an optional sixth value, delimiter, which can also be expressed as a hexadecimal value prefixed by 0x in LEEF version 2.0. The syslog header and LEEF header are separated by a single space. The last character of the LEEF header must a pipe (|).
Event attributes: A list of key-value pairs immediately following the last pipe character of the LEEF header, each having the syntax key=value. By default, each pair in the list is separated by a tab character. Otherwise, the pairs must be separated by the delimiter character that was defined as the last element of the LEEF header.

Syslog LEEF format template

<PRI>Timestamp Hostname LEEF:Version|Vendor|Product|Version|EventID|Delimiter|key1=value1 key2=value2

Each row of the following table represents a complete, single-line LEEF event.

Table 1. LEEF sample events by component
Syslog header	LEEF header	Event attributes
`May 11 11:27:23 SERVER-1`	`LEEF:2.0\|Microsoft\|MSExchange\|2016\|15345\|`	`src=10.50.1.1 dst=2.10.20.20 spt=1200`
`<13>Jun 6 05:34:55 SERVER-1`	`LEEF:2.0\|NXLog\|MyApp\|5.5.7535\|91\|0x09\|`	`SourceModuleName=json_logs Message=Module app-sched suspended LogLevel=WARNING`
`<13>1 2019-01-18T11:07:53.520Z 10.0.1.7`	`LEEF:1.0\|Microsoft\|MSExchange\|2013 SP1\|15345\|`	`src=10.0.1.7 dst=10.0.0.5 sev=5 srcPort=81 dstPort=21`
`<113>1 2019-01-18T11:07:53.520+07:00 hostname4`	`LEEF:2.0\|Lancope\|StealthWatch\|1.0\|41\|^\|`	`src=10.0.1.8^dst=10.0.0.5^sev=5^srcPort=81^dstPort=21`

The first two events conform to RFC 3164, while the last two follow RFC 5424.
The priority tag of 13 for the events on rows 2 and 3 represents Facility 1 (user-level messages), Severity 5 (Notice: normal but significant condition).
The priority tag of 113 for the event on the last row represents Facility 14 (log alert), Severity 1 (Alert: action must be taken immediately).
See either section 4.1.1 PRI Part of RFC 3164 or section 6.2.1. PRI of RFC 5424 for how to decode Facility and Severity from priority tags.

LEEF sample events in RAW format

May 11 11:27:23 SERVER-1 LEEF:2.0|Microsoft|MSExchange|2016|15345|src=10.50.1.1	dst=2.10.20.20	spt=1200
<13>Jun  6 05:34:55 SERVER-1 LEEF:2.0|NXLog|MyApp|5.5.7535|91|0x09|SourceModuleName=json_logs	Message=Module app-sched suspended	LogLevel=WARNING
<13>1 2019-01-18T11:07:53.520Z 10.0.1.7 LEEF:1.0|Microsoft|MSExchange|2013 SP1|15345|src=10.0.1.7 dst=10.0.0.5 sev=5 srcPort=81 dstPort=21
<113>1 2019-01-18T11:07:53.520+07:00 hostname4 LEEF:2.0|Lancope|StealthWatch|1.0|41|^|src=10.0.1.8^dst=10.0.0.5^sev=5^srcPort=81^dstPort=21

Sending LEEF logs

NXLog Enterprise Edition can generate LEEF logs using the to_leef() procedure of the xm_leef extension module.

Example 1. Converting logs to LEEF format

With this configuration, NXLog collects systemd logs using the im_systemd module, converts them to LEEF format, and saves the result to a file.

nxlog.conf

<Extension leef>
    Module   xm_leef
</Extension>

<Input systemd>
    Module   im_systemd
</Input>

<Output to_leef>
    Module   om_file
    File     "/var/log/systemd_output.log"
    Exec     to_leef();
</Output>

Output sample

<13>Aug 19 10:30:01 centos7_server systemd[1]: LEEF:2.0|NXLog|systemd|5.5.7535|unknown|0x09|Severity=info	sev=10	Facility=daemon	FacilityValue=3	Message=Removed slice User Slice of root.	MessageID=9d1aaa27d60140bd96365438aad20286	vSrcName=systemd	CodeFile=src/core/job.c	CodeLine=781	ProcessID=1	User=root	Group=root	ProcessName=systemd	ProcessExecutable=/usr/lib/systemd/systemd	ProcessCmdLine=/usr/lib/systemd/systemd --switched-root --system --deserialize 22	Capabilities=1fffffffff SystemdCGroup=/	SelinuxContext=system_u:system_r:init_t:s0	devTime=2022-08-19 10:30:01	BootID=feff0db8902d41ccba9fd1538f51305e	MachineID=5f4fbea6502f45c4a1af4d69be37942b	identHostName=centos7_server	Transport=journal	EventReceivedTime=2022-08-19 10:30:01	SourceModuleName=systemd	SourceModuleType=im_systemd	devTimeFormat=yyyy-MM-dd HH:mm:ss

Collecting LEEF logs

NXLog Enterprise Edition can parse the LEEF log format with the xm_leef module’s parse_leef() procedure.

Example 2. Collecting LEEF logs via TCP

With the following configuration, NXLog listens for LEEF events using the im_tcp input module, converts them to JSON format, and saves the result to a file.

nxlog.conf

<Extension json>
    Module        xm_json
</Extension>

<Extension leef>
    Module        xm_leef
</Extension>

<Input tcp>
    Module        im_tcp
    ListenAddr    0.0.0.0:514
    Exec          parse_leef();
</Input>

<Output to_file>
    Module        om_file
    File          "/var/log/leef_output.json"
    Exec          to_json();
</Output>

Input sample

<13>Aug 19 10:30:01 centos7_server systemd[1]: LEEF:2.0|NXLog|systemd|5.5.7535|unknown|0x09|Severity=info	sev=10	Facility=daemon	FacilityValue=3	Message=Removed slice User Slice of root.	MessageID=9d1aaa27d60140bd96365438aad20286	vSrcName=systemd	CodeFile=src/core/job.c	CodeLine=781	ProcessID=1	User=root	Group=root	ProcessName=systemd	ProcessExecutable=/usr/lib/systemd/systemd	ProcessCmdLine=/usr/lib/systemd/systemd --switched-root --system --deserialize 22	Capabilities=1fffffffff SystemdCGroup=/	SelinuxContext=system_u:system_r:init_t:s0	devTime=2022-08-19 10:30:01	BootID=feff0db8902d41ccba9fd1538f51305e	MachineID=5f4fbea6502f45c4a1af4d69be37942b	identHostName=centos7_server	Transport=journal	EventReceivedTime=2022-08-19 10:30:01	SourceModuleName=systemd	SourceModuleType=im_systemd	devTimeFormat=yyyy-MM-dd HH:mm:ss

Output sample

{
  "MessageSourceAddress": "192.168.0.101",
  "EventReceivedTime": "2022-08-19 02:30:01",
  "SourceModuleName": "systemd",
  "SourceModuleType": "im_systemd",
  "Hostname": "192.168.0.101",
  "LEEFVersion": "LEEF:2.0",
  "Vendor": "NXLog",
  "SourceName": "systemd",
  "Version": "5.5.7535",
  "EventID": "unknown",
  "DelimiterCharacter": 9,
  "Severity": "info",
  "SeverityValue": 5,
  "Facility": "daemon",
  "FacilityValue": "3",
  "Message": "Removed slice User Slice of root.",
  "MessageID": "9d1aaa27d60140bd96365438aad20286",
  "CodeFile": "src/core/job.c",
  "CodeLine": "781",
  "ProcessID": "1",
  "User": "root",
  "Group": "root",
  "ProcessName": "systemd",
  "ProcessExecutable": "/usr/lib/systemd/systemd",
  "ProcessCmdLine": "/usr/lib/systemd/systemd --system --deserialize 21",
  "Capabilities": "1fffffffff",
  "SystemdCGroup": "/",
  "SelinuxContext": "system_u:system_r:init_t:s0",
  "EventTime": "2022-08-19T02:30:01.000000+03:00",
  "BootID": "1494e2ff49134259b9ee0b59b95e92c9",
  "MachineID": "5f4fbea6502f45c4a1af4d69be37942b",
  "Transport": "journal",
  "devTimeFormat": "yyyy-MM-dd HH:mm:ss"
}

Disclaimer

While we endeavor to keep the information in this topic up to date and correct, NXLog makes no representations or warranties of any kind, express or implied about the completeness, accuracy, reliability, suitability, or availability of the content represented here. We update our screenshots and instructions on a best-effort basis.

The accurateness of the content was tested and proved to be working in our lab environment at the time of the last revision with the following software versions:

NXLog EE 5.5.7535
Ubuntu 20.04.4 LTS
Centos 7

Last revision: 23 August 2022