Mqtt protocol-aware access verification method and system

Abstract

The application relates to an MQTT protocol sensing access verification method, which comprises the following steps: receiving a connection request initiated by a client, and analyzing a CONNECT message in the connection request to obtain a plurality of parameter fields, wherein the parameter fields comprise protocol version information, a client identifier, a username, a keep-alive time and an MQTT5.0 attribute field; based on a preset policy set organized according to tenants, performing rule matching and parameter consistency verification on the parameter fields; when any verification result does not satisfy a condition preset by a corresponding policy, generating a corresponding rejection reason code and a hit policy identifier, and rejecting the connection request before an MQTT session is formally established; and when all verification results satisfy the policy requirements, allowing the MQTT session to be established. Through the application, the problem of insufficient access security of the MQTT protocol is solved, protocol semantic level verification is performed before the MQTT session is established, invalid connections are blocked, and application layer attacks are prevented.

Description

Technical Field

[0001] This application relates to the field of network security technology, and in particular to MQTT protocol-aware access verification methods and systems. Background Technology

[0002] Currently, MQTT protocol access control primarily relies on username / password authentication, token authentication, or topic-based access control mechanisms. These authentication operations are typically performed after the MQTT connection is established but before the session officially begins, making it impossible for the system to effectively filter abnormal or malicious connections during the initial connection phase. A large number of invalid connections still consume system resources for protocol parsing, session creation, and authentication processing, reducing the service efficiency of the MQTT Broker. This resource waste is particularly pronounced in scenarios with massive IoT device access.

[0003] Existing firewalls and intrusion detection systems often employ anomaly detection methods based on port characteristics, packet length distribution, or machine learning models when handling MQTT traffic. These technologies primarily focus on packet identification or statistical analysis of the MQTT protocol, lacking the ability to semantically parse and constrain key fields in CONNECT packets. For example, they cannot jointly verify the consistency of naming rules between ClientID and Username, the reasonable range of KeepAlive parameters, and the matching relationship between protocol version and attribute fields, resulting in many application-layer attacks failing to be effectively identified.

[0004] The MQTT 5.0 protocol introduced attribute fields (such as session expiration time, maximum message length, and user attributes), significantly increasing the complexity and configurability of connection parameters. However, existing technologies lack a unified mechanism for constraining the scope of MQTT 5.0 attribute fields, verifying whitelists, and checking consistency with other connection parameters. Furthermore, in multi-tenant cloud platform environments, different tenants often have different requirements for ClientID naming rules and connection parameter thresholds. Existing MQTTBrokers generally lack fine-grained parameter verification capabilities at the tenant level, which can easily lead to resource abuse, naming conflicts, and cross-tenant security risks. Summary of the Invention

[0005] This application provides an MQTT protocol-aware access verification method, system, electronic device, and storage medium to at least address the problem of insufficient access security of the MQTT protocol in related technologies.

[0006] In a first aspect, embodiments of this application provide an MQTT protocol-aware access verification method, the method comprising: The system receives a connection request initiated by the client and parses the CONNECT message in the connection request to obtain multiple parameter fields, including protocol version information, client identifier, username, keep-alive time and MQTT5.0 attribute fields. Based on a preset set of strategies organized by tenant dimension, rule matching and parameter consistency verification are performed on the parameter fields. The rule matching supports at least one or more of the following matching methods: exact matching, prefix matching, suffix matching, and regular expression matching. The parameter consistency verification includes protocol version validity verification, client identifier and username naming rule verification, keep-alive time range verification, and MQTT 5.0 attribute field range verification or whitelist verification. If any verification result does not meet the conditions preset by the corresponding policy, a corresponding rejection reason code and policy hit identifier are generated, and the connection request is rejected before the MQTT session is officially established; if all verification results meet the policy requirements, the establishment of the MQTT session is allowed.

[0007] In some embodiments, different tenants correspond to different policy sets, and tenant identity is identified based on the prefix of the client identifier, the domain name part of the username, or the tenant identifier key value in the MQTT5.0 attribute field. Each policy in the policy set includes at least a matching condition and a validation constraint. The matching condition is used to determine the applicable client range, and the validation constraint is used to define the legality conditions that the corresponding parameter fields should meet. The policy sets of different tenants are independent of each other to support differentiated access control in a multi-tenant isolation environment.

[0008] In some embodiments, the rule matching supports multi-level priority configuration, allowing for customization of the execution order of different matching methods; When multiple rules match the same parameter field, the rule with the highest priority is selected as the basis for judgment.

[0009] In some embodiments, the rejection reason code is used to identify the specific reason for the connection being rejected, including invalid protocol version, mismatched identity field, out-of-bounds parameter, or illegal attribute; The hit strategy identifier is used to record the specific strategy rule number that triggers the abandonment decision, supporting subsequent audit tracking and strategy optimization.

