Risk protection methods, systems, equipment and storage media for network services

Abstract

This application discloses a method, system, device, and storage medium for risk protection of network services, applied in the field of network security technology. The method includes: when a specified type of executable file is newly created in the background files of a network service, storing the file path of the executable file in a first record space; when a call to a target function is detected to match a set call condition, determining whether the file path of the executable file calling the target function matches any file path stored in the first record space; if so, obtaining the command-line parameters used when calling the target function and comparing the command-line parameters with preset sensitive files to obtain a risk assessment result; and performing risk protection operations on the executable file calling the target function based on the risk assessment result. Applying the solution of this application can effectively achieve risk protection of network services, improve the accuracy and reliability of detection, and does not affect performance.

Description

Technical Field

[0001] This invention relates to the field of network security technology, and in particular to a method, system, device, and storage medium for risk protection of network services. Background Technology

[0002] With the rapid development of information technology, network services are widely used. Network services serve as a window for information exchange with the outside world. Because network services expose ports, they face various security risks, including injection attacks, cross-site scripting (XSS), cross-site request forgery (XPS), and authentication vulnerabilities. A webshell (web backdoor) is a script or program that runs on a web server, allowing for remote control and management of the server. It provides functions such as command execution, file management, and database operations, enabling users to remotely execute arbitrary commands and manage files and databases through a web interface. However, hackers also frequently use webshells to illegally intrude into and control servers, leading to data leaks and other security problems.

[0003] Current detection methods primarily include static analysis, traffic detection, and behavioral analysis. Static analysis involves capturing code execution snippets and comparing them with a Webshell knowledge base to identify intrusions. Traffic detection involves monitoring web traffic data at the network level and analyzing specific traffic flows to identify Webshell intrusion behaviors. Behavioral analysis involves building behavioral models by analyzing function call relationships and comparing them with normal behavioral models to identify Webshell intrusion behaviors.

[0004] However, after code obfuscation, current static analysis and traffic detection are prone to failure, while behavioral analysis can impact the performance of user applications and degrade the user experience. Furthermore, all of the above solutions are for detecting intrusion behavior and do not possess interception or protection capabilities.

[0005] In summary, how to effectively protect network services from risks, improve the accuracy and reliability of detection, and not affect performance is a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0006] The purpose of this invention is to provide a method, system, device, and storage medium for risk protection of network services, so as to effectively realize risk protection of network services, improve the accuracy and reliability of detection, and not affect performance.

[0007] To solve the above-mentioned technical problems, the present invention provides the following technical solution:

[0008] In a first aspect, the present invention provides a method for risk protection of network services, comprising:

[0009] When a new executable file of a specified type is detected in the background files of a network service, the file path of the executable file is stored in the first record space;

[0010] When a call to the target function is detected to match the set call conditions, it is determined whether the file path of the executable file that calls the target function matches any file path stored in the first record space.

[0011] If so, obtain the command-line arguments used when calling the target function, and compare the command-line arguments with preset sensitive files to obtain the risk assessment result;

[0012] Based on the risk assessment results, risk protection operations are performed on the executable file that calls the target function.

[0013] On the other hand, when it is detected that a new executable file of a specified type has been created in the background files of a network service, the file path of the executable file is stored in the first record space, including:

[0014] A first probe program for monitoring file creation operations is pre-mounted;

[0015] When the first probe program determines that a specified type of executable file has been created in the background file of the network service, the file path of the executable file is stored in the first record space.

[0016] On the other hand, when it is determined, based on the first probe program, that a specified type of executable file has been newly created in the background file of the network service, the file path of the executable file is stored in the first record space, including:

[0017] Obtain the path of the network service to be monitored and store it in the second record space;

[0018] The executable file type to be monitored is obtained and stored in the third record space;

[0019] When a file creation operation is detected based on the first probe program, it is determined whether the file path corresponding to the file creation operation belongs to the range of any network service path stored in the second record space.

[0020] If it falls within the range of any network service path stored in the second record space, then determine whether the file type corresponding to the file creation operation matches any executable file type stored in the third record space.

[0021] If so, the file created by the file creation operation is determined to be an executable file of the specified type, and the file path of the executable file is stored in the first record space.

[0022] On the other hand, the path of the network service to be monitored is obtained and stored in the second record space, including:

[0023] The first selection instruction determines each network service pointed to by the first selection instruction;

[0024] Each network service pointed to by the first selection instruction is taken as the network service to be monitored, the path of each network service to be monitored is obtained, and they are all stored in the second record space;

[0025] The executable file types to be monitored are obtained and stored in a third record space, including:

[0026] The second selection instruction determines each executable file type pointed to by the second selection instruction;

[0027] Each executable file type pointed to by the second selection instruction is treated as an executable file type to be monitored and stored in the third record space.

[0028] On the other hand, when a call to the target function is detected to conform to a set call condition, it is determined whether the file path of the executable file calling the target function matches any file path stored in the first record space, including:

[0029] A second probe program for monitoring calls to the target function is pre-mounted;

[0030] When the target function is called by an executable file of a specified type based on the second probe program, it is determined that the call to the target function conforms to the set call conditions;

[0031] Determine whether the file path of the executable file that calls the target function matches any file path stored in the first record space.

[0032] On the other hand, it also includes: determining each function pointed to by the third selection instruction through the third selection instruction, and using each of them as the target function to be monitored;

