A rule-matching-based intrusion prevention system adaptive protection method and device

Abstract

The application relates to a rule-matching-based intrusion prevention system adaptive protection method and device. Three table items, a blacklist table, a whitelist table and a shunting table, are embedded in the data processing flow of a rule-matching-based NIDS system, and the three table items are provided with strategies for addition and deletion, so that the system can discard and release some high-concurrent-connection-causing traffic in advance in the early stage of traffic processing based on the original data processing flow, relieve the processing pressure of the system, and effectively solve the system abnormality problem caused by high-concurrent-connection. Compared with the prior art, the application has the remarkable advantages that the system abnormality problem caused by high-concurrent-connection can be effectively solved without affecting the original flow.

Description

Technical Field

[0001] This invention relates to the field of local area network security monitoring technology, and in particular to an adaptive protection method and device for an intrusion prevention system based on rule matching. Background Technology

[0002] To ensure internet security, it is necessary to deploy network security monitoring and network intrusion detection equipment within a local area network (LAN) for network monitoring and defense. Current mainstream Network Intrusion Prevention Systems (NIDS) are based on flow tables, performing rule matching on packets and flow information, and then taking action on the traffic based on the matched rules. In this type of NIDS system, flow tables are fundamental, playing a crucial role globally, and most rule detection operations are also based on flow tables.

[0003] Systems based on flow tables typically face the following problem: when the number of network connections consistently exceeds the system's maximum limit (i.e., the maximum capacity of the flow table), the efficiency of flow table-based operations, including adding, deleting, updating, and matching flow information rules, will be severely reduced. Without effective system protection, this can lead to serious consequences such as system malfunctions or even system crashes. Network security devices are generally connected in series within a local area network (LAN). If system malfunctions occur, they not only cannot perform their network security maintenance duties but may also hinder users' internet access. Therefore, network security devices must have mechanisms to maintain their own normal operation, and the first issue to address is the impact of high-concurrency connections on the system's underlying flow tables. Summary of the Invention

[0004] The purpose of this invention is to provide an adaptive protection method and device for an intrusion prevention system based on rule matching. By embedding three entries—a blacklist, a whitelist, and a traffic splitting table—in the NIDS system, some traffic that leads to high-concurrency connections can be discarded or allowed in advance during the initial stage of traffic processing, thereby alleviating the system processing pressure and effectively solving the system anomaly problem caused by high-concurrency connections.

[0005] The technical solution for achieving the objective of this invention is: an adaptive protection method for an intrusion prevention system based on rule matching, characterized by comprising the following steps:

[0006] S1. Add a blacklist, whitelist, and flow splitting table to the NIDS system packet processing flow. The NIDS system packet processing flow includes packet acquisition, packet parsing, flow data update, rule matching, log export, and flow data recycling.

[0007] S2. After the data packet is parsed, a blacklist lookup is performed. The blacklist uses IP addresses as keys and values. Data packets that match the blacklist are discarded and do not proceed to the next step. The parsing result of the data packet is a 5-tuple containing the IP address.

[0008] S3. After querying the blacklist, perform a whitelist query. The whitelist table also uses IP addresses as keys and values. Data packets that match the whitelist table are allowed directly without going through the subsequent process.

[0009] S4. The flow table uses a 5-tuple as the key value. A flow of packets enters the flow table or the system flow table according to the predetermined flow strategy. Packets entering the flow table are allowed to pass directly, while packets entering the system flow table continue to follow the original NIDS matching process.

[0010] Furthermore, the method also includes creating a monitoring thread to execute the enabling strategies for the blacklist switch, whitelist switch, and diversion switch; and executing the disabling and resuming strategies for the blacklist switch, whitelist switch, and diversion switch.

[0011] Furthermore, the activation strategy for the blacklist switch, whitelist switch, and traffic splitting switch is as follows: The monitoring thread checks the system flow table usage rate according to a set scanning cycle. When the system flow table usage rate reaches a set threshold, it first checks whether the blacklist switch is enabled. If the blacklist switch is not enabled, it is enabled, and the process waits for the next check. If the blacklist switch is enabled, it continues to check whether the whitelist switch is enabled. If the whitelist switch is not enabled, it is enabled, and the process waits for the next check. If the whitelist switch is enabled, it continues to check whether the traffic splitting switch is enabled. If the traffic splitting switch is not enabled, it is enabled, and the process waits for the next check. If the traffic splitting switch is enabled, the predetermined traffic splitting strategy is adjusted to increase the traffic splitting intensity in order to reduce the system flow table usage rate.