[0010] In some embodiments, the naming rule verification of the client identifier and the username includes length range limit verification, character set whitelist verification, and naming rule consistency verification; The naming rule consistency check is used to verify whether the client identifier and the username belong to the same tenant or the same device type, to prevent cross-tenant identity spoofing attacks; the character set whitelist check only allows letters, numbers and preset special characters to pass, in order to defend against injection attacks.

[0011] In some embodiments, the whitelist verification of the MQTT5.0 attribute field includes authentication method whitelist verification, which only allows authentication methods belonging to a preset set of strong security authentication methods to pass, in order to defend against authentication downgrade attacks; The range validation of the MQTT 5.0 attribute fields includes maximum message length limit validation, session expiration time range validation, and key-value pair format and quantity limit validation of user attribute fields; If the attribute fields carried in the connection request exceed the preset range or contain authentication methods not on the whitelist, the verification is considered to have failed.

[0012] In some embodiments, the method further includes: Record each policy matching result and connection handling result, and generate statistical indicators. These statistical indicators should include at least the number of policy hits, the number of connection rejections, the distribution of different rejection reason codes, and the access success rate aggregated by tenant dimension; and / or When the rejection rate of any policy is detected to be abnormally high within a preset time range, an alarm mechanism is triggered to prompt the administrator to review the policy configuration.

[0013] Secondly, embodiments of this application provide an MQTT protocol-aware access verification system, the system comprising: The parsing module is used to receive connection requests initiated by clients and parse the CONNECT message in the connection request to obtain multiple parameter fields, including protocol version information, client identifier, username, keep-alive time and MQTT5.0 attribute fields. The verification module is used to perform rule matching and parameter consistency verification on the parameter fields based on a preset set of policies organized by the tenant dimension. The rule matching supports at least one or more of the following matching methods: exact matching, prefix matching, suffix matching, and regular expression matching. The parameter consistency verification includes protocol version validity verification, client identifier and username naming rule verification, keep-alive time range verification, and MQTT 5.0 attribute field range verification or whitelist verification. The execution module is used to generate a corresponding rejection reason code and a hit policy identifier when any verification result does not meet the preset conditions of the corresponding policy, and to reject the connection request before the MQTT session is officially established; when all verification results meet the policy requirements, the establishment of the MQTT session is allowed.

[0014] Thirdly, embodiments of this application provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the MQTT protocol-aware access verification method as described in the first aspect above.

[0015] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the MQTT protocol-aware access verification method as described in the first aspect above.

[0016] Compared to related technologies, the MQTT protocol-aware access verification method provided in this application advances the verification timing to before the formal establishment of the MQTT session. It can block abnormal connections even when session resources are not allocated, effectively preventing resource exhaustion attacks. Simultaneously, by performing protocol semantic-level parsing on the CONNECT message, it can verify the consistency of the client identifier and username naming rules to prevent cross-tenant spoofing, and perform whitelist verification on MQTT 5.0 attribute fields to defend against application-layer attacks such as authentication downgrades and attribute injection.

[0017] Through pre-verification, all connection requests that fail verification will not trigger resource-intensive operations such as session object creation and authentication processing. In scenarios with massive IoT device access, this can significantly reduce the CPU, memory, and connection slot usage caused by invalid connections. Meanwhile, the tenant-based policy set achieves isolation of multi-tenant access control, avoiding naming conflicts and cross-tenant resource contention, thus improving the access security of the MQTT protocol. Attached Figure Description

[0018] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a flowchart of the MQTT protocol-aware access verification method according to an embodiment of this application; Figure 2 This is a structural block diagram of an MQTT protocol-aware access verification system according to an embodiment of this application; Figure 3 This is a schematic diagram of the internal structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this application clearer, the application is described and illustrated below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. All other embodiments obtained by those skilled in the art based on the embodiments provided in this application without inventive effort are within the scope of protection of this application.

[0020] Obviously, the accompanying drawings described below are merely some examples or embodiments of this application. Those skilled in the art can apply this application to other similar scenarios based on these drawings without any inventive effort. Furthermore, it is understood that although the efforts made in this development process may be complex and lengthy, for those skilled in the art related to the content disclosed in this application, any changes to design, manufacturing, or production based on the technical content disclosed in this application are merely conventional technical means and should not be construed as insufficient disclosure of the content of this application.

[0021] In this application, the reference to "embodiment" means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment that is mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described in this application may be combined with other embodiments without conflict.

[0022] Unless otherwise defined, the technical or scientific terms used in this application shall have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms “a,” “an,” “an,” “the,” and similar words used in this application do not indicate quantity limitation and may indicate singular or plural. The terms “comprising,” “including,” “having,” and any variations thereof used in this application are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that includes a series of steps or modules (units) is not limited to the listed steps or units, but may also include steps or units not listed, or may include other steps or units inherent to these processes, methods, products, or devices. The terms “connected,” “linked,” “coupled,” and similar words used in this application are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. “Multiple” used in this application refers to two or more. “And / or” describes the relationship between related objects, indicating that three relationships may exist; for example, “A and / or B” can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following objects are in an "or" relationship. The terms "first," "second," and "third" used in this application are merely to distinguish similar objects and do not represent a specific ordering of the objects.

