Automatic account discovery and security check system based on MySQL data transmission protocol

Abstract

The application relates to the technical field of network security, and discloses an automatic account discovery and security checking system based on a MySQL data transmission protocol, which comprises a database protocol connection and task scheduling module, an account automatic discovery module, an account analysis and whitelist account filtering module and an unmanaged account weak password detection module.

Description

Technical Field

[0001] This application relates to the field of network security technology, and in particular to an automated account discovery and security check system based on the MySQL data transmission protocol. Background Technology

[0002] With the continuous development of enterprise business systems, operation and maintenance platforms, and data analysis platforms, MySQL databases are widely deployed in production, testing, and development environments. Database accounts typically carry permissions for business access, operation and maintenance management, data synchronization, and audit queries, making them a key object in data asset security protection. In actual operation and maintenance scenarios, database accounts are numerous and come from diverse sources, including accounts included in a unified permission management platform, as well as legacy accounts, temporary accounts, and third-party system accounts.

[0003] Traditional database account verification relies on administrators manually connecting to the database and executing queries, which is inefficient, prone to omissions, and difficult to adapt to large-scale asset inspections. Furthermore, account discovery and account security checks are often disconnected, failing to automatically initiate risk analysis processes such as weak passwords and unmanaged accounts after discovering database roles or users. There is a lack of controlled mechanisms for password collision detection of unmanaged accounts, leading to uncontrollable inspection times, disordered password book usage, and inability to refill result status. Insufficient engineering capabilities, such as multi-credential attempts, connection failure retry, timeout termination, and structured result output, make it difficult to reliably integrate security inspection tasks into asset management platforms or PAM platforms. Moreover, the lack of a unified data model for inspection results makes it difficult to centrally display and subsequently handle database version, account name, weak password hit rate, and task execution status. Therefore, the fundamental problem this invention aims to solve is how to achieve agentless deployment to automatically obtain database version and account lists, and link account discovery results with the account security inspection process to achieve control over unmanaged accounts. Summary of the Invention

[0004] To achieve automatic acquisition of database version and account list in agentless deployment, and to link account discovery results with the account security check process to control unmanaged accounts, this application provides an automatic account discovery and security check system based on the MySQL data transmission protocol, adopting the following technical solution: An automated account discovery and security check system based on the MySQL data transmission protocol includes: The database protocol connection and task scheduling module is used to receive input parameters from the target database, construct database connection parameters, and establish a remote connection through the database client driver. The account auto-discovery module is used to obtain database asset version information and account list after a successful connection, and encapsulate the accounts as structured objects and store them. The account analysis and whitelist account filtering module is used to determine whether to enter the account security analysis process and to determine the scope of analysis, remove whitelist accounts and add manually specified but undiscovered accounts. The weak password detection module for unmanaged accounts is used to filter accounts that are not included in PAM management, load the password book, and retrieve passwords according to the set policies and collision limit. The concurrent collision and database probing execution module is used to perform sharding and concurrent processing of the accounts to be detected according to the configured number of worker threads; it uses the database client driver to attempt to establish a connection and records the hit information when the connection is successful; The runtime monitoring and timeout status backfilling module is used to monitor the task execution time, send a signal to stop the worker thread when a timeout occurs, and backfill the detection status of each account. The inspection results data model is used to maintain structured result objects centered on accounts and serialize them into a unified format for output after the task is completed.

[0005] Optionally, the input parameters include address, port, database name, account, password, task number, script timeout, and account discovery and account analysis switches; The system supports trying multiple sets of candidate credentials sequentially. When the main account password exists, it is added to the list of credentials to be tried. When a connection fails with a set of credentials, the exception is recorded and the next set of credentials is tried. When a script timeout exception occurs, it is immediately thrown upwards to ensure that the task status is consistent.

[0006] Optionally, the execution process of the automatic account discovery module includes: Each account is encapsulated as an object containing at least assetAccount and assetVersion fields, and written to a mapping table with the account name as the key; when the account discovery switch is turned on, the discovery list is automatically used as the object for subsequent analysis.

[0007] Optionally, the account analysis and whitelist account filtering module controls the analysis process according to the analysisEnable switch, reads the analysisAccountList, whiteList, and pamAccountList parameters to determine the range, and removes whitelist accounts from the list to be analyzed before analysis.

