An improved method and apparatus for Suricata stream detection

Abstract

The scheme discloses an improved Suricata flow detection method and device, the method comprises the following steps: generating a flow identifier according to the quintuple information of a first packet; querying whether the first packet is a new transaction, and determining a transaction identifier; loading a plurality of Suricata rules, and matching the first packet with the plurality of Suricata rules one by one; when the first packet matches a first rule, setting a flag bit for a first transaction corresponding to the first packet; if a second packet exists the flag bit, matching the second packet with a second rule; if a third packet exists the flag bit, matching the third packet with a third rule in the rule; if the third packet matches the third rule successfully, clearing the association in the first transaction, and generating an alarm information. The scheme is based on the application layer transaction, not only relying on the transport layer connection; the states set by different transactions are completely invisible, completely eliminating the false alarm caused by sharing the state.

Description

TECHNICAL FIELD

[0001] The present solution relates to the technical field of network security, and in particular to an improved Suricata flow detection method and device. BACKGROUND

[0002] Under the background of increasingly complex and advanced network threats, attack paradigms have evolved from early single-packet probes, scans and spills to complex attack chains composed of multiple packets and multiple steps. Whether it is the gradual penetration in APT attacks, session hijacking and business logic abuse in web applications, or multi-stage payload delivery based on C2 servers, their common feature is to disperse malicious payloads in continuous interaction processes and camouflage through legitimate protocol interactions. Traditional signature-based identifier IDS / IPS technology, like a police officer who only checks isolated evidence but cannot restore the crime process. Although it can accurately identify known "features" (such as a specific attack string) carried in a data packet, it cannot understand the context association and logical order of these "features" in the entire attack chain.

[0003] To this end, Suricata introduces powerful stateful flow detection capabilities, which treat a complete network session (such as a TCP connection) as a "flow" object with a life cycle and can track its state. flowbits is a core key technology that emerged in this context. The essence of flowbits is a "state memory sticker" mechanism provided for network flows. It allows the Suricata detection engine to use multiple rules to match multiple packets on the flow within the life cycle of the flow, thereby dynamically setting (set), querying (isset) and clearing (unset) custom state flags. A rule can "stick a label" by checking the content of the flow, and subsequent rules only need to check whether this label exists to determine whether the previous stage has been detected, and then write subsequent rules based on this, and the last rule matching is completed to produce an alarm and clear the label.

[0004] This technology successfully "decouples" the detection logic of multi-step attacks, enabling rules to communicate and collaborate through flowbits. It not only greatly improves the accuracy of detecting complex attacks (such as authentication bypass and multi-stage exploits), but also optimizes detection performance by avoiding redundant calculations, and is the cornerstone of Suricata's intelligent and efficient stateful detection. However, this flow detection technology also has the following shortcomings:

[0005] 1. Flowbits, a flow detection technology, is based on connections (i.e., if the five-tuple (source IP, destination IP, source port, destination port, and transport layer protocol) are the same, it is the same flow), which is a transport layer concept.

[0006] 2. Flow inspection technology is too coarse-grained and not associated with application layer protocols, making it unable to distinguish application layer transactions. For example, a TCP stream (such as a persistent HTTP / 1.1 connection) can contain multiple independent HTTP request-response transactions. Flowbits attaches tags to "streams," causing all transactions to share the same set of state flags.

[0007] 3. Flow inspection technology may lead to misalignment of state lifecycles. For example, the lifecycle of a flow tag is bound to the TCP or UDP stream, and setting and clearing it can only be done based on the transport layer protocol. However, from the application layer's perspective, the end of a session or transaction does not represent the termination of the transport layer connection.

[0008] 4. Flowbits cannot support multiple application protocols reusing the same connection. For example, in a scenario where HTTP protocol data packets can be transmitted first on the same TCP stream, and then the protocol can be upgraded to WebSocket protocol. Summary of the Invention

[0009] This solution aims to at least address the technical problems existing in the prior art. To this end, the first aspect of this invention proposes an improved Suricata flow detection method, the method comprising:

[0010] Step S1: After receiving the first message, generate a flow identifier based on the five-tuple information of the first message and a preset flow identifier generation algorithm;

[0011] Step S2: Based on the flow identifier and the application layer protocol structure, query the preset transaction array to see if the first message is a new transaction, and determine the transaction identifier of the first message;

[0012] Step S3: Load multiple Suricata rules and match the first message with each of the multiple Suricata rules;

[0013] Step S4: Check whether the current Suricata rule contains a preset transaction keyword. If it does, match the first message with the first rule in the current Suricata rule.

[0014] Step S5: when the first message matches the first rule in the current Suricata rule, setting a flag bit in the first transaction corresponding to the first message with the first rule; and saving the first transaction association relationship of the flag bit, the flow identifier and the transaction identifier of the first message to the cache;

[0015] Step S6: receiving a second message, and performing steps S1-S3 on the second message, if the current Suricata rule contains the transaction keyword, matching the flow identifier and the transaction identifier of the second message with the flow identifier and the transaction identifier in each transaction association relationship in the cache; if the matching with the first transaction association relationship is successful, checking whether the flag bit in the first transaction association relationship exists in the second message, if the flag bit exists, matching the second message with a second rule in the Suricata rule;

