CN117978509A

CN117978509A - Compressed file detection defense method, device and processing equipment

Info

Publication number: CN117978509A
Application number: CN202410188035.6A
Authority: CN
Inventors: 马征
Original assignee: Beijing Abt Networks Co ltd
Current assignee: Beijing Abt Networks Co ltd
Priority date: 2024-02-20
Filing date: 2024-02-20
Publication date: 2024-05-03

Abstract

The application provides a detection defense method, a device and processing equipment for a compressed file, which are used for bypassing the content of the compressed file by introducing an ip address blacklist mechanism, so that the decompression bomb can be conveniently and effectively detected, and the lightweight decompression bomb defense effect is realized. The application provides a detection defense method of a compressed file, which comprises the following steps: the processing equipment acquires an ip address of a sender of the compressed file; the processing equipment matches the ip address of the sender of the compressed file with a pre-configured ip address blacklist on the processing equipment, wherein the ip address blacklist describes the ip address for detecting the historical uploading behavior of the decompressed bomb or the ip address for judging that the uploading behavior of the decompressed bomb exists; if the ip address of the sender of the compressed file is in the ip address blacklist, the processing device blocks transmission of the compressed file and blocks access of the sender.

Description

Compressed file detection defense method, device and processing equipment

Technical Field

The application relates to the field of network security, in particular to a method and a device for detecting and defending compressed files and processing equipment.

Background

Decompression bombs are specially designed compressed files (compressed files with the number of decompressed files, the size of the files or the compression ratio being greater than a corresponding threshold value), which are complex in structure and contain a large amount of repeated data, and during the compression process, the repeated data can be effectively removed, so that the volume of the file is significantly reduced. However, once a compressed file (or compressed package) such as a decompressed bomb is decompressed, the file volume will increase instantaneously, even reaching the PB level, which definitely places a huge burden on memory resources and CPU computing resources, possibly resulting in downtime of the server.

Therefore, the decompression bomb needs to be effectively detected and defended, network attacks taking the decompression bomb as an attack path are prevented, and the safety of the server is ensured.

The present inventors have found that the existing decompression bomb defense strategy deployed on the server involves the reading and analysis of the compressed file, which is time-consuming, and also requires memory resources and CPU computing resources, if a large number of compressed files are faced at the same time, the server may lose response due to excessive resource overhead.

Disclosure of Invention

The application provides a detection defense method, a device and processing equipment for a compressed file, which are used for bypassing the content of the compressed file by introducing an ip address blacklist mechanism, so that the decompression bomb can be conveniently and effectively detected, and the lightweight decompression bomb defense effect is realized.

In a first aspect, the present application provides a method for detecting and defending a compressed file, where the method includes:

The processing equipment acquires an ip address of a sender of the compressed file;

The processing equipment matches the ip address of the sender of the compressed file with a pre-configured ip address blacklist on the processing equipment, wherein the ip address blacklist describes the ip address for detecting the historical uploading behavior of the decompressed bomb or the ip address for judging that the uploading behavior of the decompressed bomb exists;

if the ip address of the sender of the compressed file is in the ip address blacklist, the processing device blocks transmission of the compressed file and blocks access of the sender.

With reference to the first aspect of the present application, in a first possible implementation manner of the first aspect of the present application, the method further includes:

If the ip address of the sender of the compressed file is not in the ip address blacklist, the processing equipment calculates a hash value of the compressed file through a hash algorithm;

the processing equipment matches the hash value of the compressed file with a hash value blacklist which is pre-configured on the processing equipment, wherein the hash value blacklist describes the hash value calculated by the compressed file which is determined to be the decompression bomb;

If the hash value of the compressed file is in the hash value blacklist, the processing device updates the ip address of the sender of the compressed file into the ip address blacklist, blocks transmission of the compressed file, and blocks access of the sender.

With reference to the first possible implementation manner of the first aspect of the present application, in a second possible implementation manner of the first aspect of the present application, the method further includes:

If the hash value of the compressed file is not in the hash value blacklist, the processing equipment detects the number of decompressed files, the file size and the compression ratio of the compressed file through a CDD-VLD algorithm, and detects whether viruses exist in the compressed file or not;

If at least one of the number of files, the size of the files and the compression ratio of the decompressed compressed files is larger than the corresponding threshold value, or if viruses exist in the compressed files, the processing device updates the ip address of the sender of the compressed files into the ip address blacklist, updates the hash value of the compressed files into the hash value blacklist, blocks transmission of the compressed files and blocks access of the sender.

With reference to the second possible implementation manner of the first aspect of the present application, in a third possible implementation manner of the first aspect of the present application, before the processing device matches the hash value of the compressed file with a hash value blacklist configured in advance on the processing device, the method further includes:

the processing equipment matches the hash value of the compressed file with a hash value white list which is pre-configured on the processing equipment, wherein the hash value white list describes the hash value calculated by the compressed file which is determined not to be the decompression bomb;

If the hash value of the compressed file is not in the hash value white list, the processing equipment triggers the hash value of the compressed file to be matched with a hash value black list pre-configured on the processing equipment;

If any one of the number of files, the size of the files and the compression ratio of the decompressed compressed files is smaller than the corresponding threshold value, or if the compressed files have no virus, the processing equipment updates the hash value of the compressed files into a hash value white list.

With reference to the third possible implementation manner of the first aspect of the present application, in a fourth possible implementation manner of the first aspect of the present application, before the processing device matches an ip address of a sender of the compressed file with a pre-configured ip address blacklist on the processing device, the method further includes:

the processing equipment matches the ip address of the sender of the compressed file with a pre-configured ip address white list on the processing equipment, wherein the ip address white list describes the ip address of the sender which is determined not to be the decompression bomb;

if the ip address of the sender of the compressed file is not in the ip address blacklist, the processing device triggers matching of the ip address of the sender of the compressed file with the ip address blacklist pre-configured on the processing device.

With reference to the fifth possible implementation manner of the first aspect of the present application, in a first possible implementation manner of the first aspect of the present application, the processing device obtains an ip address of a sender of the compressed file, including:

Before receiving a compressed file, the processing equipment acquires an ip address of a sender of the compressed file;

if the ip address of the sender is not in the ip address blacklist, the processing device calculates a hash value of the compressed file through a hash algorithm, including:

if the ip address of the sender is not in the ip address blacklist, the processing equipment receives the compressed file;

The processing device calculates a hash value of the compressed file by a hash algorithm.

With reference to the first aspect of the present application, in a sixth possible implementation manner of the first aspect of the present application, the processing device is specifically a server device, and the sender is specifically a client on the user side.

In a second aspect, the present application provides a detection defense device for compressed files, where the device includes:

an acquisition unit configured to acquire an ip address of a sender of the compressed file;

The matching unit is used for matching the ip address of the sender of the compressed file with a pre-configured ip address blacklist on the processing equipment, wherein the ip address blacklist describes the ip address for detecting the historical uploading behavior of the decompressed bomb or the ip address for judging that the uploading behavior of the decompressed bomb exists;

And the blocking unit is used for blocking the transmission of the compressed file and blocking the access of the sender if the ip address of the sender of the compressed file is in the ip address blacklist.

With reference to the second aspect of the present application, in a first possible implementation manner of the second aspect of the present application, the matching unit is further configured to:

If the ip address of the sender of the compressed file is not in the ip address blacklist, calculating a hash value of the compressed file through a hash algorithm;

Matching the hash value of the compressed file with a hash value blacklist pre-configured on the processing device, wherein the hash value blacklist describes the hash value calculated by the compressed file determined to be the decompression bomb;

if the hash value of the compressed file is in the hash value blacklist, triggering an updating unit to update the ip address of the sender of the compressed file into the ip address blacklist, and triggering a blocking unit to block transmission of the compressed file and block access of the sender.

With reference to the first possible implementation manner of the second aspect of the present application, in a second possible implementation manner of the second aspect of the present application, the apparatus further includes a detection unit, configured to:

if the hash value of the compressed file is not in the hash value blacklist, detecting the number of decompressed files, the file size and the compression ratio of the compressed file through a CDD-VLD algorithm, and detecting whether viruses exist in the compressed file or not;

if at least one of the number of the decompressed compressed files, the size of the files and the compression ratio is greater than a corresponding threshold, or if viruses exist in the compressed files, the updating unit is triggered to update the ip address of the sender of the compressed files into the ip address blacklist, the hash value of the compressed files is updated into the hash value blacklist, and the blocking unit is triggered to block transmission of the compressed files and block access of the sender.

With reference to the second possible implementation manner of the second aspect of the present application, in three possible implementation manners of the second aspect of the present application, the matching unit is further configured to:

matching the hash value of the compressed file with a hash value white list pre-configured on the processing device, wherein the hash value white list describes hash values calculated by the compressed file which is determined not to be a decompression bomb;

if the hash value of the compressed file is not in the hash value white list, triggering to match the hash value of the compressed file with a hash value black list pre-configured on the processing equipment;

If any one of the number of the decompressed compressed files, the size of the files and the compression ratio is smaller than the corresponding threshold value, or if the compressed files have no virus, triggering an updating unit to update the hash value of the compressed files into a hash value white list.

With reference to the third possible implementation manner of the second aspect of the present application, in a fourth possible implementation manner of the second aspect of the present application, the matching unit is further configured to:

