.. include:: ../vars.rst .. _chapter-logging: *************************** Security Events and Logging *************************** The |RTI_SP_PRODUCT| implement a builtin |LoggingPlugin| to notify you of security events. A security event refers to any significant occurrence within the |CONNEXT| system that pertains to security mechanisms or concerns. These events can include actions or incidents related to authentication, access control, and cryptography within the |CONNEXT| environment. Security events are important for monitoring and ensuring the integrity, confidentiality, and availability of the data being communicated among |DPs| in a |CONNEXT| system. They can be logged and supervised to detect and respond to potential security threats or breaches, such as attempts by unauthorized entities to access or modify data, successful or failed authentication attempts, creation of cryptographic keys, or registration of endpoints with security attributes. Not all the log messages generated by the |RTI_SP_PRODUCT| correspond to security events (for example, memory allocation failures, DDS-related errors, etc). These messages are not logged using the |LoggingPlugin|, they use the |NDDS_Config_Logger| instead. The |LoggingPlugin| supports the following logging methods (non-exclusive): * Using |CONNEXT|'s own builtin logging system to send security messages. * Distributing security log messages over DDS using the |LoggingT|. * Distributing and storing security log messages in a logging aggregator backend (such as Grafana® Loki) using |RTI_OBSERVABILITY|. Refer to the :link_addon_products_observability_up_two:`RTI Connext Observability Framework User's Manual ` for more information. By default, log messages are processed by the |NDDS_Config_Logger|. You can configure which logging methods to use by setting the :property:`logging.mode_mask` property. You can also adjust the verbosity level of the log messages with :property:`logging.verbosity`. See :numref:`|RTI_SP_PRODUCT_HEADING| Properties for Configuring Logging`. If you distribute log messages over DDS using the |LoggingT|, the messages' log levels are used as the severity values of the :type:`BuiltinLoggingTypeV2`. If you are using the |NDDS_Config_Logger|, the messages' log levels are mapped to the values shown in :numref:`Mapping between Logging Plugin and Connext DDS Builtin Logging System`. See :link_connext_dds_pro_um:`Configuring Connext Logging in the RTI Connext DDS Core Libraries User's Manual <#users_manual/Controlling_Messages_from_.htm>` for more information on the |NDDS_Config_Logger|. .. _attention-on-verbosity-configuration-per-app: .. attention:: The verbosity of security-related messages is per application. The last *DomainParticipant* **explicitly setting** the :property:`logging.verbosity` property (set by you, in the QoS settings) will apply that setting to all the *DomainParticipants* within the application and all security-related messages logged from the |CONNEXT| libraries. This behavior is true independent of the value of the :property:`logging.mode_mask` property. If not explicitly set, the verbosity will be left unchanged. Therefore, if no |DP| has configured the verbosity, it will be left to the default (:value:`ERROR`). See the following sections for more information about the different logging methods [#]_. * :ref:`p2_core/logging:Connext DDS Builtin Logging System` * :ref:`p2_core/logging:Distributed over DDS` .. [#] Before release 6.1.0 of |CONNEXT|, you could choose to redirect the security messages to a file by setting the :property:`logging.log_file` property. In |CONNEXT| 6.1.0, this property has been removed, and using it will result in a |DP| creation failure. You can still redirect the security log to a file by enabling the :value:`BUILTIN` flag in the :property:`logging.mode_mask property` (enabled by default) and configuring the |NDDS_Config_Logger| to use a log file or an output device (see :link_connext_dds_pro_um:`Configuring Connext Logging in the RTI Connext DDS Core Libraries User's Manual <#users_manual/Controlling_Messages_from_.htm>`). Connext DDS Builtin Logging System ================================== When security logging is configured to be written to |CONNEXT|'s own builtin logging system (also known as *NDDS_Config_Logger*), you will see messages that use a JSON format and look something like the following: .. code-block:: text :class: break-lines [2020-09-11 16:17:06.477203] [CREATE DP] RTI_Security_CertHelper_loadPrivateKey:{"DDS:Security:LogTopicV2":{"f":"10","s":"3","t":{"s":"1599841026","n":"477193999"},"h":"rti-10636","i":"0.0.0.0","a":"RTI Secure DDS Application","p":"2788","k":"33554496","x":[{"DDS":[{"domain_id":""},{"guid":""},{"plugin_class":"RTI:Common"},{"plugin_method":"RTI_Security_CertHelper_loadPrivateKey"}]}],"m":"private_key is not encrypted, yet password is supplied. Aborting participant creation due to inconsistent configuration."}} [2020-09-11 16:17:06.477233] [CREATE DP] RTI_Security_AuthenticationData_create:{"DDS:Security:LogTopicV2":{"f":"10","s":"0","t":{"s":"1599841026","n":"477228999"},"h":"rti-10636","i":"0.0.0.0","a":"RTI Secure DDS Application","p":"2788","k":"33554496","x":[{"DDS":[{"domain_id":""},{"guid":""},{"plugin_class":"DDS:Auth:PKI-DH"},{"plugin_method":"RTI_Security_AuthenticationData_create"}]}],"m":"failed to read authentication.private_key_file"}} The mapping from the above format to the fields in the ``DDS:Security:LogTopicV2`` type (see :ref:`p2_core/logging:Builtin Secure Logging Topic`) is as follows: * ``"f"``: ``facility`` * ``"s"``: ``severity`` * ``"t"``: ``timestamp`` (within this field ``"s"`` refers to seconds, and ``"n"`` to nanoseconds) * ``"h"``: ``hostname`` * ``"i"``: ``hostip`` * ``"a"``: ``appname`` * ``"p"``: ``procid`` * ``"k"``: ``msgid`` * ``"m"``: ``message`` * ``"x"``: ``structured_data`` * The structured data will have at least the ``DDS`` key containing an array of key-value pairs. The |RTI_SP_PRODUCT| also populate the ``guid``, ``domain_id``, ``plugin_class``, and ``plugin_method`` key-value pairs. You can find more information about these fields in the |SEC_SPEC|. Messages from the |RTI_SP_PRODUCT| can have these possible values for the ``plugin_class`` field: ``DDS:Auth:PKI-DH`` (Builtin) and ``DDS:Auth:PSK`` (Lightweight Builtin) for the |AuthPlugin|, ``DDS:Access:Permissions`` (Builtin) and ``DDS:Access:PSK`` (Lightweight Builtin) for the |AccessControlPlugin|, ``DDS:Crypto:AES-GCM-GMAC`` (Builtin) and ``DDS:Crypto:PSK`` (Lightweight Builtin) for the |CryptoPlugin|, ``DDS:Logging:DDS_LogTopic`` for the |LoggingPlugin| (both |SP_BUILTIN| and |LIGHT_SP_BUILTIN|) and ``RTI:Common`` for error messages logged by functionality that is not tied to one of the builtin plugins defined in the Security specification. The ``RTI:Auth``, ``RTI:Access``, ``RTI:Crypto``, and ``RTI:Logging`` plugin class names are also used for Security Events logged by the core libraries. The messages may be preceded by additional information, such as timestamps or GUIDs, depending on the |NDDS_Config_Logger| format configuration and the message :link_connext_dds_api_cpp:`NDDS_Config_LogLevel `. (See :link_connext_dds_pro_um:`Format of Logged Messages, in the RTI Connext DDS Core Libraries User's Manual <#users_manual/Format_of_Logged_Messages.htm>`.) By default, the |NDDS_Config_Logger| writes to the standard output, but you can configure it to use a log file or an output device such as a custom logging device or the Distributed Logger. (See :link_connext_dds_pro_um:`Configuring Connext Logging in the RTI Connext DDS Core Libraries User's Manual <#users_manual/Controlling_Messages_from_.htm>` and :link_connext_dds_pro_um:`RTI Distributed Logger in the Core Libraries User's Manual <#users_manual/PartDistributedLogger.htm>`.) .. note:: When using |RTI_OBSERVABILITY|, the Grafana dashboards will display the plugin class names for every security event. The dashboards also display a *category* field that represents a more friendly name for these standard plugin class names. For more information, see :link_addon_products_observability_up_two:`the Observability User Manual `. Logging Security Events through the Connext DDS Builtin Logging System ---------------------------------------------------------------------- To make the security log go through the |NDDS_Config_Logger|, enable the :value:`BUILTIN` flag with the :property:`logging.mode_mask` property within the :xmltag:`domain_participant_qos` (this is the default configuration, see :link_connext_dds_pro_um:`Configuring QoS with XML, in the RTI Connext DDS Core Libraries User's Manual <#users_manual/XMLConfiguration.htm>`): .. code-block:: xml com.rti.serv.secure.logging.mode_mask BUILTIN The granularity of the log messages depends on the verbosity level set for the security log. You can set the verbosity level as follows, :value:`DEBUG` being the highest verbosity level (see :ref:`p2_core/logging:Properties for Configuring Security Events and Logging`): .. code-block:: xml com.rti.serv.secure.logging.verbosity DEBUG Distributed Over DDS ==================== When the messages are distributed over DDS, the information will be logged using the :type:`BuiltinLoggingTypeV2`, following the |SEC_SPEC|. For example, here is how the messages look in *RTI DDS Spy* (using the :command:`-printSample` option) when you use logging distribution over DDS: .. code-block:: text :class: break-lines 1543498637.929123 d +M DCB9C740 DDS:Security:LogTopicV2 DDSSecurity::BuiltinLoggingTypeV2 facility: 10 severity: DEBUG_LEVEL timestamp: sec: 1543498637 nanosec: 928903998 hostname: "localhost" hostip: "0.0.0.0" appname: "RTI Secure DDS Application" procid: "9654" msgid: "33554496" message: "received submessage from an endpoint that discovered me but that I haven't discovered yet; dropping submessage hoping it will be repaired. It will not be repaired if the endpoint did not properly share its MasterKeyId in its CryptoToken." structured_data: [0]: key: "DDS" pairs: [0]: name: "guid" value: "DCB9C740.7ECF85EB.42AA8349.000001C1" [1]: name: "domain_id" value: "25" [2]: name: "plugin_method" value: "RTI_Security_Cryptography_preprocess_secure_submsg" [3]: name: "plugin_class" value: "DDS:Crypto:AES-GCM-GMAC" Configuring the Logging Distribution ------------------------------------ To distribute the log messages over DDS, enable the :value:`SECURITY_TOPIC` flag with the :property:`logging.mode_mask` [#distributeEnable]_ property within the :xmltag:`domain_participant_qos` (see :link_connext_dds_pro_um:`Configuring QoS with XML, in the RTI Connext DDS Core Libraries User's Manual <#users_manual/XMLConfiguration.htm>`): .. code-block:: xml com.rti.serv.secure.logging.mode_mask SECURITY_TOPIC The granularity of the log messages depends on the verbosity level set for the security log. You can set the verbosity level as follows, :value:`DEBUG` being the highest verbosity level (see :ref:`p2_core/logging:Properties for Configuring Security Events and Logging`): .. code-block:: xml com.rti.serv.secure.logging.verbosity DEBUG For more details on configuring the Logging Distribution over DDS, see :numref:`|RTI_SP_PRODUCT_HEADING| Properties for Configuring Logging`. Builtin Secure Logging Topic ---------------------------- When you distribute the security logging information over DDS, your |DP| will publish this information to the |LoggingT| (``DDS:Security:LogTopicV2``), as defined in the |SEC_SPEC|. DDS samples in this topic will have the type :type:`BuiltinLoggingTypeV2` (``DDSSecurity::BuiltinLoggingTypeV2``). This type includes information about the logging level, the |DP| producing the message, a timestamp, etc. You can find the IDL description of the :type:`BuiltinLoggingTypeV2` in :file:`/resource/idl/builtin_logging_type.idl`. (See :ref:`p0_about/about_this_doc:Paths Mentioned in Documentation`.) Implementation Notes -------------------- Publication of the Builtin Secure Logging Topic ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The ``DDS:Security:LogTopicV2`` (described in :ref:`p2_core/logging:Subscribing to the Builtin Logging Topic`) is published by the same |DP| that uses the |RTI_SP_PRODUCT| to communicate securely. Therefore, this topic is published in a |SecDomain|, and the Governance and Permissions Documents that apply to that |DP| also apply to this log topic. For this reason, the |PermissionsDoc| must allow the ``DDS:Security:LogTopicV2`` to be published. By default, the ``DDS:Security:LogTopicV2`` is protected using |SubmsgProtection| set to :xmlval:`SIGN` [#]_ (see :ref:`p2_core/elements_dds_secure_system:Builtin Secure Logging Topic`). .. attention:: There is no option to use a separate “Builtin Logging” |DP| and to share it among multiple |DPs|. Custom QoS Profile for the Builtin Secure Logging Topic ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The |RTI_SP_PRODUCT| publish log messages using the QoS Profile specified by the property :property:`logging.security_topic.profile`. If this property is not set, the |RTI_SP_PRODUCT| will use the :value:`BuiltinQosLib::Generic.KeepLastReliable.TransientLocal` profile by default, and the |RTI_SP_PRODUCT| will set history.depth to 64 and publish_mode.kind to DDS_ASYNCHRONOUS_PUBLISH_MODE_QOS. If you specify a custom profile in the property :property:`logging.security_topic.profile`, only |PUB|, |TOPIC|, and |DW| QoS will be used from the specified profile. This is because the |DW| that distributes the log belongs to the same |DP| as the one instantiating the |RTI_SP_PRODUCT|. As a result, you can use the custom profile for the logger if, for example, you want to change the logger's reliability, but you cannot use it to change the logger's identity (|PrivateKey| and |IdentityCert|). .. [#distributeEnable] Before release 6.1.0 of |CONNEXT|, enabling the logging distribution was done by setting the :property:`logging.distribute.enable` property to :value:`TRUE`. In |CONNEXT| 6.1.0, this property has been removed, and setting it will result in a |DP| creation failure. .. [#] In |CONNEXT| 5.3.0, the |LoggingT| did not use |SubmsgProtection| (which did not comply with the |SEC_SPEC|). For backward compatibility, you can choose to disable |SubmsgProtection| in this topic with the :property:`access_control.use_530_logging_protection property` (see :numref:`Additional |RTI_SP_PRODUCT_HEADING| Properties for Configuring Logging Distributed Over DDS`). Advanced Logging Concepts ========================= Interface Between the Logging Plugin and the Connext DDS Builtin Logging System ------------------------------------------------------------------------------- Log messages generated by the |LoggingPlugin| in the |RTI_SP_PRODUCT| and those generated by the |NDDS_Config_Logger| (which is the default method) have a different structure. For example, the |LoggingPlugin| includes information about the process ID (procid) and the host (hostname, hostip) as fields of the ``DDSSecurity::BuiltinLoggingTypeV2`` type. To provide this information when using the |NDDS_Config_Logger|, security messages use a JSON format, as specified in :ref:`p2_core/logging:Connext DDS Builtin Logging System`. The log level values used by these logging systems are also different. :numref:`Mapping Between Logging Plugin and Connext DDS Builtin Logging System` shows the mapping between |LoggingPlugin| log values and the |NDDS_Config_Logger| log values. For example, messages marked as :value:`EMERGENCY`, :value:`ALERT`, :value:`CRITICAL`, or :value:`ERROR` in the |RTI_SP_PRODUCT| are translated to :value:`ERROR` when using the |NDDS_Config_Logger|. .. list-table:: Mapping Between |LoggingPlugin| and |NDDS_Config_Logger| :name: Mapping Between Logging Plugin and Connext DDS Builtin Logging System :widths: 48 52 :header-rows: 1 :class: longtable * - |LoggingPlugin| (|RTI_SP_PRODUCT|) Log Level Values [#]_ - |NDDS_Config_Logger| Log Level Values [#]_ * - :value:`DDS_LOGGING_EMERGENCY_LEVEL` - :value:`NDDS_CONFIG_LOG_LEVEL_FATAL_ERROR` * - :value:`DDS_LOGGING_ALERT_LEVEL` |BR| :value:`DDS_LOGGING_CRITICAL_LEVEL` |BR| :value:`DDS_LOGGING_ERROR_LEVEL` - :value:`NDDS_CONFIG_LOG_LEVEL_ERROR` * - :value:`DDS_LOGGING_WARNING_LEVEL` - :value:`NDDS_CONFIG_LOG_LEVEL_WARNING` * - :value:`DDS_LOGGING_NOTICE_LEVEL` |BR| :value:`DDS_LOGGING_INFORMATIONAL_LEVEL` - :value:`NDDS_CONFIG_LOG_LEVEL_STATUS_LOCAL` * - :value:`DDS_LOGGING_DEBUG_LEVEL` - :value:`NDDS_CONFIG_LOG_LEVEL_DEBUG` .. [#] These values correspond to the values listed in :property:`logging.verbosity` (see :numref:`|RTI_SP_PRODUCT_HEADING| Properties for Configuring Logging`). .. [#] These values are described in :link_connext_dds_pro_um:`Configuring Connext Logging in the RTI Connext DDS Core Libraries User's Manual <#users_manual/Controlling_Messages_from_.htm>`. Subscribing to the Builtin Logging Topic ---------------------------------------- To get the security logging information that is being distributed over DDS, you will need to create an application that subscribes to the |LoggingT|: * Topic name: ``DDS:Security:LogTopicV2`` * Type name: ``DDSSecurity::BuiltinLoggingTypeV2`` .. note:: Since the log messages are distributed in a secured domain, your subscriber needs an identity (|PrivateKey| and |IdentityCert|). In addition, it needs to have permission to subscribe to topic ``DDS:Security:LogTopicV2``; this permission needs to be included in its |PermissionsDoc|. You can subscribe to the |LoggingT| with *RTI DDS Spy* using the :command:`-printSample` option. .. code-block:: text rtiddsspy -printSample -domainId -qosProfile Alternatively, to create a custom subscriber, you can start from the IDL containing the definition of the ``DDSSecurity::BuiltinLoggingTypeV2``, which can be found here: :file:`/resource/idl/builtin_logging_type.idl`. (See :ref:`p0_about/about_this_doc:Paths Mentioned in Documentation`.) With the IDL, you can run :command:`rtiddsgen` to generate type support code and example code. For example, the following command will generate all the files you need to access the ``DDS:Security:LogTopicV2`` topic from your |CONNEXT| application: .. code-block:: text rtiddsgen -language C -example x64Linux3gcc4.8.2 -unboundedSupport builtin_logging_type.idl .. important:: You need to use the command-line option :command:`-unboundedSupport` because ``DDSSecurity::BuiltinLoggingTypeV2`` contains strings without a specified limit. By default, :command:`rtiddsgen` will limit unbounded strings to 255 characters, unless you specify the :command:`-unboundedSupport` option. Without this option, the type support code will not be compatible with the type used by the |RTI_SP_PRODUCT|, and you won't be able to receive any messages. For more information about the use of unbounded support with builtin types, see :link_connext_dds_pro_um:`Managing Memory for Builtin Types in the RTI Connext DDS Core Libraries User's Manual <#users_manual/Managing_Memory_for_Built_in_Types.htm>`. Properties for Configuring Security Events and Logging ====================================================== The following properties in the |DP| property configure Logging: .. list-table:: |RTI_SP_PRODUCT| Plugins Properties for Configuring Logging :name: |RTI_SP_PRODUCT_HEADING| Properties for Configuring Logging :widths: 35 65 :header-rows: 1 :class: longtable * - Property Name (prefix with :property:`com.rti.serv.secure.`) [#fPrefix]_ - Property Value Description * - :property:`logging.log_level` (<< deprecated >>) - :required:`Optional` The logging verbosity level. This setting applies to all methods of security logging (the :ref:`p2_core/logging:Connext DDS Builtin Logging System` and :ref:`p2_core/logging:Distributed Over DDS`) and all types of messages (security and non-security events). All log messages at and below the :property:`logging.log_level` setting will be logged. This property can take any of the following values: * :value:`0`: emergency * :value:`1`: alert * :value:`2`: critical * :value:`3` (default): error * :value:`4`: warning * :value:`5`: notice * :value:`6`: informational * :value:`7`: debug Notes: * This property is (<< deprecated >>) and may stop working in a future release. Use :property:`logging.verbosity` instead. * This property is incompatible with :property:`logging.verbosity` (i.e., if they are used simultaneously, participant creation will fail). :type:`Integer`: :value:`[0-7]` Default: :value:`3` (error) * - :property:`logging.verbosity` - :required:`Optional` The logging verbosity level. This setting applies to all methods of security logging (the :ref:`p2_core/logging:Connext DDS Builtin Logging System` and :ref:`p2_core/logging:Distributed Over DDS`) and all types of messages (security and non-security events). All log messages at and below the verbosity level will be logged. This property can take any of the following values (case sensitive): * :value:`SILENT` (least verbose) * :value:`EMERGENCY` * :value:`ALERT` * :value:`CRITICAL` * :value:`ERROR` (default) * :value:`WARNING` * :value:`NOTICE` * :value:`INFORMATIONAL` * :value:`DEBUG` (most verbose) Notes: * This property is incompatible with :property:`logging.log_level` (i.e. if they are used simultaneously, participant creation will fail). * Setting this property will also set the SECURITY category verbosity to the same level. Additionally, because all messages logged by the |RTI_SP_PRODUCT| fall under the SECURITY category, changing the verbosity for the SECURITY category will also set the |RTI_SP_PRODUCT| verbosity to the same value. See :link_connext_dds_pro_um:`Configuring Connext Logging in the RTI Connext DDS Core Libraries User's Manual <#users_manual/Controlling_Messages_from_.htm>` for more information about Message Logging Categories [#]_. * The verbosity level for security events always matches the level configured through this property or through the SECURITY category. The only exception in which these two levels may differ is when an |RTI_OBSERVABILITY| remote administration command modifies the collection verbosity for the ``SECURITY_EVENT`` facility. :type:`Enum`: :value:`SILENT`, :value:`EMERGENCY`, :value:`ALERT`, :value:`CRITICAL`, :value:`ERROR`, :value:`WARNING`, :value:`NOTICE`, :value:`INFORMATIONAL`, :value:`DEBUG` Default: :value:`ERROR` * - :property:`logging.mode_mask` - :required:`Optional` Controls which logging methods are used to process the log messages produced by the |LoggingPlugin|. You can specify one of these possible values: * :value:`BUILTIN` * :value:`SECURITY_TOPIC` Or any combination of the above, separating each element by :value:`|`. For example: :value:`BUILTIN | SECURITY_TOPIC` When :value:`BUILTIN` is enabled, the |LoggingPlugin| will use the :ref:`p2_core/logging:Connext DDS Builtin Logging System`. When :value:`SECURITY_TOPIC` is enabled, the |LoggingPlugin| will create a |PUB| and |DW| within the same |DP| that is setting this property. There is no option to use a separate |DP| or to share a |DW| among multiple |DPs|. (See :ref:`p2_core/logging:Subscribing to The Builtin Logging Topic`.) :type:`Mask`: :value:`BUILTIN` | :value:`SECURITY_TOPIC` Default: :value:`BUILTIN` .. list-table:: Additional |RTI_SP_PRODUCT| Properties for Configuring Logging Distributed Over DDS [#]_ :name: Additional |RTI_SP_PRODUCT_HEADING| Properties for Configuring Logging Distributed Over DDS :widths: 40 60 :header-rows: 1 :class: longtable * - Property Name (prefix with :property:`com.rti.serv.secure.`) [#fPrefix]_ - Property Value Description * - :property:`logging.security_topic.profile` - :required:`Optional` QoS Library and QoS Profile used to create logging-related entities (|PUB|, |TOPIC| and |DW|). Must be a string of the format :value:`"QosLibraryName::QosProfileName"`. If the profile does not specify the :property:`fast_pool.pool_buffer_max_size` in the :property:`dds.data_writer.history.memory_manager` property, its value will be set to :value:`512`. :type:`String`. Default: :value:`"BuiltinQosLib::Generic.KeepLastReliable.TransientLocal"`, with history.depth = 64 and publish_mode.kind = DDS_ASYNCHRONOUS_PUBLISH_MODE_QOS * - :property:`logging.security_topic.queue.size` - :required:`Optional` Size of the logging thread queue, in bytes. :type:`Integer`. Default: :value:`50688` * - :property:`logging.security_topic.queue.message_count_max` - :required:`Optional` Maximum number of log messages in the logging queue. :type:`Integer`. Default: :value:`64` * - :property:`logging.security_topic.queue.message_size_max` - :required:`Optional` Maximum serialized size of a log message in the logging queue. :type:`Integer`. Default: :value:`792` * - :property:`logging.security_topic.thread.message_threshold` - :required:`Optional` Number of bytes to preallocate for the logging message string in the logging thread, beyond which dynamic allocation will occur. :type:`Integer`. Default: :value:`256` * - :property:`logging.security_topic.thread.plugin_method_threshold` - :required:`Optional` Number of bytes to preallocate for the plugin method string in the logging thread, beyond which dynamic allocation will occur. :type:`Integer`. Default: :value:`256` * - :property:`logging.security_topic.thread.plugin_class_threshold` - :required:`Optional` Number of bytes to preallocate for the plugin class string in the logging thread, beyond which dynamic allocation will occur. :type:`Integer`. Default: :value:`256` * - :property:`access_control.use_530_logging_protection` - :required:`Optional` How to set the value of :xmltag:`metadata_protection_kind` for the :ref:`p2_core/logging:Builtin Secure Logging Topic`. If :value:`TRUE`: the value will be :xmlval:`NONE`, which is consistent with |CONNEXT| 5.3.0 behavior. If :value:`FALSE`: the value will be :xmlval:`SIGN`, which is consistent with the behavior of the |SEC_SPEC|. :type:`Boolean`. Default: :value:`FALSE` .. [#fPrefix] Assuming you used :value:`com.rti.serv.secure` as the alias to load the plugin. If not, change the prefix to match the string used with :property:`com.rti.serv.load_plugins`, followed by the :value:`.` character. .. [#] When security messages (events and non-events) are logged using the |NDDS_Config_Logger|, since they belong to the SECURITY category, the Activity Context will show ``LC:Security`` for all of them. .. [#] Before version 6.1.0 of |CONNEXT|, properties for configuring security logging distributed over DDS had a name starting with :property:`logging.distribute`. Starting with |CONNEXT| 6.1.0, these properties start with :property:`logging.security_topic`. Properties using the former names are deprecated but still usable. If you set a property using both the :property:`logging.distribute` and the :property:`logging.security_topic` forms, the latter will take effect and the former will be ignored. Logging Messages ================ :numref:`Log Messages` lists security-related events and the log messages they generate. .. list-table:: Log Messages :name: Log Messages :widths: 33 20 47 :header-rows: 1 :class: longtable * - Event - Log Level - Message * - Failed to validate local Permissions Document. - :value:`ALERT` - .. code-block:: text :class: break-lines-anywhere failed to validate local permissions * - Failed to validate remote Permissions Document. - :value:`ALERT` - .. code-block:: text :class: break-lines-anywhere failed to validate remote permissions * - Topic/DataWriter/DataReader not allowed. - :value:`ALERT` - .. code-block:: text :class: break-lines-anywhere topic not allowed: cannot be published or subscribed / datawriter not allowed / datareader not allowed * - Failed to allocate memory - :value:`CRITICAL` - .. code-block:: text :class: break-lines-anywhere insufficient memory * - Received invalid X509 certificate, from either remote or local participant - :value:`ERROR` - .. code-block:: text :class: break-lines-anywhere failed to decode certificate * - Couldn't verify certificate's signature against neither the certificate of the Identity Certificate Authority nor any alternative CAs - :value:`ERROR` - .. code-block:: text :class: break-lines-anywhere failed to verify certificate * - Certificate appears in Certificate Revocation List - :value:`ERROR` [#always_NDDS_Config_Logger]_ - .. code-block:: text :class: break-lines-anywhere certificate revoked * - Upon receiving HandshakeReplyMessageToken or HandshakeFinalMessageToken, couldn't verify challenge's signature against peer's certificate. Peer likely has mismatched private and public keys, so it’s an imposter. - :value:`ERROR` - .. code-block:: text :class: break-lines-anywhere failed to verify challenge signature * - Couldn't verify permissions or governance file signature against either the certificate of the Permissions Authority or any alternative permissions authorities - :value:`ERROR` - .. code-block:: text :class: break-lines-anywhere Document signature verification failed. Make sure document was signed by the right permissions authority. * - Received signed permissions document that is not an XML document - :value:`ERROR` - .. code-block:: text :class: break-lines-anywhere received invalid signed permissions document * - Received signed governance document that is not an XML document - :value:`ERROR` - .. code-block:: text :class: break-lines-anywhere received invalid signed governance document * - Couldn't parse the Permissions Document for some reason, such as duplicate grants for the same subject name or no grant for the intended subject name - :value:`ERROR` - .. code-block:: text :class: break-lines-anywhere failed to parse Permissions Document * - Couldn't parse the governance document for some reason - :value:`ERROR` - .. code-block:: text :class: break-lines-anywhere failed to parse governance file * - Denied participant because there is a deny rule explicitly prohibiting the participant - :value:`ERROR` - .. code-block:: text :class: break-lines-anywhere participant not allowed: deny rule found * - Denied participant because there is no rule for the participant's domain ID, and the default is to deny - :value:`ERROR` - .. code-block:: text :class: break-lines-anywhere participant not allowed: no rule found for the participant's domainId; default DENY * - Denied writer or reader because there is a deny rule explicitly prohibiting the writer or reader - :value:`ERROR` - .. code-block:: text :class: break-lines-anywhere endpoint not allowed: deny rule found * - Denied writer or reader because there is no rule for the writer or reader, and the default is to deny - :value:`ERROR` - .. code-block:: text :class: break-lines-anywhere endpoint not allowed: no rule found; default DENY * - Received authenticated content that has been tampered with, i.e. EVP_DecryptFinal_ex failed because the GCM or GMAC tag verification failed - :value:`ERROR` - .. code-block:: text :class: break-lines-anywhere DecryptFinal failed. Possible GCM authentication failure. * - allow_unauthenticated_participants = FALSE, and discovered remote participant that is unauthenticable, i.e. has not enabled security - :value:`WARNING` - .. code-block:: text :class: break-lines-anywhere unauthenticated remote participant [participant ID] denied * - allow_unauthenticated_participants = TRUE, and discovered remote participant that is either unauthenticable or fails authentication - :value:`WARNING` - .. code-block:: text :class: break-lines-anywhere allowing unauthenticated participant [participant ID] * - Writing a log message over the LogTopicV2 fails due to insufficient logging queue size - :value:`STATUS_LOCAL` [#always_NDDS_Config_Logger]_ - .. code-block:: text :class: break-lines-anywhere Failed to write log message of size = [message size] because the logging queue is full. Try to increase logging.security_topic.queue.message_count_max, which is currently [message_count_max]. * - Another participant, which is not using is_rtps_axk_protected = true or is not using security at all, has sent this one an unprotected RTPS message that is not a participant announcement, handshake message, or key exchange message. This participant is using is_rtps_axk_protected = true, so it drops the message. Or: Network traffic corruption after key exchange. Or: Misbehaving remote participant after key exchange. - :value:`STATUS_REMOTE` [#always_NDDS_Config_Logger]_ - .. code-block:: text :class: break-lines-anywhere MIGInterpreter_parse:received unencoded rtps message. Unacceptable due to is_rtps_axk_protected = true * - RTI_Security_Authentication_process_handshake failed (see next row). - :value:`STATUS_REMOTE` [#always_NDDS_Config_Logger]_ - .. code-block:: text :class: break-lines-anywhere DDS_DomainParticipantTrustPlugins_forwardProcessHandshake:!security function process_handshake returned VALIDATION_FAILED * - Another participant has lost liveliness with this one before authentication was completed and is trying to re-authenticate itself (see :ref:`p2_core/authentication:Re-Authentication`). A new authentication should restore communication once the ongoing authentication times out. Or: Network traffic corruption during authentication. Or: Misbehaving remote participant during authentication. - :value:`NOTICE` - .. code-block:: text :class: break-lines-anywhere RTI_Security_Authentication_process_handshake:received unexpected handshake message, probably from a participant that lost liveliness with this one before ongoing authentication completed. Once current authentication times out, communication should be restored. * - Received submessage encrypted with a key whose MasterKeyId hasn't yet been exchanged via CryptoToken - :value:`DEBUG` - .. code-block:: text :class: break-lines-anywhere received submessage from an endpoint that discovered me but that I haven't discovered yet; dropping submessage hoping it will be repaired. It will not be repaired if the endpoint did not properly share its MasterKeyId in its CryptoToken * - Parsed publish/subscribe rule in Permissions Document that does not apply to the writer/reader because no topic expressions match the writer/reader's topic - :value:`DEBUG` - .. code-block:: text :class: break-lines-anywhere This publish/subscribe rule doesn't apply because none of the rule's topic expressions match the endpoint's topic name of [topic name] * - Parsed publish/subscribe rule in Permissions Document that does not apply to the writer/reader because even though there's a matching topic expression, there are no matching partition expressions - :value:`DEBUG` - .. code-block:: text :class: break-lines-anywhere This publish/subscribe rule doesn't apply because none of the rule's partition expressions match with any of the endpoint's partitions * - Parsed publish/subscribe in Permissions Document that does not apply to the writer/reader because even though there's a matching topicexpression, the partition expressions in the QoS are not a subset of the ones in the - :value:`DEBUG` - .. code-block:: text :class: break-lines-anywhere This publish/subscribe rule doesn't apply because endpoint's partitions are not a subset of the rule's partition expressions .. [#always_NDDS_Config_Logger] This log message is logged using |CONNEXT|'s own builtin logging system, regardless of the logging method used.