[0033] A second probe program for monitoring calls to the target function is pre-mounted, including;

[0034] For each target function to be monitored, a second probe program for monitoring the calls to the target function is pre-attached.

[0035] On the other hand, the command-line parameters are compared with preset sensitive files to obtain a risk assessment result, including:

[0036] Determine whether at least one of the command-line parameters matches a preset sensitive file;

[0037] If so, the risk assessment result is that there is a risk;

[0038] If not, the risk assessment result is that there is no risk.

[0039] On the other hand, it also includes:

[0040] After determining that each parameter in the command line parameters does not match the preset sensitive file, it is determined whether there is at least one parameter in the command line parameters that matches the preset pending file.

[0041] If so, the resulting risk assessment is "risk pending".

[0042] If not, the risk assessment result is that there is no risk.

[0043] On the other hand, the sensitive files include: a first sensitive file related to the act of stealing or tampering with user information, a second sensitive file related to the act of stealing or tampering with user login credential information, a third sensitive file related to the act of tampering with user permission configuration, and a fourth sensitive file related to the act of tampering with login authentication configuration.

[0044] On the other hand, based on the risk assessment results, risk protection operations are performed on the executable file that calls the target function, including:

[0045] When the risk assessment result indicates that there is a risk, the process to which the executable file that calls the target function belongs is determined, and the process number of the process is recorded.

[0046] Based on the process ID, each current process chain is matched. When it is determined that any process chain contains a process with the same process ID, the process chain is blocked.

[0047] On the other hand, based on the process ID, each current process chain is matched, and when it is determined that any process chain contains a process with the same process ID, the process chain is blocked, including:

[0048] For each current process chain, a recursive search is performed to compare the process ID of each process in the process chain with the process ID of the process to which the executable file that calls the target function belongs.

[0049] If, among the process IDs of all processes in the process chain, there is a process ID that matches the process ID of the executable file that calls the target function, then the process chain is blocked.

[0050] On the other hand, it also includes:

[0051] After blocking the process chain, the executable file that calls the target function will be deleted.

[0052] Secondly, the present invention provides a network service risk protection system, comprising:

[0053] A new file monitoring module is used to store the file path of the executable file in the first record space when a new executable file of a specified type is detected in the background files of the network service.

[0054] The function call monitoring module is used to determine whether the file path of the executable file that calls the target function matches any file path stored in the first record space when a call to the target function is detected to meet the set call conditions; if so, the risk judgment module is triggered.

[0055] The risk assessment module is used to obtain the command-line parameters used when calling the target function, and compare the command-line parameters with preset sensitive files to obtain the risk assessment result;

[0056] The risk protection module is used to perform risk protection operations on the executable file that calls the target function based on the risk assessment result.

[0057] Thirdly, the present invention provides a network service risk protection device, comprising:

[0058] Memory, used to store computer programs;

[0059] A processor for executing the computer program to implement the risk protection method for network services as described above.

[0060] Fourthly, the present invention provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the risk protection method for network services as described above.

[0061] Applying the technical solution provided by the embodiments of this invention, considering that even if malicious code is obfuscated, current intrusion behaviors typically involve creating a new executable file of a specific type in the background files of a network service, and there are calls to specific functions, this application's solution, upon detecting the creation of a new executable file of a specific type in the background files of a network service, stores the file path of the executable file in a first record space for subsequent reference. Subsequent monitoring of target function calls is performed, and to reduce the probability of false positives, only when a target function call is detected to match a set call pattern, indicating a risk, will the file path of the executable file calling the target function be further checked against any file path stored in the first record space. If they match, it indicates that the executable file calling the target function may be risky, and that the executable file is a previously created executable file of the specified type in the background files of the network service. Furthermore, to further ensure accuracy, it is also necessary to obtain the command-line parameters used when calling the target function and compare the command-line parameters with preset sensitive files to obtain a risk assessment result. Furthermore, the solution in this application can perform risk protection operations on the executable file that calls the target function based on the risk assessment results. In other words, if a risk is determined to exist based on the risk assessment results, the risk can be blocked through risk protection operations to prevent intrusion from damaging network services. In addition, the risk protection method of this application is not easily invalidated and does not affect performance.

[0062] In summary, the proposed solution can effectively protect network services from risks, improve the accuracy and reliability of detection, and does not affect performance. Attached Figure Description

[0063] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0064] Figure 1 A flowchart illustrating the implementation of a network service risk protection method according to a specific embodiment of the present invention;

[0065] Figure 2 A schematic diagram of the structure of a network service risk protection system provided in a specific embodiment of the present invention;

[0066] Figure 3 A schematic diagram of the structure of a network service risk protection device provided in a specific embodiment of the present invention;

[0067] Figure 4 This is a schematic diagram of the structure of a computer-readable storage medium according to the present invention. Detailed Implementation

[0068] The core of this invention is to provide a method, system, device, and storage medium for risk protection of network services, which can effectively protect network services from risks, improve the accuracy and reliability of detection, and not affect performance.

[0069] To enable those skilled in the art to better understand the present invention, the invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0070] Please refer to Figure 1 , Figure 1 This is a flowchart illustrating an implementation of a network service risk protection method according to a specific embodiment of the present invention. The network service risk protection method may include the following steps:

[0071] Step S101: When a new executable file of a specified type is detected in the background file of the network service, the file path of the executable file is stored in the first record space.

