Anomaly detection method, device, equipment and storage medium

Abstract

The present application discloses an anomaly detection method, apparatus, device and storage medium, relating to the field of anomaly detection. The method is applied to a management platform, which is deployed with N anomaly detection engines, where N is greater than 1. The method includes: starting multiple coroutines to build a coroutine pool; for an anomaly detection engine that supports multi-coroutine sharing, each instance corresponds to multiple coroutines; for an anomaly detection engine that does not support multi-coroutine sharing, each instance corresponds to a single coroutine; obtaining an anomaly detection request sent by a user terminal, wherein the anomaly detection request includes the target anomaly detection engine to be adopted; if there is an idle coroutine, filtering out the idle coroutine from the coroutine pool; executing the execution logic of the target anomaly detection engine through the idle coroutine to obtain an anomaly detection result corresponding to the anomaly detection request. It can improve the anomaly detection efficiency of multiple terminals and save resources by sharing resources between coroutines.

Description

Technical Field

[0001] The present invention relates to the field of anomaly detection, and in particular to an anomaly detection method, apparatus, device and storage medium. Background Art

[0002] At present, when traditional computer security vendors perform anomaly detection on user computer terminals (hereinafter referred to as "terminals"), such as file detection, they often deploy computer virus file detection services on the terminals. Since the detection dimension of a single virus detection engine (hereinafter referred to as "engine") is too single and prone to missed reports, the detection service deployed on the terminal needs to integrate multiple anomaly detection engines. However, deploying detection services on multiple terminals separately requires a large installation and deployment workload and high maintenance costs. Moreover, since the engines rely on personalized database configurations, they are often large in size. Therefore, multi-engine anomaly detection services on the terminal side often cause excessive terminal resource (memory, hard disk, etc.) usage, consume the performance of user devices, and thus affect the normal operation of user services. Moreover, normal files on terminals generally account for a large proportion, and there is less demand for anomaly detection. Deploying engines on multiple terminals causes detection tasks to be dispersed, resulting in a waste of resources. Summary of the Invention

[0003] In view of this, the purpose of the present invention is to provide an anomaly detection method, apparatus, device, and medium that can improve the efficiency of anomaly detection in multiple terminals and save resources through resource sharing between coroutines. The specific scheme is as follows:

[0004] In a first aspect, the present application discloses an anomaly detection method, which is applied to a management platform, wherein the management platform is deployed with N anomaly detection engines, where N is greater than 1, and includes:

[0005] Start multiple coroutines to build a coroutine pool. For anomaly detection engines that support multi-coroutine sharing, each instance corresponds to multiple coroutines. For anomaly detection engines that do not support multi-coroutine sharing, each instance corresponds to a single coroutine.

[0006] Obtaining an anomaly detection request sent by a user terminal, wherein the anomaly detection request includes a target anomaly detection engine to be used;

[0007] If there is an idle coroutine, the idle coroutine is selected from the coroutine pool;

[0008] The execution logic of the target anomaly detection engine is executed through the idle coroutine to obtain an anomaly detection result corresponding to the anomaly detection request.

[0009] Optionally, each coroutine in the coroutine pool corresponds to N anomaly detection engines of the management platform;

[0010] Accordingly, executing the execution logic of the target anomaly detection engine through the idle coroutine includes:

[0011] Through the idle coroutine, a target anomaly detection engine is selected from the N anomaly detection engines to perform an anomaly detection operation.

[0012] Optionally, each coroutine in the coroutine pool corresponds to an anomaly detection engine;

[0013] Accordingly, filtering out idle coroutines from the coroutine pool includes:

[0014] An idle coroutine corresponding to the target anomaly detection engine is selected from the coroutine pool.

[0015] Optionally, the anomaly detection method further includes:

[0016] If there is no idle coroutine, a queuing operation is performed on the received exception detection request.

[0017] Optionally, obtaining the anomaly detection request sent by the user terminal includes:

[0018] Utilize the communication module pre-built based on the remote call framework to receive anomaly detection requests sent by multiple user terminals;

[0019] Accordingly, filtering out idle coroutines from the coroutine pool includes:

[0020] The communication module is used to filter out idle coroutines from the coroutine pool, and a corresponding idle coroutine is allocated to each of the anomaly detection requests.

[0021] Optionally, executing the execution logic of the target anomaly detection engine through the idle coroutine to obtain an anomaly detection result corresponding to the anomaly detection request includes:

[0022] Obtaining a detection result feedback mode configured by the user terminal;

[0023] Executing the execution logic of each target anomaly detection engine through the idle coroutine, so that each target anomaly detection engine performs anomaly detection for the anomaly detection request;