[0012] Furthermore, the strategies for disabling and resuming the blacklist switch, whitelist switch, and traffic splitting switch are as follows: The monitoring thread scans each blacklist node for the number of hits within a set scanning cycle. If the number of hits is less than the set value, the blacklist node is deleted. Then, if the blacklist table is empty, the blacklist switch is turned off. Next, the thread scans each whitelist node for the number of hits within a scanning cycle. If the number of hits is less than the set value, the whitelist node is deleted. Then, if the whitelist table is empty, the whitelist switch is turned off. Finally, the sum S of the usage of flow nodes in the system flow table and the traffic splitting table is calculated. If S is less than the set percentage of the maximum capacity of the system flow table, the traffic splitting switch is turned off. Then, the traffic splitting table is traversed, long connections and normally closed connections are aged out and exported, and other traffic (short connections and abnormally closed connections) is directly deleted. The number of hits refers to the number of matches when querying the blacklist / whitelist.

[0013] Furthermore, the blacklist addition strategy is as follows: after the blacklist switch is turned on, the number of connections initiated to a certain IP address within a specified time is counted. If the number of connections exceeds the set maximum number, the IP address is added to the blacklist for protection and isolation.

[0014] Furthermore, the whitelist addition strategy is as follows: after the whitelist switch is turned on, the number of new TCP connections initiated by a certain IP address within a specified time is counted. If the count of new TCP connections exceeds the set maximum value, and the IP address is an internal network address, and the system traffic growth does not exceed the set value, then the IP address is added to the whitelist.

[0015] Furthermore, in S4, the quintuple refers to: source IP address, destination IP address, source port, destination port, and protocol number.

[0016] Another objective of this invention is to provide an apparatus for an adaptive protection method for an intrusion prevention system based on rule matching, comprising a data packet acquisition module, a data packet parsing module, a stream data update module, a rule matching module, a stream data recycling module, and a log export module. The data packet acquisition module transmits the acquired data packets to the data packet parsing module, the data packet parsing module transmits the data packets and parsed information to the stream data update module, the data update module transmits the data packets to the rule matching module, the stream data recycling module recycles and processes the stream data nodes of the data update module, and the log export module exports the log information generated by the stream data recycling module and the rule matching module.

[0017] The significant advantages of this invention compared to existing technologies are:

[0018] 1. Without affecting the original process, it can effectively solve the problem of security equipment system abnormalities caused by high concurrency connections;

[0019] 2. Conduct a preliminary analysis of traffic with an abnormally high number of connections, try to block attack traffic, and allow known legitimate traffic;

[0020] 3. For high-concurrency connections where it is impossible to determine whether the traffic is normal or abnormal, handle them according to the user's choice, allowing the user to select the trusted traffic type based on their own environment. When the traffic reaches the set threshold, no rule matching check will be performed on the trusted traffic type selected by the user.

[0021] 4. Set up an effective recovery mechanism to avoid oscillations in the adaptive mechanism. Attached Figure Description

[0022] Figure 1 This is the data packet processing flow of the NIDS system.

[0023] Figure 2This is a flowchart of the method of the present invention. Detailed Implementation

[0024] The embodiments of the present invention will be described in detail below with reference to the accompanying drawings. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention. It will be understood by those skilled in the art that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have a meaning consistent with their meaning in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless defined as herein.

[0025] To address the impact of high-concurrency connections on the system, an analysis can be conducted by examining the NIDS system framework and packet processing flow. The system primarily includes functional modules such as Intrusion Detection System (IDS), Intrusion Prevention System (IPS), Network Security Monitoring (NSM), and pcap offline packet processing. See [link to NIDS system packet processing documentation] for details. Figure 1 The functions of each module in the data processing workflow are described below:

[0026] ● Packet Acquisition Module. This module is responsible for acquiring data packets and then passing the acquired packets to the packet parsing module.

