Virtual device identification method and apparatus, electronic device, computer medium, and program product

Abstract

The present disclosure provides a virtual device identification method and device, electronic equipment, computer medium and program product, relates to the technical field of computers and the technical field of network security, and particularly relates to the technical field of device virtualization. The implementation scheme is: in response to determining whether to identify whether a virtual device is installed on a client device, obtaining a preset keyword library, wherein the preset keyword library includes a plurality of risk keywords, and at least one risk keyword in the plurality of risk keywords is associated with creating a virtual device via containerization on the client device; reading a local mounting information file to determine whether at least one risk keyword exists in the local mounting information file; and in response to determining that at least one risk keyword exists in the local mounting information file, determining that the virtual device is installed on the client device.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the technical field of computer technology and network security technology, in particular to the technical field of device virtualization, and more particularly to a virtual device identification method and device, an electronic device, a computer readable storage medium, and a computer program product. BACKGROUND

[0002] With the rapid development of computer technology, device virtualization technology has been widely used. These technologies provide new means for various automated operations, but also bring challenges to the security of computer systems and mobile Internet.

[0003] The methods described in this section can not necessarily be the methods previously conceived or used. Unless otherwise indicated, nothing in this section should be assumed to be prior art merely because of its inclusion in this section. Similarly, issues mentioned in this section should not be assumed to have been admitted to be prior art in any jurisdiction unless otherwise indicated. SUMMARY

[0004] The present disclosure provides a virtual device identification method and device, an electronic device, a computer readable storage medium, and a computer program product.

[0005] According to an aspect of the present disclosure, a virtual device identification method is provided, applied to a client device, including: in response to determining that it is necessary to identify whether a virtual device is installed on the client device, obtaining a preset keyword library, wherein the preset keyword library includes a plurality of risk keywords, at least one of the plurality of risk keywords being associated with the creation of a virtual device via containerization on the client device; reading a local mount information file to determine whether at least one risk keyword exists in the local mount information file; and in response to determining that at least one risk keyword exists in the local mount information file, determining that a virtual device is installed on the client device.

[0006] According to another aspect of the present disclosure, a virtual device identification method is provided, applied to a server device, including: providing a preset keyword library, wherein the preset keyword library includes a plurality of risk keywords, at least one of the plurality of risk keywords being used to determine whether a virtual device is created via containerization on a client device in communication connection with the server device; determining whether label information indicating that a virtual device is installed on the client device is received; and in response to receiving the label information, determining the client device as a risk device so that a function associated with the virtual device installed on the client device is disabled.

[0007] According to another aspect of the present disclosure, there is provided a virtual device identification apparatus applied to a client device, comprising: a library obtaining module configured to, in response to determining that it is necessary to identify whether a virtual device is installed on the client device, obtain a preset keyword library, wherein the preset keyword library comprises a plurality of risk keywords, at least one of the plurality of risk keywords being associated with creation of a virtual device via containerization on the client device; a hit determining module configured to read a local mount information file to determine whether at least one risk keyword exists in the local mount information file; and a result determining module configured to, in response to determining that at least one risk keyword exists in the local mount information file, determine that a virtual device is installed on the client device.

[0008] According to another aspect of the present disclosure, there is provided a virtual device identification apparatus applied to a server device, comprising: a library providing module configured to provide a preset keyword library, wherein the preset keyword library comprises a plurality of risk keywords, at least one of the plurality of risk keywords being used to determine whether a virtual device is created via containerization on a client device in communication connection with the server device; a result receiving module configured to determine whether label information indicating that a virtual device is installed on the client device is received; and a risk avoiding module configured to, in response to receiving the label information, determine the client device as a risk device so that a function associated with the virtual device installed on the client device is disabled.

[0009] According to another aspect of the present disclosure, there is provided an electronic device, comprising at least one processor; and a memory in communication connection with the at least one processor; the memory storing instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the virtual device identification method as described above.

[0010] According to another aspect of the present disclosure, there is provided a non-transitory computer readable storage medium storing computer instructions for causing a computer to perform the virtual device identification method as described above.

[0011] According to another aspect of the present disclosure, there is provided a computer program product comprising a computer program which, when executed by a processor, implements the virtual device identification method as described above.

[0012] According to one or more embodiments of the present disclosure, identification of a virtual device can be effectively and accurately implemented.

[0013] It should be understood that the content described in this section is not intended to identify key or important features of the embodiments of the present disclosure, nor is it used to limit the scope of the present disclosure. Other features of the present disclosure will become apparent through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The accompanying drawings illustrate exemplary embodiments and constitute a part of the specification. Together with the description of the specification, they serve to explain exemplary implementation of the embodiments. The illustrated embodiments are for illustrative purposes only and do not limit the scope of the claims. Throughout the drawings, the same reference numerals designate similar, but not necessarily identical, elements.

[0015] Figure 1 A schematic diagram illustrating an exemplary system in which the various methods described herein may be implemented according to an embodiment of the present disclosure;

[0016] Figure 2 A flowchart of a virtual device identification method applied to a client device according to an embodiment of the present disclosure is shown;

[0017] Figure 3 A schematic diagram showing a process of constructing a keyword library according to an embodiment of the present disclosure is shown;

[0018] Figure 4 A flowchart of a virtual device identification method applied to a server device according to an embodiment of the present disclosure is shown;

[0019] Figure 5 A schematic diagram illustrating a method for identifying a virtual device applied by a system including a client device and a server device according to an embodiment of the present disclosure is shown;

[0020] Figure 6 A structural block diagram of a virtual device identification apparatus applied to a client device according to an embodiment of the present disclosure is shown;

[0021] Figure 7 A structural block diagram of a virtual device identification apparatus applied to a client device according to another embodiment of the present disclosure is shown;