[0024] The abnormality detection result is sent to the user terminal according to the detection result feedback method.

[0025] Optionally, sending the abnormality detection result to the user terminal according to the detection result feedback method includes:

[0026] If the detection result feedback mode is single-mode return, the anomaly detection result obtained in real time is sent to the user terminal until each target detection engine completes detection;

[0027] If the detection result feedback mode is multi-mode return, after all the target anomaly detection engines perform security detection on the object to be detected, all the anomaly detection results are summarized and sent to the user terminal;

[0028] If the detection result feedback mode is a high-risk mode return, when the acquired abnormal detection result is a high-risk detection result indicating that a virus file has been detected, the abnormal detection result is sent to the user terminal in real time, and abnormal detection is stopped.

[0029] In a second aspect, the present application discloses an anomaly detection device, which is applied to a management platform. The management platform is deployed with N anomaly detection engines, where N is greater than 1, and includes:

[0030] The multi-coroutine startup module is used to start multiple coroutines and build a coroutine pool. For anomaly detection engines that support multi-coroutine sharing, each instance corresponds to multiple coroutines; for anomaly detection engines that do not support multi-coroutine sharing, each instance corresponds to a single coroutine.

[0031] A request acquisition module, configured to acquire an anomaly detection request sent by a user terminal, wherein the anomaly detection request includes a target anomaly detection engine to be used;

[0032] An idle coroutine screening module, configured to screen out idle coroutines from the coroutine pool if any exist;

[0033] An anomaly detection module is used to execute the execution logic of the target anomaly detection engine through the idle coroutine to obtain an anomaly detection result corresponding to the anomaly detection request.

[0034] In a third aspect, the present application discloses an electronic device, comprising:

[0035] Memory, used to store computer programs;

[0036] A processor is used to execute the computer program to implement the aforementioned anomaly detection method.

[0037] In a fourth aspect, the present application discloses a computer-readable storage medium for storing a computer program; wherein the computer program implements the aforementioned anomaly detection method when executed by a processor.

[0038] In this application, multiple coroutines are started to build a coroutine pool; for anomaly detection engines that support multi-coroutine sharing, each instance corresponds to multiple coroutines; for anomaly detection engines that do not support multi-coroutine sharing, each instance corresponds to a single coroutine; obtain an anomaly detection request sent by a user terminal, wherein the anomaly detection request includes the target anomaly detection engine to be adopted; if there is an idle coroutine, the idle coroutine is screened out from the coroutine pool; the execution logic of the target anomaly detection engine is executed by the idle coroutine to obtain an anomaly detection result corresponding to the anomaly detection request. It can be seen that the suspicious objects to be detected on the user terminal are uploaded to a management platform deployed with multiple anomaly detection engines for detection, the file detection is separated from the terminal, and centralized and intensive anomaly detection is performed, thereby achieving lightweight terminals and intensive resource utilization, and using multiple coroutines to realize concurrent processing of multiple requests, thereby improving the anomaly detection efficiency of multiple terminals. At the same time, the engine's own concurrency is fully utilized to support multi-mode concurrency, effectively integrate different engine components, have good scalability, and maximize the sharing of resources between coroutines, saving resources. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are merely embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0040] Figure 1 A flow chart of an anomaly detection method provided in this application;

[0041] Figure 2 A specific multi-engine management architecture diagram provided for this application;

[0042] Figure 3 A specific anomaly detection concurrent model structure diagram provided for this application;

[0043] Figure 4 A specific anomaly detection system structure diagram provided for this application;

[0044] Figure 5 A flowchart of a specific anomaly detection method provided in this application;

[0045] Figure 6 A flow chart of a specific test result feedback method provided in this application;

[0046] Figure 7 A schematic diagram of the structure of an anomaly detection device provided in this application;

[0047] Figure 8 This is a structural diagram of an electronic device provided in this application. DETAILED DESCRIPTION

[0048] To make the objectives, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts shall fall within the scope of protection of the present invention.

[0049] In the prior art, computer virus file detection services are deployed on the terminal, and to ensure comprehensive detection, the detection service deployed on the terminal needs to integrate multiple anomaly detection engines. However, deploying detection services separately on multiple terminals requires a large installation and deployment workload and high maintenance costs. Moreover, since the engine relies on personalized database configuration, etc., it is often large in size. Therefore, multi-engine anomaly detection services on the terminal side often cause excessive terminal resource usage. In order to overcome the above-mentioned distinguishing technical features, this application proposes an anomaly detection method that can improve the anomaly detection efficiency of multiple terminals and save resources through resource sharing between coroutines.