Matching an ip address of a sender of the compressed file with a pre-configured ip address white list on the processing device, wherein the ip address white list describes an ip address of the sender determined not to be a decompressed bomb;

If the ip address of the sender of the compressed file is not in the ip address blacklist, triggering to match the ip address of the sender of the compressed file with the ip address blacklist pre-configured on the processing device.

With reference to the fifth possible implementation manner of the second aspect of the present application, in a first possible implementation manner of the second aspect of the present application, the obtaining unit is specifically configured to:

Before receiving a compressed file, acquiring an ip address of a sender of the compressed file;

the matching unit is specifically used for:

If the ip address of the sender is not in the ip address blacklist, receiving the compressed file;

and calculating the hash value of the compressed file through a hash algorithm.

With reference to the second aspect of the present application, in a sixth possible implementation manner of the second aspect of the present application, the processing device is specifically a server device, and the sender is specifically a client on the user side.

In a third aspect, the present application provides a processing device comprising a processor and a memory in which a computer program is stored, the processor executing the method of the first aspect of the present application or any one of the possible implementations of the first aspect of the present application when calling the computer program in the memory.

In a fourth aspect, the present application provides a computer readable storage medium having stored thereon a plurality of instructions adapted to be loaded by a processor to perform the method of the first aspect of the present application or any of the possible implementations of the first aspect of the present application.

From the above, the present application has the following advantages:

For the defending target of the decompression bomb, after the processing equipment acquires the ip address of the sender of the compressed file, the ip address of the sender of the compressed file is matched with the ip address blacklist pre-configured on the processing equipment, the ip address blacklist describes the ip address for detecting the historical uploading behavior of the decompression bomb or judges that the ip address of the uploading behavior of the decompression bomb exists, if the ip address of the sender of the compressed file is in the ip address blacklist, the transmission of the compressed file can be blocked, and the access of the sender can be blocked, so that the ip address blacklist mechanism is introduced, the file content of the compressed file is not required to be read and analyzed as in the prior art, the content of the compressed file can be bypassed, the decompression bomb can be conveniently and effectively detected, and the defending effect of the lightweight decompression bomb is realized.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are needed in the description of the embodiments will be briefly described below, it being obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a schematic flow chart of a method for detecting and defending a compressed file according to the present application;

FIG. 2 is a schematic diagram of a detecting and defending device for compressed files according to the present application;

FIG. 3 is a schematic view of a construction of the treatment apparatus of the present application.

Detailed Description

The following description of the embodiments of the present application will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present application, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to fall within the scope of the application.

The terms first, second and the like in the description and in the claims and in the above-described figures, are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that the embodiments described herein may be implemented in other sequences than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or modules is not necessarily limited to those steps or modules that are expressly listed or inherent to such process, method, article, or apparatus. The naming or numbering of the steps in the present application does not mean that the steps in the method flow must be executed according to the time/logic sequence indicated by the naming or numbering, and the execution sequence of the steps in the flow that are named or numbered may be changed according to the technical purpose to be achieved, so long as the same or similar technical effects can be achieved.

The division of the modules in the present application is a logical division, and may be implemented in another manner in practical applications, for example, a plurality of modules may be combined or integrated in another system, or some features may be omitted or not implemented, and further, coupling or direct coupling or communication connection between the modules shown or discussed may be through some interfaces, and indirect coupling or communication connection between the modules may be electrical or other similar manners, which are not limited in the present application. The modules or sub-modules described as separate components may be physically separated or not, or may be distributed in a plurality of circuit modules, and some or all of the modules may be selected according to actual needs to achieve the purpose of the present application.

Before introducing the detection defense method of the compressed file provided by the application, the background content related to the application is first introduced.

The detection defense method and device for the compressed file and the computer readable storage medium provided by the application can be applied to processing equipment, and are used for bypassing the content of the compressed file by introducing the ip address blacklist mechanism, so that the decompressed bomb can be conveniently and effectively detected, and the lightweight decompressed bomb defense effect is realized.

In the method for detecting and defending the compressed file, the execution body of the method can be a detecting and defending device of the compressed file or different types of processing Equipment such as a server, a physical host or User Equipment (UE) integrated with the detecting and defending device of the compressed file. The compressed file detection defense device can be implemented in a hardware or software mode, the UE can be specifically a terminal device such as a smart phone, a tablet computer, a notebook computer, a desktop computer or a Personal digital assistant (Personal DIGITAL ASSISTANT, PDA), and the processing device can be set in a device cluster mode.

It will be appreciated that the problem of defence against a decompression bomb is usually the problem faced by the server, but it should also be understood that other types of devices may face the problem besides the server, and therefore, the processing device executing the detection defence method of the compressed file of the present application, or the processing device carrying the application service of the detection defence method of the compressed file of the present application, may be in practical application, but may also be a different type of processing device such as a physical host or UE.