[0008] Optionally, the weak password detection module for unmanaged accounts performs filtering when noInAccountUnlockEnable is enabled; The password book is loaded by task number. If the password book does not exist locally, it is requested from the password book service and cached to obtain the password list. The password list is processed uniformly by passwd_handler, and the retrieval is controlled according to niaPasswordRetrievalType, and the number of collisions for each account is limited according to niaCollisions.

[0009] Optionally, the concurrent collision and database detection execution module sets the number of worker threads according to accountAnalysisRate and uses ThreadPoolExecutor for sharding. For tasks that do not explicitly pass a database name, determine whether the database name is provided as an input parameter: If provided, use the database name; If not provided, the local database list file will be read.

[0010] Optionally, the sharded concurrent processing uses a dynamic load-aware scheduling method instead of static sharding by ThreadPoolExecutor, specifically including: The list of accounts to be tested is written into a globally shared dynamic task queue and initially sorted. The main thread allocates an initial batch size to each worker thread. Collect real-time performance metrics, including average single-account detection time, the number of incomplete accounts currently held by the thread, and the timeout failure rate; Calculate the dynamic weight factor for each thread based on real-time performance metrics; When the number of incomplete accounts currently held by a thread exceeds a preset threshold, the main scheduler dynamically adjusts the allocation quantity based on the thread's dynamic weight factor. The main scheduler periodically evaluates the expected completion time of each thread and determines whether the thread is marked based on the expected completion time and the number of incomplete accounts currently held. The main scheduler marks some of the incomplete tasks of the marked thread as stealable, and the idle thread that has completed its own task applies to the main scheduler to steal the tasks in the stealable state. After stealing, the global task status table is updated synchronously. When the average timeout failure rate of the global statistics exceeds the preset threshold, the main scheduler automatically triggers the off-peak frequency reduction mode.

[0011] Optionally, the runtime monitoring and timeout status backfilling module starts an independent monitoring thread when the task begins, calculates the timeout threshold according to scriptTimeout, and sends the timeout signal to the worker thread through a queue; Before scanning for unmanaged accounts, the timedOutMessage of all unmanaged accounts to be detected is preset, and then updated after the detection is completed.

[0012] Optionally, the fields maintained by the inspection result data model include assetAccount, assetVersion, isWeakPass, password, baselineItem2002, and timedOutMessage; When a weak password is detected, mark isWeakPass as "yes", record the password, and set baselineItem2002 to False; After the task is completed, the list of account security check results, the list of user information, and the list of logged-in users will be serialized into JSON and concatenated using a fixed delimiter and returned.

[0013] In summary, this application includes at least one of the following beneficial technical effects: This invention remotely completes connection, account discovery, and security checks based on database data transmission protocols, without requiring additional components to be installed on the target database server. It automatically retrieves a database account list using system account / role query statements, and generates asset account profiles by including database version information. It can compare discovered accounts with the PAM-managed account list, automatically filtering unmanaged accounts for priority security checks. It supports password book services, local caching, random or sequential access, collision limit, and concurrent thread control, balancing check efficiency with target service stability. It achieves task timeout termination through independent monitoring of threads and queue signals, while retaining the status of discovered and detected accounts, reducing the risk of long-running tasks going out of control. It outputs account discovery, security check, and weak password detection results in JSON format, facilitating integration with asset management platforms, PAM platforms, and risk management platforms. Attached Figure Description

[0014] Figure 1 This is a logical diagram of an automatic account discovery and security check system based on the MySQL data transmission protocol.

[0015] Figure 2 This is the overall architecture diagram of an automatic account discovery and security check system based on the MySQL data transmission protocol. Detailed Implementation

[0016] The embodiments of this application are described in detail below, and examples of the embodiments are shown in the accompanying drawings.

[0017] In the description of this specification, the references to "certain embodiments," "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples" refer to specific features, structures, materials, or characteristics described in connection with the described embodiment or example, which are included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0018] Please see Figure 1 The present application discloses an automatic account discovery and security check system based on the MySQL data transmission protocol. The system includes a database protocol connection and task scheduling module, an automatic account discovery module, an account analysis and whitelist account filtering module, an unmanaged account weak password detection module, a concurrent collision and database detection execution module, a runtime monitoring and timeout status backfilling module, and a check result data model.