[0072] Traditional static analysis and traffic detection schemes are prone to failure because obfuscation of malicious code cannot guarantee detection accuracy. This application addresses this issue by recognizing that even with obfuscation, malicious code typically creates a new executable file of a specific type in the background files of a network service, and certain functions are called. Therefore, in this application, when a new executable file of a specific type is detected in the background files of a network service, the file path of the executable file is stored in the first record space.

[0073] Network services, also known as web services, can be monitored in various ways by creating new files in the background. For example, monitoring can be implemented using a probe program. The monitored network services can include one or more network services, and for a specified type of executable file, it can include one or more specified types of executable files.

[0074] In one specific embodiment of the present invention, step S101 may specifically include:

[0075] A first probe program for monitoring file creation operations is pre-mounted;

[0076] When the first probe program determines that a specified type of executable file has been created in the background file of the network service, the file path of the executable file is stored in the first record space.

[0077] In this implementation, a first probe program for monitoring file creation operations is pre-mounted. For example, in a specific scenario, considering that eBPF (Extended Berkeley Packet Filter) is a highly efficient security technology running in the Linux kernel, allowing user-space programs to execute in the kernel as bytecode, eBPF programs can be widely used in areas such as network packet filtering, system call tracing, performance monitoring, and security auditing. Therefore, the kprobes probe of eBPF can be used as the first probe program in this application's solution to monitor file creation operations.

[0078] When pre-mounting the first probe program, taking the eBPF kprobes probe as an example, the eBPF program can be mounted on the file creation operation in the Linux kernel space based on the eBPF kprobe technology, so that the kprobes probe can monitor the file creation operation. The specific mount point can be, for example, SEC(kprobe / create).

[0079] Because a first probe program for monitoring file creation operations is pre-mounted, if a file is created in the background file of a network service, it can be detected by the first probe program. This allows it to determine whether the newly created file is an executable file of a specified type created in the background file of the network service, and thus decides whether to store the file path in the first record space. The first record space can be any storage space capable of storing file paths. For example, in a specific scenario, when a specified type of executable file is detected to have been created in the background file of a network service, the file path of the executable file is stored in eBPF map C.

[0080] In one specific embodiment of the present invention, when it is determined, based on the first probe program, that a new executable file of a specified type has been created in the background file of the network service, storing the file path of the executable file in the first record space may specifically include:

[0081] Step 1: Obtain the path of the network service to be monitored and store it in the second record space;

[0082] Step 2: Obtain the executable file type to be monitored and store it in the third record space;

[0083] Step 3: When a file creation operation is detected by the first probe program, determine whether the file path corresponding to the file creation operation falls within the path range of any network service stored in the second record space. If it falls within the path range of any network service stored in the second record space, proceed to Step 4.

[0084] Step 4: Determine if the file type corresponding to the file creation operation matches any executable file type stored in the third record space; if so, proceed to Step 5.

[0085] Step 5: Determine that the file created by the file creation operation is an executable file of the specified type, and store the file path of the executable file in the first record space.

[0086] This implementation takes into account that since different network services have their own paths, it is necessary to first obtain the path of the network service to be monitored and store it in the second record space. For example, the path of the network service to be monitored can be specifically stored in eBPF's map A. Furthermore, it should be noted that the network service to be monitored in this application can be a single network service or multiple network services. For example, in one specific implementation, step one above can specifically include: determining each network service pointed to by the first selection instruction through a first selection instruction; taking each network service pointed to by the first selection instruction as the network service to be monitored, obtaining the path of each network service to be monitored, and storing them in the second record space.

[0087] This implementation takes into account that each network service pointed to by the first selection instruction can be determined through the first selection instruction. For example, staff can pre-determine which network services need risk protection, and then set these network services as network services to be monitored through the first selection instruction. After determining each network service to be monitored, the path of each network service to be monitored can be stored in the second record space. For example, if the path of a network service to be monitored is " / opt / webapp", then " / opt / webapp" can be stored in eBPF map A, which is the second record space described here.

[0088] Furthermore, since only specific file types pose a risk, it is necessary to obtain the executable file types to be monitored and store them in the third recording space. Each executable file type to be monitored can also be pre-defined by staff. For example, in one specific embodiment of the present invention, step two above may specifically include: determining each executable file type pointed to by the second selection instruction through the second selection instruction; and storing each executable file type pointed to by the second selection instruction as the executable file type to be monitored in the third recording space.

[0089] This implementation takes into account that each executable file type pointed to by the second selection instruction can be determined through the second selection instruction. For example, staff can pre-determine which executable file types are risky, and then set these executable file types as the executable file types to be monitored through the second selection instruction. Then, the executable file types to be monitored can be stored in the third record space. For example, if a specific executable file type to be monitored is PHP, then "PHP" can be stored in eBPF's map B, that is, stored in the third record space.

[0090] Because a first probe program for monitoring file creation operations is pre-mounted, every file creation operation can be monitored based on this first probe program. Whenever a file creation operation is detected, the file path corresponding to this operation can be compared with the contents of the second record space to determine whether the file path belongs to the range of any network service path stored in the second record space. For example, in the example above, a network service path is " / opt / webapp" and is stored in the second record space. If, during a file creation operation, the file path of the created file is " / opt / webapp / XXX", where XXX represents the name of the created file, then by parsing the input parameter `path` of the `create` function using the kprobes probe and extracting the prefix of `path`, the file path of the created file can be obtained. This path can then be compared with the paths stored in the second record space to determine that the file path " / opt / webapp / XXX" corresponding to this file creation operation belongs to the range of the path " / opt / webapp" stored in the second record space. Therefore, step four needs to be executed. Understandably, if the result of step three above indicates that the file path corresponding to the file creation operation does not fall within the range of any network service path stored in the second record space, then there is no need to execute the subsequent steps.