[0023] This embodiment provides an MQTT protocol-aware access verification method. Figure 1 This is a flowchart of the MQTT protocol-aware access verification method according to an embodiment of this application, such as... Figure 1 As shown, the process includes the following steps: Step S101: Receive the connection request initiated by the client, and parse the CONNECT message in the connection request to obtain multiple parameter fields, including protocol version information, client identifier, username, keep-alive time and MQTT5.0 attribute fields.

[0024] Before the MQTT session is formally established, the CONNECT message in the connection request initiated by the client is intercepted and parsed. Specifically, after the client completes the TCP three-way handshake with the MQTT Broker, the first control message sent by the client is the CONNECT message. Step S101 intervenes at this moment, strictly parsing the message according to the MQTT protocol specification to extract several key parameter fields required for subsequent verification. These fields include protocol version information (used to identify MQTT 3.1, 3.1.1, or 5.0 version), client identifier ClientID (used to uniquely identify the device), username (used for authentication and tenant identification), keepalive time (used to control the heartbeat interval), and properties fields introduced by the MQTT 5.0 protocol (such as session expiration time, maximum message length, authentication method, etc.).

[0025] The key technical features of this step lie in its pre-emptive and complete nature. Pre-emptiveness is reflected in the fact that the parsing operation is completed before the Broker creates the session object, allocates Will Message storage resources, or executes any authentication process. This means that even if parsing fails or subsequent verification fails, it will not cause any resource consumption on the Broker's session state, realizing the security design principle of "verification first, allocation later." Completeness is reflected in the fact that this step not only extracts the traditional mandatory fields of the MQTT protocol but also specifically parses the attribute fields added to the MQTT 5.0 protocol, including session expiration time, maximum message length, authentication method, user attributes, etc., ensuring that the verification mechanism can cover all security-related parameters of the new protocol version and avoid security blind spots caused by missing fields. Through the parsing in step S101, subsequent rule matching and consistency verification can obtain accurate and complete input data.

[0026] Step S102: Based on the preset set of strategies organized by tenant dimension, perform rule matching and parameter consistency verification on the parameter fields. The rule matching supports at least one or more of the following matching methods: exact matching, prefix matching, suffix matching, and regular expression matching.

[0027] Parameter consistency verification includes protocol version validity verification, client identifier and username naming rule verification, keep-alive time range verification, and MQTT 5.0 attribute field range verification or whitelist verification.

[0028] In some embodiments, different tenants correspond to different policy sets, and tenant identity is identified based on the prefix of the client identifier, the domain name part of the username, or the tenant identifier key value in the MQTT5.0 attribute field.

[0029] Each policy in the policy set includes at least matching conditions and validation constraints. Matching conditions are used to determine the applicable client range, and validation constraints are used to define the legality conditions that the corresponding parameter fields should meet. The policy sets of different tenants are independent of each other to support differentiated access control in a multi-tenant isolation environment.

[0030] Different tenants have their own independent sets of policies within the system. Each policy rule contains at least two core components: matching conditions and validation constraints. Matching conditions define which clients the rule applies to; for example, a matching condition could be set to prefix the clientId with "tenantA". Validation constraints define the validity requirements that the client's parameter fields must meet; for example, a validation constraint could specify that KeepAlive must be between 30 and 300 seconds.

[0031] Tenant identification methods include: parsing the prefix of the client identifier, parsing the domain name portion of the username (e.g., tenantA.com in device1@tenantA.com), or parsing the tenant identifier key value in the UserProperty field of MQTT 5.0 (e.g., the value corresponding to the key name tenant_id). These three identification mechanisms complement each other and adapt to the identification naming habits of different IoT devices.

[0032] In terms of policy matching logic, when a client connection request arrives, the system first identifies the tenant it belongs to using any of the methods mentioned above, then loads the policy set corresponding to that tenant and performs rule matching. Policy sets for different tenants are isolated from each other and do not affect each other. For example, tenant A can configure its ClientID to be no more than 32 characters long and its MQTT protocol version to be only 5.0, while tenant B can configure its ClientID to be no more than 64 characters long and its KeepAlive time to be no less than 60 seconds. Both tenants can freely define constraint rules according to their own business needs and security levels, and the system's verification engine automatically executes the corresponding verification logic according to the tenant dimension.

[0033] In some embodiments, rule matching supports multi-level priority configuration, allowing for customization of the execution order of different matching methods; when multiple rules match the same parameter field simultaneously, the rule with the highest priority is selected as the basis for judgment.

