CN116662993A - Lesovirus detection method, device, electronic equipment and storage medium - Google Patents

Abstract

The application provides a method, a device, electronic equipment and a storage medium for detecting the Leucavirus, wherein the method for detecting the Leucavirus comprises the following steps: acquiring a file operation request sent by a client mounted on a network file system; judging whether a request set formed by a file operation request and a history file operation request sent by a client accords with a preset condition or not, wherein the preset condition is used for representing that the lux virus implements the lux behavior on a network file system through the client; if yes, determining that the lux virus implements lux behavior on the network file system through the client. Even if the lux virus infects the client side and encrypts the real file in the network file system through an access path between the client side and the network file system, the lux virus can be timely found to invade the network file system by monitoring the behavior of the client side, the lux virus detection can be effectively carried out in the network file system, and the accuracy of the lux virus detection is improved.

Description

Lesovirus detection method, device, electronic equipment and storage medium

Technical Field

The present application relates to the field of network security technologies, and in particular, to a method and apparatus for detecting a lux virus, an electronic device, and a storage medium.

Background

The lux virus, typically entered the system through malware, then encrypts files on the system's hard disk, requiring the system user to pay the redemption to give the decryption key. In this way, the system user can decrypt the encrypted file using the decryption key, thereby normally using the system file.

At present, in order to prevent the Leucavirus from invading the system and causing the loss of the system user, the main method is as follows: and installing anti-luxury software in the system, wherein the anti-luxury software is used for deceiving luxury viruses by traversing the system folder and inserting a batch of virtual files which are not in the system hard disk, namely decoy files in real time. When the lux virus encrypts the system files, the files in the system are considered to be the files actually used by the system user, so that the real files and the decoy files in the system are encrypted indiscriminately. After the bait file is read and encrypted, the anti-lux software detects that the bait file is encrypted, so that lux viruses are found, and further the action that the lux viruses continue to encrypt the real file in the system is blocked, so that the anti-lux of the system file is realized.

However, for the network file system (Network File System, NFS), the client mounted on the system can access the files in the system through the network, so as to realize the operations of creating, modifying, deleting and the like of the files in the network file system by the client. Because the access path between the client and the network file system can directly access the real files in the system, the lux virus directly encrypts the real files in the system by infecting the client mounted on the system and by the access path between the client and the network file system. Therefore, even if the anti-lux software creates the decoy file in the system and detects whether the decoy file is encrypted, the decoy file cannot be detected to be encrypted, the lux virus cannot be found, and the accuracy of the lux virus detection is reduced.

Disclosure of Invention

The embodiment of the application aims to provide a method, a device, electronic equipment and a storage medium for detecting the Leucavirus, so as to improve the accuracy of detecting the Leucavirus.

In order to solve the technical problems, the embodiment of the application provides the following technical scheme:

the first aspect of the application provides a method for detecting the Leucavirus, which is applied to a network file system and comprises the following steps: acquiring a file operation request sent by a client mounted on the network file system; judging whether a request set formed by the file operation request and the history file operation request sent by the client accords with a preset condition or not, wherein the preset condition is used for representing that the lux virus implements the lux behavior on the network file system through the client; if yes, determining that the lux virus implements lux behavior on the network file system through the client.

In a second aspect, the present application provides a device for detecting a lux virus, the device being applied to a network file system, the device comprising: the receiving module is used for acquiring a file operation request sent by a client mounted on the network file system; the judging module is used for judging whether a request set formed by the file operation request and the history file operation request sent by the client accords with a preset condition or not, wherein the preset condition is used for representing that the lux virus implements the lux behavior on the network file system through the client; if yes, entering a determining module; and the determining module is used for determining that the lux virus implements the lux behavior on the network file system through the client.

A third aspect of the present application provides an electronic apparatus, comprising: a processor, a memory, a bus; the processor and the memory complete communication with each other through the bus; the processor is configured to invoke program instructions in the memory to perform the method of the first aspect.

A fourth aspect of the present application provides a computer-readable storage medium, the storage medium comprising: a stored program; wherein the program, when run, controls a device in which the storage medium is located to perform the method in the first aspect.

Compared with the prior art, the method for detecting the lux virus provided by the first aspect of the application judges whether the operation behavior of a file by a request set formed by the file operation request and the history file operation request sent by the client accords with the preset condition by acquiring the file operation request sent by the client mounted on the network file system, the preset condition is used for representing that the lux virus implements the lux behavior on the network file system by the client, if so, the client is proved to have unsafe operation behavior on the network file system, the client is determined to suffer from the lux virus infection, and further, the lux behavior is determined to be implemented on the network file system by the lux virus by the client. Therefore, even if the Leuch virus infects the client side and encrypts the real file in the network file system through the access path between the client side and the network file system, the Leuch virus can be timely found to invade the network file system by monitoring the behavior of the client side, leuch virus detection can be effectively carried out in the network file system, and the accuracy of Leuch virus detection is improved.

The apparatus for detecting the lux virus, the electronic device, and the computer readable storage medium provided in the second aspect of the present application have the same or similar advantages as the method for detecting the lux virus provided in the first aspect.

Drawings

The above, as well as additional purposes, features, and advantages of exemplary embodiments of the present application will become readily apparent from the following detailed description when read in conjunction with the accompanying drawings. In the drawings, wherein like or corresponding reference numerals indicate like or corresponding parts, there are shown by way of illustration, and not limitation, several embodiments of the application, in which:

FIG. 1 is a schematic diagram of a method for detecting the Leucasian virus according to an embodiment of the present application;

FIG. 2 is a flow chart of a method for detecting the Leucavirus in an embodiment of the application;

FIG. 3 is a schematic diagram showing the whole process of the method for detecting the Leucavirus in the embodiment of the application;