[0022] Figure 8 A structural block diagram of a virtual device identification apparatus applied to a server device according to an embodiment of the present disclosure is shown;

[0023] Figure 9 A structural block diagram of a virtual device identification apparatus applied to a server device according to another embodiment of the present disclosure is shown;

[0024] Figure 10 A structural block diagram of an exemplary electronic device that can be used to implement the embodiments of the present disclosure is shown. DETAILED DESCRIPTION

[0025] The following description of exemplary embodiments of the present disclosure is made in conjunction with the accompanying drawings, including various details of the embodiments of the present disclosure to facilitate understanding, which should be considered as merely exemplary. Therefore, it should be appreciated by those skilled in the art that various changes and modifications may be made to the embodiments described herein without departing from the scope of the present disclosure. Similarly, for the sake of clarity and conciseness, descriptions of well-known functions and structures are omitted in the following description.

[0026] In this disclosure, unless otherwise specified, the use of terms such as "first" and "second" to describe various elements is not intended to limit the positional relationship, temporal relationship, or importance relationship of these elements. Such terms are only used to distinguish one element from another. In some examples, the first element and the second element may refer to the same instance of the element, while in some cases, based on the context of the description, they may also refer to different instances.

[0027] The terms used in the descriptions of the various examples described in this disclosure are for the purpose of describing specific examples only and are not intended to be limiting. Unless the context clearly indicates otherwise, if the number of elements is not specifically limited, the element may be one or more. In addition, the term "and / or" used in this disclosure encompasses any one and all possible combinations of the listed items.

[0028] Researchers and developers have proposed various forensic methods to identify and prevent virtual devices, such as hardware fingerprinting, system attribute inspection, network interface analysis, and specific file or directory inspections. While these methods can identify virtual devices to a certain extent, they can still fail to accurately identify them due to disguises and simulations using unethical virtualization techniques.

[0029] To this end, an embodiment of the present disclosure provides a virtual device identification method based on mounting features, which can effectively identify whether a virtual device is installed on a client device.

[0030] The embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings.

[0031] Figure 1 FIG2 is a schematic diagram of an exemplary system 100 in which the various methods and apparatuses described herein may be implemented according to an embodiment of the present disclosure. Figure 1 , the system 100 includes one or more client devices 101, 102, 103, 104, 105, and 106, a server 120, and one or more communication networks 110 coupling the one or more client devices to the server 120. The client devices 101, 102, 103, 104, 105, and 106 can be configured to execute one or more applications.

[0032] In an embodiment of the present disclosure, the server 120 may run one or more services or software applications that enable execution of a virtual device identification method.

[0033] In some embodiments, server 120 may also provide other services or software applications, which may include non-virtualized environments and virtualized environments. In some embodiments, these services may be provided as web-based services or cloud services, such as provided to users of client devices 101, 102, 103, 104, 105, and / or 106 under a software as a service (SaaS) model.

[0034] exist Figure 1 In the configuration shown, the server 120 may include one or more components that implement the functions performed by the server 120. These components may include software components, hardware components, or a combination thereof that can be executed by one or more processors. Users operating client devices 101, 102, 103, 104, 105, and / or 106 may, in turn, utilize one or more client applications to interact with the server 120 to utilize the services provided by these components. It should be understood that a variety of different system configurations are possible, which may differ from the system 100. Therefore, Figure 1 is one example of a system for implementing the various methods described herein and is not intended to be limiting.

[0035] The user may use client devices 101, 102, 103, 104, 105 and / or 106 to send a virtual device identification request. The client device may provide an interface that enables the user of the client device to interact with the client device. The client device may also output information to the user via the interface. Figure 1 Only six client devices are depicted, but one skilled in the art will appreciate that the present disclosure can support any number of client devices.

[0036] Client devices 101, 102, 103, 104, 105, and / or 106 may include various types of computer devices, such as portable handheld devices, general-purpose computers (such as personal computers and laptops), workstation computers, wearable devices, smart screen devices, self-service terminal devices, service robots, gaming systems, thin clients, various messaging devices, sensors or other sensing devices, etc. These computer devices may run various types and versions of software applications and operating systems, such as Microsoft Windows, Apple iOS, UNIX-like operating systems, Linux, or Linux-like operating systems (such as Google Chrome OS); or include various mobile operating systems, such as Microsoft Windows Mobile OS, iOS, Windows Phone, and Android. Portable handheld devices may include cellular phones, smartphones, tablet computers, personal digital assistants (PDAs), etc. Wearable devices may include head-mounted displays (such as smart glasses) and other devices. Gaming systems may include various handheld gaming devices, internet-enabled gaming devices, etc. Client devices are capable of executing a variety of different applications, such as various internet-related applications, communication applications (such as email applications), and short message service (SMS) applications, and may use various communication protocols.

[0037] The network 110 may be any type of network known to those skilled in the art that can support data communications using any of a variety of available protocols, including but not limited to TCP / IP, SNA, IPX, etc. By way of example only, the one or more networks 110 may be a local area network (LAN), an Ethernet-based network, a token ring, a wide area network (WAN), the Internet, a virtual network, a virtual private network (VPN), an intranet, an extranet, a blockchain network, a public switched telephone network (PSTN), an infrared network, a wireless network (e.g., Bluetooth, WIFI), and / or any combination of these and / or other networks.