[0034] Specifically, the system allows administrators to customize the execution order of different matching methods (exact matching, prefix matching, suffix matching, and regular expression matching) during the actual validation process based on their characteristics and business needs. For example, administrators can set exact matching as the highest priority, followed by prefix and suffix matching, and regular expression matching as the lowest priority. Furthermore, when validating the same parameter field (such as ClientID), multiple rules may simultaneously meet the matching conditions—a ClientID might perfectly match a specific rule and also prefix match a general rule. This implementation explicitly stipulates that the rule with the highest priority is selected as the final judgment criterion; if priorities are the same, the rule with the strictest constraints is selected, thereby eliminating the uncertainty of results under multi-rule matching.

[0035] Table 1 illustrates a rule matching method and priority example according to an embodiment of this application. Precise rules are matched first, followed by prefix / suffix rules, and finally regular expression rules. Once a high-priority rule is matched, the validation constraint is directly applied, and low-priority rules are no longer evaluated.

[0036] Table 1

[0037] In actual deployments, policy sets often contain hundreds or even thousands of rules, and overlap or inclusion relationships between rules are inevitable. For example, a general rule defines "all ClientIDs starting with factory_ are allowed KeepAlive for no more than 300 seconds," while a specific rule defines "the specific device factory_01 is allowed KeepAlive for no more than 600 seconds." Without a priority mechanism, the system cannot decide which rule to apply, leading to different verification results for the same connection request at different times. This embodiment enforces the order in which rules take effect through priority configuration, making the verification results completely predictable and reproducible. This fundamentally eliminates the uncertainty caused by rule conflicts and ensures the seriousness and consistency of access control policy execution.

[0038] Multi-level priority configuration empowers administrators to design policies at different granularities. Administrators can first use low-priority, wide-range regular expression rules to cover general security requirements for a class of devices (e.g., all sensor devices must keep-alive for at least 30 seconds), and then use high-priority, narrow-range precise rules to configure exceptions for specific devices (e.g., critical sensor S001 is allowed to keep-alive for 10 seconds). This design pattern avoids the exploding management costs of configuring rules individually for each device while flexibly addressing the needs of special devices, achieving a balance between policy management efficiency and granularity.

[0039] In some embodiments, the client identifier and username naming rule verification includes length range limit verification, character set whitelist verification, and naming rule consistency verification.

[0040] Naming rule consistency verification is used to verify whether the client identifier and username belong to the same tenant or the same device type, preventing cross-tenant identity spoofing attacks; character set whitelist verification only allows letters, numbers and preset special characters to pass, in order to defend against injection attacks.

[0041] The length range limit check is used to ensure that the length of ClientID and Username is within a preset reasonable range, preventing excessively long identifier fields from causing buffer overflows or protocol parsing errors.

[0042] The character set whitelist validation strictly limits the types of characters allowed in the two fields. Only letters, numbers, and preset special characters (such as underscores, hyphens, and periods) are allowed to pass. All characters not in the whitelist (such as single quotes and semicolons commonly used in SQL injection, or combinations of forward slashes and periods required for path traversal) are considered illegal.

[0043] Naming convention consistency checks are used to verify whether the ClientID and Username belong to the same tenant or the same device type. For example, the prefix "tenantA_" of the ClientID must be consistent with the tenant identifier in the domain name part of the Username, "@tenantA.com". If a combination of "tenantA_" and "@tenantB.com" appears, it is considered cross-tenant identity forgery and the connection is rejected.

[0044] In IoT systems, ClientID and Username are often recorded in databases, passed to backend services, or written to log files. If special characters are allowed, attackers could use single quotes, semicolons, etc., to perform SQL injection, or use backslashes, periods, etc., to perform path traversal attacks, or even pollute the log file format with newline characters. By allowing only letters, numbers, and a very small number of preset safe characters, attackers cannot carry any special characters with syntactic meaning in the identifier field, rendering traditional injection attack methods completely ineffective.

[0045] In the absence of verification, an attacker could register tenant A's device but fill in tenant B's username in the connection request, attempting to obtain tenant B's authorization or access tenant B's resources. By enforcing that the ClientID must match the tenant identifier implicit in the Username, any connection request with a mismatched tenant identifier will be rejected before the session is established. This design moves the tenant attribution verification logic down from the business layer to the protocol verification layer, allowing identity forgery to be identified and blocked at the protocol access stage, eliminating the need for secondary verification by the backend business system. This improves security and reduces the protection burden on the business system.

[0046] In some embodiments, the whitelist verification of MQTT 5.0 attribute fields includes authentication method whitelist verification. The authentication method whitelist verification only allows authentication methods belonging to a preset set of strong security authentication methods to pass, in order to defend against authentication downgrade attacks.

[0047] MQTT 5.0 attribute field range validation includes maximum message length limit validation, session expiration time range validation, and key-value pair format and quantity limit validation for user attribute fields.

[0048] If the attribute fields carried in the connection request exceed the preset range or contain authentication methods not on the whitelist, the verification is considered to have failed.

[0049] This embodiment designs a special verification mechanism for the property field introduced in the MQTT 5.0 protocol, which is divided into two dimensions: whitelist verification and range verification.