FIG. 4 is a schematic structural diagram of a device for detecting the Leucavirus in an embodiment of the present application;

fig. 5 is a schematic structural diagram of an electronic device according to an embodiment of the present application.

Detailed Description

Exemplary embodiments of the present application will be described in more detail below with reference to the accompanying drawings. While exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application may be embodied in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the application to those skilled in the art.

It is noted that unless otherwise indicated, technical or scientific terms used herein should be given the ordinary meaning as understood by one of ordinary skill in the art to which this application belongs.

Currently, in order to detect the lux virus, anti-lux software is generally installed in a system, a bait file is inserted into the system through the anti-lux software, whether the bait file is encrypted or not is detected, and if the bait file is encrypted, the lux virus is considered to exist in the system, so that the lux virus is cleaned. However, for the network file system NFS, the lux virus directly encrypts the real file in the system by invading the client mounted in the system, and further by the access path between the client and the system. The traditional method for detecting the Leuch virus by inserting Leuch prevention software into a bait file cannot effectively detect the Leuch virus in NFS, and reduces the accuracy of Leuch virus discovery.

The inventor finds that if the bait file is not inserted into the system, but a thinking is replaced, by detecting the behavior of the client mounted on the system, when the abnormal behavior of the client is found, the client is considered to be controlled by the Leuch virus, the Leuch virus implements the Leuch behavior on the system through the client, and the damage of the system by the Leuch virus is detected. Thus, for NFS, the Leucavirus can be effectively detected, and the accuracy of Leucavirus detection is improved.

In view of this, the embodiments of the present application provide a method, an apparatus, an electronic device, and a storage medium for detecting a lux virus, by acquiring a file operation request sent by a client mounted on a network file system, where the operation behavior of a formed request set on a file meets a preset condition, where the preset condition is used to characterize that the lux virus implements the lux behavior on the network file system through the client, and if the preset condition is met, it is indicated that the client has an unsafe operation behavior on the network file system, it is determined that the client is infected by the lux virus, and then it is determined that the lux virus implements the lux behavior on the network file system through the client. Therefore, even if the Leuch virus infects the client side and encrypts the real file in the network file system through the access path between the client side and the network file system, the Leuch virus can be timely found to invade the network file system by monitoring the behavior of the client side, leuch virus detection can be effectively carried out in the network file system, and the accuracy of Leuch virus detection is improved.

First, an architecture of the method for detecting the lux virus provided by the embodiment of the present application is described.

Fig. 1 is a schematic diagram of an architecture of a method for detecting a lux virus according to an embodiment of the present application, and referring to fig. 1, the architecture may include: a network file system and a client mounted on the network file system.

A network file system in which a number of files are stored. These files can be viewed, modified, or deleted by clients accessing the network file system. The client can also add files in the network file system.

The client side needs to be mounted on the network file system, and can access the files in the network file system through the access path between the client side and the network file system, so that the operations of checking, modifying, deleting, adding and the like of the files in the network file system are realized. In practical applications, the number of clients may be multiple, i.e. multiple clients are mounted on the network file system.

The lux virus generally infects one or a plurality of clients, and then accesses the network file system through an access path between the infected clients and the network file system, so as to encrypt files in the network file system.

In the embodiment of the application, in the network file system, by monitoring the behaviors of each client side initiated to the network file system and judging whether each client side has a lux behavior on the network file system, whether one or a plurality of client sides are infected by lux viruses can be found, so that the lux viruses are detected, and the files in the network file system are effectively protected against the lux viruses.

Next, a method for detecting the lux virus according to the embodiment of the present application will be described in detail.

Fig. 2 is a flow chart of a method for detecting the lux virus according to an embodiment of the present application, and referring to fig. 2, the method may include:

s201: and acquiring a file operation request sent by a client mounted on the network file system.

The network file system (Network File System, NFS) is the most commonly used network file system on Linux, so that an application program can access data on a server disk in a network mode at a client, and both Windows and Linux systems can be used as clients to be mounted on the NFS shared directory.

On the network file system, a plurality of clients are mounted. Each client has a dedicated access path to the network file system. And each client can check, modify, delete, add and the like the files in the network file system through the access path. Each client sends file operation requests to the network file system through the access path, and the network file system correspondingly operates the files in the file operation requests based on the file operation requests.

Here, whenever a mounted client sends a file operation request to the network file system, the network file system needs to acquire the request and analyze the request.

S202: judging whether the operation behavior of a request set formed by the file operation request and the history file operation request sent by the client on the file meets preset conditions or not. If yes, S203 is executed.

The preset conditions are used for representing that the lux virus implements lux behaviors on the network file system through the client.

In practical application, the preset condition may be the total number of files deleted by the client in the network file system, the total number of files modified by the client in the network file system, the difference between the number of files deleted by the client in the network file system and the number of files newly added, the operation behavior of deleting files by the client in the network file system, and the like. The specific content of the preset condition is only required to be capable of characterizing that the existing client side performs the luxing action on the network file system, and is not particularly limited herein.

When judging whether the preset conditions are met, not only looking at the file operation request sent by the current client, but also combining the file operation requests sent in the history time of the client. This is because: a file operation request cannot indicate that the corresponding client has a luxury behavior for the network file system. For example: the client A adds a file a in the network file system before, and discovers that a great number of errors exist in the content of the file a later, and sends a file operation request for deleting the file a to the network file system. Although the request is to delete file a in the network file system, a large number of files in the network file system are not deleted, nor are files in the network file system frequently deleted. Thus, the request is not a trade-off of the network file system, but rather a normal operation of the network file system.

In a specific judging process, the currently acquired file operation request and some file operation requests sent before the client side sending the file operation request, namely, the history file operation requests, are combined together, and then whether the operation behaviors of the history file operation requests on the files accord with preset conditions or not is checked. For example: the current acquired file operation request is a deleted file f, and deleted files a, b, c, d and e exist in the history file operation request, and the preset condition is that 5 files are deleted, so that whether the number of the deleted 6 files satisfies 5 needs to be judged.