As an example, the processing device of the present application may be a server device, and the sender of the compressed file may be a client on the user side (for example, a client accessed based on a web service/browser), which can be understood that a specific application scenario where the scheme of the present application is located is defined herein, that is, an application scenario where a user uploads the compressed file to a server, where the server device located at a cloud location may be in a situation where a large number of users upload the compressed file under a service requirement inside a company or under an external service requirement of the company, so that a more important convenience application requirement exists for defending a decompressed bomb.

Next, the method for detecting and defending the compressed file provided by the application is introduced.

First, referring to fig. 1, fig. 1 shows a flow chart of a method for detecting and defending a compressed file according to the present application, and the method for detecting and defending a compressed file provided by the present application specifically includes steps S101 to S103 as follows:

Step S101, processing equipment obtains an ip address of a sender of a compressed file;

it will be appreciated that when the processing device receives the compressed file, in consideration of the defence/security problem of the decompression bomb, the processing device may trigger corresponding response processing to follow a preset defence policy of the decompression bomb to detect whether the currently received compressed file is the decompression bomb.

In the application, the response processing of the current compressed file expansion does not read and analyze the file content, but acquires the ip address of the sender.

It will be appreciated that the compressed file is transferred locally to the processing device, and is thus transferred in such a way that the source ip address (sender's ip address) is extracted from the data header of the data packet during its transfer for processing.

Specifically, the process of acquiring the ip address of the sender of the compressed file may be, in addition to easily and conveniently extracting the source ip address from the data header of the data packet corresponding to the compressed file in real time as the ip address of the sender, or may be, from a work log (e.g., a work log that specifically records the file transfer work) or another file in which the ip address of the sender of the compressed file is recorded, conveniently and directly extract the ip address of the sender.

Step S102, the processing equipment matches the ip address of the sender of the compressed file with a pre-configured ip address blacklist on the processing equipment, wherein the ip address blacklist describes the ip address for detecting the historical uploading behavior of the decompressed bomb or the ip address for judging that the uploading behavior of the decompressed bomb exists;

It can be understood that, for the defending objective of the decompression bomb, the application configures an ip address blacklist mechanism, and the ip address blacklist is combined with the application scene where the application is located, is a blacklist formed by the ip addresses with the uploading behaviors of the decompression bomb, and in specific operation, the ip addresses recorded in the blacklist are either the ip addresses with the history uploading behaviors of the decompression bomb already detected or the ip addresses with the single uploading behaviors determined to exist (whether the history uploading behaviors of the decompression bomb are detected or not, and the single uploading behaviors of the decompression bomb are directly defaulted).

Under the condition that the ip address blacklist is configured, the ip address of the sender of the current compressed file can be matched with the ip address recorded in the ip address blacklist, if so, the condition that the current compressed file is possibly a decompressed bomb is obviously indicated, so that the current compressed file can be identified as the decompressed bomb, and a targeted defending response is carried out through a subsequent step S103, so that reading and analyzing of file content of the compressed file are not needed as in the prior art, the content of the compressed file can be bypassed, and the decompressed bomb can be conveniently and effectively detected, thereby realizing a lightweight decompressed bomb defending effect.

In step S103, if the ip address of the sender of the compressed file is in the ip address blacklist, the processing device blocks transmission of the compressed file and blocks access of the sender.

It can be understood that after determining that the ip address of the sender of the compressed file belongs to the ip address alerted by the ip address blacklist in the previous step S102, the defensive response may be expanded for the current compressed file, so that, on one hand, transmission of the compressed file may be blocked, for example, discarding/deleting the compressed file, and on the other hand, the sender of the compressed file may be considered as an attacker, and further access may be blocked, thereby achieving the security defensive effect.

The detection of the decompressed bomb by the ip address can bring the following three advantages:

1) The detection of the decompression bomb is realized on the basis of not decompressing, system resources are occupied less, and the efficiency is obviously improved;

2) Malicious attacks can be prevented, compressed files containing malicious codes can possibly attack equipment maliciously during decompression, such as stealing user information, destroying system files and the like, and the files are detected and intercepted through ip addresses, so that the situation can be prevented;

3) The attack generated by the same ip address is defended pertinently, and the reliability of the service is improved.