[0038] Server 120 may include one or more general-purpose computers, specialized server computers (e.g., PC (personal computer) servers, UNIX servers, mid-range servers), blade servers, mainframe computers, server clusters, or any other suitable arrangement and / or combination. Server 120 may include one or more virtual machines running virtual operating systems, or other computing architectures involving virtualization (e.g., one or more flexible pools of logical storage devices that may be virtualized to maintain a server's virtual storage device). In various embodiments, server 120 may run one or more services or software applications that provide the functionality described below.

[0039] The computing units in the server 120 may run one or more operating systems including any of the operating systems described above as well as any commercially available server operating systems. The server 120 may also run any of a variety of additional server applications and / or middle-tier applications, including HTTP servers, FTP servers, CGI servers, JAVA servers, database servers, and the like.

[0040] In some implementations, server 120 may include one or more applications to analyze and consolidate data feeds and / or event updates received from users of client devices 101, 102, 103, 104, 105, and / or 106. Server 120 may also include one or more applications to display the data feeds and / or real-time events via one or more display devices of client devices 101, 102, 103, 104, 105, and / or 106.

[0041] In some embodiments, server 120 may be a distributed system server or a server integrated with blockchain. Server 120 may also be a cloud server, or an intelligent cloud computing server or intelligent cloud host equipped with artificial intelligence technology. A cloud server is a host product within the cloud computing service system that addresses the management difficulties and poor scalability of traditional physical hosts and virtual private servers (VPS) services.

[0042] The system 100 may also include one or more databases 130. In some embodiments, these databases may be used to store data and other information. For example, one or more of the databases 130 may be used to store information such as audio files and video files. The databases 130 may reside in a variety of locations. For example, the database used by the server 120 may be local to the server 120, or may be remote from the server 120 and communicate with the server 120 via a network-based or dedicated connection. The databases 130 may be of different types. In some embodiments, the databases used by the server 120 may be, for example, relational databases. One or more of these databases may store, update, and retrieve data to and from the databases in response to commands.

[0043] In some embodiments, one or more of the databases 130 may also be used by applications to store application data. The databases used by the applications may be different types of databases, such as a key-value store, an object store, or a conventional store backed by a file system.

[0044] Figure 1The system 100 may be configured and operated in various ways to enable application of the various methods and apparatuses described in accordance with the present disclosure.

[0045] Various aspects of the virtual device identification method according to an embodiment of the present disclosure will be described in detail below.

[0046] Figure 2 A flowchart of a virtual device identification method 200 applied to a client device according to an embodiment of the present disclosure is shown.

[0047] In this embodiment, the client device may be Figure 1 The client device may be connected to a server device for communication, and the server device may be a client device 101, 102, 103, 104, 105 or 106. Figure 1 The server 120 shown in FIG.

[0048] The virtual device referred to in this article is a device simulated by software. It functionally imitates the behavior and characteristics of real hardware devices, but there is no actual physical hardware.

[0049] like Figure 2 As shown, method 200 includes steps S201 , S202 and S203 .

[0050] In step S201, in response to determining whether a virtual device is installed on a client device, a preset keyword library is obtained, wherein the preset keyword library includes multiple risk keywords, at least one of which is associated with a virtual device created via containerization on the client device.

[0051] In the example, the client device may be pre-installed with a plug-in or application that can provide a virtual device identification service, with the help of which the user can initiate the identification of the virtual device on the client device, or the server device can send a request for identification of the virtual device to the client device so that the user can determine whether to perform the corresponding operation.

[0052] In the example, a preset keyword library can be stored on a server device. When it is necessary to identify whether a virtual device is installed on a client device, the keyword library can be sent from the server device to the client device locally, or the client device can remotely access the keyword library.

[0053] In this example, the keyword library can also be called a mount signature library because the multiple risk keywords included in the keyword library are related to mount signatures. Risk keywords can be, for example, "docker" and "container." Mount signatures refer to trace information left in the mount information file when a virtual device is created on a client device through containerization.

[0054] In Linux-based operating systems such as Android, a mount information file is a file used to record the mount status of a file system. It can provide information about how a specific process (identified by a process ID, or PID) accesses the file system, so that the mount behavior of the process can be debugged and monitored or the performance of the file system can be optimized through the mount information file. The mount information file can record the mount point, such as listing all currently mounted file systems and their corresponding mount points, or the type of file system at each mount point. It can also record the mount source, such as the address and shared path of a remote server for a network file system, etc. Accordingly, the mount information file generally includes multiple fields, such as a mount ID, a parent mount ID, a mount point, a mount source, etc.

[0055] Therefore, if a virtual device is created on a client device via containerization, corresponding trace information, known as mount signatures, will be left in the mount information file. These mount signatures are expressed as risk keywords. Therefore, if the corresponding risk keywords can be found in the mount information file, it can be confirmed that a virtual device was created on the client device via containerization.

[0056] In step S202, the local mount information file is read to determine whether the local mount information file contains the at least one risk keyword.

[0057] In an example, the client device may be installed with an Android operating system, and the local mount information file may be used for the Android operating system and stored on the client device.

[0058] In the example, for each risk keyword in the keyword library, the local mount information file may be parsed line by line to determine whether the corresponding risk keyword is hit.

[0059] In step S203, in response to determining that the at least one risk keyword exists in the local mounting information file, it is determined that a virtual device is installed on the client device.

[0060] In the example, virtual devices may include simulators, such as game simulators, cloud simulators, and virtual machines. Simulators are generally packaged using container technology on a development board. Container technology achieves isolation by using the mount namespace mechanism in the Linux kernel's namespaces. This isolation enables containers to have a different and independent operating environment from the host system while sharing the same operating system kernel. By using mount namespaces, mount points can be isolated, allowing the container to have a different file system layout from the host system, so that the container can mount its own file system without affecting the host system.

[0061] Therefore, if a client device's local mount information file contains a mount feature with containerization traces, it means that a virtual device must have been created on the client device through containerization. Conversely, a client device that has not normally created a virtual device should not have any mount features in its local mount information file.

[0062] In a virtual device identification method 200 applied to a client device according to an embodiment of the present disclosure, whether a virtual device is installed on the client device is indirectly determined by determining whether the corresponding mount characteristics exist in the client device's local mount information file, starting from the perspective of whether the mount characteristics remain in the mount information file. Because the client device can access a keyword library that reflects the mount characteristics through risk keywords, it can effectively and accurately identify the virtual device by identifying the corresponding risk keywords in the local mount information file. This avoids camouflage and simulation designed by unscrupulous virtualization technologies to evade identification, thereby improving the comprehensiveness and stability of identification.

[0063] In the disclosed technical solutions, the collection, storage, use, processing, transmission, provision and disclosure of user personal information involved are in compliance with relevant laws and regulations and do not violate public order and good morals.

[0064] In some embodiments, the plurality of risk keywords may be determined based on a first test client device having a virtual device installed thereon. A first mount information file of the first test client device may be read to obtain candidate keywords associated with containerization of the virtual device in the first mount information file as the plurality of risk keywords.

[0065] In this example, a known specific virtual device (e.g., a known virtual device manufacturer or model) may be installed on the first test client device. In this case, the local mount information file of the first test client device, i.e., the first mount information file, can be read and searched for suspicious items related to the mount characteristics in the first mount information file. Such suspicious items are keywords associated with the containerization of virtual devices, i.e., candidate keywords.

[0066] In this example, the number of first test client devices can be one or more. This means that the risk keywords can be obtained based on the first mount information file in a single first test client device, or based on multiple first mount information files corresponding to multiple first test client devices. Furthermore, when multiple first test client devices are used, each of the multiple first test client devices can have a different virtual device installed, or some of the multiple first test client devices can have the same virtual device installed.

[0067] Through the above method, by using the first test client device with the virtual device installed as a sample to obtain risk keywords reflecting the mounting characteristics, the prior knowledge related to the mounting characteristics can be comprehensively accumulated to enrich and complete the keyword library, thereby facilitating the effective and accurate identification of the virtual device.

[0068] In some embodiments, at least one candidate keyword among the plurality of candidate keywords that is present in the second mounting information file of the second test client device, on which no virtual device is installed, may be removed.

[0069] In this example, as previously mentioned, a client device that has not normally created a virtual device should not have any mount features in its local mount information file. Therefore, the local mount information file (i.e., the second mount information file) of the second test client device (a normal client device that has not installed a virtual device) will not have any mount features. This means that if any of the candidate keywords mentioned above appear in the second mount information file of the second test client device, they may not actually be risky keywords related to the mount feature. Therefore, the second mount information file of the second test client device can be used to verify this.

[0070] If any candidate keyword appears in both the first mounting information file of the first test client device and the second mounting information file of the second test client device, the candidate keyword may be removed. Conversely, if any candidate keyword appears in the first mounting information file of the first test client device but does not appear in the second mounting information file of the second test client device, the candidate keyword may be retained.

[0071] Therefore, by using the local mount information file of a normal client device to verify the previously accumulated risk keywords, accurate screening of risk keywords can be achieved, avoiding mistakenly including keywords that are actually not related to the mount characteristics into the keyword library as risk keywords, thereby helping to improve the accurate identification of virtual devices.

[0072] In some embodiments, each of the plurality of candidate keywords may have an expanded candidate keyword obtained by expansion. When both the candidate keyword and the expanded candidate keyword appear in the second mounting information file of the second test client device, the candidate keyword may be determined to exist in the second mounting information file of the second test client device.

[0073] In the example, some keywords related to the mount feature (such as "virtual") may also appear in the second mount information file of the second test client device, which is a normal client device, because they may be used more frequently or have a higher probability of use. In this case, if they are excluded according to the method of the aforementioned embodiment, it is very likely that risk keywords that are actually related to the mount feature will be missed. Therefore, it is possible to doubly verify whether the candidate keyword is indeed related to the mount feature by expanding the candidate keyword. For example, if the candidate keyword is "virtual", the corresponding extended candidate keyword may be "virtual box". Accordingly, only when the candidate keyword "virtual" and the extended candidate keyword "virtual box" both appear in the second mount information file of the second test client device, the candidate keyword "virtual" is actually determined to be present in the second mount information file of the second test client device.

[0074] In this way, it is possible to avoid missing keywords that should be included in the keyword library as risk keywords, thereby further improving the accuracy of risk keywords, and thus helping to further improve the accurate identification of virtual devices.

[0075] Figure 3 FIG. 3 is a schematic diagram showing a process 300 of building a keyword library according to an embodiment of the present disclosure.

[0076] like Figure 3 As shown, in process 300 , a first test client device 301 with a virtual device installed and a second test client device 302 without a virtual device installed can be accessed to read the corresponding first mounting information file 3011 and second mounting information file 3021 respectively.

[0077] Next, the first mount information file 3011 of the first test client device 301 may be searched for suspicious items associated with the containerization of virtual devices, namely, candidate keywords 3011a. At this point, candidate keywords 3011a may be used as risk keywords, and the accuracy of candidate keywords 3011a may be further verified.

[0078] For verification purposes, the second mounting information file 3021 of the second test client device 302 may be searched to determine whether candidate keyword 3011a exists. If not, candidate keyword 3011a may be retained as a risky keyword. If present, candidate keyword 3011a may be removed. This verification process prevents keywords that do not possess mounting characteristics from being included in the keyword library.

[0079] In addition, before removing the candidate keyword 3011a, further verification can be performed by expanding the candidate keyword 3011a. Specifically, it is determined whether both the candidate keyword 3011a and the expanded candidate keyword 3011a' appear in the second mounting information file 3021 of the second test client device 302. If both appear, the candidate keyword 3011a is determined to exist in the second mounting information file 3021 of the second test client device 302, and thus the candidate keyword 3011a can be removed.

[0080] Thus, a keyword library 303 can be constructed, and the keyword library 303 can be stored in the server device or can be remotely accessed by the server device. In actual application, the keyword library 303 can be verified online. That is, as the number of client devices that can be connected to the server device increases, the number of samples of client devices that can be used as the first test also increases accordingly. This means that the keyword library 303 can be dynamically increased, deleted, or modified.

[0081] In some embodiments, as Figure 2 The illustrated method 200 may further include generating tag information indicating that a virtual device is installed on the client device; and providing the tag information to cause a function associated with the virtual device installed on the client device to be disabled.

[0082] In this example, a client device can locally generate tag information and report it to a server device. The tag information can indicate information related to the manufacturer and model of the virtual device. After receiving the tag information, the server can use it to determine whether the virtual device involves any unauthorized technology and has illegal attributes. If so, the server can instruct the client device or remotely control the client device to disable the functions associated with the virtual device.

[0083] By using the above method, timely measures can be taken to avoid risks when identifying virtual devices with illegal attributes. At the same time, since the client device is marked with the label information of the installed virtual device, the client device can also be used as the first test client device and participate in the construction and subsequent expansion of keywords.

[0084] In some embodiments, each of the multiple risk keywords may include at least one of a first characteristic keyword indicating that the virtual device is containerized or a second characteristic keyword indicating the manufacturer of the virtual device. For example, each risk keyword may be the first characteristic keyword, the second characteristic keyword, or a combination of the first and second characteristic keywords.

[0085] In an example, the first feature keyword can be "docker", "container", etc. as described above, which can directly reflect that the virtual device is created using containerization technology. In some cases, keywords related to the manufacturer of the virtual device can also appear in the mount information file, so such second feature keywords can also be used as risk keywords.

[0086] In the above manner, by estimating the style, type or attribute of the keywords that can appear in the mount information file, the risk keywords related to the mounting feature can be more comprehensively covered, thereby helping to enrich and complete the keyword library, so as to effectively and accurately realize the identification of the virtual device.

[0087] Figure 4 A flowchart of a virtual device identification method 400 applied to a server device according to an embodiment of the present disclosure is shown.

[0088] As shown in Figure 4 , the method 400 includes steps S401, S402 and S403.

[0089] In step S401, a preset keyword library is provided, the preset keyword library including a plurality of risk keywords, at least one of the plurality of risk keywords being used to determine whether a virtual device is created via containerization on a client device in communication connection with the server device.

[0090] In an example, the preset keyword library can be stored on the server device, and when it is to be identified whether a virtual device is installed on the client device, the keyword library can be sent by the server device to the local of the client device, or the client device can also access the keyword library in a remote manner.

[0091] In an example, as described above, the preset keyword library can also be referred to as a mount feature library, and the mount feature refers to the trace information left in the mount information file when the virtual device is created via containerization on the client device, so the plurality of risk keywords included in the keyword library are related to the mount feature.

[0092] In step S402, it is determined whether label information indicating that a virtual device is installed on the client device is received.

[0093] In an example, the label information can indicate information related to the manufacturer and model of the virtual device, and when the server device receives the label information uploaded by the client device, it can be determined according to the content of the label information whether the virtual device exists on the client device, and it can also be judged according to this whether the virtual device involves any bad technology and has illegal attributes.

[0094] At step S403, in response to receiving the label information, the client device is determined as a risk device so that the function associated with the virtual device installed on the client device is disabled.

[0095] In an example, if the label information received by the server device indicates that a virtual device is installed on the client device, the client device can be identified as a risk device. At the same time, the server device can take corresponding measures, for example, the access function of the virtual device to the storage resource can be disabled, the virtual device can be isolated from normal devices, or the network access of the virtual device can be limited, to ensure the security of the system.

[0096] Therefore, in the virtual device identification method 400 applied to the server device according to the embodiments of the present disclosure, since the server device can provide the keyword library for the client device to determine whether a virtual device is created via containerization on the client device, the client device can help identify the corresponding risk keywords to effectively and accurately identify the virtual device, avoid the disguise and simulation designed by the bad virtualization technology to evade identification, and improve the comprehensiveness and stability of identification. In addition, the server device can timely process the client device according to the reporting result to prevent the virtual device from interfering with the normal operation of other systems or services or causing security risks, thereby improving the security of the information system.

[0097] In some embodiments, as shown in the method 400, the method 400 can further include: in response to receiving a request to identify whether a virtual device is installed on the client device, determining whether to start a control policy; and in response to determining to start the control policy, providing a preset keyword library. Figure 4

[0098] In an example, the request to identify whether a virtual device is installed on the client device can come from a security monitoring mechanism inside the client device system, a trigger of specific business logic, or other scenarios that need to confirm the authenticity of the client device. The server can determine whether to start the control policy according to a series of factors. These factors can include the current security policy of the system, the resource status, the business demand, the legal policy requirement, and the assessment of potential security risks, etc. For example, if the system is currently resource sufficient and the business requires strict prohibition of the existence of virtual devices, the server can decide to start the control policy; on the contrary, if the system is resource-constrained, the identification demand is not urgent, or there are other special circumstances, the server can choose not to start the control policy for the time being. Once the server determines to start the control policy, the identification process of whether the client device has a virtual device can be started. At this time, the server can provide a preset keyword library.

[0099] ​Therefore, by flexibly determining whether to start the control strategy, not only can the accurate control of whether to start the identification strategy be realized, but also when starting, the accurate judgment basis can be provided for the virtual device identification to avoid resource waste and improve system resource utilization.

[0100] Figure 5 A schematic diagram of a system applying a virtual device identification method according to an embodiment of the present disclosure is shown, which includes a client device 520 and a server device 510.

[0101] As shown in Figure 5 The left side represents the server device 510 and the corresponding steps performed by the server device 510, and the right side represents the client device 520 and the corresponding steps performed by the client device 520.

[0102] In step S501, the client device 520 can send a request to the server device 510 about whether a virtual device is installed on the client device 520. In step S502, the server device 510 can start a control strategy based on, for example, a security policy or a preset condition. In step S503, the server device 510 can provide a preset keyword library to the client device 520, which is used to identify whether a virtual device exists on the client device 520.

[0103] In step S504, after receiving the preset keyword library, the client device 520 can read and parse a local mounting information file to determine whether at least one risk keyword included in the preset keyword library exists in the local mounting information file. In step S505, if the at least one risk keyword exists in the local mounting information file, it can be confirmed that a virtual device is installed on the client device 520. In step S506, once it is confirmed that a virtual device is installed on the client device 520, corresponding label information can be generated.

[0104] In step S507, the client device 520 can send the label information to the server device 510. In step S508, after receiving the label information, the server device 510 can evaluate whether the client device 520 is a risk device according to the label information. In step S509, if the client device 520 is evaluated as a risk device, some risk functions related to the virtual device on the client device 520 can be disabled to prevent illegal or unauthorized virtual device from accessing system resources.

[0105] According to an embodiment of the present disclosure, a virtual device identification apparatus applied to a client device is also provided.

[0106] Figure 6 A structural block diagram of a virtual device identification apparatus applied to a client device according to an embodiment of the present disclosure is shown.

[0107] like Figure 6 As shown, apparatus 600 includes a library acquisition module 601, a hit determination module 602, and a result determination module 603. Library acquisition module 601 is configured to, in response to determining whether a virtual device is installed on a client device, acquire a preset keyword library, the preset keyword library including multiple risk keywords, at least one of which is associated with a virtual device created via containerization on the client device. Hit determination module 602 is configured to read a local mount information file to determine whether at least one risk keyword exists in the local mount information file. Result determination module 603 is configured to, in response to determining the presence of at least one risk keyword in the local mount information file, determine that a virtual device is installed on the client device.

[0108] The operations of the library acquisition module 601, the hit determination module 602 and the result determination module 603 may correspond to the following: Figure 2 The operations of steps S201, S202 and S203 are shown in FIG. Therefore, details of each aspect thereof will not be repeated here.

[0109] In some embodiments, the above-mentioned multiple risk keywords can be determined based on a first test client device, and a virtual device is installed on the first test client device, wherein the first mounting information file of the first test client device can be read so that multiple candidate keywords associated with the containerization of the virtual device in the first mounting information file are obtained as the above-mentioned multiple risk keywords.

[0110] In some embodiments, at least one candidate keyword among the plurality of candidate keywords that is present in the second mounting information file of the second test client device may be removed, and no virtual device is installed on the second test client device.

[0111] In some embodiments, each of the above-mentioned multiple candidate keywords may have an expanded candidate keyword obtained by expansion, wherein, when the candidate keyword and the expanded candidate keyword both appear in the second mounting information file of the second test client device, the candidate keyword can be determined to exist in the second mounting information file of the second test client device.

[0112] Figure 7 A structural block diagram of a virtual device identification apparatus 700 applied to a client device according to another embodiment of the present disclosure is shown.

[0113] like Figure 7As shown, the apparatus 700 may include a library acquisition module 701, a hit determination module 702, a result determination module 703, a label generation module 704, and a label providing module 705. The library acquisition module 701, the hit determination module 702, and the result determination module 703 may correspond to the following respectively: Figure 6 The library acquisition module 601, the hit determination module 602, and the result determination module 603 are shown. The tag generation module 704 can be configured to generate tag information indicating that a virtual device is installed on the client device. The tag provision module 705 can be configured to provide tag information to disable a function associated with the virtual device installed on the client device.

[0114] In some embodiments, each of the plurality of risk keywords may include at least one of a first characteristic keyword indicating that the virtual device is containerized or a second characteristic keyword indicating the manufacturer of the virtual device.

[0115] According to an embodiment of the present disclosure, a virtual device identification apparatus applied to a server device is also provided.

[0116] Figure 8 A structural block diagram of a virtual device identification apparatus 800 applied to a server device according to an embodiment of the present disclosure is shown.

[0117] like Figure 8 As shown, the apparatus 800 includes a library providing module 801, a result receiving module 802, and a risk avoidance module 803. The library providing module 801 is configured to provide a preset keyword library, which includes a plurality of risk keywords, at least one of which is used to determine whether a virtual device is created via containerization on a client device that is in communication with a server device. The result receiving module 802 is configured to determine whether tag information indicating that a virtual device is installed on the client device is received. The risk avoidance module 803 is configured to, in response to receiving the tag information, determine that the client device is a risky device so that functions associated with the virtual device installed on the client device are disabled.

[0118] The operations of the library providing module 801, the result receiving module 802 and the risk avoiding module 803 can respectively correspond to the following: Figure 4 The operations of steps S401, S402 and S403 are shown in FIG. Therefore, details of each aspect thereof will not be repeated here.

[0119] Figure 9 A structural block diagram of a virtual device identification apparatus 900 applied to a server device according to another embodiment of the present disclosure is shown.

[0120] like Figure 9As shown, the apparatus 900 may include a library providing module 901, a result receiving module 902, a risk avoidance module 903, an opening confirmation module 904 and an opening execution module 905. The library providing module 901, the result receiving module 902 and the risk avoidance module 903 may correspond to the following respectively: Figure 8 The library providing module 801, the result receiving module 802, and the risk avoidance module 803 are shown. The activation confirmation module 904 can be configured to determine whether to activate the control policy in response to receiving a request to identify whether a virtual device is installed on the client device. The activation execution module 905 can be configured to instruct the library providing module to provide a preset keyword library in response to determining to activate the control policy.

[0121] According to an embodiment of the present disclosure, an electronic device is also provided, comprising at least one processor; and a memory communicatively connected to the at least one processor, wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the method described above.

[0122] According to an embodiment of the present disclosure, a non-transitory computer-readable storage medium storing computer instructions is further provided, wherein the computer instructions are used to enable a computer to execute the method described above.

[0123] According to an embodiment of the present disclosure, a computer program product is further provided, including a computer program, wherein the computer program implements the method described above when executed by a processor.

[0124] refer to Figure 10 , a block diagram of an electronic device 1000 that can serve as a server or client of the present disclosure will now be described, which is an example of a hardware device that can be applied to various aspects of the present disclosure. The electronic device is intended to represent various forms of digital electronic computer devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present disclosure described and / or required herein.

[0125] like Figure 10As shown, the electronic device 1000 includes a computing unit 1001, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 1002 or a computer program loaded from a storage unit 1008 into a random access memory (RAM) 1003. Various programs and data required for the operation of the electronic device 1000 can also be stored in the RAM 1003. The computing unit 1001, the ROM 1002, and the RAM 1003 are connected to each other via a bus 1004. An input / output (I / O) interface 1005 is also connected to the bus 1004.

[0126] Multiple components in the electronic device 1000 are connected to the I / O interface 1005, including: an input unit 1006, an output unit 1007, a storage unit 1008, and a communication unit 1009. The input unit 1006 can be any type of device that can input information to the electronic device 1000. The input unit 1006 can receive input digital or character information, and generate key signal input related to user settings and / or function control of the electronic device, and can include but is not limited to a mouse, a keyboard, a touch screen, a trackpad, a trackball, a joystick, a microphone, and / or a remote control. The output unit 1007 can be any type of device that can present information, and can include but is not limited to a display, a speaker, a video / audio output terminal, a vibrator, and / or a printer. The storage unit 1008 can include but is not limited to a magnetic disk and an optical disk. The communication unit 1009 allows the electronic device 1000 to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks, and may include but is not limited to a modem, a network card, an infrared communication device, a wireless communication transceiver and / or a chipset, such as a Bluetooth device, an 802.11 device, a WiFi device, a WiMax device, a cellular communication device and / or the like.

[0127] The computing unit 1001 can be various general purpose and / or special purpose processing components having processing and computing capabilities. Some examples of the computing unit 1001 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various specialized artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 1001 performs various methods and processes described above, e.g., in some embodiments, the methods can be implemented as a computer software program tangibly embodied in a machine-readable medium, e.g., the storage unit 1008. In some embodiments, part or all of the computer program can be loaded and / or installed onto the electronic device 1000 via the ROM 1002 and / or the communication unit 1009. When the computer program is loaded onto the RAM 1003 and executed by the computing unit 1001, one or more steps of the methods described above can be performed. Alternatively, in other embodiments, the computing unit 1001 can be configured to perform the methods described above by any other suitable means, e.g., by means of firmware.

[0128] Various implementations of the systems and techniques described above can be realized in digital electronic circuitry, integrated circuitry, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a system on a chip (SOC), a complex programmable logic device (CPLD), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include implementation in one or more computer programs that are executable and / or interpretable on a programmable system including at least one programmable processor, which can be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.

[0129] Program code for carrying out methods of the present disclosure can be written in any combination of one or more programming languages. The program code can be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the program code, when executed by the processor or controller, produces the functions / operations specified in the flowcharts and / or the block diagrams. The program code can be executed entirely on a machine, partially on a machine, partially on a machine and partially on a remote machine or entirely on a remote machine or server.

[0130] In the context of this disclosure, a machine-readable medium can be a tangible medium that contains or stores a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can include but is not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the machine-readable storage medium would include a lined- up electrical connection, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0131] To provide for interaction with a user, the systems and techniques described here can be implemented on a computer having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form, including acoustic, speech, or tactile input.