[0016] Step S7: receiving a third message, and performing steps S1-S3 on the third message, if the current Suricata rule contains the transaction keyword, and the second message matches the second rule successfully in step S6, matching the flow identifier and the transaction identifier of the third message with the flow identifier and the transaction identifier in each transaction association relationship in the cache; if the matching with the first transaction association relationship is successful, checking whether the flag bit exists in the third message, if the flag bit exists, matching the third message with a third rule in the Suricata rule; wherein the first message, the second message and the third message are three messages received by Suricata in sequence; the contents of the first rule, the second rule and the third rule are three behavior information in network attack behavior arranged in the order of execution;

[0017] Step S8: if the third message matches the third rule successfully, clearing the association relationship in the first transaction, and generating an alarm information.

[0018] Optionally, after generating the flow identifier according to the five-tuple information of the first message and a preset flow identifier generation algorithm in step S1, the method further comprises:

[0019] querying whether the flow identifier exists in a preset flow table;

[0020] if not, creating a new flow record and adding the flow identifier to the flow table.

[0021] Optionally, the step S2 comprises: determining whether the first message is a new transaction according to the flow identifier and a protocol structure of an application layer.

[0022] performing application layer protocol analysis on the first packet to obtain an application layer protocol structure of the first packet;

[0023] querying the preset transaction array for a flow identifier and a protocol structure of the first packet, and setting a transaction identifier of the first packet as a transaction identifier of a target transaction in the transaction array when the transaction array contains the target transaction with the same flow identifier and protocol structure as those of the first packet;

[0024] when the transaction array does not contain a transaction with the same flow identifier and protocol structure as those of the first packet, creating a new transaction record and adding a transaction identifier uniquely marking the transaction record into the transaction array.

[0025] Optionally, after the step S4 of checking whether the current Suricata rule contains the preset transaction keyword, the method further comprises: if the current Suricata rule does not contain the transaction keyword, performing regular content matching.

[0026] Optionally, the content of the first rule is “existence of login behavior”, the content of the second rule is “existence of an identity card field”, and the content of the third rule is “existence of an identity card number”.

[0027] Optionally, the step S6 of matching the flow identifier and the transaction identifier of the second packet with the flow identifier and the transaction identifier in each transaction association relationship in the cache comprises:

[0028] querying whether the flow identifier and the transaction identifier of the second packet are contained in the combination of the flow identifier and the transaction identifier in each transaction association relationship in the cache;

[0029] if the combination is contained in the first transaction association relationship, it is determined that the second packet matches the first transaction association relationship successfully.

[0030] Optionally, the transaction keyword comprises a setting keyword, a checking keyword and a clearing keyword, and the step S4 of checking whether the current Suricata rule contains the preset transaction keyword comprises:

[0031] checking whether the current Suricata rule contains one of the setting keyword, the checking keyword and the clearing keyword, and if so, it is determined that the current Suricata rule contains the transaction keyword.

[0032] The second aspect of the present application provides an improved Suricata flow detection device applied to a Suricata application program, and the device comprises:

[0033] a flow identifier generating module, configured to generate a flow identifier according to five-tuple information of the first packet and a preset flow identifier generating algorithm after receiving the first packet;

[0034] a transaction identifier generating module, configured to query whether the first packet is a new transaction in a preset transaction array according to the flow identifier and a protocol structure of an application layer, and determine a transaction identifier of the first packet;

[0035] a loading module, configured to load a plurality of Suricata rules, and match the first packet with the plurality of Suricata rules one by one;

[0036] a first matching module, configured to check whether a preset transaction keyword is contained in a current Suricata rule, and if the transaction keyword is contained, match the first packet with a first rule in the current Suricata rule;

[0037] a setting module, configured to set a flag bit with content of the first rule for a first transaction corresponding to the first packet when the first packet matches the first rule in the current Suricata rule, and save a first transaction association relationship of the flag bit, the flow identifier and the transaction identifier of the first packet into a cache;

[0038] a second matching module, configured to receive a second packet, and perform the method of the flow identifier generating module, the transaction identifier generating module and the loading module on the second packet, match the flow identifier and the transaction identifier of the second packet with the flow identifier and the transaction identifier in each transaction association relationship in the cache respectively if the current Suricata rule contains the transaction keyword, and if the matching with the first transaction association relationship is successful, check whether the flag bit in the first transaction association relationship exists in the second packet, and if the flag bit exists, match the second packet with a second rule in the Suricata rule;

[0039] a third matching module, configured to receive a third packet, and perform the method of the flow identifier generation module, the transaction identifier generation module, and the loading module on the third packet, if the current Suricata rule contains the transaction keyword, and the second packet matches the second rule successfully in the second matching module, then match the flow identifier and the transaction identifier of the third packet with the flow identifier and the transaction identifier in each transaction association relationship in the cache respectively, if the match with the first transaction association relationship is successful, then check whether the flag bit exists in the third packet, if the flag bit exists, then match the third packet with a third rule in the Suricata rule; wherein the first packet, the second packet, and the third packet are three packets received by Suricata in sequence, and the content of the first rule, the second rule, and the third rule is three kinds of behavior information arranged in the order of execution in network attack behavior;

[0040] an alarm module, configured to clear the association relationship in the first transaction and generate alarm information if the third packet matches the third rule successfully.