In short, as can be seen from the embodiment shown in fig. 1, for the defending target of the decompression bomb, after the processing device obtains the ip address of the sender of the compressed file, the ip address of the sender of the compressed file is matched with the ip address blacklist pre-configured on the processing device, the ip address blacklist describes the ip address of the history uploading behavior of the decompression bomb detected or the ip address judged to exist the uploading behavior of the decompression bomb, if the ip address of the sender of the compressed file is in the ip address blacklist, the transmission of the compressed file can be blocked, and the access of the sender can be blocked, so that the file content of the compressed file is not required to be read and analyzed as in the prior art, the content of the compressed file can be bypassed, and the decompression bomb can be effectively detected conveniently, thereby realizing the light-weight defending effect of the decompression bomb.

The steps of the embodiment shown in fig. 1 and the possible implementation thereof in practical applications will be described in detail.

Corresponding to the case that the ip address of the sender of the compressed file may occur in the previous step S102 is not in the ip address blacklist, when the highly suspected decompressed bomb of the compressed file is not detected by the ip address, it may be considered that the file content of the current compressed file is read and analyzed as in the prior art, and whether the decompressed bomb is detected starting from the file content.

In this regard, as an exemplary embodiment, after step S102, the method of the present application may further include:

It will be appreciated that the hash values calculated by the hash algorithm for different files are necessarily different, and that the decompression bomb as an attack means is generally reusable, so that it can be determined whether the current compressed file is a decompression bomb that has occurred by the hash value.

And for the hash value of the existing decompression bomb, the hash value can be recorded through a hash value blacklist, so that when the reading analysis of the current compressed file exists, the matching processing of the hash value can be conveniently expanded to determine whether the current compressed file is the decompression bomb.

The hash algorithm adopted by the hash value calculation processing can be specifically a hash algorithm of MD5, SHA-1, SHA-256 or SHA-512, etc., and it can be understood that the hash algorithm adopted by the present application is generally an algorithm used in the market, and the present application does not improve and optimize the algorithm content of the hash algorithm, so that detailed description is omitted here.

In addition, it will be appreciated that, in a specific operation, the hash value blacklist referred to herein may be combined with the ip address blacklist that has been previously presented in the same file, for example, integrated in the same table file, so as to further promote convenience in application.

Corresponding to the analysis based on the hash value, under the condition that the sender (ip address) of the compressed file is determined to be unrecorded, the sender (ip address) of the compressed file can be recorded, a black list of the ip address which appears before is updated, and if the compressed file with the same ip address is encountered later, safety response can be conveniently carried out.

It will be appreciated that although the hash value is related to the file contents of the compressed file, it is essentially only a set of numbers that characterize the file contents to determine whether the compressed file is a decompressed bomb that has occurred, and that particular file contents are not of deep concern, and that in particular operations, it will be apparent that a more deep read analysis may be performed on the compressed file, starting with particular file contents, to determine whether the file content characteristics of the decompressed bomb exist, to more accurately determine whether the current compressed file is a decompressed bomb.

In the process, decompression processing of the compressed file can be involved, and the number and the size of the decompressed file are obtained in a decompression mode, which means that a CPU is required to calculate and judge, and CPU resources are occupied; meanwhile, the decompression process also requires a memory to store the decompressed file, which means that memory resources are occupied; in addition, the decompressed file needs to be stored on the hard disk, so that hard disk resources are occupied; decompressing a file or folder also requires the system to allocate temporary space to store decompressed content, which can also result in slow hard disk read-write speeds because of the need to constantly read and write data; meanwhile, when a large number of files are decompressed, the use amount of the memory is increased, and the system may be slow or other problems may occur.

Thus, when a large number of compressed files are faced, the prior art problem that the processing equipment is down and loses response due to excessive resource occupation is also existed.

In this way, when the two-layer decompression bomb detection mechanism is used or the decompression bomb is not checked, the application can process the deep file content characteristics of the decompression bomb as a bottom measure in the scheme of the application, and although more processing and more time-consuming conditions exist for the individual decompression bomb objectively than the prior art, the problem is allowable because the time-consuming increase is not much, and the identification efficiency of the decompression bomb can be obviously improved and the identification cost of the decompression bomb can be obviously reduced from the aspect of the whole.

Correspondingly, as a further exemplary embodiment, the method of the present application may further comprise:

Wherein CDD-VLD, central directory detection-Virus library detection, central directory test virus library test.

The CDD-VLD algorithm mainly involves two processes, firstly, using a threshold as a determination condition, determining whether the compressed file is a decompression bomb according to the number of decompressed files, the size of the files and the content characteristics (number) of the files in the compression ratio, where a case corresponds, that is, the central directory (central directory) is an important component in the format of the compressed file, which is located at the end of the compressed file and is the last entry, which contains all information about metadata of each file in the compressed file, such as file name, original size, compression method and other information, on the basis of which the total size of the file before compression can be calculated, and the compression ratio, the number of files and the like can be calculated; and secondly, determining whether the compressed file is a decompression bomb or not by matching file content characteristics recorded by a ClamAv virus library.