[0132] The systems and techniques described here can be implemented in a computing system that includes a back end component (e.g., as a data server), or that includes a middleware component (e.g., an application server), or that includes a front end component (e.g., a user computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the systems and techniques described here), or any combination of such back end, middleware, or front end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network (LAN), a wide area network (WAN), the Internet, and a blockchain network.

[0133] The computer system can include clients and servers. This relationship can be remote or on-site. The servers can be cloud servers, servers of a distributed system, or servers combined with a blockchain.

[0134] It should be understood that the various forms of flow shown above can be used to reorder, add, or delete steps. For example, the steps described in the present disclosure can be performed in parallel, sequentially, or in a different order, as long as the desired results of the technical solutions disclosed in the present disclosure can be achieved, which are not limited herein.

[0135] Although embodiments or examples of the present disclosure have been described with reference to the accompanying drawings, it should be understood that the above-described methods, systems, and devices are merely exemplary embodiments or examples, and the scope of the present disclosure is not limited by these embodiments or examples, but only by the granted claims and their equivalent scope. Various elements in the embodiments or examples can be omitted or replaced by equivalent elements. In addition, each step can be performed in an order different from that described in the present disclosure. Further, various elements in the embodiments or examples can be combined in various ways. It is important that many of the elements described herein can be replaced by equivalent elements that appear after the present disclosure as technology evolves.