[0091] When performing step four above, it is necessary to determine whether the file type corresponding to this file creation operation matches any executable file type stored in the third record space. For example, in the example above, the file path of the created file is " / opt / webapp / XXX", and if the file type is further obtained from the file name as PHP, it can be compared with the contents in the third record space. In this example, it can be determined that the file type PHP matches an executable file type stored in the third record space, that is, the third record space stores the executable file type PHP. Therefore, step five needs to be triggered; otherwise, subsequent steps are unnecessary.

[0092] When step five is triggered, it can be determined that the file created in this file creation operation is an executable file of a specified type, and its file path belongs to the path range of a network service to be detected. Therefore, this executable file may pose a risk, and the file path of the executable file needs to be stored in the first record space. For example, the file path " / opt / webapp / XXX" in the above example is stored in the first record space, which means storing the absolute file path (also known as the full path) of the executable file in the first record space.

[0093] Step S102: When a call to the target function is detected to match the set call conditions, determine whether the file path of the executable file calling the target function matches any file path stored in the first record space. If so, proceed to step S103.

[0094] In this application, the calls to the target function need to be monitored. If a call to the target function matches a predefined call pattern, further judgment is required. Monitoring the calls to the target function can typically be achieved using a probe program. Furthermore, the specific rules for determining whether a call matches the predefined call pattern can be set according to actual needs; however, it is understood that the predefined call pattern should reflect situations where the current call carries a certain degree of risk.

[0095] For example, in one specific embodiment of the present invention, step S102 may specifically include:

[0096] A second probe program for monitoring calls to the target function is pre-mounted;

[0097] When the second probe program detects that an executable file of a specified type is calling the target function, it determines that the call to the target function conforms to the set call conditions.

[0098] Determine whether the file path of the executable file that calls the target function matches any file path stored in the first record space.

[0099] In this implementation, a second probe program that can be used to monitor calls to the target function is pre-mounted. For example, in one specific scenario, the uprobes probe of eBPF can be used as the second probe program of this application to monitor calls to the target function.

[0100] When pre-mounting a second probe program, taking the eBPF uprobes probe as an example, a mount point can be set at the target function in the user-space application based on eBPF kprobe technology. This allows the uprobes probe to monitor calls to the target function. The target function can include one or more functions, and is usually specified by the user.

[0101] For example, in one specific embodiment of the present invention, it may further include: determining each function pointed to by the third selection instruction through a third selection instruction, and designating each of them as a target function to be monitored. Correspondingly, pre-loading a second probe program for monitoring the calls of the target functions may specifically include: pre-loading a second probe program for monitoring the calls of the target functions for each target function to be monitored. In this embodiment, the operator can select the functions to be monitored through the third selection instruction, designating each as a target function to be monitored, and then for each target function to be monitored, a second probe program for monitoring the calls of the target functions can be loaded.

[0102] After a second probe program for monitoring calls to the target function is pre-mounted, in this implementation, the call monitoring of the target function can be performed based on the second probe program. If it is detected that an executable file of a specified type is calling the target function, then it can be determined that the call of the target function conforms to the set call conditions.

[0103] In other words, in this implementation, not all calls to the target function conform to the set call conditions. Only when an executable file of a specified type calls the target function will the call be determined to conform to the set call conditions, thus reducing the probability of false positives. Furthermore, the specified type described in this implementation can include one or more types, and is usually consistent with the specified type in step S101.

[0104] For example, in one scenario, considering that webshells often use PHP's `system` function (a system function that executes system commands) to intrude into the operating system, the `system` function would be included in the target functions to be monitored. Taking eBPF's uprobes probe as an example, if the specified type includes PHP, an uprobes probe can be mounted on ` / usr / bin / php:system`. If a PHP executable calls the `system` function, the uprobes probe will be triggered. This indicates that a specified type of executable has been detected calling the target function, thus confirming that the call matches the set call criteria. It is then necessary to obtain the file path of the executable that called the target function to determine if the file path matches any file path stored in the first record space.

[0105] Step S103: Obtain the command-line arguments used when calling the target function, and compare the command-line arguments with the preset sensitive files to obtain the risk assessment result.

[0106] If the file path of the executable file that calls the target function obtained in step S102 matches any file path stored in the first record space, it indicates that the executable file that calls the target function this time is a specified type of executable file that was previously created in the background file of the monitored network service, which poses a security risk. However, in order to avoid misjudgment, this application solution will further obtain the risk assessment result through sensitive files.

[0107] Specifically, it is necessary to obtain the command-line arguments used when calling the target function, and then compare them with the preset sensitive files to obtain the risk assessment result.

[0108] The specific content of sensitive files can be set and adjusted according to actual needs, and may include one or more sensitive files. For example, in one specific embodiment of the present invention, the sensitive files may include: a first sensitive file related to the act of stealing or tampering with user information, a second sensitive file related to the act of stealing or tampering with user login credential information, a third sensitive file related to the act of tampering with user permission configuration, and a fourth sensitive file related to the act of tampering with login authentication configuration.