S203: determining that the lux virus implements lux behavior on the network file system through the client.

When judging that the request set formed by the file operation request obtained currently and the history file operation request of the corresponding client accords with the preset condition, the probability that the client performs the file searching operation on the file in the network file system is high, the client can be considered to be infected by the file searching virus, and further the file searching behavior of the file searching virus on the network file system through the client is determined.

The file operation request sent by the client is also a behavior of taking the best of the system, so that the system will not perform a corresponding operation based on the request sent by the client.

When the request set formed by the file operation request obtained currently and the history file operation request of the corresponding client is judged to be not in accordance with the preset condition, the normal operation of the client on the file in the network file system is indicated, the client can be considered not to be infected by the lux virus, and further, the lux virus is determined not to implement the lux behavior on the network file system through the client.

The client may still be infected by the lux virus, and thus, the file operation request sent by the client later still needs to be judged in combination with the historical operation request.

As can be seen from the foregoing, in the method for detecting the lux virus according to the embodiment of the present application, by obtaining a file operation request sent by a client mounted on a network file system, whether an operation behavior of a file by a request set formed by the request set meets a preset condition is used to characterize the lux behavior of the lux virus implemented on the network file system by the client, if yes, it is determined that the client is infected by the lux virus, and further it is determined that the lux virus implements the lux behavior on the network file system by the client. Therefore, even if the Leuch virus infects the client side and encrypts the real file in the network file system through the access path between the client side and the network file system, the Leuch virus can be timely found to invade the network file system by monitoring the behavior of the client side, leuch virus detection can be effectively carried out in the network file system, and the accuracy of Leuch virus detection is improved.

Further, as a refinement of the above step S202, the types of the file operation requests are different, and the corresponding preset conditions are also different, and after the file operation request is obtained, the corresponding preset conditions need to be determined according to the types of the file operation requests, so as to determine whether the file operation behavior of the file by integrating the file operation request with the corresponding historical file operation request meets the preset conditions.

Specifically, the step S202 may include:

step A: when the file operation request is a deletion request, judging whether the total number of the files deleted by a request set formed by the deletion request and the history deletion request sent by the client exceeds a first preset value.

That is, if a file operation request currently sent by a client needs to delete a certain file in the network file system, in general, when the file of the system is encrypted by the luxury virus, one means is to create an encrypted file according to an original file and delete the original file, then it is necessary to obtain a history file operation request set sent by the client to the network file system during a history period, determine the number of files deleted in the network file system during the history period in the history file operation request set, add 1 to the number, and determine whether the number after adding 1 exceeds a first preset value.

The first preset value here may be determined according to the actual detection accuracy of the lux virus, and may be set smaller when it is required to detect all the lux viruses involved in the system as much as possible. When the lux virus in the system needs to be detected and more false alarms are not expected to occur, the first preset value can be set larger.

And (B) step (B): when the file operation request is a write request, judging whether the total number of files modified by a request set formed by the write request and the history write request sent by the client exceeds a second preset value.

That is, if the file operation request currently sent by a client is that a certain file in the network file system needs to be modified, generally, when the file of the system is encrypted by the luxury virus, one means is to encrypt the original file directly, then a history file operation request set sent by the client to the network file system during a history period needs to be obtained, the number of files in the network file system needs to be modified during the history period is determined in the history file operation request set, 1 is added to the number, and whether the number after 1 is added exceeds a second preset value is determined.

The second preset value here may also be determined according to the actual detection accuracy of the lux virus, and may be set smaller when it is required to detect all the lux viruses involved in the system as much as possible. When the lux virus in the system needs to be detected and more false positives are not expected to occur, the second preset value can be set larger.

Step C: when the file operation request is a renaming request, judging whether the total number of the renamed files in a request set formed by the renaming request and the history renaming request sent by the client exceeds a third preset value.

That is, if the file operation request currently sent by a client is to rename a certain file in the network file system, in general, when the file of the system is encrypted by the luxury virus, one means is to encrypt the original file and then modify the file name, or encrypt the file after modifying the file name, then it is necessary to obtain a history file operation request set sent by the client to the network file system during the history period, determine the number of files in the network file system during the history period from the history file operation request set, and add 1 to the number, and determine whether the number after adding 1 exceeds a third preset value.

The third preset value here may also be determined according to the actual detection accuracy of the lux virus, and may be set smaller when it is required to detect all the lux viruses involved in the system as much as possible. When the lux virus in the system needs to be detected and more false alarms are not expected to occur, the third preset value can be set larger.

It should be noted that, the step A, B, C needs to be used alternatively according to the specific type of the file operation request.

According to the above, according to different types of file operation requests, different preset conditions are selected for judgment, so that whether the file operation requests belong to the lux behavior can be analyzed in a targeted manner, and the accuracy of lux virus detection is improved.

Further, as a refinement of the above step A, B, C, if the file operation request sent by the client is an operation performed on a file created before the file operation request, the probability that the network file operation system is infringed by the lux virus is low, because the lux virus will not encrypt the file created by itself, and the file created by the client is not encrypted in the system, so that the file created by the non-client is targeted when the judgment is made.

Specifically, the step a may include:

step A1: and judging whether the total number of files created by the non-client side and deleted by a request set formed by the deletion request and the history deletion request sent by the client side exceeds a first preset value.

In a network file system, a client may create a file therein. Other clients than the client or system administrators, i.e., non-clients, will also create files in the system. Here, the file for counting the number is a file created in the system by a non-client. For example: the system has the files 1, 2, 3 and 4, the current acquired request for sending the file operation is the client a, which has previously created the file 1 in the system, and then the file counted at this time does not include the file 1, and only aims at the file 2, 3 and 4.