[0050] The embodiment of the present application discloses an anomaly detection method applied to a management platform, wherein the management platform is deployed with N anomaly detection engines, where N is greater than 1. Figure 1 As shown, the method may include the following steps:

[0051] Step S11: Start multiple coroutines to build a coroutine pool; for anomaly detection engines that support multi-coroutine sharing, each instance corresponds to multiple coroutines; for anomaly detection engines that do not support multi-coroutine sharing, each instance corresponds to a single coroutine.

[0052] In this embodiment, a coroutine pool is constructed by starting multiple coroutines. Each coroutine can be used to undertake an exception detection request. In addition, for anomaly detection engines that support multi-coroutine sharing, each engine instance corresponds to multiple coroutines. For anomaly detection engines that do not support multi-coroutine sharing, each engine instance corresponds to a single coroutine. It is understandable that since anomaly detection is transferred to the management platform for execution, the problem of anomaly detection concurrency will arise, that is, multiple anomaly detection requests need to be processed simultaneously. Therefore, in this embodiment, the coroutine management during multi-tasking concurrency is handled by the coroutine pool. Coroutine, also known as microthread, is a program component, and the coroutine pool is a collection of such components.

[0053] For example Figure 2As shown in the multi-engine management architecture diagram, in this embodiment, multiple engines are managed through engine management objects, and engine instances use ID as a unique identifier; for anomaly detection engines that support multi-coroutine sharing, such engine instances can correspond to multiple coroutines, and such engine instances are shared, that is, for objects that support multi-coroutine sharing, a method of sharing an engine object instance between multiple coroutines is adopted, such as engines A, B and C in the figure. For anomaly detection engines that do not support multi-coroutine sharing, such engine instances only correspond to a single coroutine, and such engine instances are not shared, that is, for engines that only support single threads, a separate instance is created for each coroutine, such as engines D and E. It is understandable that, considering that in multi-engine services, different engine objects have different support modes for concurrency, such as some engine objects support multi-coroutine sharing, and some engines only support single coroutine, that is, since different detection engines have different support modes for concurrency, a unified and concurrency-friendly engine management solution is needed to achieve scalability. In this embodiment, for engines that support multi-coroutine sharing, the engine instance of such an engine can be used directly through the corresponding coroutine to execute the detection logic of the target anomaly detection engine, for example Figure 2 In the example above, coroutine 1 uses instance 1 of shared engine A to perform exception detection. At this time, other coroutines can also use instance 1 of engine A. If the engine does not support multi-coroutine sharing, you need to create an engine instance of this type of engine for the current exception detection request, for example Figure 2 In the example, exception detection is performed through coroutine 1 using instance 1 of engine D, which is only open to this coroutine. Other coroutines cannot use this instance 1. If you need to use engine D, you need to create instance i separately.

[0054] This allows for multi-mode concurrency support, unconstrained by the engine's own concurrency limitations, and effectively integrates different engine components, resulting in excellent scalability and maximum data sharing between coroutines, saving resources. Furthermore, the use of a unified engine management object provides a common interface, making engine loading, calling, and unloading easy to standardize, simplifying and facilitating operation.

[0055] The multi-coroutine creation process may include: obtaining multiple anomaly detection engines and classifying them according to whether they support multi-coroutine sharing, resulting in engines that support sharing and engines that do not support sharing; creating a corresponding instance of each engine that supports sharing as a shared instance, and sharing the shared instance with each coroutine; creating multiple corresponding non-shared instances of each engine that does not support sharing, and assigning each non-shared instance to only one coroutine to create multiple coroutines. Specifically, whether the target anomaly detection engine supports multi-coroutine sharing can be determined based on the engine's configuration information.

[0056] Step S12: Obtain an anomaly detection request sent by the user terminal, wherein the anomaly detection request includes a target anomaly detection engine to be used.

[0057] In this embodiment, the management platform obtains an anomaly detection request sent by the user terminal, which includes a scanning requirement, so as to determine the target anomaly detection engine from a plurality of engines for scanning. That is, the detection dimension required by the above-mentioned user terminal for the object to be detected is determined according to the anomaly detection request, and then the matching target anomaly detection engine is screened out from the multi-engine detection service. The above-mentioned target anomaly detection engine can be one or more, wherein the above-mentioned object to be detected can be a suspicious file.