Claims

1. A virtual device identification method, applied to a client device, comprising: In response to determining whether a virtual device is installed on the client device, obtaining a preset keyword library, wherein the preset keyword library includes a plurality of risk keywords, at least one risk keyword of the plurality of risk keywords is associated with the virtual device created via containerization on the client device, The plurality of risk keywords are determined based on a first test client device, the virtual device being installed on the first test client device, wherein a first mount information file of the first test client device is read so that a plurality of candidate keywords associated with containerization of the virtual device in the first mount information file are obtained as the plurality of risk keywords, At least one candidate keyword among the plurality of candidate keywords that exists in the second mounting information file of the second test client device is removed, and the virtual device is not installed on the second test client device. wherein each candidate keyword of the plurality of candidate keywords has an expanded candidate keyword obtained by expansion, wherein when both the candidate keyword and the expanded candidate keyword appear in the second mounting information file of the second test client device, the candidate keyword is determined to exist in the second mounting information file of the second test client device; Reading a local mount information file to determine whether the at least one risk keyword exists in the local mount information file; and In response to determining that the at least one risk keyword exists in the local mount information file, it is determined that the virtual device is installed on the client device.

2. The method according to claim 1, wherein The method further comprises: generating tag information for indicating that the virtual device is installed on the client device; and The tag information is provided to cause functionality associated with the virtual device installed on the client device to be disabled.

