* "session_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.
* "dialect" (string): the negotiated protocol dialect, or "unknown" if missing
* "command" (string): command name. E.g. SMB2_COMMAND_CREATE or SMB1_COMMAND_WRITE_ANDX
* "status" (string): status string. Can be both NT_STATUS or DOS_ERR and other variants
* "status_code" (string): status code as hex string
* "session_id" (integer): SMB2+ session_id. SMB1 user id.
* "tree_id" (integer): Tree ID
* "filename" (string): filename for CREATE and other commands.
* "disposition" (string): requested disposition. E.g. FILE_OPEN, FILE_CREATE and FILE_OVERWRITE. See https://msdn.microsoft.com/en-us/library/ee442175.aspx#Appendix_A_Target_119
* "access" (string): indication of how the file was opened. "normal" or "delete on close" (field is subject to change)
* "transaction_id" (hex): the unique id of the transaction, generated by node making the request (a.k.a the querying node). Same transaction_id is echoed back by responding nodes.
* "client_version" (hex): identifies the type and version of the bittorrent-dht client. Some implementations may be missing this field.
* "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 are "modem", "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".
* "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`` or ``TOOMANY``).
* "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:
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) or ``MQIsdp`` (MQTT 3.1).
* "connect.protocol_version": Protocol version as defined in the specification:
* protocol version ``3``: MQTT 3.1
* protocol version ``4``: MQTT 3.1.1
* protocol 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 <https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901060>`_ 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 <https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901046>`_ 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 <https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901079>`_ 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 <https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901080>`_ 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 <https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901109>`_ 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 <https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901164>`_ 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 <https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901174>`_ 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 <https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901182>`_ 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 <https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901220>`_ 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 <https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901221>`_ 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 <https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901208>`_ 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 <https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901209>`_ 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):
PGSQL eve-logs reflect the bidirectional nature of the protocol transactions. Each PGSQL event lists at most one
"Request" message field and one or more "Response" messages.
The PGSQL parser merges individual messages into one EVE output item if they belong to the same 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 of ``pgsql`` event for a SimpleQuery transaction complete with request with a ``SELECT`` statement and its response::
{
"timestamp": "2021-11-24T16:56:24.403417+0000",
"flow_id": 1960113262002448,
"pcap_cnt": 780,
"event_type": "pgsql",
"src_ip": "172.18.0.1",
"src_port": 54408,
"dest_ip": "172.18.0.2",
"dest_port": 5432,
"proto": "TCP",
"pgsql": {
"tx_id": 4,
"request": {
"simple_query": "select * from rule limit 5000;"
},
"response": {
"field_count": 7,
"data_rows": 5000,
"data_size": 3035751,
"command_completed": "SELECT 5000"
}
}
}
While on the wire PGSQL messages follow basically two types (startup messages and regular messages), those may have different subfields and/or meanings, based on the message type. Messages are logged based on their type and relevant fields.
We list a few possible message types and what they mean in Suricata. For more details on message types and formats as well as what each message and field mean for PGSQL, check `PostgreSQL's official documentation <https://www.postgresql.org/docs/14/protocol-message-formats.html>`_.
Fields
~~~~~~
* "tx_id": internal transaction id.
* "request": each PGSQL transaction may have up to one request message. The possible messages will be described in another section.
* "response": even when there are several "Response" messages, there is one ``response`` field that summarizes all responses for that transaction. The possible messages will be described in another section.
Request Messages
~~~~~~~~~~~~~~~~
Some of the possible request messages are:
* "startup_message": message sent by a frontend/client process to start a new PostgreSQL connection
* "password_message": if password output for PGSQL is enabled in suricata.yaml, carries the password sent during Authentication phase
* "simple_query": issued SQL command during simple query subprotocol. PostgreSQL identifies specific sets of commands that change the set of expected messages to be exchanged as subprotocols.
* "message": frontend responses which do not have meaningful payloads are logged like this, where the field value is the message type
There are several different authentication messages possible, based on selected authentication method. (e.g. the SASL authentication will have a set of authentication messages different from when ``md5`` authentication is chosen).
Response Messages
~~~~~~~~~~~~~~~~~
Some of the possible request messages are:
* "authentication_sasl_final": final SCRAM ``server-final-message``, as explained at https://www.postgresql.org/docs/14/sasl-authentication.html#SASL-SCRAM-SHA-256
* "message": Backend responses which do not have meaningful payloads are logged like this, where the field value is the message type
* "error_response"
* "notice_response"
* "notification_response"
* "authentication_md5_password": a string with the ``md5`` salt value
* "parameter_status": logged as an array
* "backend_key_data"
* "data_rows": integer. When one or many ``DataRow`` messages are parsed, the total returned rows
* "data_size": in bytes. When one or many ``DataRow`` messages are parsed, the total size in bytes of the data returned
* "command_completed": string. Informs the command just completed by the backend
* "ssl_accepted": bool. With this event, the initial PGSQL SSL Handshake negotiation is complete in terms of tracking and logging. The session will be upgraded to use TLS encryption
Examples
~~~~~~~~
The two ``pgsql`` events in this example reprensent a rejected ``SSL handshake`` and a following connection request where the authentication method indicated by the backend was ``md5``::
* "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.