[0050] The whitelist verification mainly targets the Authentication Method field. The system has a default set that only contains strong security authentication methods, such as only allowing "SCRAM-SHA-256", "SCRAM-SHA-512" or certificate-based authentication methods, while rejecting "PLAIN" plaintext authentication, empty authentication or other weak authentication methods.

[0051] Range validation targets multiple numeric or structured attribute fields. Maximum packet size limit validation ensures that the maximum packet size requested by the client does not exceed the system's configured limit (e.g., 256MB), preventing malicious clients from inducing the broker to allocate excessively large buffers. Session expiration time range validation limits the session expiration time (SessionExpiry Interval) to a reasonable range (e.g., between 60 seconds and 86400 seconds), preventing permanent sessions from exhausting storage resources. User attribute field key-value pair format and quantity limit validation constrains the key name length, key value length, and the total number of User Properties in a single connection, preventing attackers from launching resource exhaustion attacks using massive amounts of user attribute fields.

[0052] When the attribute values ​​carried in the connection request exceed the above preset range or contain authentication methods outside the whitelist, the system determines that the verification fails and refuses the connection before the session is established.

[0053] Authentication downgrade attacks are a common security threat in IoT systems. Attackers attempt to bypass the strong authentication process that the system should be performing by requesting weak authentication methods (such as plaintext password authentication or authentication-free authentication). In an MQTT 5.0 Broker without attribute validation, if the system is configured with strong authentication but does not validate the client's Authentication Method request, an attacker may induce the Broker to use a weak authentication mode by forging the authentication method field in the CONNECT message. This embodiment uses an authentication method whitelist mechanism to force clients to use only preset strong authentication methods; any connection requesting authentication methods outside the whitelist will be directly rejected. This design puts the choice of authentication method in the hands of the server, fundamentally eliminating the possibility of attackers negotiating downgrades to authentication strength.

[0054] MQTT 5.0 attribute fields grant clients greater customization capabilities, but also introduce new attack surfaces. Malicious clients can set an extremely large Maximum Packet Size, inducing the broker to allocate buffers beyond its actual processing capacity, leading to memory exhaustion; they can set an excessively long Session Expiry Interval (e.g., a maximum of 4,294,967,295 seconds, approximately 136 years), causing the broker to retain zombie sessions for extended periods, gradually depleting session storage resources; they can also carry thousands of key-value pairs in the User Property, or use excessively long key names and values, increasing the broker's parsing load and memory consumption. This embodiment sets reasonable security boundaries for each attribute field through range validation. Requests exceeding these boundaries are rejected before the session is established, ensuring the broker does not need to allocate any resources for these abnormal requests, effectively guaranteeing service stability and availability.

[0055] Step S103: When any verification result does not meet the conditions preset by the corresponding policy, a corresponding rejection reason code and a hit policy identifier are generated, and the connection request is rejected before the MQTT session is officially established; when all verification results meet the policy requirements, the establishment of the MQTT session is allowed.

[0056] In some embodiments, the rejection reason code is used to identify the specific reason for the connection being rejected, including invalid protocol version, mismatched identity field, out-of-bounds parameter, or illegal attribute. The hit strategy identifier is used to record the specific strategy rule number that triggers the abandonment decision, supporting subsequent audit tracking and strategy optimization.

[0057] When all parameter fields pass the validation, the MQTT session is allowed to be established normally, and the Broker continues to execute the subsequent authentication process and session creation process; when any validation result does not meet the policy conditions, the connection request is rejected before the MQTT session is officially established, and two key pieces of information are generated: the rejection reason code and the policy hit identifier.

[0058] The rejection reason code is a predefined enumeration value used to identify the specific reason why the connection was rejected. An invalid protocol version indicates that the client's requested MQTT version is not in the whitelist; a mismatched identity field indicates that the ClientID and the tenant identifier parsed from the Username are inconsistent; an out-of-bounds parameter indicates that KeepAlive or Session Expiry Interval exceeds the allowed range; and an invalid attribute indicates that the authentication method is not in the whitelist or the User Property format is invalid. A hit policy identifier records the specific policy rule number that triggered the rejection judgment, facilitating precise identification of which rule caused the rejection.

[0059] In this embodiment, the rejection operation occurs before the MQTT session is formally established. This means that all connection requests that fail verification will not trigger the subsequent resource allocation process. In scenarios with massive IoT device access, if a large number of malicious or misconfigured connection requests are rejected only after the session is established, the Broker will continuously bear the overhead of invalid resource allocation and release. By rejecting in advance, the processing cost of each invalid connection is minimized (only the CONNECT message needs to be parsed and policy matching needs to be performed), significantly improving the Broker's processing capacity and resource utilization efficiency in high-concurrency access scenarios.