The number of files to be deleted in the deletion request sent by the client is added to the number of files to be deleted in the history deletion request of the client, and the sum of the files is required to be compared with a first preset value. If the former is large, that is, the number of files created by the deletion request and the non-client side deleted by the history deletion request sent by the client side exceeds a first preset value, the client side deletes a plurality of files which are not created by the client side in the system, and the possibility of the trade-off behavior is high. If the former is small or equal, that is, the number of files created by the non-client side deleted by the deletion request and the history deletion request sent by the client side does not exceed the first preset value, the number of files created by the client side, which are not deleted by the client side in the system, is not large, and the possibility that some normal modification is performed on the files is low, so that the possibility of the file searching behavior is low.

Specifically, the step B may include:

step B1: and judging whether the total number of files created by the non-client side modified by a request set formed by the write request and the history write request sent by the client side exceeds a second preset value.

The number of files to be modified in the modification request sent by the client is added to the number of files to be modified in the history modification request of the client, and the sum of the files is required to be compared with a second preset value. If the former is large, i.e. the number of files created by the non-client modified by the modification request and the history modification request sent by the client exceeds the second preset value, it is indicated that the client modifies a lot of files not created by the client in the system, and there is a high possibility of a trade-off behavior. If the former is small or equal, i.e. the number of files created by the non-client modified by the modification request and the history modification request sent by the client does not exceed the second preset value, it is indicated that the number of files created by the client in the system is not too large, and it is possible that some normal modification is performed on the files, so that the possibility of having a luxury behavior is low.

Specifically, the step C may include:

Step C1: and judging whether the total number of files created by the non-client terminals renamed by a request set formed by the renaming request and the history renaming request sent by the client terminals exceeds a third preset value.

The number of files to be renamed in the renaming request sent by the client at this time, and the number of files to be renamed in the historical renaming request of the client are added, and the sum of the files needs to be compared with a third preset value. If the former is large, that is, the number of files created by the renaming request and the non-client side renamed by the history renaming request sent by the client side exceeds a third preset value, the client side renames a plurality of files which are not created by the client side in the system, and the possibility of the luxury behavior is high. If the former is small or equal, i.e. the number of files created by the non-client that is renamed by the renaming request and the historical renaming request sent by the client does not exceed the third preset value, it is indicated that the number of files created by the client that is renamed by the client in the system is not large, and it is possible that some normal renaming is performed on the files, so that the possibility of having a trade-off behavior is low.

Of course, the files created by the client may also participate in the determination of the number. For example: the client creates a plurality of files in the system when suffering from the infection of the Leuch virus, and the Leuch virus encrypts the files in the system after suffering from the infection of the Leuch virus. At this time, the plurality of files may also participate in the judgment of the number of files.

According to the method, when the number of the files corresponding to the file operation request is judged, the files created by the client sending the file operation request are eliminated, so that the operation behaviors of the client can be judged more accurately, and the accuracy of the Leucstrip virus detection is improved.

Further, as an extension to the above step A1, after determining that the number of files deleted by a client in the system exceeds the first preset value, the client is not immediately determined to be infected by the lux virus, and the number of files created by the client can be combined to perform judgment again, so as to improve the accuracy of lux virus detection.

Specifically, after the step A1, the method may further include:

step A2: if so, determining the total number of files created by the history creation request sent by the client.

When determining that the number of files which are not created by the files which are deleted by the current deleting request and the historical deleting request sent by the client exceeds a first preset value, the client is indicated to delete more files in the system, if the deleted files are all created by the client, the system is not required to be considered to have a searching action, and if the deleted files are not created by the client, whether the system is required to be further confirmed to have the searching action is required to be further confirmed, namely, whether the number of files which are created by the client before is matched with the number of files deleted by the client is confirmed.

In determining the number of files that a client has previously created in the system, a file creation request may be determined from all file operation requests sent by the client to the system, and then the total number of files created may be determined from the file creation requests.

Step A3: and judging whether the total number of files created by the non-client side deleted by a request set formed by the deletion request and the history deletion request sent by the client side is smaller than a preset threshold value or not. If yes, step S203 is executed, if not, it is determined that the lux virus does not implement the lux behavior on the network file system through the client.

After obtaining the total number of files created by the client history, the difference between the total number of created files and the total number of files which the client needs to delete in the system can be calculated, and the difference of the number of files is compared with a preset threshold value. If the difference of the file numbers is smaller than a preset threshold value, the client creates a new file in the system and deletes the original file, or possibly creates a new encrypted file based on the original file by using the lux virus, and then deletes the original file, then the client can be judged to be infected by the lux virus, the lux behavior is implemented on the system, the file operation request sent by the client needs to be ignored, and the prevention is started. If the difference of the file numbers is greater than or equal to the preset threshold value, the number of new files created by the client in the system is not corresponding to the number of original files deleted, or the normal operation behavior of the system files is possible, then the client can be judged not to be infected by the lux virus, the lux behavior is not implemented on the system, and the file operation request sent by the client can be executed.

The preset threshold value can be determined according to the actually required detection accuracy of the Lecable virus. The preset threshold may be set larger when it is desired to detect as much as possible all the lux viruses involved in the system. When the Leucasian virus in the system needs to be detected and more false alarms are not expected to occur, the preset threshold value can be smaller.

As can be seen from the above description, after determining that the total number of system files deleted by the client is large, by further determining the total number of files historically created by the client, only when the total number of deleted files is approximately equal to the total number of files created, the client is determined to suffer from infection by the lux virus, so that the accuracy of detecting the lux virus can be improved.

Further, as an extension to the above step B1, after determining that the number of files modified by a certain client in the system exceeds the second preset value, the client is not immediately determined to be infected by the lux virus, and whether the names of the modified files are changed can be determined again, so as to improve the accuracy of the lux virus detection.