[0058] It is understood that the target detection type can be obtained by obtaining the anomaly detection requirements of the user terminal; determining the detection type corresponding to the user terminal based on the anomaly detection requirements; and configuring a corresponding anomaly detection engine on the management platform for each target detection type, thereby deploying multiple anomaly detection engines. Specifically, corresponding detection engines are built for detection in different dimensions, enabling the management platform to support multi-engine detection services. Each anomaly detection engine within the multi-engine detection service can be configured with a unique engine ID. Specifically, the anomaly detection requirements of multiple user terminals for local terminal files can be obtained, and then the detection type required by each user terminal can be determined based on the anomaly detection requirements of each terminal, and this detection type can be used as the target detection type. The management platform generally runs on a server environment and is a software system that uses a network communication mode to manage a certain type of binary program running on different computer terminal devices. Therefore, to address the various drawbacks of traditional terminal-side anomaly detection solutions, by integrating the antivirus services of user terminals, a multi-engine anomaly detection service is built on the management platform to perform centralized and intensive anomaly detection.

[0059] Step S13: If there is an idle coroutine, the idle coroutine is selected from the coroutine pool.

[0060] In this embodiment, if there are idle coroutines in the coroutine pool, the idle coroutines are filtered out from the coroutine pool. If there are no idle coroutines, the received exception detection request is queued and executed when an idle coroutine is found. Specifically, one idle coroutine is allocated for each received exception detection request.

[0061] In this embodiment, the acquisition of the exception detection request sent by the user terminal may include: using a communication module pre-built based on a remote call framework to receive the exception detection requests sent by multiple user terminals; correspondingly, the screening of idle coroutines from the coroutine pool may include: using the communication module to screen out idle coroutines from the coroutine pool, and assigning corresponding idle coroutines to each of the exception detection requests. It can be understood that in order to be applicable to multi-terminal and multi-task exception detection, the platform side needs to process multi-task requests. In order to adapt to concurrent task processing, the message communication layer in this embodiment adopts a remote call framework (RPC, Remote Procedure Call) framework, and multiple tasks use a coroutine pool for concurrent processing. The concurrent model structure of exception detection for request and processing is as follows: Figure 3 As shown, for newly submitted anomaly detection requests, an idle coroutine is found in the coroutine pool for processing. Coroutines do not interfere with each other. The anomaly detection coroutine is in asynchronous mode. The entire concurrency model is concise and the coroutine pool is easy to manage. Therefore, the platform side needs to use this efficient and concise concurrency model to handle multi-terminal requests and multi-task concurrency. Among them, the above-mentioned remote call framework can be specifically gRPC (Google Remote Procedure Call), which is a high-performance, open source and general RPC framework for communication services between computer nodes.

[0062] Step S14: executing the execution logic of the target anomaly detection engine through the idle coroutine to obtain an anomaly detection result corresponding to the anomaly detection request.

[0063] In this embodiment, an idle coroutine is used to receive an exception detection request, and the execution logic of the target exception detection engine is executed through the idle coroutine to obtain an exception detection result corresponding to the exception detection request. That is, the target exception detection engine is used to perform an exception detection on the object to be detected corresponding to the exception detection request, and generate a corresponding exception detection result. Among them, the above-mentioned object to be detected can be included in the exception detection request, or it can be that the exception detection request only contains the path of the object to be detected. After obtaining the exception detection request, it is necessary to determine the object to be detected based on the path. It is understandable that, for example Figure 4 As shown in the diagram of a specific anomaly detection system structure, in this embodiment, the terminal is only responsible for uploading files, submitting detection tasks and receiving detection results; the management platform is responsible for receiving detection requests and concurrently processing anomaly detection tasks, and calling the multi-engine detection service to detect the uploaded files, and finally returning the detection results to the terminal. Figure 5In the specific anomaly detection method shown, the management platform first obtains the path and detection task parameters of the suspicious object to be detected uploaded from the user terminal, including but not limited to the target anomaly detection engine ID set and return mode; the management platform parses the detection task parameters and performs anomaly detection based on the detection task parameters; matches the engine ID in the multi-engine detection service, calls the engine that meets the requirements for anomaly detection, and records the detection results according to the return mode, and finally returns the detection results to the terminal.

[0064] In this embodiment, each coroutine in the coroutine pool corresponds to N anomaly detection engines of the management platform; accordingly, the execution logic of executing the target anomaly detection engine through the idle coroutine includes: selecting the target anomaly detection engine from the N anomaly detection engines through the idle coroutine to perform an anomaly detection operation. That is, multiple coroutines are created in advance on the platform side, each coroutine corresponds to an engine set, and each engine set contains multiple anomaly detection engines, that is, each coroutine corresponds to multiple anomaly detection engines; wherein, for engines that support sharing, multiple coroutines correspond to the same engine instance; for engines that do not support sharing, each coroutine corresponds to a separate engine instance, that is, different coroutines correspond to different instances of the same engine. Therefore, by creating multiple coroutines containing multiple engine instances in advance on the platform side, when faced with an exception detection request, you only need to select an idle coroutine, which simplifies the coroutine management logic on the platform side. Then, according to the requirements corresponding to the detection request, the target anomaly detection engine is determined from the multiple engines corresponding to the coroutine for anomaly detection. By creating engine instances in advance, when receiving a request, you can directly select the required engine instance for detection, providing more comprehensive detection services.