[0027] ● Packet parsing module. Responsible for parsing packet information and then passing the packet and the parsed information to the stream data update module.

[0028] ● Stream data update module. Records stream data according to the five-tuple information parsed from the data packets, and generates and updates the stream information management table (…). Figure 1 The system uses a table composed of the middle data nodes (hereinafter referred to as the system flow table) to pass the data packets to the rule matching module.

[0029] ● Rule matching module. Matches messages according to pre-defined rules and provides subsequent actions for matching messages, such as discarding, allowing, or rejecting.

[0030] ● Streaming data recycling module. Responsible for periodically aging up streaming data and exporting streaming information.

[0031] ● Log export module. Responsible for exporting various log information.

[0032] The rule matching module is the main packet inspection engine. Its working principle is to perform rule matching on packets, then tag matching packets with action labels, and perform actions such as allowing or dropping the packets. In other words, only after a packet passes through the rule matching module can its legitimacy be determined. However, if... Figure 1 As shown, before data packets enter the rule matching module, they need to pass through the flow data update module. The main function of this module is to first create and update the flow table, and then send the data packets and their related flow information to the rule matching module for detection. However, traffic with a high number of concurrent connections affects the system's flow table when the flow data update module adds flow tables before the traffic enters the rule matching module. At this time, the rule matching module cannot function at all.

[0033] There are many types of traffic that can lead to high concurrency connections, such as attack traffic: illegal scanning, brute-force attacks, FLOOD attacks, and the recently proposed TSE attack, which can have a significant impact on software switches; and normal traffic: traffic emitted by asset detection devices within the local area network. Current packet processing mechanisms cannot rely on rules to detect this traffic, or some attack traffic rules simply cannot identify. Therefore, the general approach is as follows: set an emergency running mode for the flow table (emergency running mode means that the flow table usage has reached the configured maximum capacity). When the flow table status reaches emergency running mode, the flow nodes are aged and flow node information is exported according to the configured aging time in emergency mode. To quickly reduce flow table usage, the default configuration for emergency mode flow table aging time is usually set very short, such as 5 seconds for new TCP connections and 10 seconds for new UDP connections. However, this approach has two problems: First, Figure 1 The first issue is the competition problem between the midstream data update module and the stream data recycling module during the operation of the stream table; the second issue is... Figure 1 The issue of a surge in log information sent from the midstream data recycling module to the log export module has two main problems. First, in emergency mode, the flow table frequently adds and deletes flow nodes, leading to intense contention for flow table locks. This severely slows down the overall system processing capacity and may even cause the system to malfunction. Second, reducing flow aging time results in a large amount of log output, putting significant pressure on temporary databases and log servers, potentially causing them to malfunction as well. Therefore, current common solutions cannot protect the flow table from the impact of a surge in connection traffic, and if the impact is severe, it can even cause the entire system to malfunction.

[0034] The traffic that leads to high concurrent connections can be divided into three categories based on the changes in source IP and destination IP: The first category is where the source IP remains the same but the destination IP changes, such as illegal scanning; the second category is where the destination IP remains the same but the source IP changes, such as FLOOD attacks; and the third category is where both the source IP and destination IP change, such as TSE attacks designed to target the flow tables of various software classifiers.

[0035] The adaptive protection method for intrusion prevention systems based on rule matching proposed in this invention formulates different traffic handling strategies according to three different types of traffic. Before the creation and update of flow tables, blacklists, whitelists, and traffic diversion tables are set up to divert traffic in advance to protect the flow tables, and corresponding recovery mechanisms are set up.

[0036] like Figure 2 As shown, this invention embeds three tables into the NIDS system data packet processing flow: a blacklist table, a whitelist table, and a traffic splitting table. It also provides policies for adding and deleting these three tables, enabling the system to discard or allow some traffic that leads to high-concurrency connections in advance during the initial stage of traffic processing, thereby alleviating the system's processing pressure.

[0037] 1) The blacklist uses IP address as the key and value. After the packet parsing module parses the IP address, it performs a query. Packets that match the blacklist are directly discarded and do not go through the subsequent process.

[0038] 2) The whitelist also uses IP address as the key value. After querying the blacklist, the whitelist is queried. Data packets that match the whitelist are allowed to pass directly without going through subsequent processes such as adding to the flow table or detection.