[0019] The table below is a comparison table of the meanings and explanations of the terms used in this embodiment.

[0020] Please see Figure 2 This is an overall architecture diagram of an automatic account discovery and security check system based on the MySQL data transmission protocol. It shows the calling relationships between the database protocol connection module, the automatic account discovery module, the unmanaged account filtering module, the password book processing module, the concurrent weak password detection module, the runtime monitoring module, and the result output module.

[0021] The database protocol connection and task scheduling module receives input parameters such as target database address, port, database name, account, password, task number, script timeout, and account discovery and analysis switches. It constructs database connection parameters and establishes a remote connection through the database client driver. The system supports multiple sets of candidate credentials to be tried sequentially in the do_task scheduling entry: when the input main account password exists, it is added to the list of credentials to be tried; when a set of credentials fails to connect, the exception is recorded and the next set of credentials is tried; when a script timeout exception occurs, it is immediately thrown upwards to ensure that the task status is consistent.

[0022] The account auto-discovery module retrieves database asset version information and an account list after a successful connection, encapsulating accounts into structured objects and storing them. After a successful system connection, it executes version query statements to obtain database asset version information and system account / role query statements to retrieve the account list from the target database. The account discovery module encapsulates each account into a structured object, containing at least `assetAccount` and `assetVersion` fields, and writes it to the account discovery mapping table using the account name as the key. If the account discovery function is enabled, the system automatically uses the discovered account list as the object for subsequent account analysis, achieving an automated workflow from asset connection and account enumeration to security checks.

[0023] The account analysis and whitelist filtering module is used to determine whether to enter the account security analysis process and to define the analysis scope. The system controls whether to enter the account security analysis process based on `analysisEnable`, and reads parameters such as `analysisAccountList`, `whiteList`, and `pamAccountList` to determine the analysis scope. For objects configured as whitelisted accounts, the system removes them from the list of accounts to be analyzed before analysis to avoid unnecessary weak password collisions with core operation and maintenance accounts, built-in accounts, or business whitelisted accounts. For accounts that are passed in but do not appear in the discovery results, the system will create supplementary account result objects to ensure that manually specified accounts can also enter the unified result model.

[0024] The weak password detection module for unmanaged accounts is used to filter accounts not included in PAM management. When noInAccountUnlockEnable is enabled, the system filters accounts not included in PAM management from the account discovery results as weak password detection targets. The system loads a default password book or a task-specific password book by task number; if a task-specific password book does not exist locally, it can request it from the password book service and write it to the local cache. Password books are uniformly processed by passwd_handler before entering the detection process: it supports random or sequential retrieval based on niaPasswordRetrievalType and limits the number of password collisions for each account based on niaCollisions to avoid putting excessive pressure on the target service during security checks.

[0025] The concurrent collision and database detection execution module is used to perform sharded concurrent processing of the accounts to be detected based on the configured number of worker threads.

[0026] In one embodiment, the system sets the number of weak password detection worker threads based on `accountAnalysisRate` and uses `concurrent.futures.ThreadPoolExecutor` to shard and process the accounts to be detected concurrently. Each thread iterates through combinations of username, password, and database name, and attempts to establish a connection using a database client driver; once a connection is successful, it records the target IP, username, password, and database name, among other hit information. For tasks that do not explicitly provide a database list, the system prioritizes using the database names provided in the input parameters; if not provided, it reads the local database list file to ensure the detection range is configurable.

[0027] In another embodiment, the system sets the number of weak password detection worker threads based on accountAnalysisRate and uses a dynamic load-aware scheduling method to perform sharded concurrent processing of the accounts to be detected, specifically including: The list of accounts to be tested is written into a globally shared dynamic task queue and initially sorted. The main thread allocates an initial batch size to N worker threads. Each worker thread collects real-time performance metrics during execution. These metrics include the average detection time per account, the number of incomplete accounts currently held by the thread, and the timeout failure rate. The average detection time per account is obtained by averaging the data from the last 5 accounts, and the timeout failure rate is obtained by averaging the timeout failure rates from the last 10 connections.