Specifically, after the step B1, the method may further include:

step B2: if yes, judging whether the file name of the non-client created modified by the request set formed by the write requests is changed. If yes, step S203 is executed, if not, it is determined that the lux virus does not implement the lux behavior on the network file system through the client.

When the sum of the number of files currently required to be modified and the number of files historically modified by the client exceeds a second preset value, the client is described as modifying a large number of files in the system, if only the specific content in the files is modified, the files can be considered as being modified normally, the file name is modified, and the file name is not considered as being the file name of the system, and if the file name is modified, the file name of the system can be considered as being the file name of the system, because one file name of the file of the system is encrypted by the file name of the original file, and then the file name of the original file is modified.

In determining whether a change has occurred in the file name, the first few bits of the name of the modified file may be compared with the first few bits of the name of the original file. In practical applications, the first four bits may be.

After determining that the write request modifies the file name, and adding the previously determined write request by the client to modify a large number of files, it may be determined that the client has a lux behavior with respect to the system, the client being infected with a lux virus that attacks the network file system through the client.

After determining that the file name is not modified by the write request, the fact that a large number of files are modified by the write request so far by the client determined before can be considered as the modification operation of the client on the specific content of the files normally, the client does not have a lux action on the system, the client is not infected by the lux virus, and the network file system is not infringed by the lux virus through the client.

Here, the order of determining whether the file name is changed and determining whether the number of files modified by the modification request exceeds the second preset value may be arbitrary.

According to the above, after the total number of the system files modified by the client is determined to be more, whether the file names are changed is further determined, and after the file names are determined to be changed, the client is determined to be infected by the lux virus, so that the accuracy of the lux virus detection can be improved.

Further, as an extension to the above step S202, when determining whether the operation behavior of the corresponding operation request on the file meets the preset condition, it may be determined by the number of times the corresponding operation function is called.

Specifically, before the step S202, the method may further include:

step D1: and calling a corresponding operation function according to the type of the file operation request.

Different types of file operation requests call different operation functions when modifying system files. For example: when the file operation request is of a new file type, the corresponding operation function is a creation function, namely a create function. When the type of the file operation request is deleting the file, the corresponding operation function is a deleting function, namely an unlink function. When the type of the file operation request is a modified file, the corresponding operation function is a write function, namely a write function. When the file operation request is of a type for renaming the file, the corresponding operation function is a renaming function, namely a rename function.

Step D2: and recording the action of calling the corresponding operation function in an operation cache corresponding to the corresponding operation function.

Each time an operation function is called, it is explained that a file in the system is operated correspondingly. At this time, the action of calling the operation function may be recorded in the operation buffer corresponding to the operation function, so that the number of times of calling the corresponding operation function may be directly determined from the operation buffer, and further the number of times of performing the corresponding operation by the system file may be determined.

For example, client a needs to delete file a in the system, and client a sends a delete request to the system. And after receiving the deleting request, the system calls a deleting function and deletes the file a. At this time, the function call record of the deleted file a is recorded in the delete buffer. Then, the client a needs to delete the file b in the system, and sends a delete request to the system. And after receiving the deletion request, the system calls a deletion function and deletes the file b. At this time, the function call record of the deleted file b is recorded in the delete buffer. By deleting the cache, it can be determined that client a has deleted two files in the system altogether.

Correspondingly, the step S202: judging whether the number of the behavior records which call the corresponding operation function and are stored in the corresponding operation cache exceeds the preset number.

In each type of operation cache, a call record of the corresponding operation function is stored. Each time an operation function is called, it operates on a file, and there is a record. The number of the files which are subjected to corresponding operation on the system files by the client side which sends the file operation request can be determined through the call record of the corresponding operation function, and whether the number of the files exceeds a preset condition is further judged, so that whether the modification of the client side on the system files is excessive or not is determined, namely whether a file searching behavior exists or not is determined.

Continuing with the above example, the delete cache has recorded therein a function call record for delete file a and a function call record for delete file b. By deleting the cache, it can be determined that client a has deleted both files in the system at this time. If the number of the preset files is 10, the number of the files deleted by the client A in the system does not exceed the number of the preset files, and it can be determined that the client A is not infected by the lux virus at present and the lux behavior is not implemented on the system files.

Of course, the number of files operated in the system may be directly analyzed from the file operation request, and further, the determining of the searching behavior may be performed based on the number of files.

According to the method, the number of the files operated in the system by a certain client is determined according to the calling times of the corresponding operation functions, and the number of the operated system files can be accurately counted because the operation functions are required to be called in the modification of the system files, so that the accuracy of the Leucavirus detection is improved.

Further, as an extension to the above step D1, in order to be able to count the number of times of call of the operation function, it is necessary to replace the original function in the system with a function requiring creation, deletion, writing, renaming, etc. of the counting operation.

Specifically, before the step D1, the method may include:

step D01: a virtual file system (Virtual File System, VFS) is built on the kernel mode of the network file system.

When various operation functions are inserted into the network file system, in order not to cause application to the network file system, a virtual file system may be built on the kernel mode of the network file system. The virtual file system establishes a software abstraction layer of the virtual file system between the file system on the physical storage medium and the user through the kernel. Therefore, the virtual file system calls the corresponding operation function to operate the files in the network file system, an application layer is not needed, and system call is not needed, so that the operation of the system files and the statistics of the number of file operations can be realized.

Step D02: each operating function is stored in the virtual file system.

And each operation function is used for carrying out corresponding operation on the files in the network file system through the virtual file system.

That is, the creation function, the deletion function, the write function, the rename function, and the like are stored in the virtual file system. In this way, after receiving the file operation request sent by the client, the corresponding operation function can be called in the virtual file system based on the file operation request, and the corresponding file in the network file system can be operated through the operation function. In the virtual file system, the number of times the corresponding operation function is called can be counted, so that the number of system files for executing the corresponding operation can be determined.