[0039] 3) The flow distribution table uses a 5-tuple as the key-value pair. Packets from a flow, according to the policy, either enter the flow distribution table or the system flow table. Traffic entering the flow distribution table is allowed to pass directly, while traffic entering the system's original flow table continues its original process. The embedding locations of the three types of new table entries in the packet processing flow are shown in [link to documentation]. Figure 2 .

[0040] The steps to achieve the technical solution of this invention are as follows:

[0041] 1. Add a blacklist.

[0042] Adding a strategy: When the blacklist switch is turned on (the monitoring thread, described later, turns the blacklist switch on and off based on system status), count the number of connections initiated to a specific IP address (destination IP, DIP) within a specified time period. If the number exceeds the set maximum number of connections, it is considered attack traffic, and this IP address needs to be added to the blacklist for protection and isolation. For example, the number of TCP SYN packets received by the same DIP within 2 seconds can be counted. If the number exceeds 50, this IP address is considered to be under a FLOOD attack and needs to be added to the blacklist flow table for temporary isolation and protection.

[0043] Usage: When the blacklist switch is turned on, after data packets are parsed, the source IP and destination IP of the data packets are matched against the blacklist table. Packets that match are discarded, while unmatched packets proceed to the next step. The number of hits for each blacklisted IP is recorded (this record provides the monitoring thread with the basis for determining whether to turn the blacklist switch on or off). In actual LAN use, the number of identifiable, threatening IPs is usually not large. To ensure overall system performance, the blacklist size can be set relatively small.

[0044] 2. Add a whitelist.

[0045] Policy Addition: When the whitelist switch is turned on (the monitoring thread, described later, turns the whitelist switch on and off based on system status), the number of new TCP connections initiated by a specific IP address (source IP, SIP) within a specified time period is counted. If the count of new TCP connections exceeds the set maximum value, and the IP address initiating the connection is an internal network address, and there is no significant increase in system traffic at this time, it is assumed that this IP is performing asset scanning operations within the local area network. To prevent conflicts between the asset scanning device within the local area network and the security detection settings of the device itself, the IP address of this scanning device needs to be added to the whitelist, allowing scanning traffic directly.

[0046] Usage: When the whitelist switch is turned on, for traffic that does not match the blacklist in step 1, a whitelist match will be performed. If the source IP or destination IP of the packet matches the whitelist IP address list, the packet is allowed directly without going through the subsequent flow table creation and rule matching process. Packets that do not match continue to follow the subsequent process, and the number of hits for each whitelist IP is recorded (recording the number of hits provides a basis for the monitoring thread to determine whether to turn the whitelist switch on or off). The capacity of the whitelist is the same as that of the blacklist, and it can also be set smaller.

[0047] 3. Add a flow distribution table.

[0048] Adding a strategy: Once the traffic splitter switch is turned on (the monitoring thread, described later, turns the switch on and off based on system status), the traffic splitter table is added. The traffic splitter table uses a 5-tuple as the key-value pair. Traffic entering the splitter table should be allowed directly unless there are special circumstances, as most IPS settings are connected in series in the network, and packet loss is not allowed unless the traffic is confirmed to be illegal. The purpose of creating the traffic splitter table is to allow traffic entering the table directly without further rule matching, and the table only performs simple information statistics, used solely for the monitoring thread's deletion strategy. The advantage is that it can quickly reduce the system's flow processing pressure, rule matching pressure, and log export pressure while maintaining the same query efficiency. Additionally, a strategy for how traffic is split needs to be defined. Two possible splitting strategies are: 1) proportional splitting; 2) splitting according to user preference. Proportional splitting, such as a 1:1 split, involves adding one flow to the system flow table and one flow to the splitter table. Traffic can be routed according to user preferences, and options can be set for selection. For example, outbound traffic entering the routing table can be set to not be detected, encrypted traffic from ports such as 443 can be set to not be checked, and some traffic that can be directly classified using five-tuple information can also be set as optional.

[0049] Usage: When the flow splitter is turned on, the flow splitter table works the same way as the system flow table, except that it records less information than the system flow table. It also uses the method of first checking if it exists and then creating it if it does not exist. If a data packet enters the flow splitter table, the flow information is first counted and then the packet is allowed to pass directly without going through the rule matching process.