3. The method according to claim 1 or 2, wherein: Each of the plurality of risk keywords includes at least one of a first characteristic keyword indicating that the virtual device is containerized or a second characteristic keyword indicating a manufacturer of the virtual device.

4. A virtual device identification method, applied to a server device, comprising: A preset keyword library is provided, wherein the preset keyword library includes a plurality of risk keywords, at least one of the plurality of risk keywords is used to determine whether a virtual device is created via containerization on a client device that is communicatively connected to the server device. The plurality of risk keywords are determined based on a first test client device, the virtual device being installed on the first test client device, wherein a first mount information file of the first test client device is read so that a plurality of candidate keywords associated with containerization of the virtual device in the first mount information file are obtained as the plurality of risk keywords, At least one candidate keyword among the plurality of candidate keywords that exists in the second mounting information file of the second test client device is removed, and the virtual device is not installed on the second test client device. wherein each candidate keyword of the plurality of candidate keywords has an expanded candidate keyword obtained by expansion, wherein when both the candidate keyword and the expanded candidate keyword appear in the second mounting information file of the second test client device, the candidate keyword is determined to exist in the second mounting information file of the second test client device; determining whether tag information indicating that the virtual device is installed on the client device is received; and In response to receiving the tag information, the client device is determined to be a risky device such that functionality associated with the virtual device installed on the client device is disabled.