From the above, it can be seen that, by establishing a virtual file system in the kernel mode of the network file system and storing each operation function in the virtual file system, the number of files of the client operating system can be obtained, the application layer of the network file system can not be involved, system call can not be generated, and the influence on the network file system is small.

Further, as a refinement of the above step D02, since the virtual file system is a mirror image of the network file system, and some calling functions exist in the network file system, the calling functions are inconvenient for counting the number of files of corresponding operations, and therefore, the calling functions need to be replaced with operation functions which are convenient for performing the halving analysis.

Specifically, the step D02 may include:

step D021: a shared directory of the network file system is obtained.

By sharing the directory, the storage location of the file in the network file system can be determined, and then the file in the network file system can be found. In the network file system, there will be a shared directory through which the client finds the system file, and then performs various operations on the system file.

Step D022: and searching the original operation function in the network file system through the shared directory.

After the shared directory of the system is obtained, the address in the shared directory is opened, and the returned content is the system file structure in which the original operation function in the system exists.

Step D023: and replacing the original operation function with each operation function and storing the operation functions in the virtual file system.

After the original operation function in the system is found, the original operation function can be replaced by the operation functions of creation, deletion, writing, renaming and the like and stored in the virtual file system. In this way, the files in the network file system can be correspondingly operated through the operation functions called in the virtual file system, and the number of the system files operated through the operation functions called in the virtual file system is counted.

According to the above, the original operation function in the system can be found through the shared directory of the system, and the original operation function is replaced by each operation function which is convenient for counting the number of the operated files, so that the number of the operated files in the system can be counted.

Further, as an extension to the above step S203, after determining that the lux virus violates the network file system by a certain client, the client needs to be prevented from continuing to violate the network file system.

Specifically, after the above step S203, the method may further include:

step E1: an internet protocol (Internet Protocol, IP) address of the client is determined.

After determining that the lux virus attacks the network file system through a certain client, the IP address of the client needs to be acquired, so that the client using the IP address is prevented from continuously accessing the system, and further the lux behavior is continuously implemented on the system.

When the IP address of the client is obtained, the IP address of the client may be obtained from a file operation request sent by the client, or may be obtained from registration information of the client in the system. The specific manner in which the IP address is obtained from the client is not limited herein.

Step E2: a principal using an IP address is prohibited from accessing the network file system.

After the IP address of the client is obtained, since it is determined that the client is infected by the lux virus, the client cannot access the network file system again, and thus, the client can be prevented from continuing to access the network file system by prohibiting the client from accessing the network file system by IP. The client is not allowed to continue to access the network file system until it is determined that the client has eliminated or eliminated the lux virus infection.

The IP address may be set in iptables in the process of prohibiting the client from IP access to the network file system. The iptables are firewall application software commonly used on Linux, and can control the receiving and processing of network packets. When the client continues to send the request to the network file system, the iptables can find that the IP address is forbidden to access the system according to the IP address in the request, so that network packets such as the request of the IP address are not forwarded to the network file system, and the aim of prohibiting the client from accessing the network file system by the IP is fulfilled. Of course, the control of the transmission and reception of the network packet may be performed by other software than iptables, which is not particularly limited herein.

According to the above, the client infected by the lux virus is prevented from accessing the network file system by the IP address of the client infected by the lux virus, so that the client infected by the lux virus can be effectively prevented from continuing to implement the lux behavior on the network file system, and the security of the network file system is improved.

Finally, a complete embodiment is used to explain the method for detecting the Lecable virus provided by the embodiment of the application again.

The method mainly comprises two stages:

1. and (5) a preparation stage.

After Windows or Linux is installed on the NFS server as a client, the entire NFS shared directory can be accessed like a local disk file, and all operation instructions for the shared directory file are transmitted to the NFS shared server through a transmission control protocol (Transmission Control Protocol, TCP) protocol. The NFS driver performs corresponding operations on the file in kernel state through VFS, and then transmits file operation information to the client through TCP connection. The whole process is completed in a kernel state for the NFS shared server, and has no application layer or system call.

At this point, a driver is interposed between the NFS and VFS to monitor the behavior of the NFS operational files. In the Linux kernel, the operation behavior of a file is described by a file_operation structure, and the address pointed to by the file_operation is the same for the same file system. Therefore, when the driver is initialized, the flip_open is called to open the shared directory address, the file structure is returned, the f_op in the file structure points to the file_operation, and the driver can replace all file operation functions pointed to by the f_op with custom operation functions. Thus, when the NFS calls the VFS to operate on the file, all operations of the file can be monitored.

2. And (3) a detection stage.

By analyzing the flow of the main stream of more than 20 lux virus encrypted files, summarizing 5 scenes of the encrypted files:

scene 1, reading an original file, writing an encrypted file, and deleting the original file;

scene 2, reading an original file, writing an encrypted file, and replacing the original file;

scene 3, directly encrypting and writing the original file;

scene 4, directly encrypting and writing the original file, and then renaming;

scene 5, renaming the original file, and then encrypting.

Fig. 3 is a schematic overall process diagram of a method for detecting a lux virus according to an embodiment of the present application, and referring to fig. 3, after a file operation request sent by a client is received, the file operation request passes through a tcp/ip protocol stack, an NFS kernel driver, an anti-lux driver, and a VFS file system in sequence, so as to implement an operation of the file operation request on a file in a network file system.

In an anti-lux drive, specific anti-lux logic can be summarized as:

1. when NFS calls the create function in f_op of VFS, judging whether a file is newly built, if yes, recording the file in the create_hit buffer, if no, opening the existing file, reading the first 4 bytes of the file as file identification, and recording the file in the read_hit buffer.