[0041] The third aspect of the present application provides an electronic device, which comprises a processor and a memory, and the memory stores at least one instruction, at least one program, a code set or an instruction set, and the at least one instruction, the at least one program, the code set or the instruction set is loaded and executed by the processor to realize the improved Suricata flow detection method as described in the first aspect.

[0042] The fourth aspect of the present application provides a computer readable storage medium, which stores at least one instruction, at least one program, a code set or an instruction set, and the at least one instruction, the at least one program, the code set or the instruction set is loaded and executed by the processor to realize the improved Suricata flow detection method as described in the first aspect.

[0043] The embodiments of the present application have the following beneficial effects:

[0044] The improved Suricata flow detection method provided by the embodiment of the application comprises the following steps: S1, after receiving a first packet, generating a flow identifier according to five-tuple information of the first packet and a preset flow identifier generation algorithm; S2, querying whether the first packet is a new transaction in a preset transaction array according to the flow identifier and a protocol structure of an application layer, and determining a transaction identifier of the first packet; S3, loading a plurality of Suricata rules, and matching the first packet with the plurality of Suricata rules one by one; S4, checking whether a preset transaction keyword is contained in a current Suricata rule, and if the transaction keyword is contained, matching the first packet with a first rule in the current Suricata rule; S5, when the first packet matches the first rule in the current Suricata rule, setting a flag bit with the first rule as content for a first transaction corresponding to the first packet, and saving a first transaction association relationship of the flag bit, the flow identifier and the transaction identifier of the first packet into a cache; S6, receiving a second packet, and performing steps S1-S3 on the second packet, if the current Suricata rule contains the transaction keyword, matching the flow identifier and the transaction identifier of the second packet with the flow identifier and the transaction identifier in each transaction association relationship in the cache respectively, if the matching with the first transaction association relationship is successful, checking whether the flag bit in the first transaction association relationship exists in the second packet, if the flag bit exists, matching the second packet with a second rule in the Suricata rule; S7, receiving a third packet, and performing steps S1-S3 on the third packet, if the current Suricata rule contains the transaction keyword, and the second packet matches the second rule successfully in step S6, matching the flow identifier and the transaction identifier of the third packet with the flow identifier and the transaction identifier in each transaction association relationship in the cache respectively, if the matching with the first transaction association relationship is successful, checking whether the flag bit exists in the third packet, if the flag bit exists, matching the third packet with a third rule in the Suricata rule; and S8, if the third packet matches the third rule successfully, clearing the association relationship in the first transaction, and generating an alarm information. The scheme is a transaction-based flow detection technology, based on an application layer transaction, not relying on a transport layer connection only; and by binding a state with a transaction, fine management of the state is ensured, states set for different transactions are completely invisible, false positives caused by sharing of the state are completely eliminated; and when an HTTP request-response ends, all labels set for the transaction can be cleared, preventing the state from leaking from one transaction to another irrelevant transaction; in addition, the flow detection based on the transaction can support multiplexing of a plurality of application protocols on a same connection. Attached Figure Description

[0045] Figure 1 A flowchart illustrating the steps of an improved Suricata flow detection method provided in this embodiment of the invention;

[0046] Figure 2 This is a schematic diagram illustrating the relationship between streams, messages, and transactions provided in an embodiment of the present invention;

[0047] Figure 3 This is a structural block diagram of an improved Suricata flow detection device provided in an embodiment of the present invention. Detailed Implementation

[0048] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present solution, and not all embodiments. Based on the embodiments of the present solution, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present solution.

[0049] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of embodiments of this disclosure, unless otherwise stated, "a plurality of" means two or more. Furthermore, the use of "based on" or "according to" implies openness and inclusiveness, because processes, steps, calculations, or other actions "based on" or "according to" one or more of the stated conditions or values ​​may in practice be based on additional conditions or beyond the stated values.

[0050] Figure 1 The flowchart illustrates the steps of an improved Suricata flow detection method provided in this embodiment of the invention.

[0051] like Figure 1 As shown, this method, applied to the Suricata application, includes the following steps:

[0052] Step S1: After receiving the first message, generate a flow identifier based on the five-tuple information of the first message and a preset flow identifier generation algorithm.

[0053] Suricata is an open-source, high-performance network security monitoring engine primarily used for Intrusion Detection System (IDS), Intrusion Prevention System (IPS), and Network Security Monitoring System (NSM).

[0054] Suricata receives the first packet, parses the network layer and transport layer protocol, and obtains the five-tuple information. The five-tuple information is source IP, destination IP, source port, destination port, and transport layer protocol.

[0055] The preset flow identifier generation algorithm can be a hash algorithm. Suricata generates a flow identifier according to the five-tuple information of the packet and the hash algorithm, and uses flow_id to represent the flow identifier.

[0056] As an optional embodiment, after the flow identifier is generated according to the five-tuple information of the first packet and the preset flow identifier generation algorithm in step S1, the method further includes:

[0057] Step S11: Query whether the flow identifier exists in the preset flow table.

[0058] Step S12: If not, create a new flow record, and add the flow identifier to the flow table.

[0059] In S11-S12, it is queried whether the flow_id exists in the preset flow table. The flow table is a table including all flow records (flow records are represented by flow_entry) of flow_id, which is established in advance.