5. The method according to claim 4, wherein The method further comprises: In response to receiving a request to identify whether a virtual device is installed on the client device, determining whether to enable a control policy; and In response to determining to start the control strategy, the preset keyword library is provided.

6. A virtual device identification device, applied to a client device, comprising: A library acquisition module is configured to, in response to determining whether a virtual device is installed on the client device, acquire a preset keyword library, wherein the preset keyword library includes a plurality of risk keywords, at least one risk keyword of the plurality of risk keywords is associated with the virtual device created via containerization on the client device, The plurality of risk keywords are determined based on a first test client device, the virtual device being installed on the first test client device, wherein a first mount information file of the first test client device is read so that a plurality of candidate keywords associated with containerization of the virtual device in the first mount information file are obtained as the plurality of risk keywords, At least one candidate keyword among the plurality of candidate keywords that exists in the second mounting information file of the second test client device is removed, and the virtual device is not installed on the second test client device. wherein each candidate keyword of the plurality of candidate keywords has an expanded candidate keyword obtained by expansion, wherein when both the candidate keyword and the expanded candidate keyword appear in the second mounting information file of the second test client device, the candidate keyword is determined to exist in the second mounting information file of the second test client device; a hit determination module configured to read a local mount information file to determine whether the at least one risk keyword exists in the local mount information file; and The result determination module is configured to determine that the virtual device is installed on the client device in response to determining that the at least one risk keyword exists in the local mounting information file.