[0060] Operations personnel can quickly understand the macro-level distribution of large-scale connection rejections by using the reason codes. For example, if the proportion of invalid authentication methods is too high, it may indicate an attack attempt or that the device firmware version is too old and needs to be upgraded; if the proportion of out-of-bounds parameters is too high, it may be necessary to adjust the policy thresholds to adapt to real business scenarios. The policy hit flag further provides precise micro-level positioning capabilities, allowing operations personnel to directly locate the specific policy rule that triggered the rejection and determine whether the rule is set too strictly or whether the client has indeed violated the rules.

[0061] In some embodiments, the method further includes: Record each policy matching result and connection handling result, and generate statistical indicators. The statistical indicators should include at least the number of policy hits, the number of connection rejections, the distribution of different rejection reason codes, and the access success rate aggregated by tenant dimension.

[0062] When the rejection rate of any policy is detected to be abnormally high within a preset time range, an alarm mechanism is triggered to prompt the administrator to review the policy configuration.

[0063] Record each policy matching result and connection handling result (allow or deny), and generate multi-dimensional statistical indicators based on this raw data. These indicators include at least: the number of times each policy rule is hit (reflecting which rules are frequently triggered), the total number of connection denials and their distribution by reason code (reflecting whether the main reasons for denial are parameter out-of-bounds, identity mismatch, or attribute illegality), and the access success rate aggregated by tenant dimension (reflecting the healthy access status of each tenant's device).

[0064] Based on this, a dynamic monitoring logic is also set up: when the rejection rate of a certain policy is detected to rise abnormally within a preset time range (for example, the rejection rate of a certain rule suddenly rises from 5% to 80% within 5 minutes), an alarm mechanism is automatically triggered to notify the administrator to review whether the configuration of the policy is reasonable.

[0065] It should be noted that the policy set supports online updates, including adding, modifying, and deleting policies. Updates take effect without interrupting the MQTT service. Online updates include policy version management and a rollback mechanism. A new version number is automatically generated each time a policy is updated, while historical version configurations are retained. If a new policy is detected to cause an abnormally high false rejection rate, a one-click rollback to the previous stable version is supported to ensure service continuity and availability.

[0066] By implementing the above steps, the verification process is advanced to before the formal establishment of the MQTT session. Abnormal connections can be blocked even before session resources are allocated, effectively preventing resource exhaustion attacks. Simultaneously, protocol semantic-level parsing of the CONNECT message verifies the consistency of the client identifier and username naming rules to prevent cross-tenant spoofing. Furthermore, whitelist verification is performed on MQTT 5.0 attribute fields to defend against application-layer attacks such as authentication downgrades and attribute injection.

[0067] Through pre-verification, all connection requests that fail verification will not trigger resource-intensive operations such as session object creation and authentication processing. In scenarios with massive IoT device access, this can significantly reduce the CPU, memory, and connection slot usage caused by invalid connections. Meanwhile, the tenant-based policy set achieves isolation of multi-tenant access control, avoiding naming conflicts and cross-tenant resource contention, thus improving the access security of the MQTT protocol.

[0068] Each time a verification fails, the system generates a rejection reason code and a hit policy identifier. Combined with statistical indicators such as the number of policy hits, the distribution of rejection reasons, the access success rate aggregated by tenant, and the proactive alarm mechanism when the rejection rate rises abnormally, operations and maintenance personnel can quickly locate the root cause of the problem and guide policy optimization. This achieves an upgrade from passive investigation to proactive discovery in the operation and maintenance mode, significantly improving the observability and maintainability of the system.

[0069] It should be noted that the steps shown in the above process or in the flowchart of the accompanying figures can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0070] This embodiment also provides an MQTT protocol-aware access verification system, which is used to implement the above embodiments and preferred embodiments. Details already described will not be repeated. As used below, the terms "module," "unit," "subunit," etc., can refer to a combination of software and / or hardware that performs a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0071] Figure 2This is a structural block diagram of an MQTT protocol-aware access verification system according to an embodiment of this application, such as... Figure 2 As shown, the system includes: The parsing module 21 is used to receive connection requests initiated by the client and parse the CONNECT message in the connection request to obtain multiple parameter fields, including protocol version information, client identifier, username, keep-alive time and MQTT5.0 attribute fields.

[0072] The verification module 22 is used to perform rule matching and parameter consistency verification on parameter fields based on a preset set of policies organized by the tenant dimension. The rule matching supports at least one or more of the following matching methods: exact matching, prefix matching, suffix matching, and regular expression matching.

[0073] Parameter consistency verification includes protocol version validity verification, client identifier and username naming rule verification, keep-alive time range verification, and MQTT 5.0 attribute field range verification or whitelist verification.

[0074] The execution module 23 is used to generate a corresponding rejection reason code and a hit policy identifier when any verification result does not meet the preset conditions of the corresponding policy, and to reject the connection request before the MQTT session is officially established; when all verification results meet the policy requirements, the establishment of the MQTT session is allowed.