It will be appreciated that the CDD-VLD algorithm and its application, the present application is not specifically optimized and modified, and is within the scope of the prior art, and therefore the present application is not specifically described herein.

Corresponding to deep decompression bomb analysis based on CDD-VLD algorithm, if it is determined that the compressed file is an unrecorded decompression bomb, the decompression bomb can be recorded, a previously-appearing ip address blacklist and hash value blacklist are updated, and if the compressed file with the same ip address or the same hash value is encountered later, safety response can be conveniently carried out.

Meanwhile, the hash value blacklist setting method and the hash value blacklist setting device can be configured with hash value blacklist setting in specific operation, so that the hash value blacklist setting purpose is opposite to that of hash value blacklist setting, after the hash value recorded by the hash value blacklist is encountered, the corresponding compressed file can be directly confirmed not to be a decompression bomb, and therefore, for the compressed file with key or high frequency, efficient and convenient filtering effect can be achieved.

And this may also be used in a nested manner with the setting of the hash value blacklist, and correspondingly, as a further exemplary embodiment, before the processing device matches the hash value of the compressed file with the hash value blacklist pre-configured on the processing device, the method of the present application may further include:

It can be seen that, similar to the dynamic updating maintenance of the hash value blacklist, the compressed file of the non-decompressed bomb can be confirmed through the deep decompressed bomb analysis of the CDD-VLD algorithm, and the hash value of the compressed file is updated into the hash value whitelist, so that the dynamic updating maintenance of the hash value whitelist is facilitated.

Furthermore, for the ip address blacklist mechanism introduced by the application, the application can also continuously introduce the ip address whitelist mechanism as described above, so that the compressed file sent by the specific equipment with high security can be directly released based on the ip address recorded by the ip address whitelist, thereby playing the effect of convenient release.

Thus, as a further exemplary embodiment of the present application, before the processing device matches the ip address of the sender of the compressed file with a pre-configured ip address blacklist on the processing device, the method may further include:

Likewise, embodiments herein may also relate to dynamic update maintenance of ip address whitelists based on deep decompression bomb analysis of the CDD-VLD algorithm.

In addition, for the above ip address blacklist setting, in a specific operation, the present application may further be configured with a detection threshold in number, so as to form a dual-layer processing architecture with a certain fault tolerance, and specifically includes:

In the current detection time period (adjustable time period), if the accumulated number of times that the ip address of the current compressed file appears in the ip address blacklist is greater than a detection threshold, the operation of the ip address blacklist can be formally triggered to block, otherwise, if the accumulated number of times is smaller than the detection threshold, attention/observation can be performed, and according to the situation that the ip address of the sender of the compressed file is not in the ip address blacklist, the detection processing based on the hash value is continuously expanded, and the detection processing of the decompressed bomb is continuously performed as in the above embodiment.

Therefore, the decompression bomb defense mechanism based on the ip address blacklist can be further promoted, and better flexibility can be obtained in detail, so that a small amount of misjudgment can be further avoided in practical application.

For the ip address white list, the application can be configured directly (usually manually) without autonomous updating and maintenance along with the detection of the compressed file, thus avoiding the situation that the ip address of an attacker is continuously released due to misjudgment of autonomous updating and maintenance and ensuring the network security in detail.

In addition, it can be understood that for the detection process of whether the compressed file is a decompression bomb, the detection process is usually performed after the compressed file is received, and the background corresponding to the detection process is that the detection process is performed after the compressed file is decompressed, and by default, the detection process is performed after the compressed file is decompressed, while the decompression bomb defense mechanism based on the ip address of the present application can be performed before the compressed file is received, because the file content of the compressed file is irrelevant, and the decompression process on the compressed file is not required.

In this regard, as yet another exemplary embodiment, the step S101 of the present application, the processing device obtaining the ip address of the sender of the compressed file may specifically include:

correspondingly, if the ip address of the sender is not in the ip address blacklist, the processing device calculates a hash value of the compressed file through a hash algorithm, including:

It is easy to see that in this embodiment, since the decompressed bombs in the ip address blacklist may be filtered out based on the ip address during the initiation of the receiving process of the compressed file or during the receiving process of the compressed file, in this case, under the condition that the decompressed bombs are detected conveniently, a series of running costs of the system involved in the compressed file transmission procedure may be significantly reduced, so as to achieve a better lightweight application scheme effect.

The compressed file detection defense method provided by the application is introduced, and in order to better implement the compressed file detection defense method provided by the application, the application also provides a compressed file detection defense device from the angle of a functional module.

Referring to fig. 2, fig. 2 is a schematic structural diagram of a compressed file detection defense device according to the present application, and in the present application, a compressed file detection defense device 200 may specifically include the following structure:

an acquisition unit 201 for acquiring an ip address of a sender of the compressed file;

A matching unit 202, configured to match an ip address of a sender of the compressed file with a pre-configured ip address blacklist on the processing device, where the ip address blacklist describes an ip address where a history upload behavior of the decompressed bomb is detected or an ip address where the upload behavior of the decompressed bomb is determined to exist;

And the blocking unit 203 is configured to block transmission of the compressed file and block access of the sender if the ip address of the sender of the compressed file is in the ip address blacklist.

In an exemplary embodiment, the matching unit 202 is further configured to:

If the hash value of the compressed file is in the hash value blacklist, the trigger updating unit 204 updates the ip address of the sender of the compressed file into the ip address blacklist, and the trigger blocking unit 203 blocks the transmission of the compressed file and blocks the access of the sender.

In a further exemplary embodiment, the apparatus further comprises a detection unit 205 for:

If at least one of the number of files, the size of the files and the compression ratio of the decompressed compressed files is greater than the corresponding threshold, or if there is a virus in the compressed files, the trigger updating unit 204 updates the ip address of the sender of the compressed files into the ip address blacklist, updates the hash value of the compressed files into the hash value blacklist, and the trigger blocking unit 203 blocks transmission of the compressed files and blocks access of the sender.

In yet another exemplary embodiment, the matching unit 202 is further configured to:

If any one of the number of decompressed files, the size of the files and the compression ratio is smaller than the corresponding threshold, or if the compressed files have no virus, the updating unit 204 is triggered to update the hash value of the compressed files into the hash value white list.

In yet another exemplary embodiment, the obtaining unit 201 is specifically configured to:

the matching unit 202 is specifically configured to:

and calculating the hash value of the compressed file through a hash algorithm.

In a further exemplary embodiment, the processing device is embodied as a server device and the sender is embodied as a user-side client.

The present application also provides a processing device from the perspective of hardware structure, referring to fig. 3, fig. 3 shows a schematic structural diagram of the processing device of the present application, specifically, the processing device of the present application may include a processor 301, a memory 302, and an input/output device 303, where the processor 301 is configured to implement steps of a compressed file detection defense method in the corresponding embodiment of fig. 1 when executing a computer program stored in the memory 302; or the processor 301 is configured to implement the functions of each unit in the corresponding embodiment of fig. 2 when executing the computer program stored in the memory 302, and the memory 302 is configured to store the computer program required for executing the compressed file detection defense method in the corresponding embodiment of fig. 1 by the processor 301.

By way of example, a computer program may be partitioned into one or more modules/units that are stored in the memory 302 and executed by the processor 301 to accomplish the present application. One or more of the modules/units may be a series of computer program instruction segments capable of performing particular functions to describe the execution of the computer program in a computer device.

The processing devices may include, but are not limited to, a processor 301, a memory 302, and an input output device 303. It will be appreciated by those skilled in the art that the illustrations are merely examples of processing devices, and are not limiting of processing devices, and may include more or fewer components than shown, or may combine some components, or different components, e.g., processing devices may also include network access devices, buses, etc., through which processor 301, memory 302, input output device 303, etc., are connected.

The Processor 301 may be a central processing unit (Central Processing Unit, CPU), but may also be other general purpose processors, digital signal processors (DIGITAL SIGNAL Processor, DSP), application SPECIFIC INTEGRATED Circuit (ASIC), field-Programmable gate array (Field-Programmable GATE ARRAY, FPGA) or other Programmable logic device, discrete gate or transistor logic device, discrete hardware components, or the like. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like, which is a control center for a processing device, with various interfaces and lines connecting the various parts of the overall device.

The memory 302 may be used to store computer programs and/or modules, and the processor 301 implements various functions of the computer device by running or executing the computer programs and/or modules stored in the memory 302 and invoking data stored in the memory 302. The memory 302 may mainly include a storage program area and a storage data area, wherein the storage program area may store an operating system, application programs required for at least one function, and the like; the storage data area may store data created according to the use of the processing device, or the like. In addition, the memory may include high-speed random access memory, and may also include non-volatile memory, such as a hard disk, memory, plug-in hard disk, smart memory card (SMART MEDIA CARD, SMC), secure Digital (SD) card, flash memory card (FLASH CARD), at least one disk storage device, flash memory device, or other volatile solid-state storage device.

The processor 301 is configured to execute the computer program stored in the memory 302, and may specifically implement the following functions:

It will be clearly understood by those skilled in the art that, for convenience and brevity of description, the specific working process of the detection defense device, the processing device and the corresponding units of the compressed file described above may refer to the description of the detection defense method of the compressed file in the corresponding embodiment of fig. 1, and will not be described herein in detail.