[0028] After receiving performance feedback from each thread, the main scheduler calculates the dynamic weight factor for each thread based on real-time performance metrics, expressed as: ,in, The average detection time per account, Let F be the global average detection time, and F be the timeout failure rate. The penalty coefficient is set to 0.4 in this embodiment. When the number of incomplete accounts currently held by a thread exceeds a preset threshold, the main scheduler dynamically adjusts the allocation quantity based on the thread's dynamic weight factor. In this embodiment, the preset threshold is set to 2. When the number of incomplete accounts exceeds 2, the main scheduler adjusts the allocation quantity based on the thread's dynamic weight factor. Assign the next batch of accounts to this thread, with the following number: , This represents the number of unfinished accounts in the current thread. This is the maximum limit for a single batch, and it is set based on empirical data.

[0029] The main scheduler periodically evaluates the expected completion time of each thread. , This represents the current elapsed time; the expected completion time for a given thread. It exceeds 1.5 times the shortest expected completion time globally, and If the thread fails to complete its task, the main scheduler will actively suspend the subsequent task retrieval of the thread and mark the end of its queue. The main scheduler will mark the unfinished tasks of the marked thread as stealable, and the idle threads that have completed their own tasks will apply to the main scheduler to steal the stealable tasks. The number of tasks stolen each time is min (30% of the remaining tasks of the marked thread and 1.2 times the historical average processing volume of the idle thread). The global task status table will be updated synchronously after the stealing to avoid duplicate execution. When the global average timeout failure rate exceeds the preset threshold, in this embodiment the preset threshold is set to 25%. The main scheduler automatically triggers the peak-shifting and frequency reduction mode. The peak-shifting and frequency reduction mode is as follows: the number of single batch allocations B_next for all worker threads is reduced to 60% of the original value, and a random micro-delay of 10ms to 50ms is inserted between two adjacent batch pulls to alleviate the instantaneous connection pressure on the target database server. At the same time, the account with the highest timeout failure rate is stored separately in the delayed retry queue. After the global average detection time drops back to the normal level, the first idle thread will re-execute the collision according to the original password book to ensure that the high-latency account can still be completely covered.

[0030] Compared to the static uniform sharding strategy, the dynamic load-aware scheduling method in this embodiment can effectively reduce the overhead of lock contention and task theft between threads; at the same time, through the compensation allocation mechanism of remainder R, it ensures the balance of processing time of each thread in the scenario of massive accounts, avoids the overall scanning delay caused by the overload of a single thread, and provides fine-grained task execution boundaries for the precise interruption of the subsequent timeout monitoring module.

[0031] The runtime monitoring and timeout status feedback module starts an independent monitoring thread at the beginning of the task, calculates the timeout threshold based on scriptTimeout, and if a weak password scan times out, the monitoring thread sends a timeout signal to the worker thread through a queue; upon detecting the timeout signal, the worker thread terminates execution and returns a timeout status. Before entering the scan of unmanaged accounts, the system pre-sets the timedOutMessage of the relevant accounts to "Scan for unmanaged accounts timed out, task terminated", and updates it to "success" after the account detection is completed, so that the detection progress of each account can still be reflected when the timeout is returned.

[0032] The inspection result data model maintains a structured result object with fields including assetAccount, assetVersion, isWeakPass, password, baselineItem2002, and timedOutMessage. When a weak password is detected, isWeakPass is marked as "yes", the password is recorded, and baselineItem2002 is set to False. After the task is completed, the list of account security inspection results, the list of user information, and the list of logged-in users are serialized into JSON and concatenated using a fixed delimiter for easy parsing by the upstream platform.

[0033] The system in this embodiment remotely completes connection, account discovery, and security checks based on a database data transmission protocol, without requiring the installation of additional components on the target database server. It automatically retrieves a database account list using system account / role query statements, and generates asset account profiles by including database version information. It can compare discovered accounts with the PAM-managed account list, automatically filtering unmanaged accounts for priority security checks. It supports password book services, local caching, random or sequential access, collision limit, and concurrent thread control, balancing check efficiency with target service stability. It achieves task timeout termination through independent monitoring of threads and queue signals, while retaining the status of discovered and detected accounts, reducing the risk of long-running tasks going out of control. It outputs account discovery, security check, and weak password detection results in JSON format, facilitating integration with asset management platforms, PAM platforms, and risk management platforms.