[0060] If the flow_id does not exist, it means that the flow is a new flow, a new flow record is created, and the flow_id uniquely identifying the flow record is added to the flow table, and then S2 is executed.

[0061] If the flow_id exists in the flow table, S2 is directly executed.

[0062] Step S2: According to the flow identifier and the protocol structure of the application layer, query whether the first packet is a new transaction in the preset transaction array, and determine the transaction identifier of the first packet.

[0063] The application layer protocol of the first packet is parsed, and according to the flow identifier and the protocol structure, it is judged whether the data packet is a new transaction (Transaction).

[0064] In Suricata, Transaction refers to a logical unit composed of multiple related data packets, which usually corresponds to a complete protocol interaction process. For example: HTTP transaction: a HTTP request and the corresponding response; TLS / SSL session: complete handshake process; SMTP session: complete dialogue of mail transmission.

[0065] If the flow identifier and protocol structure have appeared in previous messages, it means that the first message is not a new transaction, and the transaction identifier of the first message is set to the transaction identifier of the previous message; if the flow identifier and protocol structure have not appeared in previous messages, it means that the first message is a new transaction, and a new transaction identifier is set directly for the first message.

[0066] As an optional embodiment, step S2, determining whether the first message is a new transaction based on the flow identifier and the application layer protocol structure, includes:

[0067] Step S21: Perform application layer protocol parsing on the first message to obtain the application layer protocol structure of the first message;

[0068] Step S22: Query the flow identifier and protocol structure of the first message in the preset transaction array. When there is a target transaction in the transaction array that is the same as the flow identifier and the protocol structure, set the transaction identifier of the first message as the transaction identifier of the target transaction.

[0069] Step S23: When there is no transaction in the transaction array that is identical to both the stream identifier and the protocol structure, a new transaction record is created, and the transaction identifier that uniquely identifies the transaction record is added to the transaction array.

[0070] In steps S21-S23, the application layer protocol structure may include HTTP protocol, WebSocket protocol, etc. When a target transaction with the same flow_id and protocol structure as the first message exists in the transaction array, it indicates that the first message is not a new transaction. At this time, the transaction identifier of the target transaction (represented by tx_id) is obtained, and the tx_id of the first message is set as the tx_id of the target transaction.

[0071] If it is a new transaction, a new transaction record (represented by tx_entry) is created, and the tx_id that uniquely identifies the transaction record is added to the transaction array (represented by tx_array) corresponding to the stream.

[0072] Figure 2 This is a schematic diagram illustrating the relationship between flow, message, and transaction provided in an embodiment of the present invention.

[0073] like Figure 2 As shown, a flow is a top-level container. It represents a complete, continuous communication process, which is flow1 in the diagram.

[0074] A transaction (transaction 1) is a component of a flow. One flow can contain one or more transactions. In the figure, flow1 contains transaction 1. A transaction usually represents one complete request-response interaction.

[0075] A message (message 1, message 2,...) is the specific content of a transaction. A transaction is composed of a series of messages.

[0076] In transaction 1, message 1 and message 2 together constitute an HTTP request. Message 3, message 4 and message 5 together constitute the corresponding HTTP response. A transaction usually consists of a request message sequence and a response message sequence.

[0077] In simple terms, their relationship is flow>transaction>message. A flow is composed of multiple transactions, and each transaction is composed of specific request and response messages.

[0078] Step S3: Load multiple Suricata rules, and match the first message with the multiple Suricata rules one by one.

[0079] The application adds support for application layer transactions on the basis of flow, can solve the deficiency of the existing flow detection technology, adds a transaction-level detection keyword, that is, a transaction keyword, in part of the Suricata rules, and the transaction keyword binds the life cycle of a state to an application layer transaction.

[0080] When the message is matched with each Suricata rule one by one, if the current Suricata rule contains a transaction keyword, a transaction matching processing flow is entered.

[0081] As an optional embodiment, the transaction keyword includes a set keyword, a check keyword and a clear keyword, and the step S4 checks whether the current Suricata rule contains a preset transaction keyword, including:

[0082] It is checked whether the current Suricata rule contains one of the set keyword, the check keyword and the clear keyword, and if yes, it is determined that the current Suricata rule contains the transaction keyword.

[0083] In the embodiment of the application, the transaction keyword includes a set keyword txset, a check keyword txisset and a clear keyword txunset.

[0084] txset is used to set a flag or variable for the current transaction when certain conditions are detected. Example: txbits:txset, name. Where txbits is the transaction bit operation keyword used to operate and detect on transactions; name is the value for txset, for example, name can be user_login_attempted. txbits:txset, user_login_attempted means: set flag user_login_attempted for the current transaction.

[0085] txisset is used to check if a certain variable has been set for the current transaction. Example: txbits:txisset, name. name is the value for txisset, for example, name can be user_login_attempted. txbits:txisset, user_login_attempted means: check if flag user_login_attempted exists for the current transaction.

[0086] txunset is used to clear a previously set transaction variable. Example: txbits:txunset, user_login_attempted, which means: clear flag user_login_attempted.

[0087] Step S4: Check if the current Suricata rule contains a preset transaction keyword, if yes, match the first packet with the first rule in the current Suricata rule.

[0088] When the current Suricata rule contains a transaction keyword, enter the transaction matching process.

