Event type: PGSQL
-----------------
-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.
+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.
+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::
+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",
}
}
-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.
+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>`_.
+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": 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
+* "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).
+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
+* "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
+* "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
+* "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 represent a rejected ``SSL handshake`` and a following connection request where the authentication method indicated by the backend was ``md5``::
+The two ``pgsql`` events in this example represent a rejected ``SSL handshake``
+and a following connection request where the authentication method indicated by
+the backend was ``md5``::
{
"timestamp": "2021-11-24T16:56:19.435242+0000",
projects / thirdparty / suricata.git / commitdiff