[0050] 4. Create a monitoring thread. The monitoring thread's functions are: 1) To turn the blacklist, whitelist, and traffic splitting switches on and off; 2) To delete nodes from the blacklist and whitelist tables; 3) To delete and age out traffic splitting table nodes.

[0051] Switch opening strategy: When the system flow table utilization reaches 90%, check and open the blacklist switch, whitelist switch, and diversion switch in sequence.

[0052] Blacklist switch off and node deletion strategy: In the monitoring thread, a scan interval is set for the blacklist. At the designated scan time, the hit count of each blacklist node within that time period is scanned. If the hit count is less than the set value, the blacklist node is deleted. If the blacklist is empty, the blacklist switch is turned off. For example, if the blacklist is set to scan once per minute, and a blacklist IP has fewer than 200 hits within one minute, that blacklist IP is deleted.

[0053] The whitelist switch off and node deletion policy are similar to the blacklist, so they will not be described in detail here.

[0054] Flow table switch closure and node deletion / aging strategy: For flow tables, it's necessary to consider whether to continue using the flow table and the handling strategy for traffic entering the flow table. 1) Whether to continue using the flow table depends on the utilization rate of the system flow table and the flow table itself: If the total number of flow nodes in the current system flow table and flow table does not exceed 90% of the system flow table capacity, then the flow table switch should be closed; otherwise, the flow table switch should remain open. 2) The handling strategy for traffic entering the flow table depends on the individual flow information: Long flows within a specified time and flows with normally closed connections need to be aged and their flow information exported; other traffic can be directly deleted without exporting any information.

[0055] The following uses the open-source NIDS framework Suricata as an example to illustrate the specific implementation of this patent.

[0056] 1. How to add and use the blacklist.

[0057] 1) Create a blacklist table.

[0058] In this embodiment, the blacklist table is in the form of an array of 100 elements, where each element is a structure that stores the IP address and the number of hits.

[0059] 2) Create a DIP statistics table.

[0060] In this embodiment, the DIP statistics table is an array of 100 elements. Each array element is also a structure that stores: IP address; timestamp; destination IP of TCP SYN packets and the statistical value of packets with this IP (TCP SYN packets are used as an example here, but other types of packets can be counted in actual applications); and whether the array element is in use.

[0061] 3) With the blacklist switch on, the DIP statistics table and blacklist addition methods are as follows:

[0062] ● Obtain DIP from TCP SYN packets

[0063] ● Iterate through the DIP statistics table array, first checking if the current array element is in "use". If it is in "use", compare the IP stored in the array element with the DIP carried in the packet; if they do not match, compare the next one. If it is not in "use", record the array element position k, and then proceed to the next loop.

[0064] ● After traversing the array, if no array element matching the DIP carried in the message is found, the last "inactive" array element found is used to save the message's DIP, record the time, and increment the statistical value by 1. If no "inactive" array element is found, the process exits directly.

[0065] ● After traversing the array, if an array element that matches the message DIP is found, the interval between the current time and the time recorded in the array element is calculated.

[0066] ● For the above time interval, if it is greater than the set value (set to 2s in this embodiment), check the statistical value. If the statistical value is greater than the set value (set to 50 in this embodiment), add this DIP to the blacklist and set this array element to "not in use"; otherwise, directly set this array element to "not in use".

[0067] ● For the above time interval, if it is less than the set value (set to 2s in this embodiment), then the statistical value of this array element is incremented by 1 and the timestamp is updated.

[0068] 2. How to add and use the whitelist.

[0069] 1) Create a whitelist table.

[0070] In this embodiment, the whitelist is an array of 100 elements, where each element is a structure that stores the IP address and the number of hits.

[0071] 2) Create a SIP statistics table.

[0072] In this embodiment, the SIP statistics table is an array of 100 elements. Each array element is also a structure that stores: IP address; timestamp; source IP of the TCP SYN packet and the statistical value of the packets from this IP (TCP SYN packets are used for asset detection within the local area network); and a flag indicating whether the array element is in use.

[0073] 3) With the whitelist switch enabled, the SIP statistics table's statistical methods and the whitelist addition methods are as follows:

[0074] ● Obtain SIP from TCP SYN packets

[0075] ● Iterate through the SIP statistics table array, first checking if the current array element is in "use". If it is in "use", compare the IP stored in the array element with the SIP carried in the packet; if they do not match, compare the next one. If it is not in "use", record the array element position k, and then proceed to the next loop.

[0076] ● After traversing the array, if no array element with the same SIP as the packet is found, the last "inactive" array element found is used to save the packet's SIP, record the time, and increment the statistical value by 1. If there is no "inactive" array element, the process exits directly.

[0077] ● After traversing the array, if an array element that matches the SIP message is found, the interval between the current time and the time recorded in the array element is calculated.

[0078] ● For the above time interval, if it is greater than the set value (set to 2s in this embodiment), check the statistical value. If the statistical value is greater than the set value (set to 50 in this embodiment), and the traffic received by the current device does not exceed the average value, add this SIP to the whitelist and set this array element to "not in use"; otherwise, directly set this array element to "not in use".

[0079] ● For the above time interval, if it is less than the set value (set to 2s in this embodiment), then the statistical value of this array element is incremented by 1 and the timestamp is updated.

[0080] 3. How to add and use the distribution table.

[0081] 1) Create a flow distribution table.

[0082] In this embodiment, a hash table is used to maintain the flow table. The flow table nodes store a small amount of statistical information such as 5-tuple information, timestamps, number of packets, and connection status. The key value of the flow table is a 5-tuple. The flow table query and creation methods are consistent with the system flow table.

[0083] 2) When the diversion switch is open, the flow is diverted to the system flow table and the diversion table according to the strategy.

[0084] 3) The data packet splitting process through the splitting table and flow table is as follows. This embodiment splits packets based on session ratio, but in actual use, packet splitting can also be done by protocol number or port number.

[0085] ● Obtain the SIP and DIP of the data packets, and calculate the traffic splitting value M using (SIP+DIP)%n. Where n is the proportion of traffic splitting, which is set to 2 in this embodiment, indicating that sessions established according to SIP and DIP are split at a 1:1 ratio.

[0086] ● Sessions with a traffic splitting value M of 0 are entered into the traffic splitting table, while other sessions are entered into the system flow table. Traffic entering the traffic splitting table is allowed to pass directly after the flow information is updated. The flow information that needs to be recorded includes: number of packets, connection status, timestamp, etc. Traffic entering the system flow table follows the original process.

[0087] 4. Configure monitoring threads and recovery mechanisms.

[0088] 1) Switch on strategy.

[0089] ● The monitoring thread checks the system flow table usage rate every minute. If the usage rate reaches 90%, it checks and enables the blacklist switch, then exits the check and waits for the next timer to expire before re-checking to decide whether to enable other switches. The advantage of this is that if the high system flow table usage rate is caused by objects detected and filtered out by the blacklist, the system flow table will have returned to normal by the next check, and there will be no need to enable other switches.

[0090] ●When the next check expires, if the system flow table utilization rate reaches 90%, but the blacklist switch is already on, then continue to check if the whitelist switch is on. If it is not on, then turn it on (the way to start and exit this check is the same as the blacklist switch). If it is already on, then the flow diversion switch needs to be turned on (the way to start and exit this check is the same as the blacklist switch). If the flow diversion switch is also on, it proves that the flow diversion is not strong enough and the system flow table utilization rate is still very high, then increase the flow diversion.

[0091] 2) Switch off and restore strategy.

[0092] ● Check if the blacklist switch is turned on. If it is, iterate through the blacklist list, delete nodes that have been hit less than 200 times in 1 minute, and check if the list is empty. If it is empty, turn off the blacklist switch and stop performing DIP statistics, blacklist additions, blacklist checks, and other operations.

[0093] ●Then perform whitelist on / off, list check, and whitelist on / off settings (similar to blacklist).

[0094] ● Finally, check the flow splitter switch. First, calculate the sum S of the flow node usage in the system flow table and the flow splitter table. If S is less than 90% of the maximum capacity of the system flow table, then turn off the flow splitter switch. That is, the data packets no longer need to be split, and the original flow is restored to the system flow table. Then, traverse the flow splitter table, age out and export long connections and normally closed connections. Other traffic (short connections and abnormally closed connections) can be directly deleted.