[0075] In some embodiments, different tenants correspond to different policy sets, and tenant identity is identified based on the prefix of the client identifier, the domain name part of the username, or the tenant identifier key value in the MQTT5.0 attribute field.

[0076] Each policy in the policy set includes at least matching conditions and validation constraints. Matching conditions are used to determine the applicable client range, and validation constraints are used to define the legality conditions that the corresponding parameter fields should meet. The policy sets of different tenants are independent of each other to support differentiated access control in a multi-tenant isolation environment.

[0077] In some embodiments, rule matching supports multi-level priority configuration, allowing for customization of the execution order of different matching methods; when multiple rules match the same parameter field simultaneously, the rule with the highest priority is selected as the basis for judgment.

[0078] In some embodiments, the rejection reason code is used to identify the specific reason why the connection is rejected, including invalid protocol version, mismatched identity field, out-of-bounds parameter, or illegal attribute.

[0079] The hit strategy identifier is used to record the specific strategy rule number that triggers the abandonment decision, supporting subsequent audit tracking and strategy optimization.

[0080] In some embodiments, the client identifier and username naming rule verification includes length range limit verification, character set whitelist verification, and naming rule consistency verification.

[0081] Naming rule consistency verification is used to verify whether the client identifier and username belong to the same tenant or the same device type, preventing cross-tenant identity spoofing attacks; character set whitelist verification only allows letters, numbers and preset special characters to pass, in order to defend against injection attacks.

[0082] In some embodiments, the whitelist verification of MQTT 5.0 attribute fields includes authentication method whitelist verification. The authentication method whitelist verification only allows authentication methods belonging to a preset set of strong security authentication methods to pass, in order to defend against authentication downgrade attacks.

[0083] MQTT 5.0 attribute field range validation includes maximum message length limit validation, session expiration time range validation, and key-value pair format and quantity limit validation for user attribute fields.

[0084] If the attribute fields carried in the connection request exceed the preset range or contain authentication methods not on the whitelist, the verification is considered to have failed.

[0085] In some embodiments, the system further includes an analysis module for recording each policy matching result and connection handling result, and generating statistical indicators, which include at least the number of policy hits, the number of connection rejections, the distribution of different rejection reason codes, and the access success rate aggregated by tenant dimension.

[0086] When the rejection rate of any policy is detected to be abnormally high within a preset time range, an alarm mechanism is triggered to prompt the administrator to review the policy configuration.

[0087] By advancing the verification process to before the formal establishment of the MQTT session, abnormal connections can be blocked even before session resources are allocated, effectively preventing resource exhaustion attacks. Simultaneously, protocol semantic-level parsing of CONNECT messages verifies the consistency of client identifier and username naming rules to prevent cross-tenant spoofing, and performs whitelist verification on MQTT 5.0 attribute fields to defend against application-layer attacks such as authentication downgrades and attribute injection.

[0088] Through pre-verification, all connection requests that fail verification will not trigger resource-intensive operations such as session object creation and authentication processing. In scenarios with massive IoT device access, this can significantly reduce the CPU, memory, and connection slot usage caused by invalid connections. Meanwhile, the tenant-based policy set achieves isolation of multi-tenant access control, avoiding naming conflicts and cross-tenant resource contention, thus improving the access security of the MQTT protocol.

[0089] It should be noted that the above modules can be functional modules or program modules, and can be implemented through software or hardware. For modules implemented through hardware, the above modules can reside in the same processor; or the above modules can be located in different processors in any combination.

[0090] This embodiment also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0091] Optionally, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0092] Optionally, in this embodiment, the processor can be configured to perform the following steps via a computer program: S1 receives the connection request initiated by the client and parses the CONNECT message in the connection request to obtain multiple parameter fields, including protocol version information, client identifier, username, keep-alive time and MQTT5.0 attribute fields.

[0093] S2, based on a pre-defined set of policies organized by tenant dimension, performs rule matching and parameter consistency verification on parameter fields. The rule matching supports at least one or more of the following matching methods: exact matching, prefix matching, suffix matching, and regular expression matching. The parameter consistency verification includes verification of protocol version validity, client identifier and username naming rules, keep-alive time range verification, and MQTT 5.0 attribute field range verification or whitelist verification.

[0094] S3: When any verification result does not meet the conditions preset by the corresponding policy, a corresponding rejection reason code and policy hit identifier are generated, and the connection request is rejected before the MQTT session is officially established; when all verification results meet the policy requirements, the establishment of the MQTT session is allowed.

[0095] It should be noted that the specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementations, and will not be repeated here.

[0096] In one embodiment, Figure 3 This is a schematic diagram of the internal structure of an electronic device according to an embodiment of this application, such as... Figure 3 As shown, an electronic device is provided, which can be a server, and its internal structure diagram can be as follows. Figure 3As shown, this electronic device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database stores data. The network interface communicates with external terminals via a network connection. When executed by the processor, the computer program implements an MQTT protocol-aware access verification method.