[0089] The current Suricata rule includes multiple rules (such as the first rule, the second rule, and the third rule), and the contents of the multiple rules are matched with the contents of the first packet respectively to see which rule the first packet hits.

[0090] After loading multiple Suricata rules in step S4, the first packet is matched with the multiple Suricata rules one by one, and the method further comprises:

[0091] If the current Suricata rule does not contain the transaction keyword, perform regular content matching.

[0092] When the Suricata rule does not contain any transaction keyword, the entire transaction state management is skipped, and regular content matching is performed directly.

[0093] Thus, for Suricata rules that do not need to perform transaction rule matching, unnecessary calculation loss can be avoided, memory occupation can be reduced, and processing efficiency can be improved.

[0094] Step S5: When the first packet matches the first rule in the current Suricata rule, a flag bit with the first rule as content is set for the first transaction corresponding to the first packet; and a first transaction association relationship among the flag bit, a flow identifier of the first packet, and a transaction identifier is saved into a cache.

[0095] In a possible implementation, the content of the first rule is "existence of login behavior", the content of the second rule is "existence of an identity card field", and the content of the third rule is "existence of an identity card number".

[0096] The following takes a network attack behavior targeting at platform login once as an example for illustration.

[0097] Step 1: Detecting a login request

[0098] alert http any any ->any any (msg:"Step 1 - User Login Detected";flow:established,to_server;

[0099] http.method; content:"POST";

[0100] http.uri;content:" / login";

[0101] http.request_body; content:"username=";

[0102] txbits:txset,user_login_attempted;

[0103] noalert;

[0104] sid:1000001; rev:1;)

[0105] The rule functions to detect the HTTP POST login request (access / login and the request body contains username=) in the packet. When the packet matches the first rule in the Suricata rule, the flag bit with the content of the first rule is set for the first transaction corresponding to the first packet. The first rule is that the "login behavior" exists in the packet, that is, the username=user_login_attempted field is contained. When matching the first rule, the flag bit with the content of the "login behavior" is set for the first transaction corresponding to the packet, that is, txbits:txset,user_login_attempted.

[0106] The flag bit is associated with the subsequent request to realize state tracking.

[0107] In addition, noalert in the code means that only the state is recorded, and no alert is generated. That is, the first rule is hit, and no alert is generated.

[0108] Then, the first transaction association relationship among the flag bit (user_login_attempted), the flow identifier (flow_id) of the first packet, and the transaction identifier (tx_id) is saved in the cache.

[0109] Step S6: receiving a second packet, and performing steps S1-S3 on the second packet, if the current Suricata rule contains the transaction keyword, matching the flow identifier and the transaction identifier of the second packet with the flow identifier and the transaction identifier in each transaction association relationship in the cache; if the first transaction association relationship is matched successfully, checking whether the flag bit in the first transaction association relationship exists in the second packet, if the flag bit exists, matching the second packet with the second rule in the Suricata rule.

[0110] The second packet refers to the packet received after the first packet.

[0111] First, by matching the flow identifier and the transaction identifier of the second packet with the flow identifier and the transaction identifier in each transaction association relationship in the cache, it is determined which flow and which transaction the second packet belongs to that has been created previously. If the second packet matches the first transaction association relationship successfully, it means that the second packet and the first packet belong to the same flow and the same transaction.

[0112] When it is determined that the second packet and the first packet belong to the same flow and the same transaction, the second rule is matched with the second packet.

[0113] The matching process is described in the second step of the above example:

[0114] Step 2: Detecting sensitive information

[0115] alert http any any ->any any (msg:"Step 2 - Sensitive Action AfterLogin"; flow:established,from_server;

[0116] http.response_body;content:"id card number"; txbits:txisset,user_login_attempted;

[0117] noalert;

[0118] sid:1000002; rev:1;)

[0119] In this rule, txbits:txisset,user_login_attempted is used to detect whether the user_login_attempted flag in the first transaction association is contained in the packet. If it is contained, the second rule is matched, which is whether the "id card number" field is contained in the packet. When it is contained, the second rule is matched successfully, confirming that it is the sensitive action of obtaining the ID card number after login.

[0120] In addition, noalert in this rule means that only the state is recorded, and no alert is generated. That is, the hit of the second rule will not generate an alert.

[0121] As an optional embodiment, the matching of the flow identifier and the transaction identifier of the second packet with the flow identifier and the transaction identifier in each transaction association in the cache in step S6 comprises:

[0122] Step S61: Query whether the combination of the flow identifier and the transaction identifier of the second packet is contained in the combination of the flow identifier and the transaction identifier in each transaction association in the cache;

[0123] Step S62: If the combination is contained in the first transaction association, it is determined that the second packet matches the first transaction association successfully.

[0124] In S61-S62, the combination key = (flow identifier, transaction identifier) can uniquely identify a specific transaction. The combination keys of the two packets are matched. If the flow identifier and the transaction identifier are the same, it means that the two packets belong to the same transaction, and the transaction association is matched successfully.