[0109] This implementation method provides a comprehensive list of sensitive files, effectively reflecting intrusions at different levels. In other words, if the executable file calling the target function exhibits intrusive behavior, the command-line arguments used will typically match the aforementioned sensitive files, minimizing the likelihood of omissions. Table 1 below illustrates the sensitive files in a specific implementation method: the first sensitive file is / etc / passwd, the second is / etc / shadow, the third is / etc / sudoers, and the fourth includes / etc / pam.conf and / etc / security / pwquality.conf.

[0110] Table 1. List of Sensitive Documents

[0111]

[0112] It is understood that in other implementations, sensitive documents may include other content, which can be set and adjusted according to actual needs.

[0113] In one specific embodiment of the present invention, comparing command-line parameters with preset sensitive files to obtain a risk assessment result may include:

[0114] Determine whether at least one of the command-line arguments matches a preset sensitive file.

[0115] If so, the risk assessment result is that there is a risk;

[0116] If not, the risk assessment result is that there is no risk.

[0117] In this implementation, each parameter in the command-line arguments needs to be compared with a preset set of sensitive files. If at least one parameter matches a preset sensitive file, that is, if at least one parameter is consistent with a sensitive file within the preset set of sensitive files, then a risk is determined to exist; otherwise, no risk is determined to exist. This implementation method can obtain the risk assessment result through simple comparison, without the need for complex analysis, thus facilitating the implementation of the solution.

[0118] Furthermore, in one specific embodiment of the present invention, it may also include:

[0119] After determining that each parameter in the command line arguments does not match the preset sensitive file, it is then determined whether at least one parameter in the command line arguments matches the preset pending file.

[0120] If so, the resulting risk assessment is "risk pending".

[0121] If not, the risk assessment result is that there is no risk.

[0122] This implementation takes into account that some types of files are not as sensitive as the aforementioned sensitive files, but there is still a low degree of risk when operating on these files. Therefore, this implementation also sets up pending files. Similar to sensitive files, the pending files preset in this implementation can include one or more pending files. The specific files used as pending files in this implementation can be set according to actual needs.

[0123] After determining that each parameter in the command-line arguments does not match the preset sensitive file, this implementation also needs to determine whether at least one parameter in the command-line arguments matches the preset pending file. If none match, the risk assessment result is determined to be no risk; otherwise, the risk assessment result is pending risk. In practical applications, different levels of response operations can be adopted for the two risk assessment results of pending risk and existing risk. For example, when the risk assessment result is existing risk, actions can be taken to directly block the intrusion behavior of the relevant executable file. If the risk is pending, for example, staff can be reminded to check, or other methods can be combined for further evaluation, or the number of times the executable file triggers the pending risk can be counted. If it is too frequent, it is directly regarded as existing risk.

[0124] Step S104: Based on the risk assessment results, perform risk protection operations on the executable file that calls the target function.

[0125] After obtaining the risk assessment result, risk protection operations can be performed on the executable file that calls the target function. For example, if the risk assessment result is that there is no risk, the risk protection operation is no operation, while if the risk assessment result is that there is a risk, the risk protection operation specifically blocks the intrusion behavior of the corresponding executable file.

[0126] In one specific embodiment of the present invention, step S104 may include:

[0127] When the risk assessment result indicates that there is a risk, determine the process to which the executable file that calls the target function belongs, and record the process ID of the process;

[0128] Based on the process ID, each process chain is matched. When it is determined that any process chain contains a process with the same process ID, that process chain is blocked.

[0129] This implementation takes into account that when the risk assessment result indicates the existence of a risk, it is necessary to determine the process to which the executable file calling the target function belongs, and then record the process ID (PID). Subsequently, based on this PID, each process chain needs to be matched. This is because the process may be currently executing or may have already completed execution, triggering corresponding child processes; therefore, matching each process chain is necessary. If a process chain contains a process with the same PID, that process chain will be directly blocked to ensure the reliability of the network server and effectively prevent intrusion.

[0130] When matching process chains, recursive search can usually be used. Specifically, in one embodiment of this invention, each process chain is matched based on its process ID. When any process chain is found to contain a process with the same process ID, the process chain is blocked. This can specifically include:

[0131] Recursively search each process chain to compare the process ID of each process in the chain with the process ID of the executable file that calls the target function.

[0132] If one of the process IDs in the process chain matches the process ID of the executable file that calls the target function, then the process chain is blocked.

[0133] Once the risk assessment result indicates that there is a risk, and the process to which the executable file calling the target function belongs is determined, the PID of that process can be recorded in the eBPF map D, for example.

[0134] Taking a process chain as an example, during recursive search, the first step is to obtain the current process information of the chain. For instance, in one implementation, eBPF programs can be mounted in Linux kernel-mode file operations based on eBPF's LSM technology to block intrusion attempts. A specific mount point could be SEC (lsm / file_open). The current process information can be obtained through the kernel-mode process data structure `task_struct`. If the current process's PID matches a PID in eBPF map D, the process chain can be blocked. If not, the parent process information needs to be obtained through `task_struct` to determine if the parent process's PID matches a PID in eBPF map D. If it does, the process chain can be blocked. Otherwise, the recursive search continues until the source process of the process chain is found, indicating that each process in the chain has been checked. If the PID of a process in a process chain matches eBPF map D, the process chain can be blocked using eBPF's LSM technology.