[0065] In this embodiment, each coroutine in the coroutine pool can correspond to one anomaly detection engine; accordingly, filtering out idle coroutines from the coroutine pool includes selecting an idle coroutine from the coroutine pool that corresponds to the target anomaly detection engine. It is understood that while having each coroutine correspond to multiple anomaly detection engines can meet almost any request, it also increases platform resource usage. Therefore, it is also possible to configure a coroutine to correspond to only one anomaly detection engine. For example, in addition to starting a coroutine pool in which each coroutine corresponds to multiple anomaly detection engines, it is also possible to start a coroutine pool in which each coroutine corresponds to only one anomaly detection engine. Specifically, a coroutine that corresponds to only one anomaly detection engine can be created for commonly used engines. When a request that only requires a commonly used engine is received, this coroutine can be assigned to receive the request. However, it should be noted that before calling a coroutine that corresponds to only a single engine, the anomaly detection request must be analyzed to determine the coroutine to call. However, when calling a coroutine that corresponds to multiple engines, it is sufficient to filter out idle coroutines. After receiving the request, the idle coroutine determines the target anomaly detection engine from the multiple engines based on the information carried in the request for scanning.

[0066] As can be seen from the above, in this embodiment, a coroutine pool is constructed by starting multiple coroutines; for anomaly detection engines that support multi-coroutine sharing, each instance corresponds to multiple coroutines; for anomaly detection engines that do not support multi-coroutine sharing, each instance corresponds to a single coroutine; an anomaly detection request sent by a user terminal is obtained, wherein the anomaly detection request includes the target anomaly detection engine to be adopted; if there is an idle coroutine, an idle coroutine is filtered out from the coroutine pool; the execution logic of the target anomaly detection engine is executed by the idle coroutine to obtain an anomaly detection result corresponding to the anomaly detection request. It can be seen that the suspicious objects to be detected on the user terminal are uploaded to a management platform deployed with multiple anomaly detection engines for detection, and the detection of files is separated from the terminal, and centralized and intensive anomaly detection is performed, thereby achieving lightweight terminals and intensive resource utilization, and utilizing multiple coroutines to realize concurrent processing of multiple requests, thereby improving the anomaly detection efficiency of multiple terminals. At the same time, the engine's own concurrency is fully utilized to support multi-mode concurrency, effectively integrate different engine components, have good scalability, and maximize the sharing of resources between coroutines, saving resources.

[0067] On the basis of the above embodiment, for the above step S14, this embodiment further provides a detection result feedback method, for example Figure 6 As shown, including:

[0068] S21: Obtaining the detection result feedback mode configured by the user terminal.

[0069] In this embodiment, considering that multiple engines are deployed on the platform side for anomaly detection, the final result of anomaly detection may be a combination of the detection results of multiple engines. In order to facilitate users to query the specific details of anomaly detection in detail, this embodiment supports multiple result feedback methods, including but not limited to single mode return, multi-mode return, and high-risk mode return; of course, users can also customize the detection result feedback method, that is, the presentation form of the final result and process result of multi-engine detection in this embodiment supports user configurability.

[0070] S22: Executing the execution logic of each target anomaly detection engine through the idle coroutine, so that each target anomaly detection engine performs anomaly detection for the anomaly detection request.

[0071] S23: Sending the abnormality detection result to the user terminal according to the detection result feedback method.

[0072] In this embodiment, sending the abnormality detection result to the user terminal according to the detection result feedback method may include: if the detection result feedback method is single-mode return, sending the abnormality detection result obtained in real time to the user terminal until each target detection engine completes detection; if the detection result feedback method is multi-mode return, then after all the target abnormality detection engines perform security detection on the object to be detected, all the abnormality detection results are summarized and sent to the user terminal; if the detection result feedback method is high-risk mode return, then when the acquired abnormality detection result is a high-risk detection result indicating that a virus file has been detected, the abnormality detection result is sent to the user terminal in real time, and abnormality detection is stopped.