[0097] Those skilled in the art will understand that Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the electronic device to which the present application is applied. The specific electronic device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0098] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0099] Those skilled in the art should understand that the technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments have been described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0100] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. An MQTT protocol-aware access verification method, characterized in that, The method includes: The system receives a connection request initiated by the client and parses the CONNECT message in the connection request to obtain multiple parameter fields, including protocol version information, client identifier, username, keep-alive time and MQTT 5.0 attribute fields. Based on a preset set of strategies organized by tenant dimension, rule matching and parameter consistency verification are performed on the parameter fields. The rule matching supports at least one or more of the following matching methods: exact matching, prefix matching, suffix matching, and regular expression matching. The parameter consistency verification includes protocol version validity verification, client identifier and username naming rule verification, keep-alive time range verification, and MQTT 5.0 attribute field range verification or whitelist verification. Specifically, the client identifier and username naming rule verification includes length range limit verification, character set whitelist verification, and naming rule consistency verification. The naming rule consistency verification verifies whether the client identifier and username belong to the same tenant or the same device type, preventing cross-tenant identity spoofing attacks. The character set whitelist verification only allows letters, numbers, and preset special characters to pass, defending against injection attacks. If any verification result does not meet the conditions preset by the corresponding policy, a corresponding rejection reason code and policy hit identifier are generated, and the connection request is rejected before the MQTT session is officially established; if all verification results meet the policy requirements, the establishment of the MQTT session is allowed.

2. The method according to claim 1, characterized in that, Different tenants correspond to different policy sets. Tenant identity is identified based on the prefix of the client identifier, the domain name part of the username, or the tenant identifier key value in the MQTT5.0 attribute field. Each policy in the policy set includes at least a matching condition and a validation constraint. The matching condition is used to determine the applicable client range, and the validation constraint is used to define the legality conditions that the corresponding parameter fields should meet. The policy sets of different tenants are independent of each other to support differentiated access control in a multi-tenant isolation environment.

3. The method according to claim 1, characterized in that, The rule matching supports multi-level priority configuration, allowing for customization of the execution order of different matching methods; When multiple rules match the same parameter field, the rule with the highest priority is selected as the basis for judgment.

4. The method according to claim 1, characterized in that, The rejection reason code is used to identify the specific reason for the connection being rejected. The specific reason includes invalid protocol version, mismatched identity field, out-of-bounds parameter or illegal attribute. The hit strategy identifier is used to record the specific strategy rule number that triggers the abandonment decision, supporting subsequent audit tracking and strategy optimization.

5. The method according to claim 1, characterized in that, The whitelist verification of the MQTT 5.0 attribute fields includes authentication method whitelist verification. The authentication method whitelist verification only allows authentication methods belonging to the preset strong security authentication method set to pass, in order to defend against authentication downgrade attacks. The range validation of the MQTT 5.0 attribute fields includes maximum message length limit validation, session expiration time range validation, and key-value pair format and quantity limit validation of user attribute fields; If the attribute fields carried in the connection request exceed the preset range or contain authentication methods not on the whitelist, the verification is considered to have failed.

6. The method according to claim 1, characterized in that, The method further includes: Record each policy matching result and connection handling result, and generate statistical indicators. These statistical indicators should include at least the number of policy hits, the number of connection rejections, the distribution of different rejection reason codes, and the access success rate aggregated by tenant dimension; and / or When the rejection rate of any policy is detected to be abnormally high within a preset time range, an alarm mechanism is triggered to prompt the administrator to review the policy configuration.

7. An MQTT protocol-aware access verification system, characterized in that, The system includes: The parsing module is used to receive connection requests initiated by clients and parse the CONNECT message in the connection request to obtain multiple parameter fields, including protocol version information, client identifier, username, keep-alive time and MQTT5.0 attribute fields. The verification module is used to perform rule matching and parameter consistency verification on the parameter fields based on a preset set of policies organized by the tenant dimension. The rule matching supports at least one or more of the following matching methods: exact matching, prefix matching, suffix matching, and regular expression matching. The parameter consistency verification includes protocol version validity verification, client identifier and username naming rule verification, keep-alive time range verification, and MQTT 5.0 attribute field range verification or whitelist verification. Specifically, the client identifier and username naming rule verification includes length range limit verification, character set whitelist verification, and naming rule consistency verification. The naming rule consistency verification verifies whether the client identifier and username belong to the same tenant or the same device type, preventing cross-tenant identity spoofing attacks. The character set whitelist verification only allows letters, numbers, and preset special characters to pass, defending against injection attacks. The execution module is used to generate a corresponding rejection reason code and a hit policy identifier when any verification result does not meet the preset conditions of the corresponding policy, and to reject the connection request before the MQTT session is officially established; when all verification results meet the policy requirements, the establishment of the MQTT session is allowed.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the MQTT protocol-aware access verification method as described in any one of claims 1 to 6.

9. A storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the MQTT protocol-aware access verification method as described in any one of claims 1 to 6.

Images