[0125] S7: receiving a third packet, and performing steps S1-S3 on the third packet, if the current Suricata rule contains the transaction keyword, and the second packet matches the second rule successfully in step S6, then matching the flow identifier and the transaction identifier of the third packet with the flow identifier and the transaction identifier in each transaction association relationship in the cache respectively; if matching the first transaction association relationship successfully, then checking whether the third packet contains the flag bit, if the third packet contains the flag bit, then matching the third packet with the third rule in the Suricata rule; wherein the first packet, the second packet and the third packet are three packets received by Suricata in sequence; the content of the first rule, the second rule and the third rule is three kinds of behavior information arranged in the order of execution in network attack behavior respectively.

[0126] The third packet refers to a packet received after the second packet.

[0127] If the second packet matches the second rule successfully, and after determining that the third packet and the first packet and the second packet belong to the same transaction of the same flow, it is judged whether the third packet matches the third rule; if the second packet does not match the second rule, then after determining that the third packet and the first packet belong to the same transaction of the same flow, the third packet is matched with the second rule.

[0128] It is judged whether the third packet matches the third rule, and the matching process is described in the third step of the above example:

[0129] # Step 3: clear the flag user_login_attempted and alarm

[0130] alert http any any ->any any (msg:"Step 2 - Finished"; flow:established,from_server;

[0131] http.response_body;content:"610000000199909041111"; txbits:txunset,user_login_attempted;

[0132] alert;

[0133] sid:1000003; rev:1;)

[0134] The meaning of the above rule is: whether the identity card number is contained in the message, when contained, the third rule is matched successfully, and it is determined that the identity card number is obtained. At this time, txbits:txunset, user_login_attempted are executed, that is, the flag bit user_login_attempted is cleared.

[0135] S8: if the third message is matched successfully with the third rule, the association relationship in the first transaction is cleared, and alarm information is generated.

[0136] The alert in the code in step 3 means: alarm is generated. That is, the first rule, the second rule and the third rule are continuously hit to generate an alarm.

[0137] In addition, the first transaction association relationship of the flag bit, the flow identifier of the first message and the transaction identifier in the cache also needs to be deleted. In this way, when an HTTP request-response ends, all the labels set for the transaction can be cleared, which perfectly prevents the state from "leaking" from one transaction to another unrelated transaction, even if they share the same TCP connection.

[0138] The application adds the support of application layer transaction based on the flow, can solve the deficiency of the existing flow detection technology, and adds the transaction level detection keyword in the method: setting keyword (txset), checking keyword (txisset) and clearing keyword (txunset), the set of keywords binds the life cycle of the state with an application layer transaction:

[0139] 1. The scheme distinguishes the transaction according to the protocol structure of the application layer, is a transaction-based flow detection technology, is based on the application layer transaction, is an application layer concept, and does not rely on the transmission layer connection alone.

[0140] 2. The problem of too rough granularity can be solved. For example: by binding the state with "transaction" instead of "flow", the txset and the like keywords ensure the fine management of the state. In the same TCP and UDP connection, the state set by transaction A is completely invisible to transaction B, which completely eliminates the false alarm caused by sharing the state.

[0141] 3. The problem of life cycle mispositioning can be solved. The life cycle of the state is synchronized with the transaction, when an HTTP request-response ends, all the labels set for the transaction can be cleared, which perfectly prevents the state from "leaking" from one transaction to another unrelated transaction, even if they share the same TCP connection.

[0142] 4. Can support multiple application protocol multiplexing the same connection problem. For example: when the current connection is transmitting HTTP protocol, the current transaction id corresponds to the HTTP protocol, and the state label is also attached to the HTTP transaction; when the WebSocket protocol is changed, the current transaction id corresponds to the WebSocket protocol, and the state label is also attached to the WebSocket transaction. Perfectly support multiple application protocol multiplexing the same connection problem.

[0143] In summary, the improved Suricata flow detection method provided by the embodiment of the application comprises:

[0144] S1: after receiving the first packet, generating a flow identifier according to the five-tuple information of the first packet and a preset flow identifier generation algorithm; S2: according to the flow identifier and the protocol structure of the application layer, querying whether the first packet is a new transaction in a preset transaction array, and determining the transaction identifier of the first packet; S3: loading a plurality of Suricata rules, and matching the first packet with the plurality of Suricata rules one by one; S4: checking whether the current Suricata rule contains a preset transaction keyword, if yes, matching the first packet with a first rule in the current Suricata rule; S5: when the first packet matches the first rule in the current Suricata rule, setting a flag bit with the first rule as content for a first transaction corresponding to the first packet; and saving a first transaction association relationship of the flag bit, the flow identifier and the transaction identifier of the first packet into a cache; S6: receiving a second packet, and performing steps S1-S3 on the second packet, if the current Suricata rule contains the transaction keyword, matching the flow identifier and the transaction identifier of the second packet with the flow identifier and the transaction identifier in each transaction association relationship in the cache respectively; if matching with the first transaction association relationship is successful, checking whether the flag bit in the first transaction association relationship exists in the second packet, if the flag bit exists, matching the second packet with a second rule in the Suricata rule; S7: receiving a third packet, and performing steps S1-S3 on the third packet, if the current Suricata rule contains the transaction keyword, and the second packet matches the second rule successfully in step S6, matching the flow identifier and the transaction identifier of the third packet with the flow identifier and the transaction identifier in each transaction association relationship in the cache respectively; if matching with the first transaction association relationship is successful, checking whether the flag bit exists in the third packet, if the flag bit exists, matching the third packet with a third rule in the Suricata rule; S8: if the third packet matches the third rule successfully, clearing the association relationship in the first transaction, and generating an alarm information. The scheme is a transaction-based flow detection technology, based on the application layer transaction, not relying on the transport layer connection alone; and by binding the state with the transaction, the fine management of the state is ensured, the state set by different transactions is completely invisible, and the false alarm caused by sharing the state is completely eliminated; and when an HTTP request-response ends, all labels set for the transaction can be cleared, preventing the state from "leaking" from one transaction to another unrelated transaction; in addition, the flow detection based on the transaction can support multiple application protocols multiplexing the same connection.

