JSON Data Format¶
This page will guide you through the JSON logs format produced by Clear NDR® Central Server and details the different fields and values combination.
Example:
{
"timestamp": "2009-11-24T21:27:09.534255",
"event_type": "alert",
"src_ip": "192.168.2.7",
"src_port": 1041,
"dest_ip": "x.x.250.50",
"dest_port": 80,
"proto": "TCP",
"alert": {
"action": "allowed",
"gid": 1,
"signature_id" :2001999,
"rev": 9,
"signature": "ET MALWARE BTGrab.com Spyware Downloading Ads",
"category": "A Network Trojan was detected",
"severity": 1
}
}
Common Section¶
All the JSON log types share a common structure:
{"timestamp":"2009-11-24T21:27:09.534255","event_type":"TYPE", ...tuple... ,"TYPE":{ ... type specific content ... }}
Event types¶
The common part has a field “event_type” to indicate the log type.
"event_type":"TYPE"
Possible values are: STAMUS, ALERTS, ANOMALY, DCERPC, DHCP, DNP3, DNS, Fileinfo, FLOW, FTP, FTP_DATA, HTTP, IKE, KRB5, MQTT, NETFLOW, NFS, RDP, RFB, SIP, SMB, SMTP, SNMP, STATS, SSH, TFTP, TLS
PCAP fields¶
If Suricata is processing a pcap file, additional fields are added:
"pcap_cnt": 123
pcap_cnt
contains the packet number in the pcap. This can be used to look
up a packet in Wireshark for example.
"pcap_filename":"/path/to/file.pcap"
pcap_filename
contains the file name and location of the pcap that
generated the event.
Note
the pcap fields are only available on “real” packets, and are omitted from internal “pseudo” packets such as flow timeout packets.
Alert Events¶
Possible values: “allowed” and “blocked”
Example:
"action":"allowed"
Action is set to “allowed” unless when the rule is used the “reject” action.
It can contain information about Source and Target of the attack in the alert.source and alert.target field it target keyword is used in the signature.
"alert": {
"action": "allowed",
"gid": 1,
"signature_id": 1,
"rev": 1,
"app_proto": "http",
"signature": "HTTP body talking about corruption",
"severity": 3,
"source": {
"ip": "192.168.43.32",
"port": 36292
},
"target": {
"ip": "179.60.192.3",
"port": 80
},
Stamus Events¶
Events with the event_type stamus
are part of a Declaration of Compromise® or a Declaration of Policy Violation®.
See Declaration of Compromise® and Declaration of Policy Violation® for more information on the concept.
A typical Stamus event will have regular common fields and a “stamus” section that looks like this:
"stamus": {
"extra_info": null,
"source": "192.168.2.23",
"family_name": "Lateral Movement",
"incidents_id": [71],
"threat_id": 399,
"asset_net_info": "wifi-users-hq.organization-acme",
"pk": 3581,
"asset_info": {
"first_seen": "2025-07-24T02:40:34.968258Z",
"last_seen": "2025-07-24T02:40:44.977144Z",
"event_id": 88,
"incident_id": 71,
"kill_chain": "delivery",
"state": "ongoing"
},
"method_id": 1002026992,
"family_type": "family",
"event_id": 88,
"offender_type": "ip",
"asset_type": "ip",
"family_id": 7,
"threat_name": "Powershell",
"asset": "192.168.100.60",
"kill_chain": "delivery"
}
Fields
asset
: The asset that is the subject/victim of this event. This can be an IP address, a hostname, a mail, or a user.asset_type
: The type of the asset, such as “ip”, “hostname”, or “user”.asset_net_info
: Network definition information about the assetoffender
: The offender that took part in this event. This can be an IP address, a hostname, a mail, or a user.offender_type
: The type of the offender, such as “ip”, “hostname”, or “user”.threat_name
: The name of the threat associated with this event.family_name
: The name of the family this threat belongs to.kill_chain
: The kill chain phase this event is associated with. This can be “pre_condition”, “delivery”, “exploitation”, “installation”, “command_and_control”, or “action_on_objectives”. “pre_condition” is used for Declarations of Policy Violations, while the other phases are used for Declarations of Compromise.incidents_id
: List of incident IDs this event is associated with. This corresponds to the Declaration of Compromise or Declaration of Policy Violation linked to this event. There will be two elements in the list if the offender is tracked.threat_id
: The unique identifier of the threat associated with this event. See Deep linking to DoC/DOPV GUI for more information on how to link to the GUI of Clear NDR®.family_id
: The unique identifier of the family this threat belongs to. See Deep linking to DoC/DOPV GUI for more information on how to link to the GUI of Clear NDR®.method_id
: The unique identifier of the detection method that triggered this event.asset_info
: information about the assetfirst_seen
: The first time the threat was seen on this asset.last_seen
: The last time the threat was seen on this asset.state
: The state of the asset in relation to the threat. The value can be “new” (initial discovery of threat on asset), “ongoing” (proof of threat activity on asset), or “kill_chain_increase” (threat activity has reached a new step in the kill chain).kill_chain
: The highest kill chain phase seen for this threat on the asset. This can be “pre_condition”, “delivery”, “exploitation”, “installation”, “command_and_control”, or “action_on_objectives”. “pre_condition” is used for Declarations of Policy Violations, while the other phases are used for Declarations of Compromise.incident_id
: The incident ID this event is associated with on the asset side. This corresponds to the Declaration of Compromise or Declaration of Policy Violation linked to this event.event_id
: unique identifier of the occurences of a given detection method triggering on a given asset.
In the case of a threat where the offender is also tracked (some Lateral Movement, for example), the following fields are also present:
offender_info
: information about the offenderfirst_seen
: The first time the threat was seen on the offender.last_seen
: The last time the threat was seen on the offender.state
: The state of the offender in relation to the threat. The value can be “new” (initial discovery of threat on offender), “ongoing” (proof of threat activity on offender), or “kill_chain_increase” (threat activity has reached a new step in the kill chain).kill_chain_offender
: The highest kill chain phase seen for this threat triggered by the offender. This can be “delivery”, “exploitation”, “installation”, “command_and_control”, or “action_on_objectives”.incident_id
: The incident ID this event is associated with on the offender side. This corresponds to the Declaration of Compromise linked to this event.event_id
: unique identifier of the occurences of a given detection method triggered by a given offender.
Anomaly Events¶
Events with type “anomaly” report unexpected conditions such as truncated packets, packets with invalid values, events that render the packet invalid for further processing or unexpected behaviors.
Networks which experience high occurrences of anomalies may experience packet processing degradation when anomaly logging is enabled.
Fields
type
: Either “decode”, “stream” or “applayer”. In rare cases, type will be “unknown”. When this occurs, an additional field named “code” will be present. Events with type “applayer” are detected by the application layer parsers.event
: The name of the anomalous event. Events of type “decode” are prefixed with “decoder”; events of type “stream” are prefixed with “stream”.code
: If “type” is “unknown”, than “code” contains the unrecognized event code. Otherwise, this field is not present.
The following field is included when “type” has the value “applayer”:
layer
: Indicates the handling layer that detected the event. This will be “proto_parser” (protocol parser), “proto_detect” (protocol detection) or “parser.”
When packethdr
is enabled, the first 32 bytes of the packet are included
as a byte64-encoded blob in the main part of record. This applies to events
of “type” “packet” or “stream” only.
Examples
"anomaly": {
"type": "decode",
"event": "decoder.icmpv4.unknown_type"
}
"anomaly": {
"type": "decode",
"event": "decoder.udp.pkt_too_small"
}
"anomaly": {
"type": "decode",
"event": "decoder.ipv4.wrong_ip_version"
}
"anomaly": {
"type": "stream",
"event": "stream.pkt_invalid_timestamp"
}
{
"timestamp": "1969-12-31T16:04:21.000000-0800",
"pcap_cnt": 9262,
"event_type": "anomaly",
"src_ip": "208.21.2.184",
"src_port": 0,
"dest_ip": "10.1.1.99",
"dest_port": 0,
"proto": "UDP",
"packet": "////////AQEBAQEBCABFAAA8xZ5AAP8R1+DQFQK4CgE=",
"packet_info": {
"linktype": 1
},
"anomaly": {
"type": "decode",
"event": "decoder.udp.pkt_too_small"
}
}
{
"timestamp": "2016-01-11T05:10:54.612110-0800",
"flow_id": 412547343494194,
"pcap_cnt": 1391293,
"event_type": "anomaly",
"src_ip": "192.168.122.149",
"src_port": 49324,
"dest_ip": "69.195.71.174",
"dest_port": 443,
"proto": "TCP",
"app_proto": "tls",
"anomaly": {
"type": "applayer",
"event": "APPLAYER_DETECT_PROTOCOL_ONLY_ONE_DIRECTION",
"layer": "proto_detect"
}
}
{
"timestamp": "2016-01-11T05:10:52.828802-0800",
"flow_id": 201217772575257,
"pcap_cnt": 1391281,
"event_type": "anomaly",
"src_ip": "192.168.122.149",
"src_port": 49323,
"dest_ip": "69.195.71.174",
"dest_port": 443,
"proto": "TCP",
"tx_id": 0,
"app_proto": "tls",
"anomaly": {
"type": "applayer",
"event": "INVALID_RECORD_TYPE",
"layer": "proto_parser"
}
}
HTTP Events¶
Fields
hostname
: The hostname this HTTP event is attributed tourl
: URL at the hostname that was accessedhttp_user_agent
: The user-agent of the software that was usedhttp_content_type
: The type of data returned (ex: application/x-gzip)“cookie”
In addition to these fields, if the extended logging is enabled in the suricata.yaml file the following fields are (can) also included:
length
: The content size of the HTTP bodystatus
: HTTP status codeprotocol
: Protocol / Version of HTTP (ex: HTTP/1.1)http_method
: The HTTP method (ex: GET, POST, HEAD)http_refer
: The referrer for this action
In addition to the extended logging fields one can also choose to enable/add from more than 50 additional custom logging HTTP fields enabled in the suricata.yaml file. The additional fields can be enabled as following:
In Administration, select Appliances, select View the device that is needed. In the right upper corner select the HTTP protocol, adjust the settings as needed.
The benefits here of using the extended logging is to see if this action for example was a POST or perhaps if a download of an executable actually returned any bytes.
It is also possible to dump every header for HTTP requests/responses or both
via the setting dump-all-headers
.
Examples
Event with non-extended logging:
"http": {
"hostname": "www.digip.org",
"url" :"\/jansson\/releases\/jansson-2.6.tar.gz",
"http_user_agent": "<User-Agent>",
"http_content_type": "application\/x-gzip"
}
In case the hostname shows a port number, such as in case there is a header “Host: www.test.org:1337”:
"http": {
"http_port": 1337,
"hostname": "www.test.org",
"url" :"\/this\/is\/test.tar.gz",
"http_user_agent": "<User-Agent>",
"http_content_type": "application\/x-gzip"
}
Event with extended logging:
"http": {
"hostname": "direkte.vg.no",
"url": ".....",
"http_user_agent": "<User-Agent>",
"http_content_type": "application\/json",
"http_refer": "http:\/\/www.vg.no\/",
"http_method": "GET",
"protocol": "HTTP\/1.1",
"status":"200",
"length":310
}
Event with dump-all-headers
enabled:
"http": {
"hostname": "test.co.uk",
"url": "\/test\/file.json",
"http_user_agent": "<User-Agent>",
"http_content_type": "application\/json",
"http_refer": "http:\/\/www.test.com\/",
"http_method": "GET",
"protocol": "HTTP\/1.1",
"status": "200",
"length":310,
"request_headers": [
{
"name": "User-Agent",
"value": "Wget/1.13.4 (linux-gnu)"
},
{
"name": "Accept",
"value": "*/*"
},
],
"response_headers": [
{
"name": "Date",
"value": "Wed, 25 Mar 2015 15:40:41 GMT"
},
]
}
DNS Events¶
A new version of dns logging has been introduced to improve how dns answers are logged.
With that new version, dns answers are logged in one event rather than an event for each answer.
It’s possible to customize how a dns answer will be logged with the following formats:
detailed
: “rrname”, “rrtype”, “rdata” and “ttl” fields are logged for each answergrouped
: answers logged are aggregated by their type (A, AAAA, NS, …)
It will be still possible to use the old DNS logging format, you can control it with “version” option in dns configuration section.
Fields
Outline of fields seen in the different kinds of DNS events:
type
: Indicating DNS message type, can be “answer” or “query”.id
: Identifier fieldversion
: Indicating DNS logging version in useflags
: Indicating DNS answer flag, in hexadecimal (ex: 8180 , please note 0x is not output)qr
: Indicating in case of DNS answer flag, Query/Response flag (ex: true if set)aa
: Indicating in case of DNS answer flag, Authoritative Answer flag (ex: true if set)tc
: Indicating in case of DNS answer flag, Truncation flag (ex: true if set)rd
: Indicating in case of DNS answer flag, Recursion Desired flag (ex: true if set)ra
: Indicating in case of DNS answer flag, Recursion Available flag (ex: true if set)z
: Indicating in case of DNS answer flag, Reserved bit (ex: true if set)rcode
: (ex: NOERROR)rrname
: Resource Record Name (ex: a domain name)rrtype
: Resource Record Type (ex: A, AAAA, NS, PTR)rdata
: Resource Data (ex: IP that domain name resolves to)ttl
: Time-To-Live for this resource record
More complex DNS record types may log additional fields for resource data:
soa
: Section containing fields for the SOA (start of authority) record typemname
: Primary name server for this zonername
: Authority’s mailboxserial
: Serial version numberrefresh
: Refresh interval (seconds)retry
: Retry interval (seconds)expire
: Upper time limit until zone is no longer authoritative (seconds)minimum
: Minimum ttl for records in this zone (seconds)
sshfp
: section containing fields for the SSHFP (ssh fingerprint) record typefingerprint
: Hex format of the fingerprint (ex:12:34:56:78:9a:bc:de:...
)algo
: Algorithm number (ex: 1 for RSA, 2 for DSS)type
: Fingerprint type (ex: 1 for SHA-1)
One can control which RR types are logged by using the “types” field in the suricata.yaml file. If this field is not specified, all RR types are logged. More than 50 values can be specified with this field as shown below:
types: [a, ns, md, mf, cname, soa, mb, mg, mr, null,
wks, ptr, hinfo, minfo, mx, txt, rp, afsdb, x25, isdn,
rt, nsap, nsapptr, sig, key, px, gpos, aaaa, loc, nxt,
srv, atma, naptr, kx, cert, a6, dname, opt, apl, ds,
sshfp, ipseckey, rrsig, nsec, dnskey, dhcid, nsec3,
nsec3param, tlsa, hip, cds, cdnskey, spf, tkey,
tsig, maila, any, uri]
In Administration, select Appliances, select View the device that is needed. In the right upper corner select the DNS protocol, adjust the settings as needed.
Examples
Example of a DNS query for the IPv4 address of “twitter.com” (resource record type ‘A’):
"dns": {
"type": "query",
"id": 16000,
"rrname": "twitter.com",
"rrtype": "A"
}
Example of a DNS answer with “detailed” format:
"dns": {
"version": 2,
"type": "answer",
"id": 45444,
"flags": "8180",
"qr": true,
"rd": true,
"ra": true,
"rcode": "NOERROR",
"answers": [
{
"rrname": "www.suricata-ids.org",
"rrtype": "CNAME",
"ttl": 3324,
"rdata": "suricata-ids.org"
},
{
"rrname": "suricata-ids.org",
"rrtype": "A",
"ttl": 10,
"rdata": "192.0.78.24"
},
{
"rrname": "suricata-ids.org",
"rrtype": "A",
"ttl": 10,
"rdata": "192.0.78.25"
}
]
}
Example of a DNS answer with “grouped” format:
"dns": {
"version": 2,
"type": "answer",
"id": 18523,
"flags": "8180",
"qr": true,
"rd": true,
"ra": true,
"rcode": "NOERROR",
"grouped": {
"A": [
"192.0.78.24",
"192.0.78.25"
],
"CNAME": [
"suricata-ids.org"
]
}
}
Example of a old DNS answer with an IPv4 (resource record type ‘A’) return:
"dns": {
"type": "answer",
"id":16000,
"flags":"8180",
"qr":true,
"rd":true,
"ra":true,
"rcode":"NOERROR"
"rrname": "twitter.com",
"rrtype":"A",
"ttl":8,
"rdata": "199.16.156.6"
}
IKE Events¶
The parser implementations for IKEv1 and IKEv2 have a slightly different feature set. They can be distinguished using the “version_major” field (which equals either 1 or 2). The unique properties are contained within a separate “ikev1” and “ikev2” sub-object.
Fields
init_spi", "resp_spi
: The Security Parameter Index (SPI) of the initiator and responder.version_major
: Major version of the ISAKMP header.version_minor
: Minor version of the ISAKMP header.payload
: List of payload types in the current packet.exchange_type
: Type of the exchange, as numeric values.exchange_type_verbose
: Type of the exchange, in human-readable form. Needsextended: yes
set in theike
EVE output option.alg_enc
,alg_hash
,alg_auth
,alg_dh
,alg_esn
: Properties of the chosen security association by the server.ikev1.encrypted_payloads
: Set totrue
if the payloads in the packet are encrypted.ikev1.doi
: Value of the domain of interpretation (DOI).ikev1.server.key_exchange_payload
,ikev1.client.key_exchange_payload
: Public key exchange payloads of the server and client.ikev1.server.key_exchange_payload_length
,ikev1.client.key_exchange_payload_length
: Length of the public key exchange payload.ikev1.server.nonce_payload
,ikev1.client.nonce_payload
: Nonce payload of the server and client.ikev1.server.nonce_payload_length
,ikev1.client.nonce_payload_length
: Length of the nonce payload.ikev1.client.client_proposals
: List of the security associations proposed to the server.ikev1.vendor_ids
: List of the vendor IDs observed in the communication.server_proposals
: List of server proposals with parameters, if there are more than one. This is a non-standard case; this field is only present if such a situation was observed in the inspected traffic.
Examples
Example of IKE logging:
"ike": {
"version_major": 1,
"version_minor": 0,
"init_spi": "8511617bfea2f172",
"resp_spi": "c0fc6bae013de0f5",
"message_id": 0,
"exchange_type": 2,
"exchange_type_verbose": "Identity Protection",
"sa_life_type": "LifeTypeSeconds",
"sa_life_type_raw": 1,
"sa_life_duration": "Unknown",
"sa_life_duration_raw": 900,
"alg_enc": "EncAesCbc",
"alg_enc_raw": 7,
"alg_hash": "HashSha2_256",
"alg_hash_raw": 4,
"alg_auth": "AuthPreSharedKey",
"alg_auth_raw": 1,
"alg_dh": "GroupModp2048Bit",
"alg_dh_raw": 14,
"sa_key_length": "Unknown",
"sa_key_length_raw": 256,
"alg_esn": "NoESN",
"payload": [
"VendorID",
"Transform",
"Proposal",
"SecurityAssociation"
],
"ikev1": {
"doi": 1,
"encrypted_payloads": false,
"client": {
"key_exchange_payload": "0bf7907681a656aabed38fb1ba8918b10d707a8e635a...",
"key_exchange_payload_length": 256,
"nonce_payload": "1427d158fc1ed6bbbc1bd81e6b74960809c87d18af5f0abef14d5274ac232904",
"nonce_payload_length": 32,
"proposals": [
{
"sa_life_type": "LifeTypeSeconds",
"sa_life_type_raw": 1,
"sa_life_duration": "Unknown",
"sa_life_duration_raw": 900,
"alg_enc": "EncAesCbc",
"alg_enc_raw": 7,
"alg_hash": "HashSha2_256",
"alg_hash_raw": 4,
"alg_auth": "AuthPreSharedKey",
"alg_auth_raw": 1,
"alg_dh": "GroupModp2048Bit",
"alg_dh_raw": 14,
"sa_key_length": "Unknown",
"sa_key_length_raw": 256
}
]
},
"server": {
"key_exchange_payload": "1e43be52b088ec840ff81865074b6d459b5ca7813b46...",
"key_exchange_payload_length": 256,
"nonce_payload": "04d78293ead007bc1a0f0c6c821a3515286a935af12ca50e08905b15d6c8fcd4",
"nonce_payload_length": 32
},
"vendor_ids": [
"4048b7d56ebce88525e7de7f00d6c2d3",
"4a131c81070358455c5728f20e95452f",
"afcad71368a1f1c96b8696fc77570100",
"7d9419a65310ca6f2c179d9215529d56",
"cd60464335df21f87cfdb2fc68b6a448",
"90cb80913ebb696e086381b5ec427b1f"
]
},
}
Modbus Events¶
Common fields
id
: The unique transaction number given by Suricata
Request/Response fields
transaction_id
: The transaction id found in the packetprotocol_id
: The modbus versionunit_id
: ID of the remote server to interact withfunction_raw
: Raw value of the function code bytefunction_code
: Associated name of the raw function valueaccess_type
: Type of access requested by the functioncategory
: The function code’s categoryerror_flags
: Errors found in the data while parsing
Exception fields
raw
: Raw value of the exception code bytecode
: Associated name of the raw exception value
Diagnostic fields
raw
: Raw value of the subfunction code bytescode
: Associated name of the raw subfunction valuedata
: Bytes following the subfunction code
MEI fields
raw
: Raw value of the mei function code bytescode
: Associated name of the raw mei function valuedata
: Bytes following the mei function code
Read Request fields
address
: Starting address to read fromquantity
: Amount to read
Read Response fields
data
: Data that was read
Multiple Write Request fields
address
: Starting address to write toquantity
: Amount to writedata
: Data to write
Mask Write fields
address
: Starting address of content modificationand_mask
: And mask to modify content withor_mask
: Or mask to modify content with
Other Write fields
address
: Starting address to write todata
: Data to write
Generic Data fields
data
: Data following the function code
Example
Example of Modbus logging of a request and response:
"modbus": {
"id": 1,
"request": {
"transaction_id": 0,
"protocol_id": 0,
"unit_id": 0,
"function_raw": 1,
"function_code": "RdCoils",
"access_type": "READ | COILS",
"category": "PUBLIC_ASSIGNED",
"error_flags": "NONE",
},
"response": {
"transaction_id": 0,
"protocol_id": 0,
"unit_id": 0,
"function_raw": 1,
"function_code": "RdCoils",
"access_type": "READ | COILS",
"category": "PUBLIC_ASSIGNED",
"error_flags": "DATA_VALUE",
},
}
FTP Events¶
Fields
command
: The FTP command.command_data
: The data accompanying the command.reply
: The command reply, which may contain multiple lines, in array format.completion_code
: The 3-digit completion code. The first digit indicates whether the response is good, bad or incomplete. This is also in array format and may contain multiple completion codes matching multiple reply lines.dynamic_port
: The dynamic port established for subsequent data transfers, when applicable, with a “PORT” or “EPRT” command.mode
: The type of FTP connection. Most connections are “passive” but may be “active”.reply_received
: Indicates whether a response was matched to the command. In some non-typical cases, a command may lack a response.
Examples
Example of regular FTP logging:
"ftp": {
"command": "RETR",
"command_data": "100KB.zip",
"reply": [
"Opening BINARY mode data connection for 100KB.zip (102400 bytes).",
"Transfer complete."
],
"completion_code": [
"150",
"226"
],
Example showing all fields:
"ftp": {
"command": "EPRT",
"command_data": "|2|2a01:e34:ee97:b130:8c3e:45ea:5ac6:e301|41813|",
"reply": [
"EPRT command successful. Consider using EPSV."
],
"completion_code": [
"200"
],
"dynamic_port": 41813,
"mode": "active",
"reply_received": "yes"
}
FTP_DATA Events¶
Fields
command
: The FTP command associated with the event.filename
: The name of the involved file.
Examples
Example of FTP_DATA logging:
"ftp_data": {
"filename": "temp.txt",
"command": "RETR"
}
TLS Events¶
Fields
subject
: The subject field from the TLS certificateissuer
: The issuer field from the TLS certificatesession_resumed
: This field has the value of “true” if the TLS session was resumed via a session id. If this field appears, “subject” and “issuer” do not appear, since a TLS certificate is not seen.
If extended logging is enabled the following fields are also included:
serial
: The serial number of the TLS certificatefingerprint
: The (SHA1) fingerprint of the TLS certificatesni
: The Server Name Indication (SNI) extension sent by the clientversion
: The SSL/TLS version usednot_before
: The NotBefore field from the TLS certificatenot_after
: The NotAfter field from the TLS certificateja3
: The JA3 fingerprint consisting of both a JA3 hash and a JA3 stringja3s
: The JA3S fingerprint consisting of both a JA3 hash and a JA3 string
JA3 must be enabled in the Suricata config file (set ‘app-layer.protocols.tls.ja3-fingerprints’ to ‘yes’).
In addition to this, custom logging also allows the following fields:
certificate
: The TLS certificate base64 encodedchain
: The entire TLS certificate chain base64 encoded
Examples
Example of regular TLS logging:
"tls": {
"subject": "C=US, ST=California, L=Mountain View, O=Google Inc, CN=*.google.com",
"issuerdn": "C=US, O=Google Inc, CN=Google Internet Authority G2"
}
Example of regular TLS logging for resumed sessions:
"tls": {
"session_resumed": true
}
Example of extended TLS logging:
"tls": {
"subject": "C=US, ST=California, L=Mountain View, O=Google Inc, CN=*.google.com",
"issuerdn": "C=US, O=Google Inc, CN=Google Internet Authority G2",
"serial": "0C:00:99:B7:D7:54:C9:F6:77:26:31:7E:BA:EA:7C:1C",
"fingerprint": "8f:51:12:06:a0:cc:4e:cd:e8:a3:8b:38:f8:87:59:e5:af:95:ca:cd",
"sni": "calendar.google.com",
"version": "TLS 1.2",
"notbefore": "2017-01-04T10:48:43",
"notafter": "2017-03-29T10:18:00"
}
Example of certificate logging using TLS custom logging (subject, sni, certificate):
"tls": {
"subject": "C=US, ST=California, L=Mountain View, O=Google Inc, CN=*.googleapis.com",
"sni": "www.googleapis.com",
"certificate": "MIIE3TCCA8WgAwIBAgIIQPsvobRZN0gwDQYJKoZIhvcNAQELBQAwSTELMA [...]"
}
TFTP Events¶
Fields
packet
: The operation code, can be “read” or “write” or “error”file
: The filename transported with the tftp protocolmode
: The mode field, can be “octet” or “mail” or “netascii” (or any combination of upper and lower case)
Example of TFTP logging:
"tftp": {
"packet": "write",
"file": "rfc1350.txt",
"mode": "octet"
}
SMB Events¶
Fields
id
(integer): internal transaction iddialect
(string): the negotiated protocol dialect, or “unknown” if missingcommand
(string): command name. E.g. SMB2_COMMAND_CREATE or SMB1_COMMAND_WRITE_ANDXstatus
(string): status string. Can be both NT_STATUS or DOS_ERR and other variantsstatus_code
(string): status code as hex stringsession_id
(integer): SMB2+ session_id. SMB1 user id.tree_id
(integer): Tree IDfilename
(string): filename for CREATE and other commands.disposition
(string): requested disposition. E.g. FILE_OPEN, FILE_CREATE and FILE_OVERWRITE. See MSN Docs.access
(string): indication of how the file was opened. “normal” or “delete on close (field is subject to change)created
,accessed
,modified
,changed
(integer): timestamps in seconds since unix epochsize
(integer): size of the requested filefuid
(string): SMB2+ file GUID. SMB1 FID as hex.share
(string): share name.share_type
(string): FILE, PIPE, PRINT or unknown.client_dialects
(array of strings): list of SMB dialects the client speaks.client_guid
(string): client GUIDserver_guid
(string): server GUIDrequest.native_os
(string): SMB1 native OS stringrequest.native_lm
(string): SMB1 native Lan Manager stringresponse.native_os
(string): SMB1 native OS stringresponse.native_lm
(string): SMB1 native Lan Manager string
Examples of SMB logging:
Pipe open:
"smb": {
"id": 1,
"dialect": "unknown",
"command": "SMB2_COMMAND_CREATE",
"status": "STATUS_SUCCESS",
"status_code": "0x0",
"session_id": 4398046511201,
"tree_id": 1,
"filename": "atsvc",
"disposition": "FILE_OPEN",
"access": "normal",
"created": 0,
"accessed": 0,
"modified": 0,
"changed": 0,
"size": 0,
"fuid": "0000004d-0000-0000-0005-0000ffffffff"
}
File/pipe close:
"smb": {
"id": 15,
"dialect": "2.10",
"command": "SMB2_COMMAND_CLOSE",
"status": "STATUS_SUCCESS",
"status_code": "0x0",
"session_id": 4398046511121,
"tree_id": 1,
}
Tree connect (share open):
"smb": {
"id": 3,
"dialect": "2.10",
"command": "SMB2_COMMAND_TREE_CONNECT",
"status": "STATUS_SUCCESS",
"status_code": "0x0",
"session_id": 4398046511121,
"tree_id": 1,
"share": "\\\\admin-pc\\c$",
"share_type": "FILE"
}
Dialect negotiation from SMB1 to SMB2 dialect 2.10:
"smb": {
"id": 1,
"dialect": "2.??",
"command": "SMB1_COMMAND_NEGOTIATE_PROTOCOL",
"status": "STATUS_SUCCESS",
"status_code": "0x0",
"session_id": 0,
"tree_id": 0,
"client_dialects": [
"PC NETWORK PROGRAM 1.0",
"LANMAN1.0",
"Windows for Workgroups 3.1a",
"LM1.2X002",
"LANMAN2.1",
"NT LM 0.12",
"SMB 2.002",
"SMB 2.???"
],
"server_guid": "aec6e793-2b11-4019-2d95-55453a0ad2f1"
}
"smb": {
"id": 2,
"dialect": "2.10",
"command": "SMB2_COMMAND_NEGOTIATE_PROTOCOL",
"status": "STATUS_SUCCESS",
"status_code": "0x0",
"session_id": 0,
"tree_id": 0,
"client_dialects": [
"2.02",
"2.10"
],
"client_guid": "601985d2-aad9-11e7-8494-00088bb57f27",
"server_guid": "aec6e793-2b11-4019-2d95-55453a0ad2f1"
}
SMB1 partial SMB1_COMMAND_SESSION_SETUP_ANDX:
"request": {
"native_os": "Unix",
"native_lm": "Samba 3.9.0-SVN-build-11572"
},
"response": {
"native_os": "Windows (TM) Code Name \"Longhorn\" Ultimate 5231",
"native_lm": "Windows (TM) Code Name \"Longhorn\" Ultimate 6.0"
}
DCERPC fields
request
(string): command. E.g. REQUEST, BIND.response
(string): reply. E.g. RESPONSE, BINDACK or FAULT.opnum
(integer): the opnumcall_id
(integer): the call idfrag_cnt
(integer): the number of fragments for the stub datastub_data_size
: total stub data sizeinterfaces
(array): list of interfacesinterfaces.uuid
(string): string representation of the UUIDinterfaces.version
(string): interface versioninterfaces.ack_result
(integer): ack resultinterfaces.ack_reason
(integer): ack reason
DCERPC REQUEST/RESPONSE:
"smb": {
"id": 4,
"dialect": "unknown",
"command": "SMB2_COMMAND_IOCTL",
"status": "STATUS_SUCCESS",
"status_code": "0x0",
"session_id": 4398046511201,
"tree_id": 0,
"dcerpc": {
"request": "REQUEST",
"response": "RESPONSE",
"opnum": 0,
"req": {
"frag_cnt": 1,
"stub_data_size": 136
},
"res": {
"frag_cnt": 1,
"stub_data_size": 8
},
"call_id": 2
}
}
DCERPC BIND/BINDACK:
"smb": {
"id": 53,
"dialect": "2.10",
"command": "SMB2_COMMAND_WRITE",
"status": "STATUS_SUCCESS",
"status_code": "0x0",
"session_id": 35184439197745,
"tree_id": 1,
"dcerpc": {
"request": "BIND",
"response": "BINDACK",
"interfaces": [
{
"uuid": "12345778-1234-abcd-ef00-0123456789ac",
"version": "1.0",
"ack_result": 2,
"ack_reason": 0
},
{
"uuid": "12345778-1234-abcd-ef00-0123456789ac",
"version": "1.0",
"ack_result": 0,
"ack_reason": 0
},
{
"uuid": "12345778-1234-abcd-ef00-0123456789ac",
"version": "1.0",
"ack_result": 3,
"ack_reason": 0
}
],
"call_id": 2
}
NTLMSSP fields
domain
(string): the Windows domain.user
(string): the user.host
(string): the host.
Example:
"ntlmssp": {
"domain": "VNET3",
"user": "administrator",
"host": "BLU"
}
More complete example:
"smb": {
"id": 3,
"dialect": "NT LM 0.12",
"command": "SMB1_COMMAND_SESSION_SETUP_ANDX",
"status": "STATUS_SUCCESS",
"status_code": "0x0",
"session_id": 2048,
"tree_id": 0,
"ntlmssp": {
"domain": "VNET3",
"user": "administrator",
"host": "BLU"
},
"request": {
"native_os": "Unix",
"native_lm": "Samba 3.9.0-SVN-build-11572"
},
"response": {
"native_os": "Windows (TM) Code Name \"Longhorn\" Ultimate 5231",
"native_lm": "Windows (TM) Code Name \"Longhorn\" Ultimate 6.0"
}
}
Kerberos fields
kerberos.realm
(string): the Kerberos Realm.kerberos.snames
(array of strings): snames.
Example:
"smb": {
"dialect": "2.10",
"command": "SMB2_COMMAND_SESSION_SETUP",
"status": "STATUS_SUCCESS",
"status_code": "0x0",
"session_id": 35184439197745,
"tree_id": 0,
"kerberos": {
"realm": "CONTOSO.LOCAL",
"snames": [
"cifs",
"DC1.contoso.local"
]
}
}
SSH Events¶
Fields
proto_version
: The protocol version transported with the ssh protocol (1.x, 2.x)software_version
: The software version used by end userhassh.hash
: MD5 of hassh algorithms of client or serverhassh.string
: hassh algorithms of client or server
Hassh must be enabled in the Suricata config file (set ‘app-layer.protocols.ssh.hassh’ to ‘yes’).
Example of SSH logging:
"ssh": {
"client": {
"proto_version": "2.0",
"software_version": "OpenSSH_6.7",
"hassh": {
"hash": "ec7378c1a92f5a8dde7e8b7a1ddf33d1",
"string": "curve25519-sha256,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c",
}
},
"server": {
"proto_version": "2.0",
"software_version": "OpenSSH_6.7",
"hassh": {
"hash": "ec7378c1a92f5a8dde7e8b7a1ddf33d1",
"string": "curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256",
}
}
}
FLOW Events¶
Fields
pkts_toserver
: total number of packets to server, include bypassed packetspkts_toclient
: total number of packets to clientbytes_toserver
: total bytes count to serverbytes_toclient
: total bytes count to clientbypassed.pkts_toserver
: number of bypassed packets to serverbypassed.pkts_toclient
: number of bypassed packets to clientbypassed.bytes_toserver
: bypassed bytes count to serverbypassed.bytes_toclient
: bypassed bytes count to clientstart
: date of start of the flowend
: date of end of flow (last seen packet)age
: duration of the flowbypass
: if the flow has been bypassed, it is set to “local” (internal bypass) or “capture”state
: display state of the flow (include “new”, “established”, “closed”, “bypassed”)reason
: mechanism that did trigger the end of the flow (include “timeout”, “forced” and “shutdown”)alerted
: “true” or “false” depending if an alert has been seen on flow
Example
"flow": {
"pkts_toserver": 23,
"pkts_toclient": 21,
"bytes_toserver": 4884,
"bytes_toclient": 7392,
"bypassed": {
"pkts_toserver": 10,
"pkts_toclient": 8,
"bytes_toserver": 1305,
"bytes_toclient": 984
},
"start": "2019-05-28T23:32:29.025256+0200",
"end": "2019-05-28T23:35:28.071281+0200",
"age": 179,
"bypass": "capture",
"state": "bypassed",
"reason": "timeout",
"alerted": false
}
RDP Events¶
Initial negotiations between RDP client and server are stored as transactions and logged.
Each RDP record contains a per-flow incrementing “tx_id” field.
The “event_type” field indicates an RDP event subtype. Possible values:
initial_request
initial_response
connect_request
connect_response
tls_handshake
RDP type: Initial Request
The optional cookie
field is a string identifier the RDP client has chosen to provide.
The optional flags
field is a list of client directives. Possible values:
restricted_admin_mode_required
redirected_authentication_mode_required
correlation_info_present
RDP type: Initial Response
In the event of a standard initial response:
The protocol
field is the selected protocol. Possible values:
rdp
ssl
hybrid
rds_tls
hybrid_ex
The optional flags
field is a list of support server modes. Possible values:
extended_client_data
dynvc_gfx
restricted_admin
redirected_authentication
Alternatively, in the event of an error-indicating initial response:
There will be no “protocol” or “flags” fields.
The “error_code” field will contain the numeric code provided by the RDP server.
The “reason” field will contain a text summary of this code. Possible values:
ssl required by server
(error code 0x1)ssl not allowed by server
(error code 0x2)ssl cert not on server
(error code 0x3)inconsistent flags
(error code 0x4)hybrid required by server
(error code 0x5)ssl with user auth required by server
(error code 0x6)
RDP type: Connect Request
The optional “channel” field is a list of requested data channel names.
Common channels:
rdpdr
(device redirection)cliprdr
(shared clipboard)rdpsnd
(sound)
The optional “client” field is a sub-object that may contain the following:
version
: RDP protocol version. Possible values are “v4”, “v5”, “v10.0”, “v10.1”, “v10.2”, “v10.3”, “v10.4”, “v10.5”, “v10.6”, “v10.7”, “unknown”.desktop_width
: Numeric desktop width value.desktop_height
: Numeric desktop height value.color_depth
: Numeric color depth. Possible values are 4, 8, 15, 16, 24.keyboard_layout
: Locale identifier name, e.g., “en-US”.build
: OS and SP level, e.g., “Windows XP”, “Windows 7 SP1”.client_name
: Client computer name.keyboard_type
: Possible values are “xt”, “ico”, “at”, “enhanced”, “1050”, “9140”, “jp”.keyboard_subtype
: Numeric code for keyboard.function_keys
: Number of function keys on client keyboard.ime
: Input method editor (IME) file name.product_id
: Product id string.serial_number
: Numeric value.capabilities
: List of any of the following:support_errinfo_pdf
,want_32bpp_session
,support_statusinfo_pdu
,strong_asymmetric_keys
,valid_connection_type
,support_monitor_layout_pdu
,support_netchar_autodetect
,support_dynvc_gfx_protocol
,support_dynamic_time_zone
,support_heartbeat_pdu
.id
: Client product id string.connection_hint
: Possible values aremodem
,low_broadband
,satellite
,high_broadband
,wan
,lan
,autodetect
.physical_width
: Numeric phyical width of display.physical_height
: Numeric physical height of display.desktop_orientation
: Numeric angle of orientation.scale_factor
: Numeric scale factor of desktop.device_scale_factor
: Numeric scale factor of display.
RDP type: Connect Response
With this event, the initial RDP negotiation is complete in terms of tracking and logging.
RDP type: TLS Handshake
With this event, the initial RDP negotiation is complete in terms of tracking and logging.
The session will use TLS encryption.
The “x509_serials” field is a list of observed certificate serial numbers, e.g., “16ed2aa0495f259d4f5d99edada570d1”.
Examples
RDP logging:
"rdp": {
"tx_id": 0,
"event_type": "initial_request",
"cookie": "A70067"
}
"rdp": {
"tx_id": 1,
"event_type": "initial_response"
}
"rdp": {
"tx_id": 2,
"event_type": "connect_request",
"client": {
"version": "v5",
"desktop_width": 1152,
"desktop_height": 864,
"color_depth": 15,
"keyboard_layout": "en-US",
"build": "Windows XP",
"client_name": "ISD2-KM84178",
"keyboard_type": "enhanced",
"function_keys": 12,
"product_id": 1,
"capabilities": [
"support_errinfo_pdf"
],
"id": "55274-OEM-0011903-00107"
},
"channels": [
"rdpdr",
"cliprdr",
"rdpsnd"
]
}
"rdp": {
"tx_id": 3,
"event_type": "connect_response"
}
RDP logging, with transition to TLS
"rdp": {
"tx_id": 0,
"event_type": "initial_request",
"cookie": "AWAKECODI"
}
"rdp": {
"tx_id": 1,
"event_type": "initial_response",
"server_supports": [
"extended_client_data"
],
"protocol": "hybrid"
}
"rdp": {
"tx_id": 2,
"event_type": "tls_handshake",
"x509_serials": [
"16ed2aa0495f259d4f5d99edada570d1"
]
}
RFB Events¶
Fields
server_protocol_version.major
,server_protocol_version.minor
: The RFB protocol version offered by the server.client_protocol_version.major
,client_protocol_version.minor
: The RFB protocol version agreed by the client.authentication.security_type
: Security type agreed upon in the logged transaction, e.g.2
is VNC auth.authentication.vnc.challenge
,authentication.vnc.response
: Only available when security type 2 is used. Contains the challenge and response byte buffers exchanged by the server and client as hex strings.authentication.security-result
: Result of the authentication process (OK
,FAIL
orTOOMANY
).screen_shared
: Boolean value describing whether the client requested screen sharing.framebuffer
: Contains metadata about the initial screen setup process. Only available when the handshake completed this far.framebuffer.width
,framebuffer.height
: Screen size as offered by the server.framebuffer.name
: Desktop name as advertised by the server.framebuffer.pixel_format
: Pixel representation information, such as color depth. See RFC6143 (https://tools.ietf.org/html/rfc6143) for details.
Examples
Example of RFB logging, with full VNC style authentication parameters:
"rfb": {
"server_protocol_version": {
"major": "003",
"minor": "007"
},
"client_protocol_version": {
"major": "003",
"minor": "007"
},
"authentication": {
"security_type": 2,
"vnc": {
"challenge": "0805b790b58e967f2b350a0c99de3881",
"response": "aecb26faeaaa62179636a5934bac1078"
},
"security-result": "OK"
},
"screen_shared": false,
"framebuffer": {
"width": 1280,
"height": 800,
"name": "foobar@localhost.localdomain",
"pixel_format": {
"bits_per_pixel": 32,
"depth": 24,
"big_endian": false,
"true_color": true,
"red_max": 255,
"green_max": 255,
"blue_max": 255,
"red_shift": 16,
"green_shift": 8,
"blue_shift": 0
}
}
MQTT Events¶
EVE-JSON output for MQTT consists of one object per MQTT transaction, with some common and various type-specific fields.
Transactions
A single MQTT communication can consist of multiple messages that need to be exchanged between broker and client. For example, some actions at higher QoS levels (> 0) usually involve a combination of requests and acknowledgement messages that are linked by a common identifier:
CONNECT
followed byCONNACK
PUBLISH
followed byPUBACK
(QoS 1) orPUBREC
/PUBREL
/PUBCOMP
(QoS 2)
SUBSCRIBE
followed bySUBACK
UNSUBSCRIBE
followed byUNSUBACK
The MQTT parser merges individual messages into one EVE output item if they belong to one transaction. In such cases, the source and destination information (IP/port) reflect the direction of the initial request, but contain messages from both sides.
Example for a PUBLISH at QoS 2:
{
"timestamp": "2020-05-19T18:00:39.016985+0200",
"flow_id": 1454127794305760,
"pcap_cnt": 65,
"event_type": "mqtt",
"src_ip": "0000:0000:0000:0000:0000:0000:0000:0001",
"src_port": 60105,
"dest_ip": "0000:0000:0000:0000:0000:0000:0000:0001",
"dest_port": 1883,
"proto": "TCP",
"mqtt": {
"publish": {
"qos": 2,
"retain": false,
"dup": false,
"topic": "house/bulbs/bulb1",
"message_id": 3,
"message": "OFF"
},
"pubrec": {
"qos": 0,
"retain": false,
"dup": false,
"message_id": 3
},
"pubrel": {
"qos": 1,
"retain": false,
"dup": false,
"message_id": 3
},
"pubcomp": {
"qos": 0,
"retain": false,
"dup": false,
"message_id": 3
}
}
}
Note that some message types (aka control packet types), such as PINGREQ
and PINGRESP
, have no type-specific
data, nor do they have information that facilitate grouping into transactions. These will be logged as single items
and only contain the common fields listed below.
Common fields
Common fields from the MQTT fixed header:
\*.qos
: Quality of service level for the message, integer between 0 and 2.\*.retain
: Boolean value of the MQTT ‘retain’ flag.\*.dup
: Boolean value of the MQTT ‘dup’ (duplicate) flag.
MQTT CONNECT fields
connect.protocol_string
: Protocol string as defined in the spec, e.g.MQTT
(MQTT 3.1.1 and later) orMQIsdp
(MQTT 3.1).connect.protocol_version
: Protocol version as defined in the specification:protocol version
3
: MQTT 3.1protocol version
4
: MQTT 3.1.1protocol version
5
: MQTT 5.0
connect.flags.username
,connect.flags.password
: Set to true if credentials are submitted with the connect request.connect.flags.will
: Set to true if a will is set.connect.flags.will_retain
: Set to true if the will is to be retained on the broker.connect.will.clean_session
: Set to true if the connection is to made with a clean session.connect.client_id
: Client ID string submitted my the connecting client.connect.username
,connect.password
: User/password authentication credentials submitted with the connect request. Passwords are only logged when the corresponding configuration setting is enabled (mqtt.passwords: yes
).connect.will.topic
: Topic to publish the will message to.connect.will.message
: Message to be published on connection loss.connect.will.properties
: (Optional, MQTT 5.0) Will properties set on this request. See 3.1.3.2 in the spec for more information on will properties.connect.properties
: (Optional, MQTT 5.0) CONNECT properties set on this request. See 3.1.2.11 in the spec for more information on CONNECT properties.
Example of MQTT CONNECT logging:
"connect": {
"qos": 0,
"retain": false,
"dup": false,
"protocol_string": "MQTT",
"protocol_version": 5,
"flags": {
"username": true,
"password": true,
"will_retain": false,
"will": true,
"clean_session": true
},
"client_id": "client",
"username": "user",
"password": "pass",
"will": {
"topic": "willtopic",
"message": "willmessage",
"properties": {
"content_type": "mywilltype",
"correlation_data": "3c32aa4313b3e",
"message_expiry_interval": 133,
"payload_format_indicator": 144,
"response_topic": "response_topic1",
"userprop": "uservalue",
"will_delay_interval": 200
}
},
"properties": {
"maximum_packet_size": 11111,
"receive_maximum": 222,
"session_expiry_interval": 555,
"topic_alias_maximum": 666,
"userprop1": "userval1",
"userprop2": "userval2"
}
}
MQTT CONNACK fields
connack.session_present
: Set to true if a session is continued on connection.connack.return_code
: Return code/reason code for this reply. See 3.2.2.2 in the spec for more information on these codes.connect.properties
: (Optional, MQTT 5.0) CONNACK properties set on this request. See 3.2.2.3 in the spec for more information on CONNACK properties.
Example of MQTT CONNACK logging:
"connack": {
"qos": 0,
"retain": false,
"dup": false,
"session_present": false,
"return_code": 0,
"properties": {
"topic_alias_maximum": 10
}
}
MQTT PUBLISH fields
publish.topic
: Topic this message is published to.publish.message_id
: (Only present if QOS level > 0) Message ID for this publication.publish.message
: Message to be published.publish.properties
: (Optional, MQTT 5.0) PUBLISH properties set on this request. See 3.3.2.3 in the spec for more information on PUBLISH properties.
Example of MQTT PUBLISH logging
"publish": {
"qos": 1,
"retain": false,
"dup": false,
"topic": "topic",
"message_id": 1,
"message": "baa baa sheep",
"properties": {
"content_type": "mytype",
"correlation_data": "3c32aa4313b3e",
"message_expiry_interval": 77,
"payload_format_indicator": 88,
"response_topic": "response_topic1",
"topic_alias": 5,
"userprop": "userval"
}
}
MQTT PUBACK/PUBREL/PUBREC/PUBCOMP fields
[puback|pubrel|pubrec|pubcomp].message_id
: Original message ID this message refers to.[puback|pubrel|pubrec|pubcomp].reason_code
: Return code/reason code for this reply. See the spec for more information on these codes.[puback|pubrel|pubrec|pubcomp].properties
: (Optional, MQTT 5.0) Properties set on this request. See the spec for more information on these properties.
Example of MQTT PUBACK/PUBREL/PUBREC/PUBCOMP logging:
"puback": {
"qos": 0,
"retain": false,
"dup": false,
"message_id": 1,
"reason_code": 16
}
MQTT SUBSCRIBE fields
subscribe.message_id
: (Only present if QOS level > 0) Message ID for this subscription.subscribe.topics
: Array of pairs describing the subscribed topics:subscribe.topics[].topic
: Topic to subscribe to.subscribe.topics[].qos
: QOS level to apply for when subscribing.
subscribe.properties
: (Optional, MQTT 5.0) SUBSCRIBE properties set on this request. See 3.8.2.1 in the spec for more information on SUBSCRIBE properties.
Example of MQTT SUBSCRIBE logging
"subscribe": {
"qos": 1,
"retain": false,
"dup": false,
"message_id": 1,
"topics": [
{
"topic": "topicX",
"qos": 0
},
{
"topic": "topicY",
"qos": 0
}
]
}
MQTT SUBACK fields
suback.message_id
: Original message ID this message refers to.suback.qos_granted
: Array of QOS levels granted for the subscribed topics, in the order of the original request.suback.properties
: (Optional, MQTT 5.0) SUBACK properties set on this request. See 3.9.2.1 in the spec for more information on SUBACK properties.
Example of MQTT SUBACK logging:
"suback": {
"qos": 0,
"retain": false,
"dup": false,
"message_id": 1,
"qos_granted": [
0,
0
]
}
MQTT UNSUBSCRIBE fields
unsubscribe.message_id
: (Only present if QOS level > 0) Message ID for this unsubscribe action.unsubscribe.topics
: Array of topics to be unsubscribed from.unsubscribe.properties
: (Optional, MQTT 5.0) UNSUBSCRIBE properties set on this request. See 3.10.2.1 in the spec for more information on UNSUBSCRIBE properties.
Example of MQTT UNSUBSCRIBE logging
"unsubscribe": {
"qos": 1,
"retain": false,
"dup": false,
"message_id": 1,
"topics": [
"topicX",
"topicY"
]
}
MQTT UNSUBACK fields
unsuback.message_id
: Original message ID this message refers to.
Example of MQTT UNSUBACK logging:
"unsuback": {
"qos": 0,
"retain": false,
"dup": false,
"message_id": 1
}
MQTT AUTH fields (MQTT 5.0)
auth.reason_code
: Return code/reason code for this message. See 3.15.2.1 in the spec for more information on these codes.auth.properties
: (Optional, MQTT 5.0) Properties set on this request. See 3.15.2.2 in the spec for more information on these properties.
Example of MQTT AUTH logging:
"auth": {
"qos": 0,
"retain": false,
"dup": false,
"reason_code": 16
}
MQTT DISCONNECT fields
auth.reason_code
: (Optional) Return code/reason code for this message. See 3.14.2.1 in the spec for more information on these codes.auth.properties
: (Optional, MQTT 5.0) Properties set on this request. See 3.14.2.2 in the spec for more information on DISCONNECT properties.
Example of MQTT DISCONNECT logging:
"disconnect": {
"qos": 0,
"retain": false,
"dup": false,
"reason_code": 4,
"properties": {
"session_expiry_interval": 122,
}
}
Truncated MQTT data
Messages exceeding the maximum message length limit (config setting app-layer.protocols.mqtt.max-msg-length
)
will not be parsed entirely to reduce the danger of denial of service issues. In such cases, only reduced
metadata will be included in the EVE-JSON output. Furthermore, since no message ID is parsed, such messages
can not be placed into transactions, hence, they will always appear as a single transaction.
These truncated events will – besides basic communication metadata – only contain the following fields:
truncated
: Set to true if the entry is truncated.skipped_length
: Size of the original message.
Example of a truncated MQTT PUBLISH message (with 10000 being the maximum length):
{
"timestamp": "2020-06-23T16:25:48.729785+0200",
"flow_id": 1872904524326406,
"pcap_cnt": 107,
"event_type": "mqtt",
"src_ip": "0000:0000:0000:0000:0000:0000:0000:0001",
"src_port": 53335,
"dest_ip": "0000:0000:0000:0000:0000:0000:0000:0001",
"dest_port": 1883,
"proto": "TCP",
"mqtt": {
"publish": {
"qos": 0,
"retain": false,
"dup": false,
"truncated": true,
"skipped_length": 100011
}
HTTP2 Events¶
Fields
There are the two fields “request” and “response” which can each contain the same set of fields :
settings
: a list of settings with “name” and “value”headers
: a list of headers with either “name” and “value”, or “table_size_update”, or “error” if anyerror_code
: the error code from GOAWAY or RST_STREAM, which can be “NO_ERROR”priority
: the stream priority.
Examples
Example of HTTP2 logging, of a settings frame:
"http2": {
"request": {
"settings": [
{
"settings_id": "SETTINGSMAXCONCURRENTSTREAMS",
"settings_value": 100
},
{
"settings_id": "SETTINGSINITIALWINDOWSIZE",
"settings_value": 65535
}
]
},
"response": {}
}
Example of HTTP2 logging, of a request and response
"http2": {
"request": {
"headers": [
{
"name": ":authority",
"value": "localhost:3000"
},
{
"name": ":method",
"value": "GET"
},
{
"name": ":path",
"value": "/doc/manual/html/index.html"
},
{
"name": ":scheme",
"value": "http"
},
{
"name": "accept",
"value": "*/*"
},
{
"name": "accept-encoding",
"value": "gzip, deflate"
},
{
"name": "user-agent",
"value": "nghttp2/0.5.2-DEV"
}
]
},
"response": {
"headers": [
{
"name": ":status",
"value": "200"
},
{
"name": "server",
"value": "nghttpd nghttp2/0.5.2-DEV"
},
{
"name": "content-length",
"value": "22617"
},
{
"name": "cache-control",
"value": "max-age=3600"
},
{
"name": "date",
"value": "Sat, 02 Aug 2014 10:50:25 GMT"
},
{
"name": "last-modified",
"value": "Sat, 02 Aug 2014 07:58:59 GMT"
}
]
}
}