[0095] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any transformations or substitutions that can be conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for adaptive protection of a rule-matching based intrusion prevention system, characterized in that, Comprising the following steps: S1, adding a blacklist table, a whitelist table and a shunt table in a NIDS system data packet processing flow, the NIDS system data packet processing flow comprising data packet collection, data packet analysis, flow data updating, rule matching, log export and flow data recycling; Creating a monitoring thread to execute opening strategies of the blacklist switch, the whitelist switch and the shunt switch; executing closing and recovery strategies of the blacklist switch, the whitelist switch and the shunt switch; The opening strategy of the blacklist switch, the whitelist switch and the shunt switch is that the monitoring thread checks the system flow table usage rate according to a set scanning period, when the system flow table usage rate reaches a set threshold, firstly judging whether the blacklist switch is opened, if the blacklist switch is not opened, opening the blacklist switch, and waiting for the next check; if the blacklist switch is opened, judging whether the whitelist switch is opened, if the whitelist switch is not opened, opening the whitelist switch, and waiting for the next check; if the whitelist switch is opened, judging whether the shunt switch is opened; if the shunt switch is not opened, opening the shunt switch, and waiting for the next check; if the shunt switch is opened, adjusting the predetermined shunt strategy, and increasing the shunt strength to reduce the system flow table usage rate; The closing and recovery strategy of the blacklist switch, the whitelist switch and the shunt switch is that the monitoring thread scans according to a set scanning period, firstly scanning the hit number of each blacklist node in a scanning period, when the hit number is less than a set value, setting the blacklist node as invalid; further closing the blacklist switch when the blacklist table is empty; then scanning the hit number of each whitelist node in a scanning period, when the hit number is less than a set value, deleting the whitelist node; further closing the whitelist switch when the whitelist table is empty; finally calculating the sum S of the flow node usage in the system flow table and the shunt table, if S is less than a set percentage of the maximum capacity of the system flow table, closing the shunt switch, and then traversing the shunt table, aging and exporting long connections, normally closed connections, and directly deleting short connections and abnormally closed connections; wherein the hit number is the matching hit number in the blacklist / whitelist query; S2, after the data packet is analyzed, the blacklist query is performed, the blacklist table uses IP address as key value, the data packet matching the blacklist table is directly discarded, and does not go through the subsequent process; wherein the analysis result of the data packet is a five-tuple containing IP address; S3, after the blacklist query, the whitelist query is performed, the whitelist table also uses IP address as key value, the data packet matching the whitelist table is directly released, and does not go through the subsequent process; S4, the shunt table uses five-tuple as key value, the message of a flow enters the shunt table or the system flow table according to the predetermined shunt strategy, directly releases the message entering the shunt table, and continues to go through the original matching process of the NIDS. The adding strategy of the blacklist table is that after the blacklist switch is opened, the number of connections initiated to a certain IP address in a specified time is counted, if it exceeds the set maximum number of connections, the IP address is put into the blacklist table for protection and isolation.

2. The method of claim 1, wherein the method further comprises: ​ 3. The method of claim 1, wherein the method further comprises: The adding strategy of the white list table is: after the white list switch is turned on, the number of TCP new connection initiated by a certain IP address in a specified time is counted, if the counted number of TCP new connection exceeds the set maximum value, and the IP address is an intranet address, and the system traffic growth does not exceed the set value at this time, the IP address is added to the white list table.

4. The method of claim 1, wherein the method further comprises: The quintuple in S4 refers to: source IP address, destination IP address, source port, destination port and protocol number.

5. An apparatus for adaptive protection method of rule-matching based intrusion prevention system, applied to the adaptive protection method of rule-matching based intrusion prevention system as claimed in any one of claims 1-4, characterized in that, The data packet collection module, the data packet analysis module, the flow data updating module, the rule matching module, the flow data recycling module and the log exporting module are included, the data packet collection module transmits the collected data packet to the data packet analysis module, the data packet analysis module transmits the data packet and the analyzed information to the flow data updating module, the data updating module transmits the data packet to the rule matching module, the flow data recycling module recycles the flow data node of the data updating module, and the log exporting module exports the log information generated by the flow data recycling module and the rule matching module.

Images