2. When NFS calls an unlink function in f_op of VFS, judging whether the deleted file is in the create_hit buffer, if not, recording to the delete_hit buffer. For scene 1, judging whether the delete_hit buffer is larger than a specified threshold, if so, inquiring the create_hit buffer, acquiring the number of create files under the same path, judging whether the difference between the number of deleted files and the number of created files is smaller than a certain threshold, if so, judging that the client is a Lesovirus behavior, acquiring a corresponding IP from NFS, and adding the IP to iptables for blocking.

3. When the NFS calls a write function in the f_op of the VFS, judging whether the written file is in the create_hit buffer, if not, indicating that the written file is an existing file, and recording the written file into the write_hit buffer. For scenes 3 and 4, judging whether the write_hit is larger than a certain threshold value and whether the file header is changed (compared with the file header of the read_hit), if so, judging that the file header is a lux virus behavior, acquiring a corresponding IP from NFS, and adding the IP into iptables for blocking.

4. When NFS calls a rename function in f_op of VFS, it is determined whether a rename target is an existing file, if so, corresponding to scenario 5, recording the file into a write_hit cache, and continuing to determine a write cache threshold and a file header. And for the scene 2, when the write_hit cache reaches a certain threshold and the file head is changed, determining that the file head is in the behavior of the lux virus, acquiring the corresponding IP from the NFS, and adding the IP into the iptables for blocking. If not, reading the first 4 bytes of the file as a file identifier, and recording the file identifier into a read_hit cache.

It can be seen that the lux encryption behavior of any client to the NFS server can be protected by only installing the lux prevention driver on the NFS shared server. If the lux virus process is not started on the NFS server, but the file request behavior is initiated through a network, the lux encryption behavior is identified by analyzing and counting the behavior of the file system, and the shared directory file is protected from being encrypted by any client through lux by blocking the behavior in a network form. The method is a lower-layer scheme, and is characterized in that the method simply analyzes and counts the behavior of the encrypted file to identify the luxury encryption, so that the use of decoy files is avoided, and the disk space is saved.

Based on the same inventive concept, as an implementation of the method, the embodiment of the application also provides a device for detecting the Lecable virus. The device is applied to a network file system. Fig. 4 is a schematic structural diagram of a device for detecting the lux virus according to an embodiment of the present application, and referring to fig. 4, the device may include:

a receiving module 401, configured to obtain a file operation request sent by a client mounted on the network file system;

the judging module 402 is configured to judge whether a request set formed by the file operation request and the history file operation request sent by the client conforms to a preset condition, where the preset condition is used to characterize that the lux virus implements the lux behavior on the network file system through the client; if yes, entering a determining module;

a determining module 403, configured to determine that the lux virus implements lux behaviour on the network file system through the client.

Further, the judging module is specifically configured to judge, when the file operation request is a deletion request, whether the total number of files deleted by a request set formed by the deletion request and a history deletion request sent by the client exceeds a first preset value; or when the file operation request is a write request, judging whether the total number of files modified by a request set formed by the write request and the history write request sent by the client exceeds a second preset value; or when the file operation request is a renaming request, judging whether the total number of the renamed files in a request set formed by the renaming request and the historical renaming request sent by the client exceeds a third preset value.

Further, the judging module is specifically configured to judge whether the total number of files created by the client that are deleted by a request set formed by the deletion request and the history deletion request sent by the client exceeds a first preset value; judging whether the total number of files which are not created by the client and are modified by a request set consisting of the write request and the history write request sent by the client exceeds a second preset value or not; and judging whether the total number of files which are renamed by a request set consisting of the renaming request and the historical renaming request sent by the client and are not created by the client exceeds a third preset value or not.

Further, the judging module is further configured to determine, if yes, a total number of files created by the history creation request sent by the client; judging whether the total number of files which are deleted by a request set consisting of the deletion request and the history deletion request sent by the client and are not created by the client is smaller than a preset threshold value or not; if the number is smaller than the preset number, entering the determining module.

Further, the judging module is further configured to judge whether a file name, which is modified by the request set formed by the write request and is not created by the client, is changed if yes; if so, entering the determining module.

Further, the apparatus further comprises: the calling module is used for calling a corresponding operation function according to the type of the file operation request; recording the action of calling the corresponding operation function in an operation cache corresponding to the corresponding operation function;

the judging module is specifically configured to judge whether the number of behavior records for calling the corresponding operation function stored in the corresponding operation cache exceeds a preset number.

Further, the apparatus further comprises: the configuration module is used for establishing a virtual file system on the kernel mode of the network file system; and storing each operation function in the virtual file system, wherein each operation function is used for carrying out corresponding operation on the files in the network file system through the virtual file system.

Further, the configuration module is specifically configured to obtain a shared directory of the network file system; searching an original operation function in the network file system through the shared directory; and replacing the original operation function with each operation function and storing the operation functions in the virtual file system.

Further, the apparatus further comprises: a processing module, configured to determine an internet protocol IP address of the client; and prohibiting the body using the IP address from accessing the network file system.

It should be noted here that the description of the above device embodiments is similar to the description of the method embodiments described above, with similar advantageous effects as the method embodiments. For technical details not disclosed in the embodiments of the apparatus of the present application, please refer to the description of the embodiments of the method of the present application.

Based on the same inventive concept, the embodiment of the application also provides electronic equipment. Fig. 5 is a schematic structural diagram of an electronic device according to an embodiment of the present application, and referring to fig. 5, the electronic device may include: a processor 501, a memory 502, a bus 503; wherein, the processor 501 and the memory 502 complete the communication with each other through the bus 503; the processor 501 is operative to invoke program instructions in the memory 502 to perform the methods in one or more embodiments described above.