7. The device according to claim 6, wherein The device further comprises: a label generating module configured to generate label information for indicating that the virtual device is installed on the client device; and The tag providing module is configured to provide the tag information so that a function associated with the virtual device installed on the client device is disabled.

8. The device according to claim 6 or 7, wherein: Each of the plurality of risk keywords includes at least one of a first characteristic keyword indicating that the virtual device is containerized or a second characteristic keyword indicating a manufacturer of the virtual device.

9. A virtual device identification device, applied to a server device, comprising: A library providing module is configured to provide a preset keyword library, wherein the preset keyword library includes a plurality of risk keywords, at least one risk keyword of the plurality of risk keywords is used to determine whether a virtual device is created via containerization on a client device in communication with the server device. The plurality of risk keywords are determined based on a first test client device, the virtual device being installed on the first test client device, wherein a first mount information file of the first test client device is read so that a plurality of candidate keywords associated with containerization of the virtual device in the first mount information file are obtained as the plurality of risk keywords, At least one candidate keyword among the plurality of candidate keywords that exists in the second mounting information file of the second test client device is removed, and the virtual device is not installed on the second test client device. wherein each candidate keyword of the plurality of candidate keywords has an expanded candidate keyword obtained by expansion, wherein when both the candidate keyword and the expanded candidate keyword appear in the second mounting information file of the second test client device, the candidate keyword is determined to exist in the second mounting information file of the second test client device; A result receiving module is configured to determine whether tag information indicating that the virtual device is installed on the client device is received; and The risk avoidance module is configured to, in response to receiving the tag information, determine that the client device is a risky device so that a function associated with the virtual device installed on the client device is disabled.

10. The device according to claim 9, wherein The device further comprises: an activation confirmation module configured to determine whether to activate the control policy in response to receiving a request to identify whether a virtual device is installed on the client device; and The activation execution module is configured to, in response to determining to activate the control strategy, instruct the library providing module to provide the preset keyword library.

11. An electronic device comprising: at least one processor; as well as a memory communicatively coupled to the at least one processor; The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method according to any one of claims 1 to 5.

12. A non-transitory computer-readable storage medium storing computer instructions, wherein: The computer instructions are used to enable a computer to execute the method according to any one of claims 1 to 5.

13. A computer program product comprising a computer program, wherein: The computer program implements the method according to any one of claims 1 to 5 when executed by a processor.

Images