[0073] For example, "black" represents a virus file, "white" represents a normal file, and "gray" represents an uncertain file. In the single-mode return method, when the engine corresponding to the target anomaly detection engine ID in the multi-engine service detects a "black" or "white" result, the result and the corresponding engine ID are immediately returned. If the engines corresponding to all IDs detect a "gray" result, the "gray" result is returned. In the multi-mode return method, the results of the engine detections corresponding to all target anomaly detection engine IDs are recorded in sequence and returned in summary. In the high-risk mode return method, the "black" results detected are fed back in real time so that users can obtain the detection results that represent the risk in a timely manner. When a detection engine detects a virus file for the first time, it can be determined that the current detection object is risky, and the execution logic of the remaining anomaly detection engines can be terminated.

[0074] As can be seen from the above, this embodiment obtains the detection result feedback method configured by the user terminal; executes the execution logic of each target anomaly detection engine through the idle coroutine, so that each target anomaly detection engine performs anomaly detection in response to the anomaly detection request; and sends the anomaly detection result to the user terminal according to the detection result feedback method. Thus, by providing multiple detection result methods, the user's usage needs are met and the feedback efficiency of the detection results is improved, allowing users to make timely adjustments.

[0075] Accordingly, the embodiment of the present application also discloses an anomaly detection device for a management platform, wherein the management platform is deployed with N anomaly detection engines, where N is greater than 1, see Figure 7 As shown, the device includes:

[0076] A multi-coroutine startup module 11 is used to start multiple coroutines to build a coroutine pool; for anomaly detection engines that support multi-coroutine sharing, each instance corresponds to multiple coroutines; for anomaly detection engines that do not support multi-coroutine sharing, each instance corresponds to a single coroutine;

[0077] A request acquisition module 12 is configured to acquire an anomaly detection request sent by a user terminal, wherein the anomaly detection request includes a target anomaly detection engine to be used;

[0078] An idle coroutine screening module 13 is used to screen out idle coroutines from the coroutine pool if any are available;

[0079] The exception detection module 14 is configured to execute the execution logic of the target exception detection engine through the idle coroutine to obtain an exception detection result corresponding to the exception detection request.

[0080] As can be seen from the above, in this embodiment, a coroutine pool is constructed by starting multiple coroutines; for anomaly detection engines that support multi-coroutine sharing, each instance corresponds to multiple coroutines; for anomaly detection engines that do not support multi-coroutine sharing, each instance corresponds to a single coroutine; an anomaly detection request sent by a user terminal is obtained, wherein the anomaly detection request includes the target anomaly detection engine to be adopted; if there is an idle coroutine, an idle coroutine is filtered out from the coroutine pool; the execution logic of the target anomaly detection engine is executed by the idle coroutine to obtain an anomaly detection result corresponding to the anomaly detection request. It can be seen that the suspicious objects to be detected on the user terminal are uploaded to a management platform deployed with multiple anomaly detection engines for detection, and the detection of files is separated from the terminal, and centralized and intensive anomaly detection is performed, thereby achieving lightweight terminals and intensive resource utilization, and utilizing multiple coroutines to realize concurrent processing of multiple requests, thereby improving the anomaly detection efficiency of multiple terminals. At the same time, the engine's own concurrency is fully utilized to support multi-mode concurrency, effectively integrate different engine components, have good scalability, and maximize the sharing of resources between coroutines, saving resources.

[0081] In some specific embodiments, each coroutine in the coroutine pool corresponds to N anomaly detection engines of the management platform;

[0082] Correspondingly, the anomaly detection module 14 is further configured to select a target anomaly detection engine from the N anomaly detection engines through the idle coroutine to perform an anomaly detection operation.

[0083] In some specific embodiments, each coroutine in the coroutine pool corresponds to an anomaly detection engine;

[0084] Correspondingly, the idle coroutine screening module 13 is further configured to select an idle coroutine corresponding to the target anomaly detection engine from the coroutine pool.

[0085] In some specific embodiments, the abnormality detection device may specifically include:

[0086] If there is no idle coroutine, a queuing operation is performed on the received exception detection request.

[0087] In some specific embodiments, the request acquisition module 12 may be specifically configured to utilize a communication module pre-built based on a remote call framework to receive anomaly detection requests sent by multiple user terminals;

[0088] Accordingly, the idle coroutine screening module 13 may be configured to screen out idle coroutines from the coroutine pool using the communication module, and allocate a corresponding idle coroutine to each of the anomaly detection requests.

[0089] In some specific embodiments, the anomaly detection module 14 may specifically include:

[0090] A feedback mode acquisition unit, configured to acquire a detection result feedback mode configured by the user terminal;

[0091] a detection unit, configured to execute the execution logic of each target anomaly detection engine through the idle coroutine, so that each target anomaly detection engine performs anomaly detection for the anomaly detection request;

[0092] A result feedback unit is used to send the abnormality detection result to the user terminal according to the detection result feedback method.

[0093] In some specific embodiments, the result feedback unit may include:

[0094] A first feedback unit is configured to send the abnormality detection result obtained in real time to the user terminal if the detection result feedback mode is single-mode return, until each target detection engine completes detection;

[0095] A second feedback unit is configured to, if the detection result feedback mode is multi-mode return, aggregate all the anomaly detection results and send them to the user terminal after all the target anomaly detection engines perform security detection on the object to be detected;

[0096] The third feedback unit is used to send the abnormal detection result to the user terminal in real time and stop the abnormal detection if the detection result feedback mode is a high-risk mode return and the abnormal detection result obtained is a high-risk detection result indicating that a virus file has been detected.

[0097] The anomaly detection device may be in the form of an image file. After being executed, the image file may be run as a container or a virtual machine to implement the anomaly detection method described herein. Of course, this is not limited to image files; any software that can implement the anomaly detection method described herein is within the scope of protection of this application, such as a software module implemented in a hypervisor (virtual machine monitor) in a cloud computing platform.

[0098] Furthermore, the present application also discloses an electronic device, see Figure 8 The contents in the drawings should not be considered as any limitation on the scope of use of the present application.

[0099] Figure 8This is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of the present application. The electronic device 20 may include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 is used to store a computer program, which is loaded and executed by the processor 21 to implement the relevant steps of the anomaly detection method disclosed in any of the aforementioned embodiments.

[0100] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and the external device. The communication protocol it follows is any communication protocol that can be applied to the technical solution of this application and is not specifically limited here; the input and output interface 25 is used to obtain external input data or output data to the outside world. Its specific interface type can be selected according to specific application needs and is not specifically limited here.

[0101] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or CD, etc. The resources stored thereon include an operating system 221, a computer program 222 and data 223 including the object to be detected, etc. The storage method can be temporary storage or permanent storage.

[0102] The operating system 221 is used to manage and control the hardware devices and computer program 222 on the electronic device 20, so as to enable the processor 21 to calculate and process the massive amount of data 223 in the memory 22. The operating system 221 can be Windows Server, NetWare, Unix, Linux, etc. In addition to including computer programs capable of implementing the anomaly detection method disclosed in any of the aforementioned embodiments and executed by the electronic device 20, the computer program 222 can further include computer programs capable of performing other specific tasks.

[0103] The electronic device can be a single hardware device or a cluster of multiple hardware devices, such as a cloud computing platform. A cloud computing platform is a new software delivery model that organizes the physical hardware resources of multiple independent servers into a pooled resource cluster.

[0104] The current cloud computing platform supports several service models:

[0105] SaaS (Software as a Service): Cloud computing platform users do not need to purchase software, but instead rent software deployed on the cloud computing platform. Users do not need to maintain the software, and the software service provider will fully manage and maintain the software.

[0106] PaaS (Platform as a Service): Cloud computing platform users (usually software developers) can build new applications or extend existing applications on the cloud computing platform's infrastructure without having to purchase development, quality control, or production servers.

[0107] IaaS (Infrastructure as a Service): Cloud computing platforms provide data centers, infrastructure hardware, and software resources through the Internet. Cloud computing platforms under the IaaS model can provide servers, operating systems, disk storage, databases, and / or information resources.

[0108] Furthermore, an embodiment of the present application also discloses a computer storage medium, in which computer executable instructions are stored. When the computer executable instructions are loaded and executed by a processor, the steps of the anomaly detection method disclosed in any of the aforementioned embodiments are implemented.

[0109] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from the other embodiments. Reference can be made to the descriptions of the identical or similar parts between the various embodiments. For the devices disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple, and the relevant parts can be referred to the descriptions of the methods.

[0110] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in a random access memory (RAM), internal memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0111] Finally, it should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article, or device comprising the element.

[0112] The above is a detailed introduction to the anomaly detection method, device, equipment and medium provided by the present invention. Specific examples are used in this article to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core ideas. At the same time, for those skilled in the art, according to the ideas of the present invention, there will be changes in the specific implementation methods and application scopes. In summary, the content of this specification should not be understood as limiting the present invention.

Claims