It should be noted here that the description of the above embodiments of the electronic device is similar to the description of the above embodiments of the method, with similar advantageous effects as the embodiments of the method. For technical details not disclosed in the embodiments of the electronic device of the present application, please refer to the description of the method embodiments of the present application for understanding.

Based on the same inventive concept, embodiments of the present application also provide a computer-readable storage medium, which may include: a stored program; wherein the program, when executed, controls a device in which the storage medium resides to perform the methods of one or more of the embodiments described above.

It should be noted here that the description of the above embodiments of the storage medium is similar to the description of the above embodiments of the method, with similar advantageous effects as the embodiments of the method. For technical details not disclosed in the storage medium embodiments of the present application, please refer to the description of the method embodiments of the present application for understanding.

The foregoing is merely illustrative of the present application, and the present application is not limited thereto, and any person skilled in the art will readily recognize that variations or substitutions are within the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims (12)

1. A method for detecting a lux virus, wherein the method is applied to a network file system, and the method comprises:

acquiring a file operation request sent by a client mounted on the network file system;

judging whether a request set formed by the file operation request and the history file operation request sent by the client accords with a preset condition or not, wherein the preset condition is used for representing that the lux virus implements the lux behavior on the network file system through the client;

If yes, determining that the lux virus implements lux behavior on the network file system through the client.

2. The method of claim 1, wherein the determining whether the file operation behavior of the request set formed by the file operation request and the history file operation request sent by the client meets a preset condition includes:

when the file operation request is a deletion request, judging whether the total number of files deleted by a request set formed by the deletion request and a history deletion request sent by the client exceeds a first preset value; or,

when the file operation request is a write request, judging whether the total number of files modified by a request set formed by the write request and the history write request sent by the client exceeds a second preset value; or,

and when the file operation request is a renaming request, judging whether the total number of renamed files in a request set formed by the renaming request and the historical renaming request sent by the client exceeds a third preset value.

3. The method according to claim 2, wherein the determining whether the total number of files deleted by the request set consisting of the deletion request and the history deletion request sent by the client exceeds a first preset value includes: judging whether the total number of files which are deleted by a request set consisting of the deletion request and the history deletion request sent by the client and are not created by the client exceeds a first preset value or not;

The determining whether the total number of files modified by a request set formed by the write request and the historical write request sent by the client exceeds a second preset value includes: judging whether the total number of files which are not created by the client and are modified by a request set consisting of the write request and the history write request sent by the client exceeds a second preset value or not;

the determining whether the total number of the renamed files in the request set formed by the renaming request and the historical renaming request sent by the client exceeds a third preset value includes: and judging whether the total number of files which are renamed by a request set consisting of the renaming request and the historical renaming request sent by the client and are not created by the client exceeds a third preset value or not.

4. The method of claim 3, wherein after determining whether the total number of files deleted by the request set of deletion requests and the historical deletion requests sent by the client that are not created by the client exceeds a first preset value, the method further comprises:

if yes, determining the total number of files created by the history creation request sent by the client;

Judging whether the total number of files which are deleted by a request set consisting of the deletion request and the history deletion request sent by the client and are not created by the client is smaller than a preset threshold value or not;

if the number of the groups is smaller than the number of the groups, then the step of determining that the lux virus performs lux actions on the network file system through the client is performed.

5. The method of claim 3, wherein after determining whether the total number of files not created by the client that are modified by the set of write requests and the historical write requests sent by the client exceeds a second preset value, the method further comprises:

if yes, judging whether the file name which is modified by the request set formed by the write requests and is not created by the client is changed or not;

if so, executing the step of determining that the lux virus implements lux behavior on the network file system through the client.

6. The method according to any one of claims 1 to 5, wherein before determining whether the file operation behavior of the request set formed by the file operation request and the history file operation request sent by the client meets a preset condition, the method further comprises:

Calling a corresponding operation function according to the type of the file operation request;

recording the action of calling the corresponding operation function in an operation cache corresponding to the corresponding operation function;

the judging whether the operation behavior of the request set formed by the file operation request and the history file operation request sent by the client on the file meets the preset condition comprises the following steps:

judging whether the number of the behavior records which call the corresponding operation function and are stored in the corresponding operation cache exceeds the preset number.

7. The method of claim 6, wherein before invoking the corresponding operation function according to the type of file operation request, the method further comprises:

establishing a virtual file system on the kernel mode of the network file system;

and storing each operation function in the virtual file system, wherein each operation function is used for carrying out corresponding operation on the files in the network file system through the virtual file system.

8. The method of claim 7, wherein storing the operating functions in the virtual file system comprises:

acquiring a shared directory of the network file system;

Searching an original operation function in the network file system through the shared directory;

and replacing the original operation function with each operation function and storing the operation functions in the virtual file system.

9. The method according to any one of claims 1 to 5, wherein after determining that the network file system is infringed by the lux virus through the client, the method further comprises:

determining an Internet Protocol (IP) address of the client;

and prohibiting the body using the IP address from accessing the network file system.

10. A device for detecting a lux virus, the device being applied to a network file system, the device comprising:

the receiving module is used for acquiring a file operation request sent by a client mounted on the network file system;

the judging module is used for judging whether a request set formed by the file operation request and the history file operation request sent by the client accords with a preset condition or not, wherein the preset condition is used for representing that the lux virus implements the lux behavior on the network file system through the client; if yes, entering a determining module;

And the determining module is used for determining that the lux virus implements the lux behavior on the network file system through the client.

11. An electronic device, the electronic device comprising: a processor, a memory, a bus; the processor and the memory complete communication with each other through the bus; the processor is configured to invoke program instructions in the memory to perform the method of any of claims 1 to 9.

12. A computer-readable storage medium, the storage medium comprising: a stored program; wherein the program, when run, controls a device in which the storage medium is located to perform the method of any one of claims 1 to 9.