[0034] Taking the automatic account discovery and security check of a MySQL database service with IP address 10.10.10.58 and port 3306 as an example, the specific implementation method of this system is explained: S1: The system receives input parameters, including target address (location), port (port), database name (database), login account (user), login password (pwd), task number (taskId), script timeout (scriptTimeout), account discovery switch (discoverEnable), account analysis switch (analysisEnable), list of accounts to be analyzed (analysisAccountList), whitelist of accounts (whiteList), list of PAM managed accounts (pamAccountList), and candidate credentials (crackUserDatalist).

[0035] S2: The do_task scheduling entry point adds the incoming main account password to the candidate credential list and attempts to connect to the target database in sequence. If the current credential authentication fails, the exception is logged and the next set of credentials is tried; if a script timeout exception occurs, the task is terminated and returned to the upper layer for processing.

[0036] S3: The main task process creates a runtime monitoring thread, monitor_runtime. The monitoring thread periodically calculates the task runtime based on scriptTimeout and sends a stop signal to the weak password detection thread through a queue.

[0037] S4: After establishing a database connection, the system executes the version() query to obtain asset version information; when discoverEnable is enabled, it executes a system account / role query statement to obtain an account list and writes the account name and database version to account_discover_map.

[0038] S5: The system will use the list of discovered accounts as the analysis object and remove whitelisted accounts that do not participate in the analysis based on whiteList; for the specified analysis account passed in, if it does not exist in the results, the corresponding account result object will be created to ensure complete output.

[0039] S6: When noInAccountUnlockEnable is enabled, the system will compare the accounts found with the PAM managed account list to obtain the set of unmanaged accounts; then it will call getPasswd to read the default password book or the task-specific password book, and use passwd_handler to perform disorder, order and truncation processing according to niaPasswordRetrievalType and niaCollisions.

[0040] S7: The system selects the number of weak password detection threads based on accountAnalysisRate, divides unmanaged accounts into multiple shards, and concurrently executes connection verification using a dynamic load-aware scheduling method. Each thread iterates through combinations of username, password, and database name, attempting to establish a database protocol connection; upon successful connection, it records the IP address, username, password, and database name.

[0041] S8: If the monitoring thread finds that the running time exceeds the threshold, it writes a timeout signal to the queue; after the weak password detection thread reads the signal, it stops execution, the main process captures the timeout status of "scanning unmanaged accounts", and returns the check results of the currently existing accounts.

[0042] S9: After the weak password detection is completed, the system parses the hit results, marks the corresponding account's isWeakPass as "yes", records the hit password, and sets baselineItem2002 to False; for accounts that did not hit or have completed the detection, the timedOutMessage is updated to "success".

[0043] S10: The system serializes the account discovery and security check result list, user information list, and login user list into JSON, concatenates them using a fixed delimiter, and returns them to the caller, so that the upstream system can complete the closed loop of display, alarm, and handling.

[0044] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. An automatic account discovery and security check system based on the MySQL data transmission protocol, characterized in that, include: The database protocol connection and task scheduling module is used to receive input parameters from the target database, construct database connection parameters, and establish a remote connection through the database client driver. The account auto-discovery module is used to obtain database asset version information and account list after a successful connection, and encapsulate the accounts as structured objects and store them. The account analysis and whitelist account filtering module is used to determine whether to enter the account security analysis process and to determine the scope of analysis, remove whitelist accounts and add manually specified but undiscovered accounts. The weak password detection module for unmanaged accounts is used to filter accounts that are not included in PAM management, load the password book, and retrieve passwords according to the set policies and collision limit. The concurrent collision and database detection execution module is used to perform sharding and concurrent processing of the accounts to be detected based on the configured number of worker threads; Use the database client driver to attempt to establish a connection, and record the hit information when the connection is successful; The runtime monitoring and timeout status backfilling module is used to monitor the task execution time, send a signal to stop the worker thread when a timeout occurs, and backfill the detection status of each account. The inspection results data model is used to maintain structured result objects centered on accounts and serialize them into a unified format for output after the task is completed.