1. A method for detecting anomalies, characterized in that: Applied to a management platform, the management platform is deployed with N anomaly detection engines, N being greater than 1, the method comprising: Start multiple coroutines to build a coroutine pool. For anomaly detection engines that support multi-coroutine sharing, each instance corresponds to multiple coroutines. For anomaly detection engines that do not support multi-coroutine sharing, each instance corresponds to a single coroutine. Obtaining an anomaly detection request sent by a user terminal, wherein the anomaly detection request includes a target anomaly detection engine to be used; If there is an idle coroutine, the idle coroutine is selected from the coroutine pool; Executing the execution logic of the target anomaly detection engine through the idle coroutine to obtain an anomaly detection result corresponding to the anomaly detection request; The multi-process creation process includes: Obtain the anomaly detection engine, and classify all anomaly detection engines according to whether the engine supports multi-coroutine sharing to obtain engines that support sharing and engines that do not support sharing; create a corresponding instance as a shared instance for the engine that supports sharing, and share the shared instance with each coroutine; create multiple corresponding non-shared instances for the engine that does not support sharing, and assign one of the non-shared instances to only one coroutine to create multiple coroutines; wherein, determine whether the engine supports multi-coroutine sharing based on the engine configuration information.

2. The anomaly detection method according to claim 1, wherein: Each coroutine in the coroutine pool corresponds to N anomaly detection engines of the management platform; Accordingly, executing the execution logic of the target anomaly detection engine through the idle coroutine includes: Through the idle coroutine, a target anomaly detection engine is selected from the N anomaly detection engines to perform an anomaly detection operation.

3. The anomaly detection method according to claim 1, wherein: Each coroutine in the coroutine pool corresponds to an anomaly detection engine; Accordingly, filtering out idle coroutines from the coroutine pool includes: An idle coroutine corresponding to the target anomaly detection engine is selected from the coroutine pool.

4. The anomaly detection method according to claim 1, wherein: Also includes: If there is no idle coroutine, a queuing operation is performed on the received exception detection request.

5. The anomaly detection method according to claim 1, wherein: The obtaining of the anomaly detection request sent by the user terminal includes: Utilize the communication module pre-built based on the remote call framework to receive anomaly detection requests sent by multiple user terminals; Accordingly, filtering out idle coroutines from the coroutine pool includes: The communication module is used to filter out idle coroutines from the coroutine pool, and a corresponding idle coroutine is allocated to each of the anomaly detection requests.

6. The abnormality detection method according to any one of claims 1 to 5, characterized in that: The executing the execution logic of the target anomaly detection engine by the idle coroutine to obtain an anomaly detection result corresponding to the anomaly detection request includes: Obtaining a detection result feedback mode configured by the user terminal; Executing the execution logic of each target anomaly detection engine through the idle coroutine, so that each target anomaly detection engine performs anomaly detection for the anomaly detection request; The abnormality detection result is sent to the user terminal according to the detection result feedback method.

7. The anomaly detection method according to claim 6, characterized in that: The sending the abnormality detection result to the user terminal according to the detection result feedback method includes: If the detection result feedback mode is single-mode return, the anomaly detection result obtained in real time is sent to the user terminal until each target anomaly detection engine completes detection; If the detection result feedback mode is multi-mode return, after all the target anomaly detection engines perform security detection on the object to be detected, all the anomaly detection results are summarized and sent to the user terminal; If the detection result feedback mode is a high-risk mode return, when the acquired abnormal detection result is a high-risk detection result indicating that a virus file has been detected, the abnormal detection result is sent to the user terminal in real time, and abnormal detection is stopped.

8. An abnormality detection device, characterized in that: Applied to a management platform, the management platform is deployed with N anomaly detection engines, N is greater than 1, and the device includes: The multi-coroutine startup module is used to start multiple coroutines and build a coroutine pool. For anomaly detection engines that support multi-coroutine sharing, each instance corresponds to multiple coroutines; for anomaly detection engines that do not support multi-coroutine sharing, each instance corresponds to a single coroutine. A request acquisition module, configured to acquire an anomaly detection request sent by a user terminal, wherein the anomaly detection request includes a target anomaly detection engine to be used; An idle coroutine screening module, configured to screen out idle coroutines from the coroutine pool if any exist; An anomaly detection module, configured to execute the execution logic of the target anomaly detection engine through the idle coroutine to obtain an anomaly detection result corresponding to the anomaly detection request; The multi-process creation process includes: Obtain the anomaly detection engine, and classify all anomaly detection engines according to whether the engine supports multi-coroutine sharing to obtain engines that support sharing and engines that do not support sharing; create a corresponding instance as a shared instance for the engine that supports sharing, and share the shared instance with each coroutine; create multiple corresponding non-shared instances for the engine that does not support sharing, and assign one of the non-shared instances to only one coroutine to create multiple coroutines; wherein, determine whether the engine supports multi-coroutine sharing based on the engine configuration information.

9. An electronic device, characterized in that: include: Memory, used to store computer programs; A processor, configured to execute the computer program to implement the anomaly detection method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that Used to store a computer program; wherein when the computer program is executed by a processor, the abnormality detection method according to any one of claims 1 to 7 is implemented.

Images