[0135] As can be seen, by recursively searching each process chain, it is possible to effectively determine whether each process chain contains a process with the same process number as the process to which the executable file that calls the target function belongs. This effectively ensures the reliability of the solution, achieves effective risk protection for network services, and prevents malicious programs from further damaging the system.

[0136] In one specific embodiment of the present invention, the method may further include: deleting the executable file that calls the target function after blocking the process chain. This embodiment takes into account that after blocking the process chain, the corresponding file can be further processed, that is, the executable file that calls the target function can be directly deleted, thereby achieving the purpose of automatically removing malicious files.

[0137] Furthermore, in one specific embodiment of the present invention, the method may further include: after blocking the process chain and deleting the executable file that calls the target function, determining the IP address that sent the executable file or guided the generation of the executable file, and recording it in a suspicious IP list. This embodiment takes into account that after blocking the process chain and deleting the executable file that calls the target function, malicious files are automatically removed. However, further tracing is possible. That is, if the executable file originates from file content sent by a device and is newly created in the background file of a network service, the IP address of that device can be directly recorded in the suspicious IP list. Similarly, if the executable file is not directly sent by a device, but is newly created in the background file of a network service under the guidance of a device (e.g., the device creates the executable file in the background file of the network service through communication with the network service), the IP address of that device can also be recorded in the suspicious IP list. The suspicious IP list can assist in risk protection. For example, during traffic analysis, traffic analysis can be assisted based on the suspicious IP list, giving it special attention.

[0138] Applying the technical solution provided by the embodiments of this invention, considering that even if malicious code is obfuscated, current intrusion behaviors typically involve creating a new executable file of a specific type in the background files of a network service, and there are calls to specific functions, this application's solution, upon detecting the creation of a new executable file of a specific type in the background files of a network service, stores the file path of the executable file in a first record space for subsequent reference. Subsequent monitoring of target function calls is performed, and to reduce the probability of false positives, only when a target function call is detected to match a set call pattern, indicating a risk, will the file path of the executable file calling the target function be further checked against any file path stored in the first record space. If they match, it indicates that the executable file calling the target function may be risky, and that the executable file is a previously created executable file of the specified type in the background files of the network service. Furthermore, to further ensure accuracy, it is also necessary to obtain the command-line parameters used when calling the target function and compare the command-line parameters with preset sensitive files to obtain a risk assessment result. Furthermore, the solution in this application can perform risk protection operations on the executable file that calls the target function based on the risk assessment results. In other words, if a risk is determined to exist based on the risk assessment results, the risk can be blocked through risk protection operations to prevent intrusion from damaging network services. In addition, the risk protection method of this application is not easily invalidated and does not affect performance.

[0139] In summary, the proposed solution can effectively protect network services from risks, improve the accuracy and reliability of detection, and does not affect performance.

[0140] Corresponding to the above method embodiments, this invention also provides a network service risk protection system, which can be referred to in conjunction with the above.

[0141] See Figure 2 The diagram shown is a structural schematic of a network service risk protection system according to the present invention, comprising:

[0142] The new file monitoring module 201 is used to store the file path of the executable file in the first record space when a new executable file of a specified type is detected in the background file of the network service.

[0143] The function call monitoring module 202 is used to determine whether the file path of the executable file that calls the target function matches any file path stored in the first record space when the target function call is detected to meet the set call conditions; if so, the risk judgment module is triggered.

[0144] The risk assessment module 203 is used to obtain the command-line parameters used when calling the target function, and compare the command-line parameters with preset sensitive files to obtain the risk assessment result;

[0145] Risk protection module 204 is used to perform risk protection operations on executable files that call target functions based on risk assessment results.

[0146] In one specific embodiment of the present invention, the newly created file monitoring module 201 includes:

[0147] The first probe program mounting unit is used to pre-mount the first probe program for monitoring file creation operations;

[0148] A new file monitoring unit is used to store the file path of the executable file in the first record space when the first probe program determines that a new executable file of a specified type has been created in the background file of the network service.

[0149] In one specific embodiment of the present invention, the newly created file monitoring unit includes:

[0150] The monitoring path storage subunit is used to obtain the path of the network service to be monitored and store it in the second record space;

[0151] The monitoring type storage sub-unit is used to obtain the executable file type to be monitored and store it in the third record space;

[0152] The path determination subunit is used to determine whether the file path corresponding to the file creation operation belongs to the path range of any network service stored in the second record space when the file creation operation is detected by the first probe program; if it belongs to the path range of any network service stored in the second record space, the type determination subunit is triggered.

[0153] The type determination subunit is used to determine whether the file type corresponding to the file creation operation matches any executable file type stored in the third record space; if so, the path record subunit is triggered.

[0154] The path record subunit is used to determine whether the file created by the file creation operation is an executable file of a specified type, and to store the file path of the executable file in the first record space.

[0155] In one specific embodiment of the present invention, the path to be monitored storage subunit is specifically used for:

[0156] The first selection instruction determines each network service that the first selection instruction points to;

[0157] Each network service pointed to by the first selection instruction is taken as the network service to be monitored, the path of each network service to be monitored is obtained, and they are all stored in the second record space;

[0158] The monitoring type storage sub-unit is specifically used for:

[0159] The second selection instruction determines each executable file type that the second selection instruction points to;

[0160] Each executable file type pointed to by the second selection instruction is treated as an executable file type to be monitored and stored in the third record space.

[0161] In one specific embodiment of the present invention, the function call monitoring module 202 includes:

[0162] The second probe program mounting unit is used to pre-mount the second probe program for monitoring the call of the target function;

[0163] The function call monitoring unit is used to determine whether the call to the target function conforms to the set call conditions when the executable file of a specified type is detected to be calling the target function based on the second probe program.

[0164] The function call path determination unit is used to determine whether the file path of the executable file that calls the target function matches any file path stored in the first record space.

[0165] In one specific embodiment of the present invention, it further includes: a target function selection module, used to: determine each function pointed to by the third selection instruction through the third selection instruction, and use them all as target functions to be monitored;

[0166] The second probe program mounting unit is specifically used for;

[0167] For each target function to be monitored, a second probe program for monitoring the calls to the target function is pre-attached.

[0168] In one specific embodiment of the present invention, the risk assessment module 203 is specifically used for:

[0169] Obtain the command-line arguments used when calling the target function, and determine whether at least one of the command-line arguments matches a preset sensitive file;

[0170] If so, the risk assessment result is that there is a risk;

[0171] If not, the risk assessment result is that there is no risk.

[0172] In one specific embodiment of the present invention, the risk assessment module 203 is further configured to:

[0173] After determining that each parameter in the command line arguments does not match the preset sensitive file, it is then determined whether at least one parameter in the command line arguments matches the preset pending file.

[0174] If so, the resulting risk assessment is "risk pending".

[0175] If not, the risk assessment result is that there is no risk.

[0176] In one specific embodiment of the present invention, the sensitive files include: a first sensitive file related to the act of stealing or tampering with user information, a second sensitive file related to the act of stealing or tampering with user login credential information, a third sensitive file related to the act of tampering with user permission configuration, and a fourth sensitive file related to the act of tampering with login authentication configuration.

[0177] In one specific embodiment of the present invention, the risk protection module 204 includes:

[0178] The PID recording unit is used to determine the process to which the executable file that calls the target function belongs when the risk assessment result is that there is a risk, and to record the process number of the process.

[0179] The process chain matching unit is used to match each current process chain based on the process number. When it is determined that any process chain carries a process with the same process number, the process chain is blocked.

[0180] In one specific embodiment of the present invention, the process chain matching unit is specifically used for:

[0181] Recursively search each process chain to compare the process ID of each process in the chain with the process ID of the executable file that calls the target function.

[0182] If one of the process IDs in the process chain matches the process ID of the executable file that calls the target function, then the process chain is blocked.

[0183] In one specific embodiment of the present invention, an executable file deletion module is further included, for:

[0184] After blocking the process chain, the executable file that calls the target function will be deleted.

[0185] Corresponding to the above methods and system embodiments, this invention also provides a network service risk protection device, a computer-readable storage medium, and a computer program product, which can be referred to in conjunction with the above.

[0186] See Figure 3 As shown, the device may include:

[0187] Memory 301 is used to store computer programs;

[0188] Processor 302 is configured to execute a computer program to implement the steps of a risk protection method for network services as described in any of the above embodiments.

[0189] The computer program product includes a computer program / instruction that, when executed by a processor, implements the steps of a risk protection method for network services as described in any of the above embodiments.

[0190] See also Figure 4 The computer-readable storage medium 40 stores a computer program 41, which, when executed by a processor, implements the steps of the risk protection method for network services as described in any of the above embodiments. The computer-readable storage medium 40 referred to herein includes RAM (Random Access Memory), main memory, ROM (Read-Only Memory), EEPROM (Electrically Erasable Programmable Read Only Memory), registers, hard disks, removable disks, or any other form of storage medium known in the art.

[0191] It should also be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0192] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of each example have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this invention. Specific examples have been used herein to illustrate the principles and implementation methods of the invention; the description of the above embodiments is only for the purpose of helping to understand the technical solution and core ideas of the invention. It should be noted that those skilled in the art can make several improvements and modifications to the invention without departing from the principles of the invention, and these improvements and modifications also fall within the protection scope of the invention.

Claims

1. A method for risk protection of network services, characterized in that, include: When a new executable file of a specified type is detected in the background files of a network service, the file path of the executable file is stored in the first record space; When a call to the target function is detected to match the set call conditions, it is determined whether the file path of the executable file that calls the target function matches any file path stored in the first record space. If so, obtain the command-line arguments used when calling the target function, and compare the command-line arguments with preset sensitive files to obtain the risk assessment result; Based on the risk assessment results, risk protection operations are performed on the executable file that calls the target function; When a new executable file of a specified type is detected in the background files of a network service, the file path of the executable file is stored in the first record space, including: A first probe program for monitoring file creation operations is pre-mounted; When it is determined, based on the first probe program, that a new executable file of a specified type has been created in the background file of the network service, the file path of the executable file is stored in the first record space; When, based on the first probe program, it is determined that a specified type of executable file has been newly created in the background file of the network service, the file path of the executable file is stored in the first record space, including: Obtain the path of the network service to be monitored and store it in the second record space; The executable file type to be monitored is obtained and stored in the third record space; When a file creation operation is detected based on the first probe program, it is determined whether the file path corresponding to the file creation operation belongs to the range of any network service path stored in the second record space. If it falls within the range of any network service path stored in the second record space, then determine whether the file type corresponding to the file creation operation matches any executable file type stored in the third record space. If so, the file created by the file creation operation is determined to be an executable file of the specified type, and the file path of the executable file is stored in the first record space.