[0145] Figure 3is a structural block diagram of an improved Suricata flow detection device provided by an embodiment of the application.

[0146] As shown in Figure 3 The device 300 is applied to a Suricata application program, and the device comprises:

[0147] A flow identifier generation module 301 is configured to, after receiving a first packet, generate a flow identifier according to five-tuple information of the first packet and a preset flow identifier generation algorithm.

[0148] A transaction identifier generation module 302 is configured to, according to the flow identifier and a protocol structure of an application layer, query whether the first packet is a new transaction in a preset transaction array, and determine a transaction identifier of the first packet.

[0149] A loading module 303 is configured to load a plurality of Suricata rules, and match the first packet with the plurality of Suricata rules one by one.

[0150] A first matching module 304 is configured to check whether a preset transaction keyword is contained in a current Suricata rule, and if the transaction keyword is contained, match the first packet with a first rule in the current Suricata rule.

[0151] A setting module 305 is configured to, when the first packet matches the first rule in the current Suricata rule, set a flag bit with content of the first rule for a first transaction corresponding to the first packet, and save a first transaction association relationship among the flag bit, a flow identifier and a transaction identifier of the first packet into a cache.

[0152] A second matching module 306 is configured to receive a second packet, and perform the above steps on the second packet, if the current Suricata rule contains the transaction keyword, match a flow identifier and a transaction identifier of the second packet with flow identifiers and transaction identifiers in each transaction association relationship in the cache respectively, if the matching with the first transaction association relationship is successful, check whether the first transaction association relationship contains a flag bit in the second packet, if the flag bit is contained, match the second packet with a second rule in the Suricata rule.

[0153] The third matching module 307 is configured to receive a third packet, and perform the above steps on the third packet. If the current Suricata rule contains the transaction keyword, and the second packet matches the second rule successfully, the flow identifier and the transaction identifier of the third packet are matched with the flow identifier and the transaction identifier in each transaction association relationship in the cache. If the first transaction association relationship is matched successfully, it is checked whether the third packet contains the flag bit. If the third packet contains the flag bit, the third packet is matched with the third rule in the Suricata rule. The first packet, the second packet, and the third packet are three packets received by Suricata in sequence. The first rule, the second rule, and the third rule are three pieces of behavior information arranged in the order of execution in network attack behavior.

[0154] The alarm module 308 is configured to clear the association relationship in the first transaction, and generate alarm information if the third packet matches the third rule successfully.

[0155] For the device in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be described in detail here.

[0156] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer readable storage medium, and when the computer program is executed, the processes of the above-mentioned embodiments of the method can be included. Any reference to memory, storage, database or other medium used in each embodiment provided by the present application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. As an illustration but not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0157] Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the features disclosed herein. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.

[0158] It should be understood that the present disclosure is not limited to the precise structures as herein described and illustrated in the drawings, and that various modifications and changes can be made without departing from its scope. The scope of the present disclosure is limited only by the claims that follow.

Claims

1. An improved Suricata stream detection method, characterized in that, The method applied to a Suricata application program comprises: Step S1: after receiving a first packet, generating a flow identifier according to five-tuple information of the first packet and a preset flow identifier generation algorithm; Step S2: querying whether the first packet is a new transaction in a preset transaction array according to the flow identifier and a protocol structure of an application layer, and determining a transaction identifier of the first packet; Step S3: loading a plurality of Suricata rules, and matching the first packet with the plurality of Suricata rules one by one; Step S4: checking whether a preset transaction keyword is contained in a current Suricata rule, and if so, matching the first packet with a first rule in the current Suricata rule; Step S5: when the first packet matches the first rule in the current Suricata rule, setting a flag bit with content of the first rule for a first transaction corresponding to the first packet, and saving a first transaction association relationship of the flag bit, the flow identifier and the transaction identifier of the first packet into a cache; Step S6: receiving a second packet, and performing steps S1-S3 on the second packet, if the current Suricata rule contains the transaction keyword, matching the flow identifier and the transaction identifier of the second packet with the flow identifier and the transaction identifier in each transaction association relationship in the cache respectively, if matching with the first transaction association relationship is successful, checking whether the flag bit in the first transaction association relationship exists in the second packet, if the flag bit exists, matching the second packet with a second rule in the Suricata rule; Step S7: receiving a third packet, and performing steps S1-S3 on the third packet, if the current Suricata rule contains the transaction keyword, and the second packet matches the second rule successfully in step S6, matching the flow identifier and the transaction identifier of the third packet with the flow identifier and the transaction identifier in each transaction association relationship in the cache respectively, if matching with the first transaction association relationship is successful, checking whether the flag bit exists in the third packet, if the flag bit exists, matching the third packet with a third rule in the Suricata rule; wherein the first packet, the second packet and the third packet are three packets received by Suricata in sequence, and content of the first rule, the second rule and the third rule is three kinds of behavior information arranged in sequence according to execution in network attack behaviors; Step S8: if the third packet matches the third rule successfully, clearing the association relationship in the first transaction, and generating an alarm information.