2. The automatic account discovery and security check system based on the MySQL data transmission protocol according to claim 1, characterized in that, The input parameters include address, port, database name, account, password, task number, script timeout, and account discovery and account analysis switches; The system supports trying multiple sets of candidate credentials sequentially. When the main account password exists, it is added to the list of credentials to be tried. When a connection fails with a set of credentials, the exception is recorded and the next set of credentials is tried. When a script timeout exception occurs, it is immediately thrown upwards to ensure that the task status is consistent.

3. The automatic account discovery and security check system based on the MySQL data transmission protocol according to claim 2, characterized in that, The execution process of the account auto-discovery module includes: Each account is encapsulated as an object containing at least assetAccount and assetVersion fields, and written to a mapping table with the account name as the key; when the account discovery switch is turned on, the discovery list is automatically used as the object for subsequent analysis.

4. The automatic account discovery and security check system based on the MySQL data transmission protocol according to claim 1, characterized in that, The account analysis and whitelist account filtering module controls the analysis process based on the analysisEnable switch, reads the analysisAccountList, whiteList, and pamAccountList parameters to determine the range, and removes whitelist accounts from the list to be analyzed before analysis.

5. The automatic account discovery and security check system based on the MySQL data transmission protocol according to claim 1, characterized in that, The weak password detection module for unmanaged accounts performs filtering when noInAccountUnlockEnable is enabled. The password book is loaded by task number. If the password book does not exist locally, it is requested from the password book service and cached to obtain the password list. The password list is processed uniformly by passwd_handler, and the retrieval is controlled according to niaPasswordRetrievalType, and the number of collisions for each account is limited according to niaCollisions.

6. The automatic account discovery and security check system based on the MySQL data transmission protocol according to claim 1, characterized in that, The concurrent collision and database detection execution module sets the number of worker threads according to accountAnalysisRate and uses ThreadPoolExecutor for sharding. For tasks that do not explicitly pass a database name, determine whether the database name is provided as an input parameter: If provided, use the database name; If not provided, the local database list file will be read.

7. The automatic account discovery and security check system based on the MySQL data transmission protocol according to claim 6, characterized in that, The sharded concurrent processing adopts a dynamic load-aware scheduling method instead of static sharding using ThreadPoolExecutor, specifically including: The list of accounts to be tested is written into a globally shared dynamic task queue and initially sorted. The main thread allocates an initial batch size to each worker thread. Collect real-time performance metrics, including average single-account detection time, the number of incomplete accounts currently held by the thread, and the timeout failure rate; Calculate the dynamic weight factor for each thread based on real-time performance metrics; When the number of incomplete accounts currently held by a thread exceeds a preset threshold, the main scheduler dynamically adjusts the allocation quantity based on the thread's dynamic weight factor. The main scheduler periodically evaluates the expected completion time of each thread and determines whether the thread is marked based on the expected completion time and the number of incomplete accounts currently held. The main scheduler marks some of the incomplete tasks of the marked thread as stealable, and the idle thread that has completed its own task applies to the main scheduler to steal the tasks in the stealable state. After stealing, the global task status table is updated synchronously. When the average timeout failure rate of the global statistics exceeds the preset threshold, the main scheduler automatically triggers the off-peak frequency reduction mode.

8. The automatic account discovery and security check system based on the MySQL data transmission protocol according to claim 5, characterized in that, The runtime monitoring and timeout status backfilling module starts an independent monitoring thread when the task begins, calculates the timeout threshold according to scriptTimeout, and sends the timeout signal to the worker thread through a queue. Before scanning for unmanaged accounts, the timedOutMessage of all unmanaged accounts to be detected is preset, and then updated after the detection is completed.

9. The automatic account discovery and security check system based on the MySQL data transmission protocol according to claim 1, characterized in that, The fields maintained by the inspection result data model include assetAccount, assetVersion, isWeakPass, password, baselineItem2002, and timedOutMessage; When a weak password is detected, mark isWeakPass as "yes", record the password, and set baselineItem2002 to False; After the task is completed, the list of account security check results, the list of user information, and the list of logged-in users will be serialized into JSON and concatenated using a fixed delimiter and returned.

Images