Those of ordinary skill in the art will appreciate that all or a portion of the steps of the various methods of the above embodiments may be performed by instructions, or by instructions controlling associated hardware, which may be stored in a computer-readable storage medium and loaded and executed by a processor.

For this reason, the present application provides a computer readable storage medium, in which a plurality of instructions capable of being loaded by a processor are stored, so as to execute the steps of the method for detecting and defending a compressed file in the corresponding embodiment of fig. 1, and the specific operation may refer to the description of the method for detecting and defending a compressed file in the corresponding embodiment of fig. 1, which is not repeated herein.

Wherein the computer-readable storage medium may comprise: read Only Memory (ROM), random access Memory (Random Access Memory, RAM), magnetic or optical disk, and the like.

Because the instructions stored in the computer readable storage medium may execute the steps of the method for detecting and defending a compressed file according to the corresponding embodiment of fig. 1, the method for detecting and defending a compressed file according to the corresponding embodiment of fig. 1 may achieve the beneficial effects of the method for detecting and defending a compressed file according to the corresponding embodiment of fig. 1, which are described in detail in the foregoing description and are not repeated herein.

The above detailed description of the method, the device, the processing equipment and the computer readable storage medium for detecting and defending the compressed file applies specific examples to illustrate the principle and the implementation of the application, and the description of the above examples is only used for helping to understand the method and the core idea of the application; meanwhile, as those skilled in the art will have variations in the specific embodiments and application scope in light of the ideas of the present application, the present description should not be construed as limiting the present application.

Claims

1. A method for detecting and defending a compressed file, the method comprising:

The processing equipment matches an ip address of a sender of the compressed file with an ip address blacklist pre-configured on the processing equipment, wherein the ip address blacklist describes an ip address for detecting the historical uploading behavior of the decompressed bomb or an ip address for judging that the uploading behavior of the decompressed bomb exists;

2. The method according to claim 1, wherein the method further comprises:

if the ip address of the sender of the compressed file is not in the ip address blacklist, the processing device calculates a hash value of the compressed file through a hash algorithm;

The processing equipment matches the hash value of the compressed file with a hash value blacklist which is pre-configured on the processing equipment, wherein the hash value blacklist describes the hash value calculated by the compressed file which is determined to be a decompression bomb;

3. The method according to claim 2, wherein the method further comprises:

If at least one of the number of files, the size of the files and the compression ratio of the decompressed compressed files is greater than a corresponding threshold value, or if the compressed files have viruses, the processing device updates the ip address of the sender of the compressed files into the ip address blacklist, updates the hash value of the compressed files into the hash value blacklist, blocks transmission of the compressed files, and blocks access of the sender.

4. The method of claim 3, wherein prior to the processing device matching the hash value of the compressed file with a pre-configured hash value blacklist on the processing device, the method further comprises:

The processing device matches the hash value of the compressed file with a hash value white list pre-configured on the processing device, wherein the hash value white list describes hash values calculated for the compressed file determined not to be a decompressed bomb;

If the hash value of the compressed file is not in the hash value white list, the processing equipment triggers the hash value of the compressed file to be matched with the hash value black list pre-configured on the processing equipment;

If any one of the number of decompressed files, the size of the files and the compression ratio is smaller than a corresponding threshold value, or if the compressed files have no virus, the processing device updates the hash value of the compressed files to the hash value white list.

5. The method of claim 4, wherein before the processing device matches the ip address of the sender of the compressed file with a pre-configured blacklist of ip addresses on the processing device, the method further comprises:

The processing equipment matches the ip address of the sender of the compressed file with a pre-configured ip address white list on the processing equipment, wherein the ip address white list describes the ip address of the sender which is determined not to be a decompression bomb;

and if the ip address of the sender of the compressed file is not in the ip address white list, triggering the processing equipment to match the ip address of the sender of the compressed file with the ip address black list pre-configured on the processing equipment.

6. The method according to claim 2, wherein the processing device obtaining the ip address of the sender of the compressed file comprises:

the processing equipment acquires an ip address of a sender of the compressed file before receiving the compressed file;

If the ip address of the sender is not in the ip address blacklist, the processing device receives the compressed file;

The processing device calculates a hash value of the compressed file through the hash algorithm.

7. The method according to claim 1, wherein the processing device is in particular a server device and the sender is in particular a user-side client.

8. A compressed file detection defense device, the device comprising:

9. A processing device comprising a processor and a memory, the memory having stored therein a computer program, the processor executing the method of any of claims 1 to 7 when invoking the computer program in the memory.

10. A computer readable storage medium storing a plurality of instructions adapted to be loaded by a processor to perform the method of any one of claims 1 to 7.