2. The method of claim 1, wherein, After generating the flow identifier according to the five-tuple information of the first packet and the preset flow identifier generation algorithm in step S1, the method further comprises: querying whether the flow identifier exists in a preset flow table; If not, a new flow record is created and the flow identifier is added to the flow table.

3. The method of claim 1, wherein, The step S2 of determining whether the first message is a new transaction according to the flow identifier and the protocol structure of the application layer comprises: performing application layer protocol analysis on the first message to obtain the application layer protocol structure of the first message; querying the flow identifier and the protocol structure of the first message in a preset transaction array, and setting the transaction identifier of the first message as the transaction identifier of a target transaction in the transaction array when the target transaction with the same flow identifier and protocol structure as the first message exists in the transaction array; when the transaction array does not contain a transaction with the same flow identifier and protocol structure as the first message, a new transaction record is created, and a transaction identifier uniquely marking the transaction record is added to the transaction array.

4. The method of claim 1, wherein, After the step S4 of checking whether the current Suricata rule contains a preset transaction keyword, the step S4 further comprises: if the current Suricata rule does not contain the transaction keyword, performing regular content matching.

5. The method of claim 1, wherein, The content of the first rule is "existence of login behavior", the content of the second rule is "existence of identity card field", and the content of the third rule is "existence of identity card number".

6. The method of claim 1, wherein, The step S6 of matching the flow identifier and the transaction identifier of the second message with the flow identifier and the transaction identifier in each transaction association relationship in the cache comprises: querying whether the flow identifier and the transaction identifier of the second message are contained in the flow identifier and the transaction identifier combination in each transaction association relationship in the cache; if the combination is contained in the first transaction association relationship, it is determined that the second message matches the first transaction association relationship successfully.

7. The method of claim 1, wherein, The transaction keyword comprises a setting keyword, a checking keyword and a clearing keyword, and the step S4 of checking whether the current Suricata rule contains a preset transaction keyword comprises: checking whether the current Suricata rule contains one of the setting keyword, the checking keyword and the clearing keyword, and if yes, it is determined that the current Suricata rule contains the transaction keyword.

8. An improved Suricata flow detection device, characterized by, The device is applied to a Suricata application program, and comprises: a flow identifier generation module configured to generate a flow identifier according to five-tuple information of a first message and a preset flow identifier generation algorithm after receiving the first message; a transaction identifier generation module configured to query whether the first message is a new transaction in a preset transaction array according to the flow identifier and a protocol structure of an application layer, and determine a transaction identifier of the first message; a loading module configured to load a plurality of Suricata rules, and match the first message with the plurality of Suricata rules one by one; a first matching module configured to check whether a current Suricata rule contains a preset transaction keyword, and if yes, match the first message with a first rule in the current Suricata rule; The setting module is configured to set a flag bit with the first rule as content for a first transaction corresponding to the first packet when the first packet matches the first rule in the current Suricata rule, and save a first transaction association relationship of the flag bit, a flow identifier of the first packet, and a transaction identifier into a cache; The second matching module is configured to receive a second packet, and perform the method of the flow identifier generation module, the transaction identifier generation module, and the loading module on the second packet. If the current Suricata rule contains the transaction keyword, the flow identifier and the transaction identifier of the second packet are matched with the flow identifier and the transaction identifier in each transaction association relationship in the cache. If the first transaction association relationship is matched successfully, it is checked whether the flag bit in the first transaction association relationship exists in the second packet. If the flag bit exists, the second packet is matched with a second rule in the Suricata rule. The third matching module is configured to receive a third packet, and perform the method of the flow identifier generation module, the transaction identifier generation module, and the loading module on the third packet. If the current Suricata rule contains the transaction keyword, and the second packet is matched with the second rule successfully in the second matching module, the flow identifier and the transaction identifier of the third packet are matched with the flow identifier and the transaction identifier in each transaction association relationship in the cache. If the first transaction association relationship is matched successfully, it is checked whether the flag bit exists in the third packet. If the flag bit exists, the third packet is matched with a third rule in the Suricata rule. The first packet, the second packet, and the third packet are three packets received by Suricata in sequence. The first rule, the second rule, and the third rule contain three kinds of behavior information in network attack behaviors arranged in sequence according to execution order. The alarm module is configured to clear the association relationship in the first transaction and generate an alarm information if the third packet is matched with the third rule successfully.

9. An electronic device, comprising: The electronic device includes a processor and a memory. The memory stores at least one instruction, at least one program, a code set, or an instruction set. The at least one instruction, the at least one program, the code set, or the instruction set is loaded and executed by the processor to implement the improved Suricata flow detection method according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The storage medium stores at least one instruction, at least one program, a code set, or an instruction set. The at least one instruction, the at least one program, the code set, or the instruction set is loaded and executed by the processor to implement the improved Suricata flow detection method according to any one of claims 1-7.

Images