2. The network service risk protection method according to claim 1, characterized in that, Obtain the path of the network service to be monitored and store it in the second record space, including: The first selection instruction determines each network service pointed to by the first selection instruction; Each network service pointed to by the first selection instruction is taken as the network service to be monitored, the path of each network service to be monitored is obtained, and they are all stored in the second record space; The executable file types to be monitored are obtained and stored in a third record space, including: The second selection instruction determines each executable file type pointed to by the second selection instruction; Each executable file type pointed to by the second selection instruction is treated as an executable file type to be monitored and stored in the third record space.

3. The network service risk protection method according to claim 1, characterized in that, When a call to the target function is detected to match a predefined call pattern, it is determined whether the file path of the executable file calling the target function matches any file path stored in the first record space, including: A second probe program for monitoring calls to the target function is pre-mounted; When the target function is called by an executable file of a specified type based on the second probe program, it is determined that the call to the target function conforms to the set call conditions; Determine whether the file path of the executable file that calls the target function matches any file path stored in the first record space.

4. The network service risk protection method according to claim 3, characterized in that, Also includes: The third selection instruction is used to determine each function pointed to by the third selection instruction, and each function is used as the target function to be monitored. A second probe program for monitoring calls to the target function is pre-mounted, including; For each target function to be monitored, a second probe program for monitoring the calls to the target function is pre-attached.

5. The network service risk protection method according to claim 1, characterized in that, The command-line parameters are compared with preset sensitive files to obtain a risk assessment result, including: Determine whether at least one of the command-line parameters matches a preset sensitive file; If so, the risk assessment result is that there is a risk; If not, the risk assessment result is that there is no risk.

6. The network service risk protection method according to claim 5, characterized in that, Also includes: After determining that each parameter in the command line parameters does not match the preset sensitive file, it is determined whether there is at least one parameter in the command line parameters that matches the preset pending file. If so, the resulting risk assessment is "risk pending". If not, the risk assessment result is that there is no risk.

7. The network service risk protection method according to claim 1, characterized in that, The sensitive files include: a first sensitive file related to the act of stealing or tampering with user information; a second sensitive file related to the act of stealing or tampering with user login credential information; a third sensitive file related to the act of tampering with user permission configuration; and a fourth sensitive file related to the act of tampering with login authentication configuration.

8. The risk protection method for network services according to any one of claims 1 to 7, characterized in that, Based on the risk assessment results, risk protection operations are performed on the executable file that calls the target function, including: When the risk assessment result indicates that there is a risk, the process to which the executable file that calls the target function belongs is determined, and the process number of the process is recorded. Based on the process ID, each current process chain is matched. When it is determined that any process chain contains a process with the same process ID, the process chain is blocked.

9. The network service risk protection method according to claim 8, characterized in that, Based on the process ID, each current process chain is matched. When it is determined that any process chain contains a process with the same process ID, the process chain is blocked, including: For each current process chain, a recursive search is performed to compare the process ID of each process in the process chain with the process ID of the process to which the executable file that calls the target function belongs. If, among the process IDs of all processes in the process chain, there is a process ID that matches the process ID of the executable file that calls the target function, then the process chain is blocked.

10. The risk protection method for network services according to claim 8, characterized in that, Also includes: After blocking the process chain, the executable file that calls the target function will be deleted.

11. A risk protection system for network services, characterized in that, include: A new file monitoring module is used to store the file path of the executable file in the first record space when a new executable file of a specified type is detected in the background files of the network service. The function call monitoring module is used to determine whether the file path of the executable file that calls the target function matches any file path stored in the first record space when a call to the target function is detected to meet the set call conditions; if so, the risk judgment module is triggered. The risk assessment module is used to obtain the command-line parameters used when calling the target function, and compare the command-line parameters with preset sensitive files to obtain the risk assessment result; The risk protection module is used to perform risk protection operations on the executable file that calls the target function based on the risk assessment result. The newly created file monitoring module includes: The first probe program mounting unit is used to pre-mount the first probe program for monitoring file creation operations; A new file monitoring unit is used to store the file path of the executable file in the first record space when the first probe program determines that a new executable file of a specified type has been created in the background file of the network service. The newly created file monitoring unit includes: The monitoring path storage subunit is used to obtain the path of the network service to be monitored and store it in the second record space; The monitoring type storage sub-unit is used to obtain the executable file type to be monitored and store it in the third record space; The path determination subunit is used to determine whether the file path corresponding to the file creation operation belongs to the path range of any network service stored in the second record space when the file creation operation is detected by the first probe program; if it belongs to the path range of any network service stored in the second record space, the type determination subunit is triggered. The type determination subunit is used to determine whether the file type corresponding to the file creation operation matches any executable file type stored in the third record space; if so, the path record subunit is triggered. The path record subunit is used to determine whether the file created by the file creation operation is an executable file of a specified type, and to store the file path of the executable file in the first record space.

12. A network service risk protection device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the risk protection method for network services as described in any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the risk protection method for network services as described in any one of claims 1 to 10.

Images