From: Juliana Fajardini Date: Mon, 11 Dec 2023 20:26:31 +0000 (-0300) Subject: doc/eve-format: break pgsql section to char limit X-Git-Tag: suricata-8.0.0-beta1~1910 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=7dcc2e7a713de20af0dbc1e935ec791cba2e6f95;p=thirdparty%2Fsuricata.git doc/eve-format: break pgsql section to char limit --- diff --git a/doc/userguide/output/eve/eve-json-format.rst b/doc/userguide/output/eve/eve-json-format.rst index 0c7bc867ae..f33f205e01 100644 --- a/doc/userguide/output/eve/eve-json-format.rst +++ b/doc/userguide/output/eve/eve-json-format.rst @@ -2432,13 +2432,17 @@ Example of HTTP2 logging, of a request and response: 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", @@ -2464,51 +2468,74 @@ Example of ``pgsql`` event for a SimpleQuery transaction complete with request w } } -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 `_. +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 `_. 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",